Manual de Referencia SQL

I
Contenido
Agradecimientos Introduccin ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xxiii xxv
PARTE 1 Visin general de SQL
1.
Jotrod uccin
3
4
'.
El lenguaje SQL __ _ . El papel de SQL _................... Caractersticas y ventajas de SQL , . Independencia del fabricante . Transportabilidad entre sistemas informticos . Estndares SQL _ __ .' __ .. _. _ . Acuerdos y obligaciones de IBM (DB2) __ . . Obligaciones de Microsoft (SQL Server, ODBC y ADO) Fundamentos relacionales . Estructura de alto nivel en ingls , .. Consultas ad hoc interactivas . Acceso mediante programacin a bases de datos. _ _. _ . Vistas mltiples de los datos _. __ _ . Lenguaje completo de base de datos _ __ .. Definicin dinmica de datos _ _ _. _ . Arquitectura cliente/servidor . . . Soporte de aplicaciones empresariales . Extensibilidad y tecnologa de objetos _.... Acceso a bases de datos en Internet . Integracin de Java (IDBC) . _ _ . Infraestructura de la industria .
6
7 8 8
9 9
9
10 10
ID
11 1I II 1I 12
12
12 13 13 14
vii
l'
viii
Contenido
Contenido
ix
2. Una introduccin a SQL

Una base de datos simple Recuperacin de datos _ Resumen de datos .. ._ _ Adicin de datos a la base de datos .. " , ." , ,., Eliminacin de datos Actualizacin de la base de datos Proteccin de datos . Creacin de bases de datos .. Resumen -_ _.. _. _ _ ,
. . . . . .
15
15
El modelo relacional de datos .,., La base de datos de ejemplo, . "

Tablas.... ..
,. .
..
59
60
17
19 20 20
21 21
62
. ,
Claves primarias _.. _. _. . . . . . . . . . . Relaciones _. _ " . Claves externas _.. . .. , ,., Las 12 reglas de Codd '" , , Resumen .
PARTE 11 Recuperacin de datos
64 66 67
68
71
22 23
25
. , , , _
25
3. SQL en perspectiva
SQL y la gestin de bases de datos Una breve historia de SQL ,... . . "" Los primeros aos .. , , , , Los primeros productos relacionales Productos de mM Aceptacin comercial _. _
oO.,"
5.
Fundamentos de SQL
oO
75 75 77
26
28 28
.
_
oO, , .. '
Estndares de SQL ..................... , ............... ' Los estndares ANSIJISO ", Otros estndares de SQL ",, ODBC y el grupo de acceso SQL SQL y transportabilidad .. . . SQL y redes .,., .. , .. ,.",. .,.,.,,.,., , , , .... ' , , , . , .
.oO .. . oO,
Arquitectura Arquitectura Arquitectura Arquitectura SQL SQL SQL SQL
centralizada , del 'servidor de archivos cliente/servidor mullicapa _
, _ . .
.
29 30 32 32 34 35 36 38 38
39
Instrucciones , Nombres ,., , ,., Nombres de tablas Nombres de columnas Constantes Constantes Constantes Constantes Constantes . , . ".. , . " numricas , .. , de cadena de fecha y hora simblicas
,.,.,
" . .
. .
.
80
8J
Tipos de datos ... ,",."., .. ',.,' ............... ,",
81
' , , , ,., ' _ . .

oO '
86 86
87
88
Expresiones ,.,.,.,
89 89
90 91
93
40
42 42
Funciones predefinidas ., Datos ausentes (valores NULL) Resumen .

6.
... _......................
La proliferacin de SQL . , . , . . , . , . , , .. , . , SQL y la estrategia de la base de datos unificada de IBM
en las minicomputadoras . _ en los sistemas basados en UNIX en computadoras personales .. _ y el procesamiento de transacciones
, _, ,._ _ _ .
. .
44
44 45 45
Consultas simples
95 95 98 98 98
JOl 102
105
47
48 49 51 52
SQL y las bases de datos de trabajo en grupo ".,', SQL y los almacenes de datos ,.,.,
SQL y las aplicaciones distribuidas en Internet Resumen
_. _
_. . .
La instruccin SELECT _............................ La clusula SELECT _......................... , . La clusula FROM ..... Resultados de las consultas , . Consultas simples ., ,."...... ,.,., ' Columnas calculadas _. _. . _ _ _ _ Seleccin de todas las columnas (SELECT *) _
Filas duplicadas (DISTINCT) .. ,
4. Bases de datos relacionales

Los primeros modelos de datos . Sistemas gestores de archivos Bases de datos jerrquicas Bases de datos en red .. . _
53 53 53
55
. . .
56
Seleccin de filas (clusula WHERE) . . , Condiciones de bsqueda ," ,., ,.,." . El test de comparacin (=. <>. <, <=, >, >=) . El test pe rango (BETWEEN) .. _ . . _ . _ .. _ ....... El test de pertenencia a conjuntos (IN) . _ . El test de encaje de patrones (LIKE) "
, oO oO_,., , ..... ' ...........
106
107
109
110
113
115
117
Contenido
Contenido
xi
188
El lesl de valores nulos (15 NULL) . Condiciones compueslas de bsqueda (ANO. QR Y NOT) . Ordenacin de los resultados de las consultas (clusula ORDER BY) . Reglas para el procesamienLO de consuhas sobre una sola tabla . Combinacin de los resultados de las consultas (UNION)" . . Uniones y filas duplicadas * Uniones y ordenacin" .. . __ . Uniones mltiples" . __ . _................................ Resumen. . . . . . . . . . . . . . . . . . .. _....................... 7.
Consultas multitabla (reuniones)
119 121 124 127 128
130 131
132
133
135
Funciones de columna en ht lista de seleccin . Valores NULL y funcione de columna _. Eliminacin de filas duplicadas (DISTINCT) ............... Consultas de agrupacin (CI<iusula GROUP BY) . . . . . . . . . . . . . . . . . . Agrupacin de mltiples columnas ...................... __ Restricciones sobre las consultas de agrupacin .............. Valores NUT L en las consultas de agrupacin _ _. _. Condiciones de bsqueda de grupos (Clusula HAVING) . _ .. _ . Restricciones sobre las condiciones de bsqueda de grupos . Valores NULL )' condiciones de bsqueda de grupos . _. _. _. . HAVING sin GROUP BY _. Resumen . __ . . _......................................
189 191
192
196
198 200 201
Un ejemplo de consulta con dos tablas ........................ Reuniones simples (equirrcuniones) . _ _. Consultas padrelhijo . Reuniones con criterios de seleccin de filas . Encaje de mltiples columnas . Consultas con tres), ms labIas .......................... Otras cquirreuniones .. . _. _ . Reuniones sin igualdad _ _.......................... Considemciones sobre SQL y consultas multitabla ........... Nombres calificados de columnas ........................ Selecciones de todas las column<ls ...................... Autorreuniones _ _..................... Alias de tablas ......................................... Rendimiento de las consultas multitabla ....................... La estructura de una reunin . . Multiplicacin de tablas . Reglas para el procesamiento de consultas multitabla . Reuniones externas * . . . Reuniones externas por la izquierda y por la derecha '" Notacin de la reunin externa * . . Reuniones y el estndar SQL2 _ . Reuniones internas en SQL2 '" ............................. Reuniones externas en SQL2 '" _ Reuniones cruzadas y reuniones de unin en SQL2 ......... Reuniones multitabla en SQL2 . Resumen . _. _. _. _....................... _
135
205 205 206 206
137 139
141
142
143
9.
SubconsuJtas y expresiones de consultas ...................

Uso de las subconsullas _. _ _ _. _. Concepto de subconsulta . _.. _ __ . _....... Subconsultas en la clusula WHERE . Referencias externas _.. _ . Condiciones de bsqueda en las subconsultas ... _.... _ El test de comparacin en subconsultas (==. <>, <, <==, >, >=) El test de pertenencia a conjuntos (IN) ...................... El test de existencia (EXISTS) . Tests cuantificados(ANY y ALL) . . . . . . . . . . . . . . . . . . . . . . . . . Subconsultas y reuniones . Subconsultas anidadas Subconsultas correlacionadas * Subconsultas en la clusula HAVING '" ........... Resumen de las subconsultas .. . ......... Consultas avanzadas en SQL2 * .. Expresiones escalares (SQL2) Expresiones de filas (SQU) ........................ Expresiones de labias (SQL2) Expresiones de consulta (SQL2) ............. Consultas SQL: un resumen final ................ _..........
207
207 209
145
146
210
212 213
148
149
150
213 215
217
151 154 155

156 157
219
225 226
228
230 232
158 159 163

166 168
234
236 242 246
169
172
173
176 179
181
181 183 184 185 186
249 254
PARTE IJI Actualizacin de datos
8. Consultas de resumen
Funciones de columna _...... _ Clculo del lolal de una columna (SUM) Clculo de la media de una columna (AVG) . . . . . . . . . . . . . _ . . Bsqueda de valores extremos ('UN y MAX) Recuento de valores de datos (COUNT) .............. _
10.
Actualizaciones de la base de datos ....................... Adicin de datos a la base de datos ................. _..... _. La instruccin IN5ERT sobre una sola fila ...... _ _. _. . . La instruccin INSERT sobre varias filas _. . Utilidades de carga masiva _. . . . . . . . . . . . .
257 257 258 262 265
xii
Contenido
Contenido
xiii
Eliminacin de datos de la base de datos .............. La inslruccin DELETE . . . . . . . . . . . . . . . . . . . . . . . . . Eliminacin de todas las lilas . DELETE con subconsulla * ModifIcacin de datos de la base de datos La instruccin UPDATE Actualizacin de todas las filas . UPDATE con subconsulla * Resumen
266 266 268 269

271
271
274 274
276
.
JI.
Integridad de datos
277 277
279
Concepto de la integrIdad de datos . Datos requeridos Comprobacin simple de validez. Restricciones de comprobacin de columnas (SQL2) . Dominios (SQL2) Integridad de las entidades . Otras restricciones de unjcidad . Unicidad y valores NULL . ...... Integridad referencial ............................... Problemas de integridad referencial . Reglas de eliminacin y actualizacin *' ................... Eliminaciones y actualizaciones en cascada * Ciclos referenciales * . . Claves externas y valores NULL '" ........... Restricciones avanzadas (SQL2) Asertos ........... . . Tipos de restricciones en SQL2 . . . . . . . . . . . . . Comprobacin diferIda de restricciones . Reglas de negocio ......... . ....................... Concepto de disparador . Disparadores e integridad referencial . Ventajas e inconvenientes de los disparadores . Djsparadores y el estndar SQL ......................... Resumen.
El problema de los daLOs no comprometidos El problema de los datos inconsistentes El problema de la insercin fantasma Transacciones simultneas ............ Bloqueo * Niveles de bloqueo . Bloqueos compartidos y exclusivos lnterbloqueos * Tcnicas avanzadas de bloqueo * Versiones * . Funcionamiento de las versiones * Ventajas e inconvenientes de las versiones * Resumen
. . .
.
~.
327 328 330 331 333 334 336 338 339 346 346 350 350
280 281 282 283 284 284 285 286 288 292 294 299 300 301 302 303 306 308 310 311 312
313 315
PARTE IV Estructura de la base de datos
13.
Creacin de bases de datos

El lenguaje de definicin de datos Creacin de bases de datos. Definiciones de tablas . Creacin de tablas (CREATE TABLE) . Eliminacin de una tabla (DROP TABLE) _. Cambio de la definicin de una tabla (ALTER TABLE) Definicin de restricciones. . . . Asertos . Dominios Alias y sinnimos (CREATE/DROP ALIAS) ndices (CREATE/DROP INDEX). . ........... Gestin de otros objetos de la base de datos Estructura de la base de datos . Arquilectura de base de datos nica Arquitectura de mltiples base de datos Arquitectura de ubicacin mltiple Bases de datos en mltiples servidores . Estructura de la base de datos y el estndar ANSI/ISO ....... Catlogos en SQL2 .................. Esquemas en SQL2 . Resumen .
365
355 357 358 359 369 370 374 375 375 376
378
12.
Procesamiento de transacciones
Conceplo de transaccin ...............................
COMMIT y ROLLBACK . . . . . . . . . . . ......
315
317
382 386 387 388 390 392 393 395 396 400
401
El modelo de transacCIones ANSl/ISO Otros modelos de transacciones .. Transacciones: entre bastidores Transacciones y procesamiento multiusuario El problema de la actualizacin perdida ..
319 321 323 325 326
14.
Vistas .................................................
Concepto de vista El manejo de las vistas por el SGBD Ventajas de las vistas Inconvenientes de las vistas . .................... . .
401 403 404 404
xiv
Contenido
Contenido
xv
Creacin de vistas (CREATE VIE\-l) - . . . . . . . . . . . - . - .. - Vistas horizontales .. - .. Vistas verticales Vistas de subconjuntos de filas y columnas Vistas de agrupacin Vistas de reunin Actualizacin de vistas . . . . . . . . . . . . . . . . . . . Actualizaciones de vistas y el estndar ANSI/ISO Actualizaciones de vistas en producLOs SQL comerciales Comprobacin de las actualizaciones en las vistas
OPTION)
. . . . . _. .
(CHECK . .
405 405 407 409 410

412
PARTE V
Programacin con SQ L
17.
SQL incorporado
Tcnicas de programacin en SQL .. _ Procesamiento de instrucciones en el SGBD __ . _ Conceptos de SQL incorporado . Desarrollo de un programa SQL incorporado Ejecucin de un programa SQL incorporado Instrucciones simples de SQL incorporado Declaracin de tablas Manejo de crrores Uso de variables del anfitrin Recuperacin de datos con SQL incorporado Consultas de una nica fila Consultas de mltiples filas Eliminaciones y actualizaciones con cursores _. _ Los cursores y el procesamiento de transacciones Resumen .
.
.
481 481 483 485 486 490 492 495 497 506 513 514 521 530 534 535 537
414 415 416 417 419 420

422
425
Eliminacin de vistas (DROP Vistas materializadas * Resumen
VIEW)
.
.
. .
15.
Seguridad en SQL .......................................

Conceptos de seguridad en SQL . Identificadores de usuario . Objetos de seguridad _ . Privilegio . Las vistas y la seguridad en SQL . Concesin de privilegios (GRANT) . . . . . . . . . . . . . . . . . . . . . . . . Privilegios sobre columnas . Transmisin de privilegios (GRANT OPTION) .............. Retirada de privilegios (REVOKE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . REVOKE y GRANT OPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REVOKE y
425
427
432 432 436 438

440
. . _.. . . . . . . . .
18.
SQL dinmico Lmites de SQL esttico Conceptos de SQL dinmico Ejecucin de instrucciones dinmicas Ejecucin dinmica en dos pasos
La instrucci6n PREPARE
. _
(EXECUTE
441
444
_. .
537 539
541 544 .
IMMEDIATE)
446
el estndar ANSIIISO
. . . .. .
............
.
Resumen. . .. . . .. .. . . .
448 450 451

_. .
16.
El catlogo del sistema

El concepto de catlogo del sistema El catlogo y las herramientas de consulta El catlogo y el estndar ANSI/ISO Contenido del catlogo Informacin de tablas _ _. _ Informacin de columnas Informacin de vistas ._ Comentarios Informacin de relaciones Informacin de usuarios Informacin de privilegios El esquema de la informacin de SQL2 Otra informacin del catlogo Resumen
.
. . .
.
. . . . . . .
451 452 454 454 456 459 463 465 466 469 471
472 477 477
La instruccin EXECUTE .. .. .. .. . . Consultas dinmicas . La instruccin DESCRIBE _..................... La instruccin DECLARE CURSOR .......... _.......... La instruccin dinmica OPEN . . . . . . . . . . . . . . . . . . . . . . . La instruccin dinmica FETCH . . . . . . . . . . . . . . . . . . . . . . . La instruccin dinmica CLOSE .................
Dialectos de SQL dinmico ...............................

SQL dinmico en Oracle .. ................... _ .
SQL dinmico y el estndar SQL2

instrucciones bsicas de SQL2 dinmico SQL2 y SQLOA SQL2 y consultas de SQL dinmico Resumen _
.
.
.
547 548 557 563 565 566 569 570 570 571 575 575
577
. .
584
588 591 600
19.
Las API de SQL Conceptos de las API
.. .
,-xvi
Contenido Contenido
xvii
La API dbi lb (SQL Server) . . Tcnicas bsicas de SQL Server Consull.as de SQL Server _. Actualizaciones posicionadas . Consultas dinmicas _. ODBC y el estndar SQUCLI .. . . La estandarizacin de la imerfaz en el nivel de Ila~adas (CLI) Estructuras CLl . ProcesamienlO de inslrucciones CLl Errores e informacin de diagnstico en CLJ Atributos de CL! Llamadas de informacin a eL! La API de ODBC .. La estructura de ODSC ODBC y la independencia del SGBD . Funciones del catlogo de ODSC Capacidades ampl adas de ODBC La interfaz de llamadas de Oracle (OCl) Conlroladores OCI . . Conexin a un servidor de OracJe Ejecucin de inslrucciones . Procesamiento de los resultados de una consulta Manejo de descriplores . . . . . . . . . . . Gestin de Lransacciones _ . Conectividad con bases de datos Java (JDBC) . Historia y versiones de JDBe .... . ..... _ _ . lmplememaciones de lDSC y Lipos de conLroladores __ La API de JDBC Resumen _ .
594 595
602 608 609 614 615 620 624 647 649 651 652
653
654 655 656
660
662 663 664 21.
. de flujo de control Repeticin con cursores . Gestin de condiciones de error VClllajas de los procedimienlOs almacenados Rendimiento de lo!'. procedimientos almacenado~ . _ Procedimientos almacenados definidos por el sistema Pro<.:edimientos almacenados exlernos . Disparadores . . Ventajas e inconvenicllles de los disparadores . Disparadores en TrunsacLSQL Disparadores en SPL de lnrormix Disparadores en PLlSQL de Gracle Olras consideraciones sobre los disparadores Procedimientos almacenados. disparadores y el estndar SQL El estndar de Jos procedimientos almacenados SQLlPSM Estndares de disparadores en SQL: 1999 . Resumen .
OLra~ conslrUClOra~
Ejecucin repelida
721
724
. . .
.
725
729
730 733 733

734
735 736 737

739 741 742
743
744 753
754 757
758
SQL y los almacenes de dalos
665
666 666 668 669 670 676 696
PARTE VI SQL hoy y maana

20. Procesamiento de bases de dalos y procedimientos almacenados
Conceplos de los almacenes de daLos . Componentes de un almacn de datos La evolucin de los almacenes de dalos Arquiteclura de las bases de datos para los almacenes de datos Cubos de hechos . Esquemas en estrella. _ Dimensiones multinivel _. . EXlensiones de SQL para los almacenes de dalos Rendimiento de los almacenes de datos Rendimiento de la carga Rendimienlo de las consultas Resumen. . . . . . . . . . . .
22. SQL l' los servidores de aplicaciones.. .. .. .... . .. .. .
760 761
. . . . . . . . .
.. .. . 762 762 764 766 768 769 769 771
772
775 775
701
702 704 706
Conceptos de los procedimienLos almacenados Un ejemplo bsico Uso de Jos procedimientos almacenados .. Creacin de un procedimiento almacenado Llamada a un procedim.iento almacenado Variables de los procedimientos almacenados Bloques de instrucciones . . Devolucin de un valor Devolucin de valores por parmetros Ejecucin condicional
. . . . .
706 708 710

713
715
717
720
SQL y los SiLios web: las primeras implementaciones Los servidores de aplicaciones y las arquitecturas de tres capas de los sitios web .. ......... ......... Acceso a bases de datos desde los servidores de aplicaciones. . . . . . Tipos EJB .. .. Acceso a bases de dalas con sesiones bean ............. ......... . Acceso a entidades con sesiones bean _. Mejoras de EJB 2.0 . . . . . . . . . . . ... . . .... . . . . . Cach de los servidores de aplicaciones .. .. .. . .. . Resumen .......... ...............
777 779 780 782 786
790
791 793
xviii
Contenido
Contenido
xix
872
23.
Redes SQL y bases de datos distribuidas El desafo de la gestin de datos distribuidos . Distribucin de datos: enfoques prcticos _. _ . Acceso a bases de datos remotas _.............. _.. Transparencia de los datos remotos _ Extractos de tablas . Rplica de tablas ................. Rplicas actualizables . Compromisos de las rplicas . Arquitecturas normales de rplica. . . ............... Acceso a bases de datos distribuidas ......................... Solicitudes remotas. . . . . . . . . . . . .................. Transacciones remotas _. _......... Transacciones distribuidas . . . .. . . . . . Solicitudes distribuidas. . . . . . . El protocolo de compromiso de dos fases * Aplicaciones de redes y arquitectura de bases de datos Aplicaciones cliente/servidor y arquitectura de bases de datos Aplicaciones cliente/servidor con procedimientos almacenados . Aplicaciones empresariales y cach de datos .. Gestin de grandes volmenes de datos en Internet Resumen . . . . . .. .. .......... . .
795 795 801 802 806 808 810 813 814 816 819 821
822
Mtodos y procedi mientas almacenados Soporte de objetos en el estndar SQL: 1999 Resumen. ... .. ... ... . ...................
875 876
25.
SQL)' XML
XML Fundamentos de XML XML para dalos . XML y SQL _ __ _ . _.................. _ Elementos y atributos . Uso de XML con bases de datos Salidas de XML Entradas de XML . intercambio de datos en XML . Almacenamiento e integracin con XML .............. XML y metadatos _ . . . . . ....... _.. Definiciones de tipos de documentos (DTD) . XML Schema .. XML y consultas .......... Conceptos de XQuery . . . .................... Procesamiento de consultas en XQuer)' ....... Bases de datos XML __ . Resunen . . . . . . . . . . . _.............
879 879
881
824 825 827 831 831 832 834 836 838 839 839 840 842 842 844 845 846 847 850 852 855 856 858 861 863 867 868 869 871
24.
SQL y los objetos ......................................

Bases de datos orientadas a objetos . Caractersticas de las bases de datos orientadas a objetos Pros y contras de las bases de datos orientadas a objetos. Los objetos y el mercado de bases de datos . Bases de datos relacionales orientadas a objetos _. Soporte de grandes objetos . ......... BLOB en el modelo relacional ........................... Procesamiento especializado de BLOB . Tipos de datos abstractos (estructurados) ................. Definicin de tipos abstractos de datos . Manipulacin de tipos abstractos de datos Herencia . Herencia de tablas: implementacin de clases de objetos _. Conjuntos, arrays y colecciones . . _ _ _. Definicin de colecciones Consultas sobre datos de tipo coleccin . Manipulacin de datos de tipo coleccin . Colecciones y procedimientos almacenados . Tipos de dalos definidos por el usuario . ....... _.
884 885 886 889 890 892 894 894 899 901 903 910 911 914 916 917
26.
El futuro de SQL .........................................

Tendencias del mercado de bases de datos . Madurez del mercado de las bases de datos empresariales . . Diversidad y segmentacin del mercado Aplicaciones empresariales empaquetadas . Ganancias de rendimiento del hardware . . . . Hardware para servidores de bases de datos ................ Las guerras de las pruebas . Estandarizacin de SQL . SQL en la prxima dcada . ............ Bases de datos distribuidas . Almacenes de datos masivos Bases de datos de rendimiento ulLra-aho Integracin de los servicios de Internet y de red Bases de dalos incorporadas integracin de objetos _ Resumen .. _. . .
919 920
920
922 922
923
925 926 928 931 931 932 933 934 935 935 937
Contenido
xxi
PARTE VII Apndices Apndice A.

Apndice B.
La
bas~
de datos de ejemplo
941 947 948 948 949 949 951 951 952 952 953 954 955 956 957 958 958 960 960 961 961 962 962 963 965 965
967
Perfiles de los fabricantes de bases de datos
A2i, loe. (www.a2i.com) Arbor Software (www.hyperion.com) Birdstep Technology (www.birdstep.com) Computer Assocates (www.cai.com) Compuler Corporation of America (www.cca-inLcom) Empress Software (www.crnprcss.com)
eXceJon (www.cxln.com) .
Rutinas para la gesti6n del enlorno SQL Rutinas pan la gestin de las conexiones SQL Rutinas para la gestin de las instrucciones SQL Rutinas para la ejecucin de instrucciones SQL Rutinas para el procesamiento de los resultados de las consultas Rutinas para la descripcin de los resultados de las consultas Rutinas para la gestin de descriptores de los resultadm. de las consultas H.utinas para el procesamiento diferido de parmetros dinmicos Rutinas para errores. estado y diagnstico Rutinas de informacin de la implementacin CL! Cdigos de los valores de los parmetros eL! Apndice E. La La La La La La La La La La La La La La La La La La La La La La La vista vjsta vista vista vista vista vista vista vista vista vista vista vista vjsta vista VIsta vista vista vista vista vista vista vista
978 978 979 980 981 982 983 985 985 986 987 993 994 995 995 997 997 998 999 999 1000 1001 1001 1002 1002 1003 1004 1004
Gupla Technologies (www.guptaworldwide.com) Hewlett Packard (www.hp.com)
. .
El estndar del esquema de la informacin de SQL ....

SCHEMATA TABLES CQLUMNS VI EWS . VIEW_TABLE_USAGE VIEW_COLUMN_USAGE TABLE_CONSTRJI.INTS REFERENTIAL_CONSTRAINTS CHECK_CONSTRJ>.INTS KEY_COLUMN_USAGE ASSERTIONS CONSTRAINT_TABLE_USAGE CONSTRP.INT_COLUMN_USAGE TABLE_PRIVILEGES COLUMN_PRIVILEGES USAGE_PRIVILEGES DOMAINS . DOMAIN_CONSTRAINTS DOMJl..IN_cLUMN_USAGE CHARACTER_SETS COLLATIONS TRANSLJI.TIQNS SQL_LANGUAGES
IBM Corporation (www.ibm.com) lnformix Software (vase IBM Corporation)

Microsoft Corporation (www.microsofLCOm)
....
. .
. .
............
MySQL AB (www.mysql.com)
Objectivity (www.objectivity.com) Onide Corporation (www.oracIe.com) Persistence Software (www.persistence.com) Pervasive Software (wwV:'.pervasive.com) PointBase (www.pointbase.com) ... PostgreSQL (www.pos'tgresql.org) Quadbase Systems (v$ww.quadbase.com). . Red Brick Systems (vase IBM Corporation) Sybase, Inc. (www.sybase.com) TimesTen Performance Software (www.ti.mesten.com) Yersant Corporation (www.versant.com)
. . . . .
Apndice C.
Referencia de la sintaxis de SQL ................

. .
lOas
1006 1007 1008 1009 1009
Instrucciones de definicin de datos Instrucciones bsicas de manipu"laci6n de datos Instrucciones de procesamiento de transacciones Instrucciones de cursores Expresiones de consultas .... Condiciones de bsqueda Expresiones Elementos de las instrucciones Elementos simples ..
968 969 970 970 970

972 972
laja
973 973 97S

977 977
Apndice F.
Gua de instalacin del eD-ROM
1013 1014 1014 1015 1015 1016
Apndice D.
La interfaz del nivel de llamadas de SQL
lnstalacin del software SGBD SQL Microsoft SQL Server 2000 .

Requisitos de hardware y de software Notas sobre la instalacin Inslalacin de SQL Server 2000
Valores devueltos por eL! . Rutinas generales de gestin de controladores.
xxii
Contenido
. 1017 . 1017 1018 . . . 1018 1018 Notas sobre la instalacin . Instalacin de DB2 Enterprise Edition . 1019 Inicio de DB2 Enterprise Edition . . 1020 1020 Desinstalacin de DB2 Enterprise Edition 1020 MySQL . Requisitos de hardware y de software _ . 1021 Notas sobre la instalacin . 1021 Instalacin de MySQL . 1021 Inicio de MySQL .. 1022 Desinstalacin de MySQL . 1022 Descarga del software del SGBD Oraele .................... 1022 Inicio de SQL Server 2000 Desinstalacin de SQL Server 2000 IBM DB2 Requisitos de hardware y de software ndice... 1025
Agradecimientos
Gracias especiales a Matan Arazi por hacer de nuevo un trabajo excepcional de ensamblaje del CD de este libro, llevando a cabo otro milagro al comprimir tres productos SGBD en un nico CD, y por hacerlo en plazos imposibles. Gracias tambin al equipo de McGraw-Hill/Osborne, incluyendo a Jane
Brownlow. Jennifer Malnick. Martin Przybyla. Greg Gnntle y Chrisa Hotchkiss.
xxiii
Introduccin
Esta edicin I de SQL. Manual de referencia proporciona un tratamiento extenso y profundo del lenguaje SQL para usuarios, tanto tcnicos como no, programadores, profesionales de procesamiento de datos y directivos que deseen comprender el impacto de SQL en la industria informtica actual. Este libro ofrece un marco conceptual para comprender y usar SQL, describe la historia de SQL y los estndares SQL, y explica el papel de SQL en varios segmentos de la industria informtica, desde el procesamiento de datos de la empresa y los almacenes de datos (data warehouses) hasta las arquitecturas de los sitios web. Esta edicin contiene captulos enfocados especialmente en el papel de SQL en las arquitecturas de los servidores de aplicaciones, y la -integracin de SQL con XML y otras tecnologas basadas en objetos. Este libro mostrar paso a paso el uso de las caractersticas de SQL, con muchas ilustraciones y ejemplos reales para aclarar los conceptos de SQL. El libro tambin compara productos SQL de importantes fabricantes de SGBD (sistemas gestores de bases de datos) -describiendo sus ~ventajas y compromisos- para ayudarle a seleccionar el producto adecuado para su aplicacin. El CD-ROM adjunto contiene versiones de prueba-reales de tres importantes fabricantes de SOBD, adems de instrucciones para la descarga de las versiones de prueba de versiones posteriores, de forma que uno pueda probarlas por s mismo y adquirir,experiencia real en el uso de los principales productos SGBD de Gracle, Microsoft e lBM, as como el popular SGBD de cdigo abierto MySQL. En algunos de los captulos, el tema tratado se explora en dos mbitos diferentes -una descripcin fundamental del tema y una discusin avanzada orientada a profesionales informticos que necesitan comprender los aspectos internos de SQL. La informacin avanzada se trata en secciones marcadas con un asterisco (*). No es necesario leer estas secciones para comprender lo que es y hace SQL.
Organizacin del libro

El libro est dividido en seis partes que tratan varios aspectos del lenguaje SQL: La Parte Uno, Visin general de SQL, proporciona una introduccin a SQL y una perspectiva de mercado de su papel como lenguaje de bases de datos. Sus cuatro captulos describen la historia de SQL, la evolucin de los estndares SQL y cmo se corresponde SQL con el modelo de datos relacional y
Nota del editor: segunda del ingls. primera en castellano.
xxv
xxvi
,
Introduccin
Introduccin
xxvii
con tecnologas anteriores de bases de dalos. La Parte Uno tambin contiene un breve recorrido de SQL que ilustra concisamente sus caractersticas ms importantes y proporciona una visin general de todo el lenguaje. La Parte Dos. Recuperacin de datos, describe las caractersticas de SQL que permiten realizar consultas a la base de datos. El primer captulo de esta parte describe la estructura bsica del lenguaje SQL. Los siguientes cuatro captulos comienzan con las consultas SQL ms simples y progresivamente se construyen cansullas ms complejas, incluyendo consultas sobre varias tablas, consultas de resumen y consultas que usan subconsultas. La Parte Tres, Actualizacin de datos, muestra cmo se puede usar SQL para aadir nuevos datos a la base de datos, borrar los datos de la base de datos y modificar datos existentes en ella. Tambin describe los aspectos de la integridad de las bases de datos que surgen al actualizar los datos, y cmo SQL trata estos aspectos. El ltimo de los tres captulos de esta parte estudia el concepto de transaccin en SQL y su soporte para el procesamiento de transacciones multiusuario. La Parte Cuatro, Estructura de la base de datos, estudia la creacin y administracin de una base de datos basada en SQL. SUS cuatro captulos muestran cmo crear tablas, vistas e ndices que forman la estructura de una base de datos relacional. Tambin describe el esquema de seguridad de SQL, que impide los accesos no autorizados a los datos, y el catlogo del sistema de SQL, que describe la estructura de la base de datos. Esta parte tambin estudia las diferencias significativas entre las estructuras de bases de datos soportadas por varios productos SGBD basados en SQL. La Parte Cinco, Programacin con SQL, describe cmo los programas de aplicacin usan SQL para el acceso a bases de datos. Estudia SQL incorporado, especificado por el estndar ANSI y usado por mM, Oracle, Ingres, Informix y muchos otros productos SGBD basados en SQL. Tambin describe la interfaz de SQL dinmico que se usa para construir tablas de bases de datos de propsito general, tales como los generadores de informes y programas de exploracin de bases de datos. Finalmente, esta parte describe las API (Application Programming Interface, interfaz de programacin de aplicaciones) de SQL, incluyendo ODBC, el estndar ISO CL! (Cal/-Level Interface, interfaz en el nivel de llamada) y IDBC, el estndar de la interfaz en el nivel de llamada para Java, as como interfaces en el nivel de llamada tales como el API OCI de Oracle. La Parte Seis, SQL hoy y maana,. examina el uso de SQL en varias de las reas de aplicacin actuales y destacadas, y el estado vigente de los productos SGBD basados en SQL. Dos captulos describen l uso de los procedimientos almacenados y los disparadores para el procesamiento interactivo de transacciones, y el uso comprobado de SQL para los almacenes de datos. Cuatro captulos adicionales describen las bases de datos distribuidas basadas en SQL, la influencia de las tecnologas de objetos sobre SQL y la integracin de SQL con las tecnologas XML. Finalmente, el ltimo captulo explora el futuro de SQL y algunas de las tendencias ms importantes en la gestin de datos basada en SQL.
Convenciones usadas en este libro

Esta edicin de SQL Manual de referencia describe las caractersticas de SQL y las funciones disponibles en los productos SGBD ms conocidos, as como las descritas en los estndares de SQL ANSIfISO. Siempre que ha sido posible, la sintaxis descrita en este libro y usada en los ejemplos se aplica a todos los dialectos de SQL. Cuando difieren los dialectos, se destacan las diferencias en el texto, y los ejemplos siguen las prcticas ms comunes. En estos casos es posible que haya que modificar ligeramente las instrucciones SQL de los ejemplos para acomodarse a la marca particular de SOBD. A lo largo del libro, los trminos tcnicos aparecen en cursiva la primera vez que se usan y definen. Los elementos del lenguaje SQL, incluyendo las palabras clave, nombres de tablas y de columnas e instrucciones de ejemplo, aparecen en MAYSCULAS y CON FUENTE NO PROPORCIONAL. Los nombres de las funciones de la API de SQL aparecen en minsculas y con fuente no proporcional. Los listados de programa aparecen con fuente no proporcional y usan la convencin habitual de caja para el lenguaje de programacin de que se trate (maysculas para COBOL y FORTRAN, minsculas para C y Java). Ntese que estas convenciones se usan s610 para mejorar la legibilidad; la mayora de las implementaciones de SQL aceptarn instrucciones tanto en maysculas como en minsculas. Muchos de los ejemplos de SQL incluyen resultados de consultas, que aparecen inmediatamente despus de la instruccin SQL como si se tratase de una sesin interactiva. En algunos casos, los resultados de consultas largas se truncan despus de unas cuantas filas; esto se indica con elipsis (...) a continuacin de la ltima fila de los resultados de las consultas.
Por qu este libro es para usted

Esta edicin de SQL. Manual de referencia es el libro adecuado para cualquiera que desee comprender y aprender SQL, incluyendo a los usuarios de bases de datos, los profesionales de procesamiento de datos y arquitectos de sistemas, programadores, estudiantes y directivos. Describe -con un lenguaje sencillo y comprensible, ilustrado con figuras y ejemplos- lo que es SQL, por qu es importante y cmo se usa. Este libro no es especfico de ninguna marca o dialecto de SQL. En cambio, describe el estndar, el ncleo del lenguaje SQL y pasa a describir las diferencias entre los productos SQL ms populares, incluyendo Oracle, Microsoft SQL Server, la base de datos universal DB2 e Inforrnix de IBM, Sybase y MySQL. Tambin explica la importancia de los estndares basados en SQL, tales como ODBe y IDBC, y los estndares ANSI/ISO para SQL y las tecnologas relacionadas con SQL. Esta edicin contiene nuevos captulos y secciones que estudian las ltimas innovaciones de SQL en las reas de las tecnologas relacionales orientadas a objetos, XML y las arquitecturas de servidores de aplicaciones. Si se afronta por primera vez SQL, este libro ofrece un tratamiento extenso y paso a paso del lenguaje, progresando desde consultas simples hasta conceptos ms avanzados. Su estructura permitir empezar rpidamente a usar SQL, pero el
xxviii
Introduccin
libro continuar adquiriendo valor al usar las caractersticas ms complejas del lenguaje. Se puede usar el software SQL del CO-RM adjunto para probar los ejemplos y adquirir prctica con SQL. Si se es un profesional de procesamiento de datos, arquitecto de sistemas o directivo, este libro proporcionar una perspectiva del impacto que SQL est teniendo en la industria de las tecnologas de informaci6n --desde los ordenadores personales, los almacenes de datos y sitios web hasta aplicaciones distribuidas basadas en Internet-. Los primeros captulos describen la historia de SQL, su papel en el mercado y su evoluci6n desde las primeras tecnologas de bases de datos. Los ltimos captulos describen el futuro de SQL y el desarrollo de nuevas tecnologas de bases de datos, tales como bases de datos distribuidas, extensiones de SQL orientadas a objetos, bases de datos de informaci6n comercial e integracin de las bases de datos con XML. Si se es un programador, este libro ofrece un tratamiento muy completo de la programacin con SQL. A diferencia de los manuales de referencia de muchos productos SGBD, ofrece un marco conceptual p<\ra la programacin SQL, explicando tanto el por qu como el cmo del desarrollo de aplicaciones basadas en SQL. Compara las interfaces de programacin SQL ofrecidas por todos los pro~ ductos principales SQL, incluyendo SQL incorporado, SQL dinmico, ODBC, JDBC y API propietarias tales como Oracle Call Interface. La descripcin y comparacin de las tcnicas de programacin proporciona una perspectiva que no se encuentra en ningn otro libro. Si se est eligiendo un producto SGBD, este libro ofrece una comparacin de las caractersticas de SQL y los beneficios ofrecidos por varios fabricantes de SOBO. Se explican las diferencias entre los productos SOBD ms importantes, no slo en trminos tcnicos, sino tambin en trminos de su impacto en las aplicaciones y su posicin competitiva en el mercado. El software SGBD del CD-ROM adjunto se puede usar para probar estas caractersticas en un prototipo de su propia aplicacin. En resumen, tanto los usuarios tcnicos como no tcnicos se pueden beneficiar de este libro. Es la fuente de informacin ms extensa disponible sobre el lenguaje SQL, las caractersticas y beneficios de SQL, productos populares basados en SQL, la historia de SQL y el impacto de SQL en la direccin futura-de la industria de las tecnologas de la informacin.
Parte 1
VISiN GENERAL DE Sal
Los primeros cuatro captulos de este libro proporcionan una perspectiva y una introduccin rpida a SQL. El Captulo l describe lo que es SQL y explica sus principales caractersticas y beneficios. En el Captulo 2, un recorrido rpido de SQL muestra muchas de sus capacidades con ejemplos simples y rpidos de programar. El Captulo 3 ofrece una perspectiva de mercado de SQL a travs de su historia, describiendo los estndares SQL y los fabri cantes principales de los productos basados en SQL, e identificando las razones de la importancia actual de SQL. El Captulo 4 describe el modelo de datos relacional en el que se basa SQL y lo compara con modelos de datos anteriores.
CAPTULO
Introduccin
.~
El lenguaje SQL y los sistemas de bases de datos relacionales basados en l son una de las tecnologas bsicas ms importantes de la industria informtica. Durante ms de dos dcadas SQL ha pasado de su primer uso comercial a ser un segmento del mercado de productos y servicios informticos valorado en decenas de miles de millones de euros al ao, y SQL es hoy en da el lenguaje estndar para las bases de datos informticas. Literalmente centenares de productos de bases de datos, que se ejecutan en sistemas infonnticos que van desde los grandes sistemas (mainframes) a las computadoras personales. e incluso a los dispositivos de mano, admiten actualmente SQL. Se ha adoptado un estndar oficial internacional para SQL y se ha ampliado dos veces. Prcticamente todos los principales productos de software para empresas confan en SQL para la gestin de los datos, y SQL se halla en el neleo de los productos de bases de datos de Microsoft, Oraele e IBM, las tres mayores empresas de software del mundo. SQL tambin se halla en el corazn de los productos de bases de datos de cdigo abierto que estn ayudando a incrementar la popularidad de Linux y del movimiento de cdigo abierto. Desde sus oscuros comienzos como proyecto de investigacin de IBM. SQL ha saltado a una posicin destacada como importante. tecnologa infonntica y como poderosa fuerza de mercado. Qu es, exactamente, SQL? Por qu es importante? Qu puede hacer y cmo funciona? Si SQL es verdaderamente un estndar, por qu hay tantas versiones y dialectos diferentes? Cmo son los productos ms populares de SQL, como SQL Server, Gracle. Infonnix, Sybase y DB2, comparados entre s? Qu relacin tiene SQL con los estndares de Microsoft, como ODBC y COM? Cmo conecta IDBC a SQL con el mundo de Java y con la tecnologa de objetos? Qu papel desempea en la arquitectura emergente de los servicios web, y las arquitecturas competidoras de servicios web de los campos basados en Microsoft y en Java? De verdad SQL se adapta tanto a los grandes sistemas como a los dispositivos de mano? De verdad ha ofrecido el rendimiento necesario para el procesamiento de grandes volmenes de transacciones? Cmo afectar SQL al modo en que se emplean las computadoras, y cmo puede obtenerse el mximo de esta importante herramienta de gestin de datos?
li,
4 SOL. Manual de referencia
.~.
Captulo 1: Introduccin
El lenguaje SOL
SQL es-una herramienta para la organizacin, gestin y recuperacin de los da~ tos almacenados en bases de datos informticas. El acrnimo SQL es la abrevia~ tura de Srructured Query Language (lenguaje estructurado de consultas). Por motivos histricos, SQL se suele pronunciar sicuel (en ingls), pero tambin se utiliza la pronunciacin alternativa S.Q.L.. Como el nombre indica, SQL es un lenguaje que se utiliza para interactuar con bases de datos. De hecho, SQL trabaja con un tipo especfico de bases de datos, denominado bases de datos relacionales. La Figura 1.1 muestra el modo en que trabaja SQL. El sistema informtico de la figura tiene una base de datos que almacena informacin importante. Si el sistema informtico se halla en una empresa, puede que la base de datos almacene datos de inventario, de produccin, de ventas o de nminas. En una computadora personal puede que la base de datos almacenara datos sobre los cheques emitidos, listas de personas y de sus nmeros de telfono o datos extrados de un sistema informtico mayor. El'programa informtico que controla 'la base de datos se denomina sistema gestor de bases de datos (database management system), O SGBD. Cuando se necesita recuperar datos de una base de datos, se utiliza el lenguaje SQL para formular la solicitud. El SGBD procesa la solicitud de SQL, recupera los datos solicitados y los devuelve al usuario. Este proceso de solicitud de datos de las bases de datos y de recepcin de los resultados se denomina consulta de la base de datos ----'de ah el nombre de lenguaje estructurado de consultas. El nombre de lenguaje estructurado de consultas induce realmente a confusin. En primer lugar, SQL es mucho ms que una herramienta para consultas, aunque se fuera su propsito original y la recuperacin de datos siga siendo una de sus
JI
funciones ms importantes. SQL se utiliza para controlar LOdas las funciones que el SOBD ofrece a los usuarios, entre las que se hallan: Definicin de los datos. SQL permite que el usuario defina la estructura y la organizacin de los datos almacenados y las relaciones entre los elementos de datos almacenados. Recuperacin de los datos. SQL permite que el usuario o un programa de aplicacin recupere de la base de datos los dalas almacenados y los emplee. Manipulacin de los datos. SQL permite que el usuario o un programa de aplicacin actualice la base de dalas aadiendo daLas nuevos, eliminando datos antiguos y modificando los datos almacenados previamente. Control de acceso. SQL puede utilizarse para restringir la capacidad del usuario para recuperar, aadir y m9dificar datos, protegiendo as los datos almacenados contra los accesos no autorizados. Compartimiento de los datos. SQL se utiliza para coordinar el compartimiento de datos entre usuarios concurrentes, asegurando as que no interfieran entre s. Integridad de los datos. SQL define restricciones de integridad en la base de datos, protegindola as del deterioro debido a las actualizaciones inconsistentes o a los fallos del sistema. SQL es, por tanto, un lenguaje completo para el control y la interaccin COIl sistemas de gestin de bases de datos. En segundo lugar, SQL no es, en realidad, un lenguaje informtico completo como COBOL, C, C++ o Java. SQL no contiene ninguna sentencia IF para la comprobacin de condiciones, ni instrucciones GOTO; DO, ni FOR para el control del flujo de los programas. En cambio, SQL es un sublenguaje de bases de datos, que consta de unas cuarenta instrucciones especializadas para las tareas de gestin de las bases de datos. Estas instrucciones de SQL se pueden incorporar en otro lenguaje, corno COBOL o e, con el fin de ampliar ese lenguaje para su empleo en el acceso a bases de datos. De manera alternativa, pueden enviarse de forma explcita a un sistema gestor de bases de datos para su procesamiento mediante una intelfaz en el nivel de llamadas desde un lenguaje como e, C++ o Java, o mediante mensajes enviados mediante una red informtica. Finalmente, SQL no es un lenguaje especialmente estructurado, sobre todo si se compara con lenguajes muy estructurados, como C, Pascal o Java. En cambio, las instrucciones de SQL se parecen a las frases escritas en ingls, completadas con palabras ruido}) que no aaden nada al significado de la frase pero que hacen su lectura ms naturaL Hay unas cuantas inconsistencias en el lenguaje SQL, y tambin hay algunas reglas especiales para evitar la construccin de instrucciones SQL que parezcan perfectamente legales pero que carezcan de sentido. Pese a la inexactitud de su nombre, SQL se ha situado como el lenguaje estndar para el empleo de las bases de datos relacionales. SQL es a la vez un lenguaje potente y un lenguaje que resulta relativamente sencillo de aprender. El recorrido rpido por SQL del Captulo 2 ofrecer una buena visin general del lenguaje y de sus posibilidades.
.~
'~i
"
1I :~
f,l
i~ ,
ti in,
"l
:~
f'
:tI
.~
Solicitud SOL
~
),
m
ded Datos
;
~
~i
}~nOOll.
110101 101110
Sistema informtico
Figura 1.1.
Uso de SOL para el acceso a bases de datos.
l ~
" 1
l
i.
SOL Manual de referencia
El papel de SaL
SQL no es, por s mismo, un sistema gestor de bases de datos, ni un producto independiente. No se puede ir a una tienda de informtica y comprar SQL, En cambio, SQL es un componente integral de los sistemas de gestin de bases de datos, un lenguaje y una herramienta para comunicarse con los SOBD. La Figura 1.2 muestra algunos de los componentes de un SGBD lpico, y el modo en que SQL acta como el pegamento que los mantiene unidos. El motor de bases de dalos es el corazn del SGBD. responsable de estructurar realmente, almacenar y recuperar los dalOs de la base de datos. Acepta las solicitudes de SQL de otros componentes del SOBD -como el recurso de formularios, el escrilor de informes o el recurso de consullas interactivas-, de los programas de aplicacin escritos por los usuarios e, incluso, de otros sistemas informticos. Como muestra la figura, SQL desempea muchos papeles diferentes:
SQL es un lenguaje interactivo de consultas. Los usuarios escriben comandos de SQL en programas interactivos de SQL para recuperar los datos y
010011 110101 101110
Herramientas de programacin
fI
mostrarlos en la pantalla. lo que proporciona una herramienta prctica y fcil de utilizar para las consultas ad hoc a las bases de datos. ~QL es un lenguaje de programacin de bases de datos. Los programadores Incorporan comandos de SQL en los programas de aplicacin para tener acceso ~ los datos de las bases de datos. Tanto los programas escritos por los usuaflos como los programas de utilidades de las bases de datos (como los escritores de informes y las herramientas deintroducci6n de datos) utilizan esta tcnica para el acceso a las bases de datos. SQL es un lenguaje de administracin de bases de datos. El responsable de la administracin de una base de datos en una minicomputadora o en un gran sistema utiliza SQL para definir la estructura de la base de datos y controlar el acceso a los datos almacenados. SQL es un lenguaje cliente/servidor. Los programas de las computadoras personales utilizan SQL para comunicarse mediante una red con los servidores de bases de datos que almacenan los datos companidos. Esta arquitectura cliente/servidor se ha vuelLo muy popular para las aplicaciones de tipo empresarial. SQL es un lenguaje de acceso a datos por Internet. Los servidores web de Internet que interactan con los datos empresariales y los servidores de aplicaciones de Internet utilizan SQL como lenguaje estndar para el acceso a las bases de datos empresariales. SQL es un lenguaje de bases de datos distribuidas. Los sistemas de gestin de bases de datos distribuidas utilizan SQL para ayudar a distribuir los datos por muchos sistemas informticos interconectados. El software SGBD de cada sistema utiliza SQL para comunicarse con los dems sistemas, enviando solicitudes de acceso a los datos. SQL es un lenguaje de pasarelas de bases de datos. En las redes informticas con mezcla de diferentes productos de SGBD, SQL suele utilizarse como pasarela que permita a unas marcas de SGBD comunicarse con las otras.
'f~~
Motor de la base
~d.datOrs
SQL, por tanto, se ha manifestado como una herramienta til y potente para enlazar personas, programas y sistemas infonnticos con los datos almacenados en las bases de datos relacionales. .
sistemas informticos
:LY I
Caractersticas y ventajas de SaL

SQL es a la vez un lenguaje sencillo de comprender y una herramienta completa para la administracin de los datos. A continuacin se indican algunas de las caracterst.icas principales de SQL y las fuerzas del mercado que les han permitido tener xito: Independencia del fabricante. Transportabilidad entre sistemas informticos. Estndares SQL. Acuerdos y obligaciones de IBM (DB2).
Base de datos
A otras marcas
de SGBD
i
I
Figura 1.2.
Componentes de un sistema gestor de bases de datos tpico.
1
I
SOL. Manual de referencia
Obligaciones de Microsoft (SQL Server, ODBC y ADO). Fundamentos relacionales. Estructura de alto nivel en ingls. Consultas ad hoc interactivas. Acceso mediante programacin a bases de da(Qs. Vistas mltiples de los dalos. Lenguaje completo de base de datos. Definicin dinmica de datos. Arquitectura cliente/servidor. Soporte de aplicaciones empresariales. Extensibilidad y tecnologa de objetos. Acceso a bases de dalOS en Internet. Integracin de Java (lOBe). Infraestructura de la industria.
nmicas pueden utilizarse como prototipos para aplicaciones de bases de datos basadas en SQL antes de pasarlas a sistemas multiusuario de elevado coste.
Estndares SOL
El organismo estadounidense de normalizacin (American National Standards Insti tute, ANSI) y la Organizacin Internacional de Normalizacin (Inlernational Standards Organization, ISO) publicaron un primer estndar para SQL en 1986, que se ampli en 1989, y nuevamenle en 1992 y en 1999. SQL tambin es un estndar federal para procesamiento de informacin de EE UU (U. S. Federal Information Processing Standard, FIPS), lo que lo transforma en un requisito fundamental para los grandes contratos informticos del gobierno estadounidense. A lo largo de los aos otros grupos internacionales, gubernamentales estadounidenses y de fabricantes han liderado la normalizacin de nuevas capacidades de SQL, como las interfaces en el nivel de llamada o las extensiones basadas en los objetos. Muchas de estas nuevas iniciativas se han incorporado con el tiempo al estndar ANSl/ ISO. LbS estndar en evolucin sirven de sello oficial de aprobacin de SQL y han acelerado su aceptacin en los mercados.
stas son las razones por las que SQL se ha situado como la herramienta estndar para la administracin de datos en las computadoras personales, las minicomputadoras y los grandes sistemas. Todas se describen en los apartados siguientes.
Independencia del fabricante

Todos los fabricantes principales de SGBD ofrecen SQL, y ningn producto nuevo de bases de datos ha tenido un xito importante en la ltima dcada sin soporte de SQL. Las bases de datos basadas en SQL y los programas que la utilizan pueden pasarse de un SGBD al SGBD de otro fabricante con un mnimo esfuerzo de conversin y una pequea readaptacin del personal. Las herramientas de bases de datos, como las herramientas de consulta, los escritores de informes y los generadores de aplicaciones, funcionan con muchas marcas diferentes de bases de datos de SQL. La independencia del fabricante que SQL ofrece de esta manera fue uno de los molivos ms importantes de su temprana popularidad y sigue siendo hoy en da una caracterstica importante.
Acuerdos y obligaciones de IBM (DB2)

SQL fue inventado originalmente por investigadores de lB M, y desde entonces se ha transformado en un producto estratgico para IBM basado en su base de datos insignia DB2. El soporte de SQL est disponible en todas las principales familias de productos de IBM. desde las computadoras personales a 'los sistemas intennedios (AS/400 y servidores basados en UNIX) y los grandes sistemas de IBM. El trabajo inicial de IBM proporcion una seal clara de la direccin lOmada por IBM para que la siguieran los dems fabricantes de bases de datos y de sistemas en los albores del desarrollo de SQL.y de las bases de datos relacional.es. Ms adelante, el compromiso y el amplio sopone de IBM aceleraron la aceptacin por los mercados de SQL. La influencia de IBM en SQL hoy en da llega mucho ms. all de su propio negocio de sistemas informticos. Los productos basados en SQL que ha desarrollado O adquirido IBM se ejecutan hoy en da en una amplia gama de hardware, en muchos casos de fabricantes informticos de la competencia como Sun O Hewlett-Packard.
Transportabilidad entre sistemas informticos

~,
' - .
Los productos de bases de datos basados en SQL se pueden ejecutar en sistemas informticos que van desde los grandes sistemas y los sistemas medianos a las computadoras personales, las estaciones de trabajo, una amplia gama de computadoras servidoras especializadas e, incluso, dispositivos de mano. Operan en sistemas informticos independientes, en redes de rea local departamentales y en redes empresariales, o en Internet. Las aplicaciones basadas en SQL que comienzan en sistemas de un solo usuario o de servidores depanamentales pueden pasarse a sistemas servidores de mayor tamao a medida que crecen. Los datos de las bases de datos empresariales basadas en SQL pueden extraerse y descargarse a bases de datos departamentales o personales. Finalmente, las computadoras personales eco-
Obligaciones de Microsoft (SOL Server, ODBC y ADO)

Microsoft ha considerado desde hace tiempo el acceso a las bases de datos una parte fundamental de su arquitectura de software para computadoras personales Windows. Tanto las .versiones de sobremesa como las de servidor de Windows proporcionan un acceso estandarizado a las bases de datos relacionales mediante la conectividad abierta de bases de datos (Open Database COllneclivity, ODBC),
10
11
una API en el nivel de llamadas basarla en SQL. Las principales aplicaciones de software de Windows (hojas de clculo, procesadores de texto, bases de datos, etc.) de Microsoft y de otros fabricantes admiten ODBC. y todas las principales bases de datos de SQL ofrecen acceso DBC. Microsoft ha mejorado el soporte de OOBC con capas de acceso de nivel superior, ms orientadas a objetos, como parte de su tecnologa Enlace e incrustacin de objetos (Object Linking and Embedding, OLE DB) y, ms recientemente, como parte de ActiveIX (Objetos de datos AclivelX, AClivelX Daca Objects o ADO). Cuando Microsoft comenz su esfuerzo para hacer de Windows un sistema operativo para servidores viable a finales de los aos ochenta del siglo pasado, introdujo SQL Server como su propia oferta basada en SQL. SQL Server sigue siendo hoy en da un producto insignia de Microsoft y un componente fundamental de su arquitectura .NET para servidores web.
consullas ad hoc de SQL fue una ventaja importante respecto de las bases de datos no relacionales en los primeros tiempos de su evolucin, y ms recientemente ha seguido siendo una ventaja fundamental sobre las bases de datos basadas solamente en objetos.
Acceso mediante programacin a bases de datos

SQL es tambin un lenguaje de bases de datos empleado por los programadores para escribir aplicaciones que tengan acceso a las bases de datos. Se emplean las mismas instrucciones de SQL tanto para el acceso interactivo corno para el acceso mediante programaci6n, por lo que las partes del programa de acceso a las bases de dalas pueden comprobarse previamente con SQL interactivo e incrustarse posteriormente en el programa. A diferencia de esto, las bases de datos tradicionales ofrecan un conjunto de herramientas para el acceso med.iante programacin y un recurso de consulta diferente para las solicitudes ad hoc, sin ninguna sinergia entre los dos modos de acceso.
Fundamentos relacionales
SQL es un lenguaje para bases de datos relacionales y se ha hecho popular junto con el modelo relacional de bases de datos. La estructura tabular, de filas y columnas, de las bases de datos relacionales resulta intuitiva para los usuarios, lo que hace que el lenguaje SQL siga siendo sencillo y fcil de comprender. El modelo relacional tiene tambin un slido fundamento terico que ha guiado la evolucin e implementacin de las bases de datos relacionales. Aprovechando una ola de aceptacin provocada por el xito del modelo relacional, SQL se ha transformado en el lenguaje de bases de datos para las bases de datos relacionales.
Vistas mltiples de los datos

Al emplear SQL el creador de una base de datos, puede ofrecer a diferentes usuarids de la base de datos d;iferentes vistas de su estructura y de su contenido. Por ejemplo, la base de datos puede construirse de modo que cada usuario slo vea los datos de su departamento o regin de ventas. Adems, los datos de diferentes partes de la base de datos pueden combinarse y presentarse al usuario como una mera tabla de filas y columnas. Las vistas de SQL pueden, por tanto, utilizarse para mejorar la seguridad de la base de datos y adaptarla a las necesidades particulares de cada usuario.
Estructura de alto nivel en ingls

Las instrucciones de SQL tienen el aspecto de frases sencillas en ingls, 10 que hace que SQL sea sencillo de aprender y de comprender. Esto se debe en parte a que las instrucciones de SQL describen los datos que hay que recuperar, en lugar de especificar cmo hallar los datos. Las tablas y columnas de las bases de datos de SQL pueden tener nombres descriptivos largos. En consecuencia, la mayor parte de las instrucciones de SQL dicen 10 que quieren decir y pueden leerse como frases claras en lenguaje natural.
Lenguaje completo de base de datos

SQL se desarroll en un principio como un lenguaje para consultas ad hoe, pero su capacidad va hoy en da mucho ms all de la recuperacin de datos. SQL ofrece un lenguaje completo y consistente para la creacin de bases de datos, la administracin de su seguridad, la actualizacin de su contenido, la recuperacin de datos y el compartimiento de datos entre usuarios concurrentes. Los conceptos de SQL que se aprenden en una parte del lenguaje pueden aplicarse a otros comandos de SQL, lo que hace que los usuarios sean ms productivos.
Consultas ad hoc interactivas

SQL es un lenguaje de consultas interactivas que da a los usuarios acceso ad hoc a los datos almacenados. Al emplear SQL de manera interactiva, los usuarios pueden obtener respuestas, incluso a preguntas complejas, en minutos o en segundos, en ntido contraste con los das o semanas que tardara un programador en escribir un programa personalizado para informes. Debido a la capacidad para consultas ad hoc de SQL los datos resultan ms accesibles y pueden utilizarse para ayudar a una organizacin a tomar decisiones mejores y ms informadas. La capacidad para
Definicin dinmica de datos

Mediante SQL se puede modificar y expandir de manera dinmica la estructura de las bases de datos, aunque los usuarios estn teniendo acceso al contenido de la
12
13
base de datos. Esto supone un importante avance respecto de los lenguajes estticos de definicin de datos, que impedan el acceso a las bases de datos mientras se modificaba su estructura. SQL ofrece, por tanto. la mxima flexibilidad, lo que permite que las bases de datos se adapten a los requisitos cambiantes mientras las aplicaciones en lnea siguen funcionando sin interrupcin.
Arquitectura cliente/servidor
SQL es un vehculo natural para la implementacin de aplicaciones mediante una arquitectura distribuida cliente/servidor. En este papel, SQL sirve de enlace entre los sistemas informticos visibles al usuario, optimizados para la interaccin con el usuario, y los sistemas subxacentes especializados en la gestin de las bases de datos, 10 qu.e permite que cada sistema h~ga lo que mejor ~ace. SQL tambin permite que las computadoras persomile1s funcionen como sistemas visibles para los servidores de red o para bases de dtos de minicomputadoras y de grandes sistemas, ofreciendo acceso a los datos empresariales desde las aplicaciones de las computadoras personales.
lentamente SQL para incluir caractersticas orientadas a objetos. Estas bases de datos relacionales orientadas a objetos, que siguen estando basadas en SQL. se han constituido en una alternativa ms popular que las bases de datos slo orientadas objetos y han perpetuado el dominio de SQL durante la ltima dcada._ La ltima ola de la tecnologa orientada a objetos, incrustada en el estndar XML y las arquitecturas de servicios web, ha vuelto a crear un conjunto de bases de datos XML y lenguajes de consulta alternativos para desafiar a SQL. La historia pasada parece sugerir que las extensiones de SQL basadas en XML y el modelo relacional volvern a superar este reto y a asegurar que se mantenga la importancia de SQL.
Acceso a bases de datos en Internet

Con la reciente popularidad de Internet y de WorId Wide Web, y sus fundamentos basados en estndares, SQL hall un nuevo papel a finales de los aos noventa del siglo pasado como estndar de acceSO.3 datos en Internet. En los primeros tiempos del desarrollo del web, los desarrolladores necesitaban una manera de recuperar y presentar en las pginas web la informacin de las bases de datos, y utilizaron SQL como lenguaje comn para las pasarelas de bases de datos. Ms recientemente la aparicin de arquitecturas de Internet de tres capas con capas delgadas diferenciadas de clientes, servidores de aplicaciones y servidores de bases de datos ha asentado 3 SQL como enlace estndar entre las capas de aplicaciones y de bases de datos. En el futuro, el papel de SQL en Internet se ampliar ms all de las arquitecturas de los sitios web para incluir la gestin de datos para las aplicaciones colaboradoras y los objetos distribuidos en una arquitectura de servicios web.
Soporte de aplicaciones empresariales

Todas las aplicaciones empresariales de gran tamao que asumen la operativa diaria de las grandes empresas y organizaciones utilizan bases de datos basadas en SQL para almacenar y organizar los datos. Los datos sobre las transacciones empresariales (pedidos, importes de las ventas, clientes, niveles de inventarios, importes de pagos, etc.) tienden a tener un formato estructurado de registros y de campos, que se convierte con facilidad en el formato de filas y columnas de SQL. Al crear las aplicaciones para utilizar bases de datos de SQL de tipo empresarial, los principales fabricantes de aplicaciones eliminan la necesidad de desarrollar su .propio software de gestin de datos y pueden aprovecharse de las herramientas y de las habilidades de programacin ya existentes. Como cada una de las principales aplicaciones empresariales necesita una base de datos basada en SQL para operar, las ventas de aplicaciones empresariales g-eneran de manera automtica una demanda inducida de nuevas copias de software de bases de datos.
Integracin de Java (JDBC

Un rea importante de desarrollo de SQL en los ltimos cinco o diez aos ha sido la integracin de SQL con Java. Viendo la necesidad de enlazar el lenguaje Java con las bases de datos relacionales existentes, Sun Microsystems (los creadores de Java) present la Conectividad Java de bases de datos (Java Database Connectivity, JDBC), una API estndar que permite que los programas de Java utilicen SQL para el acceso a bases de datos. JDBe recibi un impulso posterior cuando se adopt como acceso estndar a datos en la especificacin de la edicin empresarial Java2 (Java2 Enterprise Edition, J2EE), que define el entorno operativo proporcionado por todos los principales servidores de aplicaciones de Internet. Adems de su papel como lenguaje de programacin desde el que se utilizan bases de datos, muchos de los principales fabricantes de bases de datos tambin han anunciado o implementado el soporte de Java en sus sistemas de bases de datos, 10 que permite que se utilice Java como lenguaje para los procedimientos almacenados y la lgica empresarial dentro de las propias bases de datos. Esta tendencia hacia la integracin entre Java y SQL asegurar que se mantenga la importancia de SQL en la nueva era de la programacin basada en Java.
Extensibilidad y tecnologia de objetos

El principal desafo al prolongado dominio de SQL como estndar de bases de datos ha surgido de la aparicin de la programacin basada en objetos y de la introduccin de bases de datos basadas en objetos como extensin de la amplia tendencia del mercado hacia la tecnologa basada en objetos. Los fabricantes de bases de datos basadas en SQL han respondido a este reto ampliando y mejorando
14
Infraestructura de la industria
Quizs el factor ms importante de los que han contribuido a la creciente importancia de SQL sea la aparicin de toda una infraestructura de la industria informtica basada en SQL. Los sistemas de bases de datos relacionales basados en SQL constituyen una parte importante de esta infraestructura. Las aplicaciones empresariales que utilizan SQL y necesitan bases de datos basadas en SQL son otra parte importante, al igual que las herramientas para informes, las herramientas para introduccin de datos, las herramientas de diseo, las herramientas de programacin y un conjunto de herramientas de otros tipos que simplifican el uso de SQL. Una gran cantidad de programadores de SQL experimentados constituye una parte fundamental de esa infraestructura. Otra parle importante son los servicios de formacin y de soporte que giran alrededor de SQL y que ayudan a conferir y perpetuar la eficacia en SQL. Ha surgido toda una subindustria alrededor de la consultora, optimizacin y ajuste de rendimiento de SQL. Todas las partes de la infraestructura tienden a reforzarse entre s y contribuyen al xito actual de las dems partes. En pocas palabras, para resolver problemas de gestin de datos la solucin ms sencilla, de menor riesgo y de menor coste casi siempre es una solucin basada en SQL.
CAPTULO
Una introduccin a SOL
Antes de sumergirnos en los detalles de SQL, conviene desarrollar una perspectiva global del lenguaje y del modo en que trabaja. Este captulo contiene una introduccin rpida a SQL que ilustra sus principales caractersticas y funciones. El objetivo de esta introduccin rpida no es hacer que el lector sea competente en la escritura de instrucciones SQL; se es el objetivo de la segunda parte del libro. Para cuando el lector haya concluido este captulo, tendr ms bien una familiaridad bsica con el lenguaje SQL y una visin general de sus posibilidades.
Una base de datos simple

Los ejemplos de la introduccin rpida se basan en una base de datos relacional simple para una pequea compaa de distribucin. La base de datos, que se muestra en la Figura 2.1, almacena la informacin necesaria para implementar una pequea aplicacin de procesamiento de pedidos. Especficamente, almacena la informacin siguiente:
d~tos
Los clientes que compran los productos de la compaa. Los pedidos realizados por esos clientes. Los representantes que venden los productos a los clientes. Las oficinas comerciales en que trabajan esos representantes.
Esta base de datos, como la mayora, es un modelo del mundo reah). Los almacenados en la base de datos representan entidades reales -clientes, pedidos, representantes y oficinas-o Hay una tabla independiente de datos para cada tipo de entidad. Las solicitudes a la base de datos que se realizan empleando el lenguaje SQL simulan las actividades del mundo real, cuando los clientes realizan, cancelan y modifican los pedidos, cuando se contrata y se despiden representan tes, etc. A continuacin se ver ]a manera en que se puede utilizar SQL para manipular los datos.
15
16
Captulo 2: Una introduccin a SOL
17
Tabla PEDIDOS
1l\W~PEPUlO
Tabla onCINAS
CLIEIlTE
2117
PZC>IA..-PEDIDO
u,
,~
,~~
C1Wi'IDAD
112961 113012
112989
11/1211989
11/01/1990
106 RE! 105 ACI

106 FEA
2"441.
,
" ,
IIlPORTE
J1.500,OOE
J.745.00
1. 458. DoE
OFICINA CIUDAD 22 o..inie1 11 12 NlIvarra Castelln
REGIOl1 Oeaetl Esee Este Esee Qesee
'"
OBJE'l'IVO 300.000 OOE" 51S.000.00e 800.000.ooe 350.000.00E: 725.000,OOE"
VENTAS 1I16.04200E" 692.637 ooe 735.042 00E: 367.911,00E: 8J5.915.00
2111
nOl
41003
03/0111990
O/OUU90
U.
~"
HOO'
41002
113051 112968
2118
108 OSA
101 ACI
12110/1989 )0/0111990
113016 113045
11296]
113(1)
210. 2101
2112
110 ACI 108 REI
0210211"0
11112119119
U/Olll990
no]
:1118
2108
2l:i!4
as .\el
108 BIc
109 FEA
2"'HR 41004
Hao]
..,
"
l.'20,DOE 3.978.00
13 Almeria
21 Len
'"'
'" '" ",
l2.saO.DoE
(S.DOO.DOE
",
11305. 112991
.l/OUIno
08l0H1990
101 BIC
lOS ACI
loa~
'" HaO)
U004
..,
..
J.n6. aoE
652.DOE
Tabla REPRESENTANTES
J:l)I'.8RE
~""""'1>rt_
1.no.OD 652.00 70l,apE:

1.IOO.OOE
105 10' 102 106 10' 101 \10 108 10l 101
'"
1un3
lU024
nH2I1989
20/0111990
2101
211t
lD062
11297g
2HD2I1990 12/1011989 22/0111"0 08/0111990 0210111990

29/01/1990 04/ll/H89
2124
~"
107 !'EA 102 ACI
,,,
"
Ud. Ji-'-: s.....",. SantOS
SaaJel Cl.~l Bcrn.ordo S;Onctlct

Den!el l<uidrobO
-..
"
OFlCll~
KV lJ
~= Repn ....t .....

R~r..,t.Dte
c:om-R.\':'a
!l/ouau
,u. =,
lSO.OOG.OOE IrJl.L 21S.000.0OE 20ILOOO.OOE 10; 10O.ogO.OOE" 101 :uw. :l50.000.00 215.000.00E JOO.ooo.oee
"
l.(lO.QoE
.S.OOO.DOE
HU
2101 2112
UOOt 41002
?13C
Ill021 lUOO? 113069 113034 112n2 ua?s lIJOSS 113048 1l299J 113065 IlJ003 11J049 112981 llJ051 1l30U
105 hel 1081HM

,~
12110/1'19
1510211990 10/0211990
2109 . 107 210? llO 108 2118 2111 103 2108 m 2120 102 2106 2106 2108 2118 210J 2111 2113 .102
REI
7?SC 2M5C 41002 2AUG 4100X

719C
iln
REI
Ul!!
", " " ,
4.104.00 2.92S,00 Jl.350.00E 612.00E ?60,00E 2.100.00E 150.00 J.1S0.00 1.8U.OOE 2.no,OOE 5.625,OOE 1U.CIOE 21.S00.0OE 600.00 22.500.0OE
"'...h Sa: Le6<l Fnire Pablo Cru:

Neus "':c.l.r~'.
" " "

U
JIlILI.
"
" "
lUlOlan 21 Repu.... tc.Dte 10H21U16 11 VI' V.tlt 1'/0611'111 12 Jef. V""u UIOS/ln7 12 Reor.........,te 20110/1986 Repr. . .., ...... llfOlfl99g 21 Jaf. '1ent... 12/10/1989 n ll~rea.n~."~e Ol/Ol/IUl
11 22 Il.pr. . . nt~n" U/ll/B88
". ". ". '" ".
".
",
v:,r..u
167.'ll.CO
J'2.n~.OO "~.OSO.OO
3S0.000.00
JOO.OO~.OO
2n.'12.0OE IU.5".00 JOS.67J.OO lS.9SS.00 J6l.B65.00 286.115.00E IU.04 . 00
Figura 2.1.
Una base de datos relacional simple. (Continuacin.)
04/0111989
2110211990 25/0111990 10/02119'0 31/1211989 18/0211990 02102/1990
102 REI 109 1101 I08fOSA 105 ACI 103 Ael 101 Rl:I
2USC
'"
me
~"
4100Y 4100X 2AUIl
~"
" , ,
U
Recuperacin de datos
En primer lugar se realizar un listado de las oficinas comerciales, mostrando la ciudad en que se halla cada una y sus ventas en el ao actual. La instruccin de SQL que recupera los datos de la base de datos se denomina SELECT. Esta instruccin de SQL recupera los datos deseados:
SELECT CIUDAD, OFICINA, VENTAS FROM OFICINAS CIUDAD
",
Tabla CLIENTES
OC, EMPIlESA 2111 JCP S.A.

2102 Filas 2103 2t2.3 Cruz e hijos 2101 Ace lntenuleio.... 211S Sierra.. S .....
,~
REP CLI
LIMITE CREOIl'O 50.000,00E: 65.000,eoe 50.000.0040 40.000.00E 35.000.0OE: 20.000.0O 65.000.00E" . 50.000.00E 4S.000.OOE' 20.000.0oE' 40.000.00E: 55.000.00E J5.000.00E" 30.000,00E: SO.OOO.OOE: 6S.000.00e 2S.000.00e 60.000.00 20.000.00E: 25.000.00 4S.000.00
'" '"
'" no '" ". '" '" '" ". '"
10>
'"
2101 Ja:-an<!ll1s Ltd. 2112 Z"ta Ptl'duc:c:ioncs
-----------Daimiel
OFICINA
------22
11
------------
VENTAS
2121 O!".J. Asociadol

2114 orion Ltd. 2124 Pascual Henuno.s 2108 Me=he " l.6pcz 2117 J.P. sotoc:a 2122 'toledo S.A. 2120 Rico S.A. 2106 F. Lpez S.A. 2119 Salomn S ..... 2118 M"jonda Silee....._ 211J t...ro " sagaz 2109 Chen AsocIado. 2105 AJ.A InvenIones
". '"
Navarra Castelln Almera Len
12
13
21
186.042.00 692.637.00 735.042.00 367.911,OO 835.915.00
'"' ", '" '"
'" '"
Figura 2.1.
Una base de datos relacional simple. (Contina.)
La instruccin 5ELECT pide tres fragmentos de los datos -la ciudad, el nmero de la oficina y el importe de las ventas- de cada oficina. Tambin especifica que todos estos datos vengan de la tabla OFICINAS, que almacena los datos de las oficinas comerciales. El resultado de la consulta aparece, en forma tabular, inmediatamente despus de la solicitud. La instruccin SELECT se emplea para todas las consultas de SQL Por ejemplo, a continuacin se ofrece una consulta que muestra un listado de los nombres y las ventas en el ao actual de cada representante que figura en la base de datos. Tambin mu'estra la cuota (objetivo de ventas) y el nmero de la oficina en que
18
SQL. Manual de referencia
19
trabaja cada uno.- En este caso, los datos provienen de la tabla de representantes siguiente, VENTASREPS:
SELECT NOMBRE, REP_OFICINA, VENTAS. CUOTA
Se puede utilizar la misma tcnica para obtener un listado de los grandes pedi~ dos incluidos en la base de datos y averiguar el cliente que realiz cada pedido, el producto que se solicit y la cantidad que se pidi. Tambin se puede pedir a SQL que ordene los pedidos de acuerdo con su importe:
SELECT FROM WHERE ORDER NUM_PEDIDO, CLIENTE, PEDIDOS IMPORTE> 25000,OO BY IMPORTE PRODUCTO, CANTIDAD, IMPORTE
FROM VENTASREPS
NOMBRE
---------------- ------------ -----------13 11 21

11 12 12 NULL 21 12 22
REP_OFICINA
VENTAS
Bruno Arteaga Mara Jimnez Susana Santos Samuel Clavel Bernardo Snchez Daniel Ruidrobo Toms Saz Len Freire Pablo Cruz Neus Azcrate
367.91l,OO 392.725,QO 474.0S0,OO 299.912,00 142.594,OOe: 305.6i3,OO 75.98S,OO 361.865,00 286.775,OO l86.042,OO
-----------350. OOO,OO
300. OOO,OO 350. 000,00e: 275.000,OOe: 200.000,OOe: 300.000,OO NULL 350.000,OOe: 275.000,OO 300.000,OO
CUOTA
NUM_PEDIDO 112987 113069 112961 113045
----------- --------
CLIENTE PRODUCTO
-------4l00Y 775C 2A44L 2A44R
2103 2109 2117 2112
--------- ----------11 22
7
CANTIDAD
IMPORTE
10
27.S00,00 31.350,00e: 31.500,00 4S.000,00e:
SQL tambin permite que se soliciten resultados calculados. Por ejemplo, se puede pedir a SQL que calcule el importe en que cada representante supera su cuota o est por debajo de ella:
SELECT NOMBRE, VENTAS, FROM VENTASREPS NOMBRE CUOTA, (VENTAS - CUOTA)
Resumen de datos
SQL no slo recupera de la base de datos fragmentos individuales de datos, sino que tambin puede utilizarse para resumir el contenido de la base de datos. Se desea averiguar el tamao promedio de los pedidos de la base de datos. Esta solicitud pide a SQL que examine todos los pedidos y averige su importe promedio:
SELECT AVG(IMPORTE) FROM PEDIDOS AVG(IMPORTE) 8.256,37
---------------- ------------ ------------ --------------17.911,00 367.911,00e: 3S0. 000, 00e: Bruno Arteaga
392.725,00 474.0S0,00 2.99.912,OO 142.594,OO 30S.G73,OO 7S.985,OO 361.865,OO 286.775,00 186.042,OOe: 300.000,00e: 350.000,00 275.000,OO 200.000,OOe: 300.000,OO NULL 350.000,00 275.000,OOe: 300.000,OOe: 92.72S,00e: 124.0S0,00 24.912,OO -57 .40G, 00e: 5.673,OO NULL 11.865,00 1l.775,OO -113.958,OO
VENTAS
CUOTA
(VENTAS-CUOTA)
Maria Jimnez Susana Santos Samuel Clavel Bernardo Snchez Daniel Ruidrobo Toms Saz Len Freire Pablo Cruz Neus Azcrat.e
Tambin se podra pedir el tamao promedio de los pedidos de un cliente concreto:

SELECT AVG(IMPORTE) FROM PEDIDOS WHERE CLIENTE = 2103 AVG(IMPORTE) 8.895,50e:
Los datos solicitados (incluida la diferencia entre las ventas y la cuota de cada representante) vuelven a aparecer en una tabla de filas/columnas, Quizs se prefiera centrar la atencin en los representantes cuyas ventas son menores que sus cuotas. SQL permite recuperar esa clase de informacin selectiva muy fcilmente, aadiendo una comparacin matemtica a la solicitud anterior:
SELECT NOMBRE, VENTAS, CUOTA, FROM VENTASREPS WHERE VENTAS < CUOTA NOMBRE Bernardo Snchez Neus Azcrate VENTAS 142.594,OOe: 186.042,00 (VENTAS - CUOTA)
Finalmente, se averiguar el valor total de los pedidos realizados por cada cliente. Para ello se puede pedir a SQL que agrupe los pedidos por nmero de cliente y luego sume Jos pedidos de cada -cliente:
SELECT CLIENTE, SUM(IHPORTEj FROM PEDIDOS GROUP BY CLIENTE
CUOTA (VENTAS-CUOTA) 200.000,OO 300.000,OO -57.406,00 -1l3.958,OO
20

SUM(IMPORTE)
1.458,OO
21
CLIENTE 2101 2102

2103 2106 2107 2108
y si se decide despedir a todos los representantes cuyas ventas sean inferiores a sus cuotas, se pueden eliminar de la base de datos con la instruccin DELETE:
DELETE FROM REPRESENTANTES WHERE VENTAS < CUOTA
3.978,QO 35.582,OO
4.026,OO
23.132,OO
7.255,OO
31.350,OO
2 filas eliminadas.
2109 2111 2112 2113

2114
6.445,QO 47.925,O 22.S00,OO 22.10Q,QO

31.500,OO
Actualizacin de la base de datos

Tambin se puede utilizar SQL para modificar los datos que ya se hallan almacenados en la base de datos. Por ejemplo, para aumentar el lmite de crdito de Filas a 75.000 , habra que utilizar la instruccin de SQL UPDATE:
UPDATE CLIENTES SET LIMITE_CREDITO = 75000.00 WHERE EMPRESA = 'Filas' 1 fila actualizada.
2117 2118 2120 2124
3.60S,OO
3.750,QO 3.D82,QO
Adicin de datos a la base de datos

Tambin se puede utilizar SQL para aadir datos nuevos a la base de datos. Por ejemplo, supngase que se acaba de abrir una oficina comercial regional Oeste en Daganzo, con un objetivo de' ventas de 275.000 . A continuacin puede verse la instruccin INSERT que aade la nueva oficina a la base de datos, como oficina nmero 23:
INSERT INTO OFICINAS (CIUDAD, REGION, OBJETIVO, VENTAS, VALUES ('Daganzo', 'Oeste', 275000.00, 0.00. 23) 1 fila insertada. OFICINA)
La instruccin UPDATE tambin puede realizar de manera simultnea varias modificaciones en la base de datos. Por ejemplo, esta instruccin UPDATE eleva la cuota de todos los representantes en 15.000 :
UPDATE REPRESENTANTES SET CUOTA = CUOTA + 15000.00 8 filas actualizadas.
De manera parecida, si Mara Jimnez (nmero de empleado 109) suscribe a un nuevo cliente, Acme Industrial, esta instruccin INSERT aade el cliente a la base de datos como cliente nmero 2125 con un lmite de crdito de 25.000 :
INSERT INTO CLIENTES (EMPRESA, REP_CLI. NUM_CLI, LIMITE_CREDITO) VALUES ('Acme Industrial', 109, 2125, 25000.00) 1 fila insertada.
Proteccin de datos
Un papel importante de las bases de datos es proteger los datos almacenados del acceso por usuarios no autorizados. Por ejemplo, supngase que la secretaria, Mara, no ha sido autorizada con anterioridad a introducir en la base de datos los datos de los clientes nuevos. Esta instruccin de SQL le concede ese permiso:
GRANT INSERT ON CLIENTES TO MARIA Privilegio concedido.
Eliminacin de datos
Al igual que la instruccin de SQL INSERT aade datos nuevos a las bases de datos, la instruccin de SQL DELETE elimina datos de las bases de datos. Si Acme Industrial decide pasarse a la competencia unos das ms tarde, se puede eliminar de la base de datos la informacin de cliente de Acme con esta instruccin:
DELETE PROM CLIENTES WHERE COMPANY = 'Acme Industrial' 1 fila eliminada.
De manera parecida, la siguiente instruccin de SQL da a Mara permiso para actualizar y para recuperar datos de los clientes con la instruccin SELECT:
GRANT UPDATE, SELECT ON CLIENTES TO MARIA Privilegio concedido.
22
23
Si ya no se permite a Mara aadir clientes nuevos a la base de datos, la instruccin REVQKE se lo impedir:
REVOKE INSERT ON CLIENTES FROM MARIA Privilegio revocado.
Una vez creada la tabla, se pueden rellenar con datos. A continuacin se ofrece una instruccin INSERT para un nuevo envo de 250 cables de la serie 7 (producto ACI-410Q7), que cueslan 225,00 cada unidad ':
INSERT INTO PRODUCTOS
VALUES ('ACI',
(ID_FAB,
ID_PRODUCTO, DESCR!PCION,
225.00,
PRECIO,
STOCK)
'41007',
'Serie 7 cable',
250)
1 fila insertada.
De manera parecida, la instruccin REVOKE revocar todos los privilegios de Mara para cualquier tipo de acceso a los datos de los clientes:
REVOKE ALL ON CLIENTES FROM MARIA
Finalmente, si se descu.bre posteriormente que ya no hace falta almacenar los datos de los productos en la base de datos, se puede eliminar la tabla (y todos los datos que contiene) con la instruccin DROP TABLE:
DROP TABLE PRPDUCTOS
Privilegio revocado. Tabla eliminada.

Antes de poder almacenar datos en una base de datos hay que definir la estructura de los datos. Supngase que se desea ampliar la base de datos de ejemplo aadiendo una tabla de datos de los productos que vende la empresa. Para cada producto los datos que hay que almacenar son los siguientes: Un cdigo de identificacin del fabricante de tres caracteres. Un cdigo de identificacin del producto de cinco caracteres. Una descripcin del producto de treinta caracteres como mximo. El precio del producto. La cantidad actualmente en inventario.
CREATE TABLE
Resumen
Esta introduccin rpida a SQL ha mostrado lo que puede hacer SQL y ha ilustrado el estilo del lenguaje SQL, utilizando ocho de las instrucciones de SQL empleadas con ms frecuencia. Para resumir: Se puede utilizar SQL para recuperar datos de la base de datos, empleando la instruccin SELECT. Se pueden recuperar todos los datos almacenados o slo parte de ellos, ordenarlos y pedir a SQL que resuma los datos empleando totales y promedios. Se puede utilizar SQL para actualizar la base de datos, aadiendo datos nue vos con la instruccin INSERT, eliminando datos con la instruccin DELETE y modificando los datos existentes con la instruccin UPDATE. Se puede utilizar SQL para controlar el acceso a la base de datos, concediendo y revocando privilegios para usuarios concretos con las instrucciones
M
La instruccin de SQL los datos de Jos productos:
define una nueva tabla para almacenar
GRANT
CREATE TABLE PRODUCTOS (ID_FAB CHAR(3), ID_PRODUCTO CHAR(Sl, DESCRIPCION VARCHAR(20l, PRECIO MONEY. STOCK INTEGER)
y REVOKE.
Se puede utilizar SQL para crear la base de datos definiendo la estructura de nuevas tablas y eliminando tablas cuando ya no resultan necesarias utilizando las instrucciones CREATE y DROP.
Tabla creada.
. Aun~ue ms crptica que los ejemplos anteriores de instrucciones de SQL, la instruccin CREATE TABLE sigue siendo bastante directa. Asigna el nombre PRODUCTOS a la nueva tabla y especifica el nombre y el tipo de los datos almacenados en cada una de sus cinco columnas.
I N. del T.: El fonnato numrico que acepta la mayora de SGBD para la entrada de datos interactiva con SQL es el anglosajn, es decir, los millares separados por comas y la parte fraccionaria por puntos. Sin embargo, el formato de la respuesta s se puede adaptar en algunos SGBD, por lo que las respuestas se muestran en este libro segn el convenio numrico en espaol.
CAPTULO
SOL en perspectiva
SQL es a la vez un lenguaje estndar defacto y un lenguaje estndar oficial para la gestin de bases de datos. Qu significa que SQL sea un estndar? Qu papel desempea SQL como lenguaje de bases de datos? Cmo lleg SQL a ser un estndar y qu repercusin est teniendo el estndar SQL en las computadoras personales, las redes de rea local, las minicomputadoras y Jos grandes sistemas? Para responder a estas preguntas este captulo sigue la historia de SQL y describe su papel actual en el mercado informtico.
SOL Y la gestin de bases de datos

Una de las tareas principales de los sistemas informticos es almacenar y gestionar datos. Para realizar esta tarea comenzaron a aparecer programas informticos especializados conocidos como sistemas gestores de bases de datos a finales de los aos sesenta y comienzos de los setenta del siglo pasado. Los sistemas gestores de bases de datos, o SGBD, ayudaban a los usuarios a organizar y estructurar los datos y permitan que el sistema informtico desempeara un papel ms activo en la gestin de los datos. Aunque los sistemas gestores de bases de datos se desarrollaron en primer lugar en los grandes sistemas informticos, su popularidad se extendi rpidamente a las minicomputadoras y, posteriormente, a las computadoras personales y a las estaciones de trabajo. Hoy en da, muchos sistemas gestores de bases de datos operan en compuladoras servidoras especializadas. La gestin de bases de dalOs ha desempeado tambin un papel fundamental en la explosin de las redes informticas y de Internet. Los primeros sistemas de bases de datos se ejecutaban en grandes sislemas informticos monolticos, en los que la informacin, el software de gestin de bases de datos y el usuario o la aplicacin que tenan acceso a la base de datos operaban lodos en el mismo sistema. Los aos ochenta y noventa del siglo pasado vieron la explosin de un nuevo modelo cliente/servidor para el acceso a bases de dalOs, en el cual un usuario o un programa de aplicacin que se ejecute en una computadora personal tienen acceso
25
26
Captulo 3: SOL en perspectiva
27
a una base de datos de un sistema informtico diferente mediante una red. A fines de los aos noventa, la creciente popularidad de Internet y del World Wide Web entrelazaron an ms los mbitos de las redes y de la gestin de datos. Actualmente, los usuarios necesitan poco ms que un explorador web para tener acceso a las bases de datos e interactuar con ellas, no slo dentro de sus propias organizaciones, sino en todo el mundo. A menudo estas arquitecturas basadas en Internet implican tres o ms sistemas informticos diferentes -una computadora que ejecuta el explorador web e interacta con el usuario, conectada a un segundo sistema que ejecuta un programa de aplicacin o servidor de aplicaciones, que, a su v.ez, est conectado a un tercer sistema que ejecuta el sistema gestor de bases de datos. Hoy en da la gestin de bases de datos es un negocio enorme. Las compaas de software independientes y los fabricantes de computadoras facturan miles de millones de euros cada ao en productos de gestin de bases de datos. La inmensa mayora de las aplicaciones informticas de tipo empresarial que acogen la operativa diaria de las grandes empresas y de otras organizaciones utiliza bases de datos. Entre estas aplicaciones se hallan algunas de las categoras de aplicaciones de crecimiento ms rpido, como la Planificacin de recursos empresariales (Enterprise Resource Planning, ERP), la Gestin de relaciones con los clientes (Customer Relationship Management, CRM), la Gestin de la cadena de suministros (Supply Chain Management, SCM), la Automatizacin de la fuerza de ventas (Sales Force Automation, SFA) y las aplicaciones financieras. Los fabricantes de computadoras desarroll?n y venden computadoras servidoras que se hallan configuradas especficamente como servidores de bases de datos; estos sistemas constituyen por s mismos un mercado de varios miles .de millones de euros al ao. Las bases de datos proporcionan la inteligencia que sustenta la mayor parte de los sitios web orientados a transacciones, y se emplean para capturar y analizar las interacciones de los usuarios con los sitios web. La gestin de bases de datos se vincula de este modo a todos los segmentos del mercado informtico. Desde fines de los aos ochenta se ha hecho tan popular un tipo especfico de SGBD, denominado sistema gestor de bases de datos relacionales (SGBDR), que es la forma estndar de bases de datos. Las bases de datos relacionales organizan los datos de una manera sencilla, tabular, y presentan muchas ventajas respecto de los tipos anteriores de bases de datos. SQL es especficamente un lenguaje para bases de datos relacionales empleado para trabajar con bases de datos relacionales.
Tabla 3.1.
Hitos en el desarrollo de SOL
Fecha
Evento Codd define el modelo relacional de bases de datos. IBM comienza el proyecto System/R. Se publica el primer artculo que describe el lenguaje SEQUEL. Se realizan pruebas de SystemlR con clientes. Orade introduce el primer SGBDR comercial. Relational Technology introduce Ingres. IBM anuncia SQUDS. ANSI forma el comit para estndares de SQL. IBM anuncia DB2. Se ratifica el estndar ANSI SQLl. Sybase introduce SGBDR para el procesamiento de transacciones. Se ratifica el estndar ISO SQLl. Ashton-Tate y Microsoft anuncian SQL Server para OS/2. Se publica la primera prueba de rendimiento TPC (TPC-A). Se publica la prueba de rendimiento TPC-B. Se publica la especificacin de acceso a bases de datos SQL Access Group. Microsoft publica la especificacin ODBC. Se ratifica el estndar ANSI SQL2 (SQL-92). Se publica la prueba de rendimiento TPC-C (OLTP). Por primera vez se distribuyen sistemas de almacenamiento de datos SQL especializados. Por primera vez se distribuyen productos ODBC. Se distribuye comercialmente tecnologa paralela de servidores de bases de datos. Se publican el API estndar para el acceso OLAP a bases de datos y la prueba de rendimiento OLAP. UDB DB2 de IBM unifica la arquitectura DB2 para las plataformas de IBM y de otros fabricantes. Los principales fabricantes de SGBD anuncian estrategias de integracin de Java. Microsoft SQL Server 7 ofrece soporte de bases de datos para Windows NT en mbito empresarial. Oracle Si ofrece integracin entre las bases de datos e Internet y rompe con el modelo cliente/servidor. Se distribuyen por primera vez productos comerciales de bases de datos residentes en memoria. J2EE estandariza el acceso IDBe a bases de datos desde los servidores de aplicaciones. Oracle introduce servidores de aplicaciones con cach integrada de bases de datos. Microsoft introduce SQL Server 2000, dirigido a las aplicaciones empresariales. La posibilidad de integracin de XML aparece en los principales productos SGBDR. IBM adquiere el negocio de bases de datos de Informix. Gartner clasifica a IBM como primer fabricante de bases de datos, superando a Oraele.
1970 1974 1974 1978 1979 1981 1981 1982 1983 1986 1986 1987 1988 1989 1990 1991 1992 1992 1992 1993 1993 1994 1996 1997 1997 1998 1998 1998 1999 2000 2000 2001 2001 2002
el
Una breve historia de SOL

La historia del lenguaje SQL se halla ntimamente vinculada al desarroll9 de las bases de datos relacionales. La Tabla 3.1 muestra algunos de los hitos en sus treinta aos de historia. El concepto de base de datos relacional fue desarrollado originalmente por el Dr. E. F. Cad(! (<<Ted), un investigador de IBM. En Junio de 1970, el Dr. Codd public un artculo titulado A Relational Model of Data for Large Shared Data
28
29
Banks (<<Un modelo relacional de datos para grandes bancos de datos compartidos), que esbozaba una teora matemtica del modo en que se podan almacenar y manipular los datos empleando una estructura tabular. Los orgenes de las bases de datos relacionales y SQL se remontan a este artculo, que apareci en Communicarions o/ the AssociatiolJ for CompUling Machinery (<<comunicaciones de la aso~ ciacin de maquinaria informtica).
empresa, Relational Software, Ine., para crear un SGBD relacional basado en SQL. El producto. denominado Oracle. se distribuy en 1979 y se transform en el primer SGBD relacional disponible comercialmente. Gracle se adelant dos aos
Los primeros aos

El artculo de Codd desat un frenes de investigacin en bases de datos relacionales, incluido un importante proyecto de investigacin de IBM. El objetivo del pro. yecto, denominado System/R, era comprobar la operatividad del concepto relacional y proporcionar experiencia en la implementacin real de un SGBO relacional El trabajo en SystemIR comenz a mediados de los aos setenta en los laboratorios Santa Teresa de IBM en San Jos, California. En 1974 y 1975, la primera fase del proyecto System/R produjo un prototipo mnimo de SGBD relacional. Adems del propio SGBD, el proyecto SystemlR inclua el trabajo en los lenguajes de consulta a bases de datos. Uno de estos lenguajes se denomin SEQUEL, acrnimo de Lenguaje estructurado de consulta en ingls (Slruelured English Query Language). En 1976 y 1977 el prototipo de investigacin de System/R se volvi a escribir desde el principio. La nueva implementacin soportaba consultas multitabla y permita que varios usuarios compartieran el acceso a los datos. La implementacin de SystemIR se distribuy a varios sitios clientes de IBM para su evaluacin en 1978 y 1979. Estos primeros sitios clientes proporcionaron experiencia de usuarios reales Con System/R y su lenguaje de bases de datos, el cual, por motivos .legales, se haba renombrado como SQL, O Lenguaje estructurado de consultas (Structured Query Language). Pese al cambio de nombre, la pronunciacin inglesa SEQUEL se mantuvo, y contina usndose hoy en da. En 1979 el proyecto de investigacin System/R lleg a su final, e IBM concluy que las bases de datos relacionales no slo eran factibles, sino que podan ser la base de un producto comercial til.
enteros al primer producto que comercializ IBM y se ejecutaba en las minicomputadoras VAX de Digital, que resultaban menos caras que los grandes sistemas de IBM. La empresa vendi agresivamente las ventajas del nuevo estilo relacional de gestin de bases de datos y, finalmente, acab cambiando su nombre por el de su producto insignia. Hoy en da Oracle Corporation es el principal fabricante de sistemas gestores de bases de datos relacionales, y un importante fabricante de aplicaciones empresariales basadas en la base de datos Orade, con ventas anuales de muchos miles de millones de euros. Los profesores de los laboratorios informticos de Berkeley de la Universidad de California tambin estaban investigando en las bases de datos relacionales a mediados de los aos setenta. Al igual que el equipo de investigacin de mM, crearon un prototipo de SGBD relacional y denominaron Ingres a su sistema. El proyecto lngres inclua un lenguaje de consultas, denominado QUEL, que, aunque ms estructurado que SQL, era menos similar al ingls. Muchos de los expertos actuales en bases de datos debe!1 su vinculacin a las bases de datos relacionales al proyecto Ingres de Berkeley, incluidos los fundadores de Sybase e IlIustra (actualmente, propiedad de IBM), as como muchas de las compaas emergentes de bases de datos orientadas a objetos. En 1980, varios profesores abandonaron Berkeley y fundaron Relational Technology, Inc., para crear una versin comercial de Ingres, que se anunci en 1981. Ingres y Oracle se convirtieron rpidamente en grandes rivales, pero su rivalidad ayud a llamar la atencin hacia la tecnologa de las bases de datos relacionales en esta etapa inicial. Pese a su superioridad tcnica en muchos aspectos, logres se convirti en un claro jugador de segundo nivel en este mercado, que competa contra las posibilidades basadas en SQL (y las agresivas estrategias de mercadotecnia y de ventas) de Grade. El lenguaje QUEL original fue sustituido de manera efectiva por SQL en 1986, prueba del dominio del mercado del estndar SQL. Hacia mediados de los noventa, la tecnologa Ingres se haba vendido a Computer Associates, uno de los principales fabricantes de software para grandes sistemas.
Los primeros productos relacionales

El proyecto SystemIR y su lenguaje de bases de datos SQL se dieron a conocer con detalle en las revistas tcnicas durante los aos setenta. Los seminarios sobre tecnologa de bases de datos ofrecan debates sobre las ventajas del nuevo y hertico modelo relacional. Hacia 1976 pareca evidente que IBM se estaba entusiasmando con la tecnologa relacional de bases de datos y que estaba estableciendo un importante compromiso con el lenguaje SQL. La publicidad de System/R atrajo la atencin de un grupo de ingenieros de Menlo Park, California, que consideraron que la investigacin de IBM presagiaba un mercado comercial para las bases de datos relacionales. En 1977 formaron una
Productos de IBM
Mientras Oracle e Ingres corran a convertirse en productos comerciales, el proyecto System/R de IBM tambin se haba convertido en un esfuerzo por crear un producto comercial, denominado SQUData System (SQUDS). IBM anunci SQU DS en 1981 y comenz a distribuir el producto en 1982. En 1983, IBM anunci una versin de SQLIDS para VMlCMS, un sistema operativo que se empleaba con frecuencia en los grandes sistemas de IBM en las aplicaciones de los centros informticos empresariales. En 1983, IBM introdujo tambin Database 2 (DB2), otro SGBD relacional para sus grandes sistemas. DB2 operaba bajo el sistema operativo MVS de IBM, que
30
.Captulo 3: SaL en perspectiva
31
era el burro de carga utilizado en los grandes centros de procesamiento de datos de los grandes sistemas. La primera versin de DB2 comenz a distribuirse en 1985. y los empleados de IBM la saludaron como una pieza estratgica de la tecnologa de software de lBM. DB2 se ha convertido desde entonces en la insignia de los SGBD relacionales de IBM, y con el peso de IBM tras l, el lenguaje SQL de DB2 se convirti en el lenguaje de bases de dalos estndar de facto. La tecnologa DB2 se ha migrado actualmente a todas las lneas de productos de IBM, desde las computadoras personales a los servidores de red y los grandes sistemas. En 1997. IBM llev an ms all la estrategia multiplataforma de DB2, anunciando versiones de DB2 para sistemas informticos fabricados por Sun Microsystems, Hewleu-Packard y otros competidores de IBM en hardware. IBM dio otro paso en su estrategia multiplataforma en 200 1, cuando adquiri el negocio de bases de datos de Informix y, especialmente, la base instalada de Informix en servidores basados en UNIX que no son de IBM. Segn la mayor parte de los analistas de la industria, IBM es el segundo fabricante ms importante de software de gestin de bases de datos, y algunas encuestas a usuarios lo colocan realmente en primer lugar, un poco por delante de Oracle en cuota de mercado.
Aceptacin comercial
Durante la primera mitad de los ochenta, los fabricantes de bases de datos relacionales luchaban por conseguir la aceptacin comercial de sus productos. Los produc:tos relacionales presentaban varias. desventajas en relacin con las arquitecturas tradicionales de bases de datos. Excepto los productos de IBM, las bases de datos relacionales procedan de pequeos fabricantes emergentes. Y, salvo los productos de 1BM, las bas~s de datos relacionales tendan a ejecutarse en minicomputadoras, en lugar de en los grandes sistemas de 1BM. Los productos relacionales, sin embargo, tenan una ventaja importante. Sus lenguajes de consultas relacionales (SQL, QUEL y otros) permitan a los usuarios formular consultas ad hoc a la base de datos -y obtener respuestas inmediatassin necesidad de escribir ningn programa. En consecuencia. las bases de datos relacionales comenzaron a convertirse poco a poco en aplicaciones de centros informticos como herramientas de soporte de decisiones. Hacia mayo de 1985, Oracle proclam con orgullo que tena ms de mil instalaciones. lngres se instal en un nmero de sitios comparable. DB2 y SQUDS tambin se aceptaron poco a poco y contaron sus instalaciones combinadas'en poco ms de mil sitios. En la segunda mitad de los aos ochenta del siglo pasado SQL y las bases de datos relacionales se aceptaron rpidamente como la tecnologa de las bases de datos del futuro. El rendimiento de los productos de bases de datos relacionales mejor espectacularmente. lngres y Oracle, en especial, dieron un paso de gigante con cada nueva versin, proclamando su superioridad sobre el competidor y un rendimiento doble o triple que el de la versin anterior. Las mejoras de la potencia de procesamie~to del hardware informtico subyacente tambin ayudaron a mejorar el rendimiento.
Las fuerzas del mercado tambin fomentaron la popularidad de SQL a fines de los aos ochenta del siglo pasado. IBM increment su promocin de SQL, situando a DB2 como la solucin de gestin de datos para los aos noventa. La publicacin del estndar ANSI/ISO para SQL en 1986 otorg estatus oficial a SQL como estndar. SQL tambin se afianz como estndar en los sistemas informticos basados en UNIX, cuya popularidad se aceler en los aos ochenta. A medida que las computadoras personales se hacan ms potentes y se conectaban en redes de rea local (local area networks, LAN), fueron necesitando una gestin de bases de datos ms sofisticada. Los fabricantes de bases de datos para pe adoptaron SQL como la solucin para estas necesidades, y los fabricantes de bases de datos para minicomputadoras bajaron un nivel del mercado para competir en el mercado emergente de las redes de rea local de computadoras personales. En los primeros aos novema del siglo pasado las implememaciones de SQL que mejoraban poco a poco y las espectaculares mejoras de las velocidades de los procesadores hicieron de SQL una solucin prctica para las aplicaciones de procesamiento de transacciones. Finalmente, SQL pas a constituir una parte fundamental de la arquitectura cliente/servidor que utilizaban las computadoras personales, las redes de rea local y los servidores de red para crear sistemas de procesamiento de informacin mucho ms econmicos. La supremaca de SQL en el mundo de las bases de datos no se ha librado de desafos. A principios de los aos noventa, la programacin orientada a objetos se haba implantado como el mtodo preferido para el desarrollo de aplicaciones, especialmente para las computadoras personales y sus interfaces grficas de usuario. El modelo de objetos. con sus objetos, sus clases, sus mtodos y su herencia, no proporcionaba un encaje ideal con el modelo relacional de tablas, filas y columnas de datos. Surgi una nueva generacin de empresas de bases de datos orientadas a objetos apoyadas por capital de riesgo que deseaban dejar obsoletas las bases de datos relacionales y a sus fabricantes, al igual que haba hecho SQL con los fabricantes no relacionales anteriores. Sin embargo, SQL y el modelo relacional superaron con creces el reto. Los ingresos anuales totales de las bases de datos orientadas a objetos se miden, como mucho, en centenares de millones de euros. mientras que SQL y los sistemas de bases de datos relacionales, sus herramientas y sus servicios generan decenas de miJes de millones de euros al ao. A medida que SQL creci para abordar una variedad cada vez mayor de tareas de gestin de datos, el enfoque untamao-sirve-para-todos dio muestras de agotamiento. A finales de los aos noventa, la gestin de bases de datos ya no era un mercado monoltico. Surgieron sistemas especializados de bases de datos para dar soporte a diferentes necesidades del mercado. Uno de los segmentos de crecimien to ms rpido fueron los almacenes de datos, en los que se utilizaban las bases de datos para buscar entre cantidades enormes de datos y descubrir las tendencias y los patrones subyacentes. Una segunda tendencia importante fue la incorporacin a SQL de nuevos tipos de datos (como los datos multimedia) y los principios de orientacin a objetos. Un tercer segmento de importancia fueron las bases de datos mviles para las computadoras personales porttiles que podan operar tanto conectadas como desconectadas de un sistema centralizado de bases de datos. 'Otro
32
33
segmento importante de aplicaciones fueron las bases de datos incorporadas para su empleo con dispositivos inteligentes, como los equipos de red. Las bases de dalos residentes en la memoria se establecieron como otro segmento, diseado para niveles de rendimiento muy elevados. Pese a la aparicin de subsegmenlos del mercado de bases de datos, SQL ha seguido siendo un denominador comn de lodos ellos. A medida que la industria informtica se prepara para este nuevo siglo. el dominio de SQL como el estndar de bases de datos sigue siendo muy fuerte. Siguen surgiendo nuevos reto"s -las bases de datos basadas en el Lenguaje extendido de marcas (eXtended Markup Language, XML) son el ltimo intento de salirse del modelo relacional y de SQLpero la historia de los ltimos veinte aos indica que SQL y el modelo relacional tienen una enorme capacidad para aceptar las nuevas necesidades de gestin de datos y adaptarse a ellas.
Estndares de SaL
Uno de los desarrollos ms importantes en la aceptacin de mercado de SQL es la aparicin de estndares de SQL. Las referencias al estndar de SQL suelen hacer referencia al estndar oficial adoptado por el organismo estadounidense de normalizacin (American National Standards Institute, ANSI) y la Organizacin Internacional de Normalizacin (International Standards Organization, ISO). Sin embargo, hay otros estndares importantes de SQL, como el estndar de/acto para algunas partes dellenguaje SQL, que ha sido definido por la familia de productos DB2. de lB M, y el dialecto de SQL de Oracle, que tiene una cuota de mercado dominante en cuanto a base instalada. .
Los estndares ANSI/ISO

El trabajo en el estndar oficia! de SQL comenz en 1982, cuando ANSI encarg a su comit X3H2 la definicin de un lenguaje estndar para bases de datos relacionales. En principio el comit debati las ventajas de los diversos lenguajes de bases de datos propuestos. Sin embargo, como el compromiso.de IBM con SQL se incrementaba y SQL se estableci como un estndar de jacto en el mercado, el comit seleccion SQL como lenguaje para las ,bases de datos relacionales y centr su atencin en normalizarlo. El estndar ANSI para SQL resultante se basaba principalmente en SQL de DB2, aunque contena algunas diferencias importantes respecto de DB2. Tras varias revisiones el estndar se adopt oficialmente como estndar ANSI X3.135 en 1986, y como estndar ISO en 1987. El gobierno estadounidense ha adoptado desde entonces el estndar ANSI/ISO como Estndar federal para el procesamiento de la informacin (Federalln/ormatioll Processing Standard, FIPS). Este estndar, lger.amente revisado y ampliado en 1989, suele denominarse SQL-89 o estndar SQLI.
Muchos de los integrantes de los comits de estndares de ANSI y de ISO eran representantes de los fabricames de bases de datos que tenan productos SQL ya existentes, cada uno de los cuales implementaba un dialecto de SQL ligeramente diferente. Al igual que ocurre con los dialectos de los lenguajes humanos, los dialectos de SQL eran, por lo general. bastante parecidos el1lre s, pero incompatibles en sus detalles. En muchas reas el comit simplemente obvi estas diferencias omitiendo del estndar ciertas partes del lenguaje y especificando otras como definidas por el implementador. Estas decisiones permitieron que las implememaciones ya existentes de SQL proclamaran una gran adhesin al estndar ANSI/ISO resultante, pero hicieron el estndar relativamente dbil. Para abordar los agujeros del estndar original, el comit ANSI continu su trabajo y se distribuyeron borradores de un nuevo estndar ms riguroso, SQL2. A diferencia del estndar de 1989, los borradores de SQL2 especificaban caractersticas muc'ho ms all de las halladas en los productos SQL comerciales en vigor. Se propusieron incluso ms modificaciones de gran alcance para un posterior estndar SQL3. Adems, los borradores de estndares intentaban estandarizar oficialmente panes del lenguaje SQL en que las diferentes Imarcas de SGBD haban definido diferentes estndares propietarios desde haca mucho tiempo. En consecuencia, los estndares propuestos SQL2 y SQL3 resultaron mucho ms polmicos que el estndar SQL inicial. El estndar SQL2 super el proceso de aprobacin de ANSI y se aprob definitivamente en octubre de 1992. Mientras que el estndar original de 1986 ocupaba menos de cien pginas, el estndar SQL2 (denominado oficialmente SQL-92) ocupa cerca de seiscientas pginas. El comit de estndares de SQL2 reconoci el gran avance logrado desde SQLI hasta SQL2 creando explcitamente tres niveles de cumplimiento de los estndares de SQL2. El nivel de cumplimiento ms bajo (nivel inicial) slo exige una capacidad adicional mnima respecto del estndar SQL-89. El nivel de cumplimiento intermedio (nivel intermedio) se cre como un avance posible respecto de SQL-89, pero que evita los aspectos ms complejos y la mayora de los problemas dependientes del sistema y de las marcas de SGBD. El tercer nivel de cumplimiento (completo) exige una implementacin completa de todas las posibilidades de SQL2. A lo largo de las seiscientas pginas del estndar la descripcin de cada caracterstica incluye una definicin de los aspectos concretos de esa caracterstica que deben soportarse para conseguir un cumplimiento inicial, intermedio o completo. Pese, a la existencia del estndar SQL2 desde hace ms de diez aos, en la prctica los productos comerciales de SQL ms populares no implementan completamente la especificacin SQL2, y no hay dos productos comerciales de SQL que soporten exactamente el mismo dialecto de SQL. Adems, a medida que los fabricantes de bases de datos introducen nuevas posibilidades, amplan continuamente.sus dialectos de SQL y se apartan ms del estndar. No obstante, el ncleo central del lenguaje SQL se ha estandarizado bastante. Donde se poda lograr sin daar a los clientes o a las caractersticas ya existentes los fabricantes han adaptado sus productos para que cumplan con el estndar SQL-89, y con las posibilidades ms tiles del estndar SQL2.
34
35
Entretanto, se contina trabajando en estndares posteriores a SQL2. El esfuerzo de SQL3 se fragment finalmente en esfuerzos de estandarizacin independientes y se centr en diferentes extensiones de SQL. Algunas de ellas, como las posibilidades de los procedimientos almacenados, ya se hallan en muchos productos comerciales de SQL y plantean los mismos retos de estandarizacin afrontados por SQL2. Otras, como las extensiones de SQL orientadas a objetos no estn todava disponibles de manera general o completamente implementadas, pero han generarlo un alto grado de debate. Con la mayor parte de los fabricantes que slo han implementado recienlemente las principales posibilidades de SQL2, y con la diversidad de extensiones de SQL disponibles hoy en da en productos comerciales, el trabajo en SQL3 ha alcanzado menos importancia comercial. El verdadero estndar de SQL, por supuesto, es el lenguaje SQL implementado en los productos que estn generalmente aceptados por el mercado. En su mayora los. programadores y los usuarios tienden a seguir las partes del lenguaje que son bastante parecidas en una amplia gama de productos. La innovacin de los fabricantes de bases de datos sigue impulsando la invencin de nuevas posibilidades de SQL; algunos productos permanecen en el mercado durante aos slo para asegurar la compatibilidad con productos anteriores, y algunos logran el xito comercial y pasan a ser de aceptacin general.
ODBC y el grupo de acceso SOL

Un rea importante de la tecnologa de bases de datos no abordada por los estndares oficiales es la interoperatividad entre bases de dolos -los mtodos mediante los cuales se pueden intercambiar datos entre bases de datos diferentes, generalmente a travs de una red. En 1989 un grupo de fabricantes form el Grupo de acceso SQL (SQL Access Group) para abordar este problema. La especificacin resultante del Grupo de acceso SQL para el acceso a bases de datos remotas (Remate Database Access, RDA) se public en 1991. Por desgracia, la especificacin RDA se hallaba ntimamente ligada a Jos protocolos OSI, que nunca se implementaron ampliamente, por lo que tuvo poco impacto. La interoperatividad transparente entre bases de datos de diferentes fabricantes sigue siendo un objetivo huidizo. Un segundo estndar del Grupo de acceso SQL tuvo mucho ms impacto en el mercado. Ante la insistente peticin de Microsoft, el Grupo de acceso SQL ampli su campo de atencin para incluir una interfaz en el nivel de llamadas para SQL. Basada en un borrador de Microsoft, la especificacin Interfaz en el nivel de llamadas (CalJ-Levellnlerface, CU) resultante se public en 1992. La misma especificacin de Conectividad abierta de bases de datos (Open Oatabase Connectivity, OOBC) de Microsoft, basada en el estndar CLI, se public ese mismo ao. Con el poder de mercado de Microsoft tras l y la bendicin de estndares abiertos del Grupo de acceso SQL, OOBC se ha implantado como la interfaz estndar de jaclO para el acceso mediante computadora personal a las bases de datos de SQL. Apple y Microsoft anunciaron un acuerdo para soportar ODBC en Macintosh y en Windows en la primavera de 1993, lo que da a ODBC estatus de estndar de la industria en los dos entornos de interfaz grfica ms populares. Las implementaciones de ODBC para los sistemas basados en UNIX no tardaron en llegar. En 1995 la interfaz OOBC se transform de manera efectiva en un estndar ANSI/lSO, con la publicacin del estndar de la Interfaz en el nivel de llamadas para SQL (SQUCall-Levellnterface, CLI). Hoy en da, OOBC est en su cuarta revisin de importancia como estndar para el acceso a bases de datos en diversas plataformas. El soporte de OOBC est disponible para todas las marcas de SGBD. La mayor parte de los programas de aplicacin que se venden como paquetes que tienen el acceso a bases de datos como una parte importante de sus posibilidades soportan ODBC, y van desde las aplicaciones de tipo empresarial de varios millones de euros como la planificacin de recursos empresariales y la gestin de la cadena de suministros a aplicaciones para computadoras personales como las hojas de clculo, las herramientas de consulta y los programas de elaboracin de infonnes. La atencin de Microsoft ha pasado de OOBC a in~ terfaces de nivel superior (como OLEJDB) y, ms recientemente, a los objetos de datos de ActiveIX (ActiveIX Data Objects. ADO), pero ests nuevas interfaces se apilan sobre OBC para el acceso a bases de datos relacionales, y sta sigue siendo una tecnologa fundamental para el acceso a bases de datos entre diferentes plataformas.
Otros estndares de SOL

Aunque es el ms ampliamente reconocido, el estndar ANSI/ISO no es el nico estndar para SQL. X/OPEN, un grupo de fabricantes europeos, tambin adopt SQL como parte de su conjunto de estndares para un entorno porttil de aplicaciones basado en UNIX. Los estndares x/OPEN han desempeado un papel importante en el mercado nfonntico europeo, donde la transportabilidad entre sistemas informticos de diferentes fabricantes es una preocupacin fundamental. Por desgracia, el estndar x/OPEN se diferencia del estndar ANSI/ISO en varias reas. IBM tambin incluy SQL en la especificacin de su audaz proyecto de los aos noventa del siglo pasado Arquitectura de aplicacin de sistemas (Syslems Applicalion Architeclure, SAA), que prometa que todos sus productos de SQL acabaran pasndose a este dialecto SQL de SAA. Aunque SAA no logr cumplir sus promesa de unificar la lnea de productos de IBM, el impulso hacia un SQL unificado de IBM continu. Con su base de datos DB2 para grandes sistemas como insignia, IBM introdujo implementaciones de DB2 para OS/2, su sistema operativo para computadoras personales, y para su lnea. de productos RS/6000 de estaciones de trabajo y de servidores basados en UNIX. Hacia 1997 IBM haba llevado a DB2 ms all de su propia lnea de productos y haba distribuido versiones de DB2-Universal Database para sistemas hechos por los fabricantes rivales Sun Microsystems, Hewlett-Packard y Silicon Graphics, y para Windows NT. IBM reforz an ms sus posicin en el software para bases de datos en plataformas de hardware que no son de IBM con su adquisicin en 2001 de la base de datos Informix. Con el liderazgo histrico de IBM en la tecnologa de las bases de datos relacionales, el dialecto de SQL'incorporado por DB2 es un estndar de jaclo muy potente.
SOL Y transportabilidad
La existencia de estndares publicados para SQL ha generado unas cuantas afirmaciones exageradas sobre SQL y la transportabilidad de las aplicaciones. Se sue-
36
Capitulo 3: SOL en perspectiva
37
len dibujar diagramas como el de la Figura 3.1 para mostrar el modo en que las aplicaciones que utilizan SQL pueden trabajar de manera intercambiable con cualquier sistema gestor de bases de datos basado en SQL. De hecho, los agujeros del estndar SQL-89 y las diferencias actuales entre los dialectos de SQL son lo bastante significativas como para que haya que modificar siempre las aplicaciones al pasarlas de una base de datos de SQL a otra. Entre estas diferencias, muchas de las cuales se eliminaron en el estndar SQL2 pero todava no se han .implementado en los productos comerciales, figuran:
Cdigos de error. El estndar SQL-89 no especifica los cdigos de error que hay que mostrar cuando SQL o.etecta un error, y cada implementacin comercial utiliza su 'propio conjunto de cdigos. El estndar SQL2 especifica los'cdigos de error estndar. Tipos.de datos. El estndar SQL-89 define un conjunto mnimo de tipos de datos,'pero'omite algunos de los tipos ms populares y tiles, corno las cadenas de caracteres ,de .longitud variable, las fechas y las horas y los datos de monedaJEIestndar SQL2 aborda'este problema, pero no los tipos de datos nuevos, 'como Jos grficos.y los objetos multimedia. Tablas'del'sistema. El estndar SQL-89'no dice nada respecto de las tablas del 'sistema que ofrecen informacin relativa a la estructura de la propia base de ~atos. Cada fabricante tiene su propia estructura para estas tablas, e, incluso, las cuatro implementaciones de IBM difieren entre s. Las tablas se estandarizan en SQL2, pero slo en los grados de cumplimiento ms elevados, que la mayora de los fabricantes todava no ofrece. SQL interactivo. El estndar especifica slo la programacin con SQL utilizado por los programas de aplicacin, no SQL interactivo. Por ejemplo, la instruccin SELECT utilizada para consultar la base de datos en SQL interactivo est ausent~ en el estndar SQL-89. Una vez ms, el estndar SQL2
APllc:c;n
Aplicacin 2
Aplicacion 3
. 'APll,,:cin
. I
SGBD
1
.+
I
+.
~.J
SOL eS;ndarll
I
+
SGBD
..
I
SGBD
2
aborda este problema, pero mucho despus de que todos los principales vendedores de SGBD tuvieran posibilidades bien establecidas de SQL interactivo. Interfaz para programacin. El estndar original especifica una tcnica abstracta para emplear desde el interior de SQL unos programas de aplicacin escritos en COBOL. C, FORTRAN y otros lenguajes de programacin. Ningn producto comercial de SQL utiliza esta tcnica, y hay variaciones considerables entre las interfaces para programacin utilizadas realmente. El estndar SQL2 especifica una interfaz incorporada para SQL para los lenguajes de programacin ms populares, pero no una interfaz en el nivel de llamadas. El estndar SQUCLI de 1995 abord finamente el acceso a SQL mediante programacin, pero no antes de que los productos SGBD comerciales hubieran popularizado interfaces propietarias y las incorporaran profundamente en forma de cientos de millares de aplicaciones de usuario y paquetes de aplicaciones. SQL dinmico. El estndar SQL-89 no incluye las caractersticas necesarias para desarrollar partes visibles al usuario de finalidad general, como las herramientas para bsqueda y los redactores de informes. Estas caractersticas, conocidas como SQL dinmico, se hallan en casi todos los sistemas de bases de datos de SQL, pero varan significativamente de un producto.a otro. SQL2 incluye un estndar para SQL dinmico. Pero con centenares de miles de aplicaciones ya existentes, dependientes de la compatibilidad con los productores anteriores, los fabricantes de SGBD no 10 han implementado. Diferencias semnticas. Como los estndares especifican ciertos detalles como definidos por el implementador, resulta posible ejecutar la misma consulta en dos implementaciones diferentes confof?les con SQL y obtener dos conjuntos de resultados de la consulta diferentes. Estas diferencias se producen en el manejo de los valores NULL, en las funciones de columnas y en la eliminacin de filas duplicadas. Secuencias de ordenacin. El estndar SQL-89 no aborda la secuencia de ordenacin (tipo de orden) de los caracteres almacenados en la base de datos. El resultado de una consulta ordenada ser diferente si la consulta se ejecuta en una computadora personal (con caracteres ASCII) O en un gran sistema (con caracteres EBCDIC). El estndar SQL2 incluye una especificacin elaborada de manera que los programas y los usuarios pueden solicitar una secuencia de ordenacin determinada, pero es una caracterstica de nivel avanz.ado que no est incluida, por lo general, en los productos comerciales. Estructura de las bases de datos. El estndar SQL-89 especifica el lenguaje SQL que hay que utilizar una vez se ha abierto una base de datos determinada y est preparada para su procesamiento. Los detalles de las denominaciones de las bases de datos y del modo en que se establece la conexin inicial con la base de datos varan ampliamente y no son transferibles. El estndar SQL2 crea ms uniformidad pero no puede enmascarar por completo estos detalles.
Figura 3.1.
El mito de la transportabilidad de SOL.
Pese a estas diferencias, las herramientas comerciales para bases de datos que presumen de transportabilidad entre varias marcas diferentes de bases de datos de
38
39
SQL comenzaron a surgir a principios de los aos noventa. En cada caso, no obstante, las herramientas necesitaban un adaptador especial para cada SGBD albergado, que genera el dialecto de SQL adecuado, controla la conversin de tipos de datos, traduce los cdigos de error, etc. La transportabilidad transparente entre diferentes marcas de SGBD, basada en SQL estndar, es el principal objetivo de SQL2 y de DBC, y se ha alcanzado un progreso significativo. Hoy en da, casi todos los programas que albergan varias bases de datos incluyen controladores especficos para comunicarse con cada una de las principales marcas de SOBD, y suelen incluir un controlador ODBe para tener acceso a las dems.
SOL Y redes
El espectacular crecimiento de las redes informticas en los aos noventa tuvo un importante impacto en la gestin de bases de datos y dio a SQLunanueva importancia. A medida que las redes se hicieron ms' comunes, las aplicaciones que tradicionalmente se ejecutaban en una minicomputadora o en un gran sistema central pasaron a redes de rea local de estaciones detrabajo de mesa y servidores. En estas 'redes SQL desempea un papel crucial como enlace entre la aplicacin que se ejecuta en la estacin de trabajo de mesa con una interfaz grfica de usuario y el SGBD que gestiona los datos compartidos en un servidor efectivo en costes. Ms recientemente. la creciente popularidad de Internet y World Wide Web ha reforzado el papel de SQL en las redes. En la arquitectura de Internet de tres capas que se est imponiendo, SQL vuelve a proporcionar el enlace entre la lgica de las apli'caciones (que se ejecuta ahora en la capa intermedia, en un servidor de aplicaciones o en un servidor web) y la base de datos residente en la capa del sistema subyacente. Las siguientes secciones estudian la evolucin' de las arquitecturas de red de las bases de datos y el papel de SQL en cada una de ellas.
Gracle e Ingres. En esta arquitectura el SGBn y los datos fsicos residen en una minicomputadora o gran sistema central, junto con el programa de,aplicacin que acepta las entradas desde el terminal del usuario y muestra los datos en la pantalla del usuario. El programa de aplicacin se comunica con el SGBD empleando SQL. Supngase que el usuario escribe una consulta que exige una bsqueda secuencial en la base de datos, como puede ser una solicitud de bsqueda del'tamao promedio de los pedidos para .todos los pedidos. El SGBD recibe la consulta, busca por la base de datos recogiendo cada registro,de datos del disco, calcula el promedio y muestra el resultado en la pantalla del terminal. Tanto el procesamiento de la aplicacin como el de la base de datos tienen lugar en la computadora central, por lo que la ejecucin de este tipo de consulta (y, de hecho, de cualquier tipo de consulta) resulta muy eficiente. El inconveniente de la arquitectura centralizada es la posibilidad de ampliacin. Segn se agregan usuarios, cada uno de ellos aade carga de trabajo de procesamiento de la aplicacin al sistema. Como el sistema es compartido, cada usuario experimenta un rendimiento deteriorado a medida que el sistema se va cargando.
Arquitectura del servidor de archivos
,.
-1
La introduccin de las computadoras personales y de las redes derrea local llev al desarrollo de la arquitectura del servidor de archivos, .que puede verse en la Figura 3.3. En esta arquitectura, una aplicacin que se ejecute.en una computadora personal puede tener acceso de manera transparente,a los ,datos ubicados en un servidor de archivos, que almacena los archivos compartidos. Cuando una aplica-
Arquitectura centralizada
La Figura 3.2 muestra la arquitectura tradicionl de las bases de datos utilizada por DB2, SQUDS, y las bases de datos originales de minicomputadoras como
_1 :
Servidor de archivos
Base
Gran sistema Pulsaciones---+ , - - - - - - , - - - - - - , SoticitudesL_,_-.d de E/S de disco ~ aloques de disco
\~
de datos y archivos ompartido
,;~. :'
\~
Aplicacin
+- Caracteres L
----'
Figura 3.3. Figura 3.2. Gestin de bases de datos en una 'arquitectura centralizada.
La gestin de las bases-de datos en una arquitectura de servidor de archivos.
40
Captulo 3: SaL en perspectiva
41
cin de una computadora personal solicita Jos datos de un archivo compartido, el software de red recupera del servidor de manera automtica el bloque solicitado del archivo. Las primeras bases de dalos de computadoras personales, como dBASE y, ms tarde, Microsoft Access. albergaban este enfoque de servidor de archivos, en el que cada computadora personal ejecutaba su propia copia del software de SGBD. Para las consultas tpicas que slo recuperan una fila o unas pocas filas de la base de datos, esta arquitectura proporciona un rendimiento excelente, porque cada usuario tiene toda la polencia de una computadora personal que ejecuta su propia copia del SGBD. No obstante, considrese la consulta formulada en el ejemplo anterior. Como la consulta exige una bsqueda secuencial de la base de datos, el SGBD solicita de la base de datos de manera repetida bloques de datos, que se ubican fsicamente al otro lado de la red, en el servidor. Finalmente se solicitarn todos losbloques del archivo y enviados por la red. Obviamente, esta arquitectura produce un trfico de red muy intenso y un bajo rendimiento para las consultas de este tipo.
Arquitectura cliente/servidor
La Figura 3.4 muestra la siguiente etapa de la evolucin de las bases de datos de red -la arquitectura de bases de datos cliente/servidor-o En este esquema las computadoras personales se combinan en una red de rea local con un servidor de bases de datos que almacena las bases de datos compartidas. Las funciones del SGBD se dividen en dos partes. La parte visible para el usuario de las bases de datos, como las herramientas para consultas interactivas, los redactores de infor-
\;---.
~
Servidor de bases de datos
,------
\;---,
Figura 3.4.
~.9
pe
Il:'~.
-'\;---,
La gestin de bases de datos en una arquitectura cliente/servidor.
mes y los programas de aplicaciones, se ejecuta en la computadora personal. El motor de bases de datos subyacente que almacena y gestiona los datos se ejecuta en el servidor. A medida que la arquitectura cliente/servidor creci en popularidad en los aos noventa, SQL se convirti en el lenguaje de bases de datos estndar para la comunicacin entre las herramientas visibles para el usuario y el motor subyacente en esta arquitectura. Considrese una vez ms la consulta que solicita el tamao promedio de los pedidos. En la arquitectura cliente/servidor la consulta viaja por la red hasta el servidor de bases de datos en forma de solicitud SQL. El motor de bases de datos del servidor procesa la solicitud y explora la base de datos, que tambin reside en el servidor. Cuando se ha calculado el resultado, el motor de bases de datos lo devuelve por la red en forma de una nica respuesta a la solicitud inicial, y la aplicacin visible para el usuario lo muestra en la pantalla de la computadora personal. La arquitectura cliente/servidor reduce el trfico de red y divide la carga de trabajo de la base de datos. Las funciones intensivas del usuario, como el manejo de la entrada y exhibicin de los datos, se concentran en la computadora personal del usuario. Las funciones intensivas de datos, como la E/S de archivos y el procesamiento de consultas, se concentran en el servidor de bases de datos. Y, 10 que es ms importante, el lenguaje SQL proporciona una interfaz bien definida entre los sistemas visibles al usuario y los sistemas subyacentes, comunicando las solicitudes de acceso a la base de datos de manera eficiente. A mediados de los aos noventa, estas ventajas hicieron de la arquitectura cliente/servidor el esquema ms popular para la implementacin de nuevas aplicaciones. Todos los productos SGBD ms populares -Gracle, Informix, Sybase, SQL Server, DB2 y muchos ms- ofrecan posibilidades de cliente/servidor. La industria de las bases de datos creci para incluir muchas empresas que ofrecan herramientas para la creacin de aplicaciones cliente/servidor. Algunas provenan de las propias empresas de bases de datos; otras procedan de empresas independientes. Al igual que las dems arquitecturas, la arquitectura cliente/servidor presentaba sus inconvenientes. El principal era el problema de la gestin del software de las aplicaciones, que ahora se hallaba distribuido entre centenares o millares de computadoras personales de sobremesa en lugar de ejecutarse en una minicomputadora O un gran sistema central. Para actualizar un programa de aplicacin de una gran empresa, el departamento de sistemas informticos tena que actualizar millares de sistemas de computadoras personales, uno a uno. La situacin era an peor si haba que sincronizar las modificaciones del programa de aplicacin con modificaciones en otras aplicaciones, o con el propio sistema SGBD. Adems, con las computadoras personales en las mesas de los usuarios, stos tendan a aadir nuevo software personal propio o a modificar la configuracin de sus sistemas. Estas modificaciones solan transtornar el funcionamiento de las aplicaciones ya existentes, lo que incrementaba la carga de trabajo del soporte tcnico. Las empresas desarrollaron estrategias para solucionar estos problemas, pero a fines de los aos noventa haba una creciente preocupacin sobre la gestionabilidad de las aplicaciones cliente/servidor en las grandes redes distribuidas de computadoras personales.
1-
42
Captulo 3: SOL en perspec.tilt8
43
Arquitectura multicapa
Con la -implantacin de Internet y, especialmente, de World Wide Web, la arquitectura de las bases de datos de red dio otro paso en su evolucin. Al principio la web se utilizaba para tener acceso a documentos estticos (explorarlos), y evolucion fuera del mundo de las bases de datos. Pero, cuando el empleo de los exploradores web se hizo ms amplio, no pas mucho tiempo antes de que las empresas pensaran en utilizarla como una manera sencilla de proporcionar acceso tambin a las bases de datos empresariales. Por ejemplo, supngase que una empresa empieza utilizando la web para proporcionar informacin de sus productos a los clientes poniendo a su disposicin en su sitio web descripciones de los productos y grficos. El siguiente paso natural era dar a los clientes acceso a la informacin sobre la disponibilidad de los productos en cada momento mediante la misma interfaz del explorador web. Esto exige conectar el servidor web con el sistema de bases de datos que almacena los niveles de inventario actuales (en perpetuo cambio) de los productos. Los mtodos utilizados para conectar los servidores web con los sistemas SOBD evolucionaron rpidamente entre fines de los aos noventa y comienzos de este siglo, y han convergido en la arquitectura de tres capas que puede verse en la Figura 3.5. La interfaz de usuario es un explorador web que se ejecuta en una computadora personal o algn otro dispositivo cliente ligero en la capa visible para el usuario. Se comunica con un servidor web en la capa intermedia. Cuando la solicitud del usuario es, por algn motivo, ms compleja que una mera pgina web, el servidor web transfiere la solicitud a un servidor de aplicaciones, cuyo papel es manejar la lgica empresarial necesaria para procesarla ~solicitud, A menudo la solicitud implica el acceso a una aplicacin ya existente (heredada) que se ejecuta en un gran sistema o 'a una base de datos empresariaL Estos sistemas se ejecutan en la capa subyacente de la arquitectura. Al igual que con la arquitectura cliente/servidor, SQL se ha establecido firmemente como el lenguaje de bases de datos estndar para la comunicacin entre el servidor de aplicaciones y las bases de datos subyacentes. Todos los productos de los servidores de aplicaciones distribuidos en paquetes proporcionan un API basado en SQL al que se puede llamar para 'acceso a las bases de datos. Como en el mercado de servidoresde aplicaciones se ha convergido alrededor del estndar Edicin empresarial Java2 (Java2 Enterprise Edition, J2EE), la conectividad Java para bases de datos (Java DataBase Connectivity, JDBe) se ha implantado como el API estndar para el acceso de los servidores de aplicaciones a las bases de datos.
1
e
ro
U
Gran sistema Sistema
"
~
Base de datos
SGSD
OLTP
heredado
~ u
. s ro
'~
'O E
Pginas web estticas
Servidor web Software del servidor web
Servidor de aplicaciones Servidor de' aplicaciones (lgica empresarial)
, ,
~ Q
o;
Explorador web
ro :
", ".
ro Q ro
.,~
.~-.
\'-~
Figura 3.5.
La gestin de bases de datos en una arquitectura de Internet de tres
capas.
infonnticos basados en UNIX. En el mercado de las computadoras personales las bases de datos de SQL en sistemas operativos Windows orientados a servidores estn planteando un serio desafo a la dominacin de UNIX como platafonna de procesamiento de bases de datos, especialmente para las aplicaciones departamentales. SQL est aceptado como tecnologa para el procesamiento en conexin de transacciones (online transaction processing, OLTP), lo que refutan completamente la idea generalizada en los aos ochenta de que las bases de datos relacionales nunca ofreceran un rendimiento lo bastante bueno para las aplicaciones de procesamiento de transacciones. El almacenamiento de datos y las aplicaciones de bs queda de datos basadas en SQL son el estndar para ayudar a las empresas a descubrir patrones de compra de los clientes y ofrecer mejores productos y servicios. En Internet las bases de datos basadas en SQL son el fundamento de productos ms personalizados, y de los servicios de informacin que son una ventaja fundamental del comercio electrnico.
La proliferacin de SaL
Como estndar para el acceso a las bases de datos relacionales, SQL ha tenido una importante repercusin en todas las facetas del mercado informtico. IBM ha adoptado SQL como tecnologa unificadora de las bases de datos para su lnea de productos. Las bases de datos basadas en SQL dominan el mercado de los sistemas
44
45
SOL Y la estrategia de la base de datos unificada de IBM

SQL ha desempeado un papel fundamental como lenguaje comn para acceso a las bases de datos en todas las familias de computadoras de IBM. Originalmente este papel era parte de la estrategia SAA de IBM, que se anunci en marzo de 1987. Aunque los principales objetivos de IBM para SAA no se consiguieron, el papel unificador de SQL se ha vuelto an ms importante con el tiempo. El sistema de bases de datos DB2, la insignia de los SGBD basados ea SQL de IBM, se ejecuta ahora en una amplia gama de sistemas informticos de IBM y de otros fabricantes, entre ellos: Grandes sistemas. DB2 comenz como el portaestandarte de SQL para los grandes sistemas de IBM que ejecutaban MVS, y actualmente ha sustituido a SQLlDS como sistema relacional para los sistemas operalivos para gran~ des sistemas VM y VSE. AS/400. Esta implementacin de SQL se ejecuta sobre la familia de sistemas de tamao mediano para empresas de IBM, dirigidos a las pequeas y medianas empresas y a aplicaciones de servidores. Servidores de arquitectura potente. DB2 se ejecuta bajo el sistema operativo UNIX en la familia de estaciones de trabajo y de servidores basados en RISC de IBM, y como plataforma de servidores de bases de datos de UNIX de IBM. Otras plataformas UNIX. IBM soporta DB2 ea plataformas basadas en UNIX de Sun Microsystems y de Hewleu-Packard, los dos principales fabricantes de sistemas UNIX, y en estaciones basadas en UNIX de Silicon Graphics. Windows. Una versin de DB2 para servidor de red de rea local de computadoras personales compite con Microsoft SQL Server, Oracle y otros productos en los servidores de bases de datos basados en Windows.
neral sustituy a sus bases de datos anteriores como herramienta estratgica de gestin de datos. Adems, muchos de los fabricantes de minicomputadoras reven dieron bases de datos relacionales de los fabricantes independientes de software de bases de datos. Estos esfuerzos ayudaron a establecer SQL como una teenoto ga importante para los sistemas informticos de gama media. A mediados de los aos noventa, los produclOS SQL de los fabricantes de SQL haban desaparecido en su mayor parte, derrotados en el mercado por el software multiplataforma de Oracle, Inforrnix, Sybase y Q(fOS fabricantes. En lnea con esta tendencia, la imp0rlancia de los sistemas operativos propietarios de las minicomputadoras tambin disminuy, suslituidos por el empleo generalizado de UNIX en los sistemas de gama media. El anterior mercado de SQL para minicomputadoras se ha convenido de manera efecliva en el mercado actual de servidores de bases de datos basados en UNIX basados en SQL.
SOL en los sistemas basados en UNIX

SQL se ha establecido firmemente como la solucin de gestin de datos predilecta para los sistemas informticos basados en UNIX. Originalmente desarrollado en los BeU Laboratories, UNIX se hizo popular en los aos ochenta del siglo pasado como sistema operativo estndar independiente del fabricante. Se ejecuta en una amplia gama de sistemas informticos, desde estaciones de trabajo a grandes sistemas, y se ha transformado en el sistema operativo estndar para los sistemas servidores de alta gama, incluidos los servidores de bases de datos. A principios de los aos ochenta del siglo pasado ya se dispona de cuatro bases de datos principales para los sistemas UNIX. Dos de ellas, Ingres y Oracle, eran versiones UNIX de los productos que se ejecutaban en las minicomputadoras propietarias de DEC. Las otras dos, Informix y Unify, se escribieron especficamente para UNIX. Ninguna de ellas ofreca originalmente soporte para SQL, pero hacia 1985 Unify ofreci un lenguaje de consultas SQL e Informix se haba vuelta a escribir como Informix-SQL, con soporte integral de SQL. Hoy en da los productos SOBD de Oracle, DB2, Informix y Sybase dominan el mercado de bases de datos basadas en UNIX y estn disponibles en todas las plataformas principales de servidores UNIX. Los servidores de bases de datos basados en UNIX son un componente habitual tanto de la arquitectura cliente/servidor como de la arquitectura de Internet de tres capas. La bsqueda constante de mayor rendimiento de las bases de datos de SQL ha generado algunas de las tendencias ms importantes en el hardware de los sistemas UNIX. Entre ellas figuran la aparicin del multiprocesamiento simtrico (symmelric multiprocessing. SMP) como arquitectura habitual de los servidores y el empleo de tecnologa RAID (Redundan! Array ollndependent Disks, array redundante de discos independientes) para incrementar el rendimiento de E/S.
SOL en las minicomputadoras

Las minicomputadoras fueron uno de los ms frtiles mercados. de los primeros tiempos para los sistemas de bases de datos basados en SQL. Tanto Gracle como Ingres se comercializaron originalmente para los sistemas de minicomputadoras VAXlVMS de Digital. Ambos productos se han pasado desde entonces a otras muchas plataformas. Sybase, un sistema de bases de datos posterior especializado en el procesamiento en lnea de transacciones, tambin consider VAX una de sus principales plataformas. A lo largo de los aos ochenta, los fabricantes de minicomputadoras tambin desarrollaron sus propias bases de datos propietarias que utilizaban SQL. Digital consider tan importantes las bases de datos relacionales que incluy una versin en tiempo de ejecucin de su base de datos RdbNMS con cada sistema VAXI VMS. Hewlett-:Packard ofreci Allbase, una base de datos que albergaba su dialecto HPSQL y una interfaz no relacional. La base de datos DGISQL de Data Ge-
SOL en computadoras personales

Las bases de datos han sido populares en las computadoras personales desde los primeros das del PC de IBM. El producto dBASE de Ashton-Tate alcanz una
46
47
base instalada de ms de un milln de computadoras personales basadas en MSDOS. Aunque estas primeras bases de datos para computadoras personales solan presentar los datos de forma tabular, carecan de toda la potencia de los SGBD relacionales y de un lenguaje para bases de datos relacionales como SQL. Las primeras bases de datos para computadoras personales basadas en SQL fueron versiones de productos populares para minicomputadoras que apenas caban en las computadoras personales. Por ejemplo, Professional Gracle for the IBM pe, introducido en 1984, necesitaba dos megabytes de memoria -muy por encima de la tpica configuracin de 640KB de las computadoras personales de aquel entonces. El verdadero impaclO de SQL en las computadoras personales comenz con el anuncio de OS/2 por mM y Microsoft en abril de 1987. Adems del producto OS/2 estndar, mM anunci un OS/2 Extended Edition (OS/2 EE) propietario con una base de datos SQL incorporada y soporte de comunicaciones. Con esta introduccin mM volvi a indicar su fuerte compromiso con SQL, diciendo en efecto que SQL era tan importante que formaba parte del sistema operativo de la computadora. . . OS/2 Extended Edition plante un problema a Microsoft. Como desarrollador y distribuidor del OS/2 estndar a otros fabricantes de computadoras personales, Microsoft necesitaba una alternativa a Extended Edition. Microsoft respondi obteniendo la licencia del SGBD de Sybase, que se haba desarrollado para VAX, y comenz a adaptarlo a OS/2. En enero de 1988, en un movimiento sorpresa, Microsoft y Ashton-Tate (el lder en bases de datos para computadoras personales de la poca con su producto dBASE) anunciaron que venderan conjuntamente el producto basado en OS/2 resultante, rebautizado SQL Server. Microsoft vendera SQL Server con OS/2 a los fabricantes de c;omputadoras; Ashton-Tate vendera el producto en el canal detallista a los usuarios de computadoras personales. En septiembre de 1989. Lotus Development (el otro de los tres grandes del software para computadoras personal~s de la poca) aadi su apoyo a SQL Server invirtiendo en Sybase. Ms adelante, ese mismo ao, Ashton-Tate renunci a sus derechos exclusivos de distribucin minorista y vendi su.inversi6n a Lotus. SQL Server para OS/2 slo obtuvo un xito limitado. Pero, en el tpico estilo de Microsoft, Microsoft sigui invirtiendo mucho en el desarrollo de SQL Server y lo adapt a su sistema operativo Windows NT. Por un tiempo, Microsoft y Sybase siguieron siendo socios, con Sybase centrada en los mercados de las minicomputadoras y de los servidores basados en UNIX y con Microsoft centrado en las redes de:rea local de computadoras personales y en Windows NT. A medida que los sistemas Windows NT y UNIX se iban volviendo competidores como plataformas de sistemas operativos para servidores de bases de datos, ]a relacin se volvi menos cooperativa y ms competitiva. Finalmente, Sybase y Microsoft se fueron cada uno por su lado. La ascendencia comn de los productos SQL de Sybase y de Microsoft todava puede verse en posibilidades de los productos y en algunas extensiones comunes de SQL (por ejemplo, los procedimientos almacenados), pero las lneas de productos ya han divergido de manera significativa. Hoy en da SQL Server es un importante sistema de bases de datos en los servidores basado$ en Windows. SQL Server 7, que se distribuy a finales de 1998, supuso un impulso importante en el tamao y en ]a escala de las aplicaciones de
bases de datos que poda soportar SQL Server. SQL Server 2000, que se ejecUla en Windows 2000, proporcion otro impulso importante. SQL Server est destinado a seguir teniendo un papel importante a medida que Microsof( vaya desplegando su familia de produc(os para servidores .NET. Adems del impacto de SQL Server, la disponibilidad de Oracle y, en menor grado, de nformix, DB2 y otros productos SGBD habituales ha ayudado a los servidores basados en Windows a ir erosionando poco a poco el dominio de UNIX como pla(aforma para servidores de bases de datos. Aunque UNIX sigue dominando las instalaciones de servidores de bases . de datos de mayor (amao, las configuraciones de los servidores del sistema operativo Windows y los sistemas de arquitecrura Intel en los que se ejecutan han logrado credibilidad en el mercado de gama media.
SOL Y el procesamiento de transacciones

SQL y las bases de datos relacionales tuvieron originalmente muy poca repercusin en las aplicaciones de procesamiento en conexin de transacciones (online transaction processing, LTP). Con su nfasis en las consultas, las bases de datos relacionales quedaron confinadas al soporte de decisiones y a las aplicaciones con conexin de escaso volumen, donde su rendimiento ms lento no supona un'inconveniente. Para las aplicaciones OLTP, en las que centenares de usuarios necesitaban acceso con conexin a los datos y tiempos de respuesta inferiores al segundo, el Sistema de gestin de la informacin (lnformation Management Syslem, IMS) no relacional reinaba como el SGBD dominante. En 1986 un nuevo fabricante de SGBD, Sybase, introdujo una nueva base de datos, basada en SQL, diseada especialmente para las aplicaciones OLTP. El SGBD de Sybase se ejecutaba en minicomputadoras VAXNMS y estaciones de trabajo Sun, y se centraba en el mximo rendimiento con conexin. OracIe Corporation y Relational Technology comunicaron poco despus que tambin ellos ofreceran versiones OLTP de sus populares sistemas de bases de datos Oracle e Ingres. En el mercado UNIX, Informix anunci una versin OLTP de su SGBD, denominada Informix-Turbo. En 1988 IBM se subi al tren del OLTP relacional con DB2 Version 2, para el que las pruebas de rendimiento mostraban que la nueva versin operaba por encima de las doscientas cincuenta transacciones por segundo en los grandes sistemas. IBM proclam que el rendimiento de DB2 ya era adecuado salvo para las aplicaciones OLTP ms exigentes, y anim a los clientes a considerarlo una seria alternativa a IMS. Las pruebas de rendimiento de OLTP se han convertido hoy en da en una herramienta de ventas estndar para las bases de datos relacionales, pese a las serias dudas sobre la precisin con que estas pruebas miden realmente el rendimiento en las aplicaciones reales. La idoneidad de SQL para OLTP mejor espectacularmente a lo largo de los aos noventa, en que los avances en la tecnologa relacional y un hardware informtico ms potente llevaron a velocidades de transaccin cada vez ms altas. Los fabricantes de SGBD comenzaron a promover sus productos de acuerdo con su rendiiento OLTP y, por unos aos, la publicidad de las bases de datos se centr
48
Captulo 3: SQL en perspectiva
49
casi en su totalidad en estas guerras de pruebas de rendimiento. Una organizacin independiente de los fabricantes, el Consejo de Procesamiento de Transacciones (Transaction Processing Council), entr en la guerra de las pruebas de rendimien to con una serie de pruebas de rendimiento independientes del fabricante (TPC-A, TPC-B y TPC-C), que slo sirvieron para intensificar la obsesin de los fabricantes por el rendimiento. A fines de los aos noventa, las bases de datos relacionales, basadas en SQL, en servidores de bases de datos de gama alta, basados en UNIX, superaron la marca de las mil transacciones por segundo. Los sistemas cliente/servidor que utilizan bases de datos SQL se han convertido en la arquitectura aceptada para la implementacin de aplicaciones OLTP. Desde una situacin de inadecuado para OLTP , SQL ha crecido hasta ser el fundamento estndar de la industria para la creacin
Este fenmeno, as como el soporte popular de las computadoras personales una dcada antes, estimul el rpido crecimiento del segmento de bases de datos para trabajo en grupo. Hoy en da SQL est bien establecido como estndar para las bases de datos para trabajo en grupo. A SQL Server de Microsoft se han unido Oracle, lnformix, Sybase, DB2 y otras muchas marcas de SGBD que se ejecutan en las plataformas de los servidores Windows. Las bases de datos de SQL basadas en Windows son el segundo mayor segmento del mercado de SGBD, y el que crece ms rpidamente. Desde 'este slido dominio del segmento del trabajo en grupo, los sistemas servidores basados en Windows estn lanzando un continuo asalto a las aplicaciones de bases de datos de tipo empresarial, socavando de manera lenta pero segura las implantaciones de bases de datos de gama baja basadas en UNIX.
de aplicaciones OLTP.
SOL Y los almacenes de datos SOL Y las bases de datos para trabajo en grupo
El espectacular crecimiento de las redes de rea local para computadoras personales a 10 largo de los aos ochenta y noventa supuso una nueva oportunidad para la gestin de bases de datos departamental o para trabajo en grupo. Los sistemas de bases de datos originales dirigidos a este segmento del mercado se ejecutaban en el sistema operativo OS/2 de IBM. De hecho, SQL Server, hoy en da una parte fundamental de la estrategia Windows de Microsoft, hizo su debut originalmente como producto para bases de datos de OS/2. A mediados de los aos noventa, Novell tambin hizo un intenso esfue~o para hacer de su sistema operativo NetWare una plataforma atractiva para servidores de bases de datos para trabajo en grupo. Desde los primeros das de las redes de rea local de computadoras personales, NetWare se haba establecido como el sistema operativo de red dominante para los servidores de 'archivos y de impresin. Mediante acuerdos con Oracle y con otras empresas, Novell intent9 extender tambin este liderazgo a los servidores de bases de datos para trabajo en grupo. La llegada de Windows NT al mundo de la informtica de trabajo en grupo fue el catalizador que hizo que despegara realmente el mercado de las bases de datos para trabajo en grupo. Aunque NetWare ofreca una clara ventaja en rendimiento frente a NT como servidor de archivos para trabajo en grupo, NT tena una arquitectura ms slida y de propsito general, ms similar a la de los sistemas operativos para minicomputadoras. Microsoft vendi con xito NT como una plataforma ms atractiva para la ejecucin de aplicaciones para trabajo en grupo (como servidor de aplicaciones) y de bases de datos para trabajo en grupo. El mismo producto de Microsoft, SQL Server, se anunciaba (y, a menudo, se venda) con NT como una plataforma para bases de datos para trabajo en grupo muy integrada. Los departamentos empresariales de sistemas informticos fueron en principio muy cautos respecto al empleo de tecnologa relativamente nueva y sin .probar, pero la combinacin NT/SQL Server permiti a los departamentos y a ejecutivos ajenos a los sistemas informticos emprender por su cuenta proyectos del nivel de trabajo en grupo de menor escala, sin la ayuda de los sistemas informticos de sus empresas. Durante varios aos, el esfuerzo para hacer de SQL una tecnologa viable para las aplicaciones OLTP apart la 'atencin de los puntos fuertes originales de las bases de datos relacionales en procesamiento de consultas y en toma de decisiones. Las prue-:' bas de rendimiento y la competencia entre las principales marcas de SGBD se centr en las transacciones sencillas, como el aadido de un nuevo pedido a la base de datos o la determinacin del saldo de la cuenta de un cliente. Debido a la potencia del modelo de bases de datos relacionales, las bases de datos que utilizaban las empresas para tratar las operaciones de negocios coti.dianas tambin podan utilizarse para analizar las cantidades crecientes de datos que se estaban acumulando. Un tema habitual de las conferencias y los discursos de las ferias para gerentes de sistemas informticos era que los datos acumulados de cada empresa (almacenados en bases de datos de SQL, por supuesto) deberan tratarse como un activo valioso y emplearse para ayudar a mejorar la calidad de la toma de decisiones empresariales. Aunque las bases ,de datos relacionales podan, en teora, llevar a cabo fcilmente tanto aplicaciones de OLTP como de toma de decisiones, surgieron algunos problemas prcticos muy significativos. Las cargas de trabajo de OLTP consisten en muchas transacciones breves con las bases de datos, y el tiempo de respuesta para los usuarios es muy importante. Sin embargo, las consultas de apoyo a las decisiones pueden implicar bsquedas secuenciales de grandes tablas de las bases de datos para responder a preguntas como el tamao promedio de los pedidos por regin de ventas o la comparacin entre las tendencias de inventario entre un ao y el anterior. Estas consultas pueden tardar minutos u horas. Si un analista de la industria intentara ejecutar una de estas consultas en un momento en que los volmenes de transacciones comerciales alcanzaran su mximo, podra ocasionar un grave deterioro en el rendimiento OLTP. Otro problema es que los datos para la respuesta a las preguntas tiles sobre tendencias comerciales suelen estar dispersos en muchas bases de datos diferentes, que suelen implicar a varios fabricantes de SOBD y a diferentes plataformas informticas. El deseo de aprovechar los datos comerciales acumulados, y los problemas prcticos de rendimiento que generaba a las aplicaciones OLTP, llev al concepto
50
51
de almacn de datos, que puede verse en la Figura 3.6. Los datos comerciales se extraen de los sistemas OLTP, se les vuelve a dar formato y se validan segn sea necesario, y se ubican en una base de datos independiente que est dedicada a las consultas para toma de decisiones (el almacn}). La extraccin y transformacin de los datos puede programarse para su procesamiento por lotes fuera de las horas punta. Lo ideal sera que slo se pudieran extraer datos nuevos o modificados, lo que minimizara la cantidad de datos que habra que procesar en el ciclo mensual, semanal o diario de puesta al da del almacn. Con este esquema, las consultas de anlisis comercial que consumen tanto tiempo utilizan el almacn de datos, y no la base.de datos OLTP, como origen de datos. Las bases de datos relacionales basadas en SQL ,eran una opcin clara para el almacenamiento del almacn de datos, debido a su procesamiento flexible de las consultas. Se form una serie de empresas nuevas para crear las herramientas de extraccin y transformacin de datos y de consulta de la base de datos necesarias para el modelo del almacn de datos. Adems, los fabricantes de SGBD comenzaron a centrar su atencin en el tipo de consultas a las bases de datos que los clien-
tes solan ejecutar en los almacenes de datos. Estas consultas solan ser grandes y complejas -como el anlisis de decenas o centenares de millones de recibos de cajas registradoras para buscar patrones de adquisicin-de productos-, y exigan datos de series temporales -por ejemplo, el anlisis de los datos de ventas de productos o de cuotas de mercado a lo largo del tiempo-. Tambin tendan a exigir resmenes estadsticos de los datos ~ventas totales, volumen promedio de los pedidos, crecimiento porcentual, etc.-, ms que los propios datos. Para abordar las necesidades especializadas de las aplicaciones de los almacenes de datos (a menudo denominadas Procesamiento en conexin analtico, OnLine Analytical Processing, OLAP), comenzaron a aparecer bases de datos especializadas, Estas bases de datos se optimizaron de diferentes maneras para las cargas de trabajo OLAP. Su rendimiento se ajust para el acceso a consultas complejas slo de lectura. Asuman funciones estadsticas y otras funciones de tratamiento de datos avanzadas. como el procesamiento incorporado de series temporales, as como el clculo previo de los datos .estadsticos de las bases de datos, de modo que la recuperacin de los promedios y de los totales pudiera ser muchsimo ms rpida. Algunas de estas bases de datos especializadas no utili-
zaban SQL, pero muchas s lo hacan (lo que llev al trmino adjunto ROLAP,
.
~
'E
o u o
o
Servidor de bases de_datos LAN
Servidor de bases de datos Unix
Gran sistema
Base de Base Base Aplicacin datos ...... SGBO Ide datos del+SGBO de datos del+- de negocio de clientes l...'::=:s:;;='J11 productos ~=+=J inventarin heredada
l.
de Procesamiento analtico relacional en conexin (Relational OnLine Analytic Processing). Al igual que en tantos segmentos del mercado de bases de datos, las ventajas de SQL como estndar demostraron que eran una fuerza importante. El almacenamiento de datos se ha convertido en un segmento de ms de mil millones de euros anuales del~mercado de bases de datos, .y las bases de datos' basadas en SQL se han establecido con firmeza como la tecnologa habitual para la creacin de almacenes de datos.
, .>
.~
I I
/
~
SOL Y las aplicaciones distribuidas en Internet

A fines de los aos noventa, World Wide Web y la posibilidad de exploracin
web que permiti fueron la. fuerza motriz del crecimiento de Internet. Con su atencin en la entrega de contenido en forma de texto y de grficos. los primeros usos de la web tuvieron poco que ver con la gestin de datos. Sin embargo, hacia mediados de los aos noventa gran parte del contenido ofrecido en los sitios web empresariales tena su orige-Q. en bases de datos empresariales basadas en SQL. Por ejemplo. en e! sitio web comercial de un detallista, las pginas que contienen la informacin sobre los productos disponibles para la venta, sus precios, la disponibilidad de los productos, las ofertas esp~ciales y.dems suelen crearse a peticin del usuario, con base en los datos rec~perados de una base de datos de SQL. La inmensa mayora de las pginas mostradas por los sitios de subastas en lnea o por los sitios de las agencias de viajes en lnea se basan, de manera anloga, en los datos recuperados de bases de datos de SQL, transformados al formato de pginas HTML de la web. En el sentido inverso, los datos introducidos por el usuario en los formularios de las pginas del explorador casi siempre se capturan en bases de datos de SQL que forman parte de la arquitectura del sitio web.
Herramientas de extraccin y formato de datos
.
E
." ."
o
" '"
l.~
g
-
rl....
Herramientas de anlisis de datos y elaboracin de informes
Solicitud~r;:=t==;-l
Sal
SGSD +-Oatos
Almacn, de datos -'
Figura 3.&.
El concepto de almacn de datos.
IJ.
52
A comienzos de este siglo, la atencin de la i.ndustria haba pasado a la siguiente fase de internet y al papel que pueden desempear las tecnologas de inter net en la conexin de las aplicaciones de las computadoras entre s. Estas arquitecturas de aplicaciones distribuidas recibieron una amplia cobertura de la prensa especializada bajo la denominacin de servicios web. De acuerdo .con la vieja costumbre de la industria informtica, aparecieron bandos enfrentados que defendan diferentes conjuntos de estndares y de lenguajes para implementarlos: un bando liderado por Microsoft bajo la cobertura .NET y un bando rival centrado eh Java y los servidores de aplicaciones basados en J2EE. Ambas arquitecturas otorgaron un papel clave a XML, un estndar para el intercambio de datos estructurados, como los datos que residen en las bases de datos de SQL. En respuesta a la atencin prestada por la industria a los servicios web se ha anunciado gran cantidad de productos que enlazan los mensajes con formato XML y las bases de datos basadas en SQL. Los nuevos fabricantes de bases de datos y algunos de los vendedores de bases de datos orientadas a objetos han anunciado productos de bases de datos basados en XML, argumentando que ofrecen una contrapartida ideal y nativa para el intercambio de datos con formato XML por Internet. Los fabricantes establecidos de bases de datos relacionales han respondido con sus propias iniciativas XML, aadiendo a sus productos posibilidades de entrada y salida XML y, en algunos casos, soporte de los tipos de datos XML. La interaccin entre XML y SQL es una de las reas ms activas en la gestin de datqs hoy en da, y la actividad en esta rea mantendr a SQL en el centro de atencin de la industria hasta bien entrada la primera dcada del siglo.
CAPTULO
Bases de datos relacionales
Resumen
Este captulo ha descrito el desarrollo de SQL y su papel como lenguaje estndar para la gestin de bases de datos relacionales: SQL fue desarrollado originalmente por investigadores de lBM, y el fuerte soporte de IBM es una razn fundamental de su xito. Hay estndares oficiales ANSIJISO de SQL y otros varios estndares de SQL, cada uno de ellos ligeramente diferente de los estndares ANSI/ISO. Pese a la existencia de estndares, hay muchas pequeas variaciones entre los dialectos comerciales de SQL; no hay dos variedades de SQL exactamente iguales. .. . SQL se ha convertido en el lenguaje estndar para la gestin de bases de datos en una amplia gama de sistemas informticos y reas de aplicaciones, incluidos los grandes sistemas, las estaciones de trabajo, las computadoras personales, los sistemas OLTP, los sistemas cliente/servidor, los almacenes de datos e Internet.
Los sistemas gestores de bases de datos organizan y estructuran los datos de modo que los usuarios y los programas de aplicacin puedan recuperarlos y manipularlos. Las estructuras de los datos y las tcnicas de acceso proporcionadas por cada SOBn son su modelo de datos. El modelo de datos determina tanto la personalidad del SOBn como las aplicaciones para las que se halla especialmente bien adaptado. SQL es un lenguaje de bases de datos para bases de datos relacionales que utiliza el modelo relacional de datos. Qu es exactamente una base de datos relacional? Cmo se almacenan los datos en las bases de datos relacionales? En qu se diferencian las bases de datos relacionales de tecnologas anteriores, como las bases de datos jerrquicas y las bases de datos de red? Cules son las ventajas e inconvenientes del modelo relacional? Este captulo describe el modelo relacional de datos adoptado por SQL y lo compara con estrategias anteriores para la organizacin de las bases de datos.
Los primeros modelos de datos

Cuando la gestin de bases de datos se extendi en los aos setenta y ochenta, aparecieron unos cuantos modelos de datos que se popularizaron. Cada uno de estos modelos de datos primigenios tena ventajas e inconvenientes que desempearon papeles fundamentales en el desarrollo del modelo relacional de datos. En muchos aspectos, el modelo relacional de datos represent un intento de racionalizar y simplificar los primeros modelos de datos. Para comprender el papel y la contribucin de SQL y del modelo relacional, resulta til examinar brevemente algunos modelos de datos que precedieron al desarrollo de SQL.
Sistemas gestores de archivos

Antes de la introduccin de los sistemas gestores de bases de datos, todos los datos almacenados de manera permanente en los sistemas informticos, como los
53
...
54
Captulo 4: Bases de daros relacionales
55
registros de las nminas y de la contabilidad, se guardaban en archivos individuales. Un sistema gestor de archivos, generalmente proporcionado por el fabricante la computadora como parte de su sistema operativo, realizaba el seguimiento del nombre"y d~ la ubicacin de los archivo~. El sistema gestor de archivos bsicamente careca de modelo de datos; no saba nada del contenido interno de los archivos. Para el sistema gestor de datos, un archivo que contuviera un documento d~ un procesador de textos y uo'archivo que contuviera datos de una nmina parecan iguales. El conocimiento sobre el contenido de los archivos -los datos que contienen .y el modo en que esos datos estn organizados- se incorporaba en los programas de aplicacin que utilizaban el archivo, como se muestra en la Figura 4.1. En esta aplicacin para nminas cada uno de los programas de COBOL que procesaban el archivo maestro del empleado contena una descripcin del archivo (file description, FD) que indicaba la disposicin de los datos en el archivo. Si se modificaba la estructura de los datos -por ejemplo, si haba que almacenar un elemento de datos adicional para cada empleado-, haba que modificar cada programa que tuviera accesq al archivo. Como el nmero de archivos y de programas creca con el tiempo, cada vez se dedicaba ms esfuerzo del departamento de procesamiento de datos a mantener las aplicaciones existentes, en lugar de a desarrollar otras nuevas. Los problemas del mantenimiento de grandes sistemas basados en archivos llev, a fines de los aos sesenta, al desarrollo de sistemas gestores de bases de
de
datos. La idea subyacente a estos sistemas era sencilla: sacar de cada .programa la definicin del contenido y la estructura de los archivos y almacenarla, junto con Jos datos, en una base de datos. Al utilizar la informacin de la base de datos, el SOBD que la controlaba podra adoptar un papel mucho ms activo en la gestin de los datos y de las modificaciones de la estructura de la base de datos.
Bases de datos jerrquicas

Una de las aplicaciones ms imponantes de los primeros sistemas gestores de bases de datos era la planificacin de la produccin para las empresas manufactureras. Si un fabricante de automviles decida producir diez mil unidades de un modelo de coche y cinco mil de otro modelo, necesitaba conocer el nmero de piezas que deba encargar a sus proveedores. Para responder a esta pregunta haba que descomponer el producto (coche) en sus partes (motor, carrocera, chasis), que a su vez haba que descomponer en sus componentes (vlvulas, cilindros, bujas), y. as sucesivamente. El manejo de esta lista de componentes, conocida como lista de materiales, era un trabajo hecho a medida para las .computadoras. La lisla de materiales de un producto tiene una estructura jerrquica natural. Para almacenar estos -datos se desarroll el modelo jerrquico de datos; que se muestra en la Figura 4.2. En este modelo cada registro de la base de datos representa un componente concreto. Los registros tienen relaciones padre/hijo, que vinculan cada parte con sus componentes, y as. sucesivamente.
Programa de actualizacin de empleados
FD
I I
I I I
I I I
Programa de informes de empleados
FD
'.
J~
Archivo maestro
emplea~os
I I
I I I
I I I
I
Figura 4.1.
Programa de emisiones de cheques FD I FD I I
Aplicacin para nminas que emplea un sistema gestor de archivos.
Figura 4.2.
Base de datos jerrquica de una lista de materiales.
56
Captulo 4: Bases de datos relacionales
57
Para tener acceso a los datos de la base de dalas un programa, podra llevar a cabo las tareas siguientes: Hallar un componente determinado por su nmero (como pudiera ser la puerta izquierda). Bajar hasta el primer nodo hijo (la manilla de la puerta). Subir hasta su nodo padre (la carrocera). ~overse de lado hasLa el siguiente nodo hijo (la puerta derecha). La recuperacin de los dalOs en las bases de datos jerrquicas exiga, por tanto, navegar por los registros, subiendo, bajando y desplazndose lateralmente registro a registro. Unos de los sistemas gestores de bases de datos jerrquicas ms populares era el Sistema de gestin de la informacin (Information Management System, IMS) de IBM, que se introdujo por primera vez en 1968. Las ventajas de IMS y de su modelo jerrquico son las siguientes: Estructura sencilla. La organizacin de las bases de datos de IMS era fcil de comprender. La jerarqua de la base de datos era anloga al organigrama de una empresa o a un rbol genealgico. Organizacin padre/hijo. Las bases de datos de IMS eran excelentes para la representacin de las relaciones padre/hijo, como A es parte de B o A
datos de procesamiento de pedidos, por ejemplo, cada pedido puede formar parte de tres relaciones padre/hijo diferentes, que vinculan el pedido al cliente que lo ha formulado. al vendedor que )0 ha tramitado y al producto solicitado, como puede verse en la Figura 4.3. La estructura de este tipo de dalos simplemente no encajaba en la estricta jerarqua de IMS. Para poder trabajar con aplicaciones como las de procesamiento de pedidos, se desarroll un nuevo modelo de datos de red. El modelo de dalOs de red ampli el modelo jerrquico permitiendo que cada registro formara parte de varias relaciones padre/hijo, como puede verse en la Figura 4.4. Estas relaciones se denominaron conjuntos en el modelo de red. En 1971 la Conferencia sobre lenguajes de sistemas de datos (Conference on Data Systems Languages) public un estndar oficial para bases de datos de red, que se conoci como el modelo CODASYL. IBM no desarroll nunca un SGBD de red propio, y prefiri ampliar IMS a lo largo de los aos. Pero, durante los aos setenta, las empresas independientes de software se apresuraron a adoptar el modelo de red, creando
productos como IDMS de Cullinet, Total de Cincom y el SGBD Adabas, que se

hizo muy popular. Para los programadores, tener acceso a las bases de datos de red era muy parecido a tener acceso a las bases de datos jerrquicas. Los programas de aplicacin podan hacer lo siguiente: Hallar un registro padre concreto mediante su clave (que puede ser el nmero de cliente). Bajar hasta el primer hijo de un conjunto determinado (el primer pedido rea izado por el cliente).
es propiedad de B.
Rendimiento. IMS almacenaba las relaciones padrelhijo en forma de punteros fsicos de un registro de datos a otro, por lo que el movimiento por la base de datos era rpido. Como la estructura era sencilla, IMS poda situar los registros padres e hijos cercanos unos de otros en el disco, lo que minimizaba las operaciones de entrada y salida de disco. IMS sigue siendo un SGBD muy utilizado en los grandes sistemas de IBM. Su rendimiento bruto lo convierte ela base de datos preferida para las aplicaciones de elevado volumen de procesamiento de transacciones, como el procesamiento de las transacciones de los cajeros automticos de los bancos, comprobacin de los nmeros de las tarjetas de crdito y seguimiento de la entrega de paquetera urgente. Aunque el rendimiento de las bases de datos relacionales ha mejorado espectacularmente en la ltima dcada, los requisitos de rendimiento de las aplicaciones de este tipo tambin se han incrementado, por lo que IMS sigue teniendo un papel que desempear. Adems, el gran nmero de datos empresariales almacenado en bases de datos de IMS garantiza que el empleo de IMS se prolongue hasta mucho despus de que las bases de datos relacionales hayan eliminado la barrera del rendimiento.
Clientes
Vendedores
Productos
Bases de datos en red

La sencilla estructura de las bases de datos jerrquicas se volvi un inconveniente cuando los datos pasaron a tener una estructura ms compleja. En una base de
Figura 4.3.
Pedidos
Relaciones padre/hijo mltiples.
58
59
Conjunto
Figura 4.4.
Una base de datos de red (CODASYL) para el procesamiento de pedidos.
dones de conjunto y la estructura de los registros con antelacin. La modificacin de la estructura de la base de datos sola exigir la reconstruccin de toda la base de datos. Tanto las bases de datos jerrquicas como las de red eran herramientas para los programadores. Para responder a una pregunta, como el producto ms solicitado por Acme, el programador tena que escribir un programa que se desplazara por la base de datos. La pila de solicitudes atrasadas de informes personalizados sola extenderse a semanas o meses, y para el momento en que el programa estaba escrito, la informacin que aportaba sola carecer de valor. Los inconvenientes de los modelos jerrquico y de red motivaron un intenso inters en el nuevo modelo relacional de datos cuando el Dr. Codd lo describi por primera vez en 1970. Al principio, el modelo relacional no fue mucho ms que una curiosidad acadmica. Las bases de datos de red siguieron siendo importantes durante los aos setenta y principios de los aos ochenta, especialmente en los sistemas de minicomputadoras, cuya popularidad iba en aumento. Sin embargo, a mediados de los aos ochenta, el modelo relacional se fue imponiendo claramente como la nueva ola en gestin de datos. Para principios de los aos noventa, la importancia de las bases de datos de red se hallaba en franco declive, y hoy en da ya no desempean un papel importante en el mercado de las bases de datos.
Desplazarse lateralmente de un hijo al siguiente del conjunto (el siguiente pedido realizado por el mismo cliente). Subir desde un hijo a su padre en otro conjunto (el vendedor que tramit el pedido). Una vez ms, el programador tena que navegar por la base de datos registro a registro, esta vez especificando la relacin por la que hay que navegar, adems de la direccin. " Las bases de datos de red tenan varias ventajas: Flexibilidad. La existencia de varias relaciones padre/hijo permitan a las bases de datos de red representar los datos que no ten~n una estructura jerrquica sencilla. ; . Estandarizacin. El estndar CODASYL impuls la popularidad del modelo de red. y los fabricantes de minicomputadoras, como-Digital Equipment Corporation y Data General. implementaron bases de datos de red. Rendimiento. Pese a su mayor complejidad. las bases de datos de red presuman de un rendimiento prximo al de las bases de datos jerrquicas. Los conjuntos se representaban como punteros hacia los registros fsicos de los datos y, en algunos sistemas, el administrador de la base de datos poda especificar las agrupaciones de los datos de acuerdo con las relaciones de los conjuntos. Las bases de datos de red tambin tenan sus inconvenientes. Al igual que las bases de datos j-errquicas, resultaban muy rgidas. Haba que especificar las rela-
El modelo relacional de datos

El modelo relacional propuesto por el Dr. Codd era un intento de simplificar la estructura de las bases de datos. Eliminaba de las bases de datos -las estructuras padrelhijo explcitas y, en su lugar, representaba todos los datos de la base de datos como meros valores de filas y columnas en tablas de datos. La Figura 4.5 muestra una versin relacional de la base de datos "de red para el procesamiento de pedidos de la Figura 4.4. Por desgracia, la definicin prctica de lo que es u~ base de d3:~oS relacional se volvi mucho menos rotunda que la definicin matemtica precisa del trabajo de Codd de 1970. Los primeros sistemas gestores relacionales de bases de datos no lograron implementar algunas partes fundamentales del modelo de Codd. A medida que el concepto relacional creca en popularidad, muchas bases de datos que se denominaban relacionales, en realidad, no lo eran. En respuesta a la degradacin del tnnino relacional, el Dr. CocId escribi un artculo en 1985 en el que estableca doce reglas que deba seguir cualquier base de datos que se denominara verdaderamente relacional. Las doce reglas de Codd se han aceptado desde entonces como la definicin de los verdaderos SGBD relacionales. No obstante, resulta ms sencillo comenzar con una definicin menos formal: Una base de datos relacional es una base de datos en la que todos los datos visibles para el usuario estn estrictamente organizados como tablas de valores de datos y en la que todas las operaciones de la base de datos se realizan sobre estas tablas.
60
61
Tabla PRODUCTOS
OESCRIPCION Serie 3. cable

Serie 4, cable Hilo de cobre
PRECIO
107,00 117,00 350,00
STOCK 207
139
Tabla PEDIDOS
_ _PEVlOO PECHA....PWlDO
CLID:TE
2117 2111
u,
112961 113012
17112/1989
llfOllU90 0l/01/1990 10/0211991)
14
112989
113051
2101 2118
112958
12/10/1989
2102
2107 2112 2101 2118
2108
Tabla PEDIDOS NUK PEDIDO 112963 112975 112983 113012 CLIENTE PRODUCTO 41004 2A44G 41004 41003 CANTIDAD
113036 111045 112961 113013 111058 U2997 112983
lO/Olflno 02/02/1990 1111211989 14/01/1990
". '" ". ,U ,,, ". '" U" Haot ", no ". m
m m
~, ~,
..
"
'w~
CAllTlDAD
IKI'ORTE
7 )1.';00,00
2AUI-
4100)
41002
"
,
" ", ",
3.145.00 1.458,00
1.420,00 1.978.00
22.500,00 o
,O'
Acme
JCP S.A.
Acme
JCP S.A.
28 6 6 35
OO
n/ovugo
08/0111990 27112/1989 20/01119'0 24/0211990 12110/1989 22/01/1990 08/01/1990 0210311990 29/01/1990 04/11/19U 12110/1989 15/0211990 10/0211990 0'10111989 27/0211990 25/0111990 10/0211990 31/12/1989 18/02/1990 0210211990
2124 2101 2114 2124 2114 2103 2112 2109 n01 2118 2111 2108 2120 2106 2106
...
Tabla CLIENTES EMPRESA REP CLI 105 LIMITE CREOITO
11302.
113062 112979 113027 113007 1130H 111014 112992 112915 113055 1130U
'" '" '" O" ". '" ", ,U ",
'"
.
~,
2l.UR 41004
10 4S.000,OO 3.216.00 o 652.00 o 1.480,00 o 652,00
~,
41001
,U
(100) 4100.
XK41
'"
"
",
702.00 7.100.00
Acme
JCP S.A.
".
'" '"
'" '" ,O'
4100Z 41002
2.430.00 "615.000.00 4.104.00
,~ ,~
50.000,00 50.000.00
103
'" '" '" OO. ", '" '"

~, ~, ,~
773c 77SC 2A4SC 41002 2"44G UOOx 779c 2At'>C
2 925.00 22 31 350.00 632.00 760.00 2.100.00 150,00 3.750.00 1.a96.00 2.130.00
,~
Figura 4.5.
Una base de datos relacional para el procesamiento de pedidos.
112993 113065 113003 11)049 112981 113057 n30U
no.
2118 2103 2111 211)
Esta definicin est pensada especficamente para excluir estructuras como los punteros incorporados de las bases de datos jerrquicas y de red. Los SOBD relacionales pueden representar las relaciones padrelhijo, pero stas quedan representadas estrictamente por los valores de los datos comenidos en las tablas de la base de datos.
'" '" " ", m U" ", ." " ."

OS' OS'
~,
77,C
", , , " ,
,
4100Y noox
5.625.00 776.00 E 11 27.S00.00 600.00 "5 22.500.00
~,
2"UR
Tabla PRODUCTOS
IDJAB ID_PRODUCTO DESCRIPCION 2A<S 4100 Zftpa~:~
La base de datos de ejemplo

La Figura 4.6 muestra una pequea base de datos relacional para una aplicacin de procesamiento de pedidos. Esta base de datos de ejemplo se usa a lo largo del libro y proporciona la base para la mayor parte de los ejemplos. El Apndice A contiene una descripcin de la estructura de la base de datos y de su contenido. La base de datos de ejemplo contiene cinco tablas. Cada tabla almacena la informacin sobre una clase concreta de entidad: La tabla CLIENTES almacena datos sobre cada cliente, como el nombre de la empresa, el lmite de crdito y el representante que llama al cliente. La tabla REPRESENTANTES almacena el nmero de empleado, su nombre, su edad, las ventas en el ao en curso y otros datos sobre cada representante. La tabla OFICINAS almacena los datos sobre cada una de las oficinas, incluidos la ciudad en la que se ubica la oficina, la regin comercial a la que pertenece, etc.
'" , '"
'"
~,
'"
BIC,
,~
'"-
-"
2.750.00E SS ooE 180 ooe 1.87S.00 107.00 117.00 652.00 Z50.00e 134,00E '.'>OO.OO 148 OO 5',00E 55,00
.=.
no
R""'-uctora 41672 Plato 779c 90kg bruo 4100)
.."
S~~~~ 3,
." '" '"

,~ ~,
41004 Serie 4, " ..ble 41003 ll<Uice Buln XK4B Reductora
" ", , '" '",

'"
" "
'"
ZM' Llave 112 Iluso 41089 RU<m UOOl Serie 1,
'"
""
."
Barrilete
'" "
m
Figura 4.6.
La base de datos de ejemplo (contina).
62
Captulo 4: Bases de datos re/acionales
63
Tabla CL1ENTES
CLIDlPR!:S.O. S.A. 2111 2102 ,U... 210l .o.c212l C..,1 l>ij". 2101 ....,. Inma"'ona1 2115 Si.rru S.A. 2101 J.r I.lU. L<.d. 2112 U pro<hK:ciones 2121 I;IIA oci-oo!oos 21H 0'-;_ Ud.. 2124 'ascual He.......", !lEP C!.I
JC'
'" ...
LIHITE CllEDITO 50.000.00 f:
210' 2117 2122 2120 2106 211' 21l' 21U 210' n05
""""''''" ~ Lope.
Sotoca '1"01_ S.A.
J.'.
Rl.co S.A. P. 1.6po.1 S.A.

$001_ S.A.
IIoIj.. rAda Sist..... s
lb.... ,~. . CMo Aao<:i.dos AAJ>. Inve.... .....,.
.. '" ...,, .. ... ... ..,, .. ,.. '" ... ,.. .., .., ... ... ".
'" '"
U.OOO.OO. !>O.OOO.OO f: 40.000.00 f: l5.000.00 f: 20.000.00 f: U.OOO.OO f: !>O.OOO.OO f: 15.000.00 f:

~0.000.00
f:
f:
10.000.00 55.000.00 l5.0OO.00 lO.OOO.OO 50.000.00 '5.000 00 25.000.00 '0.000.00 lO.OOO 00

~S.OOO.OO
lE
f: f:
,
f:
,
f: f:
45.000.00 f:
l.bl. OFICINAS
OFICINA
n Po.1.d 11 "'v.rra
CIUDAll
JP:7
OB.1l:TlYO
VUlTAS
" .....,
,
~"
12 Ca."I14<1 1J Al_d.
10B 10' 10. 105 10B
lOO.OOO.OO f: 575.000.00'; 800.000.00 f: l50.000.00 f: 725.000.00 t!
1I6.0U.00 U2.U1.00 735.0U.00 n7.911.00 1l5.915.00
f: f: f: lE f:
labl. REPRESENTAm'f:S
'" ... ,.. '" ... ... ,..

U.
Of"ICI
B.n>no ..... ~ . .
o.
liarla Ji..t"" SUs.....

s.o~o.
S...... I Ch"s1
Ilernarclo Unchn
D&ni .. 1 ku1drobo
'"
'"
1""". Su Len Pnin Pablo e ......

Ileu&
A.~'r.te
" " " " " "

U
ro"
..
" "
", " " " " " " " " "
Represen""'~.
ro=
~~ro
1210211,.8 12110/19$9 1011211,.6 14/06/1988 19/05/1987

~O/IO/UU
/lepres~t4n'"
,u. ...
ro~
Ilepr..s""tant.. VP V..nt... Jefe V"" .... Represent.n... l<epruen ...,t.. Jefa V"" .... Representan.e Repru.. n'an~ ..
Il/0III"0 lUIO/Un 0l/Ol/1981
It/Il/U88
... ,.. ... ,. '" , '" ...,
~,
~~
350.000.00 E: 300.000.00 E: )50.000.00 E: 21$.000.00 E: 200.000.00 E: lOO.OOO.OO

~,
l57.911.00 E: 392.725.00 E: 474.050.00 E: 2".'12.00 U2.5~ . 00 E: l05.673.00 E: 75.985.00 l61.865.00 186.775.00 U6.042.00 E:
l50.000.00 E: 215.000.00 E: lOO.OOO.OO E:
datos tiene un nombre de tabla nico que identifica su comenido. (Realmente, cada usuario escoge sus propios nombres de tablas sin preocuparse de los nombres escogidos por otros usuarios. como se explica en el Captulo 5.) La estructura de filas y columnas de las tablas se muestra con mayor claridad en la Figura 4.7, que es una vista aumentada de la tabla OFICINAS. Cada fila horizontal de la tabla OFICINAS representa una nica entidad fsica -una nica ofici na comercial-o Conjuntamente, las cinco filas de la tabla representan las cinco oficinas comerciales de la empresa. Todos los datos de cada fila de la tabla se aplican a la oficina representada por esa fila . Cada columna vertical de la tabla OFICINAS representa un elemento de datos que se almacena en la base de datos para cada oficina. La columna VENTAS contiene los totales de ventas del ao en curso para cada oficina. La columna JEF muestra el nmero de empleado de la persona que dirige la oficina. Cada fila de una tabla contiene exactamente un valor de datos en cada columna. En la fila que representa la oficina de Navarra, por ejemplo, la columna CIUDAD contiene el valor Navarra. La columna VENTAS contiene el valor 692.637,00 , que es el total de ventas de la oficina de Navarra para el ao en curso. En cada columna de una tabla, todos los valores de los datos de esa columna comparten el mismo tipo de datos. Por ejemplo, todos los valores de la columna CIUDAD son palabras, todos los de la columna VENTAS .son importes monetarios, y todos los valores de la columna JEF son enteros (que representan los n meros de empleado). El conjunto de valores de datos que puede .contener una columna se denomina dominio de esa columna. El dominio de la columna CIUDAD es el conjunto de todos los nombres de las ciudades. El dominio de la columna VENTAS es cualquier cantidad de dinero. El dominio de la columna REGION es exactamente dos valores de datos, Este y Oeste, porque sas son las dos nicas regiones comerciales que tiene la empresa. Cada columna de una tabla tiene un nombre de columna, que,suele escribirse como encabezado en la parte superior de la columna. Todas las columnas de una
Figura 4.6.
La base de datos de ejemplo (continuacin).

Tabla OFICINAS
La tabla PEDIDOS realiza un seguimiento de cada pedido realizado por los clientes, identificando al representante que tramit la orden, el producto solicitado. la cantidad y el importe del producto, etc. En aras de la simplicidad, cada pedido es para un solo producto. La tabla PRODUCTOS almacena los datos sobre cada producto disponible para la venta, como su fabricante, su nmero de producto, su descripcin y su precio.
OFICINA CIUDAD 22 Daimiel 11 Navarra 12 Castelln 13 Almera 21 Los ngeles

Ciudad en la que se ubica la oficina
REGIN Oeste Este Este Este oeste
JEF
108 10G lO' lOS 108
OBJETIVO
300.000,OO" 575.000,OO BOO.OOO,OO 350.000,OO 725.000,OO
VENTAS
lB6.042,0O 692.637.00 735.042.00 367.91l.00 835.91l,OO
+--
Los datos de esta fila son para esta oficina
~Losdatos
Tablas
El principio organizativo de las bases de datos relacionales es la tabla, una disposicin rectangular en filas y columnas de valores de datos. Cada tabla de la base de
Nmero de empleado del jefe de la oficina
t Ventas de la oficina
en el ao en curso
de esta fila son para esta oficina
Figura 4.7.
La estructura en filas y columnas de las tablas relacionales.
64
65
tabla deben tener nombres diferentes, pero no hay nada que prohba que dos columnas de tablas diferentes tengan nombres idnticos. De hecho, los nombres de
columnas utilizados frecuentemente, como NOMBRE, DIRECCION, CANTIDAD, PRECIO
Y VENTAS. Se suelen hallar en muchas tablas diferentes de cada base de dalos de produccin. Las columnas de una tabla tienen un orden de izquierda a derecha, que se
define cuando la tabla se crea por primera vez. Cada tabla siempre tiene, como
mnimo, una columna. El estndar ANSI/ISO de SQL no especifica un nmero mximo de columnas por tabla, pero casi todos los productos comerciales de SQL s que imponen un lmite. Generalmente, el lmite es de doscientas cincuenta y cinco columnas o ms por tabla. A diferencia de las columnas, las filas de las tablas no tienen ningn orden concreto. De hecho, si se realizan dos consultas consecutivas a la base de datos para que muestre el contenido de una tabla, no hay ninguna garanta de que las filas se muestren dos veces en el mismo orden. Por supuesto, se puede pedir a SQL que organice las filas antes de mostrarlas, pero el orden aplicado no tiene nada que ver con la verdadera disposicin de las filas dentro de la tabla. Las tablas pueden tener cualquier nmero de filas. Las tablas sin ninguna fila son perfectamente legales y se denominan tablas vacias (por motivos obvios). Las tablas vacas siguen teniendo estructura, impuesta por sus columnas; tan slo no contiene ningn dato. El estndar ANSI/ISO no limita el nmero de filas de las tablas, y muchos produclOs de SQL permiten que las tablas crezcan hasta agotar el espacio de disco disponible en la computadora. Otros _productos de SQL imponen un lmite mximo, pero siempre muy generoso -dos mil millones de filas o ms es algo habitual.
La tabla PRODUCTOS, parte de la cual aparece en la Figura 4.8, es un ejemplo de tabla en la que la clave principal debe ser una combinacin de columnas. La columna ID_FAB identifica al fabricante de cada producto de la tabla, y la ca lumna ID_PRODUCTO especifica el nmero de producto del fabricante. La colum na ID_PRODUCTO podra ser una buena clave primaria, pero no hay nada que impida que dos fabricantes diferentes utilicen el mismo nmero para sus produc tos. Por tanto, hay que utilizar una combinacin de las columnas ID_FAB e ID_PRODUCTO como clave primaria de la tabla PRODUCTOS. Se garantiza que cada producto de la tabla tenga una combinacin nica de valores de datos en estas dos columnas. La clave principal tiene un valor nico diferente para cada fila de la tabla, por lo que no hay dos filas de una tabla que tenga clave primaria que sean duplicados exactos la una de la otra. Las tablas en las que cada fila es diferente de todas las dems se denominan relaciones en trminos matemticos. El nombre base de datos relacional proviene de este trmino, ya que las relaciones (tablas con filas dife rentes) se hallan en el corazn de las bases de datos relacionales. Aunque las claves primarias son una parle esencial del modelo relacional de datos, los primeros sistemas gestores de bases de datos (System/R, DB2, Oracle y otros) no proporcionaban soporte explcito a las claves primarias. Los diseadores de bases de datos solan asegurar que todas las tablas de sus bases de datos tuvie ran una clave primaria, pero el SoBD en s mismo no proporcionaba ningn modo de identificar la clave primaria de cada tabla. DB2 Version 2, introducido en abril de 1988, fue el primer producto comercial de SQL de IBM que dio soporte a las claves primarias. En consecuencia, el estndar ANSI! ISO se ampli para incluir la definicin de soporte de clave primaria y, hoy en da, la mayor parte de los sistemas gestores de bases de datos lo ofrecen.
Claves primarias
Como las filas de las tablas relacionales no estn ordenadas, no se puede seleccionar una fila concreta por su posicin en la tabla. No hay una primera fila, ltima fila ni fila decimotercera de una tabla. Entonces, cmo se puede especificar una fila concreta como, por ejemplo, la fila de la oficina comercial de Daimiel? En las bases de datos relacionales bien diseadas, cada tabla tiene alguna colum na o combinacin de columnas cuyos valores identifican de manera unvoca cada fila de la tabla. Esta columna (o columnas) se denomina clave primaria de la tabla. Vase una vez ms la tabla OFICINAS de la Figura 4.7. A primera vista, tanto la columna OFICINA como la columna CIUDAD pueden servir como clave primaria de la tabla. Pero si la compaa se expande y abre dos oficinas comerciales en la misma ciudad, la columna CIUDAD ya no puede servir de clave primaria. En la prctica los nmeros de identificacin, como los nmeros de oficina (OFICINA en la tabla OFICINAS), los nmeros de empleado (NUM_EMPL en la tabla REPRESENTANTES) y los nmeros de cliente (NUM_CLI en la tabla CLIENTES) suelen escogerse como claves primarias. En el caso de la tabla PEDIDOS no hay opcin -lo nico que idenli fica de manera unvoca un pedido es su nmero de pedido (NUM_PEDIDO).
Tabla PRODUCTOS
ID_FAS ID PRODUCTO DESCRIPCIN PRECIO
STOCK
'CI .eI BIC
41003 41004 41003
Serie 3, cable 107,00 Serie 4, cable 117,00E: Hlice 652,OOE:
207
139
3
.
Figura 4.8.
Clave principal
..
Tabla con una clave primaria compuesta.
- - - - ------- -
66
67
Relaciones
j
Una de las principales diferencias entre los modelos relacionales ~ los modelos de datos anteriores es que los punteros explcitos, como las relacIOnes padre! hijo de las bases de datos jerrquicas, estn prohibidos en las bases de datos relacionales. No obstante, como es obvio. _estas relaciones tambin existen en las bases de datos relacionales. Por ejemplo, en la base de datos de ejemplo, cada representante est asignado a una oficina comercial concreta, por lo que hay una relacin obvia entre las filas de la tabla OFICINAS y las de la tabla REPRESENTANTES. El modelo relacional no pierde informacin al prohibir estas relaciones en la base de datos? Como puede verse en la Figura 4.9, la respuesta a la pregunta es no. La figura muestra un primer plano de unas cuantas filas de las tablas OFICINAS y REPRESENTANTES. Obsrvese que la columna OFICINA_REP de la tabla REPRESENTANTES contiene el nmero de oficina de la oficina comercial en que trabaja cada representante. El dominio de esta columna (el conjunto de .valores legales que puede contener) es exactamente el conjunto de nmeros de oficinas hallados en la columna OFICINA de la tabla OFICINA. De hecho, se puede hallar la oficina comercial en la que trabaja Maa limnez buscando el valor de la columna OFICINA_REP (11) de Maa y buscando la fila de la tabla OFICINAS que tiene el mismo valor en'.1a columna OFICINA (en la fila de la oficina de Navarra). De manera parecida, para hallar todos los representantes que trabajan en Navarra se puede anotar el valor de OFICINA de la fila de Navarra (11) y luego buscar en-la co-
lumna OFICINA_REP de la tabla REPRESENTANTES el valor correspondiente (en las filas de Mara limnez y Samuel Clavel). La relacin padre/hijo entre una oficina comercial y la gente que trabaja en eIJa no se pierde con el modelo relacional, tan slo deja de representarse mediante un puntero explcito almacenado en la base de datos. En lugar de eso, la relacin se representa mediante valores de datos comunes almacenados en las dos tablas. Todas las relaciones de las bases de datos relacionales se representan de esta manera. Uno de los principales objetivos del lenguaje SQL es permitir la recuperacin de la base de datos de los datos relacionados entre s mediante la manipulacin de estas relaciones de una manera sencilla y directa.
Claves externas
Las columnas de una tabla cuyos valores coinciden con los de la clave primaria de otra tabla se denominan claves externas. En la Figura 4.9, la columna OFICINA_REP es una clave externa de la tabla OFICINAS. Aunque OFICINA_REP es una columna de la tabla REPRESENTANTES, los valores que contiene esa columna son nmeros de oficinas. Coinciden con los valores de la columna OFICINA, que es la clave primaria de la tabla OFICINAS. Conjuntamente una clave primaria y una clave externa crean una relacin padrefhjjo entre las tablas que las contienen, al igual que las relaciones padre/hijo de las bases de datos jerrquicas. Al igual que una combinacin de columnas puede servir de.clave primaria de una tabla, las claves externas tambin pueden ser una combinacin de columnas. De hecho, la clave externa ser siempre una clave compuesta (multicolumna) cuando haga referencia a una tabla con una clave primaria compuesta. Evidentemente, el nmero de columnas y los tipos de los datos de las columnas de la clave externa y de la clave primaria deben ser idnticos entre sr. Una tabla puede contener ms de una clave externa si se halla relacionada con ms de una tabla. La Figura 4.10 muestra las tres claves externas de la tabla PEDIDOS de la base de datos de ejemplo: La columna CLIENTE es una clave externa de la tabla CLIENTES, que relacion'a cada pedido con el cliente que lo realiz. La columna REP es una clave externa de la tabla REPRESENTANTES, que relaciona cada pedido con el representante que lo tramit. Las columnas FAB y PRODUCTO son, conjuntamente, una clave externa compuesta de la tabla PRODUCTOS, que relaciona cada pedido con el producto solicitado. Puede que las diferentes relaciones padrelhijo creadas por las tres claves externas de la tabla PEDIDOS resulten familiares al lector, y deben serlo. Son, precisamente, las mismas relaciones de la base de datos de red de la Figura 4.4. Como muestrael ejemplo, el modelo relacional tiene toda la potencia del modelo de red para expresar relaciones complejas.
Tabla OFICINAS OFICIN CIUDAD - REGIN Oeste Este Este
Tabla REPRESENTATES
NOMBRE
105
lO'
102 106
Bruno Arteaga Maria Jimenez

Susana Santos Samuel Clavel
Figura 4.9.
Una relacin padre/hijo en una base de datos relacional.
68
69
Tabla CLIENTES f:!'l.PRESA NUM eLI
NUI'LEKPL
Tabla PRODUCTOS
ID FAB ID PRODUCTO DESCRIPCI
NOMBRE
Bruno
Arteag<l
3.
A=e
~\
PEDIDO FECHA_P
<ACl
41004)
Serie 4.
cable
~ >
4.
"'"
CLlEIm:
112963
l7-DIC-89
"
'>L
10
1\ 105
'" ''''
P ODUcro
;.
5.
ACI 4 1004)
.,;
<
bIes de manera lgica recurriendo a la combinacin del nombre de una tabla, el valor de una clave primaria y el nombre de una columna. Tratamiento sistemtico de los valores NULL. Los valores NULL (que son diferentes de la cadena de caracteres vaca y de las cadenas de caracteres de caracteres en blanco y de cero o de cualquier otro nmero) estn incluidas en los SGBD completamente relacionales para la representacin de manera sistemtica de la informacin ausente y de la informacin no aplicable, independientemente del tipo de datos. Catlogo dinmico con conexin basado en el modelo relacional. La descripcin de la base de datos se representa en el nivel lgico de la misma manera que los datos normales, de modo que los usuarios autorizados puedan aplicar el mismo lenguaje relacional para su consulta que para la de los datos normales. Regla del sublenguaje de datos completo. Los sistemas relacionales pueden albergar varios lenguajes y diversos modos de empleo de los terminales (por ejemplo, el modo de relleno de los huecos). Sin embargo, debe haber, como mnimo, un lenguaje cuyas instrucciones sean expresabies, mediante alguna sintaxis bien definida, como cadenas de caracteres y que sea completo en su soporte de todos los elementos siguientes:
Figura 4.10.
Varias relaciones padre/hijo en una base de datos relacional.
Las claves externas son una parte fundamental del modelo relacional, ya que crean relaciones entre las tablas de la base de datos. Por desgracia, al igual que con las claves primarias, el soporte de las'c1aves externas estaba ausente de los primeros sistemas gestores de bases de datos relacionales. Se aadi en DB2 Version 2, se han aadido desde entonces al estndar ANSUISO y aparecen hoy en da en muchos productos comerciales.
Definici6n de los datos. Definicin de las vistas. Manipulacin de los datos (de manera interactiva y mediante programaci6n). Restricciones de integridad. Autorizacin. Lmites de las transacciones (comienzo, compromiso y retroceso).
6. 7. Regla de la actualizacin de las vistas. Todas las vistas que, en teora, sean actualizables tambin lo son por el sistema. Insercin, actualizacin y eliminacin de alto nivel. La posibilidad de manejo de las relaciones de la base de datos o de las relaciones derivadas como un solo operando no slo se aplica a la recuperacin de los datos, sino tambin a la insercin, actualizacin y eliminacin de datos. Independencia de los datos fsicos. Los programas de aplicacin y las actividades de los tenninales no se ven afectados lgicamente cuando se producen cambios en las representaciones para almacenamiento o en los mtodos de acceso. Independencia de los datos lgicos. Los programas de aplicacin y las actividades de los terminales no se ven afectados lgicamente cuando se realizan en las tablas base modificaciones de cualquier tipo que preserven la informacin y que, tericamente, permitan que no se vean afectados. Independencia de la integridad. Las restricciones de integridad propias de una base de datos relacional concreta deben ser definibles en el sublenguaje relacional de datos y almacenables en el catlogo, no en los programas de aplicaci6n.
Las 12 reglas de Codd "

En su artculo de 1985 en Computerworld, Ted Codd present doce reglas que deben cumplir las bases de datos para considerarlas verdaderamente relacionales. Las doce reglas de Codd, que se muestran en la lista siguiente, se han convertido desde entonces en una definicin semioficial de las bases de datos relacionales. Las reglas proceden del trabajo terico de Codd sobre el modelo relacional y representan realmente ms un objetivo ideal que una definicin de las bases de datos relacionales.
l. Regla de la informacin. Toda la informacin de las bases de datos relacionales se representa de manera explcita en el nivel lgico y exactamente de una manera: mediante los valores de las tablas. ReglC:l del acceso garantizado. Est garantizado que todos y cada uno de los datos (valores atmicos) de una base de datos relacional sean accesi8.
9.
10.
2.
70
11.
71
12.
Independencia. de la distribucin. Los SGBD tienen independencia de la distribucin. Regla de la no subversin. Si un sistema relacional tiene un lenguaje de bajo nivel (un solo registro cada vez), ese nivel bajo no puede utilizarse para subvertir o soslayar las reglas de integridad ni las restricciones expresadas en el lenguaje relacional de alto nivel (varios registros a
la vez).
En los primeros aos noventa, se hizo popular la compilacin de tablas de puntuacin para los productos de SOBD comerciales, para mostrar su grado de cumplimiento de estas reglas. Por desgracia, estas reglas son subjetivas, por lo que las tablas de puntuacin solan estar llenas de notas al pie y de salyedades, y no revelaban gran cosa sobre los productos. Hoy en da la base de la competencia entre los fabricantes .de bases de datos tiende a girar alrededor del rendimiento, las prestaciones, la disponibilidad De herramientas de desarrollo, la calidad del soporte del fabricante, la disponibilidad de programas de aplicacin que soporten ese sistema concreto de bases de datos y. otros aspectos, ms que. sobre sU"conformidad con las reglas de Codd..No obstante, son una parte importante de la historia del modelo relacional. La regla 1 es, bsicamente, la definici6n informal de las bases de datos relacio. :v nales presentada al comienzo de este apartado. La regla 2 subraya la impo~ncia de las ciaves primarias para' la ltalizacin de los datos en las bases de datos. El nombre e la tabla ubica la tabh! correcta; el nombre de la columna localiza la columna correcta y el valor de la clave primaria ubica la fila que contiene el elemento de datos concreto que nos interesa. La ~egla 3 exige el soporte de los datos que faltan mediante los valores NULL, que se describen en el Captulo 5. . . La regla 4 exige que las bases de datos relacionales se describan a s mismas. En otros trminos, las bases de datos deben contener determinadas tablas de sistema cuyas columnas describan. la estructura de la propia base dedatos. Estas "tablas se describen en el Captulo 16. . .' , La regla 5,obliga a emplear .un lenguaje relacional de bases del datos, como SQL, aunque no se. exija especficamente que sea,SQL. El lenguaje debe poder albergar las funciones iundamentles de los SGBD .!.....:;creacin de!\)ases de datos, recuperacin e introduccin de.datos.implementacin de la seguridad=de la base de datos, etc. J ; ; ' . . . . . ,.. <,.' .' .:.........' . La regla 6 trata de las vistas, que son tablas virtuales.. empleadas :para dar a diferentes usuarios de la base de datos vistas:diferentes de :su estructura. Se trata de una de las reglas ms difciles deimplementar.. en.laprctica, y-hoy en da ningn producto comercial la cumple totalmente. Las Lvistas yJos problemas de su actualizacin se describen en el Captulo 14. . './ . :;.. La regla 7 subraya la naturaleza orientada a conjuntos de las ,bases de datos relacionales. Exige.que las filas se traten como conjuntos en las ,operaciones de insercin, eliminacin y actualizacin. Esta regla est pensada para .prohibir las implementaciones que admiten la modificaci6n mediante navegacin, slo una fila cada vez, de la's bases de datos. 'j'
1
La reglas 8 y 9 aslan a los usuarios o a los programas de aplicacin de la implementacin de las bases de datos a bajo nivel. Especifican que ni las tcnicas concretas de acceso o de almacenamiento empleadas por el SGBD y, ni siquiera, las modificaciones en la estructura de las tablas de la base de datos, deben afectar a la capacidad del usuario para trabajar con los datos. La regla JO dice que el lenguaje de la base de datos debe soportar las restricciones de integridad que restringen los datos que pueden introducirse en la base de datos y las modificaciones de la base de datos que pueden realizarse. Se trata de otra regla que no est incluida en la mayor parte de los productos SGBD comerciales. La regla 11 dice que el lenguaje de la base de datos debe poder manipular los datos distribuidos ubicados en otros sistemas informticos. Los datos distribuidos y los retos de su gestin se describen en el Captulo 23. Finalmente, la regla 12 evita otros caminos de acceso a la base de datos que puedan subvertir su estructura relacional y su integridad.
Resumen
SQL se basa en el modelo relacional de datos que organiza los datos de las bases de datos como un conjunto de tablas: Cada tabla tiene un nombre que la identifica de manera unvoca. Cada tabla tiene una o varias colu:mnas con nombre que estn dispuestas en un orden determinado, de izquierda a derecha. Cada tabla tiene cero o ms fiJas, cada una de las cuales contiene un nico valor de datos en cada columna. Las filas no estn ordenadas. Todos los valores de los datos de una columna dada tienen el mismo tipo de datos, y se obtienen de un conjunto de valores legales denominado dominio de esa columna. Las tablas estn relacionadas entre s mediante los datos que contienen. El modelo relacional de datos utiliza las claves primarias y las claves externas para representar estas relaciones entre las tablas: Una clave primaria es una columna o una combinaci6n de columnas de una tabla cuyos valores identifican de manera unvoca cada fila de la tabla. Cada tabla tiene slo una clave primaria. Una clave externa es una columna o una combinacin de columnas de una tabla cuyos valores son el valor de la clave principal de alguna otra tabla. Cada tabla puede contener ms de una clave externa, que la vincula a una o varias tablas. Una combinacin de claves primarias y claves externas crea una relacin padre/hijo entre las tablas que las contienen.
I
l'
i
I
Parte II
RECUPERACiN DE BATOS
~
Las consultas son el corazn del lenguaje SQL, y muchos usan SQL como herramienta de consulta de bases de datos. Los cinco captulos siguientes describen las consultas SQL en profundidad. El Captulo 5 describe las tructuras bsicas del lenguaje SQL que se usaD para fQrmar las instrucciones SQL. El Captulo 6 estudia consultas simples que obtienen datos de una nica tabla de datos. El Captulo 7 expande el estudio a consultas sobre varias tablas. Las consultas que resumen datos .se describen en el Captulo 8. Finalmente, el Captulo 9 explica la capacidad de las subconsultas SQL que se usa para manejar consultas complejas.
es-
,.
.', .-', ..-..,. -:-5

CAPITULO'
Fundamentos de SOL
"'.~
,
"#
,"
t: .- "; ;:~-,
.'
~..
~ -:- ': lo ....
..
~I
Este captulo comIenza con una descripcin detallada de las caractersticas de SQL. Describe la estructura' bsica.de una instruccin SQL y los elementos bsicos del lenguaje, como las palabras clave,-los tipos de datos y las expresiones. Tambin se describe la forma en que SQL maneja los datos con valores NULL. Aunque stas sean las caractersticas bsicas <te".SQL. hay alguns' diferencias sutiles en la forma en que se implementan en' varios'productos populareS SQL y, en muchoscasos-.los productos SQL proporcionan extensiones significativas a las capacidades especificadas en el estndar SQL de ANSmSO..En este oaptulo tambin se describen
estas diferencias y
I
,
e~t~nsiones.
. .;"_'
Instrucciones
El cuerpo principal del lenguaje SQL consiste en unas 40 instrucciones.. Las in~. trucciones ms importantes y usadas con mayor frecuencia' se resumen ~n"I2.~'Ta~ bla 5.1. Cada instruccin requiere un'a accin- especfica del SGBD, com ctr una nueva tabla, recuperar datos o insertar datos nuevos en la base de datos. Todas las ins~cciores,SQL tienen la.mis9Ja.fo~a.,bsi<;:a:.JJustrada en la Fig~ra 5.L ~ Cada instruccin SQL comienza con un verbo. una palabra clave que describe lo que hace la instruccin. CREATE, INSERT, DELETE y COMMIT son verbOs -habituales. La instruccin contina con'una o msclusulas. Una clusula puede especificar los datos sobre los que operar la instruccin, o proporcionar ms detalles sobre lo que debe hacer la instruccin. Cada clusula tambin comienza con una pahibra clave:' com' WHERE, FRM," '.i:NTO 'HAVING. A)gunas clusulas son opcionales, y otras son-obli'gatbrfas. El-confnidd y e""stttittt'a especficos pueden variar para distintas clusulas, Muchas clusulas c'onti'ene"tt1i 1'ombres de tablas o de columnas; algunas contienen palabras clave, constante,sno expresiones adicionales. El estndar SQL.de ANSI/lSO eSp'ecific~.I,~s,p,J~!1fas clave SQL que se usan como verbos y en clusulas. De acuerdo con el estnd~ estas palabras clave no se pueden..llsar .para.denominar_oh}elos.,oeJa baSe J:B~t~ tales._como tablas.. colum-
. j.'
. : .
..
.','
.
,
.,'.
'
. ', ,
'.
~J
..-.
'l
...
75
76
Captulo 5: Fundamentos de SQL
77
Tabla 5.1.
Instrucciones principales de SQl
nstruccin Manipuu:in de datos

SELECT
INSERT
Descripcin
Verbo Recupera datos de la base de datos. Aade nuevas filas de dalos a la base de datos. Elimina filas de datos de la base de datos. Modifica datos existentes en la base de datos.
Nombre de tabla
~Of:LETE
~
/
DELETE
UPDATE
::;"
FROM
wtfEM. lIENTAS < 2 OOOO OO
REPRESENTANTE~
.
Clu,ula,
Palab,., clav:
Definicin de datos
CREATE TABLE
DROP TABLE
Aade una nueva tabla a la base de datos.
Nombre umna Constante Figura 5.1.

La estructura de una instruccin SOL.
Elimina una tabla de la base de datos.

Cambia la estructura de una tabla existente. Aade una nueva vista a la base de dalos.
ALTER TABLE CREATE VIEW DROP VIEW
Elimina una vista de la base de datos.
CREATE INDEX
OROP INDEX
Construye un ndice sobre una col,:,-mna.

Elimina el ndice de una columna.
Aade un nuevo esquema a la base
d~
CREATE SCHEMA
DROP SCHEMA CREATE DOMAIN ALTER DOMAIN DROP DOMAIN
datos.
Eliminaun esquema de la base de datos. Aade un nuevo dominio qe valores de datos. Cambia la definicin de un dominio. Elimina un dominio de la base de datos. Concede privilegios de acceso a los usuarios. Elimina privilegios de acceso de los usuarios. Finaliza la transaccin actual. Aborta la transaccin actual. Define las-caractersticas de acceso a datos de la transaccin actual. Define un cursor para una consulta. Describe el plan de acceso a datos de una consulta. Abre un cursor para recuperar los resultados de una consulta. Recupera una fila de resultados de una consulta. Cierra un cursor. Prepara una instruccin SQL para la ejecucin dinmica. Ejecuta dinmicamente una instruccin SQL. Describe una consulta preparada.
Control de acceso
GRANT
REVQKE
Control de transacciones
COMMIT ROLLeACK SET TRANSACTION
Programacin con SQL

DECLARE EXPLAIN OPEN FETCH CLaSE PREPARE EXECUTE DESCRIBE
nas y usuarios. Muchas implementaciones de SQL suavizan esta restriccin, pero en general es buena idea evitar,las palabras clave cuando se da nombre a las tablas y columnas propias. La Tabla 5.2 lista las palabras clave incluidas en el estndar SQL2 de ANSI/ISO, que triplica aproximadamente el nmero de palabras clave reservadas en el antiguo estndar SQLl. El estndar SQL2 tambin incluye una lista de palabras clave potenciales que son candidatas para revisiones futuras del estndar. En la Tabla 5.3 se incluyen estas palabras clave. A lo largo del libro se ilustran las fonnas ~ceptables de una instruccin SQL mediante un diagrama sintctico, como el que se muestra en la Figura 5.2. Una instruccin o clusula SQL vlida se construye siguiendo la lnea en el diagrama sintctico y en los ejemplos (como DELETE y FRoM,en la Figura 5.2) siempre se muestran en maysculas, pero casi todas las implementaciones de SQL admiten tanto maysculas como minsculas en las palabras clave, y a menudo es ms conveniente escribirlas en minsculas. Los elementos variables de una instruccin SQL (como el nombre de la tabla y la condicin de bsqueda en la Figura 5.2) se muestran en minsculas cursivas. Es privativo especificar el elemento apropiado cada vez que se usa la instruccin. Las clusulas y palabras clave opcionales, tales como la clusula WHERE de la Figura 5.2, se indican como caminos alternativos en el diagrama sintctico. Cuando se ofrece la eleccin de palabras clave opcionales, la eleccin predetenninada (es decir, el comportamiento de la instruccin si no se especifica ninguna palabra clave) aparece SUBRAYADA.
Nombres
Los objetos de una base de datos SQL se identifican asignndoles nombres nicos. Los nombres se usan en las instrucciones SQL para identificar el objeto de
78
saL.
Manual de referencia
Captulo 5: Fundamentos de SOL
79
Tabla 5.3.
ABSOLUTE ACTION
AOO
Palabras clave potenciales de SQL2 de ANSI/ISO

< 0'-'
CROSS CURRENT
'"'
co
NE:XT
NO NOT
SPACE
AFTER. ;
ALIAS
EQUALS GENERAL
'OLO OPERAT10N OPERATORS
RETURN RETURNS ROLE
',.- TEST THERE TR1GGER
GLOB~L
soc
SQLCOOE SQLERROR SQLSTATE SUBSTR1NG
SUM
CURRENT_OATE
ASYNC BE:FORE BOOLEAN BREADTH COMPLE:TION CALL IGNORE LE:AVE LESS LIMIT LOOP MODIFY
ALL
ALLOCATE ALTER
CURRENT2.TIME
'GOTO
NULL. OCTET_LENGTH
OTHERS "PARAMETERS . PENOANT PREORDER PRIVATE PROTECTED RECURSIVE

RON
UNDER '; VARIABLE VIRTUAL VISIBLE WAIT "":\
CURRENT_USER
CURSOR
GROUP HAV1NG HOUR IDENT1TY
OR
SVEPOINT SEARCH :. SENSITIVE SEQUENCE SIGNAI: SIMILAR
ANO AN'
ON
DATE
ONLY OPEN .OPTION

OR
. 'SYSTEM_USER TABLE TEMPORARY CYCLE DATA DEPTH DICT10NARJ ;( EACH ELSEIF
'" " "C

ASSERTION
AT
DEALLOCATE
1MMEDIATE
O"
DECIMAL DECLARE
DEFAULT
"
1ND1CATOR
ORDER OUTER OUTPUT OVERLAPS
"'"
TIME .TIMESTAMP TIMEZONE_HOUR TIMEZONE_M1NUTE
TO
.~,
N'"
NONE OBJECT OFF'
0>0
\'iHIut ,. l.;,
WITHOUT
1N1TIALLY 1NNER INPUT
REFERENCltJG REPL},CE; RFSJ;GNAL
SQIE:l'CEPTION, 'SQLWARNING STRUCTURE
.;j
AUTHORIZATION
AV'
BE.GIN
BE~EEN
DEFERRABLE
DEFE!-RED ,
DEL~TE,
INSERT
>NT
PART1AL POS.1TION PRECISION PREPARE
TRA:Lt':l",G TRANSACT10N TRNSLATE :: TRANSLATION TIM TRUE .. , UN10N UNIQUE UNKNOWN 'UPOATE UPPER USAGE USER USING
VALU~
BIT'
BIT_LENGTH
DEse
DESCRIBE
1NTEGER :'1NTERSECT 1NTERVAL INTO

'Ji . '1S
80TH
DESCRIPTOR
BY
CASCADE
OIAGNOSTICS
iOISCONNECT
P~E:SERVE
CASCADEti
CASE
", 'I~~I~'TI
DOMAIN
PR'rMARY . PRIOR'
PR1V1LEGES "' ~PROCEOURE 'PUBLIC RE:AD REAL .REFERENCES RELAT1VE RESTR1CT RE:VOKE
'
1SOLAT10N J1N
CAST
DOVBLE
CATALOG
CHAR CHARACTER
CH~_LENGTH
DROP
ELSE END .
'" LANGUAGE
LAST LEA01NG LEFT. LEVEL L1KE LOCAL LOWER
El;ID_EXEC
ESCAPE
CHARACTER_LENGTH
CHECK
EXCEPT
CLOSE
CO!'L~~~E
EXCEPTION EXEC
EXECUTE EXIsTS E:XTERNAL EXTRACT FALSE . FETCH FIRST FLOAT
ROR
0,"
VALUES VARCHAR VJl.RYING
R1GHT ROLLBACK ROWS
la base de datos sobre el que la instruccin debera actuar, Lds objetos ;con 'llom.: bre fundamentales en una base de datos -relacional-son los nomores de "tablas (que identifican tablas), nombres_de columnas (qu~jdentifican columnas) y nombres de usuarios (que identifican,usuarios de la ,basede datos); 'en .el ~stndar original SQLl se especificaron 10s convenios de denominacin !deestb.s'l0bjet0s: El estndar SQL2,de ANSUISO expande significativamente lajlista deentid.'des con nombre para incluir esquemas (colecciones de tablas');restricciones'{ligadu:" ras sobre los contenidos de las' tablas y'sus rlaciones);ldominios (conjiHs de valores legales que se pueden asignar a una columna)'y varios otros tipos 'de objetos: Muchas'implementaciones de SQL albergan objetos.con nombre'a-uicidnales, como -los procedimientos almacenados, las relaciones de clave 'primaria'o externa,' formularios de entrada' de datos"y esquemas de rplica de 'dato"s: El estndar original ANSI/ISO ,especific -que los nombres SQL deben Conte ner de 1 a 18 caracteres, deben empezar con una letra y no pueden contener espacios o caracteres de puntuacin especiales. El estndar SQL2 aument el mxiino
COLL,E
COLLATIN COLUMN
COHMIT
'~TCH
MAX
"
,';
VIEW WHEN WHENEVR WHERE' 'WITH WORK WRITE
SCHEMA 'SCROLL SECONO . SECTION SELECT SESSION SESSION_USER
M"
MINUTE' Momn::E' MONTH NAMES NAT10NAL NATURAL NCRAR NULL1F NUMERIC
COWh:CT
CQNNECTION
,1----,...-L
DELETE FRDM
rJombrede-tabfa --~...,.------,
.,'
"
CONSTRAINT
CONSTRAINTS
CONTINUE
CONVERT
Y"R
ZONE
WHERE
condicin-de:bisqeda""C"'-'-"''----'''-+!
FORE1GN FOUNO FROM - [: FULL
s"'
SIZE SMALL1NT SOME
CORRESPONOING COUNT CREATE
Figura 5.2.
Un diagramlsintcti'ca~deejempID:::~ '"~': ;':-,;-.~
80
81
a 128 caracteres, En la prctica, los nombres albergados.por los productos SOBD basados en SQL varan significativamente. Es comn ver restricciones ms fuenes sobre los nombres que estn conectados con otro software fuera de la base de datos (tales como nombres de usuarios, que pueden corresponder con los nombres de inicio de sesin usados en un sistema operativo), y restricciones ms dbiles sobre los nombres que son privados a la base de datos. Los diferentes productos tambin difiereI! en los caracteres especiales que admiten en los nombres de las tablas. Por razones de transportabilidad, es mejor tener nombres relativamente cortos y evitar el uso de caracteres especiales.
Nombres de columnas
Cuando se especifica un nombre de columna en una instruccin SQL, SQL puede determinar normalmente por el contexto la columna que se pretende. Sin embargo, si la instruccin involucra dos columnas con el mismo nombre de dos tablas diferentes, se debe usar un nombre de columna calificado para identificar sin ambigedad la columna que se pretende. Un nombre de columna calificado especifica tanto el nombre de la tabla que contiene la columna como el nombre de la columna, separados por un punto (.). Por ejemplo, la columna denominada VENTAS de la tabla REPRESENTANTES tiene el nombre de columna calificado:
REPRESENTANTES. VENTAS
Nombres de tablas
Cuando se especifica el nombre de una tabla en una instruccin SQL, SQL entiende que se hace referencia a una de las tablas propias (es decir, una de las que haya creado el propio usuario). Usualmente se desea elegir nombres de tablas que sean pequeos pero descriptivos. LOS nombres de las tabJas en la base de datos de ejemplo (PEDIDOS, CLIENTES, OFICINAS, REPRESENTANTES, PRODUCTOS) son una muestra adecuada. En una base de datos personal o departamental, la eleccin de los nombres de las tablas recae en el desarrollador o diseador de la base de datos. En una base de datos ms grande de uso compartido y corporativa, puede haber estndares corporativos para la denominacin de tablas, con el fin de' asegurar que los nombres de las tablas no entren en conflicto. Adems, la mayora de marcas de SGBD permiten que usuarios diferentes creen tablas con el mismo nombre (es decir, tanto Juan como Susana pueden. crear una tabla denominada CUMPLEAOS). El SGBD usa la tabla apropiada dependiendo del usuario que est realizando la consulta. Con los permisos adecuados tambin se puede hacer referencia a tablas de otros usuarios usando un nombre de tabla calificado. Un nombre de tabla calificado especifica tanto el nombre del propietario de la tabla como el nombre de la tabla, separados por un punto (.). Por ejemplo, Juan podra acceder a la tabla CUMPLE~OS de Susana usando el nombre de tabla 'calificado:
SUSANA.CUMPLEARos
Si la columna proviene de una tabla propiedad de otro usuario, se usa un nombre de tabla calificado en el nombre de columna calificado. Por ejemplo, la columna FECHA_NAC de la tabla CUMPLEA90s, propiedad del usuario SUSANA, se especifica por el nombre de columna completamente calificado:
SUSANA. CUMPLEAOS. FECHA_NAC
Los nombres de columna calificados se pueden usar generalmente en una instruccin SQL en cualquier lugar en que pueda aparecer un nombre simple de columna (sin calificar); en las descripciones de cada instruccin SQL se destacan las excepciones.
Tipos de datos
El estndar SQL2 de ANSIIISO especifica los diferentes tipos de datos que se pueden almacenar en una base de datos basada en SQL y manipulada por el lenguaje SQL. El estndar SQLl original especific slo un conjunto mnimo de tipos de datos" El estndar SQL2 expandi esta lista para incluir cadenas de caracteres de longitud variable, datos de fecha y hora, cadenas de bits y otros tipos. Los productos SGBD actuales pueden procesar una rica variedad de tipos de datos, y hay una considerable diversidad en los tipos de datos particulares incluidos en diferentes marcas de SGBD. Los tipos de datos habituales son, entre otros, los siguientes: Enteros. Las columnas con este tipo de datos contienen normalmente cuentas, cantidades, edades, etc. Las columnas enteras se usan tambin frecuentemente para contener nmero de identificacin (ID), como cliente, empleado y nmeros de pedidos. Nmeros decimales. Las columnas con este tipo de datos almacenan nmeros que tienen partes fraccionarias y deben ser calculados con precisin, como las tasas y los porcentajes. Se usan tambin frecuentemente para almacenar cuentas de dinero.
Un nombre de tabla calificado se puede usar generalmente en una instruccin SQL en cualquier lugar en que pueda aparecer un nombre de tabla. El estndar SQL2 de ANSIIISO generaliza la noci6n de un nombre de tabla calificado an ms. Permite la creacin de una coleccin de tablas con nombre, denominada esquema. Es posible hacer referencia a una tabla en un esquema especfico usando un nombre de tabla -calificado. "Por ejemplo, la referencia a la tabla CUMPLEAOS del esquema INFOEMPLEADOS sera:
INFOEMPLEADOS.CUMPLEARos
El Captulq 13 proporciona ms informacin sobre los esquemas, usuarios y otros aspectos de la estructura de una base de datos SQL.
82
83
Nmeros en coma flotante. Las columnas con este tipo de'datos_se,usan para almacenar nmeros cientficos que pueden ser objeto de clculo aproximado, como pesos y distancias. Los nmero en coma flotant~pueden.repre: sentar un rango mayor de va,lores que Jos nmeros decimales, pero producen errores de redondeo en los .clculos. Cadenas de caracteres de longitud fija. Las colu,mnas con este tipo cte.-datos almacenan, normalmente, nombres de personas y empresas, jirecciones, descripciones, etc. '. , Cadenas de caracteres de longit1,ld variable. Este tipo de datQ~ p~frnite que una columna almacene cadenas de caracteres que varan en su longitud de fila en fila, con un tamao mximo. (El estndar SQLI permita slo cadenas de caracteres de longitud fija, que son ms fciles para el SOBD de procesar, pero pueden malgastar un espacio considerable.) Cantidades monetarias. Muchos productos SQL ,albergan un tipo MONEY o CURRENC-Y, 'que se almacena usualmente como un nmero,decimal O en.coma flotante. Al tener,un tipo concreto de datos monetario, .el SGBD puede .dar formato adecuadamente a las 'cantidades monetarias al visualizarlas.' Fechas y horas. El soporte de valores de fecha y hora es tambin comn en los productos SQL, aunque los detalles pueden variar considerablemente de un producto a otro. Generalmente se albergan distintas combinaciones de fechas, horas, marcas temporales (timestamp), intervalof'd&tiempo'y aritmtica de fechas y horas. El estndar'SQL2incluye una'especificacil-elaborada para los tipos de datos DATE, TIME, TIMESTAMP LrNTERVAL, in'c1u''; yendo soporte para zonas horarias y precisin temporal (por ejemplo; dcims o centsimas de segundo). Datos booleanos. Algunos productos SQL, como Informix Dynamic Server, albergan valores lgicos (TRUE y FALSE) como un tipo explcito,' y algUiIos tambin permiten operaciones lgicas (comparaciones, AND y OR, Y'otras) sobre los datos almacenadosconinstrucciones SQL. Texto largo. Varias bases de datos basadas en SQL albergan columnas. que almacenan largas cadenas>deltex~o (normalmente; hasta 3.2.000 o 65.000 caracteres y, en .algunos casos,incluso.ms). Esto permite a la base de datos almacenar documentos completos,' descripciones de productos~~,artculos.tc.:. nicos,:resmenes y .datos,textuales s~milares sin estructura.El SGBD prohibe usualmente el uso de estas columnas 'en ,las consultas interactivas y las .. ":;' 1"J' 1, j,"_ bsquedas.'." Corrientes de bytes sin estructura. Varios SGBD permiten el almacenamiento y recuperacin de secuencias de bytes sin estructura y de longitud variable. Las columnas que contie~en estos datos~se usan'para almacenar imgenes de vdeo,comprimidas, cdigo ejecutable 'y otros tipos de datos sin estructura. El tipo de datos de SQL Ser.ver .IMAGE, por ejemplo; puede almacenar una corriente de hasta dos mil millones de bytes de datos. Caracteres no romanos. Al crecer las bases de datos'para dapsoporte'a aplicaciones globales, los fabricantes de SGBD han ido aadiendo 'soporte para cadenas de longitud fija y ,variable de caracteres de.-16 bits .usadas para representar Kanji u otros caracteres asiticos o rabes. Mientras que las, bases
de datos modernas permiten el almacenamiento y recuperacin de dichos caracteresl (usando a menudo el convenio UNICODE para representarlos), el soporte;de .la bsqueda y ordenacin en los tipos GRAPHIC Y VARGRAPHIC .vara 'ampliamente. La Tabla 5.4 lista los tipos de datos especificados en el estndar ANSUISO de SQL.
.
~'.
Tabla 5.4....
Tip~s de datos de SOL de ANSI/ISO

-u;
~.
Descripcin Cadenas de caracteres de longitud fija. rCadenas de caracteres de longitud variable*. .
CRAR (longitud),.
CHARAC'I.'.E~
(longit.td)
1,',
VARCHAR ::( longitud) CHAR VARYING (longitud) CHARACT,ER .VARYING .(longitud)
NCHAR; '(longitud)
NATINA:L,CHJI.R NATIONAI.:
(longitud) CHARACTER (longitud)
Cadenas de caracteres nacionales de ll-; longitud fija*, .(

, I
NCHAR VARYING (longitud) NATI'NF.:L Cli1l.."R;VARYING '(longitud)-' N+I;6iL't~ARA.CTERVARYING (longitud)

-\(l"
'Cadenas de caract~ies n'acionales de longitud variable *. (

'~l.
(~, '!.,
'.j'
"
INTEGER
Nmeros enteros. Nmeros enteros pequeos. Cadenas de bits de longitud fija*. Cadenas de bits de longitud variable*. Nmeros decimales.
INT
"
SMf\LHN,T,
BIT~,(longitud),
BIT VARYING NUMERIC DECIMAL.

DEC
(longitud)
(precisin, escala) (precisin, escala) (precisin, escala)
FLOAT REAL
(pre~is"iAr
Nmeros en coma flotante. Nmeros en coma flotante de baja precisin. Nmeros en coma flotante de-alta. precisin. Fechas del calendario*.
.1'
DOUBLE PRECISION DATE TIME
(precisin) (precisin)
Horas de
reloj~.
TIMESTAMP INTERVAL
Fechas y horas*. Intervalos de tiempo*.
* Nuevo tipo de datos en SQL2.
'/ 1
84
85
Las diferencias entre los tipos de datos ofrecidos en varias implementaciones SQL son una de las barreras prcticas a la transponabilidad de las aplicaciones basadas en SQL. Estas diferencias han sido resultado de la innovacin en la evolucin de las bases de datos para la inclusin de un rango ms amplio de capacidades. ste ha sido el patrn habitual: Un fabricante de SaBn aade un nuevo tipo de datos que proporciona nuevas capacidades tiles para un cierto grupo de usuarios. Otros fabricantes de SGBD aaden el mismo tipo de datos o similar, e introducen sus propias innovaciones para diferenciar sus productos del resto. Durante varios aos se incrementa la popularidad del tipo de datos y llega a ser parte de la corriente principal de tipos de datos albergados por la mayora de implementaciones de SGBD. Los cuerpos estndares se involucran en el intento de estandarizar el nuevo tipo de datos y eliminar las diferencias arbitrarias entre las implementaciones de los ~abricantes. Cuanto ms se ha asentado el tipo de datos, ms difcil es encontrar el compromiso al que se enfrenta el grupo de estandarizacin. Normalmente esto resulta en una adicin al estndar que no se corresponde exactamente con ninguna de las implementaciones actuales. Los fabricantes de SGBD aaden lentamente soporte para el nuevo tipo de datos estandarizado como una opcin a sus sistemas, pero, dado que tienen una gran base instalada que usa la versin antigua (ahora propietaria) del tipo de datos, deben tambin continuar con su soporte. Durante un periodo de tiempo muy grande (generalmente varias versiones principales del producto SGBD), los usuarios migran al nuevo tipo de datos estandarizado y el fabricante de SGBD puede empezar el proceso de eliminacin de la versin propietaria. Los datos de fecha y hora proporcionan un ejemplo excelente de este fenmeno y las variaciones en los tipos de datos que crean. DB2 ofreci pronto soporte para las fechas y las horas, con tres tipos de datos diferentes:
DATE.
SQL Server se introdujo con un nico tipo de datos de fecha y hora, denominadatos TIMESTAMP de DB2. Si Server podra aceptar esta versin de la consulta (sin la aritmtica de fechas):
do
DATETIME, que se asemeja mucho al tipo de FECHA_CONTRATO contiene datos DATETIME, SQL
5ELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO >= '06/14/1989'
Dado que en la consulta no se ha especificado la hora del 14 de junio de 1989, SQL Server asume la medianoche de esa fecha. La consulta SQL Server significa realmente:
SELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO >= '06/14/1989 12:00AM'
Si la fecha de contrato de un representante se almacenase en la base de datos como el medioda del 14 de junio de 1989, el representante no se incluira en los resultados de la consulta de SQL Server, pero s en los de DB2 (dado que s6lo se almacen la fecha). SQL Server tambin alberga aritmtica de fechas mediante un conjunto de funciones predefinidas. As, la consulta al estilo DB2 se puede tambin especificar de esta forma:
SELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO >= DATEADD(DAY, 15,
'05/30/1989')
"
lo cual es considerablemente diferente a la sintaxis de DR2. Gracle tambin alberga los datos de fecha y hora con un nico tipo de datos, denominado DATE. Al igual que el tipo de datos DATETIME de SQL Server, la parte de la hora de un valor DATE de Gracle entiende medianoche si no se especifica una hora concreta. El formato de fechas predeterminado de Oracle es diferente de los formatos de DB2 y SQL Server, as que la versin de Gracle de la consulta es:
SELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO >= '14-JUN-89'
TIME.
Almacena una fecha, como Junio 30, 1991. Almacena un momento del da, como 12:30 P.M. T:IKESTAKP. Un instante especfico en la historia, con una precisin mejor que el nanosegundo. .
Se pueden especificar fechas y horas concretas como constantes de cad~ena y se incluye la aritmtica de .fechas. A continuacin se muestra un ejemplo de una consulta vlida usando las fechas DB2, en el que se asume que la columna FECHA_ CONTRATO contiene un dato DATE.
SELECT NOMBRE, FECHA_CONTRATO FROM REPRE~ENTANTES WHERE FECHA_CONTRATO >= '0513011.989'
Oracle tambin alberga una aritmtica limitada de fechas, de forma que la consulta al estilo DB2 tambin se puede especificar, pero sin la palabra clave DAYS:
SELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO >= '30-HAY-89'
15
+ 15 DAYS
Finalmente, el estndar SQL2 de ANSIIISO aadi soporte para los datos de fecha y hora con un conjunto de tipos de datos basados en los tipos de datos de DB2,
86

21 -375 2000.00
+4~7500.8778
87
pero no idnticos a stos. Adems de los tipos de datos DATE, TIME YTIME5TAMP, el estndar especifica el tipo de datos INTERVAL, que se puede usar para almacenar un intervalo de"tiempo (por ejemplo, un intervalo medido en"das o una duracin medida en horas, minutos y segundos). El estndar tambin proporciona un mtodo muy elaborado y complejo para manejar la aritmtica de fechas y horas, especificando la precisin de los intervalos, ajustando las diferencias debidas al-uso horario, etc. Como ilustran estos ejemplos, las sutiles diferencias en los 'tipos de datos en varios productos SQL conducen a diferencias significativas en la sintaxis de las instrucciones SQL. Incluso pueden provocar que la misma instruccin SQL produzca resultados ligeramente distintos en diferentes sistemas gestores de bases de datos. La ampliament predicada transportabilidad de SQL es cierta, pero s.lo de manera general. Una aplicacin se puede trasladar de una base de datos a otra y puede ser muy transportable si slo usa las caractersticas fundamentales y bsicas de SQL. Sin embargo, las diferencias sutiles en las implementaciones SQL indican que los tipos de datos y las instrucciones SQL deben ajustarse casi siempre si hay que llevarlos a otras marcas de SGBD. Cuanto ms compleja sea la aplicacin, ms probable es que.lIegue alser dependiente {fe-las caractersticas' y matices especficos, y, por tanto,menos'tran'sportable. J d. T ''l'']!'
No se d.ebe poner una coma entre los dgitos de _~na constante numrica, y no todos los dIalectos .de SQL permiten ~l signo positivo. as que es mej?r evitarlo. Para los datos monetarios, la mayora de implementaciones SQL U$an simplemenM te las_ .const~ntes ~nteras ~ decmales, aunque algunas permiten que se esp~cifique la constante con un smbolo de moneda: . .
$0.75 $5000.00 $~567.89
Las constantes en coma flotante (tambin denominadas literales numricos aproximados) se especifican usando la notacin E, usada comnmente en los len M guajes de programacin corno e y FORTRAN. AqU hay algunas constantes vlidas en SQL de coma flotante:
,"
1.SE3 -3.14159El 2.5E-7 0.783926E21
'
"
La se lee como por diez elevado a la poten.cia, as.ql,Ie la iprimer~ se lee 1,5 por diez elevado al cubo, o 1.500..
c.o~stante
"
Constantes
En algunas instrucciones SQL, un valor de datos numrico, de carcter o de fechas se debe expresar de forma textual. Por ejemplo. en esta instruccin INSERT, que aade un representante a la base de datos: ... . VENTAS).
Constantes de cadena
El estndar ANSIIISO especifica' gti'e las constantes SQL para ios datos de cuacteres se deben encerrar entre comillas simples (' ....), como en estos ejemplos:
'Garcia, Juan J .. ' 'Madrid' 'Oeste'
INSERT INTO REPRESE~TAN~~S VALUES (115,

.
(,~~_~MPL~, NOM~~~ ., ~~~T,t:-,. ~f.C~~_CO~~~:o,
, , el valor de cada columna en' la nueva fila insertada se especifica en' ta..clusula VALUES.' Los valores de datos,constantes tambin se usan en expresiones, como en , I ", .. :.'. la instruccin SELECT:' . "
SELECT CIUDAD FROM OFICINAS
'"Daniel Izquierdo', 175000'.00, ':21-JU-'90",l:-O;'OO)
Si hay que incluir una comilla simple dentro del texto const~nte, s~ escribe -~n la constante como dos caracteres consecutivos de comilla simple. As, el valor constante:
.,
'McDon.~ld'
's'
WHERE OBJETIVO>
(1.1 * VENTAS) + 10000.00
es la cadena de diez caracteres McDonald's. Algunas implementaciones de SQL, como-SQL Server e Infonnix, aceptan constantes de cadena encerradas entre comillas dobles
-e'..."):
".
El estndar SQL de ANSIIISO especifica el fonnato de las constantes de cadena y numricas,'o literales,'que'representan valores de datos'especficos. 'La mayora de implementaCiones de SQL siguen estos convenios. . 1:
"Garcia. Juan J..
"Madrid"
Oeste"
Constantes numricas
Las constantes enteras y decimales (tambin denominadas literales numicos exactos)se e"sc'riben como nmeros:deciinales ordin-aris en las instrucciones SQL; como u'~signo opcional positivo o negativo. .'.'
Desafortunadamente, las comillas dobles pueden plantear problemas de transportabilidad con otros productos SQL. El estndar SQL2 proporciona la capacidad adicional de especificar constantes de cadena de un conjunto concret~ de caracteres nacionales (por ejemplo, francs O alemn) o de un conjunto de caracteres definido por el usuario. Las capacidades del conjunto de caracteres definido por el usuario no se han implementado, generalmente, en los principales productos SQL.
~.
8S
89
Constantes de fecha y hora

En los productos SQL que incluyen los datos de fecha y hora, los valores constantes para fechas, horas e intervalos de tiempo se especifican como constantes de cadena. El formato de estas constantes vara de un SGBD a otro. Hay incluso ms variaciones introducidas por las diferencias en la forma en que se escriben las fechas y las horas en diferentes pases. DB2 alberga varios formatos internacionales diferentes para las constantes de fecha, hora y marca temporal, como se muestra en la Tabla 5.5. La eleccin del formato se hace al instalar el SGBD. DB2 tambin alberga duraciones especificadas como constantes especiales, como en este ejemplo:
FECHA_CONTRATO + 30 DAYS
Tambin se puede usar la funcin predefinida de Oracle TO_DATE {} para convertir las constantes escritas en otros formatos. como en este ejemplo:
SELECT NOMBRE, EDAD FROM REPRESENTANTES WHERE FECHA_CONTRATO = TO_DATE('JUN 141989',
'MON DD YYYY'}
El estndar SQL2 especifica un formato para las constantes de fecha y hora basado en el formato de la Tabla 5.5, excepto en. que las constantes de hora se escriben con dos puntos, en lugar de puntos, para separar las horas, minutos y segundos.
Constantes simblicas
Adems de las constantes proporcionadas por el usuario, el lenguaje SQL incluye constantes simblicas especiales que devuelven valores de datos mantenidos por el propio SGBD. Por ejemplo, en algunas marcas de SGBD, la constante simblica CURRENT_DATE da el valor de la fecha actual y se puede usar en consultas como la siguiente, que lista los representantes cuya fecha de contrato est an en el futuro:
SELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO > CURRENT_DATE
Ntese que, sin embargo, no se puede almacenar una duracin en la base de datos, ya que DB2 no tiene un tipo de datos explcito DURATION. SQL Server tambin alberga los datos de fecha y hora, y acepta una variedad de formatos diferentes para las constantes de fecha y hora. El SGBD acepta automticamente todos los formatos alternativos, y se pueden entremezclar si se desea. Aqu hay algunos ejemplos de constantes de fecha legales en SQL Server:
March 15, 1990 Mar 1S 1990 3/15/1990 3-15-90 1990 MAR 15
y aqu hay algunas constantes de tiempo legales:

15:30:25 3:30:25 PM 3:30:25 pm 3 PM
Las fechas y horas de Gracle tambin se escriben como constantes de cadena, usando este formato:
15-MAR-90
Tabla 5.5.
Formatos de fecha y hora en SOL de IBM
Fonnato:
Ejemplo
de fecha
511911960
Fonnato
debora
, ombre, del formato

American (americano) European (europeo) Japanese (japons) ISO Formato TIMESTAMP
de la fecha
mmldd/yyyy
Ejemplo de hora
El estndar SQLl e'specificaba slo una nica constante simblica (la constante USER descrita en el Captulo 15), pero la mayora de productos:SQL proporcionan muchas ms. ,Generalmente, una constante simblica puede ~parecer en una instruccin SQL en cualquier lugar en que pueda aparecer cualquier constante ordinaria del mismo tipo de datos. El estndar SQL2 adopt las constantes simblicas ms tiles de las implementaciones SQL y proporciona CURRENT_DATE, CURRENT_TIME y CURRENT_TIMESTAMP (obsrvense los caracteres de subrayado), as como USER, SESSION_USER y SYSTEM_USER. Algunos productos SQL, incluido SQL Server, proporcionan acceso a los valores del sistema mediante funciones predefinidas, en lugar de constantes'simblicas, La versin de SQL Server para la consulta anterior es:
SELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO> GETDATE(}
hh:mm am/pm 2: 18 PM hh.mm.ss hh:mm:ss hh.mm.ss 14.18.08 14:18:08 14.18.08
dd.mm.yyyy yyyy-mm-dd
yyyy-rnrn-dd yyyy-rnrn-dd hh.mm.ss.nnn .nnn
19.5.1960 1960-5-19 1960-5-19
Las funciones predefinidas se describen ms tarde en este captulo, en la seccin Funciones predefinidas.
Expresiones
Las expresiones se usan en el lenguaje SQL para calcular-valores que se recuperan de una base de datos y para calcular valores uSdos en las bsquedas. Por
Ejemplo de TIMESTAMP
1960-05-19-14. 18.08.048632
~-----
90
Captulo 5: Fundamentos_de SaL
91
ejemplo, esta consulta calcula las ventas de cada oficina como un porcentaje de su objetivo: .
SELECT CIUDAD, OBJETIVO. VENTAS, (Vf;NTAS!OBJETIVO)
~
de DB2 MONTH () y YEAR (l toman un valor DATE o TIHE$TAMP como -entratla y de: vuelven un enter que es el mes b porcin del ao "Bel valor. Esta consulfillista el nombre y mes de contratacin de cad~ representante en la base de datos de ejemplo:
SELECT NOMBRE, MONTH(FECHA_CONTRATO) FROM REPRESENTANTES
100
FRQM OFICINAS
y esta consulta lista las oficinas cuyas ventas superan en sq.OOO al objetivo:
y esta lista
SELECT CIUDAD FROM OFICINAS
1. ,:
todos los -representantes contratados en 1988:
WHERE VENTAS> OBJETIVO + 50000.00
SELECT NOMBRE, MONTH(FECHA_CONTRATO) FROM REPRESENTANTES WHERE YEAR(FECHA_CONTRATO = 1988
El estndar SQL de ANSI/ISO especifica cuatro operaciones aritmticas"que se pueden usar en expresiones: suma (X+Y), resta (X-Y), multiplicacin (X*Y) y divisin (XlY). Se, pueden usar.,parntesisl para formar expresiones ms.complica... ..~j, .) .. 1 das.-como,sta:.' ;. '1:
.. ,~'J
(VENTAS
~.
-'o '., " .. '1.05) -
1.... :.;
"
_.~,
,(OBJETIVO.~
.9?) ..
Las funciones predefinidas tambin se usan habitualmente para dar formato a los datos. La funcin predefinida de Orade' TO_CHAR ( ) , por ejemplo, toma un tipo de datos DATE y una especificaCin de formato como argumentos, y devuelve una cadena conteniendo la versin 'con formato de la fecha. En los resultados producidos por esta consulta:
SELECT NOMBRE, TO_CHAR(FECHA_CONTRATO. 'OAY MONTH 00, yyyy.) FROM REPRESENTANTES
, , De manera estricta. los parntesis no se necesitan en esta consulta porque el estndar ANSI/ISO especifica que la multiplicacin y la divisin tienen una precedencia superior a la suma y la resta. Sin embargo, se deberan usar parntesis siempre para que las expresiones no sean ambiguas. 'dado que diferentes dialectos SQL usan diferentes reglas. Los parntesis tambin incrementan la legibilidad de la instrucCin y hacen que 'las instruccones S.QL sean ms fciles de mantener.' 'El estndar ANSI/ISO tambin 'especifica la conversin automtica de ti'pos de datos de enteros a nmeros 'decimales, y de nmeros decimales a n,meros en coma flotante. Por tao, se pueden mezclar estos tipos 'de datos en una expresin mim.rica.'MuchasiInpleme.ntacines SQL albergan otros operadores y' admiten operaciones sobre datos de carter y de "fecha. DB2, por ejemplo, alberga el operador de concatenaCin'de cadenas', escrit<:l"como dos caracteres consecutivos 'de'barra vertical (11). Si las columnas NOMBRE y '-?>PELLIDO contienen los valores Juan y Garca, entonces esta 'expresin' DB2: 1 /, ' " 1
. ,"
'~l ~
todas las fechas endrri el fonnato Wednesday June 14, 1989 debido a la funcin predefinida. _. En general, las funciones pre.definidas se pueden especificar en cualquier lugar de una expresin SQL en que ,pueda aparecer una constante del mismo tipo de datos. Las funciones pr~efinidas inluidas en los dialectos SQI: populares son demasiado numerosas p~a listarl~~ :aqu. Los dialectos de SQL de IBM incluyen cerca de dos docenas de funciones predeterminadas, y SQL Server tiene varias docenas, 'El estndar SQL2'incorpora las fnncioneS 'pretlefinidasm's tiles de estas implementaciones, en muchos .casos con una sintaxis ligeramente diferente. En la Tabla 5.6 se'-restimen estas"fun~ciones.
,.. :_.
t,"
,."
(. Sr ./Sra.
1I
NOMBRE
11' ....
11
APELLIDO)
Datos ausentes (valores NUL'LJ

DadQ_que una.base. de datos es. usualmente un.modelo de una situacin del mundo real, varias piezas de datos estarn inevitablemente ausentes, sern desconocidas o simplemente no se podrn aplicar. As, en la base de datos de ejemplo. la columna CUOTA de la tabla REPRESENTANTES contiene el objetivo de 'ventas de cada representante. Sin embargo, el ltimo representante contratado an no tiene asignada cuota; este dato est ausente en esa fila de la tabla.'lCabra estar tentado de poner un cero en esa columna, pero no sera un reflejo fiel de la situacin. El representante no tiene una cuota cero la cuota simplemente no se conoce an. ~l De forma similar, la columna DIRECTOR de la tabla REPRESENTANTES contiene el nmero de empleado de cada' jefe del representante. Pero Sarnuel Clavel,
produce la cadena Sr.lSra. Juan Garca. Como ya se ha mencionado. DB2 tambin alberga la suma y resta de datos DATE, TIME Y TIMESTAMP en las ocasiones en que estas operaciones tienen sentido. Esta capacidad se ha incluido en e est~ndar SQL2, _,
Funciones predefinidas
Aunque el estndar SQLl no las especifica, la mayora de las implementaciones SQL incluye~ varias funciones predefinidas. Estas facilidades proporcionan a menudo conversiones de tipos de. datos: Por ejemplo. las funciones 'predefinidas
92
93
Tabla 5.6.
Funcin"
BIT_LENGTH CAST
Funciones predefinidas de SGL2
Devuelve
(valor
AS
(cadena) tipo_de_datos)
El nmero de bits en una cadena de bits.
El valor, convertido al tipo de datos especificado (por ejemplo, llna fecha convertida a una cadena de caracteres).
La longitud de una cadena de caracteres. Una cadena convertida como se especifica por la funcin de conversin.
CARACTER_LENGTH CQNVERT
(cadena
USING
(cadena) conv)
CURRENT_DATE CURRENT_TlME
La
(precisin) (precisin) origen)
fe~ha
actual.
La hora actual, con la precisin especificada. La hora y fecha actual, con la precisin especificada. La parte especificada (DAY, HOUR, etc.) de un valor DATETIME. Una cadena convertida a minsculas. El nmero de bytes de 8 bits de una cadena de caracteres. La posicin en donde aparece objetivo dentro de la cadena origen. Una porcin de la cadena origen,
CURRENT_TIMESTAMP EXTRACT
(parte
FROM
LOWER
(cadena) (cadena)
IN
OCTET_LENGTH
datos real, como 0,473,83 o Samuel Clavel. En cambio, es una seal, o recordatorio, de que el valor de datos est ausente o es desconocido. La Figura 5.3 muestra los contenidos de la tabla REPRESENTANTES. Ntese que los valores de CUOTA y OFICINA_REP de Toms Saz y el valor de JEFE de Samuel Clavel en la tabla tienen todos valores NULL. En muchas situaciones los valores NULL requieren del SGBD un manejo especial. Por ejemplo, si el usuario solicita la suma de la columna CUOTA, cmo se deberan manejar los datos ausentes al calcular la suma? La respuesta la da un conjunto de reglas especiales que gobiernan el manejo de los valores NULL en varias instrucciones y clusulas SQL. A causa de las reglas, algunas personalidades importantes en bases de datos estn convencidas de que no se deberan usar los valores NULL. Otros, incluyendo al Dr. Codd, han proclamado el uso de los diferentes valores NULL, con indicadores distintivos para los datos desconocidos y no aplicables. Independientemente de los debates acadmicos, los valores NULL son una parte muy enraizada del estndar SQL de ANSI/lSO y se admiten en prcticamente todos los productos comerciales de SQL. Tambin desempean un papel prctico e importante en las bases de datos de produccin. En este libro se resaltan las reglas especiales que se aplican a los valores NULL (y los casos en los que estos valores se manejan de forma consistente en diferentes productos SQL).
POSITION
(objetivo (origen
origen) n
FOR
Resumen
Este captulo ha descrito los elementos bsicos del lenguaje SQL. La estructura bsica de SQL se puede resumir como sigue: El lenguaje SQL usado habitualmente incluye unas 30 instrucciones, y cada una consiste en un verbo y una o ms clusulas. Cada instrucci6n realiza una nica funcin especfica.
SUBCADENA
FROM
longitud)
TRANSLATE TRIM (BOTH
(cadena
USING FROM
trad)
cadena) cadena)
carcter
TRIM (LEADING
carcter
FROM
TRIM (TRAILING
carcter
FROM
cadena)
UPPER
(cadena)
comenzando en el ensimo carcter, en una longitud longitud. Una cadena traducida como se especifica por la funci6n de traduccin. Una cadena con las apariciones a ambos lados de carcter eliminadas. Una cadena con cualquier nmero de apariciones de carcter al principio eliminadas. Una cadena con cualquier. nmero de apariciones de carcter al final eliminadas. Una cadena convertida a maysculas.
Tabla REPRESDnANTES
NU~ ~PL
vicepresidente de Ventas, no tiene ningn jefe en la organizacin de ventas. Esta columna no se aplica a SamueL De nuevo, se podra pensar en introducir un cero o 9999 en la columna, pero ninguno de estos valores sera el nmero de empleado del jefe de SamueL Ningn valor de datos es vlido para esta columna. SQL admite explcitamente datos ausentes, desconocidos o no aplicables mediante el concepto de los valores nulos. Un valor nulo es un indicador que dice a SQL (y al usuario) que el dato est ausente o no es aplicable. Por conveniencia, un dato.omitido se dice que tiene el valor NULL. Pero el valor NULL nQ es un valor de
<
'"' '" '" , '" no '" '" '" '"
..
Bruno AnO!a a Maria Ji.....n. . S"Mna SaHos sa",,,el Clavel Bernardo S&nche. Oaniel Ruidrol>o To..... S~z Lebn Free Pablo Cr"~ Ne"s A.~~rate
"~~
,~,
"
" " " " "
" '"
OFICINA REP 13 11 21 11 n 12 12 4l NULL 21 12
PUESTO Re ruenUn'e Re resMtanU Re ruentante VP Ventas Jefe Venta. Re r ... enUn'e Re re.entante Jefe Ventas Re r ... enUn'e Re reuntan.e
nCII" CONTR1ITO 1210211988 12!IOf1989 10/12/1986

14/06fl988 19f0511981
,m
NULL
'" '"' '" , '" '"
20flO/19a6 13/01/1990 12/10/1989 01/03/1981 14fl1/1968
. .. '"
..
350.000,00E: 300.000,00';; 350.000,001: 215.000,00& 200.000,00E: O.OOO,OOE NULL 50.000.00e 215.000,Ooe ~00. 000, ooe
,~"
VENtAS 361.911,00E: 392.125.00';; 414.0S0.001: 299.9H,00e 142.594,ooe

~05.613.00e
1S.9S5,001: 361.865,OOe 286.17S.00E 186.042.001:
Valor desconocido
/
"
REPRESENTANTES.
Valor desconocido
Figura 5.3.
Valores
NULL
en la tabla
94
Las bases.de datos basadas en SQL pueden almacenar varios tipos de datos, incluyendo texto, enteros, nmeros decimales, nmeros en coma flotante y, usualmente, muchos otros tipos de datos especficos del propio fabricante. Las instrucciones SQL pueden incluir expresiones que combinan nombres de columna, constantes y funciones predefinidas, usando'operadores aritmticos y otros especficos del propio fabricante. Las variaciones en los tipos de datos, constantes'y funciones predefinidas hacen que la transportabilidad de las instrucciones SQL sea ms difcil que lo que pudiera parecer en un primer momento. Los valores NULL proporcionan una forma sistemtica de manejar datos ausentes o no aplicables en el lenguaje SQL.
CAPTULO
Consultas simples
Por muchas razones, las consultas son el corazn del lenguaje SQL. La instruccin SELECT, que se usa para ~xpresaf. consultas SQL, es la instruccin ms potente y compleja de las instrucciones SQL. A pesar de las muchas opciones que ofrece la instruccin SELECT, es posible comenzar simplemente y despus construir consultas ms complejas. Este captulo estudia las consultas SQL ms simples -las que recuperan datos de una nica tabla de la base de datos.
La instruccin
5ELEC'l'
La instruccin SELECT recupera datos de una base de'datos y los devuelve'en forma de resultados, de la.consulta: Ya se han' examinado muchos ejemplos de. la instruccin SELECT enJa iJ;ltroduccin.a SQL del Captulo 2. Aqu hay algunas otras consultas de ejemplo que recuperan informacin sobre las oficinas comerciales:
Listqr las .oficin~s
~~~er.qi.aJ._es c~n sus objeti~os y ve,ntas actua:li;..

VENTAS -VENTAS ..
:- - - - -.- :-~. -,. -:-:: 7'
SELECT CIUDAD, "OBJETIVO, FROM OFICINAS CIUDAD

~'-.------;.-
Dairnie Navarra Caste1l6n Almera Len.
------------300.000,00
575.000,00 800.000,00 350.000,00 125.00_0,00
O~ETIVO
186.042,OO. 692'.637 ;o 735.042,00 367.911. 00 835.915,00 .
Listar las ofiinas comerciales de la regin Este . .

SELECTO CIUDAD, OBJETivo, FROM OFICINAS WHERE REGlON = 'Este' VENTAS ..
0
ccm sus,obje"tivos.Yventas. ... "
95
-'--
96
CIUDAD

OBJETIVO
VENTAS
Captulo 6: Consultas simples
97
Navarra Caste116n Almera
----------- ------------- ------------575OOO,OO 800.000,00 350.000,00
692.637,00 735.042,00
367.911,00
f--SELECT-t;
MJ.i
d
especificacin
elementode-
If;cn,.
1
Listar las oficinas comerciales de la regin Este cuyas ventas excedan sus objetivos y ordenadas segn el nombre de ciudad.
SELECT CIUDAD,
FROM OFICINAS
DISTINC
OBJETIVO,
VENTAS
""'-- FROM
WHERE REGlON = 'Este' AND VENTAS > OBJETIVO ORDER BY CIUDAD

CIUDAD OBJETIVO VENTAS
-- , ---'-
Almera
350.000,00
367.911,00
Navarra
575.000,00
692:637,00
L L,
WHERE condIn-de-
bsqueda
,Cules son los objetivos y ventas de las oficinas de la regin Este?

SELECT AVG(OBJETIVO) , AVG(VENTAS FRQM OFICINAS WHERE REGlON = 'Este'
GROUP BY~:cin
columna-de-
AVG(OBJETIVO)
575.000,00
AVG(VENTAS)
598.530,00
LHAVING L,
Figura 6.1.
condin-debsqueda
especifican-de-
aRDER BY~~acin
,
SELECT.
Para las' consultas simples, la solicitud en ingls y la instruccin SELECT de SQL son muy similares. Cuando la solicitud se torna m.s complicada, se deben usar ms caractersticas de la instruccin SELECT para especificar de forma precisa la consulta. La Figura 6.1 muestra la forma completa de la instruccin SELECT, que consiste en seis clusulas. Las clusulas SELECT y FROM son obligatorias. El resto de clusulas es opcionaL Slo se incluyen en una instruccin SELECT cuando se quiere usar las funciones que proveen. La siguiente lista resume la funcin de cada clusula: La clusula SELECT lista los elementos de datos a recuperar por la instruccin SELECT. Los elementos pueden ser columnas de la base de datos o columnas calculadas por SQL al procesar la consulta. La clusula SELECT se describe en la siguiente seccin. La clusula FROM lista las tablas que contienen los datos a recuperar por la consulta. En este captulo se describen las consultas que toman datos de una nica tabla. Las consultas ms complejas que combinan datos de dos o ms tablas se estudian en el Captulo 7. La clusula WHERE informa a SQL de que incluya slo ciertas filas de datos en los r~sultados de la consulta. Se usa una condicin de bsqueda para especificar las filas deseadas. Los usos bsicos de la clusula WHERE se descri-
Diagrama sintctico de la instruccin
ben en la seccin Seleccin de filas (clusula WHERE)>>, ms adelante en este captulo. Las que conllevan subconsultas se estudian en el Captulo 9. La clusula GROUP BY especifica una consulta de resumen. En lugar de producir una fila de resultados por cada fila de datos de la base de datos, agrupa filas similares y produce una fila de resumen de los resultados de cada grupo. Las consultas de resumen se describen en el Captulo 8. La clusula HAVING indica a SQL que incluya en el resultado slo determinados grupos producidos por la clusula GROUP BY. Al igual que la clusula WHERE, usa una condicin de bsqueda para especificar los grupos deseados. La clusula HAVING se describe en el Captulo 8. La clusula ORDER BY ordena los resultados tomando como base los datos de una o ms columnas. Si se omite, los resultados no se ordenan. La clusula aRDER BY se describe en la seccin Ordenacin de los resultados de las consultas (clusula ORDER BY)>>, ms adelante en este captulo.
98
I
Sal interactivo
,99
La clusulasELEcT
La clusula SELECT con la que comi~nza cada instruccin SELECT especifica los elementos de datos que recupera la consulta. Los elementos se especifican usual mente por una lista de seleccin, una lista de elementos de seleccin separados por comas. Cada elemento de seleccin en la lista genera'una nica columna de resultados de la consulta, de izquierda a derecha. Un elemento de seleccin puede ser: Un nombre de Lolumna. que identifica una columna de la tabla o tablas que aparecen en la clusula FROM. Cuando aparece un nombre de columna como elemento -de selecci, SQL -simplemente toma el valor de esa columna de cada fila de la tabla de la base de datos y lo pone en la fila correspondiente de los resultados de la consulta: Una constante, que especifica que ese mismo valor de constante aparecer en cada fila-de-los resultados de fa c6sulta. Una expresin SQL. que indica que SQL debe calcular el valor a poner en los resultados, segn se especifica en la expresin En este captulo se describe cada tipo de elemento de seleccin.
SELECr CIUDAD, REGIN FROM OFICINAS
I
Programa .1 Programacin con Sal
Consulta
---
--Resultados de la consulta
CIUDAD Daimiel Navarra Castelln Almeria Len REGIN oeste Este Este Este Oeste
1+-
-' SGBD
Consulta
Base de dato
,., ..
La clusula
FROM
Figura 6.2.
la estructura tabular de los resultados de las consultas SOL.
La clusula FROM c0nsiste en la-palabra clave FRDM seguida por-una lista de especificaciones de tabla separadas-por comas. Cada especificacin de tabla identifica una tabla que contiene datos a recuperar por la consulta. Estas tablas se denominan tablas fuente, de la consulta (y de la instruccin SELECT), porque son la fuente de todos'los 'datos de los resultados: Todas las consultas de este captUlo tienen una nica tabla fuente, y cada clusula FROM contienen un ~ico 'nombre de tabla.
'1, l'
Listar los nombres, oficinas y fechas de contratacin de todos los lrepresentantes.

SELECT NOMBRE, OFICINA_REP, FROM REPRESENTANTES FECHA_CONTRATO
.,.
"
Resultados de las consultas

"',,
El resultado de una consulta' SQL. es siempre uria tbla . .de datos, como las de la base de datos. Si se escribe-una instruccin SELECT usando SQL interactivo, el SGBD 'muestra los resultados deforma.tabular en-la/pantalla de la computaoora. SI un programa enva 'un consulta al SGBD usando'..programacin con SQL, se devuelve la tabla de resultados al programa, En cua1quier caso, los resultados siempre tienen el mismo formato de filas y columnas que las tablas reales de la base de datos, como se muestra en la Figura 6.2. Los'resultados de una clusula sonusualmente una tabla cOn varias filas y columnas. Por ej"hlplo, -esta' consulta produce una tabla'de tres columnas (porque pide tres elementos de datos) y diez filas (porque hay 10 representantes)" 0 e
NOMBRE
Bruno Arteaga
Mar~a,y'iI!'nez
13 12-FEB-88
'In
Susana Santos Samuel Clavel Bernardo Snchez DanielJ Ru-idrobo- - .,.. ,,-' Toms Saz Len Freire. Pablo C:r;uz Neus Azc'ra te
21 11 12 12 NULL 21
12-0<;:1'-89 10-DIC-..86 14-JUN-88 i'9-MAY-87 20':"OCT-86 13-ENE-90 12-0CT-B9 12 01-MAR~B7 22 14-NOV-88
En cambio, la siguiente consulta produce una nica fila porque slo un representante tiene el nmero de empleado requerido. Aunque esta nica fila de resultados parezca menos tabular que los resultados multifila, SQL lo considera una tabla de tres columnas y una fila_ .
100

NOMBRE CUOTA

JEFE 104 106
101
Cules son el nombre. la cuota y las ventas del empleado nmero 107?
SELECT NOMBRE. CUOTA, VENTAS FROM REPRESENTANTES WHERE NUM_EMPL : 107 NOMBRE Neus Azcrate
CUOTA
300.000.00
VENTAS
186.042.00
En algunos casos, los resultados de una consulta pueden ser un nico valor, como en el siguiente ejemplo:
Cules son las ventas promedio de nuestros represen/antes?
SELECT AV~(VENTAS) FROM REPRESENTANTES
AVG (VENTAS)
Bruno Arteaga Maria Jimnez Susana Santos samuel Clavel Bernardo Snchez Daniel Ruidrobo Toms Saz Le6n Freire Pablo Cruz Neus Azcrate
350.000,00 300.000,00 350.000.00 275.000,00 200.000.00 300.000.00 NULL 350.000,00 275.000,00 300.000.00
lOa
NULL 106 104 101 106 104
loa
289.353,20
El hecho de que una consulta SQL produzca siempre una tabla es importante. Significa que los resultados de la consulta se pueden almacenar como una tabla en la base de datos. Significa que el resultado de dos consultas similares se pueden combinar para formar una tabla mayor de resultados. Finalmente, significa que los resultados de una consulta pueden ser el objetivo de otras consultas posteriores. Una estructura tabular de una base de datos relacional tiene, por tanto, una relacin sinrgica con las capacidades de las consultas relacionales de SQL. Las tablas se pueden consultar y las consultas producen tablas.
Estos resultados son una tabla, aunque una muy pequea que s610 tiene una fila y una columna. Finalmente, es posible que una consulta no produzca ninguna fila como resultado, como en este ejemplo:
Consultas simples
Las consultas ms simples solicitan columnas de datos de una nica tabla de la base de datos. Por ejemplo, esta consulta solicita tres columnas de la tabla OFICINAS:
Listar el nombre y fecha de coiltrato de quienes tengan ventas superiores a 500.000 f.

SELECT NOMBRE. FECHA_CONTRATO FROM REPRESENTANTES WHERE VENTAS> SOOOOO.OO NOMBRE FECHA_CONTRATO
Listar la ubicacin, regin y ventas de cada oficina comercial.

SELECT CIUDAD, REGION. VENTAS FROM OFICINAS CIUDAD REGlaN VENTAS
186.042,00 692.637,00 735.042,00 367.911,00 835.915,00
Incluso en esta situacin los resultados son una tabla. En este caso es una tabla vaca, con dos columnas y ninguna fila. Ntese que el soporte de SQL par~ dalos ausentes se extiende tambin a los resultados de las consultas. Si un elemento de datos de la base de datos contiene un valor NULL, el valor NULL aparecer en los resultados de la consulta cuando se recupere el elemento de datos. Por ejemplo, la tabla REPRESENTANTES contiene valores NULL en sus columnas CUOTA y JEFE. La siguiente consulta devuel ve estos valores NULL en la segunda y tercera columnas de los resultados de la consulta.
Daimiel Navarra Caste1l6n Almeria Le6n
Oeste Este Este Este Oeste
Listar los representantes, sus cuotas y sus jefes.

SELECT NOMBRE, CUOTA, JEFE FROM REPRESENTANTES
La instruccin SELECT, para consultas simples como sta, incluye slo las dos clusulas requeridas. La clusula SELECT da nombre a las columnas requeridas; la clusula FROM da nombre a la tabla que las contiene. Conceptualmente, SQL procesa la consulta examinando la tabla referenciada en la clusula FROM, de fila en fila, como se muestra en la Figura 6.3. Por cada fila, SQL toma los valores de las columnas requeridas en la lista de seleccin y produce una nica fila de resultados. La consulta devuelve as una fila de datos por cada fila de la tabla.
102

Castelln Almera Len
REGIN
JEF

Este Este Oeste -64.958,00 E 17.911,00 110.915,00
103
Tabla OFICINAS
OFICINA
CIUDAD
OBJETIVO
VENTAS
186.042,OO
22 Daimiel
11
Navarra
Oeste Este
Este
12 cast.elln 13 Almera 21 Len
ESte oeste
loa 106 104 lOS 108
300.000,Dae
575.000,OO BOa.OOO.ooe 3S0.000,OO
692.637,OO
7J5.Q42,OO
nS.ODO.OO
367.911.00 835.915.00
Para procesar la consulta, SQL va a las oficinas y genera una fila de resultados por cada fila de la tabla OFICINAS, como se muestra en la Figura 6.4. Las dos primeras columnas de resultados vienen directamente de la tabla OFICINAS. La tercera columna de resultados se calcula, fila a fila, usando los valores de datos de la fila en curso de la tabla OFICINAS. Aqu hay otros ejemplos de consultas que usan columnas calculadas:
Mostrar el valor del inventario de cada producto.

CIUDAD
Daimiel
REGIN
OBJETIVO
SELECT ID_FAB, ID_PRODUCTO, FROM PRODUCTOS ID_FAS REI 'CI ID_PRODUCTO
DESCRIPClON,
(STOCK
PRECIO)
Resultados de la consulta
Navarra
Cast.elln
Almera
oeste Este
Est.e
-1l3.958,OO
117.637,OO
~64.958.00
LoOn
Este Oeste
17.911,OO llO.915.00
--------------- -------------------------- Rueda 2A45C 16.590,00

4100Y XK47 41672 779C 41003 41004 41003 Zapata pequei'ia Reductora Plato 90-kg brazo Serie 3. cable Serie 4. cable Hlice 68.750,00 13 .490, 00 0,00 16.875,00 22.149,00 16.263.00 1.956,00
DESCRIPCION
(STOCK~PRECIO)
QS'
Figura 6.3.
Procesamiento de una consulta simple (sin clusula WHERE).
BIC IMM 'CI 'CI BIC
Columnas calculadas
Adems de las columnas cuyos valores vienen directamente de la base de datos, una consulta SQL puede incluir columnas calculadas, cuyos valores se obtienen a partir de los valores -de datos almacenados. Para solicitar una columna calculada se especifica una expresin SQL en la lista de seleccin. Como se estudi en el Captulo 5, las expresiones SQL pueden incluir la suma, la resta, la multiplicacin y la divisin. Tambin se pueden usar parntesis para construir expresiones ms complejas. Por supuesto, las columnas referenciadas en una expresin aritmtica deben tener un tipo numrico. Si se intenta sumar, restar, multiplicar o dividir columnas que contengan datos textuales, SQL informar de un error. Esta consulta muestra una columna calculada simple:
Tabla PRODUCTOS
PRECIO > 2 OOO ID FAB ID PRODUCTO ACI 4100Y REI 2A44L 4100Z 'CI REI 2A44R
-..-.
Resultados de la con sulta
Tabla PEDIDOS
1
1--->
FAB REI REI IMM
UNIN
}--+
Listar la ciudad, regin y cantidad por encima o por debajo del objetivo de cada oficina.
SELECT CIUDAD, REGlON. FROM OFICINAS CIUDAD Daimiel Navarra REGlON Oeste . Este (VENTAS
d
OBJETIVO)
PRODUCTO 2A44L 2M4R 775C
'CI REI ACI REI REI REI IMM
4100Y 2A44L 4100Z 2A44R 2A44L 2A44R 775C
(VENTAS-OBJETIVO) -113.958,00 E 117.637,00
CANTIDAD > 30.000
Figura 6.4.
Procesamiento de consultas con una columna calculada.
104
105
Mostrar los resultados si se eleva la cuota de cada representante en un 3 por ciento de las ventas de este ao.
SELECT NOMBRE, CUOTA, (CUOTA
sultados se muestran en pantalla, pero es crucial en la programacin con SQL cuando los resultados se recuperan con un programa y se usan para clculos.
(. 03'"'VENTAS)
FROM REPRESENTANTES NOMBRE CUOTA (CUOTA+(,03*VENTASI)
Seleccin de todas las columnas

361.037,33 311. 781, 15 364.221,50 283.997,36 204.277,82
309.170,19
NULL
(SELECT
*)
Bruno Arteaga
Mara Jimnez
Susana Santos Samuel Clavel Bernardo Snchez Daniel Ruidrobo
Toms Saz
Len Freire
Pablo Cruz
Neus Azcrate
350.000,00 300.000.00 350.000.00 275.000,00 200.000,00 300.000,00 NULL 350.000,00 275.000,00 300.000,00
A veces es conveniente mostrar el contenido de todas las columnas de una tabla. Esto puede ser particularmente til cuando se afronta una nueva base de datos y se desea obtener una idea rpida de su estructura y de los datos que contiene. SQL permite usar un asterisco (*) en lugar de la lista de seleccin como abreviatura de todas las columnas: Mostrar todos los daros de la tabla
SELECT FROM OFICINAS OFICINA CIUDAD 22 11 12 13 21 OFICINAS.
360.855,95 283.603,25 305.581,26
Como se mencion en el Captulo 5, muchos productos SQL proporcionan operaciones aritmticas adicionales, operaciones sobre cadenas de caracteres y funciones predefinidas que se pueden usar en las expresiones SQL. stas pueden aparecen en las expresiones de la lista de seleccin, como en el siguiente ejemplo con DB2. Listar el nombre. mes y ao de contrato de cada representante.
SELECT NOMBRE, MONTH(FECHA_CONTRATOI, FROM REPRESENTANTES YEAR(FECHA_CONTRATOI
------------ ------- ---- ------------- ------------- 186.042,00 Daimiel Oeste 108 300.000,00
Este Este Este Oeste 106 lO' 105 108 575.000,00 800.000,00 350.000,00 725.000,00
REGlaN
JEF
OBJETIVO
VENTAS
Navarra Castelln A1meria Len
692.637,00 735.042,00 367.911,00 835.915,00
Las constantes SQL tambin pueden ser tiles por s mismas como elementos de una lista de seleccin. Esto puede ser til para producir resultados que sean ms fciles de leer e interpretar, como en el siguiente ejemplo. Listar las ventas de cada ciudad.
SELECT CIUDAD, 'tiene unas ventas de' , VENTAS FROM OFICINAS CIUDAD Daimiel Navarra Castel1n A1mera Len TIENE UNAS VENTAS DE VENTAS
Los resultados de la consulta contienen las seis columnas de la tabla OFICIen el mismo orden, de "zquierda a derecha, que la tabla. El estndar de SQL ANSUISO especifica que una instruccin SELECT puede tener una seleccin de todas las columnas o una lista de seleccin, pero no ambas, como se muestra en la Figura 6.1. Sin embargo. muchas implementaciones de SQL tratan el asterisco slo como un elemento ms de la lista de seleccin (*). As, la consulta:
NAS,
SELECT (SALES - TARGET) FROM OFFICES
----------
--------------------- ------------tiene unas ventas de 186.042,00

tiene tiene tiene tiene unas unas unas unas ventas ventas ventas ventas de de de de 692.637,00 735.042,00 367.911,00 835.915,00
Los resultados de la consulta parecen consistir en una frase independiente para cada oficina, pero son realmente una tabla de tres columnas. La primera y tercera columnas contienen valores de la tabla OFICINAS. La segunda columna contiene la misma cadena de 20 caracteres. Esta distincin es sutil cuando los re-
es legal en la mayora de los dialectos comerciales de SQL (por ejemplo, en DB2, Oraele y SQL Server), pero no se permite en el estndar ANSI/ISO. La seleccin de todas las columnas es ms apropiada cuando se usa SQL interactivo. Se debera evitar en la programacin con SQL porque los cambios de la estructura de la base de datos pueden hacer que el programa falle. Por ejemplo, supngase que la tabla OFICINAS se haya eliminado de la base de datos y se haya recreado con sus columnas reorganizadas y con una nueva sptima columna. SQL se hace cargo automticamente cargo de los detalles concernientes a la base de datos de tales cambios, pero no puede modificar el programa de aplicacin. Si el programa espera que la consulta SELECT FROM OFICINAS devuelva seis columnas como resultado con ciertos tipos de datos, dejar de funcionar cuando las columnas se reorganicen y se aada una nueva.
106
107
Estas dificultades se pueden evilar si se escribe el programa para solicitar las columnas que se necesitan segn su nombre. Por ejemplo, la siguiente consulta produce los mismos resultados que SELECT* FROM OFICINAS. Es tambin inmune a los cambios de la estructura de la base de datos, siempre que no cambien los nombres de las columnas referenciados de la tabla OFICINAS:
SELECT OFICINA, CIUDAD, FROM OFICINAS REGlON. JEF. OBJETIVO, VENTAS
Filas duplicadas (DISTINCT)

Si una consulta incluye la clave primaria de una tabla en su lista de seleccin, entonces cada fila de los resultados ser nica (dado que la clave primaria tiene un valor diferente en cada fila). Si la clave primaria no se incluye en los resultados de la consulta. pueden aparecer filas duplicadas. Por ejemplo. supngase que se hace esta solicitud:
Conceptualmente, SQL resuelve esta consulta generando en primer lugar el conjunto completo de resultados (cinco filas) y eliminando despus las filas que son duplicados exactos para formar los resultados definitivos de la consulta. La palabra clave DI8TINCT se puede especificar independientemente de los contenidos de la lista SELECT (con ciertas restricciones sobre las consultas de resumen, como se describe en el Captulo 8). Si se omite la palabra clave DISTINCT, SQL no elimina las filas duplicadas. Tambin se puede especificar la palabra clave ALL para indicar explcitamente que se conserven las filas duplicadas, pero es innecesario porque es el comportamiento predeterminado.
Seleccin de filas (clusula WHERE)

Las consultas SQL que recuperan todas las filas de una tabla son tiles para el examen de la base de datos y para los informes, pero para poco ms. Usualmente no se desea seleccionar slo algunas de las filas de una tabla e incluir slo stas en los resultados de la consulta. La clusula WHERE se usa para especificar las filas que se desea recuperar. Aqu hay algunos ejemplos de consultas simples que usan la clusula WHERE:
Listar los nmeros de empleado de todos los jefes de oficinas comerciales.

SELECT JEF FROM OFICINAS
JBF
108
Mostrar las oficinas donde las ventas superen a los objetivos.

SELECT CIUDAD, VENTAS, OBJETIVO FROM OFICINAS WHERE VENTAS > OBJETIVO CIUDAD VENTAS
la.
104 105 108
Los resultados deJa consulta tienen cinco filas (una por cada oficina), pero dos de ellas son duplicados exactos, Por qu? Debido a que Len Freire es jefe tanto de la oficina de Len como de la de Daimiel, y su nmero de empleado (108) aparece en ambas filas de la tabla OFICINAS. Estos resultados no eran los que probablemente se pensara obtener. Si hay cuatro jefes diferentes, se debera haber esperado s610 cuatro nmeros de empleado en los resultados. Se puede eliminar las filas duplicadas de los resultados insertando la palabra clave DISTINCT en la instruccin SELECT justo antes de la lista de seleccin. Aqu se ofrece una versin de la consulta anterior que produce los resultados deseados:
-------Navarra Almera Le6n
------------- ------------- 692.637,00 575.000,00

367.911,00 835.915,00 350.000,00 725.000,00
OBJETIVO
Mostrar el nombre, ventas y cuota del nmero de empleado 105.

SELECT NOMBRE, VENTAS. FROM REPRESENTANTES WHERE NUM_EMPL = 105 NOMBRE Bruno Arteaga CUOTA
Listar los nmeros de empleado de todos los jefes de oficinas comerciales.

SELECT DISTINCT JEF FROM OFICINAS JEF
VENTAS 367.911.00
CUOTA 350.000,00
Mostrar los empleados subordinados de Bernardo Snchez (empleado nmero 104).

SELECT NOMBRE, VENTAS FROM REPRESENTANTES WHERE JEFE = 104
la'
105
la.
108
ti
108
NOMBRE

VENTAS
Captulo 6: Consuftassimp'les
109
Bruno Arteaga Daniel Ruidrobo Pablo Cruz
367.911,00 305.673.00 286.775,00
!~;
La clusula WHERE consiste en la palabra clave WHERE seguida de una condicin de bsqueda que especifica las filasa recuperar. En la consulta anterior, por ejemplo, la condicin de bsqueda es JEFE = 104. La Figura 6.5 muestra cmo funciona la clusula WHERE. Conceptualmente, SQL examina cada fila deJa tabla REPRESENTANTES, una a una, y aplica la condicin de bsqueda a la fila. Cuando aparece un nombre de columna en ]a condicin de bsqueda (como la columna JEFE en este ejemplo), SQL usa el valor de la columna en la fila en curso. Para cada fila, la condicin de bsqueda puede producir 'uno de los siguientes tres resultados: Si la condicin de bsqueda es TRUE, la fila se incluye en los resultados de la consulta. Por ejemplo, la fila de Bruno Arteaga tiene el valor correcto de JEFE y se incluye. Si la condicin de bsqueda es FALSE, la fila se excluye de los resultados de la consulta. Por ejemplo, la fila de Susana Santos tiene un valor de JEFE incorrecto y se excluye. Si la condicin de bsqueda tiene un valor NULL (desconocido), la fila se excluye de los resultados. Por ejemplo, la fila de Samuel Clavel tiene un valor NULL para la columna JEFE y se excluye. La Figura 6.6 muestra otra forma de pensar sobre el papel de la condicin de bsqueda de clusula WHERE. Bsicamente, la condicin de bsqueda acta como
NOMBRE Bruno Arteaga Mara Jimnez Susana Santos Samuel Clavel Bernardo Snchez Daniel Ruiclrobo
JEFE
104 106 108
- f-+
---<[-+
I~
NOMBRE Bruno Arteaga Daniel Ruidrobo Pablo Cruz
VENTAS
367.911,OO 305.673,OO 286.775,OO
NULL
106 104
~
Filtro
JEFE '" 104
Figura 6.6.
La clusula WHERE como filtro,
un filtro para las filas de la tabla. Las filas que satisfacen la condicin de bsqueda atraviesan el filtro y pasan a formar parte de los resultados. Las filas que no satisfacen la condicin de bsqueda quedan atrapadas por el filtro y se excluyen de, los resultados,
Condiciones de bsqueda
SQL ofrece un rico conjunto de condiciones de bsqueda que penniten especificar muchos tipos diferentes de consultas de forma eficiente y natural. Aqu se resumen cinco condicin bsicas de consulta (denominadas predicados en el estndar ANSUISO) y se describen en las secciones subsiguientes: Test de comparacin. Compara el valor de una expresin con el valor de otra expresin. Este test se puede usar para seleccionar las oficinas de la regin este o los representantes cuyas ventas estn por encima de sus cuotas. Test de ra;ngo. Comprueba si el valor de una expresin se encuentra en un rango especificado de valores. Este test se puede usar para hallar los representantes cuyas ventas estn comprendidas entre 100.000 y 500.000. Test de pertenencia a conjuntos. Comprueba si el valor de una expresin coincide con uno de un conjunto de valores. Este test se puede usar para seleccionar las oficinas ubicadas en Navarra, Castelln o Len. Test de encaje de patrones. Comprueba si 'el valor de una columna que contiene datos de cadena coincide con un patrn especificado. Este test se puede usar para seleccionar los clientes cuyos nombres comienzan por la letra E. Test de valores nulos. Comprueba si una columna tiene un valor NULL (desconocido). Este test se-puede usar'P4ra hallar los representantes que no tienen an un jefe asignado.
(
Tabla REPRESENTANTES NOMBRE Bruno Arteaga Mara Jimnez Susana Santos SaJIluel Clavel Bernardo snchez Daniel Ruidrobo
JEFE = 104
l'
\
TRUE
)
Resultados de la consulta NOMBRE Bruno Arteaga Daniel Ruidrobo Pablo Cruz FALSE VENTAS 367 911,00 305673,00 266775,00
<W: /
JEFE
"JEFE
5lli;
108 106 104
(NULL
\~
JEFE - 104
= 104
Desconocido
Figura 6.5,
Seleccin de filas con la clusula WHERE.
110
111
El test de comparacin
(=,
<>,
<,
<=,
>,
>=)
Listar las oficinas que no estn dirigidas por el nmero de empleado J08.
SELECT CIUDAD. JEF PROM OFICINAS WHERE JEF <> 108 CIUDAD JEF
La condicin de bsqueda ms usual en una consulta SQL es un test de compara-
cin. En un test de comparacin, SQL calcula y compara los valores de dos expresiones para cada fila de datos. Las expresiones pueden ser tan simples como un" nombre de columna o una constante, o pueden ser expresiones aritmticas ms complejas. SQL ofrece seis formas diferentes de comparar las dos expresiones, como se muestra en la Figura 6.7. A continuacin hay algunos ejemplos de test de comparacin.
Hallar los representantes contratados antes de 1988.
SELECT NOMBRE FROM REPRESENTANTES WHERE FECHA_CONTRATO < 'Ol-ENE-SS' NOMBRE
;,1
Navarra Caste1l6n Almeria
106 104 105
Como se muestra en la Figura 6.7, el test de comparacin se escribe A < > B, de acuerdo con la especificacin de SQL ANSI/ISO. Varias implementaciones de SQL usan notaciones alternativas, como A != B (usada por SQL Server) y A~=B (usada por DB2 y SQUDS). En algunos casos son formas alternativas; en otros, son la nica forma aceptable del test de desigualdad. Cuando SQL compara los valores de dos expresiones en el test de comparacin pueden ocurrir tres resultados: Si la comparacin es cierta, el test da un resultado TRUE. Si la comparacin es falsa, el test da un resultado FALSE. Si alguna de las dos expresiones devuelve un valor NULL. la comparacin devuelve un resultado NULL.
Recuperacin de una nica fila
Susana Santos Bernardo Snchez Daniel Ruidrobo Pablo Cruz
Listar las oficinas cuyas ventas estn por debajo del 80 por ciento de sus objetivos.
SELECT CIUDAD, VENTAS. OBJETIVO PROM OFICINAS WHERE VENTAS < (,S OBJETIVO)
t
CIUDAD
VENTAS 186.042,00
OBJETIVO 300.000,00
Daimiel
El test de comparacin ms comn es el que comprueba si el valor de una columna es igual a una ~onstante, Cuando la columna es una clave primaria, el test asla una nica fila de la tabla produciendo una nica fila de resultados de la consulta, como en este ejemplo:
Obtener e"l nombre y e/limite. de crdito del cliente nmero 2107.
- - - expresin-l - - , - - -
expresin-2
----+-
SELECT EMPRESA, LIMITE_CREDITO FROM CLIENTES WHERE NUM_CLI 2107 EMPRESA LIMITE_CREDITO 35.000,00
<>
<
Ace Internacional
<=
>
Figura 6.7.
Diagrama sintctico del test de comparacin.
Este tipo de consulta el es fundamento de los programas de recuperacin de datos de bases de datos basados en formularios. El usuario introduce un nmero de cliente en el formulario y el programa usa el nombre para construir y ejecutar una consulta, Despus se muestran los datos en el formulario. Ntese que las instrucciones SQL para recuperar un cliente en concreto por su nmero, como en este ejemplo, y la recuperacin de todos los clientes con ciertas caractersticas (como clientes con lmite de crdito superior a 25.000 ) tienen
I
1 11'
:~I
112
113
exactamente la misma forma. Los dos tipos de consultas (recuperacin segn la clave primaria y recuperacin basada en bsqueda de datos) seran operaciones muy diferentes en una base de datos no relacional. Esta uniformidad hace que SQL sea mucho ms simple de aprender y usar que otros lenguajes de consulta anteriores.
_exP'es;n-de-res'l
NOT jBE1'>1EEN
eXp'es;n-;nfedo,
ANO
exp'es;n-supedo, .....
Consideraciones sobre los valores
NULL
figura 6.8.
Diagrama sintctico del test de rango (BETWEEN).
El comportamiento de los valores NULL en los tests de comparacin pueden revelar que algunas nociones obviamente ciertas acerca de las consultas SQL no sean realmente ciertas. Por ejemplo, podra parecer que los resultados de estas dos consultas incluiran todas las filas de la tabla REPRESENTANTES:
El test de rango
(BETWEEN)
Listar los represellta1lIes que exceden su cuota.

SELECT NOMBRE FROM REPRESENTANTES WHERE VENTAS > CUOTA NOMBRE Bruno Arteaga Mara Jimnez Susana Santos Samuel Clavel Daniel Ruidrobo Len Freire Pablo Cruz
SQL proporciona una forma diferenre de condicin de bsqueda con el resr de rango (BETWEEN) mosrrado en la Figura 6.8. El resr de rango comprueba si un valor se encuentra entre dos especificados. Implica tres expresiones SQL. La prime~ ra define el valor a comprobar; la segunda y tercera, los lmites inferior y superior del rango a comprobar. Los tipos de daros de las rres expresiones deben ser comparables. Este ejemplo muesrra un test de rango rpico.
Hallar los pedidos del ltimo trimestre de 1989.

SELECT NUM_PEDIDO. FECHA_PEDIDO. FAB. PRODUCTO. IMPORTE FROM PEDIDOS WHERE FECHA_PEDIDO BETWEEN '01-0CT-89' AND '31-DIC-89' NUM_PEDlOO FECHA_PEDIDO 112961 112968 112963 112983 112979 112992 112975 112987 17-DIC-89 12-0CT-89 17-DIC-89 27-DIC-89 12-0CT-89 04-NOV-89 12-0CT-89 31-DIC-89 FAB PRODUCTO REI ACI ACI ACI ACI ACI REI P.CI 2A44L 41004 41004 41004 4100Z 41002 2A44G 4100Y IMPORTE 31.500,00 3.978,00 3.276,00 702,00 15.000,00 760,00 2.100,00 27.500,00
LisIar los representantes que no llegan a su cuota.

SELECT NOMBRE FROM REPRESENTANTES WHERE VENTAS < = CUOTA NOMBRE Bernardo Snchez Neus Azcrate
Sin embargo, las consultas producen, respectivamente, siete y dos filas de un total de nueve, mientras que hay 10 filas en la tabla REPRESENTANTES. La fila de Toms Saz tiene un valor NULL en la columna CUOTA porque an no se le ha asignado una cuota. Esra fila no es lisrada por ninguna de las consultas; desaparece en el test de comparacin. Como muestta esre ejemplo, es necesario reflexionar sobre el manejo de los valores NULL cuando se especifica una condicin de bsqueda. En la lgica trivalorada de SQL, una condicin de bsqueda puede devolver un resultado TRUE, FALSE 'o NULL. Slo las filas para las que la condicin de bsqueda ofrezca un resultado TRUE se inciuirn en los resultados de la consulta.
El test BETWEEN incluye los lmites del rango, de forma que los pedidos del 1 de ocrubre o del 31 de diciembre se incluyen en los resuHados de la consuHa. Aqu hay otro ejemplo de tesr de rango:
Hallar los pedidos que se encuentran entre varios rangos de cantidades.

SELECT NUM_PEDIDO. IMPORTE FROM PEDIDOS WHERE IMPORTE BETWEEN 20000.00 AND 29999.99 NUM_PEOIDO 113036 IMPORTE 22.500,00
114

112987
113042
115
t
.~
:11
27.500,00 22.500.00
SELECT NUM_PEDlDO, IMPORTE FROM PEDIDOS WHERE IMPORTE BETWEEN 30000.00 AND 39999.99 IMPORTE
112961
113069
Antes de confiar en este comportamiento es recomendable probarlo en el SGBD particular que se use. Conviene hacer notar que el test BETWEEN no aade realmente nada al poder expresivo de SQL, ya que se puede expresar como dos tests de comparacin. El test de rango:
A BETWEEN B ANO C
31.500,00 31.350,00
SELECT NUM_PEDIDO. IMPORTE FROM PEDIDOS WHERE IMPORTE BETWEEN 40000.00 ANO 49999.99
es completamente equivalente a:
lA >= Bl AND (A < = Cl
NUN_PEDIDO
113045
IMPORTE
45.000,00
Sin embargo, el test BETWEEN es una forma ms simple de expresar una condicin de bsqueda cuando se piensa en trminos de rangos de valores.
"
.,
La versin negada del test de rango (NOT BETWEEN) comprueba los valores que estn fuera del rango, como en este ejemplo:
Listar los representantes cuyas ventas no se encuentren entre el 80 y el 120 por ciento de su cuota.
SELECT NOMBRE, VENTAS, CUOTA FROM REPRESENTANTES WHERE VENTAS NOT BETWEEN (.8 NOMBRE Maria Jimnez VENTAS
392.725,00 474.050,00 142.594,00 186.042,00
El test de pertenencia a conjuntos
(IN)
CUOTA) ANO (1.2 * CUOTA) CUOTA

300.000,00 350.000,00 200.000,00 300.000,00
Otra condicin comn de bsqueda es el test de pertenencia a conjuntos (IN) mostrado en la Figura 6.9. Comprueba si un valor de datos coincide con uno de una lista de posibles valores. Aqu se muestran varias consultas que usan este test:
Listar los represen'tames que trabajan en Navarra, Almera o Daimiel.

SELECT NOMBRE, CUOTA, VENTAS FROM REPRESENTANTES WHERE REP_OFICINA IN (11, 13, NOMBRE Bruno Arteaga Mara Jimnez Samuel Clavel Neus Azcrate CUOTA
350.000,00 300.000,00 275.000,00 300.000,00
Susana Santos
Bernardo Snchez Neus Azcrate
22) VENTAS
367.911,00 392.725,00 299.912,00 186.042,00
La expresin de test especificada en el test BETWEEN puede ser cualquier expresin SQL vlida, pero en la prctica es generalmente slo el nombre de una columna, como en los ejemplos anteriores. El estndar ANSIfISO define reglas relativamente complejas para el manejo de los valores NULL en el test BETWEEN: Si la expresin de test produce un valor NULL, o si ambas expresiones que definen el rango producen valores NULL, entonces el test BETWEEN devuelve un resultado NULL. Si la expresin que define el lmite inferior del rango produce un valor NULL, entonces el test BETWEEN devuelve FALSE si el valor es mayor que el lmite superior, y NULL en caso contrario. Si la expresin que define el lmite superior del rango produce un valor NULL, entonces el test BETWEEN devuelve FALSE si el valor es menor que el lmite inferior, y NULL en caso contrario.
-------------- ------------- ------------
-exp'esin-de-'es' - [
NOT
Figura 6.9.
Diagrama sintctico del test de pertenencia a conjuntos IIN).
116
117
'"
Hallar todos los pedidos de un jueves de enero de 1990.
SELECT NUM_PEDIDO, FECHA_PEDIDO, IMPORTE
CIUDAD IN (' Navarra' l
razones de transportabilidad. es generalmente buena idea evitar listas con un nico elemento, como la siguiente:
'18-ENE-90.
FROM PEDIDOS WHERE FECHA_PEDIDO IN
(' 04-ENE-90.
'11-ENE-90',
'25-ENE-90') NUM_PEDIDO FECHA_PEDIDO 113012 ll-ENE-90 113003 25-ENE-90

I1iPORTE
3.745,00
y reemplazarla con un test simple de comparacin:

CIUDAD = 'Navarra'
5.625.00
El test de encaje de patrones
(LIKE)
Hallar rodos los pedidos de cuatro representantes en concreto.

SELECT NUM_PEDIDO, REP, IMPORTE FROM PEDIDOS WHERE REP IN (107, 109, 101, 103)
NUM_PEDIDO REP
Se puede usar un test simple de comparacin para recuperar las filas que coincidan con un texto en concretQ. Por ejemplo, esta consulta devuelve una fila de la tabla CLIENTES segn el nombre:
Mostrar eilimite de crdito de Sierras S. A.
IMPORTE
3.978,00 1.480,00 652,00 2.430,00
112968
113058
112997
113062 113069
101 109 107 107
SELECT EMPRESA, LIMITE_~REDITO FRQM CLIENTES WHERE EMPRESA = 'Sierras S.A.'
112975 113055 113003 113057 113042
107 103
101
31.350,00 2.100,00
150,00
109
103
5.625,00
600,00
101
22.500,00
Se puede comprobar si los valores de datos no coinciden con los valores usando la fonna NOT IN del test de pertenencia a conjuntos. La expresin de test en un test IN puede ser cualquier expresin SQL, pero es generalmente un nombre de columna, como en los ejemplos anteriores. Si la expresin de test produce un valor NULL, el test IN devuelve NULL. Todos los elementos de la lista de valores deben tener el mismo tipo, y el tipo debe ser comparable al tipo de datos de la expresin de test. Al igual que el test BETWEEN, el test IN no aade nada a la potencia expresiva de SQL, ya que la condicin de bsqueda:
X
Sin embargo, sera posible haber olvidado si el nombre de la empresa era Sierras, Segadoras o Sillas)}. Se puede usar el test de encaje de patrones para devolver los datos basados en una coincidencia parcial del nombre del cliente. El test de encaje de patrones (LIKE), mostrado en la Figura 6.10, comprueba si el valor de una columna coincide con un patrn especificado. El patrn es una cadena que puede incluir uno o ms caracteres comodn. Estos caracteres se interpretan de fonna especial.
Caracteres comodn
El carcter comodn signo del porcentaje (%) coincide con cualquier secuencia de varios o ningn caracteres. Aqu hay una versin modificada de la consulta anterior que usa el signo del porcentaje:
SELECT" EMPRESA, LIMITE_CREDITO FROM CLIENTES WHERE EMPRESA LIKE 'S% S.A.'
IN
{A,
s,
el
es completamente equivalente a:
(X
= AlaR
(X
= B)
OR (X
= Cl
-nombre-de-columna~LlKEParrnL
.
ESCAPE carader-de-escape
Sin embargo, el test IN ofrece una forma mucho ms eficiente de expresar esta condicin de bsqueda, especialmente si el conjunto contiene ms de unos pocos valores. El estndar de SQL ANSIIISO no especifica un lmite mximo sobre el nmero de elementos que pueden aparecer en la lista de valores, y la mayora de implementaciones comerciales tampoco establecen un lmite superior explcito. Por
J.. .
(LIKE).
NOT
-.J
Figura 6.10. Diagrama sintctico del test de encaje de patrones
118
119
La palabra clave LIKE indica a SQL que compare la columna NAME con el patrn 8% S. A.. Cualquiera de los nombres siguientes podra coincidir con el patrn:
sierras S.A. Segadoras S.A. Sillas S.A. Sandalias S.A.
pero stos no:

Segadoras SA Sierras Ine.
El carcter comodn de subrayado L) coincide con cualquier carcter nico. Si se est seguro de que el nombre de la compaa es Segadoras o Pegadoras, por ejemplo, se puede usar esta consulta:
SELECT EMPRESA, LIMITE_CREDITO FRQM CLIENTES WHERE EMPRESA LIKE '_egadoras S.A.'
En este caso, los siguientes nombres coincidiran con el patrn:

Segadoras S.A. Pegadoras S.A. Legadoras S.A.
de porcentaje en una columna de datos textuales, por ejemplo, se puede incluir simplemente el signo de porcenlaje en el patrn porque SQL lo tratar como un comodn. Con algunos productos SQL populares no se pueden comparar los dos caracteres comodn. Esto no plantea generalmente problemas serios porque los caracteres comodn no aparecen frecuentemente en los nombres, nmeros de producto y otros datos textuales del tipo que se almacena habitualmente en una base de datos. . El estndar de SQL ANSI/ISO especifica una forma de comparar estos caracteres mediante el uso de un carcter de escape especial. Cuando el carcter de escape aparece en el patrn, el carcter que lo sigue inmediatamente se trata como un carcter literal, en lugar de cmo un carcter especial (se dice que este ltimo carcter est escapado). El carcter escapado puede ser cualquiera de los caracteres comodn o el propio carcter de escape, que ahora tiene un significado especial en el patrn. El carcter de escape se especifica como una cadena constante de un carcter en la clusula ESCAPE de la condicin de bsqueda, como se muestra en la Figura 6.10. Aqu se muestra un ejemplo que usa el signo del dlar ($) como carcter de escape:
pero estos nombres no:

Secadoras S.A. Pagadoras S.A.
Hallar los productos cuyos bolos A %BC.
identificado~s de
producto comienzan con los sm-
Los caracteres comodn pueden aparecen en cualquier lugar de la cadena patrn y en cualquier nmero. Esta consulta permite tanto la cadena Secadoras como Pegadoras, y tambin el final del nombre de la empresa S. A. o S. L.:
SELECT EMPRESA, LIMITE_CREDITO FROM CLIENTES WHERE EMPRESA LIKE '_egadoras %'
SELECT NUM_PEDIDO, PRODUCTO FROM PEDIDOS WHERE PRODUCTO LIKE 'A$%BC%' ESCAPE '$'
Se pueden buscar cadenas que no coincidan con un patrn usando la forma del test de encaje de patrones. El test LIKE se debe aplicar a una columna con un tipo de datos de cadena. Si el valor de la columna es NULL, el test LIKE devuelve un resultado NULL. Si usted ha usado computadoras mediante una interfaz de comandos (como el entorno de UNIX), probablemente haya encontrado ya el encaje de patrones. Frecuentemente, el asterisco (*) se usa en lugar del signo del porcentaje (%), Y el signo de interrogacin de cierre (?) en lugar del subrayado de SQL, pero las capacidades de encaje de patrones son similares en la mayoria de situaciones en que una aplicacin infonntica ofrece la capacidad de comparar partes seleccionadas de una palabra o texto.
NOT LIKE
El primer signo de porcentaje del patrn, que sigue al carcter de escape, se trata como un signo de porcentaje literalmente, el segundo funciona como comodn. El uso de los caracteres de escape es muy comn en las aplicaciones de encaje de patrones, por In que el estndar ANSUlSO los especific. Sin embargo, nn formaba parte de las primeras implementaciones de SQL, y se ha adoptado lentamente. Para asegurar transportabilidad, se debera evitar la clusula ESCAPE.
El test de valores nulos lIS
NULL)
Caracteres de escape
Uno de los problemas del encaje de patrones de cadenas es cmo hacer la comparacin de los propios caracteres comodn. Para comprobar si hay un carcter
Los valores NULL crean una lgica trivalorada para las condiciones de bsqueda de SQL. Para una fila dada, el resultado de una condicin de bsqueda puede ser TRUE o FALSE, o puede ser NULL porque una de las columnas usadas en la evaluacin de la condicin de bsqueda contenga un valor NULL. A veces es til comprobar explcitamente los valores NULL en una condicin de bsqueda y manejarlos directamente. SQL proporciona un test especial sobre valores NULL (IS NULL), mostrado en la Figura 6.11, para manejar esta tarea.
I
i
l'
120
I!.' ;;1
'i~
'1,
i l'
1 11
;11
- - nombre-de-columna 15
-------,-----LNOT~
NULL
121
La palabra clave NULL no se puede usar aqu porque no es realmente un valor, sino una seal de que el valor es desconocido. Incluso si el test de comparacin:
OFICINA_REP = NULL
::
l'
Figura 6.11. Diagrama sintctico del test de valores NULL (r5 NULL).
Esta consulta usa el valor NULL para encontrar el representante de la base de datos de ejemplo que no tenga asignada an una oficina:
Buscar el representante que no tenga an una oficina asignada.
SELECT NOMBRE FRM REPRESENTANTES WHERE OFICINA_REP 15 NULL NOMBRE Toms Saz
fuese legal, las reglas para el manejo de los valores NULL en las comparaciones hara que su comportamiento fuese diferente del que cabra esperar. Cuando SQL encuentre una fila donde OFICINA_REP fuese NULL, la condicin de bsqueda comprobara:
NULL = NULL
La forma negativa del test de valores NULL (1S NOT NULL) encuentra las filas que no contienen un valor NULL:
Listar los representantes que
SELECT NOMBRE
El resultado es TRUE, o FALSE? Dado que los valores en ambos lados de la igualdad son desconocidos, SQL no puede decidirlo, as que las reglas de la 16gica de SQL dicen que la condicin de bsqueda debera dar un resultado NULL. Dado que la condicin de bsqueda no produce un resultado cierto, la fila se excluye de los resultados de la consulta -precisamente lo opuesto de lo que se esperara-o Como resultado de la forma en que SQL maneja los valores NULL en las comparaciones, se debe usar explcitamente el valor NULL para comprobar los valores NULL.
ten~an
oficinas asignadas.
Condiciones compuestas de bsqueda
(AND, OR
Y NOT)
FROM REPRESENTANTES WHERE OFICINA_REP r5 NOT NULL NOMBRE

Bruno Arteaga Maria Jimnez Susana Santos Samuel Clavel Bernardo Snchez Daniel Ruidrobo Len Freire Pablo Cruz Neus Azcrate
Las condiciones simples de bsqueda descritas en las secciones precedentes devuelven un valor TRUE, FALSE o NULL cuando se aplican a una fila de datos. Usando las reglas de la lgica se pueden combinar estas condiciones simples de bsqueda de SQL para formar otras ms complejas, como la que se muestra en la Figura 6.12. Ntese que las condiciones de bsqueda combinadas con AND, OR Y NOT pueden ser a su vez condiciones compuestas de bsqueda.
---WHERE
tL:J
L
AND
cond;c;n-de-bsqueda
I
'
ti
I
I ,
A diferencia de las condiciones de bsqueda descritas anteriormente, el test de valores NULL no puede devolver un resultado NULL. Siempre es TRUE o FALSE. Puede resultar extrao que no se pueda comprobar un valor NULL usando una simple condicin de bsqeda de comparacin, como:
SELECT NOMBRE FROM REPRESENTANTES WHERE OFICINA_REP = NULL
OR
Figura 6.12. Diagrama sintctico de la clusula WHERE.
122
123
La palabra reservada OR se usa para combinar dos condiciones de bsqueda cuando cualquiera de ellas (o ambas) debe ser cierta:
Tabla 6.1.
AND
La tabla de verdad de AND

TRUE TRUE FALSE NULL FALSE FALSE FAL5E FALSE NULL NULL FALSE NULL
Hallar los representantes que estn por debajo de su cuota o con ventas por debajo de 300.000 .
SELECT FROM WHERE DR
NOMBRE
TRUE FALSE
NOMBRE, CUOTA, VENTAS REPRESENTANTES VENTAS < CUOTA VENTAS < 300000.00 CUOTA
VENTAS 299.912,00 142.594,00
N11LL
Samuel Clavel Bernardo Snchez Toms Saz Pablo Cruz Neus A%crate
275.000,00 200.000,00
Hallar todos los representantes que o bien (a) trabajan en Daimiel, Navarra o CasteIln; o bien (b) no tienen jefe y estn contratados desde junio de 1988; o (e) superan su cuota pero tienen ventas de 600.000 o menos.
SELECT FROM WHERE OR OR NOMBRE REPRESENTANTES {OFICINA_REP IN (22, 11, 12)) (JEFE IS NULL AND FECHA_CONTRATO >~ 'Ol-JUN-88') (VENTAS> CUOTA AND NOT VENTAS> 600000.00)
NULL
275.000,00
300.000.00
75.985,00 286.775.00 186.042,00
Tambin se puede usar la palabra clave AND para combinar dos condiciones de bsqueda que deben ser simultneamente ciertas:
Hallar los representantes que estn por debajo de su cuota y con ventas por debajo de 300.000 .
SELECT NOMBRE, CUOTA, VENTAS FROM REPRESENTANTES WHERE VENTAS < CUOTA AND VENTAS < 300000.00 NOMBRE
Bernardo Snchez Neus Azcrate
CUOTA 200.000,00 300.000,00
VENTAS 142.594,00 186.042,00

NOT
Finalmente. se puede usar la palabra clave condicin de bsqueda sea falsa:
para seleccionar filas donde la
La razn por la que podra desearse ver esta lista particular de n~:)Jnbres no importa. Lo que ilustra este ejemplo es una consulta razonablemente compleja. Como con las condiciones simples de bsqueda, los valores NULL afectan al resultado de las condiciones compuestas de bsqueda, y los resultados son sutiles. En particular, el resultado de (NULL OR TRUE) es TRUE, [JO NULL, como se podra esperar. Las Tablas 6.1, 6.2 Y6.3 especifican tablas de verdad para AND, OR Y NOT, respectivamente, y muestran el impacto de los valores NULL. Cuando se combinan ms de dos condiciones de bsqueda con ANO, OR Y NOT, el estndar ANSI/ISO especifica que NOT tiene la precedencia ms alta, seguido de ANO, y despus OR. Para asegurar la transportabilidad, siempre es buena idea usar parntesis y eliminar cualquier posible ambigedad. El estndar SQL2 aade otra condicin lgica de bsqueda, el test IS, a la lgica proporcionada por ANO, OR Y NOT. La Figura 6.13 muestra la sintaxis del test IS, que comprueba si el valor lgico de una expresin o test de comparacin es
TRUE, FALSE
UNKNOWN (NULL).
Hallar ,odos los representantes que estn por debajo de su cuota pero que sus ventas no estn por debajo de J50.000 .
SELECT NOMBRE, CUOTA, VENTAS FROM REPRESENTANTES WHERE VENTAS < CUOTA AND NQT VENTAS < 150000.00 NOMBRE
Neus Azcrate
Por ejemplo, el test IS:

((VENTAS - CUOTA) > 10000.00) 15 UNKNOWN
Tabla 6.2.
VENTAS 186.042,00
OR
'rRUE
La tabla de verdad de OR
TRUE
CUOTA 300.000,00
FALSE TRUE FALSE
N11LL
TRUE NULL
NULL
TRUE TRUE TRUE
Al usar las palabras clave AND, OR Y NOT y parntesis para agrupar el criterio de bsqueda, sepueden construir criterios de bsqueda muy complejos, ~mo el siguiente:
P'ALSE
N11LL
NULL
1I
124
1:
SOL. Manual de referencia Tabla de verdad de

NQT
125
Tabla 6.3.
NO'!'
i
I
'rRUE FALSE
FAL5E TRUE
NULL NULL
- - - aRDER BY
I'n~mbre-de-COlumnaj
I
I
Lnumero-de-columna
f----...
lI
Ase --1
DESC~
I
se puede usar para hallar filas donde la comparacin no se pueda realizar debido a que VENTAS o CUOTA tenga un valor NULL. De forma similar, el test 18:
((VENTAS
~
CUOTA)
>
10000.00)
I5 FALSE
seleccionar las filas donde VENTAS no estn significativamente sobre CUOTA. Como muestra este ejemplo, el test 18 no aade realmente potencia expresiva a SQL, ya que el test se podra haber escrito de manera simple:
NOT ((VENTAS - CUOTA)
>
Figura 6.14. Diagrama sintctico de la clusula
QRDER
BY.
Mostrar las ventas de cada oficina, ordenadas alfabticamente por regin y, dentro de cada regin, por ciudad.
SELECT CIUDAD, REGlON, VENTAS FROM OFICINAS ORDER BY REGlON, CIUDAD CIUDAD REGlON VENTAS
10000.00)
Para asegurar una transportabilidad mxima, conviene evitar estos tests y escribir las expresiones usando slo AND, OR Y NOT. No siempre es posible evitar la forma 18 UNKNOWN del test.
!
11
---------Almera
------Este Este Este Oeste Oeste
------------367.911,00 735.042,00 692.637,00 186.042,00 835.915.00
Ordenacin de los resultados de las consultas (clusula ORDER BY)

Al igual que las filas de una tabla de la base de datos, las filas de los resultados de una consulta no se organizan de modo particular. Se puede pedir que SQL
ordene los resultados incluyendo la clusula ORDER BY en la instruccin SELECT. La clusula aRDER BY, mostrada en la Figura 6.14, consiste en la palabra clave DRDER BY seguida de una lista de especificaciones de orden separadas por comas. Por ejemplo, los resu:Itados de esta consulta se ordenan sobre dos columnas: REGlON y CIUDAD:
Castelln Navarra Daimiel Len
ti'
La primera especificacin de orden (REGlON) es la clave de ordenacin principal; las siguientes (CIUDAD, en este caso) son progresivamente claves de ordenacin menores, usadas como decisivas cuando dos filas de resultados tienen los mismos valores de las claves principales anteriores. Al usar la clusula ORDER BY, se puede solicitar la ordenacin en secuencia ascendente o descendente, y se puede ordenar sobre cualquier elemento de la lista de seleccin de la consulta. De manera predeterminada, SQL ordena los datos en secuencia ascendente. Para pedir una ordenacin descendente, se incluye la palabra clave DEse en la especificacin de orden, como en el siguiente ejemplo:
,
'li
eSI-de.comparaC;nj,s--r=TRUE:=f
FALSE
UNKNOWN
Listar las oficinas, ordenadas en orden decreciente de ventas, de forma que las oficinas con mayores ventas aparezcan primero.
SELECT CIUDAD, REGION, FROM OFICINAS ORDER BY VENTAS DESC CIUDAD REGlON VENTAS
expresin-lgica
VENTAS
l,:
Figura 6.13. El diagrama sintctico de IS.
Len
Oeste
835.915,00
- - - - - - - -
126

Este Este Este Oeste
127
Castelln Navarra Almera

Daimiel
735.042,00 692.637,00
367.911,00
186.042,00
Como se indic en la Figura 6.14, se puede usar tambin la palabra clave Ase para especificar un orden ascendenre. pero dado que es la secuencia predeterminada de ordenacin, la palabra clave usualmente se omite. Si la columna de los resultados que se usa para ordenar es una columna calculada, no tiene nombre de columna para ser usado en una especificacin de nombre. En este caso se puede especificar un nmero de columna en lugar de un nombre de columna, como en este ejemplo:
juntos de caracteres internacionales o para asegurar la transportabilidad entre los sistemas de conjuntos de caracteres ASCII y EBCDIC. Sin embargo, esta rea de la especificacin de SQL2 es muy compleja y, en la prctica, muchas implementa~ ciones de SQL o bien ignoran los aspectos de los tipos de ordenacin o usan su propio esquema propietario para el control por el usuario de la secuencia de arde nacin.
Reglas para el procesamiento de consultas sobre una sola tabla

Las consultas de una nica tabla son generalmente simples, y es fcil de com prender generalmente el significado de una consulta simplemente leyendo la instruccin SELECT. Sin embargo, cuando las consultas se complican es importante tener una definicin ms precisa de los resultados que producir una instruc cin SELECT dada. Los siguientes pasos describen el procedimiento para generar los resultados de una consulta SQL que incluya las clusulas descritas en este caplUlo. Como muestran estos pasos, los resultados producidos por una instruccin SELECT se especifican aplicando cada una de esta clusulas, una a una. La clusu la FROM se aplica en primer lugar (seleccionando la tabla que contiene los datos a recuperar). A continuacin se aplica la clusula WHERE (seleccionando las filas especficas de la tabla). La clusula SELECT se aplica a continuacin (generando las columnas especficas de los resultados y eliminando los duplicados si se solicita). Finalmente, la clusula ORDER BY se aplica para ordenar los resultados. Para generar los resultados de una instruccin 5ELECT hay que seguir estos pasos: l. 2. Comenzar con la tabla referenciada en la clusula FROM. Si hay un clusula WHERE, aplicar su condicin de bsqueda a cada fila de la tabla, reteniendo las filas para las que la condicin de bsqueda es TRUE, y descartando las filas para las que es FALSE o NULL. Para cada fila restante, calcular el valor de cada elemento en la lista de seleccin para producir una nica fila de resultados. Para cada referencia a columna, usar el valor de la columna en la fila en curso. Si se especifica SELECT DISTINCT, eliminar cualquier fila duplicada de los resultados que se hubieran producido. Si hay una clusula ORDER BY, ordenar los resultados como se haya especificado.
Listar las oficinas, ordenadas descendentemente segn el rendimiento de sus ventas, de forma que las oficinas COn mejor rendimiento aparezcan primero.
SELECT CIUDAD, REGlaN, FROM OFICINAS ORDER BY 3 DESC CIUDAD Navarra Le6n Almeria Castelln Daimiel REGION Este Oeste Este Este Oeste (VENTAS - OBJETIVO)
(VENTAS-OBJETIVO)
----------
-----------------117 .637,00 110 .915,00 17 .911,00 -64 .958,00 -113 .958,00
Estos resultados se ordenan segn la tercera columna, que es la diferencia entre VENTAS y OBJETIVO de cada oficina. Al combinar nmeros de columnas, nombres de columnas, ordenaciones ascendentes y descendentes, se pueden especificar ordenaciones muy complejas de los resultados, como en el siguiente ejemplo final:
Listar las oficinas, ordenadas alfabticamente por regin, y dentro de cada regin en orden descendente por el rendimiento de sus ventas.
SELECT CIUDAD, REGlaN, (VENTAS - OBJETIVO) FRQM OFICINAS aRDER BY REGlaN Ase, 3 DEse CIUDAD REGlaN Este Este Este Oeste Oeste
3.
4. 5.
Navarra Almeria Castelln Len Daimiel
----------
-----------------117.637.00 17.911.00 -64.958,00 110.915,00 -113.958,00
(VENTAS-OBJETIVO)
El estnqar SQL2 permite controlar el tipo de orden usado por el SGBD por cada clave de ordenacin. Esto puede ser importante cuando se trabaje con con-
Las filas generadas por este procedimiento forman los resultados de la consulta. Estas reglas para ti procesamiento de consultas SQL se expandir varias veces en los prximos tres captulos para incluir las clusulas restantes de la instruccin SELECT.
I .l
128
129
'''i'
Combinacin de los resultados de las consultas (UNION)*

A veces es conveniente combinar los resultados de dos o ms consultas en una nica tabla de resultados. SQL dispone de esta capacidad mediante la caracterstica UNION de la instruccin SELECT. La Figura 6.15 ilustra cmo usar la operacin UNION para satisfacer la siguiente solicitud:
De forma similar, la segunda parte de la solicitud se puede satisfacer con la consulta inferior en la figura:
Listar todos los productos de los que se hayan pedido ms de 30.000 en un nico pedido.
SELECT DISTINCT FAB, PRODUCTO FROM PEDIDOS WHERE IMPORTE> 30000.00 FAB IMM REI REI PRODUCTO 775C 2A44L 2A44R
tll
11
"
Listar todos los productos en los que su precio supere 2.000 o cuando se hayan pedido ms de 30.000 del producto en un nico pedido.
La primera parte de la solicitud se puede satisfacer con la consulta superior de la figura:
Listar todos los productos en los que su precio supere 2.000 .

1
:1
ii.
;1
SELECT ID_FAS, ID_PRODUCTO FROM PRODUCTOS WHERE PRECIO> 2000.00 ID_FAS ID_PRODUCTO
ACl REl ACl REl
Como se muestra en la Figura 6.15, la operacin UNION produce una nica tabla de resultados que combina las filas de los resultados de la consulta de arriba con las filas de los resultados de la de abajo. La instruccin SELECT que especifica la operacin UNION es:
Listar todos los productos en los que su precio supere 2.000 o cuando se hayan pedido ms de 30.000 del producto en un nico pedido.
SELECT FROM WHERE UNION SELECT FROM WHERE ACI ACI IMM REI REI ID_FAB, ID_PRODUCTO PRODUCTOS PRECIO> 2000.00 DISTINCT FAB, PRODUCTO PEDIDOS IMPORTE> 30000.00 4l00Y 4100Z 775C 2A44L 2A44R
4100Y 2A44L 4100Z 2A44R
Tabla PRODUCTOS
ID JEF
ID PRODUCTOS 4100Y 2A44L 4100Z 2A44R

Resultados de la consulta ACl REl ACl REl REl REl lMM
r----11'
I <lOla J:'tW.lUU::;
ACl REl ACl REl
l'
" "
1:
r+
JEF
eUNlNJ-1
--
4100Y 2A44L 4100Z 2A44R 2A44L 2A44R 755C
Hay restricciones severas sobre las tablas que se pueden combinar en una operacin UNION: Las dos tablas deben contener el mismo nmero de columnas. El tipo de datos de cada columna de la primera tabla debe ser el mismo que el de la columna correspondiente de la segunda. -Ninguna de las dos tablas se pueden ordenar con la clusula ORDER BY. Sin embargo, los resultados de la consulta combinada, s, corno se describe en la siguiente seccin. Ntese que los nombres de las columnas de las dos consultas combinadas con no tienen que ser idnticas. En el ejemplo anterior la primera tabla de resul-
PRODUCTO 2A44L 2A44R
..--..
REl REl lMM
755c
~
Figura 6.15. Uso de UNION para combinar los resultados.
UNION
iJ
!I
130
131
tados tiene las columnas ID_JEF e ID_PRODUCTO, mientras que la segunda tabla de resultados tiene las columnas FAB y PRODUCTO. Dado que las columnas de las dos tablas tienen nombres diferentes, las columnas de los resultados producidos por la operacin UNION se dejan sin nombre. El estndar de SQL ANSI/ISO especifica una restriccin ms sobre la instruccin SELECT que participa en una operacin UNION. Slo se pemiten nombres de columna o una especificacin de todas las columnas (SELECT *) en la lista de seleccin, y prohbe expresiones en ella. La mayora de implementaciones comerciales de SQL relajan esta restriccin y permiten expresiones simples en la lista de seleccin. Sin embargo, muchas implementaciones SQL no permiten que las instrucciones SELECT incluyan clusulas GROUP BY o HAVING, y algunas no permiten funciones en la lista de seleccin (prohiben las consultas de resumen descritas en el Captulo 8). De hecho, algunas implementaciones SQL ni siquiera albergan la operacin UNION.
Ntese que el manejo predeterminado de las filas duplicadas en la operacin y para la instruccin simple SELECT es exactamente opuesto. Para la instruccin SELECT, SELECT ALL (se conservan los duplicados) es la forma predeterminada. Para eliminar filas duplicadas se debe especificar explcitamente SELECT DISTINCT. Para la operacin UNION, UNION (se eliminan los duplicados) es la for~ ma predeterminada. Para conservar filas duplicadas se debe especificar explcitamente UNION ALL. Los expertos en bases de datos han criticado el manejo de las filas duplicadas en SQL y apuntan a esta inconsistencia como un ejemplo de los problemas. La razn de esta inconsistencia que las formas predeterminadas de SQL se eligieron para producir el comportamiento correcto en la mayora de las ocasiones:
UNION
Uniones y filas duplicadas*

Dado que la operacin UNION combina las filas de dos conjuntos de resultados, tendera a producir resultados con filas duplicadas. Por ejemplo, en la consulta de la Figura 6.] 5, el producto REI-2A44L se vende por 4.500,00 , por 10 que aparece en el conjunto superior de los resultados. Tambin hay un pedido de 31.500,00 de este producto en la tabla ORDERS, por 10 que aparece en el conjunto inferior de los resultados. De forma predeterminada, la operacin UNION elimina las filas duplicadas como parte de su procesamiento. As,. el conjunto combinado de resultados contiene slo una fila del producto REI-2A44L Si se desea conservar las filas duplicadas de una operacin UNION, hay que especificar la palabra.clave ALL inmediatamente a continuacin de la palabra UNION. Esta forma de la consulta produce dos filas duplicadas para el producto REI-2A44L:
En la prctica, la mayora de instrucciones SELECT simples no producen filas duplicadas, por lo que la forma predeterminada es no eliminar duplicados. En la prctica, la mayora de operaciones UNION produciran filas duplicadas no deseadas, por lo que la forma predeterminada es la eliminacin de duplicados. La eliminacin de filas duplicadas de los resultados es un proceso costoso en tiempo, especialmente si los resultados contienen un gran nmero de filas. Si se sabe, debido a las consultas individuales implicadas, que una operacin UNION no puede producir filas duplicadas, se debera especificar la operacin UNION ALL, porque la consulta se ejecutar mucho ms rpidamente.
Uniones y ordenacin*
La clusula QRDER BY no puede aparecer en ninguna de las dos instrucciones SELECT combinadas con una operacin UNION. No tendra mucho sentido ordenar los dos conjuntos de resultados porque se transmitiran directamente a la opera~ cin UNION y nunca seran visibles para el usuario. Sin embargo, el conjunto combinado de resultados producidos por la operacin UNION se pueden ordenar especificando la clusula ORDER BY despus de la segunda instruccin SELECT. Dado que las columnas producidas por la operacin UNION no tienen nombre, la clusula ORDER BY debe especificar las columnas por su nmero de columna. A continuacin se muestra la misma consulta de productos que la mostrada en la Figura 6.15, con los resultados ordenados por fabricante y nmero de producto:
Listar todos los productos para los que el precio sea mayor que 2.000 , a cuando se hayan pedido ms de 30.000 del producto en un nico pedido.
SELECT ID_FAB, ID_PRODUCTO PROM PRODUCTOS WHERE PRECIO> 2000.00
UNION ALL
SELECT DISTINCT FAB, PRODUCTO FROM PEDIDOS WHERE IMPORTE> 30000.00

ACI RE! 4100Y 2A44L
Listar todos los productos para los que el precio sea mayor que 2.000 o cuando se hayan pedido ms de 30.000 del producto en un nico pedido, ordenados por fabricante y nmero de producto.
SELECT ID_FAB, ID_PRODUCTO FROM PRODUCTOS WHERE PRECIO> 2000,00 UNION
ACI
RE! IMM RE! RE!
4100Z
2A44R 775C 2A44L 2A44R
132
133
SELECT DISTINCT FAS, PRODUCTO FROM PEDIDOS WHERE IMPORTE> 30000.00
ORDER BY 1,
Tabla A I(lUI(l"" sin. Tabla B

sil!
Mary
ACI
4100Y
ACI
IMM
4100Z
?75C
RE!
RE!
2A44L
2A44R
Sue
Julia Harry
George Fred
(
sil!
UNIN
.J
sil! Mary George Fred
Uniones mltiples*
Tabla
UNIN
Sue
Julia Harry Mary' George
Sue
Julia Harry
La operacin UNION se puede usar repetidamente para combinar tres o ms conjuntos de resultados, como se muestra en la Figura 6.16. La unin de la tabla B y la tabla e de la figura produce una nica tabla combinada. Esta tabla se combina con la tabla A en otra operacin UNION. La consulta de la figura se escribe:
Mary
George Sil! Harry
..J
,1
SELECT FRQM A UNION (SELECT PROM B UNION

SELECT
Figura 6.16. Operaciones
UNION anidadas.
FROM e) Bruno
Sin embargo, si las uniones implican una mezcla de orden de evaluacin s importa. Si la expresin:
A UNIaN ALL B UNION C
UNION
UNION ALL,
el
Mara
Genaro Fulgencio Susana 'Julia Hilario
se interpreta como:
A UNION ALL (B UNION e) UNION
Los parntesis de la consulta indican la operacin UNION que se debe realizar primero. De hecho, si todas las operaciones UNION de la instruccin eliminan las filas duplicadas, o si todas ellas las conservan, el orden en que se realicen no es importante. Estas tres expresiones son completamente equivalentes:
A UNION (B UNION Cl
entonces produce diez filas de resultados (seis de la la tabla A). Sin embargo, si se interpreta como:
(A UNION ALL Bl UNION
interior ms cuatro de
(A UNIaN B) UNION C (A UNIaN C) UNION B
entonces produce slo cuatro filas, dado que la UNION externa elimina todas las filas duplicadas. Por esta razn siempre es buena idea usar parntesis en las operaciones UNION de tres o ms tablas para especificar el orden de evaluacin pretendido.
l',
,1'
,,1,
, i
y producen siete filas de resultados. De forma similar, las siguientes tres expresiones son completamente equivalentes y producen doce filas de resultados, dado que se conservan los duplicados:
A UNION ALL (B UNION ALL Cl
Resumen
Este. captulo es el primero de cuatro sobre las consultas SQL. Ha descrito las siguientes caractersticas de las consultas: La instruccin SELECT se usa para expresar una consulta SQL. Cada instruccin SELECT produce una tabla de resultados que contiene una o ms columnas, y ninguna o varias filas.
f :,
L
::
(A UNION ALL Bl UNION ALL e (A UNTON ALL cl UNION ALL B
134
La clusula FROM especifica la tabla o tablas que contienen los datos a recuperar por una consulta. La clusula SELECT especifica la columna o columnas de datos que se incluirn en Ios resultados, que pueden ser columnas de datos de la base de datos o columnas calculadas. La clusula WHERE selecciona las filas a incluir en los resultados aplicando una condicin de bsqueda a las filas de la base de datos. Una condicin de bsqueda puede seleccionar filas comparando valores, comprobando un valor con un rango de valores, encajando un patrn de cadena y comprobando si son valores NULL. Los condiciones simples de bsqueda se pueden combinar con ANO, OR Y NOT para formar condiciones de bsqueda ms complejas. La clusula ORDER BY especifica que los resultados se deberan ordenar de forma ascendente o descendente segn los valores de una o ms columnas. La operacin UNION se puede usar en una instruccin SELECT para combinar dos o ms conjuntos de resultados en un nico conjunto.
CAPTULO
Consultas multitabla (reuniones)
Mucha~
consultas tiles necesitan datos de dos o ms tablas de la base de datos. Por ejemplo, las solicitudes de datos de la base de datos de ejemplo toman datos de dos, tres y cuatro tablas: Listar los representantes y las oficinas en las que trabajan (tablas
SENTANTES REPRE-
Y OFICINAS).
Listar cada pedido de la ltima semana, mostrando el importe del pedido, el nombre del cliente y el nombre del producto del pedido (tablas PEDIDOS,
CLIENTES
Y REPRESENTANTES).
Mostrar todos los pedidos de los representantes de la regin Este mostrando la descripcin del producto y el representante (PEDIDOS, REPRESENTANTES,
OFICINAS
Y PRODUCTOS).
SQL permite recuperar datos que responden a estas solicitudes con las consultas multitabla que renen datos de dos o ms tablas. En este captulo se describen estas consultas y la caracterstica de reunin de SQL.
Un ejemplo de consulta con dos tablas

La mejor forma de comprender las facilidades que proporciona SQL para las consultas multitabla es comenzar con una solicitud simple que combina datos de dos tablas diferentes:
Listar rodos los pedidos. mostrando el nmero de pedido, su importe y el nombre y lmite de crdito del cliente.
Los cuatro elementos de datos solicitados estn almacenados claramente en dos tablas diferentes, como se muestra en la Figura 7.1.
135
l
136
Captulo 7: Consultas multitabla (reuniones)
137
I ,
1'
Tabla PEDIDOS
NUM PEDIDO
FECIlA.-PEDlOO
17/1?I1<lg'l
CLIEm'E
.e,
106 105 106
C1IN1'IDAD
IMPORTE
Tab! a CLIENTES NUM CLI EMPRESA
REP CLI LIMITE CREDrTO
Relacin de clave primaria/clave
externa
""" 113012
112989
11/01/1990
03/01/1990
g6f
211V
~;
35 6
34.500,OO 3 745,OO
1 458,OO
=,
1
Hen..,h..
L6 n ez
21.22
Toledo S A. \
109 106 105
~ooo~
30,000 OO
00 000 OO
Listar todos los pedidos, mostrando el nmero de pedido,
su importe y el nombre y Ifmite de crdito del e/iente.

Tabla PEDIDOS
Tabla CLIEtn'ES
NUM_cIlr I EMPRESA
REP~CLIILIMITE_~REDITO
h'U!LPEOIDO PF:CIII..-PEDIDO CLIENTE
,'-"" IJ.P. llJ)

2
11961 11 012 11 989
Henche & Lpez
Sotoca
Toledo S.A.
109 106 105
550oo,oaE
35000,OaE 30.000,00
17/12/1989 11/01/1990 2111 03/0111990 2101
$!V '" '"

105
'"
II
CM'TIDAD
IMPORTE
{~ 1,L
a
MPORTE
7 :::i1.500.00.$ 351!:745.00 6 1.458,00
@
Figura 7.1.
Resultados de la ccos
NUM PEDIDO
,,~
EMPRESA
J . P.
Una solicitud sobre dos tablas.
-~112961 ~1.500.00
LIMITE CR:llTO
sotocl'
35.000.00
La tabla PEDIDOS contiene el nmero de pedido y su importe, pero no tiene nombres de cliente ni lmites de crditos. La tabla CLIENTES contiene, los nombres y saldos de los clientes, pero no tiene informacin de los pedidos. Sin embargo, hay un enlace entre estas dos tablas. En cada fila de la tabla PE~ la columna CLIENTE contiene el nmero de cliente que realiz el pedido, que coincide c;on el. v~lor de la .columna NUM_CLI en una de las filas de la tabla CLIENTES. Ob.viame~te, la instru~.cin SELECT que maneja la solicitu~ d~be usar de algn modo este enlace entre las tablas para generar sus resultados. Antes de examinar la instruccin SELECT de la consulta, es instructivo pensar en cmo uno mismo resolvera la solicitud usando lpiz y papeL La Figura 7.2 muestra lo que uno probablen:ente ~arfa:
DIDOS,
Figura 7.2.
Procesamiento manual de una consulta multitabla.
5.
Con esto se ha generado una fila de resultados! Ir de nuevo a la tabla e ir a la siguiente fila. Repetir el proceso, empezando en el paso 2, hasta que no queden ms pedidos.
PEDIDOS
Por supuesto, sta no.es la nica forma de generar los resultados, pero independientemente de cmo se haga, dos cosas sern ciertas: Cada fila de resultados torna sus datos de un par especfico de filas, uno de la tabla PEDIDOS y otro de CLIENTES. La pareja de filas se encuentran haciendo coincidir los contenidos de las columnas correspondientes de las tablas.
Comenzar escribiendo los cuatro nombres de columna para los resultados. Despu's'ir a 'la tabla PEDIDOS y comenzar con.el primer pedido, Buscar en la fihel nmerde pedido (112961) y su importe (31.500,00 E), Y copiar ambos valores en la primera fila de resultados. Buscar en la fila el nmero de cliente que realiz el pedido (2117) e ir a la tabla CLIENTES para encontrar el nmero de cliente 2117 en la columna
CUST_NUM.
Reuniones simples (equirreunion~;i

El proceso de la formacin de pares de filas haciendo corresponder los contenidos de las columnas relacionadas se denomina reunin de tablas. La tabla resultante (que contiene datos de las tablas originales) se denomina reunin de dos tablas
Buscar en la fila de la tabla CLIENTES el nombre del cliente (<<1. P. Sotoca,,) y el lmite de crdito (35.000,00 E), Ydespus copiarlos en la tabla de resultados.
138
139
(una reunin que se basa en una correspondencia exacta entre las dos reuniones se denomina equirreuni6n. Las reuniones tambin se basan en otras clases de comparaciones de columnas, como se describe ms tarde en este captulo). Las reuniones son el fundamento del procesamiento de consultas multitabla en SQL. Todos los datos de una base de datos relacional se almacenan en sus columnas como valores explcitos de datos, as que todas las posibles relaciones entre tablas se pueden formar haciendo corresponder los contenidos de las columnas relacionadas. Las reuniones proporcionan, por tanto, una facilidad potente para incorporar las relaciones entre los datos en la base de datos. De hecho. dado que las bases de datos relacionales no contienen punteros u otros mecanismos para relacionar filas entre s. las reuniones son el nico mecanismo para incorporar relaciones de datos entre tablas. Dado que SQL maneja las consullas multitabla haciendo corresponder columnas. no debera sorprender que la instruccin SELECT de una consulta multitabla contenga una condicin de bsqueda que especifica el encaje de columnas. Aqu hay una instruccin SELECT para la consulta calculada manualmente en la Figura 7.2:
Listar todos los pedidos, mostrando el nmero de pedido, su importe y el bre y lmite de crdito del cliente.
SELECT NUM_PEDIDO, IMPORTE, FROM PEDIDOS, CLIENTES WHERE CLIENTE : NUM_CLI EMPRESA, LIMITE_CREDITO
nom~
sta restringe las filas que aparecen en los resultados. Dado que es una consulta de dos tablas. la condicin de bsqueda especifica las mismas columnas coincidentes que se usaron en el procesamiento manual de la consulta. Realmente captura el espritu del encaje de columnas muy bien. diciendo: Generar los resultados slo para parejas de filas en las que el nmero de cliente (CUST) de la tabla PEDIDOS coincide con el nmero de cliente (CUST_NUM) de la tabla CLIENTES. Ntese que la instrucci6n SELECT no dice nada sobre c6mo debera ejecutar SQL la consulta. No hay mencin acerca de comenzar con los pedidos o comenzar con los usuarios. En su lugar. la consulta dice a SQL qu tipo de resultados deberan aparecer y deja a SQL decidir cmo generarlos.
Consultas padre/hijo
Las consultas multitabla ms comunes involucran dos tablas que tienen una relacin natural padre/hijo. La consulta de los pedidos y clientes de la seccin anterior es un ejemplo de tal consulta. Cada pedido (hijo) tiene un cliente asociado (padre), y cada cliente (padre) puede tener muchos pedidos asociados (hijos). Las parejas de filas que generan los resultados son combinaciones de filas padre/hijo. Del Captulo 4 se puede recordar que las claves externas y las claves primarias crean la relacin padre!hijo en una base de datos SQL. La tabla que contiene la clave externa es el hijo en la relacin: la tabla con la clave primaria es el padre. Para incorporar la relacin padrelhijo en una consulta hay que especificar una condici6n de bsqueda que compare la clave externa con la clave primaria. Aqu hay otro ejemplo de una consulta que incorpora la relacin padre/hijo mostrada en la Figura 7.3:
----------- ---------- ------------------ --------------6S.000,00 1. 458, OO Jarandilla Ltd,

112989 112968 3.978,00 Filas 112963 3.276,OO Acme 112987 27.500,OO Acme 112983 7.02,00 Acme 4.104,00 Acme 113027 112993 1.896,OO F. Lpez S,A, 2.130,00 F. Lpez S,A, 113065 113036 22.500,OO Ace Internacional 632,00 Ace Internacional 113034 113058 1. 480, OOE Henche & Lpez 113055 150.00 Henche & Lpez 113003 5.625,00 Henche & Lpez 6S.000,OO SO.OOO,OO SO.OOO,OO 50.000,00 50.000,00 65.000,OO 65.000,OO 35.000,OO 35.000,00 55.000,00 55.000,OO 55.000,OO
NUM_PEDIDO
IMPORTE EM,PRESA
LIMITE_CREDITO
T bl OFICINlIS OI'INA CIUD.>.D

'22 Daimiel
,,
REGIN Deste Este Este Este oest"
'"
OBJE"l'IVO 3CC.OCO.OO S7S.00C,OO BOO.COO.OO 350.00C.OO 72S.000,OO
<ti ~n
d.
Nllvllrrll
"
",.
'" '" '" '"
Tebl'l\E~
""\M...EHPL
'"
lB6.C42,CC 6'2.6)7.0C 73S.042,OO 367.'ll,OO 835.915,OO
-~
Rll'Suhados de le consult.
Esto se parece a las consultas del captulo anterior pero con dos nuevas caractersticas. En primer lugar. la clusula FROM lista dos tablas en lugar de una. En segundo lugar. la condicin de bsqueda:
'" '" '" '" ". no '" ". '"

lO'
BruDOAr~ K4na JiDn"

SUsana Santos S4muel Clavel Bernardo S'ncllu o.o.n1el Ru,drobo T<lIMS saz l.e6n F..eHe pablo C~uz Ileus Azc..ate
~~ " " ."" ~ "

U
""" OFICmA..-REP 13
Representante Represll'ntante Representante VP Ventas Jefe Ventes Rep....S..nt...nt .. Rep...."ent...nte Jefe vente" Repres ..nt...nte R.. p ..esent...nte
""~
-~
CIUDAD """N
<
compara columnas de dos tablas diferentes. Estas columnas se denominan columnas coincidentes de las dos tablas. Al igual que todas las condiciones de bsqueda.
Figura 7.3.
Una consulta padre/hijo con OFICINAS y REPRESENTANTES.
140
141
Listar cada representante y la ciudad y la regin en que trabajan.

SELECT NOMBRE. CIUDAD. REGION FROM REPRESENTANTES. OFICINAS WHERE OFICINA_REP = OFICINA
NOMBRE CIUDAD REGION
Listar las oficinas y los nombres y puestos de sus jefes.

SELECT CIUDAD. NOMBRE. PUESTO FROM OFICINAS, REPRESENTANTES WHERE JEF = NUM_EMPL CIUDAD Castelln Almeria Navarra Daimiel Len NOMBRE Bernardo Snchez Bruno Arteaga PUESTO VENTAS JEF VENTAS REP VP VENTAS VENTAS JEF VENTAS JEF
Mara Jimnez Samuel Clavel
Bernardo Snchez
Pablo Cruz Daniel Ruidrobo Bruno Arteaga Susana Santos Len Freire Neus Azcrate
Navarra Navarra Castelln Castelln
Este Este
Este
Este
SaI'luel Clavel
Len Freire Len Freire
Castelln
Este
Este
Almeria
Len Len Daimiel
Oeste Oeste Oeste
La tabla OFICINAS (hijo) contiene JEF, una clave externa para la tabla (padre) REPRESENTANTES. Esta relacin se usa para hallar la fila correcta de REPRESENTANTES para cada representante, de forma que se pueda incluir en los resultados el nombre y el puesto correc[Qs del jefe. SQL no requiere que las columnas coincidentes se incluyan en los resultados de una consulta multitabla. A menudo se omiten en la prctica, como en los dos ejemplos precedentes. Esto es porque las claves primarias y externas son generalmente nmeros identificadores (como los nmeros de oficina y de empleados en los ejemplos) que las personas consideran difciles de recordar, mientras que los nombres asociados (ciudades, regiones, nombres, puestos) son ms fciles de comprender. Es muy comn que se usen nmeros de identificacin en la clusula WHERE para reunir dos tablas, y especificar nombres ms descriptivos en la clusula SELECT para generar las columnas de los resultados.
La tabla REPRESENTANTES (hijo) contiene OFICINA_REP, una clave externa de la tabla OFICINAS (padre). Esta relacin se usa para encontrar la fila de OFICINAS correcta para cada representante, de forma que se incluyan las ciudades y regiones correctas en los resultados. Aqu hay otra consulta que involucra las mismas dos tablas, pero con los papeles de padre e hijo invertidos, como se muestra en la Figura 7.4.
NUMJ:MPL
105 109 102 106 104
EDAD OFICINILREP PUESTO NOMBRE Bruno Arteaql 37 13 Representante Mara Jimmel 11 Representante 31 SUsana Santos 21 Representante 5a=.tel Clavel 11 VP Ventas 52 12 Jefe Ventas Bernardo Srlchel 33 OaJ:iel Ruidrobo 45 12 Representante NULL Representante TOIlIs sal 41 Len freire 62 21 Jefe Vent.as lD3 ~o Crul 29 12 Represent.ant.e . lI.zcrat.e lD7 22 Represent.ant.e
.
"
(
<
Reuniones con criterios de seleccin de filas

La condicin de bsqueda que especifica las columnas coincidentes de una consulta multitabla se puede combinar con otras condiciones de bsqueda para restringir ms los contenidos de los resultados. Supngase que se desea volver a ejecutar la consulta anterior mostrando slo las oficinas con los mayores objetivos de ventas:
Listar las oficinas con un objetivo superior a 600.000 .
SELECT CIUDAD, NOMBRE, PUESTO FROM OFICINAS, REPRESENTANTES WHERE JEF = NUM_EMPL ANO OBJETIVO> 600000.00 CIUDAD Castelln Len Len NOMBRE Bernardo Snchez Freire PUESTO Jefe Ventas Jefe Ventas
Figura 7.4.
Una consulta padre/hijo diferente con OFICINAS y REPRESENTANTES.
142
Captulo 7: Consultas muJtitabla (reuniones)
143
Con la condicin de bsqueda adicional, las filas que aparecen en los resultados de la consulta se restringen ms. El primer test (JEF = NUM~EMPL) selecciona slo parejas de filas de OFICINAS y REPRESENTANTES que tienen la relacin padre/hijo adecuada; el segundo test selecciona slo las parejas de filas en las que la oficina est por encima del objetivo.
Consultas con tres y ms tablas

SQL puede combinar datos de tres o ms tablas usando las mismas tcnicas bsicas de las consultas de dos tablas. Aqu se muestra un ejemplo simple de una reunin de tres tablas:
Encaje de mltiples columnas

La tabla PED"IDOS y la tabla PRODUCTOS de la base de datos de ejemplo estn relacionadas por una pareja de claves externa y primaria. Las columnas FAB y PRODUCTO de la tabla PEDIDOS forman juntas una clave externa de la tabla PRODUCTOS, encajando sus columnas ID_FAS e ID_PRODUCTO, respectivamente. Para reunir las tablas en trminos de la relacin padre/hijo, se deben especificar ambas parejas de columnas coincidentes, como se muestra en este ejemplo:
Listar los pedidos superiore.s a 25.000 , incluyendo el nombre del representante que tom nota del pedido y el nombre del cliente.
SELECT FROM WHERE AND AND
NUM-
NUM_PEDIDO, IMPORTE, EMPRESA, NOMBRE PEDIDOS, CLIENTES, REPRESENTANTES CLIENTE ~ NUM_CLI REP = NUM~EMPL IMPORTE> 25000.00 IMPORTE 27 .500,00 31 .350,OO 45 .OOO,QO 31 .500,00 EMPRESA Acme Chen Asociados Zeta Producciones J.P. Sotoca NOMBRE
PEDIDO 112987 113069 113045 112961
----------- ----------- ------------------- -------------Bruno Arteaga Neus Azcrate Len Freire Samuel Clavel
Listar todos los pedidos, mostrando la cantidad y descripcin de cada producto.

SELECT NUM_PEDIDO, IMPORTE, DESCRIPCION PROM PEDIDOS, PRODUCTOS WHERE FAS ~ ID_FAS AND PRODUCTO ~ ID_PRODUCTO NUM_PEDIDO
-------~---
I ,
113027 112992 113012 112968 112963 112983 113055 113057
---------- --------------4.104,00 760,00 3.745,00 3.978,00 3.276,00 702,00 150,00 600,00 Serie 2, cable Serie- 2, cable Serie 3, cable Serie 4, cable Serie 4, cable Serie 4, cable Zapata grande Zapata grande
IMPORTE DESCRIPCION
Esta consulta usa dos claves externas de la tabla PEDIDOS, como se muestra en la Figura 7.5. La columna CUST es una clave externa de la tabla CLIENTES, que enlaza cada pedido con el cliente que lo encarg. La columna REP es una clave externa de la tabla REPRESENTANTES, que enlaza cada pedido con el representante que lo anot. Planteando de manera informal, la consulta enlaza cada pedido con su cliente y representante asociados.
Tabla CLIENTES
NillLCLI EMPRESA
Tabla REPRESENtANTES
<..u.
JCP
s .....
~~~ ~~s
REP eLI LIMITE CREDlTO 103 SO.OOO.OO 101 6S.000,OO 105 SO.OOO,OO
NUM RMPL
NOMBRE
EDAD OFICINJ\.....REP
Bruno Arteaga
31
13
Maria Jinlnez
31
48
11
21
susana santos
i
La condicin de bsqueda en la consulta dice a SQL que las parejas de filas relacionadas de las tablas PEDIDOS y PRODUCTOS son aquellas en las que ambas parejas de columnas coincidentes contienen los mismos valores. Las reuniones mul ticolumna que involucran dos tablas son menos comunes que las reuniones de una nica columna y se encuentran generalmente en consultas que involucran claves externas compuestas como sta. No hay ninguna restriccin de SQL sobre el nmero de columnas involucradas en la condicin de encaje, pero las reuniones generalmente reflejan las relaciones del mundo real entre entidades representadas en las tablas de las bases de datos, y estas relaciones se encuentran usualmente en una o slo unas pocas columnas de las tablas.
'\
Resultados de la consl.Ilta
CLIDm REP F
PROOOCTO CJ.Ill'I[l>,D
IMPORTE
NUI\_PEDlOO CAN'J'IDA!l EMPRESA 00l!ERE
112961 17/12/1989
113012 11/0111990 112989 03/01/1990
l'. 1, ,JI' I
, I
: I
2A4.4L 41003 114
7 21.500,OO 35 3.745.00 6 1.458,OO
Figura 7.5.
Una reunin de tres tablas.
144
Capftulo 7: Consultas multitabla (reuniones)
145
Aqu hay otra consulta de tres tablas que usa una organizacin diferente de relaciones padre/hijo:
Listar los pedidos superiores a 25.000 , mostrando el nombre del cliente que lo encarg y el nombre del represelllanle asignado al cliente.
SELECT FROM WHERE AND HUM_PEDIDO. IMPORTE, EMPRESA, NOMBRE PEDIDOS, CLIENTES. REPRESENTANTES CLIENTE = NUM_eL! REP_eL! = NUM_EMPL
No es extrao encontrar consultas de tres o incluso cuatro tablas en aplicaCiones SQL de produccin. Incluso en los confines de la pequea base de datos de ejemplo, de cinco tablas, no es difcil enconlrar una consulta de cuatro tablas con sentido: Listar Los pedidos superiores a 25.000 t: mostrado el nombre del cliente que lo encarg, el representante del cliente y la oficina en la que trabaja el representante.
SELECT FROM WHERE AND ANO ANO NUM_PEDIDO, IMPORTE, EMPRESA, NOMBRE, CIUDAD PEDIDOS, CLIENTES, REPRESENTANTES. OFICINAS CLIENTE ~ NUM_CLI REP_CLI ~ NUM_EMPL OFICINA_REP ~ OFICINA IMPORTE> 25000.00 IMPORTE EMPRESA 27.500,OO 31.350,OO Chen Asociados 45.000,OO Zeta Producciones 31.500,OO J,P, Sotoca NOMBRE CIUDAD
AND IMPORTE> 25000.00

NUM_PEDIDO
-----------
JI ~
11
112987 113069 113045 112961
----------27.S00,OO
IMPORTE EMPRESA
~--~--------------
NOMBRE
-------------Bruno Arteaga Pablo Cruz Len Freire
Acme
31.350.00 Chen Asociados 45.000,OO Zeta Producciones 3l.S00,QO J.P. Sotoca
samuel Clavel
NUM_PEDIDO 112987 113069 113045 112961
----------- -----------
La Figura 7.6 muestra las relaciones de esta consulta. La primera relacin usa de nuevo la columna eLI de la tabla PEDIDOS como una clave externa de la tabla CLIENTES. La segunda usa la columna REP_CLI de la tabla CLIENTES como clave externa de la tabla REPRESENTANTES. Planteando de manera informal, esta consulta enlaza cada pedido con su cliente, y cada cliente con su representante.
------------------ -------------- ---------Acrne Bruno Arteaga Almeria

Pablo Cruz Len Freire Samuel.Clavel Caste1l6n Len Navarra
La Figura 7.7 muestra las relaciones padre/hijo de esta consulta. Se extiende la secuencia de reunin del ejemplo anterior un paso ms, enlazando un pedido con su cliente, el cliente con su representante y el representante con su oficina.
I aOla REPRESENTMITES
""'_D',"
" ~
-.o
OPICIWL.REP
Otras equirreuniones
La gran mayora de consultas multitabla se basan en relaciones padre/hijo, pero SQL no requiere que las columnas coincidentes se relacionen como clave primaria y externa. Cualquier par de columnas de dos tablas pueden servir como columnas coincidentes, siempre que tengan tipos de datos comparables. El siguiente ejemplo muestra una consulta que usa un par de fechas como ~?~umnas coincidentes. Hallar lodos los pedidos recibidos en fechas en las que se haya contratado algn lluevo representante.
SELECT NUM_PEDIDO., IMPORTE, FECHA_PEDIDO, FROM PEDIDOS, REPRESENTANTES WHERE FECHA_PEDIDO ~ FECHA~CONTRATO NUM_PEDIDO IMPORTE FECHA_PEDIDO NOMBRE
T'b"'m~~
"",,-m
210~
""
Len pre:ire Pablo Cru:l . Neu$ A:lc!rate
" " "

m
"
LoIMI"fE_CRrolro
" u
EMPRU...
JCP s .....
T.b""~'oo'~
NUlLPEDIDO
Filas
~
.05
SO.OOO,OO 6S.000,OO SO.OOO,OOE
"aSUlIaDOS ae III COfl$una

~,= ~
FEOlA..PlXlt
CA.'lTIIJ)
IMPORTE
112'61 11/12/1989 113012 11/01/1990 112'89 03/01/U'0
I~ '" '"
U
<05
2101
~ ;4
7 31.S00,00 3S 3.74S,00 ---i 1.,sa,00
----------- ----------- ------------- -------------3.978,OO 12-0CT-89 Maria Jimnez 112968

112979 112975 112968 112979 112975 15.000,OO 2.100.00 3.978.-00 15.000,OO 2.100.00 12-QCT-89 12-OCT-89 12-0CT-89 12-0CT-89 12-0CT-89 Maria Jimnez Mara Jimnez Len Freire ;1' : Len Fre i re Len,Freire
NOMBRE
i I
i
Figura 7.6.
Una reunin de tres tablas con relaciones padre/hijo en cascada.
lL
'--
146
147
Tabla OFICINAS
OFICINA
Tabla PEDIOOS
q , "
n
:22 Daimiel
N8varrl
"""'"
."","
oeste
Este Este
~ ". ~~
io
~,.
~'"
'" ". '" '" '"
Nl/tLPEDIOO FECHA.-PEDlOO
CU~
l' l' l'
Tebla REPReSEN'I'Am'ES
WUM DlPL
tl\nLEMPL
NOKBRE
OPIClNAJtEP
~
O
Pllblo cru~ ~u. A"c'rat..
..... h.i..
"
29
~
12
~
'" '" '" '" '" no '" '" '"

'"
Bruno Art.eaqa M<l..-ia Jilllne" Sus..na sant.os 5aa1el Cl..vel Berna...-do Snche o..niel Ruidrobo TOIlIs 5<>." Len f"reire Pelo Cruz Nes "'"cArat.e
12/02.L1988 2/101198 10/1211986 ;:: 14/06/1988 19/0511987
~"""""'"
113051
I ~~~~?~198: ~
0~;~~;~:87''''
U/11/1988
R< ~
n
....?"
m
10L!!2lJ.J90 12110/198 30/1;1111990
2118 2102 2107
24~90
2110/198" 2210111990
----
h;
2124 2114 2103
113055
04Lllll989 121101198 15/1;1:.1/1990
2118 2111 2108
Figura 7.8.
~
Una reunin sin claves primaria y externa.
JCP S.A.
~'~"~.
21 3 I " "
lOS
~~~
SO.ooo.oae
fiS.OOO.OO 50.000.ooe
,'
112961 17/12/1989
CLlEIlfE
diferentes (112968,112975 Y 112979) se realizaron el 12 de octubre de 1989, y se contrataron dos representantes (Len Freire y Maa Jimnez) el mismo da. Los tres pedidos y los dos representantes producen seis filas de resultados. Esta relacin varios a varios es diferente de la relacin uno a varios creada con las columnas coincidentes de la clave primaria y externa. La situacin se puede resumir corno sigue: Las reuniones que encajan las claves primarias con las externas siempre producen relaciones padrelhijo uno a varios. Otras reuniones tambin pueden generar relaciones uno a varios si la columna coincidente en al menos una de las tablas tiene valores nicos en todas las filas de la tabla. En general, la reunin de columnas coincidentes arbitrarias generan relacio nes varios a varios. Ntese que estas tres situaciones diferentes son independientes de cmo se escriba la instruccin SELECT que expresa la reunin. Los tres tipos de reunin se escriben de la misma forma -incluyendo un test de comparacin entre los pares de columnas coincidentes en la clusula WHERE. No obstante, es til pensar en las reuniones de esta manera para comprender cmo traducir una consulta en lenguaje natural a la instruccin SELECT correcta.
IMPORTE:
113012 11/01/1990 112989 .03/01/1990
3losaD,oae
3.745.00
1.458,OO
r---t
I
Figura 7.7.
"
Una reunin de cuatro tablas.
Los resultados de esta consulta vienen de pares de filas de las tablas PEDIDOS y REPRESENTANTES en las que FECHA_PEDIDO coincide con FECHA_CONTRATO con el representante, como se muestra en la Figura 7.8. Ninguna de estas columnas es una clave externa o primaria, y la relacin entre pares de filas es extraa -10 nico que inevitablemente hay en comn entre los pedidos y los representantes es que han ocurrido en la misma fecha. Sin embargo, SQL rene de todas formas y sin problemas las tablas. Columnas coincidentes como las del ejemplo generan una relacin varios a varios entre las dos tablas. Varios pedidos pueden compartir la fecha de contrato de un representante, y ms de un representante puede haber sido contratado en la fecha en que se haya realizado un determinado pedido. Por ejemplo. ntese que tres pedidos
Reuniones sin igualdad

El trmino reunin se aplica a cualquier consulta que combine datos de dos tablas comparando los valores de un par de columnas de las tablas. Aunque las reuniones
148
Capftulo 7: Consultas multitabla (reuniones)
149
II
"\
~\
basadas en la igualdad "entre columnas coincidentes (equirreuniones) son con mucho las ms comunes, SQL tambin permite reunir tablas en trminos de otros operadores de comparacin. Aqu hay un ejemplo en que se usa un test de comparacin mayor -q"ue ( como base de una reunin:
Las autorreuniones se pueden usar para crear una consulta multitabla que relacione una tabla consigo misma. Los alias de tabla se pueden usar en la clusula FROM para simplificar los nombres calificados de columna y permitir referencias no ambiguas a columnas en las autorreuniones.
Listarlodas las combinaciones de representan/es y oficinas en las que la cuota de representantes es mayor que el dbjelivo de la oficina.
Nombres calificados de columnas

SELECT NOMBRE. CUOTA; CIUDAD, OBJETIVO FROM REPRESENTANTES, OFICINA~ WHERE CUOTA > OBJETIVO NOMBRE CUOTA CIUDAD
Bruno Arteaga Susana Santos Len Freire
-------------- -----------.'_ ..
--------
------------
OBJETIVO
350.00Q,QO Daimiel 350~OOO,OO Daimiel 350.000,OO Daimiel
300.000,OO 300.000,OO 300.000,OO
La base de datos de ejemplo incluye varios casos en los que dos tablas contienen columnas del mismo nombre. Las rabIas OFICINAS y REPRESENTANTES, por ejemplo, tienen una columna denominada VENTAS. La columna de la tabla OFICINAS contiene las ventas del ao para cada oficina; la de REPRESENTANTES contiene las ventas del ao de cada representante. Normalmente no hay confusin entre las dos columnas porque la clusula FROM determina la que es apropiada en cualquier consulta dada, como en estos ejemplos:
l'
l.
Como en todas las consultas de dos. tablas, cada fila .de los resultados viene de un par de filas, en este caso de las tablas REPRESENTANTES y OFICINAS. La con dicin de bsqueda:
CUOTA_ > OBJETIVO
Mostrar las ciudades en las que las ventas superan los objetivos.
SELECT CIUDAD, VENTAS FROM OFICINAS WHERE VENTAS > OBJETIVO
selecciona un par de .filas donde la columna
CUOTA
de la fila de
REPRESENTANTES
exc~e-la columna OBJETIVO de la.fila de OFICINAS. Ntese ,que los pares de filas de REPRESENTANTES y OFICINAS seleccionadas se relacionan s6lo de esta forma; no se requiere especficamente que la fila de REPRESENTANTES represente a al-
Mostrar todos los represemantes con ventas superiores a 350.000 .

SELECT NOMBRE, VENTAS FROM REPRESENTANTES WHERE VENTAS> 350000.00
guien"quetrabajeen la'ficinaTepresentada en la fila de OFICINAS. El ejemplo es un poco rebuscado e ilustra por qu las 'reuniones ti'asadas en relaciones que sean las de igualdad no son :muy comunes. Sin embargo, pueden ser ,tiles en aplicaciones para la ayuda a la 'toma de decisiones y otras aplicaciones que exploran relaciones ms complejas en la base de datos. loO ;,
'..:'
~.'
Sin embargo, aqu hay una consulta en la que los nombres duplicados causan un problema:
'"
, ...
Mostrar el nombre, ventas y oficina de cada representante.

SELECT NOMBRE, VENTAS, CIUDAD FROM REPRESENTANTES, OFICINAS WHERE OFICINA_REP = OFICINA Error: VENTAS es un nombre ambiguo de columna
Considera.ciones,sobre SQ/..:yconsultas multitabla

n' 1:...
,,1,
ll":
,,:
.,.,""
Las'corisultas-mltitabla 'descntas"ha'sta momento no him requerido ninguna sintaxisespecil' de SQ~'o"caractefsticas"del lenguaje ms all 'de'las descritas para lasJeonsultas 'a 'Una nica tabla. Sin embargo,. :algunas consultas multitabla no se pueden expresar sin las caractersticas adicionales del lenguaje SQL descritas en las siguientes secciones, En concreto: Los nombres calificados de columna se necesitan '3 ';veces'im consultas mul.- " titabla-para'eliminar referencias "ambiguas a columnas. '. ~.I'. Das selecciones de todas lascolumnas (SELECT "')tienen un significado es" J,~' J. -'pecia): para -las consultas multitabla: ........
el
Aunque la descripcin en ingls de la consulta implica que se desea la colum-
na
VENTAS
de la tabla
REPRESENTANTES,
la consulta SQL es ambigua. El SGBD
no tiene forma de saber si se desea la columna VENTAS de la tabla REPRESENTANTES o la de OFICINAS, ya que ambas aportan datos a los resultados de la consulta. Para eliminar esta ambigedad se debe usar un nombre calificado de columna para identificar la columna. Recurdese del Captulo 5 que un nombre calificado de columna especifica el nombre de una columna y la tabla que contiene la columna.
150

VENTAS
151
Los nombres calificados de las dos columnas plo son:

OFICINAS. VENTAS
,
en la base de datos de ejem-
SELECT FROM REPRESENTANTES, OFICINAS WHERE OFICINA_REP = OFICINA
Y REPRESENTANTES. VENTAS
Un nombre calificado de columna se puede usar en cualquier lugar de una instruccin SELECT en la que se permita un nombre de columna. La tabla especificada en la columna calificada debe, por supuesto, coincidir con alguna de las tablas especificada en la lista FROM. Aqu est la versin corregida de la consulta anterior, que usa un nombre de columna calificado:
Obviamente, la forma SELECT * de una consulta llega a ser mucho menos prctica cuando hay dos, tres o ms tablas en la clusula FROM. Muchos dialectos SQL tratan el asterisco como una clase especial de nombre de columna comodn que Se expande en una lista de columnas. En estos dialectos el asterisco se puede calificar con un nombre de tabla, al igual que la referencia a columnas calificadas. En la siguiente consulta, el elemento de seleccin REPRESENTANTES. * se expande en una lista que contiene slo las columnas de la tabla
REPRESENTANTES:
Mostrar el nombre, ventas y oficina de cada representante.

SELECT NOMBRE. REPRESENTANTES. VENTAS, FROM REPRESENTANTES. OFICINAS WHERE OFICINA_REP = OFICINA NOMBRE CIUDAD
Lisiar lada /a informacin de los representantes y los lugares en que trabajan.

SELECT REPRESENTANTES.~. CIUDAD, FROM REPRESENTANTES, OFICINAS WHERE OFICINA_REP = OFICINA REGION
II
~:
REPRESENTANTES,VENTAS CIUDAD
392.725,OO 299.912,OO 142.594.00 286.775.00 30S.673,OO 367.91l,OO 474.0S0,OO 361.86S.00 186.042,OO Navarra Navarra Castell6n Castelln Castel16n Almera Len Le6n Daimiel
~~~~~-~:~~~:---Saffiuel Clavel Bernardo Snchez Pablo Cruz Daniel Ruidrobo Bruno Arteaga Susana Santos Len Freire Neus Azcrate
La consulta producira once columnas de resultados -las nueve de REPRESENlas otras dos columnas solicitadas explcitamente de la tabla de elemento de seleccin todas las columnas calificadas se soporta en muchos pero no en todos los SGBD basados en SQL. No se permiti en el estndar SQLl, pero es parte de la especificacin SQL2 de ANSI/ISO.
TANTES seguidas de OFICINAS. Este tipo
Autorreuniones
Muchas consultas multitabla involucran una relacin que una tabla tiene consigo misma. Por ejemplo, supngase que se desea listar los nombres de todos los representantes y sus jefes. Cada representante aparece como una fila en la tabla REPRESENTANTES, Y la columna JEFE contiene el nmero de empleado del jefe del representante. Podra parecer que la columna JEFE es una clave externa de la tabla que tiene los datos de los jefes. De hecho lo es; es una clave externa de la misma tabla ~EPRESENTANTES. Si se intentase expresar esta consulta como cualquier consulta de dos tablas, con una coincidencia entre clave primaria y externa, sera como:
SELECT NOMBRE, NOMBRE FROM REPRESENTANTES, REPRESENTANTES WHERE JEFE ; NUM_EMPL
i.
i I
El uso de nombres calificados de columna en las consultas muJtitabJa es siempre conveniente. L~ desventaja, por supuesto, es que hacen que el texto de la consulta sea mayor. Al usar SQL interactivo se puede desear en primer lugar una consulta sin nombres calificados y dejar que SQL encuentre las columnas ambiguas. Si SQL informa de un error se puede editar la consulta para calificar las columnas ambiguas.
Selecciones de todas las columnas

Como se estudi en el Captulo 6. SELECT * se puede usar para seleccionar todas las columnas de la tabla nombrada en la clusula FROM. En una consulta multitabla, el asterisco selecciona todas las columnas de todas las tablas de la clusula FROM. La siguiente consulta, por ejemplo, producira quince columnas de resultados -las nueve columnas de la tabla REPRESENTANTES seguidas por las seis de la tabla OFICINAS:
Esta instruccin SELECT es ilegal debido a la referencia duplicada a la tabla en la clusula FROM. Se podra intentar eliminar la segunda referencia a la tabla REPRESENTANTES as:
REPRESENTANTES
Listar (oda la informacin de los representantes y las oficinas en las que trabajan.
SELECT NOMBRE, NOMBRE FROM ~EPRESENTANTES WHERE JEFE = NUM_EMPL
152
11
Capitulo 7: Consultas muJtitabla (reuniones)
153
l'
l.,
Esta consulta es legal, pero no hace 10 que se quiere. Es una consulta sobre una sola tabla, as que SQL toma fila a fila las filas de la tabla REPRESENTANTES aplicando la condicin de bsqueda:
JEFE
==
NUM_EMPL
I
i'
Las filas que satisfacen esta condicin son aqullas en las que las dos colum-
nas tienen el mismo valor -es decir, las filas en que un representante es su propio jefe. No hay tales filas, as que la consulta no produce ningn resultado-o No son
exactamente los datos que se deseaban recibir segn la consulta requerida. Para comprender cmo resuelve SQL este problema hay que imaginar dos co pias idnticas de la tabla REPRESENTANTES, una denominada EMPS, que contiene empleados, y otra denominada JEFES, que contiene jefes, como se muestra en la Figura 7.9. La columna JEFE de la tabla EMPS sera una clave externa de la tabla JEFES, y la siguiente consulta funcionara:
Dado que las columnas de las dos tablas tienen nombres idnticos, todas las referencias a columna estn calificadas. En caso contrario, esto parecera una consulta ordinaria sobre dos tablas. SQL usa exactamente esta tabla imaginaria duplicada para reunir una tabla consigo misma. En lugar de duplicar realmente los contenidos de una tabla, SQL permite simplemente hacer referencia a ella con un nombre diferente, denominado alias de tabla. A continuacin est la misma consulta escrita usando los alias para EMPS y JEFES para la tabla REPRESENTANTES:
Listar los nombres de los empleados y sus jefes.

SELECT EMPS.NOMBRE, JEFES.NOMBRE FROM REPRESENTANTES EMPS, REPRESENTANTES JEFES WHERE EMPS.JEFE = JEFES.NUM EMPL EMPS.NOMBRE JEFES.NOMBRE
Listar los nombres de los representantes y sus jefes.

SELECT EMPS.NOMBRE, JEFES.NOMBRE FROM EMPS, JEFES WHERE EMPS.JEFE = JEFES.NQM_EMPL
Tabl '"U'''
uc.r<.o>
'AN'rES) ''-VI-'''' U" "<'''''<'''''''''''''-'''0>'

NOMBRE
Toms Saz Bruno Arteaga Daniel Ruidrobo Pablo Cruz Mara Jirnnez Bernardo Snchez Len Freire Susana Santos Neus Azcrate
OFICONA.-REP
Daniel Ruidrobo Bernardo Snchez Bernardo Snchez Bernardo Snchez Samuel Clavel Samuel Clavel Sarnuel Clavel Len Freire Len Freire
NmCEMPL
EDAD
I
!II
1
'" '"
'"'
'1
Bruno Artell.gll. Mara Jimne'l: Susana Santos Samuel Clavel Bernardo Snche aniel Ruidrobo s Saz Freb::e cruz zcrllte
n " '" " "
n n n
" " '"
'"
H
" " n """ " "
La clusula FROM asigna un alias diferente a cada una de las dos copias de la tabla REPRESENTANTES involucrada en la consulta, especificando el nombre de alias inmediatamente despus del nombre real de la tabla. Como muestra el ,ejemplo, cuando una clusula FROM contiene un alias de tabla, el alias se debe usar para identificar la tabla en las referencias calificadas a columna. Por supuesto, realmente slo es necesario usar un alias para una de las dos apariciones de las dos tablas en esta consulta. Se podra haber escrito tan fcilmente como:
SELECT REPRESENTANTES. NOMBRE, JEFES.NOMBRE FROM REPRESENTANTES, REPRESENTANTES JEFES WHERE REPRESENTANTES.JEFE = JEFES.NUM_EMPL
l
I
'11I
1
". I
-~ i~
Aqu el alias JEFE se asigna a una copia de la tabla, mientras que el propio nombre de la tabla se usa para la otra copia. A continuacin se muestran algunos ejemplos adicionales de autorreuniones:
11:
,
~ I
Figura
7.9. Una autorreunin de la tabla REPRESENTANTES.
Listar los representantes con una cuota superior a la de su jefe.

SELECT FROM WHERE AND REPRESENTANTES , NOMBRE, REPRESENTANTES,CUOTA, REPRESENTANTES, REPRESENTANTES JEFES REPRESENTANTES.JEFE = JEFES.NUM_EMPL REPRESENTANTES. CUOTA > JEFES.CUOTA JEFES,CUOTA
1 ,
. I
1, lit
l I1
154

REPRESENTANTES CUOTA JEFES. CUOTA
155
REPRESENTANTES. NOMBRE
Bruno Arteaga
---------------------- --------------------- -----------350.000,OO 20D.OOO,OOe:

3ea.OOO,CaE:
275.000,OO
Daniel Ruidrobo Pablo Cruz

Mara Jimnez Len Freire
3ea.OOO,caE:
350.000,OO
200.000,OO 200.000.00 275.000.00 275.000,OO
Listar los representantes que trabajan en una oficina distinta a la de su jefe, mostrando el nombre y oficina en donde trabaja cada uno.
SELECT EMPS.NOMBRE. OFICINA_EMP,CIUDAD, JEFES. NOMBRE, QFICINA_JEF.CIUDAD FROM REPRESENTANTES EMPS. REPRESENTANTES JEFES. OFICINAS OFICINA~EMP. OFICINAS OFICINA_JEF WHERE EMPS.QFICINA_REP = QFICINA_EMP.OFICINA AND JEFES.OFICINA_REP = OFICINA_JEF.OFICINA AND EMPS.JEFE = JEFES.NOM_EMPL AND EMPS.OFICINA_REP <> JEFES.OFICINA_REP
Figura 7.10.
El diagrama sintctico de la clusula FROM.
La Figura 7.10 muestra la forma bsica de la clusula FROM para una instruccin SELECT sobre varias tablas, completada con alias de tabla. La clusula tiene dos funciones importantes:
La clusula
OFICINA_JEF. CIUDAD
Navarra Castelln Navarra Len
EMPS.NOMBRE
OFICINA_EMP.CIUDAD
JEFES.NOMBRE
Bernardo Snchez Bruno Arteaga Len Freire Neus Azcrate
Castelln Almera Len Daimiel
Samuel Clavel Bernardo Snchez Samuel Clavel Len Freire
PROM identifica ladas las labias que aportan datos a los resultados de la consulta. Cualquier columna referenciada en la instruccin SELECT debe venir de una de las tablas listadas en la clusula PROM. (Hay una excepcin para las referencias externas de las subconsultas, como se describe en el Captulo 9.) La clusula FROM especifica la etiqueta que se usa para identificar la tabla en las referencias calificadas a columnas dentro de la instruccin SELECT. Si se especifica un alias de tabla, se convierte en la etiqueta de tll;bla; en caso contrario, el nombre de la tabla, tal y como aparece en la clusula PROM, es el que se convierte en la ~tiqueta.
Alias de tablas
Como se ha descrito en la seccin anterior, los alias de tablas se requieren en las consultas con autorreuniones. Sin embargo, se puede usar un alias en cualquier consulta. Por ejemplo, si una consulta se refiere a una tabla de otro usuario, o si el nombre de la tabla es muy largo, el nombre de la tabla puede llegar a ser tedioso de escribir como un calificador de columna. Esta consulta, que hace referencia a la tabla CUMPLEAOS y pertenece al usuario SAM:
Lisrar los nombres, las cuotas y cumpleaos de los representantes.
SELECT REPRESENTANTES. NOMBRE, CUOTA, SAM.CUMPLEA~OS.BIRTH_DATE FROM REPRESENTANTES, CUMPLEARos WHERE REPRESENTANTES. NOMBRE = SAM.CUMPLEAaOS.NOMBRE
'1,
"
: I
I
ti
El nico requisito para las etiquetas de tabla en la clusula FROM es que todas las etiquetas de una clusula FROM sean distintas entre s. La especificacin SQL2 permite opcionalmente que la palabra clave AS aparezca entre el nombre de la tabla y su alias. Aunque esto hace que la clusula FROM sea ms fcil de leer, no est incluido en todas las implementaciones de SQL. (Ntese que la especificacin SQL2 usa el trmino nombre de correlaci6n para referirse a lo que hemos llamado alias de tabla. La funcin y el significado de un nombre de correlacin son exactamente como se describen aqu; muchos productos SQL usan el trmino alias, y es ms descriptivo en cuanto a la funcin que realiza un alias de tabla. El estndar SQL2 especifica una tcnica similar para designar nombres de columna alternativos, y en esa situacin el nombre alias de columna se denomina realmente alias en el estndar).
es ms fcil de leer y escribir si se usan los alias R y
e para las dos tablas:
Rendimiento de las consultas multitabla

Al aumentar el nmero de tablas de una consulta, la cantidad de esfuerzo requerido para manejarlas se incrementa rpidamente. El propio lenguaje SQL no impone ningn lmite en el nmero de tablas reunidas en una consulta. Algunos productos SQL limitan de hecho el nmero de tablas; un lmite cercan? a ocho es algo muy
Listar los nombres, las cuotas y cumpleaos de los representantes.

SELECT R. NOMBRE , CUOTA. C.BIRTH_DATE FROM REPRESENTANTES R, SAM.CUMPLEA&OS C WHERE R.NOHBRE = S.NOMBRE
I
\
156
157
comn. El alto coste de procesamiento de consultas que renen muchas tablas impone un lmite prctico an menor en muchas aplicaciones. En las aplicaciones de procesamiento interactivo de transacciones (OLTP, Online Transaction Processing) es comn que una consulta contenga slo una o dos tablas. En estas aplicaciones el tiempo de respuesta es crtico -el usuario introduce normalmente uno o dos datos y necesita una respuesta de la base de datos en un segundo o dos-o Algunas consultas OLTP tpicas en la base de datos de ejemplo seran:
El usuario introduce el nmero de cliente en un formulario y el SOBD devuelve el lmite de crdito del cliente, el saldo de la cuenta y otros datos (una consulta a una sola tabla). Un dependiente examina el nmero de producto de un paquete y obtiene el nombre y el precio del producto de la base de datos (una consulta a una sola tabla). El usuario introduce el nombre de un representante y el programa lista los pedidos en curso para ese representante (una consulta a dos tablas).
los resultados que produce mediante una instruccin SELECT dada, y, en menor medida, la teora acerca de las bases de datos relacionales sobre las reuniones.
Multiplicacin de tablas
Una reunin es un. caso especial de una combinacin de datos ms general de dos tablas, conocida como producto cartesiano (o simplemente el producto) de dos tablas. El producto de dos tablas es otra tabla (la tabla producto) que consiste en todos los posibles pares de filas de las dos tablas. Las columnas de la tabla producto son todas las columnas de la primera tabla seguidas de todas las columnas de la segunda tabla. La Figura 7.11 muestra dos pequeas tablas de ejemplo y su producto. Si se especifica una consulta de dos tablas sin una clusula WHERE, SQL obtiene el producto de las dos tablas como resultado. Por ejemplo, esta consulta: Mostrar todas las combinaciones posibles de representantes y ciudades.
SELECT NOMBRE, CIUDAD PROM REPRESENTANTES, OFICINAS
Ili
:1/
I
En cambio, en las aplicaciones de ayuda a la toma de decisiones, es normal que una consulta conlleve muchas tablas diferentes y haga uso de complejas relaciones de la base de datos. En estas aplicaciones los resultados de la consulta se usan a menudo para ayudar en la toma de decisiones costosas, de forma que una consulta que requiera varios minutos o incluso varias horas es perfectamente aceptable. A continuacin se relacionan algunas consultas tpicas para la ayuda a la toma de decisiones para la base de datos de ejemplo: El usuario introduce el nombre de una oficina y el programa lista los 25 pedidos mayores correspondientes a los representantes de esa oficina (una consulta a tres tablas). Un informe resume las ventas por el tipo de producto para cada representante, mostrando los representantes y los productos que venden (una consulta a tres tablas). Un jefe considera la posibilidad de abrir una nueva oficina de ventas en Salamanca y ejecuta una consulta que analiza el impacto sobre los pedidos, productos, clientes y los representantes que los gestionan (una consulta a cuatro tablas).
obtendra el produclO de las tablas REPRESENTANTES y OFICINAS, mostrando todos los posibles pares de representantes y ciudades. Habra 50 filas de resultados (5 oficinas * 10 representantes = 50 combinaciones). Ntese que la instruccin SELECT es exactamente la misma que se usara en la reunin de dos tablas, sin la clusula WHERE que compara las columnas coincidentes, como en: Mostrar todos los representantes y las ciudades en que trabajan.
Tabla CHICAS
NOMBRE
CIUDAD Caste116n Barcelona Castelln
Beatri Mara Susana
La estructura de una reunin

Tabla CHICOS
Para las reuniones simples es muy fcil escribir la instruccin SELECT correcta, basada en la solicitud formulada en lenguaje natural, o examinar una instruccin SELECT y determinar lo que hace. Sin embargo, cuando se renen varias tablas o cuando las condiciones de bsqueda son complejas, llega a ser muy difcil observar simplemente una instruccin SELECT y determinar lo que significa. Por esta razn es importante definir con ms cuidado y ms formalmente lo que es una reunin,
NOMBRE
CIUDAD
Jaime Samuel
Daimiel Castelln
Figura 7.11.
El producto de dos tablas.
158

5. 6.
159
SELECT NOMBRE, CIUDAD FROM REPRESENTANTES, OFICINAS WHERE OFICINA_REP = OFICINA
Estas dos consultas ilustran una relacin importante entre las reuniones y los
productos:
7.
Si se especifica SELECT DISTINCT, eliminar todas las filas duplicadas del resultado que se hubieran producido. Si la instruccin es una UNION de instrucciones SELECT, mezclar los resul tados de las instrucciones individuales en una nica tabla de resultados. Eliminar las filas duplicadas a menos que se especifique UNIQN ALL. Si hay una clusula ORDER BY, ordenar los resultados corno se especifique.
Una reunin entre dos tablas es simplemente el producLO d.e las dos tablas con algunas de sus filas eliminadas. Las filas .eli~llinadas son ~recl.samente las que no cumplen la condicin de las columnas comcldentes en la leU~l?,n. , Los productos son importantes porque SO~ parte de ~a d.efimclOn ~ormal de como procesa SQL una consulta multitabla, descnta en la sigUIente seccin.
Las filas generadas por este procedimiento contienen los resultados de la consulta. Siguiendo los pasos anteriores: l. La clusula FROM genera todas las posibles combinaciones de filas de las tablas CLIENTES (21 filas) y PEDIDOS (30 filas), produciendo una tabla producto de 630. La clusula vlHERE selecciona slo las filas de la tabla producto en las que los nmeros de cliente coinciden (NUM_CLI = CLIENTE) Y el nmero de cliente sea el especificado (NUM_CLI = 2103). Slo se seleccionan cuatro filas; las otras 626 filas se eliminan. La clusula SELECT extrae las tres columnas requeridas (EMPRESA, NUM_PEDIDO y CANTIDAD) de cada fila restante de la tabla producto para generar cuatro filas de resultados detallados de la consulta. La clusula ORDER BY ordena las cuatro filas de la columna NUM_PEDIDO para generar los resultados finales de la consulta.
Reglas para el procesamiento de consultas multitabla

Los pasos que siguen al cdigo de ejemplo .siguient~ vuel~e.n a plantear las re~las para el procesamiento de consultas SQL, Intro~ucldo ongInalmente en la ~lg~ ra 6.14, y las expande para incluir consultas ~ultltabla. ~as reglas definen ~I s.lgmficado de cualquier instruccin SELECT multltabla especificando un procedl~11Iento que siempre genera el conjunto correcto de resultados. Para ver cmo funclOna el procedimiento, considrese esta consulta:
2.
3.
4.
Listar el nombre de la empresa y rodos los pedidos del cliente nmero 2103.
SELECT FROM WHERE AND ORDER EMPRESA Acrne Acme Acme Acme EMPRESA, NUM_PEDIDO, CLIENTES, PEDIDOS NUM_CLI = CLIENTE NUM eLI = 2103 BY NUM_PEDIDO NUM_PEDIDO IMPORTE
Obviamente, ningn SOBD basado en SQL resolvera la consulta de esta forma, pero el propsito de la definicin previa no es describir cmo un SGBD resuelve la consulta. En cambio, constituye una definicin de cmo determinar exactamente lo que significa una consulta multitabla -es decir, el conjunto de resultados que debera producir.
IMPORTE
-------- ----------- ----------3.276,OO 112963

112983 112987 113027 702,OO 27 .SOO.OO 4 .104.00
Reuniones externas*
La operacin de reunin de SQL combina la informacin de dos tablas formando parejas de filas relacionadas de dos tablas. Las parejas de filas que conforman la tabla reunida son aquellas en las que las columnas coincidentes de cada una de las dos tablas tienen el mismo valor. Si una de las filas de una tabla no tiene correspondencia en este proceso, la reunin puede producir resultados inesperados, como se ilustra en estas consultas:
Para generar los resultados de una instruccin SELECT:
1.
2.
3.
l'
4.
Si la instruccin es una UNION de instrucciones SELECT, aplicar los pasos 2 al 5 a cada una de las instrucciones para generar sus resultados individuales. Formar el producto de las tablas listadas en la clusula FROM. Si la clusula FROM lista slo una tabla, el producto es esa tabla. Si hay una clusula WHERE, aplicar su condicin de bsqueda ~ ~ada fila ~e la tabla producto, conservando las filas para las que la condiCin de busqueda es TRUE (y descartando a las que corresponda FALSE o NULL). Para cada fila restante calcular el valor de cada elemento en la lista de seleccin para produci; una nica fila de resultados. Por cada referencia a columna, usar el valor de la columna de la fila en curso.
LisIar los representames y las oficinas en las que trabajan.

SELECT NOMBRE, OFICINA_REP FROM REPRESENTANTES NOMBRE Bruno Arteaga Mara Jimnez OFICINA_REP 13 11
160

21 11 12 12

Pablo Cruz Daniel Ruidrobo Bruno Arteaga Susana Santos Len Freire Neus Azcarate
161
Susana Santos Samuel Clavel Bernardo Snchez Daniel Ruidrobo Toms Saz Len Freire
Castelln Castelln
Almera Len Len
Pablo Cruz
Neus Azcrate
NULL 21 12 22
Daimiel
Listar los representantes y las ciudades en las que trabajan.

SELECT NOMBRE, CIUDAD FROM REPRESENTANTES, OFICINAS WHERE DFICINA_REP = OFICINA
NOMBRE
Mara Jimnez Samuel Clavel Bernardo Snchez Pablo Cruz
CIUDAD
Navarra Navarra
Castelln
Daniel Ruidrobo
Bruno Arteaga Susana Santos Len Freire Neus Azcrate
Castel16n Castel16n Almeria

Len Len
Estos resullados se generan usando un tipo diferente de operacin reunin, denominada reunin externa (indicada con la notacin *= en la clusula WHERE). La reunin externa es una extensin de la reunin estndar descrita anteriormente en este captulo, que se denomina a veces reunin interna. El estndar SQL I especifica slo la reunin interna; no incluye la reunin externa. Los primeros produc tos SQL de IBM slo daban soporte a la reunin interna. Sin embargo, la reunin externa es una parte bien asimilada y til del modelo de bases de datos relacionales, y se ha implementado en muchos productos SQL de marcas diferentes a lBM, incluyendo los productos lderes de Microsoft, Sybase, Oracle e Informix de 18M. La reunin externa tambin es la forma ms natural de expresar un cierto tipo de consultas, como se muestra en el resto de esta seccin. Para comprender bien la reunin externa es til abandonar la base de datos de ejemplo y considerar las dos tablas simples de la Figura 7.12. La tabla CHICAS
Daimiel
Tabla CHICAS NOMBRE Ana Beatriz Mara Nuria
SUS41111
Basndonos en las descripciones en lenguaje natural de estas dos consultas, probablemente cabra esperar que produjesen el mismo nmero de filas. Pero la primera consulta incluye una fila cada uno de los diez representantes, mientras que la segunda slo produce nueve. Por qu? Porque Toms Saz no est actualmente asignado y tiene un .valor NULL en la columna OFICINA_REP (que es la columna coincidente de la reunin). Este valor NULL no encaja con ninguno de los nmeros de oficina de la tabla OFICINAS, por lo que la fila de Toms de la tabla REPRESENTANTES no encaja con ninguna. Como resultado, desaparece de la reunin. La reunin estndar SQL tiene as el potencial de perder informacin si las tablas que se renen contienen filas que no encajan. Basndonos en la versi6n de la consulta en lenguaje natural cabra esperar que la segunda consulta produjese resultados como los siguientes:
ICIUDAD
Oenia CastelIn Barcelona NULL CasteU6n
,.
=:
rabra CHICOS
NOMBRE
CIUDAD Denia Castelln Barcelona

NULL
An' Be4tri Hara Nuria Susana
Castelln
Files
no coincidentes
Tabla resultado de la reunin externa

SELECT NOMBRE. CIUDAD FROM REPRESENTANTES. OFICINAS WHERE OFICINA_REP -; OFICINA NOMBRE
Toms
Filas no coincidentes
"'"',.
--+
Mara
AnA
NULC HULL
ClI1CAS. NOKBRE:
SUS4nII.
Beatriz
CIUDAD NULL
- { Nuria
Oflo,s .ClUOMl Ol.ICOS.1lIlBRE Ol.ICAS.CIIJIWI Barcelona Herminio Barcelona Barcelona Jos Barcelona Catelln CasteU6n samuel Castelln CalStelln Semuel Denia NULL NULL
NULC NULC NULL
NULL
NULC
Jailllt! Genaro
Daimiel
NULL
Saz Mara Jimnez
~-
Navarra Samuel Clavel Navarra Bernardo Sanchez Castelln
Figura 7.12.
Anatoma de una reunin externa.
162

SELECT FROM CHICAS. CHICOS WHERE CHICAS.CIUDAD *;* CHICOS.CIUDAD
163
lista cinco chicas y las ciudades en las que viven; la tabla CHICOS lista cinco chicos y sus ciudades de residencia. Para encontrar los pares de chicas y chicos que viven en la misma ciudad se podra usar esta consulta, que forma la reunin ioter na de las dos tablas:
Listar las chicas y los chicos que viven en la misma ciudad.

SELECT FRDM CHICAS, CHICOS WHERE CHICAS.CIUDAD : CHICAS.NOMBRE Mara Maria Susana Beatriz
-------------- -------------- --------------------------- Boston Mara Jos

Mara Susana Beatriz Ana Nuria NULL NULL Boston Castelln Castel16n Daimiel NULL NULL NULL Herminio Sarnuel Sarnuel NULL NULL Joime Genaro Boston Boston Caste1l6n Castelln NULL NULL DalIas NULL
CHICAS.NOI1BRE
CHICAS.CIUDAD
CHICOS. NOMBRE
CHICOS.CIUDAD
CHICOS CIUDAD CHICOS NOMBRE CHICOS.CIUDAD
-------------- -------------- -------------- ------------Boston

Boston
Bosten Castel16n Castelln
CHICAS. CIUDAD
Jos Herminio Samuel Samuel
Boston Castel16n Castelln
La reunin interna produce cuatro filas de resultados. Ntese que dos de las chicas (Ana y Nuria) y dos de los chicos (Jaime y Genaro) no estn representados en los resultados. Estas filas no se pueden emparejar con ninguna fila de la otra tabla y, por tamo, no aparecen en los resultados de la reunin interna. Dos de las filas sin correspondencia (Ana y Jaime) tienen valores vlidos en las columnas CIUDAD, pero no coinciden con ninguna ciudad de la Olra tabla. Las otras dos filas no coincidentes (Nuria y Genare) tienen valores NOLL en las columnas CIUDAD, y por las reglas del manejo de valores NULL en SQL, el valor NULL no encaja con ningn otro valor (ni siquiera con otro valor NULL). Supngase que se desea listar los pares chica/chico que viven en la misma ciudad, y que se incluyan tambin los que no coincidan. La reunin externa de las tablas CHICAS y CHICOS produce exactamente este resultado. La siguiente lista muestra el procedimiento para la construccin de la reunin externa, y esta reunin se muestra grficamente en la Figura 7.12. ]. 2. Empezar con la reunin interna de las dos tablas usando las columnas coincidentes de la forma usual. Para cada fila de la primera tabla que no coincida con ninguna de la segunda, aadir una fila a los resultados usando los valores de las columnas de la primera tabla y asumiendo un valor NULL para todas las columnas de la segunda tabla. Para cada fila de la segunda tabla que no coincida con ninguna fila de la primera tabla, aadir una fila al resultado usando los valores de las columnas de la segunda tabla y asumiendo un valor NULL para todas las columnas de la primera tabla. La tabla resull.l''~ .rerna de dos tablas. . <':QL que produce la reunin externa:
ClLtu ....
La reunin externa de dos tablas contiene ocho filas. Cuatro de las filas son idnticas a las de la reunin interna de las dos tablas. Otras dos filas, de Ana y Nuria, vienen de filas que no encajan de la tabla CHICAS. Estas filas tambin se han rellenado con valores NULL hacindolas corresponder con una fila imaginaria con valores NULL en las columnas de la tabla CHICOS, y aadindolas a los resultados. Las ltimas dos filas, de Jaime y Genaro, vienen de filas que no encajan de la tabla CHICOS. Estas filas tambin se han rellenado con valores NULL hacindolas corresponder con una fila imaginaria con valores NULL en las columnas de la tabla CHICAS, y aadindolas a los resultados. Como muestra este ejemplo, la reunin externa es una reunin que preserva informacin. Cada fila de la tabla CHICOS se representa en los resultados (a veces ms de una vez). De forma similar, cada fila de la tabla CHICAS se representa en los re.sultados (de nuevo, en ocasiones ms de una vez).
Reuniones externas por la izquierda y por la derecha*

Tcnicamente, la reunin externa producida por la consulta anterior se denomina reunin externa completa de dos tablas. Ambas tablas se tratan de forma simtrica en la reunin externa completa. Hay otras dos reuniones externas bien definidas que no tratan de fonna simtrica a las dos tablas. La reunin externa por la izquierda de dos tablas se produce siguiendo los pasos 1 y 2 de la lista numerada anterior, pero omitiendo el paso 3. La reunin externa por la izquierda incluye as copias rellenas con valores NULL de las filas que no encajan de la primera tabla (izquierda), pero no incluyen las filas que no encajan de la segunda (derecha). A continuacin se muestra la reunin externa por la izquierda de las tablas CHICAS y CHICOS: Listar las chicas y chicos de la misma ciudad y cualquier chica que no encaje.
SELECT FROM CHICAS. CHICOS WHERE CHICAS.CIUDAD * ; CHICOS.CIUDAD
3.
4.
A continuacin se muestra, Listar las chicas y chicos de la I/usma chica que no encaje.
,do cualquier chico o
164

CHICAS.CIUDAD
Bostan Bostan Castelln Castel16n Daimiel NULL CHICOS. NOMBRE Jos Herminio Samuel Samuel NULL NULL CHICOS.CIUDAD Bostan Bostan Castelln Castel16n NULL NULL
165
CHICAS. NOMBRE Mara Maria Susana Beatriz
Ana
Nuria
La consulta produce seis filas de resultados. mostrando los pares chica/chico que coinciden con las chicas que no encajan. Los chicos que no encajan no aparecen en los resultados. De forma similar, la reunin externa por la derecha de dos tablas se produce siguiendo el paso 1 y el 3 de la lista numerada anterior, pero omitiendo el paso 2. La reunin externa por la derecha incluye copias con valores NULL de las filas que no encajan de la segunda tabla (derecha), pero no incluye las filas que no encajan de la primera tabla (izquierda). A continuacin se muestra una reunin externa por la derecha de las tablas CHICAS y CHICOS: Listar las chicas y chicos de la misma ciudad y los chicos que no encajan.
SELECT FRDM CHICAS, CHICOS WHERE CHICAS.CIUDAD ~- CHICOS.CIUDAD CHICAS.NOMBRE Maria Maria Susana Beatriz NULL NULL CHICAS.CIUDAD Boston Boston Castelln Castelln NULL NULL
las tablas REPRESENTANTES y OFICINAS. La columna OFICINA_REP de la tabla REPRESENTANTES es una clave externa de la tabla OFICINAS; indica la oficina en la que trabaja cada empleado y si se permite que contenga un valor NULL para un nuevo representante que no haya sido an asignado a una oficina. Toms Saz es uno de tales representantes de la base de datos de ejemplo. Cualquier reunin que use la relacin REPRESENTANTES~a-OFICINASy espere incluir datos de Toms Saz debe ser una reunin externa, con la tabla REPRESENTANTES como la tabla mayor. A continuacin se muestra el ejemplo usado anteriormente:

SELECT NOMBRE, CIUDAD FROM REPRESENTANTES, OFICINAS WHERE QFICINA_REP -: OFICINA NOMBRE Toms Saz Maria Jimnez Samuel Clavel Bernardo Snchez Pablo Cruz Daniel Ruidrobo Bruno Arteaga Susana Santos Len Freire Neus Azcrate CIUDAD NULL Navarra Navarra Castell6n Castelln Castelln Almeria Len Len Daimiel
--------------
-------------- -------------Jos Herminio Samuel Samuel Jaime Genaro
CHICOS.NOMBRE
CHICOS.CIUDAD Boston Boston Castelln Castelln DalIas NULL
--------------
Esta consulta tambin produce seis filas de resultados, mostrando los pares chica/chico que coinciden y los chicos que no encajan. Esta vez no aparecen en el resultado las chicas que no encajan. Corno se indic antes, las reuniones externas por la izquierda y por la derecha no tratan de forma simtrica a las dos tablas. A menudo es til pensar que una de las tablas es la tabla mayor (todas sus filas se representan en el resultado), y la otra tabla, la menor (la que contiene valores NULL en las columnas de los resultados de la consulta de reunin). En una reunin externa, la tabla izquierda (la primera que se menciona) es la tabla mayor, y la derecha (la ltima que se menciona) es la menor. Los papeles se invierten en una reunin externa por la derecha (la tabla derecha es la mayor, y la izquierda, la menor). En la prctica, las reuniones por la izquierda y por la derecha son ms tiles que la reunin externa completa, especialmente cuando se renen datos de dos tablas con. una relacin padre/hijo (clave primaria/clave externa). Para ilustrarlo considrese de nuevo la base de datos de ejemplo. Ya se ha visto un ejemplo con
Ntese en este caso (una reunin externa por la izquierda) que la tabla hijo (REPRESENTANTES, la tabla con la clave externa) es la tabla mayor de la reunin externa, y la tabla padre (OFICINAS) es la tabla menor. El objetivo es retener las filas que contienen valores NULL de la clave externa (como los de Toms Saz) de la tabla hijo en los resultados, de forma que la tabla se convierta en la tabla mayor en la reunin externa. No importa si la consulta se expresa realmente como una reunin externa por la' izquierda (como se hizo previamente) o como una reunin externa por la derecha como sta:

SELECT NOMBRE, CIUDAD FROM REPRESENTANTES, OFICINAS WHERE OFICINA ~- OFICINA~REP NOMBRE Toms Saz Maria Jimnez Samuel Clavel Bernardo Snchez Pablo Cruz Daniel Ruidrobo CIUDAD NULL Navarra Navarra Castelln Castelln Castelln
166

Almera Len Len Daimiel
167

Neus Azcrate
Lo que importa es que la tabla hijo es la tabla mayor de la reunin externa. Tambin hay consultas de reunin tiles en las que el padre es la tabla mayor, y la tabla hijo es la menor. Por ejemplo, supngase que la empresa de la base de datos de ejemplo abre una nueva oficina de ventas en Daganzo, pero inicialmente la oficina no tiene representantes asignados a ella. Si se desea generar un informe que liste todas las oficinas y los nombres de los representames que trabajan en ellas, se podra querer incluir una fila representando a la oficina de Daganzo. Aqu est la consulta de reunin externa que produce estos resultados:
SQL Server. Esta notacin indica una reunin externa aadiendo un asterisco al ~est. de comparacin en la clusula WHERE que define la condicin de reunin. Para mdlcar la reunin exte~na de dos tablas, TBLl y TBL2, sobre las columnas COLly COL2, se pone un astensco (*) antes y despus del operador de reunin estndar. El test de comparacin resultante de la reunin externa completa es:
WHERE COLl
~=*
COL2
.Para indicar una reunin externa por la izquierda de TBLl y TBL2, slo se espeCIfica el primer asterisco, dando el siguiente test de comparacin:
WHERE COL! *= COL2
Listar las oficinas y los representantes que trabajan en cada una.

SELECT CIUDAD, NOMBRE FROM OFICINAS, REPRESENTANTES WHERE OFICINA ~= OFICINA_REP CIUDAD Navarra Navarra Castelln Castelln Castelln Almera Len Len Daimiel Daganzo NOMBRE Mara Jimnez Samuel Clavel Bernardo snchez Pablo Cruz Daniel Ruidrobo Bruno Arteaga Susana Santos Len Freire Neus Azcrate NULL
. Para indicar una re~nin externa por la derecha de TBLl y TBL2, slo se espeCifica el segundo astensco, dando el siguiente test de comparacin:
WHERE COL! =* COL2
II
. ~e puede usar u.na reunin, ~xterna c.on cualquiera de los operadores de comparaClOn usando la mIsma notaclOn. Por ejemplo, una reunin externa por la izquierda de TBLl y TBL2 que use una comparacin mayor igual (>=) producira un test de comparacin como ste:
WHERE COL! *>= COL2
En este caso, la tabla padre (OFICINAS) es la tabla mayor de la reunin externa, y la tabla hijo (REPRESENTANTES) es la menor. El objetivo es asegurar que todas las filas de la tabla OFICINAS se representan en los resultados, as que desempea el papel de la tabla mayor. Los roles de las dos tablas estn exactamente invertidos con respecto al ejemplo anterior. Por supuesto, la fila de Toms Saz, que estaba incluida en los resultados del ejemplo anterior (cuando la tabla REPRESENTANTES era la mayor), no se encuentra en este conjunto de resultados porque ahora REPRESENTANTES es la tabla menor.
. Grade tambin incluye la operacin de reunin externa, pero usa una notacin dlfe~ente. Esta notacin inicia la reunin externa en la clusula WHERE incluyendo un signo de suma entre parntesis despus de la columna cuya tabla tiene aadida lafila imaginaria NULL (es decir, la tabla menor de la reunin externa). La reunin externa por la izquierda de TBLl y TBL2 produce la condicin de bsqueda:
WHERE COLl = COL2
{+)
y la reunin externa por la derecha de queda:

WHERE COLl
(+)
TBLl
TBL2
produce la condicin de bs-
= COL2
Notacin de la reunin externa*

Dado que la reunin externa no form parte del estndar SQLl y no se implement en los primeros productos SQL de 1BM, los fabricantes de SGBD que daban soporte a la reunin externa usaron varias notaciones en sus dialectos SQL. La notacin *=*, usada en los ejemplos anteriores de esta seccin, se emplea en
Ntese que el signo de suma aparece en el lado opuesto de la comparacin con respecto a la notacin de SQL Server. Grade no incluye la reunin externacompleta, pero, como se indic anteriormente, esto no disminuye la utilidad prctica de las reuniones externas de Oracle l.
I N. del T.: A diferencia de versiones anteriores, la versin Oracle 9i incorpora la notacin estndar ANSI/ISO SQL: 1999 para las reuniones eXlernas, incluyendo la reunin externa completa.
168
Captulo 7: Consultas muftitabla (reuniones)
169
Aunque ambas notaciones para las reuniones externas son relativamente convenientes. son tambin algo engaosas. Recurdese que las reglas para el procesamiento de consultas SQL multitabla comenzaban examinando la clusula FROM de una consulta y construyendo conceptualmente el producto de dos (o ms) tablas. Slo despus de que la tabla product.o se construyera, el SGBD comenzaba a eliminar las filas que no satisfacan la condicin de bsqueda de la clusula WHERE. Pero con la notacin de SQL Server o de Oracle, la clusula FROM no indica al SOBD si construir una tabla producto que sea s610 la reunin interna o una que incluya filas con valores NULL de una reunin externa. Para determinarlo, el SGBD debe anticipar la clusula WHERE. Un problema ms serio es que una reuni6n entre dos tablas puede involucrar ms de un par de columnas coincidentes, y no es claro cmo se debera usar la notacin cuando hay dos o tres pares de columnas coincidentes. Aparecen otros problemas con la notacin de la reunin externa cuando la reunin se extiende a tres o ms tablas. Es fcil extender la nocin de una reunin externa a tres tablas:
TBLl OUTER-JOIN TBL2 OUTER-JOIN TBL3
ste es un conjunto de operaciones de la base de datos perfectamente legtimo de acuerdo con la teora de bases de datos relacionales. Pero el resultado depende del orden en que se realicen las operaciones de reunin externa. Los resultados de:
(TBLl OUTER-JOIN TBL2) OUTER-JOIN TBL3
sern, en gen~ral, diferentes de los resultados de:

TBLl OUTER-JOIN (TBL2 OUTER-JOIN TBL3)
damentalmente debido a su menor impacto en el lenguaje SQL ms que en su claridad o correccin. Frente a este escenario, el estndar SQL2 especific un nuevo mtodo para el soporte de las reuniones externas que no estaba basado en la notacin establecida de un producto SQL popular en concreto. La especificacin SQL2 puso eL soporte de las reuniones externas en la clusula FRM con una sintaxis elaborada que permite que el usuario especifique exactamente cmo se deben reunir las tablas fuente. El soporte de la reunin externa en el estndar SQL2 tiene dos ventajas distintas. Primera, el estndar SQL2 puede expresar incluso la ms compleja de las reuniones. Segunda, los productos de bases de datos existentes pueden soportar las extensiones de SQL2 a SQLl y mantener el soporte de su sintaxis propia para las reuniones externas sin conflictos. La base de datos relacional de IBM 082, por ejemplo, ha aadido soporte para la mayor parte de la sintaxis, aunque no toda, de la reunin de SQL2 en el momento de escribir este libro. Es razonable esperar que la mayora de las marcas principales de SOBD la incluirn, y que las caractersticas de la reunin en el estilo SQL2 sern parte de la corriente principal de SQL en los prximos aos. Las ventajas del soporte extendido de las reuniones en SQL2 tienen el costo de una complejidad aadida con respecto a lo que haba sido una de las partes ms simples del lenguaje SQL. De hecho, el soporte extendido de las reuniones es parte de una extensin mucho mayor de las capacidades de las consultas en SQL2, que aaden incluso ms capacidades y complejidad. Las otras caractersticas extendidas incluyen las operaciones de conjuntos sobre los resultados (unin, interseccin y diferencia de tablas) y expresiones de consulta mucho ms ricas que manipulan filas y tablas, y se permiten usar en subconsultas. Las capacidades extendidas relativas a las reuniones se describen en esta seccin. Las otras caractersticas extendidas se describen en el siguiente captulo, despus de la discusin de las subconsultas bsicas.
Al usar cualquiera de las notaciones de SQL Server o de Oraele es imposible especificar el orden de evaluacin de las reuniones externas. A causa de ello, los resultados producidos por la reunin externa de tres o ms tablas depende de los aspectos especficos de la implementacin del SOBD.
Reuniones internas en SOL2*

La Figura 7.13 muestra una forma simplificada de la sintaxis SQL2 extendida de la clusula FRQM. Es ms fcil entender todas las opciones proporcionadas considerando cada tipo de reunin una a una, comenzando con la reunin interna estndar y despus avanzando a lasdiferentes formas -de la reunin externa. La reunin interna estndar de las tablas CHICAS y CHICOS se pueden expresar en el lenguaje SQLl, como:
SELECT FROM CHICAS. CHICOS WHERE CHICAS.CIUDAD : CHICOS.CIUDAD
Reuniones y el estndar SOL2

Las reuniones externas plantearon un problema a los escritores del estndar SQL2. Dado que las reuniones externas son el nico camino para representar algunas consultas extremadamente tiles, fue importante que el estndar SQL2 incluyese soporte para las reuniones externas. Adems, las reuniones externas se incluyeron en muchos productos SQL comerciales y llegaron a seruna parte muy importante del lenguaje SQL. Sin embargo. los mtodos usados para representar las reuniones externas variaron ampliamente entre los diferentes productos SQL, como se muestra en las secciones anteriores. Adems. todos los mtodos usados para denotar reuniones externas en productos comerciales tenan deficiencias y se eligieron fun-
sta es todava una instruccin aceptable en SQL2. Los escritores del estndar SQL2 no podran realmente haberla hecho ilegal sin romper todos los millones de consultas multitabla que se haban escrito hasta comienzos de la dcada de 1990.
_1
170
Captulo 7: Consultas multitab/a (reuniones)
171
1-
_
FRDM
Pero el estndar SQL2 especifica una forma alternativa de expresar la misma consulta:
tabla
-.---,.espeCific8Cin-de. ~--------T---
...
5ELECT FROM CHICAS INNER JOIN CHICOS ON CHICAS. CIUDAD = CHICOS. CIUDAD
expresin-de-reunin-nawral-------l expresin-de-reunin----------j
expresin-de-prOduc"'~o-c~,:u~"~d~o======j
expresin-de-unin-
expresin-dtrreunin-narural
1-
tabla
1 NATURAL
-- , - - - - - - - - - - T - INNER FULL -
JOIN tabla
2---+-e
Ntese que las dos tablas a reunir estn conectadas explcitamente mediante una operacin JOIN, y la condicin de bsqueda que describe la reunin se especifica ahora en una clusula ON en la clusula FROM. La condicin de bsqueda que sigue a la palabra clave ON puede ser cualquier condicin de bsqueda que especifique el criterio usado para hacer corresponder las filas de las dos tablas reunidas. Las columnas referenciadas en la condicin de bsqueda deben venir slo de dos tablas reunidas. Por ejemplo: prtase de la hiptesis que las tablas CHICAS y CHICOS se hubieran ampliado con la columna EDAD. A continuacin se muestra una reunin que encaja pares chica/chico de la misma ciudad y que tambin requiere que el chico y la chica de cada pareja tengan la misma edad:
SELECT FROM CHICAS INNER JOIN CHICOS ON (CHICAS.CIUDAD = CHICOS. CIUDAD) ANO (CHICAS.EDAD = CHICOS. EDAD)
-==::;;===:;1
OUTER
LE'" RIGHT
expresin-dtrreunin
1-
tabla J-
'.,
INNER
FULL
---.JOIN fabla 2
--------j
aUTER
ON sends condition yo' T USING(column lisO
LE'"
RIGHT
En estas reuniones simples de dos tablas, todo el contenido de la clusula WHEse ha trasladado a la clusula ON, y sta no aade ninguna funcionalidad nueva al lenguaje SQL. Sin embargo, recurdese de este mismo captulo que en una reunin exterior que involucre tres o ms tablas, el orden en que suceden las reuniones afecta a los resultados de la consulta. La clusula QN proporciona un control detallado acerca de cmo se procesan estas reuniones multitabla, como se describe ms adelante en este captulo. El estndar SQL2 permite otra variacin en la reunin interna simple entre las tablas CHICAS y CHICOS. Dado que las columnas coincidentes de las dos tablas tienen los mismos nombres y se comparan segn su igualdad (que es el caso habitual), se puede usar una forma alternativa de la clusula ON especificando una lista de nombres de columnas coincidentes:
RE
expresin-de-producto cruzado
r-rabla
J-------
CROSS JOIN
_ _ _ _ tabla2 ........
SELECT FROM CHICAS INNER JO IN CHICOS USING (CIUDAD. EDAD)
expresin-da-unin
r--
tab /a 1 - - - - - - - CROSS JOIN
- - - - fabla
2-+e
Figura 7.13.
Clusula FROM extendida en el estndar SQL2.
La clusula USING especifica una lista separada por comas de los nombres de columnas coincidentes, que debe ser idntica en ambas tablas. Es completamente equivalente a la clusula ON que especifica explcitamente cada par de columnas coincidentes, pero es mucho ms compacta y, por tanto, fcil de entender. Por supuesto, si las columnas coincidentes tienen diferentes nombres en las tablas CHICAS Y CHICOS, hay que usar una clusula ON o WHERE con un test de igualdad. La clusula QN tambin se debe usar si la reunin no conlleva la igualdad de las columnas coincidentes. Por ejemplo, si se desea seleccionar los pares chica/chico en
172
Captulo 7: Consultas multitab/a (reuniones)
173
donde se requiere que la chica sea mayor que el chico, se debe usar una clusula QN para especificar la reunin:
SELECT FROM CHICAS INNER JOIN CHICOS ON (CHICAS. CIUDAD : CHICOS.CIUDAD ANO CHICAS.EDAD > CHICOS. EDAD)
o bien:
SELECT FROM CHICAS FULL OUTER JOIN CHICOS USING (CIUDAD)
Hay una variacin final de esta consulta simple que ilustra otra caracterstica de la clusula FRM de SQL2. Una reunin de dos tablas en la que las columnas coincidentes son exactamente las columnas especficas de las dos tablas que tienen nombres idnticos, se denomina reunin natural, porque usualmente sta es la forma ms natural de reunir las dos tablas. La consulta que selecciona pares de chica/chico que viven en la misma ciudad y tienen la misma edad se puede expresar como una reunin natural.usando esta consulta:
SELECT FROM CHICAS NATURAL INNER JO IN CHICOS
Como "'a palabra clave INNER es opcional en el lenguaje SQL2, el estndar SQL2 tambin permite omitir la palabra clave OUTER. La consulta anterior se podra haber escrito:
SELECT FROM CHICAS FULL JOIN CHICOS USING (CIUDAD)
El SGBD puede inferir de la palabra FULL que se requiere una reunin externa. Al especificar LEFT o RIGHT en lugar de FULL, el lenguaje SQL2 se -extiende de forma natural a las reuniones externas por la izquierda O por la derecha. A continuacin se muestra la reunin externa por la izquierda de la misma consulta:
SELECT PROM CHICAS LEFT OUTER JOIN CHICOS USING (CIUDAD)
Si se especifica la palabra clave NATURAL, no se pueden usar las clusulas ON y USING en la especificacin de la reunin, porque la reunin natural define especficamente la condicin de bsqueda a usar para reunir las tablas -se confrontan todas las columnas con nombres idnticos de columna en ambas tablas. El estndar SQL2 parte de que la reunin predeterminada de dos tablas es una reunin interna. Se puede omitir la palabra clave INNER de los ejemplos anteriores y la consulta resultante sigue siendo una instruccin SQL2 vlida con el mismo significado.
Como se describi anteriormente en este captulo, los resultados inciuirn pares chica/chico que no encajan y filas con valores NULL para cada fila que no encaje de la tabla CHICAS (la tabla izquierda de la reunin), ,pero los resultados no incluyen filas que no encajan de la tabla CHICOS. Anlogamente, la versin de la reunin externa por la derecha de la misma consulta, especificada como:
SELECT FROM CHICAS RIGHT OUTER JO IN CHICOS USING (CIUDAD)
Reuniones externas en SOL2*

El estndar SQL2 proporciona un soporte completo de las reuniones externas usando las mismas clusulas descritas en la seccin anterior para las reuniones internas y palabras clave adicionales. Por ejemplo, la reunin externa completa de las tablas CHICAS y CHICOS (sin las columnas EDAD) se genera con esta consulta:
SELECT FROM CHICAS FULL OUTER JOIN CHICOS ON CHICAS,CIUDAD = CHICOS,CIUDAD
incluye pares chico/chica y filas que no encajan de la tabla CHICOS (la tabla derecha de la reunin), pero no incluye las filas que no encajafl de la tabla CHICAS.
Reuniones cruzadas y reuniones de unin en SOL2*

El soporte en SQL2 de reuniones extendidas incluye otros dos mtodos para combinar datos de dos tablas. Una reunin cruzada es otro nombre del producto cartesiano de dos tablas, como se describi anteriormente en este captulo. Una reunin de unin est muy relacionada con la reunin externa completa; sus resultados son un subconjunto de los generados por la reunin externa completa. Aqu hay una consulta SQL2 que genera el producto completo de las tahlas
CHICAS y CHICOS: SELECT FROM CHICAS CROSS JOIN CHICOS
Como se explic anteriormente en este captulo, los resultados de la consulta contendrn una fila por cada par chica/chico que encaje, as como una fila por cada chico que no, con valores NULL en las columnas de la otra tabla sin encaje. SQL2 permite las mismas variaciones de las reuniones internas para las reuniones externas; la consulta tambin se podra haber escrito como:
SELECT FROM CHICAS NATURAL FULL OUTER JOIN CHICOS
lIII
174
saL. Manual de referencia
175
Por definicin, el producto cartesiano (a veces denominado producto cruzado. de ah el nombre CRDSS JOIN, reunin cruzada en ingls) contiene cada posible par de filas de las dos tablas. Multiplica las dos tablas convirtiendo las tablas de, por ejemplo, tres chicas y dos chicos en una tabla de seis (3x2 == 6) pares chica! chico. No hay columnas coincidentes o criterio de seleccin asociados con los productos cruzados, as que no se permiten las clusulas ON y USING. Ntese que la reunin cruzada realmente no aade ninguna nueva capacidad al lenguaje SQL. Se pueden generar exactamente los mismos resultados con una reunin interna que no especifica columnas coincidentes. As que la consulta anterior se puede escribir como:
SELECT FROM CHICAS, CHICOS
El uso de las palabras clave CROSS JO IN en la clusula FROM slo hace ms explcita la reunin cruzada. En la mayora de bases de datos, la reunin cruzada de dos tablas es por s misma de muy poco uso prctico. Su utilidad viene realmente como bloque constructor de expresiones de consulta ms complejas, que comienzan con el producto cruzado de dos tablas, y despus usa las capacidades de las consultas de resumen de SQL2 (descritas en el siguiente captulo) u operaciones de conjuntos de SQL2 para manipular ms los resultados. La reunin de unin en SQLZ combina algunas de las caractersticas de la operacin UNION (descrita en el captulo anterior) con algunas de las caractersticas de las operaciones de reunin descritas en este captulo. Recurdese que la operacin UNtaN combina las filas de dos tablas que deben tener el mismo nmero de columnas y los mismos tipos de datos para las columnas correspondientes. Esta consulta, que usa una operacin simple UNION:
SELECT FROM CHICAS UNION ALL
tabla. En este aspecto, la reunin de unin es corno todas las otras reuniones. Para cada fila de los resultados que vienen de la tabla CHICAS, las columnas que vienen de la tabla CHICAS reciben los valores de datos correspondientes; las otras columnas (las que vienen de la tabl.a CHICOS) tienen valores NULL. De forma similar, por cada fila de resultados que vIenen de la tabla CHICOS, las columnas que vienen de la tabla CHICOS reciben los valores de datos correspondientes; las otras columnas (en este caso las que vienen de la tabla CHICAS) tienen valores NULL. Otra forma de observar los resultados de la reunin de unin es compararlos con ]os resultados de una reunin externa completa de las tablas CHICAS y CHICOS. Los resultados de la reunin de unin incluyen filas con valores NULL de los datos de la tabla CHICAS y filas con valores NULL de los datos de la tabla CHICOS pero no incluyen ninguna de las filas generadas por las columnas coincidentes: Volviendo a la definicin de la reunin externa de la Figura 7.14, la reunin de unin se produce omitiendo el paso 1 y siguiendo el paso Z y el 3.
Reunin externa completa Reunin externa por la izquierda Reunin externa por la derecha
'\
"'"
Filas que encajan de TBLl con valores NULL para las columnas de TBL2 Pares de las filas coincidentes de TBLl/TBL2 Reunin interna Filas ~ue encajan de TBL2 con valores NULL para las columnas de TBLl
SELECT
FROM CHICOS
"Filas que no encajan de TBLl con valores NULL para las columnas de TBL2
cuando se aplica a una tabla de tres filas de chicas y de dos filas de chicos, da una tabla de cinco filas de resultados. Cada fila de los resultados corresponde a una fila de la tabla CHICAS o de la tabla CHICOS de la cual deriva. Los resultados tienen dos columnas, NOMBRE y CIUDAD, porque las tablas CHICAS y CHICOS tienen cada una estas dos columnas. La reunin de unin de las tablas CHICAS y CHICOS se especifica con esta consulta SQL2:
SELECT FROM CHICAS UNION JOIN CHICOS
Pares de las filas Que no encajan de TBLl/TBL2
Filas que no encajan de TBL2 con valores NULL para las columnas de TBLl
Reunin cruzada
Reunin de unin
/
\
y
1\
v .'
Todos los pares TBLlxTBL2 (m x n filas)
1\
Y'
TBLl con valores NULL
TBL2 con valores NULL
Los resultados tienen de nuevo cinco filas, y de nuevo cada fila de los resultados viene de exactamente una de las filas de la tabla CHICAS o de la tabla CHICOS. Pero a diferencia de la unin simple, estos resultados tienen cuatro columnas -todas las columnas de la primera tabla ms todas las columnas de la segunda
(mfitas)
(n filas)
Figura 7.14.
Relaciones entre los tipos de reunin en SQL2.
176
Capitulo 7: Consultas multitabla (reuniones)
177
Finalmente es til examinar la relacin entre los conjuntos de filas producidos por la reunin cruzada, los diferentes tipos de reuniones externas y la reunin interna mostrada en la Figura 7.14. Al reunir dos tablas, TBL1 con m filas y TBL2 con n filas, la figura muestra que:
La reunin cruzada contendr m x n fiJas. consistentes en todas los pares de filas de las dos tablas. TBL1 INNER JOIN TBL2 contendr algn nmero de filas, f. que es menor que m x n. La reunin interna es estrictamente un subconjunto de la reunin cruzada. Se forma eliminando las filas de la reunin cruzada que no satisfacen la condicin de la reunin interna. La reunin externa por la izquierda contiene todas las filas de la reunin interna ms cada fila que no encaje de TBL1, con valores NULL. La reunin externa por la derecha contiene todas las filas de la reunin interna ms cada fila que no encaje de TBL2, con valores NULL. La reunin externa completa contiene todas las filas de la reunin interna ms cada fila que no encaja de TBLl, con valores NULL, ms cada fila que no encaja de TBL2, con valores NULL. Grosso modo, sus resultados son iguales a la reunin externa por la izquierda ms la reunin externa por la derecha. La reunin de unin contiene todas las filas de TBLl, con valores NULL, ms todas las filas de TBL2, con valores NULL. Grosso modo, sus resultados son la reunin externa menos la reunin interna.
tener slo una de estas filas o ninguna si no hay datos sobre los progenitores del vstago. Las tablas CHICAS, CHICOS Y PROGENITORES proporcionan un rico conjunto de datos para algunos ejemplos de reuniones multitabla. Por ejemplo, supngase que se desea confeccionar una lista de todas las chicas junto con los nombres de sus madres y los chicos que viven en la misma ciudad. A continuacin se muestra una consulta que produce la lista:
SELECT FROM ON JOIN ON WHERE CHICAS.NOMBRE, NOMBREPRO, CHICOS.NOMBRE ((CHICAS JOIN PROGENITORES PROGENITOR. VSTAGO : NOMBRE) CHICOS (CHICAS.CIUDAD : CHICOS.CIUDAD TIPO : -MADRE"
Dado que ambas reuniones son internas, cualquier chica que no tenga algn chico que viva en la misma ciudad o que no tenga a su madre definida en la base de datos no se mostrar en los resultados de la consulta. ste puede ser el resultado deseado o no. Para incluir las chicas sin una madre que encaje en la base de datos, se debera cambiar la reunin entre las tablas CHICAS y PROGENITORES en una reunin externa por la izquierda, como sta:
SELECT FROM ON JO IN ON WHERE CHICAS. NOMBRE, NOMBRE PRO , CHICOS.NOMBRE {(CHICAS LEFT JO IN PROGENITORES PROGENITORES. VSTAGO = NOMBRE) CHICOS (CHICAS.CIUDAD : CHICOS.CIUDAD)) (TIPO: "MADRE") OR (TIPO IS NULL)
Reuniones multitabla en SOL2

Una ventaja importante de la notacin SQL2 es que pennite una .especificacin muy clara de las reuniones de tres o cuatro tablas. Para construir estas reuniones ms complejas, cualquiera de las expresioes de reunin mostradas en la Figura 7.1~ y descritas en las anteriores secciones se pueden encerrar entre parntesis. La expresin de reunin resultante se puede usar por sr mima en otra expresin de reunin, como si fuese una simple tabla. As como SQL permite combinar opera ciones matemticas (+, -, * y !) con parntesis y construir expresiones ms complejas, el estndar SQL2. permite construir expresiones de reunin ms complejas del mismo modo. Para ilustrar las reuniones multitabla asmase que se ha aadido una nueva tabla PROGENITORES a la base de datos que contiene las tablas CHICAS y CHICOS del ejemplo que se ha estado usando. La ta~la PROGENITORES tiene tres columnas:
VSTAGO
Esta consulta incluir todos los pares chica/chico, independientemente de que las chicas tengan a su madre definida en la base de datos, pero se seguirn omitiendo las chicas que no vivan en la misma ciudad que algn chico. Para incluir tam bin a estas chicas, la segunda reunin tambin se debe convertir en una reunin externa por la izquierda:
SELECT FROM ON LEFT ON WHERE CHICAS.NOMBRE, NOMBREPRO, CHICOS.NOMBRE {(CHICAS LEFT JO IN PROGENITORES PROGENITORES. VSTAGO = NOMBRE) JOIN CHICOS (CHICAS.CIUDAD : CHICOS.CIUDAD (TIPO: "MADRE") OR {TIPO IS NULLI
Coincide con la columna NOMBRE de las tablas TIPO Especifica PADRE o MADRE Nombre de pila del progenitor NOMBREPRO
CHICAS
y CHICOS
Ntese que la extensin con valores NULL de las filas de la tabla CHICAS de la reunin externa con sus madres tambin crea alguna complicacin adicional en la clusula WHERE. Las chicas sin madres coincidentes generarn filas no slo con el nombre de la madre con valor NULL (NOMBREPRO), sino tambin un valor NULL en la columna TIPO. El criterio simple de seleccin:
WHERE (TIPO: -MADRE")
Cada fila de las tablas CHICAS y CHICOS puede tener dos filas coincidentes en la tabla PROGENITORES, una especificando una MADRE y otra un PADRE, o puede
178
Captulo 7: Consultas mu/titabla (reuniones)
179
generara un resultado desconocido para estas filas y no se incluiran en los resultados. i Pero la razn de usar la reunin externa por la izquierda fue asegurarse de que se incluyesen! Para resolver este problema la clusula WHERE se expande para comprobar tambin las filas en las que el tipo de progenitor es NUL~. Como ejemplo final supngase que se desea generar de nuevo un listado de chicas/chicos, pero en este caso se desea incluir en los resultados el nombre del padre del chico y de la madre de la chica. Esta consulta requiere una reunin de cuatTo tablas (CHICOS. CHICAS Y dos copias de la tabla PROGENITORES, una para reunir con la informacin de los chicos los nombres de los padres, y otra para reunir la informacin de las chicas para obtener los nombres de sus madres). De nuevo, el potencial de las filas sin encaje en las reuniones significa que hay varias posibles respuestas correctas a la consulta. Supngase, como antes, que se desease incluir todas las chicas y chicos en los pares chica/chico, incluso si el chico o chica no tiene una fila coincidente en la tabla PROGENITORES. Es necesario usar reuniones externas para las partes (CHICOS reunin PROGENITORES) y (CHICAS reunin PROGENITORES) de la consqlta, pero una reunin interna para la parte (CHICOS reunin CHICAS) de la consulta. Esta consulta SQL2 da los resultados deseados:
SELECT CHICAS.NOMBRE, MADRES.NOMBREPRO, CHICOS.NOMBRE, PADRES.NOMBREPRO FROM ({CHICAS LEFT JOIN PROGENITORES AS MADRES ON ({VSTAGO = CHICAS.NOMBRE) ANO (TIPO = -MADRE"))) JO IN (CHICOS LEFT JOIN PROGENITORES AS PADRES ON ((VSTAGO = CHICOS.NOMBRE) ANO (TIPO = "PADRE")))) USING (CIUDAD)
reunin en la que aparecen. Cuando se completa el procesamiento de la clusula seleccin en la clubsqueda que se aplica a reuniones especficas; la clusula WHERE especifica el criterio de bsqueda que se aplica a la tabla complela resultado de estas reuniones.
FROM, la tabla resultado se usa para aplicar el criterio de sula WHERE. Por tanto, la clusula ON especifica el criterio de
Resumen
En este captulo se ha descrito la forma en que SQL maneja las consultas que combinan datos de dos o ms tablas: En una consulta multitabla (una reunin), las tablas que contienen los datos se listan en la clusula FROM. Cada fila de resultados es una combinacin de datos de una nica fila de cada tabla y es la nica fila que obtiene sus datos de una combinacin particular. Las consultas multitabla ms comunes usan la relacin padre/hijo creada por las claves primarias y las claves externas. En general, las reunin se puede construir comparando cualquier par de columnas de las dos tablas reunidas, usando un test de igualdad o cualquier otro test de comparacin. Se puede pensar que una reunin es el producto de dos tablas de las que se han eliminado algunas de las filas. Una tabla se puede reunir consigo misma; las autorreuniones requieren el uso de alias de tabla. Las reuniones externas extienden la reunin (interna) estndar conservando las filas que no encajan de una tabla o de ambas reunidas en los resultados y usando valores NULL para los datos de la otra tabla. El estndar SQL2 proporciona un soporte completo para las reuniones internas y externas, y para la combinacin de resultados de reuniones con otras operaciones multitabla, como las uniones, intersecciones y diferencias.
Esta consulta resuelve el problema del test de la clusula WHERE de forma diferente -trasladando el test sobre el TIPO de progenitor a la clusula ON de la especificacin de la reunin. De este modo, el test para el TIPO apropiado de progenitor se realizar cuando el SGBD encuentre columnas coincidentes para construir la reunin, antes de que se aadan las filas con valores NULL a los resultados de la reunin externa. Dado que la tabla PROGENITORES se usa dos veces en la clusula FRDM, con dos papeles diferentes, es necesario dar dos alias de tabla diferentes para especificar correctamente los nombres en la lista de seleccin. Como muestra este ejemplo, incluso una consulta de cuatro reuniones como sta puede llegar a ser bastante compleja usando la sintaxis de SQL2. Sin embargo, a pesar de la complejidad, la consulta SQL2 especifica de forma precisa la consulta que debe resolver el SGBD. No hay ambigedad acerca del orden en que se renen las tablas, o sobre cules son las reuniones internas o externas. En resumen, la capacidad aadida compensa la complejidad introducida por la clusula FROM de SQL2. Aunque ninguno de los ejemplos de las consultas incluidos en esta seccin tengan clusulas WHERE u ORDER BY, se pueden usar libremente con la clusula FROM extendida en SQL2. La relacin entre las clusulas es simple y permanece como se describi antes en este captulo. El procesamiento especificado en una clusula USING u DN se aplica como parte de una especificacin particular de la
'i
CAPTULO
Consultas de resumen
Muchas solicitudes de informacin no requieren el grado de detalle proporcionado por las consultas SQL descritas en los dos ltimos captulos. Por ejemplo, cada una de las siguientes solicitudes piden un nico valor o un pequeo nmero de valores que resumen los contenidos de la base de datos: Cul es la cuota total de todos los representantes? Cules son la mayor y menor cuotas asignadas? Cuntos representantes exceden su cuota? Cul es el importe de un pedido medio? Cul es el importe del pedido medio de cada oficina de ventas? Cuntos representantes estn asignados a cada oficina .de ventas?
SQL alberga estas solicitudes de datos ~e resumen mediante funciones de columna y las clusulas GROUP BY y HAVING de la instruccin SELECT, que se describen en este captulo.
Funciones de columna
SQL permite resumir los datos de la base de datos mediante un conjunto de funciones de columna. Una funcin de columna de SQL toma una columna de datos completa como argumento y produce un nico elemento de datos que resume la columna. Por ejemplo, la funcin de columna AVG () toma una columna de datos y calcula su media. A continuacin se muestra una consulta que usa la funcin de columna AVG () para calcular el valor medio de dos columnas de la tabla REPRESENTANTES:
Cul es la cuota media y las ve1llas medias de nuestros represemantes?

SELECT AVG(CUOTA), AVG(VENTAS) FROM REPRESENTANTES
AVG(CUOTA) AVG(VENTAS)
300.000,OO 289.353,20
181

182
Captulo 8: Consultas de resumen
183
I
I
1,"
1"
La Figura 8. J muestra grficamente cmo se producen los resultados de la consulta. La primera funcjn de columna de la consulta tomas los valores de la columna CUOTA y calcula su media; la segunda calcula la media de los valores de la columna VENTAS. La consulta produce una nica fila de resultados que resume los datos de la tabla REPRESENTANTES. SQL ofrece seis funciones de columna diferentes, como se muestra en la Figura 8.2. Las funciones de columna ofrecen seis clases diferentes de datos de resumen: calcula el total de una columna. calcula el valor medio de una columna. .MIN() halla el menor valor de una columna. MAX () halla el mayor valor de una columna. COUNT () cuenta el nmero de valores de una columna. COUNT ( *) cuenta las filas de los resultados.
SUM () AVG ()
SOt1.
(LEXpresin---------. J
DISTINCT
Nombre-de-columna-l
I---AVG
(-r Expresin
LDISTINCT
Nombre-de-COlumna"J)
1--- MIN
(Expresin)J------------------.I
i,
1--- MAX
COUNT
{Expresin)I-----------.:---.:------->!
(T
DISTINCT
3- Nombre-de-columna
El argumento de una funcin de columna puede ser simplemente un nombre de columna, corno en el ejemplo anterior, o puede ser una expresin SQL, como se muestra a continuacin:
COUNT
('J
-----------------..1
Cul es el rendimiento medio de la cuota de nuestros representantes?
Figura 8.2.
Diagrama sintctico de las funciones de columna.
NUM EMPLE NOMBRE
JEFE
I l'
I
l' ,!
r!
1
105 109 102 106 104 101 110 108 103 107
Bruno Arteaga Mara Jimnez Susana Santos Samuel Clavel Bernardo Snchez Daniel Ruidrobo Toms Saz Len Freire Pablo Cruz Neus Azcrate
104 106 108 NULL 106 104 101 106 104 108
CUOTA 350.000,00 300.000,00 350.000,00 27S.000,00 200.000,00 300.000,00 NULL 3S0.000,OO 27S.000,OO 300.000,00
VENTAS 367.91l,00 392.72S,00 474.0S0,00 299.912,00 142.594,00 305.673,00 75.985,00 361. 86S, OO 286.775,00 186.042,00
SELECT AVG(100 * (VENTAS/CUOTA)) FROM REPRESENTANTES AVG{100*(VENTAS/CUOTA) ) 102,60
Para procesar esta consulta, SQL construye una columna temporal que contiene el valor de la expresin {lOO * (VENTAS/CUOTA}) para cada fila de la tabla REPRESENTANTES y despus calcula las medias de la columna temporal.
Clculo del total de una columna
(SUM)
I l'
1',
300.000,OO
298.253,20
La funcin de columna SUM () calcula la suma de los valores de datos de una columna. Los datos de la columna deben tener un tipo numrico (entero, decimal, coma flotante o moneda). El resultado de la funcin SUM () tiene el mismo tipo de datos bsico que los datos de la columna, pero el resultado puede tener mayor precisin. Por ejemplo, si se aplica la funcin SUM () a una columna de enteros de 16 bits, se puede producir un entero de 32 bits como resultado. A continuacin se muestran varios ejemplos que usan la funcin de columna
SUM{}:
Figura 8.1.
Operacin de una consulta de resumen.
184
185
Cules son las cuotas y ventas tolales de lOdos los representantes?

SELECT SUM(CUOTA). SUM(VENTAS) FROM REPRESENTANTES
SUM{CUOTA)
Bsqueda de valores extremos
(MIN
MAX)
SUM(VENTAS)
2.700.000,00 2.893.532.00
Cul es el 10tal de los pedidos de Bruno Arteaga?

SELECT SUM(IMPORTE) FROM PEDIDOS, REPRESENTANTES WHERE NOMBRE = 'Bruno Arteaga' AND REP = NUM_EMPL SUM(IMPORTE)
Las funciones de columna MIN () y MAX () hallan respectivamente los valores menor y mayor de una columna. Los datos de la columna pueden contener informacin numrica, de cadena o de fecha y hora. El resultado de la funcin MIN () O MAX () tiene exactamente el mismo tipo de datos que los datos de la columna. A continuacin hay algunos ejemplos que muestran el uso de estas funciones de columna: Cules
SO"
las cuotas mayor y menor asignadas?
ij
I
I
I n
SELECT MIN(CUOTA) , MAX(CUOTA) FROM REPRESENTANTES HIN/CUOTA) HAX(CUOTA)
39.327,OO
200.000,00 350.000,OO
Clculo de la media de una columna
(AVG)
Cul es la fecha ms antigua de

SELECT MIN(FECHA_PEDIDO) FROM PEDIDOS MIN(FECHA_PEDIDO) 04-ENE-S9
UIl
pedido en la base de datos?
La funcin de columna AVG () calcula la media de una columna. Como con la funcin SUM ( ) los datos de la columna deben tener un tipo numrico. Dado que la funcin AVG () suma los valores de la columna y despus lo divide por el nmero de valores, su resultado puede tener un tipo de datos diferente del de los valores de la columna. Por ejemplo, si se aplica la funcin AVG () a una columna de enteros, el resultado puede ser un nmero decimal o en coma flotante. dependiendo del SGBD que se est usando. A continuacin se muestran algunos ejemplos de la funcin de columna AVG (): Calcular el precio medio de los productos del fabricante AC/.
SELECT AVG(PRECIO) FROM PRODUCTOS WHERE ID_FAS = 'ACI' AVG(PRECIO) S04,29
Cul es el mejor rendimiento en ventas de los representantes?

SELECT MAX(lOO (VENTAS/CUOTA)) FROM REPRESENTANTES MAX(100*IVENTAS!CUOTA)) 135,44
Calcular el importe medio de los pedidos de Acme (nmero de cliente 21.03).

SELECT AVG(IMPORTE) FROM PEDIDOS WHERE CLIENTE = 2103 AVG(IMPORTE) 8.895,50
Cuando las funciones de columna MIN () Y MAX () se aplican a datos numricos, SQL compara los nmero en orden algebraico (los nmeros grandes negativos son menores que los nmeros pequeos negativos, que son menores que cero, el cual es a su vez menor que todos los nmeros positivos). Las fechas se comparan secuencialmente (las fechas anteriores son menores que las posteriores). Al usar HIN () Y MAX () con datos de cadena. la comparacin de dos cadenas depende del conjunto de caracteres que se use. En una computadora personal o minicomputadora, ambas usan el conjunto de caracteres ASCII, los dgitos vienen antes que las letras en la secuencia de ordenacin, y todos los caracteres en mayscula vienen antes de los caracteres en minscula. En los grandes sistemas (mainframe) de IBM, que usan el conjunto de caracteres EBCDIC, los caracteres en minscula preceden a los caracteres en mayscula. y los dgitos vienen des-
186
187
pus de las letras. A continuacin se muestra una comparacin de las secuencias de ordenacin de ASCII y EBCDIC de una lista de cadenas, de las menores a las mayores:
ASCII
1234ABC
Cuntos representantes exceden su cuota?

SELECT COUNT(NOMBRE} FROM REPRESENTANTES WHERE VENTAS > CUOTA COUNT(NOMBRE}
7
EBCDIC
acme mfg.
5678ABC
ACME MFG. Acrne Mfg.
zet.a carpo
Acme Mfg.
ACME MFG.
ZETA Zeta acme zeta
CQRP. Carpo mEg. carpo
Zeta Carpo
ZETA CORP.
Cuntos pedidos de ms de 25.000- estn registrados?

SELECT COUNT(IMPORTE) FROM PEDIDOS WHERE IMPORTE> 25000.00 COUNT (IMPORTE)
4
1234ABC
5678ABC
La diferencia en las secuencias de ordenacin significa que una consulta con una clusula ORDER BY puede producir diferentes resultados en dos sistemas diferentes. Los caracteres internacionales plantean problemas adicionales (por ejemplo,
los caracteres acentuados en francs, alemn, espaol, italiano, o las letras del alfabeto cirlico usados en griego y ruso, O los smbolos kanji usados en japons). Algunas marcas de SOBD usan algoritmos de ordenacin internacional especiales para ordenar estos caracteres en su posicin correcta en cada lenguaje. Otros simplemente los ordenan de acuerdo con el valor numrico del cdigo asignado al carcter. Para manejar estos aspectos, el estndar SQL2 incluye un soporte elaborado para los conjuntos de caracteres nacionales, conjuntos de caracteres definidos por el usuario y secuencias de ordenacin alternativas. Desafortunadamente, el soporte de estas caractersticas de SQL2 vara ampliamente entre diferentes productos SGBD populares. Si una aplicacin maneja texto internacional se debe experimentar con el SGBD particular para determinar cmo s-e manejan estos caracteres. .
Ntese que la funcin COUNT () ignora los valores de Jos elementos de datos de la columna; simplemente cuenta cuntos elementos de datos hay. Como resultado, no importa realmente la columna que se especifique como argumento de la funcin COUNT ( ). El ltimo ejemplo se podra haber escrito simplemente como:
SELECT COUNT (NUM_PEDIDO) FROM PEDIDOS WHERE IMPORTE> 25000.00
Recuento de valores de datos
(COUNT)
La funcin de columna COUNT () cuenta el nmero de valores de datos de una columna. Los datos de la columna pueden ser de cualquier tipo. La funcin COUNT ( ) siempre devuelve un entero, independientemente del tipo de datos de la columna. A continuacin se muestran varios ejemplos de consultas que usan la funcin de columna COUNT ( 1:
Cuntos clientes hay?
SELECT COUNT(NUM_CLI) FROlo1 CLIENTES
De hecho, es difcil pensar en la consulta como contar los importes de pedidos o contar los nmeros de pedido; es mucho ms fcil pensar cmo contar los pedidos. Por esta razn, SQL alberga una funcin de columna especial, CQUNT (* ) , que cuenta filas en lugar de valores de datos. A continuacin se muestra la misma consulta, reescrita de nuevo esta vez con la funcin COUNT (*) :
SELECT COUNT(*) FROM PEDIDOS WHERE IMPORTE> 25000.00 COUNT(*)
4
21
Si se piensa en la funcin COUNT (*) como una funcin de recuento de filas, esto hace que la consulta sea ms fcil de leer. En la prctica, la funcin COUNT ( * ) se usa casi siempre en lugar de la funcin CQUNT () para contar filas.
188
']
SELECT AVG ! IMPORTE) , SOM!IHPORTE), (100 ' (100 ' AVG(IMPORTE/CUOTA)) PROM PEDIDOS, CLIENTES, REPRESENTANTES WHERE CLIENTE = NUH_CLI ANO REP NUH_EHPL

AVG(IHPORTE/LIHITE_CREOITO)),
il89
Funciones de columna en la lista de seleccin

Las consultas simples con una funcin de columna en su lista de seleccin son muy fciles de comprender. Sin embargo. cuando la lista de seleccin incluye varias funciones de columna, o cuando el argumento de una funcin de columna es una expresin compleja, la consulta puede ser difcil de l~er y comprender. Los siguientes pasos muestran las reglas del procesamiento de consultas SQL expandido una vez ms para describir cmo se manejan las funciones de columna. Como antes, las reglas estn pensadas para proporcionar una d.efinicin precisa de lo que significa una consulta, no una descripcin de cmo resuelve realmente el SGBD los resultados de la consulta. Para generar los resultados de una consulta de una instruccin SELECT: l. Si la instruccin es la UNION de instrucciones SELECT, aplicar los pasos del 2 al 5 a cada una de las instrucciones para generar sus resultados individuales. 2. Formar el producto de las tablas listadas en la clusula FROM. Si la clusula FRQM lista una nica tabla, el producto es esta tabla. 3. Si hay una clusula WHERE, aplicar su condicin de bsqueda a cada fila de la tabla producto, conservando las filas para las que la condicin de bsqueda es TRUE (y descartando aquellas para las que la condicin es FALSE o NULL). 4. Para cada fila restante, calcular el valor de cada elemento de la lista de seleccin para producir una nica fila de resultados. Para una referencia a columna simple, usar el valor de la columna en la fila en curso. Para una funcin de columna, usar el conjunto completo de filas como argumento. 5. Si se especifica SELECT DISTINCT. eliminar cualquier fila duplicada que se haya producido en el resultado. 6. Si la instruccin es una UNION de instrucciones SELECT, mezclar los resultados de la consulta de las instrucciones individuales en una nica tabla de resultados. Eliminar las filas duplicadas a menos que se especifique UNION
ALL.
AVG (IMPORTE) SUM (IMPORTE) (100' AVG (IMPORTE/LIMITE_CREOITO)) 8.256.37 247.69l.00 24,4:>
(lOO'AVa (IMPORTE/CUOTA) )
2,51
Sin las funciones de columna, sera:

SELECT IMPORTE, IMPORTE, IMPORTE/LIMITE_CREDITO, FROM PEDIDOS, CLIENTES, REPRESENTANTES WHERE CLIENTE = NUM_CLI AND AND REP = NUM_EMPL IMPORTE/CUOTA
y producira una fila de resultados detallados para cada.pedido. Las funciones de columna usan las columnas de esta tabla de resultados detallados para generar una tabla de una nica fila de resultados de resumen. Una funcin de columna puede aparecer en la lista de seleccin en cualquier lugar en que pueda aparecer un nombre de columna. Por ejemplo, puede ser parte de una expresin que sume o reste los valores de dos funciones de columna. Sin embargo, el argumento de una funcin de columna no puede contener otra funcin de columna, porque la expresin resultante no tiene sentido. Esta regla se conoce a veces como es ilegal anidar las funciones de columna. Tambin es ilegal mezclar funciones de columna y nombres de columnas normales en una lista de seleccin, de nuevo porque la consulta resultante no tendra sentido. Por ejemplo, considrese esta consulta:
SELECT NOMBRE, SUH(VENTAS) FROM REPRESENTANTES
7. Si hay una clusula se especifique.
ORDER BY,
ordenar los resultados de la consulta como
Las filas generadas por este procedimiento forman los resultados de la consulta. Una de las mejores formas de pensar en las consultas de resumen y en las funciones de columnas es imaginar el procesamiento de consultas dividido en dos pasos. Primero habra que imaginar cmo funcionara la consulta sin las funciones de columna, produciendo muchas filas de resultados detallados. Despus habra que imaginar a SQL aplicando las funciones de columna sobre los resultados detallados. produciendo una nica fila de resumen. Por ejemplo, considrese la siguiente consulta compleja:
Hallar el importe medio de los pedidos. ellolal de los importes, la media de los impories de los pedidos como un porcenlaje dellmile de crdilo del cliente, y el imporle medio de los pedidos como un porcemaje de la cuota del represemallle.
El primer elemento de seleccin pide a SQL que genere una tabla de diez filas de resultados detallados -una fila por cada representante-. El segundo elemento pide a SQL que genere una columna de una fila de resultados de resumen que contenga el total de la columna VENTAS. Los dos elementos SELECT se contradicen entre s, produciendo un error. Por esta razn, o todas las referencias a columna de la lista de seleccin aparecen en el argumento de una funcin de columna (produciendo una consulta de resumen), o la lista de seleccin no contiene ninguna funcin de columna (produciendo una consulta detallada). Realmente. la regla es un poco ms compleja cuando se consideran las consultas agrupadas y las subconsultas. Los refinamientos necesarios se describen ms adelante en la seccin Condiciones de bsqueda de grupos.
Valores
NULL
Y funciones de columna
Las funciones de columna SUM (), AVG (), MIN (), MAX () Y COUNT () toman cada columna de valores de datos como argumento y producen un nico valor de datos
190
191
como resultado. Qu ocurre si uno o ms de los valores de datos de la columna es un valor NULL? El estndar SQL de ANSI/ISO especifica que los valores NULL de la columna se ignoran por las funciones de columna.
Esta consulta muestra cmo la funcin COUNT () ignora los valores NULL de una columna:
SELECT COUNT{*), COUNT(VENTAS) , COUNT(CUOTA) FROM REPRESENTANTES
COUNT(*) COUNT(VENTAS} COUNT(CUOTA)
9
tiene un valor del argumento distinto de NULL slo para nueve de los diez representantes. En la fila con un valor NULL de la cuota, la resta produce un valor NULL, que se ignora en la funcin SUM ( ) . Por tanto, las ventas del representante sin cuota, que se incluyen en el clculo anterior, se excluyen en este clculo. Cul es la respuesta correcta? Las dos! La primera expresin calcula exactamente lo que dice: la suma de VENTAS, menos la suma de CUOTA. La segunda expresin tambin calcula exactamente 10 que dice: la suma de (VENTAS-CUOTA)>>. Sin embargo, cuando aparecen valores NULL, los dos clculos no son el mismo. El estndar ANSI/ISO especifica estas reglas precisas para el manejo de valores NULL en las funciones de columna: Si alguno de los valores de datos de una columna es NULL, se ignora para el propsito del clculo del valor de una funcin de columna. Si cada elemento de datos de la columna es NULL, entonces SUM (), AVG (), MIN () y MAX () devuelven un valor NULL; la funcin COUNT () devuelve el valor cero. Si no hay elementos de datos en la columna (es decir, la columna est vaca). entonces las funciones de columna SUM (1, AVG (), MIN () Y MAX () devuelven el valor NULL; la funcin COUNT () devuelve el valor cero. COUNT (") cuenta fiJas y no depende de la presencia o ausencia de valores NULL en la columna. Si no hay filas, devuelve el valor cero. Aunque el estndar es muy claro en esta rea, los productos comerciales SQL pueden producir resultados diferentes del estndar, especialmente si todos los valores de datos de una columna son NULL o cuando una funcin de columna se aplica a una tabla vaca. Antes de asumir el comportamiento especificado por el estndar se debera contrastar con el SGBD que se use.
10
10
REPRESENTANTES
contiene diez filas, as que COUNT (* devuelve un recuento de diez. La columna VENTAS contiene diez valores que no son NULL, as que la funcin COUNT (VENTAS) tambin devuelve un recuento de diez. La columna CUOTA es NULL para el ltimo representante contratado. La funcin COUNT (CUOTA) ignora este valor NULL y devuelve un recuento de nueve. A causa de estas anomalas, la funcin COUNT (*) se usa casi siempre en Jugar de COUNT ( ) , a menos que se desee excluir explcitamente los valores NULL de una columna particular del total. Ignorar Jos valores NULL tiene poco impacto en las funciones de columna MIN ( ) y MAX ( ) . Sin embargo, puede causar problemas sutiles en las funciones de columna SUM () y AVG (), como se ilustra en esta consulta:
SELECT SUM (VENTAS 1 , SUM(CUOTA), FROM REPRESENTANTES SUM(VENTAs) sUM(CUOTA} 2.893.532,OO 2.700.000,OO (SUM!VENTAS) SUM(CUOTA)), SUM(VENTAs-CUOTA)
La tabla
(SUM(VENTAS)-SUM(CUOTA)) 193.532,OO
sUM(VENTAS-CUOTA) 117.547,OO
Se esperara que las dos expresiones:

(SUM(VENTAS) SUM(CUOTA)) y SUM{VENTAS-CUOTA)
Eliminacin de filas duplicadas
(DISTINCT)
de la lista de seleccin produjesen resultados idnticos, pero el ejemplo muestra que no lo hacen. El representante con un valor NULL en la columna CUOTA es de nuevo la razn. La expresin:
sUM(VENTAS
resume el total de ventas de los diez representantes, mientras que la expresin:

SUH(CUOTA)
Recurdese del Captulo 6 que se puede especificar la palabra clave DISTINCT al principio de la lista de seleccin para eliminar filas duplicadas de resultados. Tambin se puede pedir a SQL que elimine valores duplicados de una columna antes de aplicarle una funcin de columna. Para eliminar valores duplicados, se incluye la palabra clave DISTINCT antes del argumento de la funcin de columna, inmediatamente despus del parntesis de apertura. A continuacin se muestran dos consultas que ilustran la eliminacin de filas duplicadas en las funciones de columna: Cuntos puestos diferentes tienen los representantes?
SELECT COUNT{DISTINCT PUESTO} FROM REPRESENTANTES COUNT{DISTINCT PUESTO)
3
resume el tata] de ventas de slo los nueve valores de cuota que no son NULL. La expresin:
SUM(VENTAS) SUM(CUOTA)
calcula la diferencia de estas dos cantidades. Sin embargo, la funcin de columna: SUM(VENTAS-CUOTA)
192

Cul es el importe medio de los pedidos de cada representante?
SELECT REP, AVG(IMPORTE) FROM PEDIDOS GRQUP BY REP REP AVG(IMPORTE)
101 8.876,00 1025.694,OO 103 1.350,OO 105 7.865,40 106 16.479,OO 107 11.477,33 108 8.376,14 109 3.552,50 110 1l.566,OO
193
Cuntas oficinas de ventas tienen representalltes que superen sus cuolas?

5ELECT COUNT(DISTINCT OFICINA_REPI FROM REPRESENTANTES WHERE VENTAS > CUOTA
COUNT(DISTINCT OFICINA_REP)
4
El estndar SQLl especifica que cuando se use la palabra clave DISTINCT, el argumento de la funcin de columna debe ser un nombre simple de columna; no puede ser una expresin. El estndar permite la palabra clave DISTINCT en las funciones de columna SUM () y AVG (). El estndar no permite el uso de la palabra clave DISTINCT en las funciones de columna HIN () y MAX () porque no tiene impacto en sus resultados. pero algunas implementaciones lo permiten de lodas formas. El estndar tambin requiere la palabra clave DIST1NCT en la funci6n de columna, pero muchas implementaciones de SQL permiten el uso de la funci6n COUNT () sin ella. D18T1NCT no se puede especificar en la funcin COUNT (1<) porque no trata en absoluto con una columna de valores de datos simplemente cuenta filas. El estndar SQL2 relaja estas restricciones, permitiendo que D18T1NCT se aplica en cualquiera de las funciones de columna y permitiendo expresiones como argumentos de cualquiera de las funciones. Adems, la palabra clave D1ST1NCT se puede especificar slo una vez en una consulta. Si aparece en el argumento de una funcin de columna, no puede aparecer en ninguno otro. Si se especifica antes de la lista de seleccin, no puede aparecer en ninguna de las funciones de columna. La nica excepcin es que D1STINCT se puede especificar una segunda vez dentro de una subconsulta (contenida dentro de la consulta). Las subconsultas se describen en el Captulo 9.
w
La primera consulta es una simple consulta de resumen, como en los ejemplos anteriores de este captulo. La segunda consulta produce varias filas de resumen una fila por cada grupo, resumiendo los pedidos de cada representante. La Figura 8.3 muestra cmo funciona la segunda consulta. Conceptualmente, SQL resuelve la consulta como sigue:
1. SQL divide los pedidos en grupos. con un grupo por cada representante.
Dentro de cada grupo, todos los pedidos tienen el mismo valor en la columna REP.
Tabla PEDIDOS
Consultas de agrupacin (clusula
GROUP BY)
I ilDlil Al,iKUPIUlA
Las consultas de resumen descritas hasta el momento son como los totales en el pie de un infonne. Condensan todos los datos detallados del infonne en una nica fila de datos de resumen. Como los subtotales son tiles en los informes impresos, es conveniente a menudo resumir los resultados en un nivel subtotal. La clusula GROUP BY de la instruccin SELECT proporciona esta capacidad. La funcin de la clusula GROUP BY se comprende ms fcilmente mediante un ejemplo. Considrense estas dos consultas:
NUM. PEDIOO
RE'
IMPORTE
,.r:k
'"
Figura 8.3.
112961 112989 112975 113057
'>
>,>
<
lO' lO' lO' lO'
( ) 31.500,00 1.458,00 2.100.00 600.00E
M.; "".
I
f-i
10.
~~~o;;~;;'RT"
106 16.479,00 106 1.350,OO
\~
108
Cul es el importe medio de los pedidos?

SELECT AVG(IMPORTE) FROM PEDIDOS AVG(IMPORTE)
8.256,37
113051 113045 113013 113024 113007 112992 113049
I~ ~~: I ~
108 108 108 108
1.420,OO 45.000.00 652,OO 7.100,OOE 2.925,OOE 750.00E 775,OOE
8.376.00
Funcionamiento de una consulta de agrupacin.
194

3 1 2 2
Captulo 8: Consultas de resumen clientes clientes clientes clientes del del del del representante representante representante representante 103 lO' 105 106
195
2. Para cada grupo, SQL calcula el valor medio de la columna IMPORTE para todas las filas del grupo, y genera una nica fila resumen de. resultados. ~ fila contiene el valor de la columna REP para el grupo y el Impone medio de los pedidos calculado.
Una consulta que incluya una clusula GROUP BY se denomina consulta de agrupacin porque agrupa los datos de sus .tablas fuente e? una nica fila de resume." por cada grupo de filas. Las columnas listadas en la clausula ,GROUP BY se de.n?mlnan columnas de agrupacin de la consulta, porque determman cmo se dVlden las filas en grupos. A continuacin se muestran ejemplos adicionales de consultas de agrupacin:
Cul es el rango de las cuotas asignadas en cada oficina?

SELECT OFICINA_REP, MIN(CUOTA), FROM REPRESENTANTES GROUP BY OFICINA_REP MIN(CUOTA) NULL 11 12 13 21 22 NULL 275.000.00 200.000,OO 350.000,OO 350.000,OO 300.o00,oaE MAX{CUOTA)
Hay un vnculo ntimo entre las funciones de columna SQL y la clusula GROUP Recurdese que las funciones de columna toman una columna de valores de datos y producen un nico resultado. Cuando est presente la clusula GROUP BY, dice a SQL que divida los resultados detallados en grupos y que aplique la funcin de columna separadamente a cada grupo, produciendo un nico resultado para cada grupo. Los siguientes pasos muestran las reglas para el procesamiento de consultas SQL, expandido de nuevo para las consultas de agrupacin. Para generar los resultados de una consulta de una instruccin SELECT:
BY.
l.
MAX(CUOTA) NULL 300.000,OO 300.000,ooe 350.000,OO 350.000,OO 300.000,ooe
2. 3.
Si la instruccin es la UNION de instrucciones SELECT, aplicar los pasos del 2 al 7 a cada una de las instrucciones para generar sus resultados individuales. Formar el producto de las tablas listadas en la clusula FROM. Si la clusula FROM lista una nica tabla, el producto es esta tabla. Si hay una clusula WHERE, aplicar su condicin de bsqueda a cada fila de la labia producto, conservando las filas para las que la condicin de bsqueda es TRUE (y descanando aquellas para las que la condicin es FALSE
o NULL).
Si hay una clusula GROUP BY, organizar las filas restantes de la tabla producto en dos grupos. de forma que las filas de cada grupo tengan idnticos valores en todas las columnas de agrupacin. 5. Si hay una clusula HAVING, aplicar su condicin de bsqueda a cada grupo de filas, conservando los grupos para los que la condicin de bsqueda es TRUE (y descartando aquellos para los que la condicin es FALSE o NULL). 6. Para cada fila restante (o grupo de filas), calcular el valor de cada elemento de la lista de seleccin para producir una nica fila de resultados. Para una referencia a columna simple, usar el valor de la columna en la fila en curso (o grupo de filas). Para una funcin de columna, usar el grupo actual de filas como argumento, si se especific GROUP BY; en caso contrario, usar el conjunto completo de resultados. 7. Si se especifica SELECT DISTINCT, eliminar cualquier fila duplicada que se haya producido en el resultado. 8. Si la instruccin es una UNION de instrucciones SELECT, mezclar los resultados de la consulta de las nstrucciones individuales en una nica tabla de resultados. Eliminar las filas duplicadas a menos que se especifique UNION
ALL.
Cuntos representantes estn asignados a cada oficina?

SELECT OFICINA_REP, COUNT(*) FROM REPRESENTANTES GROUP BY OFICINA_REP OFICINA_REP COUNT{*) NULL 11 12 13 21 22
1
4.
2
3
1
2
1
Cuntos clientes diferentes atiende cada representante?

SELECT COUNT (DISTINCT NUM_CLII, FROM CLIENTES GROUP BY REP_CLI clientes del representante'. REP _eLI
COUNT{DISTINCT NUM_CLI) CLIENTES DEL REPRESENTANTE REP_CLI 3 clientes del representante 4 clientes del representante
9.
Si hay una clusula se especifique.
ORDER BY,
101 102
Las filas generadas por este procedimiento forman los resultados de la consulta.
196

210S 210S 2109 2111 2111 101 109 107 103 105 150,00 7.10S,OO 31.3S0,O. 2.700,0 3.745,O.
197
Agrupacin de mltiples columnas

SQL puede agrupar los resultados de la consulta en trminos de los contenidos de dos o ms columnas. Por ejemplo, supngase que se desean agrupar los pedidos por representante y por cliente. Esta consulta agrupa los datos basndose en ambos criterios: Calcular los pedidos totales para cad~ cliente de cada representante.
SELECT REP, CLIENTE,
FROM PEDIDOS
SUM(IHPORTE)
GROUP BY REP, CLIENTE REP CLIENTE SUMIIMPQRTE) 101 101 101 102 102 102 103 105 105
2102 2108 2113
3.978,OO
150,OO 22.S0Q,QO
2106
2114
2120
2111
4.026.00 15.000,OO 3.750,OO

2.700,OO
Ntese que tambin es imposible obtener tanto resultados detallados como de resumen de una nica consulta, Para obtener resultados detallados con subtotales o para obtener subtotales multinivel hay que escribir un programa de aplicacin que use SQL para programacin y calcular los subtotales en la lgica del programa. Los desarrolladores originales de SQL Server trataron esta limitacin de SQL estndar aadiendo una clusula COMPUTE opcional al final de la instruccin SELECT. La clusula COMPUTE calcula los subtotales y los sub-subtotales, como se muestra en este ejemplo:
CalcuLar el total de los pedidos de cada cliente de cada representante, ordena. dos por representante y, dentro de cada representante, por cliente.
SELECT REP, CLIENTE, IMPORTE FROM PEDIDOS aRDER BY REP, CLIENTE COMPUTE SUM(IMPORTEj BY REP, CLIENTE COMPUTE SUM(IMPORTE) , AVG(IMPORTE) BY REP RETRIEVING DATA REP CLIENTE 101
2102
2103
2111
35.582,OO
3.745.00
Incluso con varias columnas de agrupacin, SQL proporciona s610 un nico nivel de agrupacin. La consulta produce una fila de resumen separada para cada par representante/cliente, Es imposible crear grupos y subgrupos con dos niveles de subtotales en SQ~, Lo mejor que se puede hacer es ordenar los datos de forma que las filas de los resultados de aparezcan en el orden apropiado, En muchas implementaciones de SQL, la clusula GROUP BY tendr automticamente el efecto colateral de ordenar los datos, pero se puede omitir esta ordenacin con una clusula ORDER BY, como se muestra a continuacin:
Calculflr el total cf..e los pedidos de cada cliente de cada representante, ordenados por cliente y, dentro de cada cliente, por representante"
SELECT FROM GROUP ORDER CLIENTE, REP, SUM(IMPORTE) PEDIDOS BY CLIENTE, REP BY CLIENTE, REP
IMPORTE
3.978,OO
sum
3 _978, OO:
REP CLIENTE 101

2108
IMPORTE
150,00
sum
150,OO:
-- - -- - - ----.- --- --- - - - --101 2113
REP CLIENTE
IMPORTE
22.S00,OO
sum
CLIENTE REP SUM(IMPORTE)
22.500,OO: 2101 2102 2103 2106 2107 106 101 105 102 110 1.4SB,OO,
surn
26.628,OO
avg
3.97B,OO:
35. SB2, OO: 4.026,OO: 23.132,OO:
S.B76,OO
..
198

IMPORTE
Capitulo 8: Consultas de resumen
199
REP CLIENTE
102
------------ --------2.130,oaE:
2106
102
2106
1.896.00
Tambin hay restricciones sobre los elementos que pueden aparecen en la lista de seleccin de una consulta de agrupacin. Todos los elementos de la lista de seleccin deben tener un nico valor para cada grupo de filas. Bsicamente, esto significa que un elemento de seleccin de una consulta de agrupacin puede ser: Una constante Una funcin de columna, que produce un nico valor resumiendo las filas del grupo Una columna de agrupacin, que por definicin tiene el mismo valor en cada fila del grupo Una expresin que contenga combinaciones de lo anterior En la prctica, una consulta de agrupacin siempre incluir tanto una columna de agrupacin como una funcin de columna en la lista de seleccin. Si no aparece ninguna funcin de columna, la consulta se puede expresar de forma ms sencilla usando SELECT DISTINCT, sin GROUP BY. A la inversa, si no se incluye una columna de agrupacin en los resultados, no ser posible decir qu fila de los resultados vienen de qu grupo! Otra limitacin de las consultas de agrupacin es que SQL ignora la informacin sobre las claves primarias y las externas al analizar la validez de una consulta de agrupacin. Considrese esta consulta:
,uro
4.026.00 REP CLIENTE
IMPORTE
--------- --------------102 2114 1S.000,OO

,uro
15.000,oae:
----------- ------------3.750,OO
102
REP CLIENTE
IMPORTE
2120
suro
3.150.00
,uro
22.776.00
avg
5.694,QO
Calcular el total de los pedidos de cada representante.

SELECT FROM WHERE GROUP NUM_EMPL, NOMBRE, SUM(IMPORTE) PEDIDOS, REPRESENTANTES REP = NUM_EMPL BY NOM_EMPL
La consulta proct!.lce una fila de resultados por cada fila de la tabla PEDIDOS,
pedidos de cada par cliente/representant,e (un subtot~l de baJo nIvel) y calcula la suma de los pedidos y el importe medIO de los pedIdos de. cada representante (un subtotal de alto nivel). Los resultados de la consulta contienen por tanto una mezcla de filas de detalle y de resumen, que incluyen tanto subtotales como sub-subtotales. , . . La clusula COMPUTE no es nada estndar, y de hecho ~s ~~lca en .el dIalecto Transact-SQL usado en SQL Server. Adems, viola los prInCIpIOS bslcos de las consultas relacionales porque los resultados de la instruccin SELECT no son una tabla, sino una combinacin extraa de diferentes tipos de filas. No obstante, como muestra el ejemplo, puede ser muy til.
ordenados pur
CLIENTE
dentro de
REP.
Adems, calc~la 1~ suma de los
Error: NOMBRE no es una expresin GROUP BY
Dada la naturaleza de los datos, la consulta tiene perfectamente un buen sentido porque la agrupacin del nmero de empleado de un representante es de hecho la misma agrupacin que sobre el nombre del representante. Ms precisamente, la columna de agrupacin NUM_EMPL es la clave primaria de la tabla REPRESENTANTES, as que la columna NOMBRE debe tener un nico valor en cada grupo. No obstante, SQL informa de un error porque la columna NOMBRE no est especificada explcitamente como columna de agrupacin. Para corregir el problema se incluye simplemente la columna NOMBRE como una segunda columna de agrupacin (redundante):
Restricciones sobre las consultas de agrupacin

Las consultas de agrupacin son sujeto de algunas limitaciones ~lgo estrictas. Las columnas de agrupacin deben ser columnas reales de las tablas h~tadas en la clusula FROM de la consulta. No se pueden agrupar las filas en trmmos del valor de una expresin calculada.

SELECT FROM WHERE GROUP NUM_EMPL, NOMBRE, SUM(IMPORTE) PEDIDOS, REPRESENTANTES REP = NUM_EMPL BY NUM_EMPL, NOMBRE
200
SOL. Manuaf de referencia

SUM (IMPORTE)
201
-------------------------------------26.628,OO
101 Daniel Ruidrobo 102 Susana Santos Bruno Arteaga Samuel Clavel Neus Azcrate Len-Freire Mara Jimnez
22.776,DO
103 Pablo Cruz
NUM_EHPL NOMBRE
NOMBRE Clara Luisa Herminio Samanta Juana Jorge Mara Paula Carlos Jos Susana Sandra
PELO Marrn NULL NULL NULL NULL Marrn Marrn Marrn Marrn Marrn Rubio Rubio
OJOS
2.7DQ,QO
39.327,OO 32.958.00 34.432,OO 58.633,OO
105 106 107 lOa 109
7.taS,Ooe
23.132,OO
110 Toms Saz
Por supuesto, si el nmero de empleado del representante no se necesita en los resultados de la consulta, se puede eliminar completamente de la lista de seleccin, dando:
Azul Azul Azul NULL NULL NULL NULL NULL NULL Marrn Azul Azul

SELECT FROM WHERE GROUP NOMBRE NOMBRE, SUM(IMPORTE) PEDIDOS. REPRESENTANTES REP = NUM_EMPL BY NOMBRE
SUM (IMPORTE)
Figura 8.4.
La tabla PERSONAS.
ejemplo de la Figura 8.4 ilustra manejo de ANSI/ISO de los valores clusula GROUP BY, como se muestra en esta consulta:
SELECT PELO, OJOS. COUNT(*) FROM PERSONAS GROUP BY PELO. OJOS PELO Marrn NULL NULL Marrn Marrn Marrn OJOS COUNT(*) Azul Azul NULL NULL Marrn Marrn
1
el
NULL
en la
---------------------------
Bruno Arteaga Daniel Ruidrobo Len Freire Mara Jimnez Neus Azcrate Pablo Cruz samuel Clavel Susana Santos Toms Saz
39.327,00 .26.628,00 5B.633,00 7.105.00 34.432.00 2.700,00 32.958,00 22.776,00 23.132,00
2 3 2
2
Valores NULL en las consultas de agrupacin

Un valor NULL plantea un problema esp~cial cuando aparece en una columna de agrupacin. Si el valor de la columna es desconocido, en qu grupo se deberla situar la fila? En la clusula WHERE, cuando se comparan dos valores NULL diferentes, el resultado es NULL (no TRUE), es decir, los dos valores NULL no se consideran iguales. Aplicar el mismo convenio a la clusula GROUP BY forzara que SQL reemplazase cada fila con una columna de agrupacin NULL en un grupo separado por s mismo. En la prctica, esta regla no es muy til. En su lugar, el estndar SQL de ANSI/ ISO SQL considera que dos valores NULL son iguales para los propsitos de la clusula GROUP BY. Si dos filas tienen valores NULL en las mismas columnas de agrupacin" e idnticos valores en todas sus columnas de agrupacin con valbres diferentes de NULL, se agrupan en el mismo grupo de filas. La pequea tabla de
Aunque este comportamiento de los valores NULL en la agrupacin de columnas est especificado claramente en el estndar ANSI/ISO, no est implementado en todos los dialectos de SQL. Conviene construir una pequea tabla de test y comprobar el comportamiento de cada SGBD en particular antes de confiar en ningn comportamiento especfico.
Condiciones de bsqueda de grupos (clusula HAVING)

Al igual que la clusula ~IHERE se puede usar para seleccionar y descartar las filas individuales que participan en una consulta, la clusula HAVING se puede usar para seleccionar y descartar los grupos de filas. El formato de la clusula HAVING es paralelo al de la clusula WHERE, que consiste en la palabra clave HAVING seguida de una condicin de bsqueda. La clusula HAVING especifica as una condicin de bsqueda para grupos.
202
203
Un ejemplo proporciona la mejor forma de comprender el papel de la clusula HAVING. Considrese esta consulta:
Cul es eL importe medio de fas pedidos de cada representante los cuyos pe didas superan los 30.000 ?
5ELECT RE?, AVG(IHPORTEI
PROM PEDIDOS
Las condiciones de bsqueda que se pueden especificar en la clusula HAVING son las mismas que las usadas en la clusula WHERE, como se describi en los captulos 6 y 9. A continuacin se muestra otro ejemplo del uso de una condicin de bsqueda de grupos: Para cada oficina con dos O ms personas, calcular la cuota total y las ventas totales para lodos los representantes que trabajan en ella.
SELECT FROM WHERE GROUP HAVING CIUDAD CIUDAD, SUM(CUOTA) , SUM (REPRESENTANTES, VENTASJ OFICINAS, REPRESENTANTES OFICINA ~ OFICINA_REP BY CIUDAD COUNT(*) >= 2 SUM{CUOTA) SUM (REPRESENTANTES ,VENTAS)
735.042,OO 835.915,OO 692.637.00
GROO? BY RE? HAVING SUM(IMPORTE} REP AVG(IMPORTE)

105 106 107 108 7.865. 40 16.479, oo 1l.477,33 8.376,14
>
30000.00
, i
La Figura 8.5 muestra grficamente cmo resuelve SQL la consulta. La clusula GROUP BY organiza primero los pedidos en grupos por represent~nte. La clusula HAVING elimina despus cualquier grupo donde el total de los pedid.os en el gru~o no exceda los 30.000 . Finalmente. la clusula SELECT calcula el Importe medIO de los pedidos para cada grupo restante y genera los resultados de la consulta.
Castelln 775.000,OO Len 700.000,00E: Navarra 575.000,00
Los siguientes pasos muestran las reglas para el procesamiento de consultas SQL, expandidos de nuevo para incluir las condiciones de bsqueda de grupos. Para generar los resultados de una consulta de una instruccin SELECT:
1.
T: bt PEDIDOS
,,
2. 3.
Tabla AGRUPADA
NmLPEOIDO
Tabla AGRUPADA
112961 112989 112975 113057
106 106
""
IMPORTE
31.!>OO,OO 1.458,00 2.100,00 600.00
"" +(stni CA.~I~r 106 >30.000 E

?
Sl.nI CANTIDM)
4.
H.<:.79.00
-+(SUM CANTlOAD) >30.000 E ?

\
5.
GROUP
.,
t
1l30S1 113045 113013 113024 113007 112992 113049
Si la instruccin es la UNION de instrucciones SELECT. aplicar los pasos del 2 al 7 a cada una de las instrucciones para generar sus resultados individuales. Formar el producto de las tablas listadas en la clusula FROM. Si la clusula FROM lista una nica tabla, el producto es esta tabla. Si hay una clusula WHERE, aplicar su condicin de bsqueda a cada fila de la tabla producto, conservando las filas para las que la condicin de bsqueda es TRUE (y descartando aquellas para las que la condicin es FALSE o NULL). Si hay una clusula GROUP BY, organizar las filas restantes de la tabla producto en dos grupos, de forma que las filas de cada grupo tengan idnticos valores en todas las columnas de agrupacin. Si hay una clusula HAVING, aplicar su condicin de bsqueda a cada grupo de filas, conservando los grupos para los que la condicin de bsqueda es TRUE (y descartando aquellos para los que la condicin es FALSE o
NULL).
~g: I <
108 108 108 108 108
1.420,00 4S.000.00 652.00 7.100.00 2.925.00 760,00 776,00
F"""
6.
<
7.
Para cada fila restante (o grupo de filas), calcular el valor de cada elemento de la lista de seleccin para producir una nica fila de resultados. Para una referencia a columna simple, usar el valor de la columna en la fila en curso (o grupo de filas). Para una funcin de columna, usar el grupo en curso de filas como argumento si se especific6 GROUP BY; en caso contrario, usar el conjunto completo de resultados. Si se especifica SELECT DISTINCT, eliminar cualquier fila duplicada que se haya producido en el resultado.
Figura 8.5.
Funcionamiento de una condicin de bsqueda de grupos.
..
204
8.
205
Si la instruccin es una UNIQN de instrucciones SELECT, mezclar los resultados de la consulta de las instrucciones individuales en una nica tabla de resultados. Eliminar las filas duplicadas a menos que se especifique UNIQN
ALL.
5. 6.
Genera una fila de resumen de resultados para cada grupo. Ordena los resultados de la consulta de forma que los productos con el mayor stock aparecen en primer lugar.
9.
Si hay una clusula se especifique.
QRDER BY.
Las filas generadas por este procedimiento forman los resullados de la consulta. Siguiendo este procedimiento, SQL maneja la consulta del ejemplo anterior como sigue:
1.
Como se describi anteriormente. DESCRIPCION, PRECIO y STOCK se deben especificar como columnas de agrupacin en esta consulta, slo porque aparecen en la lista de seleccin. Realmente no contribuyen en nada al proceso de agrupacin ID_FAB e ID_PRODUCTO especifican completamente una nica fila de la tabla PRODUCTOS, haciendo automticamente que las otras tres columnas tengan un nico valor en cada grupo.
2. 3.
4.
Rene las tablas OFICINAS Y REPRESENTANTES para encontrar la ciudad en la que trabaja cada representante. Agrupa las filas resultantes por oficina. Elimina los grupos con dos o menos filas - representa las oficinas que no cumplen el criterio de la clusula HAVING. Calcula la cuota total y las ventas totales para cada grupo.
Restricciones sobre. las condiciones de bsqueda de grupos

La clusula HAVING se usa para incluir o excluir grupos de filas de los resultados, as que la condicin de bsqueda que especifica debe ser una que se aplique al grupo completo, en lugar de a filas individuales. Esto significa que un elemento que aparezca dentro de la condicin de bsqueda en una clusula HAVING puede ser: Una constante Una funcin de columna que produce un nico valor que resume las filas del grupo Una columna de agrupacin, que por definicin tiene el mismo valor en cada fila del grupo Una expresin que contenga una combinacin de lo anterior En la prctica, la condicin de bsqueda de la clusula HAVING incluir siempre al menos una funcin de columna. Si no, la condicin de bsqueda se trasladara a la clusula WHERE y se aplicara a filas individuales. La forma ms sencilla de determinar si una condicin de bsqueda pertenece a la clusula WHERE O a HAVING es recordar cmo se aplican las dos clusulas:
La clusula WHERE se aplica afilas individuales, as que las expresiones que contiene se deben poder calcular sobre filas individuales. La clusula HAVING se aplica a grupos de filas, as que las expresiones que contiene se deben poder calcular sobre grupos de filas.
A continuacin se muestra otro ejemplo ms, que usa todas las clusulas de la instruccin SELECT:
Mostrar el precio, stock y cantidad total en orden para cada producto en que la cantidad total del pedido sea mayor que el 75 por ciento del stock.
SELECT DESCRIPCION, PRECIO, STOCK, SUM{CANTIDAD) FROM PRODUCTOS, PEDIDOS WHERE FAB = ID_FAB AND PRODUCTO ID~PRODUCTO GROUP BY ID_FAB" ID_PRODUCTO, DESCRIPCION, PRECIO, HAVING SUM(CANTIDAD) > (.75 STOCK) ORDER BY STOCK DESC
STOCK
DESCRIPCION
----------------------------------------------32 38 355,OO Reductora

25,OOE Zapata grande 243,OO Montura del motor 4.500,OO Riostra 1.425,OO 50-kg brazo
37
PRECIO STOCK SUM(CANTIDAD)
15 12
5
30 16
15
22
Para procesar esta consulta, SQL realiza conceptualmente los siguientes pasos: . 1. 2. 3. Rene las tablas PEDIDOS y PRODUCTOS para determinar la descripcin, el precio y stock de cada producto pedido. Agrupa las filas resultantes por fabricante e identificador de producto. Elimina los grupos donde la cantidad pedida (el total de la columna CANTIDAD para todos los pedidos del grupo) es menor que el 75 por ciento de la de stock. Calcula la cantidad total pedida por cada grupo.
Valores NULL Y condiciones de bsqueda de grupos

Al igual que la condicin de bsqueda de la clusula WHERE, la condicin de bsqueda de la clusula HAVING puede producir uno de estos tres resultados: Si la condicin de bsqueda es TRUE, el grupo de filas se conserva y contribuye como una fila de resumen a los resultados.
4.
206
Si la condicin de bsqueda es FALSE, se descarta el grupo de filas y no contribuye a ninguna fila-de resumen de los resultados. Si la condicin de bsqueda es NULL, se descarta el grupo de filas y no contribuye a ninguna fila de resumen de los resultados. Las anomalas que ocurren con los valores NU~L .en la condici~ de bsqueda son las mismas que en la clusula WHERE; se descnbieron en el CapItulo 6.
CAPTULO
Subconsultas
y expresiones de consultas
HA VING
sin GROUP BY .
La clusula HAVING se usa casi siempre en conjuncin con la clusula GROUP BY, pero la sintaxis de la instruccin SELECT no 1.0 requiere..Si aparece una clusula HAVING sin una clusula GROUP BY, SQL considera el conjunto completo de resultados detallados de la consulta en un nico grupo. En otras palabras, las funcion~s de columna de la clusula HAVING se aplican a un, y slo un, grupo para determInar si el grupo se incluye o excluye de los resultados, y el grupo c~nsiste en todas las filas. El uso de una clusula HAVING sin la clusula correspondiente GROUP BY se ve rara vez en la prctica.
Resumen
En este captulo se han descrito las consultas de resumen, que resumen datos de la base de datos: Las consultas de resumen usan funciones de columna SQL para colapsar una columna de valores de datos en un nico valor que resume la columna. Las funciones de columna pueden calcular la media, la suma, el mnimo y el mximo de una columna, contar el nmero de valores de datos en una columna o contar el nmero de filas de resultados de la consulta. Una consulta de resumen sin una clusula GROUP BY genera una nica fila de resultados, resumiendo todas las filas de una tabla o un conjunto reunido de tablas. Una consulta de resumen con una clusula GROUP BY genera mltiples filas de resultados cada una resumiendo las filas de un grupo en concreto. La clusula ~AVING acta como una clusula WHERE para grupos, seleccionando los grupos de filas que contribuyen al resumen de los resultados de la consulta.
Las subconsultas en SQL permite usar los resultados de una consulta como parte de otra. La capacidad de usar una consulta dentro de una consulta fue el motivo original de la palabra estructurado en el nombre <<lenguaje estructurado de consultas (Structured Query Language, SQL). Las subconsultas son menos conocidas que las reuniones de SQL, pero desempean un papel importante en SQL por tres motivos: Una instruccin SQL con una subconsulta es a menudo la forma ms natural de expresar una consulta, porque se acerca a la descripcin en lenguaje natural de la consulta. Las subconsultas hacen ms fcil la escritura de las instrucciones SELECT, porque permiten dividir la consulta en piezas (la consulta y sus subconsultas) y despus componerlas de nuevo. Algunas consultas no se pueden expresar en el lenguaje SQL sin el uso de una subconsulta. Las primeras secciones de este captulo describen las subconsultas y muestran cmo se usan en las clusulas WHERE y HAVING de una instruccin SQL. Las ltimas secciones de este captulo describen las capacidades avanzadas de expresin de consultas que se han aadido al estndar SQL2, que expanden sustancialmente la capacidad de SQL para realizar incluso las operaciones ms complejas de bases de datos.
Uso de las subconsultas

Una subconsulta es una consulta dentro de otra. El SGBD usa los resultados de la subconsulta para determinar los resultados de la consulta de alto nivel que contiene a la subconsulta. En las formas ms simples de una subconsulta, sta aparece dentro de una clusula WHERE o HAVING de otra instruccin SQL. Las subconsul-
207
208
Captulo 9: Subconsultas y expresiones de consultas
209
tas proporcionan una forma natural y. eficiente de manejar las solicitudes de consultas que se expresan en trminos de los resultados de otras. A continuacin se muestra un ejemplo de tal solicitud:
Concepto de subconsulta
La Figura 9.1 muestra la forma de una subconsulta SQL. La subconsulta se encierra entre parntesis; sin embargo, tiene la forma familiar de una instruccin SELECT, con una clusula FROM y clusulas opcionales WHERE, GROUP BY Y HAVING. La forma de estas clusulas en una subconsulta es idntica a la de la instruccin SELECT, y realizan sus funciones normales cuando se usan dentro de una subconsulta. Hay, no obstante, algunas diferencias entre una subconsulta y un instruccin SELECT real: En la mayora de los usos comunes, una subconsulta debe producir una nica fila de datos como resultado. Esto significa que una subconsulta casi siempre tiene un nico elemento de seleccin en su clusula SELECT.
Listar las oficinas en las que el objetivo de ventas exceda la suma de las cuotas de cada representante.
La solicitud pide una lista de oficinas de la tabla OFICINAS donde el valor de la columna OBJETIVO cumple alguna condicin. Parece razonable que la instruccin SELECT que expresa la consulta pueda ser corno:
SELECT CIUDAD FROM OFICINAS WHERE OBJETIVO
>
???
El valor ??? se debe rellenar y debe ser igual a la suma de las cuotas de los representantes asignados a la oficina en cuestin. Cmo se puede especificar ese valor en la consulta? Por el Captulo 8 se sabe que la suma de las cuotas de una oficina determinada (digamos, por ejemplo, el nmero de oficina 21) se puede obtener con esta consulta:
SELECT SUM(CUOTA) FROM REPRESENTANTES WHERE OFICINA_REP ~ 21
r-ISELECT
-t:
ALL
=r
I!;:Cin -'n',-------"
elemento-de-
DISTINCT
Pero sera poco eficaz tener que escribir esta consulta, escribir los resultados y escribir en la consulta anterior la cantidad correcta. Cmo se pueden poner los resultados de esta consulta en la consulta anterior en lugar de los signos de interrogacin? Podra ser razonable comenzar con la primera consulta y reemplazar ??? por la segunda consulta, como sigue:
SELECT CIUDAD FROM OFICINAS WHERE OBJETIVO> (SELECT SUM(CUOTA) FROM REPRESENTANTES WHERE OFICINA_REP ~ OFICINA)
L....+
PROM
fespecificac:n-de+tablas
L-.
WHERE
condicin-de-bsqueda
~GROUP BY
De hecho, sta es una consulta SQL formada correctamente. Por cada oficina, la consulta intema (la subconsulta) calcula la suma de las cuotas de los representantes que trabajan en esa oficina. La consulta externa (la consulta principal) compara el objetivo de la oficina con el total calculado y decide si aade la ofi~ina a los resultados de la consulta principal. Al trabajar juntas, la consulta principal y la subconsulta expresan la solicitud original y recuperan los datos solicitados de la base de datos. Las subconsultas SQL aparecen normalmente como parte de las clusulas WHERE o HAVING. En la clusula WHERE ayudan a seleccionar filas individuales que aparecen en los resultados. En la clusula HAVING ayudan a seleccionar grupos de filas que aparecen en los resultados de la consulta.
columnas-de-
agrU~aCin ~
~HAVING condicin-de-bsqueda
..
Figura 9.1.
Diagrama sintctico de las subconsuJtas.
210
211
La clusula RDER BY no se puede especificar en una subconsulta. Los resultados de la subconsulta se usan internamente en la consulta principal y nunca son visibles para el usuario, as que tiene poco sentido, en cualquier caso, ordenarlas. Los nombres de columna que aparecen en una subconsulta pueden hacer referencia a columnas de tablas de la consulta principal. Estas referencias externas se describen en detalle ms adelante en la seccin Referencias externas. En la mayora de implementaciones, una subconsulta no puede ser la UNION de varias instrucciones SELECT diferentes; s610 se permite una nica SELECT. (El estndar SQL2 permite expresiones de consultas mucho ms potentes y alivia esta restriccin, como se describe ms adelante en la seccin Consultas avanzadas en SQL2.)
Es ms conveniente usar la subconsulta, pero no es esencial. Usualmente, la subconsultas no son tan simples. Por ejemplo, considrese de nuevo la consulta de la seccin anterior:
Listar las oficinas para las que el objetivo de ventas supere la suma de las cuotas de cada representante.
SELECT CIUDAD PROM OFICINAS WHERE OBJETIVO>
(SELECT SUM(CUOTA) FROM REPRESENTANTES WHERE OFICINA~REP = OFICINA)
CIUDAD
Castelln Len
Subconsultas en la clusula WHERE

Las subconsultas se usan ms frecuentemente en la clusula WHERE de una instruccin SQL. Cuando aparece una subconsulta en la clusula WHERE, funciona como parte del proceso de seleccin de filas. Las subconsultas ms simples aparecen dentro de una condicin de bsqueda y producen un valor que se usa para comprobar la condicin de bsqueda. A continuacin se muestra un ejemplo de una subconsulta simple:
En este caso (ms normal), la subconsulta no se puede calcular una vez para toda la consulta. La subconsulta produce un valor diferente para cada oficina, en trminos de las cuotas de los representantes para esa oficina en particular. La Figura 9.2 muestra
Listar los representantes cuya cuota sea menor que ella por ciento de los objetivos totales de la empresa.
SELECT NOMBRE FROM REPRESENTANTES WHERE CUOTA < (.1 * (SELECT SUM(OBJETIVO) NOMBRE
Bernardo Snchez
-+@{:"= "'" ''"0'",'

>?
Tabla OFICINAS
OFICINA CIUDAD OilJETIVO
Subconsulta
PROM REPRESENTANTES WHERE OFlCINJ\.ftEP ~ 22
,}
FROM OFICINAS})
En este caso la subconsulta calcula la suma de los objetivos de ventas de todas las oficinas para determinar el objetivo total de la empresa, que se multiplica por el 10 por ciento para detenninar la cuota de venta umbral para la consulta. Este valor se usa despus en la condicin de bsqueda para comprobar cada fila de la tabla REPRESENTANTES y encontrar los nombres requeridos. En este caso simple la subconsulta produce el mismo valor para cada fila de la tabla REPRESENTANTES; el valor de CUOTA de cada representante se compara con el mismo nmero de la com- . paa. De hecho, se podra realizar esta consulta realizando primero la subconsulta, calculando el importe de cuota umbral (275.000 en la base de datos de ejemplo), y llevando a cabo la consulta principal usando este nmero en una consulta WHERE simple:
WHERE CUOTA < 275000
" n " "

B
Daimiel Navarra Castelln Almeria Le6n
300.000,00 575.000.00 BOO.OOO.OO 350.000.00 725.000.00
Tabla REPRESENTANTES Subconsulta
L.0{~ELECT SUM (CumA) } >7 FROM REPRESENTANTES

l'o'HERE OFICINI\...REP .. 21
Figura 9.2.
Funcionamiento de la subconsulta en la clusula 1'1HERE.
212
213
conceptualmente cmo realiza SQL la consulta. La consulta principal obtiene sus datos de la tabla OFICINAS y la clusula WHERE selecciona las oficinas que se incluirn en los resultados de la consulta. SQL va por las filas de la tabla OFICINAS una a una, aplicando el test establecido en la clusula WHERE. La clusula WHERE compara el valor de la columna OBJETIVO de la fila en curso con el valor producido por la suhconsulta. Para comprobar el valor de OBJETIVO, SQL lleva a cabo la subconsulta encontrando la suma de las cuotas de los representantes de la oficina en curso. La subconsulta produce un nico nmero, y la clusula WHERE compara el nmero con el valor de OBJETIVO, seleccionando o descartando la oficina en curso en trminos de la comparacin. Como muestra la figura, SQL lleva a cabo repetidamente la subconsulta, una vez por cada fila comprobada en la clusula WHERE de la consulta principal.
Condiciones de bsqueda en las subconsultas .

Las subconsultas aparecen usualmente como parte de la condicin de bsqueda de una clusula WHERE o HAVING. El Captulo 6 describi las condiciones simples de bsqueda que se pueden usar en estas clusulas. Adems, la mayora de productos SQL ofrecen estas condiciones de bsqueda en las subconsultas: Test de comparacin en subconsultas. Compara el valor de una expresin con el valor producido por la subconsulta. Este test se parece al test simple de comparacin. Test de pertenencia al conjunto devuelto por una subconsulta. Comprueba si el valor de una expresin coincide con uno de los valores del conjunto producido por la subconsulta. Este test se parece al test simple de pertenencia a conjuntos. Test de existencia. Comprueba si la subconsulta produce alguna fila de resultados. Tests cuantificados. Compara el valor de una expresin con cada uno de los valores del conjunto producido por una subconsulta.
Referencias externas
Dentro del cuerpo de una subconsulta es necesario a menudo hacer referencia al valor de una columna de la fila actual de la consulta principal. Considrese de nuevo la consulta de las secciones anteriores:
Listar las oficinas para las que el objetivo de ventas supere la suma de las cuotas de sus representantes.
SELECT CIUDAD FROM OFICINAS WHERE OBJETIVO>
El test de comparacin en subconsultas !=, <>, <, <=, >, >=)

Este test de comparacin en subconsultas es una forma modificada del test simple de comparacin, como se muestra en la Figura 9.3. Compara el valor de una expresin con el valor producido por una subconsulta y devuelve un resultado TRUE si la comparacin es cierta. Este test se usa para comparar el valor de la fila que se est comprobando con un nico valor producido por la subconsulta, como en el siguiente ejemplo.
(SELECT SUM(CUOTA) FROM REPRESENTANTES WHERE OFICINA_REP = OFICINA)
I
l'
l'
El papel de la subconsulta en esta instruccin SELECT es calcular la cuota total de los represenFantes que trabajan en una oficina en concreto -especficamente, la oficina que se est comprobando en la clusula WHERE de la consulta principal-o La subconsulta hace esto examinando la tabla REPRESENTANTES. Pero obsrvese que la columna OFICINA de la clusula WHERE de la subconsulta no hace referencia a ninguna columna de la tabla REPRESENTANTES; hace referencia a una columna de la tabla OFICINAS, que es parte de la consulta principal. Al ir por cada fila de la tabla OFICINAS, usa el valor de OFICINA de la fila actual cuando realiza la subconsulta. La columna OFICINA de esta subconsulta es un ejemplo de una referencia externa, que es un nombre de columna que no se refiere a ninguna de las tablas listadas en la clusula FROM de la subconsulta en la que aparece el nombre de columna. En cambio, el nombre de columna hace referencia a una columna de una tabla especificada en la clusula FROM de la consulta principal. Como muestra el ejemplo anterior, cuando el SGBD examina la condicin de bsqueda de la subconsulta, el v.alor de la columna en una referencia externa se toma de la fila que se est comprobando en la consulta principal.
---expresin
--,'r-<>
----,-- subconsulta---+-.
<
<=
>
>=
Figura 9.3.
Diagrama sintctico del test de comparacin en subconsultas.
214

DESCRI PC ION Serie 3, cable Serie 1, cable Serie 2, cable

STOCK 207 277 167
215
Listar los representantes cuyas cuotas son iguales o superiores al objetivo de la oficina de ventas de Almeria.
SELECT NOMBRE
FROM REPRESENTANTES WHERE CUOTA >= (SELECT OBJETIVO FROM OFICINAS WHERE CIUDAD = 'Almera') NOMBRE
El test de comparacin en subconsultas especificado por el estndar SQLl e incluido por todos los productos SOBO lderes permite que una subconsulta aparezca slo en la parte derecha del operador de comparacin. Esta comparacin: A < (subconsulta)
se permite, pero esta otra:
La subconsulta del ejemplo devuelve el objetivo de ventas de la oficina de AImera. El valor se usa despus para seleccionar a los representantes cuyas cuotas son superiores al objetivo obtenido. El test de comparacin en subconsultas ofrece los mismos seis operadores de comparacin (=. <>, <, <=, >, >;:.) disponibles para el test de comparacin. La subconsulta especificada en este test debe producir un nico valor del tipo de datos apropiado -es decir, debe producir una nica fila de resultados conteniendo exactamente una columna-o Si la subconsulta produce varias fiJas o varias columnas, la comparacin no tiene sentido y SQL informa del error. Si la subconsulta no produce filas o produce un valor NULL, el test de comparacin devuelve NULL (desconocido). A continuacin se muestran ms ejemplos de este test:
(subconsulta) > A
no se permite. Esto no limita la capacidad de los tests de comparacin, porque el operador en cualquier comparacin de desigualdad siempre se puede dar la vuelta de forma que la subconsulta se site en la parte derecha de la desigualdad. Sin embargo. significa que a veces se debe invertir la lgica del lenguaje natural para obtener una forma de la solicitud en una instruccin SQL legaL El estndar SQL2 elimin esta restriccin y permite que la subconsulta aparezca en cualquier lado del operador de comparacin. De hecho, el estndar SQL2 va mucho ms all y permite que se aplique un}est de comparacin a una fila completa de valores. en lugar de a un nico valor. Esta y otras caractersticas ms avanzadas de expresin de consultas se describen en las ltimas secciones de este captulo. Sin embargo, no se incluye de forma unifonne en las versiones actuales de los principales productos SQL. Por razones de transportabilidad, es mejor escribir consultas que se adecuen a las restricciones de SQLl, como se han descrito.
Listar"todos los clientes a los que sirve Bruno Arteaga.

SELECT EMPRESA FROM CLIENTES WHERE REP_CLI
(SELECT NUM_EMPL FROM REPRESENTANTES WHERE NOMBRE: 'Bruno Arteaga')
El test de pertenencia a conjuntos
(IN)
EMPRESA Acme Toledo S.A.
El test de pertenencia a conjuntos (IN) en subconsultas es una forma modificada del test de pertenencia a conjuntos simple. como se muestra en la Figura 9.4. Compara
Listar todos los productos del fabricante AC/ para los que su stock est por encima del stock del producto ACI-41004.
SELECT FROM WHERE ANO OESCRIPCION, STOCK PRODUCTOS IO_FAB : 'ACI' STOCK> (SELECT STOCK FROM PRODUCTOS WHERE IO_FAB : 'ACI' AND ID_PRODUCTO: '41004')
- - expresin-de-test
--,--IN------ subconsulta
LNOT-I
...
subcon~
Figura 9.4.
Diagrama sintctico del test de pertenencia a conjuntos en su Itas (IN).
216
Captulo 9: $ubconsultas y expresiones de consultas

SELECT EMPRESA FROM CLIENTES WHERE NUM_CLI IN (SELECT FROM WHERE ANO AND AND EMPRESA
Acme Ace Internacional Henche & L6pez JCP S.A.
>
217
un nico valor de datos con una columna de valores de datos producidos por una subconsulta y devuelve un resultado TRUE si el valor de dalos coincide con uno de los valores de la columna. Este test se usa cuando es necesario comparar un valor de la fila que se est comprobando con un conjunto de valores producido por una subconsulta. A continuacin se muestra un ejemplo simple:
Listar los represemames que trabajan en oficinas que esIn por encima de sus objetivos.
SELECT NOMBRE FROM REPRESENTANTES WHERE OFICINA_REP IN (SELECT OFICINA
FROM OFICINAS
DISTINCT CLIENTE PEDIDOS FAB = 'ACI' PRODUCTO LIKE '4100%' FECHA_PEDIDO BETWEEN '01-ENE-90' '30-JUN-90')
WHERE VENTAS NOMBRE
OBJETIVO)
Maria Jimnez Samuel Clavel Bruno Arteaga Susana Santos Len Freire
En cada uno de estos ejemplos la subconsulta produce una columna de valores de datos, y la clusula WHERE de la consulta principal comprueba si un valor de una fila de la consulta principal coincide con uno de los valores de la columna. La forma de la subconsulta del test IN funciona exactamente igual que el test simple IN, excepto en que el conjunto de valores se produce por una subconsulta, en lugar de listarse explcitamente en la instruccin.
La subconsulta produce un conjunto de nmeros de oficina donde las ventas SQn superiores a sus objetivos (en la base de datos de ejemplo hay tres de estas oficinas con nmeros 11, 13 y 21). La consulta principal comprueba a continuacin cada fila de la tabla REPRESENTANTES para determinar si un representante en concreto trabaja en una oficina con uno de estos nmeros. A continuacin se muestran otros ejemplos de subconsultas que comprueban la pertenencia a conjuntos:
Listar los represimtantes que no trabajan en oficinas dirigidas por Len Freire (empleado lOS).
SELECT NOMBRE FROM REPRESENTANTES WHERE OFICINA-REP NOT IN (SELECT OFICINA FROM OFICINAS WHERE JEF = 108) NOMBRE
Bruno Arteaga Maria Jimnez Samuel Clavel Bernardo Snchez Daniel Ruidrobo Pablo Cruz
El test de existencia
(EXISTS)
El test de existencia (EXISTS) comprueba si una subconsulta produce alguna fila como resultado de la consulta, como se muestra en la Figura 9.5. No hay ningn test de comparacin simple que se parezca al test de existencia; se usa slo con subconsultas. A continuacin se muestra un ejemplo de una solicitud que se puede expresar de forma natural con un test de existencia:
Listar los productos para los que se haya recibido un pedido de 25.000 o ms.
La solicitud se podra reescribir fcilmente como:

Listar los productos para los que existe al menos un pedido en la tabla PEDI DOS de forma que (a) sea para el producto en cuestin), (b) tenga un importe de al menos 25.000 .
~EXISTS
subconsulta
...
LNcrr~
Figura 9.5.
Listar t040s los clientes que han formulado pedidos de zapatas de ACI (fabricante ACI, nmeros de producto que comienzan en 4100) entre enero y junio de 1990,
Diagrama sintactico del test de existencia
(EXISTS).
218

SELECT EMPRESA PROM CLIENTES WHERE REP_CLI
219
La instruccin SELECT usada para obtener la lista requerida de productos se parece a la solicitud reescrita:
SELECT DISTINCT DESCRIPCION
FROM PRODUCTOS
WHERE EXISTS (5ELECT NUM_PEDIDO

FROM PEDIDOS
WHERE PRODUCTO = ID PRODUCTO

AND FAB = ID_FA8
AND
I~PORTE
>= 25000.00)
(SELECT PROM WHERE AND NOT EXISTS ( SELECT FROM WHERE ANO EMPRESA Cruz e hijos F. Lpez S.A.
NUM_EMPL REPRESENTANTES NOMBRE ~ 'Susana Santos') PEDIDOS CLIENTE NUM_CLI IMPORTE> 3000.00)
DESCRIPCION
SO-kg brazo
Llave Riostra
Zapata pequei\a
Listar las oficinas donde haya un representante cuya cuota represente ms del 55 por ciento del objetivo de la oficina.
SELECT CIUDAD FRQM OFICINAS WHERE EXISTS (SELECT FROM REPRESENTANTES WHERE OFICINA_REP ~ OFICINA ANO CUOTA> (.55 .. OBJETIVO)) CIUDAD Daimiel Almeria
Conceptualmente, SQL procesa esta consulta examinando la tabla PRODUCTOS y realizando la subconsulta para cada ~roducto. La s~bcons~lta produce una columna que contiene los nmeros de pedido para cualqUier pedl.do ~el producto en curso que exceda de 25.000 . Si hay tales pedidos (es deCIr, SI la columna no est vaca), el test EXISTS es TRUE. Si la subconsulta no produce filas, el test EXISTS es FALSE. El test EXISTS no puede producir un valor NULL. Se puede invertir la lgica del test EXISTS usando la forma NOT EXISTS. En este caso, el test es TRUE si la subconsulta no produce filas. y FALSE en caso contrario. . Ntese que la condicin de bsqueda no usa realmente los resultados de la subconsulta. Simplemente comprueba si la subconsulta produce resulta~d~s. Por esta razn, SQL relaia la regla de las subconsultas deben devolver una UOIca columna de datos y permite usar la forma SELECT * en la subconsulta de un test EXISTS. La consulta anterior se podra haber escrito as:
Ntese que en cada uno de estos ejemplos la subconsulta incluye una referencia exterior a una columna de la tabla de la consulta principal. En la prctica, la subconsulta de un test EXISTS siempre contendr una referencia externa que vincule la subconsulta con la fila que se est comprobando en el momento en la consulta principal.
Listar los productos para los que se hayan recibido pedidos de 25.000 o ms.
SELECT DESCRIPCION FROM PRODUCTOS WHERE EXISTS (SELECT FROM WHERE AND AND
Tests cuantificados (ANY y ALL)
PEDIDOS PRODUCTO ~ ID PRODUCTO FAB ~ ID_FAB IMPORTE >~ 25000.00)
La versin de la subconsulta del test IN comprueba si un valor de datos es igual a algn valor de una columna de los resultados de una subconsulta. SQL proporciona dos tests cuantificados, ANY y ALL, que extienden esta nocin a otros operadores de comparacin, como mayor que ( y menor que)} ). Ambos tests comparan un valor de datos con la columna de valores de datos producida por una subconsulta, como se muestra en la Figura 9.6.
El test ANY
En la prctica, la subconsulta de un test EXISTS se escribe siempre usando la notacin SELECT ,o,. A continuacin se muestran ejemplos adicionales de consultas que usan EXISTS:
Listar los clientes asignados a Susana Santos que hayan fonnulado un pedido superior a 3.000 .
El test ANY se usa en conjuncin con uno de los seis operadores de comparacin de SQL (=, <>, <, <=, >, >=) para contrastar un nico valor de test con una columna de valores de datos producida por una subconsulta. Para realizar este test, SQL usa
;"
220
221
- - - - expresin-de-test
--[,
ANY
subconsulta----+-
1---<>----1.I
< ----1 f--<=----1
>
ALL
incluye en los resultados de la consulta. En caso contrario, el representante no se incluye en los resultados. La palabra clave 50ME es una alternativa para ANY especificada en el estndar de SQL ANSIfISO. Se puede usar en general cualquiera de ellas, pero algunas marcas de SGBD no admiten SOME. El test ANY puede ser difcil de entender a veces porque implica un conjunto completo de comparaciones, no slo simplemente una. Si se lee el test de forma ligeramente diferente a como aparece en la instruccin puede ayudar. Si aparece el test ANY:
WHERE X < ANY (SELECT Y ... )
en lugar de leer este test como:
----1
donde X es menor que algn Y seleccionado ...
,--->=-.l
se puede probar a leerlo como:

"donde, para algn Y,
Figura 9.6.
Diagrama sintctico de los tests de comparacin cuantificados (ANY

y ALL).
X es menor que Y
Cuando se usa este truco, la consulta precedente se convierte en:
el operador de comparacin especificado para contrastar el valor de test con cada valor de datos de la columna, uno a uno. Si alguna de las comparaciones individuales da un resultado TRUE, el test ANY devuelve un resultado TRUE. A continuacin se muestra un ejemplo de una solicitud que se puede expresar con el test ANY:
Listar los representantes que han formulado un pedido que representa ms del 10 por ciento de su cuota.
SELECT NOMBRE
SeLeccionar Los representantes en los que, para aLgn pedido anotado por el representante, ellO por ciento de La cuota del representante es menor que el impar/e del pedido.
Si la subconsulta en un test ANY no produce filas de resultados o si los resultados incluyen valores NULL, la operacin de un test ANY puede variar de un SGBD a otro. El estndar SQL de ANSI/ISO especifica estas reglas detalladas que describen los resultados del test ANY cuando el valor del test se compara con la columna de los resultados de la subeoosulta: Si la subconsulta produce una columna vaca de resultados, el test ANY devuelve FALSE -no se produce ningn valor en la subconsulta para el que se cumpla el test de comparacin. Si el test de comparacin es TRUE para al menos uno de los valores de datos de la columna, entonces la condicin de bsqueda ANY devuelve TRUE -hay realmente algn valor producido por la subconsulta para el que se cumple el test de comparacin. Si el test de comparacin es FALSE para cada valor de datos en la columna, entonces la condicin de bsqueda ANY devuelve FALSE. En este caso se puede afirmar que no se ha producido ningn valor en la subconsulta para el que se cumpla el test de comparacin. Si el test de comparacin no es TRUE para algn valor de datos de la columna, pero es NULL (desconocido) para uno o ms valores de datos, entonces la condicin de bsqueda ANY devuelve NULL. En esta situacin no se puede afirmar si hay un valor producido por la subconsulta para el que se cumple el
FROM REPRESENTANTES WHERE (.1 * CUOTA) < ANY (SELECT IMPORTE

FROM PEDIDOS
WHERE REP : NOM_EMPLl NOMBRE

Samuel Clavel
Len Freire
Neus Azcrate
PRESENTANTES,
Conceptualmente, la consulta principal comprueba cada fila de la tabla REuna a una. La subconsulta halla todos los pedidos anotados por el representante en curso y devuelve una columna que contiene los importes de estos pedidos. La clusula WHERE de la consulta principal calcula a continuacin ellO por ciento de la cuota del representante actual y lo usa como valor de test, comparndolo con cada importe de pedido producido por la subconsulta. Si algn pedido supera el valor calculado del test, el test ANY devuelve TRUE, y el representante se
....
222
223
test de comparacin; puede que lo haya y puede que no dependiendo de los valores reales (an desconocidos) para el dato NULL.
El operador de comparacin ANY puede ser muy sutil de usar en la prctica, especialmente en conjuncin con el operador de comparacin desigualdad (<. A continuacin se muestra un ejemplo que ilustra el problema:
Siempre se puede convertir una consulta con un test ANY en una consulta con un test EXISTS, trasladando la comparacin dentro de la condicin de bsqueda de la subconsulta. Esto es generalmente una buena idea porque elimina errores como el que se ha descrito. Aqu hay una forma alternativa de la consulta usando el test
EXISTS:
SELECT NOMBRE, EDAD FROM REPRESENTANTES WHERE NOT EXISTS {SELECT FROM OFICINAS WHERE NUM_EMPL NOMBRE EDAD 31 48 45 41 29
49
Listar los nombres y edades de todas las personas incluidas en ventas que no dirigen una oficina.
Es tenlador expresar esta consulta como se muestra en este ejemplo:
SELECT NOMBRE, EDAD FROM REPRESENTANTES WHERE NUM_EMPL <> ANY (SELECT JEF FROM OFICINAS)
JEF}
La subconsulta:
SELECT JEF
Mara Jimnez Susana Santos Daniel Ruidrobo Toms Saz Pablo Cruz Neus Azcrate
FROM OFICINAS
El test ALL
produce obviamente los nmeros de empleado de Jos directores y, por tanto, la consulta parece decir:
Hallar cada representante que no sea director de ninguna oficina.

Pero esto no es lo que dice la consulta! Lo que dice es esto:
Hallar cada representante que, para alguna oficina, no sea su director.

Por supuesto para un representante dado es posible hallar algunas oficinas de las que este representante no sea director. Los resultados incluiran a todos los representantes y, por tanto, fallaran al responder la cuestin planteada. La consulta correcta es:
SELECT NOMBRE, EDAD FROM REPRESENTANTES WHERE NOT (NUM_EMPL :
Al igual que el test ANY, el test ALL se usa en conjuncin con uno de los seis operadores de comparacin de SQL (=, <>, <, <=, >, >=) para contrastar un nico valor de test con una columna de valores de datos producidos por una subconsulta. Para resolver el test, SQL usa el operador de comparacin especificado para contrastar el valor de test con cada valor de datos de la columna, uno por uno. Si todas las comparaciones individuales producen un resultado TRUE, el test ALL devuelve un resultado TRUE. A continuacin se muestra un ejemplo que se puede resolver con el test ALL:
Listar las oficinas, y sus objetivos, donde todos los representantes tengan ven. tas que excedan el 50 por ciento del objetivo de cada oficina.
SELECT CIUDAD, OBJETIVO FROM OFICINAS WHERE (.50 OBJETIVO) < ALL (SELECT VENTAS FROM REPRESENTANTES WHERE OFICINA_REP : OFICINA) CIUDAD Daimiel Navarra Almera OBJETIVO 300.000,OO 575.000,OO 350.000,OO
ANY (SELECT JEF FROM OFICINAS')
NOMBRE Mara Jimnez Susana Santos Daniel Ruidrobo Toms Saz Pablo Cruz. Neus Azcrate
EDAD 31 48 45 41 29
49
cINAs'
Conceptualmente, la consulta principal comprueba cada fila de la tabla OFIuna a una. La subconsulta halla todos los representantes que trabajan en la
..
,,-
1 ...
224
225
oficina en curso y devuelve una columna que contiene las ventas de cada representante. La consulta WHERE de la consulta principal calcula a continuaci6n el 50 por ciento del objetivo de la oficina y lo usa como valor de test, comparndolo con cada valor de ventas producido por la subconsulta. Si todas las ventas superan el valor de test calculado, el test ALL devuelve TRUE, y la oficina se incluye en los resultados de la consulta. En caso contrario no se incluye. Al igual que con el test ANY, el test ALL puede ser difcil de comprender porque implica un conjunto completo de comparaciones, no slo una nica. De nuevo, ayuda el leer el test de forma ligeramente diferente a como aparece en la instruccin. Si aparece este test ALL:
WHERE X
<
Los errores sutiles que pueden ocurrir cuando el test ANY se combina con el operador de comparacin de desigualdad tambin pueden ocurrir con el test ALL. Como con el test ANY, el test ALL siempre se puede convertir en un test EXISTS equivalente trasladando la comparacin dentro de la subconsulta.
Subconsultas y reuniones
Es posible que se haya reparado a lo largo de este captulo en que muchas de las consultas que se han escrito con subconsuItas se podran haber escrilo como consultas multitabla, o reuniones. ste es el caso habitual, y SQL permite escribir la consulta de ambas formas. Este ejemplo lo ilustra:
ALL (SELECT Y ... )
en lugar de leerlo corno:

-donde X es menor que todos Y seleccionados
LiSTar los nombres y edades de los representantes que trabajan en las oficinas de la regin oeste.
SELECT NOMBRE. EDAD FROM REPRESENTANTES WHERE OFICINA_REP IN (SELECT OFICINA FROM OFICINAS WHERE REGION ~ 'Oeste') NOMBRE Susana Santos Le6n Freire Neus Azcrate EDAD 48 62 49
se puede probar a leerlo como:

"donde. para todo Y. X es menor que Y
Cuando se usa este truco, la consulta anterior se convierte en:
Seleccionar las oficinas donde, para todos los representantes que trabajan en cada una de ellas, el 50 por ciento del objetivo de la oficina es menor que las ventas del representante.
Si la subconsulta en un test ALL no produce filas de resultados, o si la consulta incluye valores NULL, la operacin del test ALL puede variar de un SGBD a otro. El estndar SQL de ANSIIISO especifica estas reglas detalladas que describen los resultados del test ~LL cuando el valor del test se compara con la columna de los resultados de la subconsulta: Si la subconsulta produce una columna vaca de resultados, el test ALL devuelve TRUE. El test de comparacin no se cumple para ningn valor de la subconsulta; simplemente no hay valores. Si el test de comparacin es TRUE para todos los valores de datos de la columna, entonces la condicin de bsqueda ALL devuelve TRUE. De nuevo, el test de comparacin se cumple para cada valor producido por la subconsulta. Si el test de comparacin es FALSE para algn valor de datos en la columna, entonces la condicin de bsqueda ALL devuelve FALSE. En este caso el test de comparacin no se cumple para ningn valor de datos producido por la consulta. Si el test de comparacin no es FALSE para ningn valor de datos de la columna, pero es NULL (desconocido) para uno o ms valores de datos, entonces la condicin de bsqueda ALL devuelve NULL. En esta situacin no se puede afirmar si hay un valor producido por la subconsulta para el que se cumple el test de comparacin; puede que lo haya y puede que no, dependiendo de los valores reales (an desconocidos) para el dato NULL.
Esta forma de la consulta refleja estrechamente la solicitud planteada. La subconsulta da una lista de oficinas de la regin oeste y la consulta principal halla los representantes que trabajan en una de las oficinas de la lista. A continuacin se muestra una forma alternativa de la consulta usando una reunin de dos tablas:
Listar los nombres y edades de los representantes que trabajan en las oficinas de la regin oeste.
SELECT FROM WHERE AND NOMBRE Susana Sa~tos Len Freire Neus Azcrate NOMBRE. EDAD REPRESENTANTES. OFICINAS OFICINA_REP : OFICINA REGION = 'Oeste' EDAD 48 62 49
NAS
Esta forma de la consulta rene la tabla REPRESENTANTES con la tabla OFICIpara hallar la regin en la que trabaja cada empleado, y despus elimina las filas de los empleados que no trabajan en la regin oeste.
226
227
Cualquiera de las dos consultas hallar los representantes correc!os, y ninguna es mejor o peor. Muchas personas encontrarn que la primera forma (con una subconsulta) es ms natural porque la solicitud en lenguaje natural no pide ninguna informacin acerca de las oficinas, y porque parece un poco extrao reunir las tablas REPRESENTANTES y OFICINAS para responder a la solicitud. Por supuesto, si la solicitud se cambia para pedir alguna informaci6n de la tabla OFICINAS:
Listar los nombres y edades de los representantes que trabajan en las oficinas de la regin oeste y las ciudades en que trabajan. la forma de subconsulta no funcionar y se deber usar la consulta de dos tablas. A la inversa, muchas consultas con subconsultas no se pueden traducir a una reunin equivalente. A continuacin se muestra un ejemplo simple: Listar los nombres y edades de representantes que estn por encima de la cuota media.
SELECT NOMBRE, EDAD FROM REPRESENTANTES WHERE CUOTA> (SELECT AVG(CUOTA) FROM REPRESENTANTES) NOMBRE Bruno Arteaga Susana Santos Le6n Freire EDAD 37 48 62
FROM REPRESENTANTES WHERE OFICINA_REP IN (SELECT OFICINA FROM OFICINAS WHERE REGION = 'Este'j) EMPRESA Filas sierras S.A. AAA Inversiones JCP S.A. Chen Asoc iados QMA Asociados bero &< Sagaz Acme
En este ejemplo, la subconsulta ms interna:

SELECT OFICINA FROM OFICINAS WHERE REGION = 'Este'
produce una columna que contiene los nmeros de oficina de las oficinas de la regin este. La siguiente subconsulta:
SELECT NUM_EMPL FROM REPRESENTANTES WHERE OFICINA_REP IN (subconsulta)
En este caso, la consulta interna es una consulta de resumen, mientras que la externa no, por lo qu~ no hay fonna de que las dos consultas se puedan combinar en llna nica reunin.
Subconsultas anidadas
Todas las consultas descritas hasta ahora en este captulo tienen consultas de dos niveles, y contienen una consulta principal y una subconsulta. Al igual que se puede usar una subconsulta dentro de una consulta principal, se puede usar una subconsulta dentro de otra subconsulta. A continuacin se muestra un ejemplo de una solicitud que se representa de fonna natural como una consulta de tres niveles. con una consulta principal, una subconsulta y una sub-subconsulta:
Listar los clientes cuyos representantes estn asignados a oficinas de la regin de ventas este.
SELECT EMPRESA FROM CLIENTES WHERE REP_CLI IN (SELECT NUM_EMPL
produce una columna que contiene los nmeros de empleado de los representantes que trabajan en una de las oficinas seleccionadas. Finalmente. la consulta ms exterior:
SELECT EMPRESA FROM CLIENTES WHERE REP_CLI IN (subconsultaj
detennina los clientes cuyos representantes tienen uno de los nmeros de empleado seleccionados. La misma tcnica usada en esta consulta de tres niveles se puede usar para construir consultas con cuatro o ms niveles. El estndar SQL de ANSIIISO no especifica un nmero mximo de niveles de anidamiento, pero en la prctica una consulta llega a consumir mucho tiempo al aumentar el nmero de niveles. La consulta tambin llega a ser difcil de leer, comprender y mantener cuando contiene ms de uno o dos niveles de subconsultas. Muchas implementaciones de SQL restringen el nmero de niveles de subconsulta a un nmero relativamente pequeo.
228
229
Subconsultas correlacionadas*
Conceptualmente, SQL resuelve una subconsulta una y otra vez -una por cada fila de la consulta principal-. Para muchas subconsultas, sin embargo, la subconsulta produce los mismos resultados para cada fila o grupo de filas. A continuacin se muestra un ejemplo:
Listar las oficinas de ventas cuyas yemas eslll por debajo del objetivo medio.
SELECT CIUDAD PROM OFICINAS WHERE VENTAS < (SELECT AVG(OBJETIVO) FROM OFICINAS)
CIUDAD
Daimiel Almeria
En esta consulta no sera muy inteligente realizar la subconsulta cinco veces (una vez por cada oficina). El objetivo medio no cambia con cada oficina; es completamente independiente de la oficina que se est comprobando actualmente. Como resultado, SQL puede manejar la consulta resolviendo primero la subconsulta, dando el objetivo medio (550.000 ) Ydespus convirtiendo la consulta principal en:
SELECT CIUDAD FROM OFICINAS WHERE VENTAS < 550000.00
referencia externa) tiene un valor diferente. Por tanto, SQL no tiene otra alternativa que resolver esta subconsulta cinco veces -una por cada fila de la tabla OFICINAS. Una subconsulta que contiene una referencia externa se denomina subconsulta correlacionada porque sus resultados estn correlacionados con cada fila individual de la consulta principal. Por el mismo motivo, una referencia externa se conoce a veces como referencia correlacionada. Una subconsulta puede contener una referencia externa a una tabla de la clusula FROM de cualquier consulta que contenga la subconsulta, independientemente de la profundidad en que se aniden las subconsultas. Un nombre de columna en una subconsulta de cuarto nivel, por ejemplo, puede hacer referencia a una de las tablas listadas en la clusula FROM de la consulta principal, o a una tabla listada en la clusula FROM de la consulta de segundo o tercer nivel que la contiene. Independientemente del nivel de anidamiento, una referencia externa siempre toma el valor de la columna en la fila en curso de la tabla que se est comprobando. Dado que una subconsulta puede contener referencias externas, hay incluso ms posibilidades de nombres de columna ambiguos en una subconsulta que en una consulta principal. Cuando un nombre de columna no calificado aparece dentro de una subconsulta, SQL debe determinar si se refiere a una tabla de la clusula FRQM de la propia subconsulta o de la clusula FROM de la consulta que contiene a la subconsulta. Para minimizar esta posibilidad de confusin, SQL siempre interpreta una referencia a columna en una subconsulta usando la clusula FROM posible ms prxima. Para ilustrarlo, en este ejemplo se usa la misma tabla en la consulta y en la subconsulta:
Listar los representantes mayores de 40 aos y que dirigen a un representante que supere su cuota.
SELECT FROM WHERE AND NOMBRE REPRESENTANTES EDAD > 4 o NUM_EMPL IN (SELECT JEFE FROM REPRESENTANTES WHERE VENTAS > CUOTA)
Las implementaciones comerciales de SQL detectan automticamente esta situacin y usan este atajo siempre que es posible para reducir la carga de procesamiento requerido por una subconsulta. Sin embargo. el atajo no se puede usar si la subconsulta contiene una referencia exterior, como en este ejemplo:
Listar todas las oficinas cuyos objetivos excedan la suma de las cuotas de los representantes que trabajan en ellas:
SELECT CIUDAD FROM OFICINAS WHERE OBJETIVO>
NOMBRE
Samuel Clavel
Len Freire
(SELECT SUM(CUOTA) FROM REPRESENTANTES WHERE OFICINA_REP = OFICINA)
CIUDAD
Castelln
Len
Por cada fila de la tabla OFICINAS a comprobar en la clusula WHERE de la consulta principal, la columna OFICINA (que aparece en la subconsulta como una
Las columnas JEFE, CUOTA Y VENTAS de la subconsulta son referencias a la tabla REPRESENTANTES de la clusula FRQM de la propia subconsulta; SQL no . las interpreta como referencias externas y la subconsulta no es una subconsulta correlacionada. SQL puede resolver la subconsulta en primer lugar en este caso, hallando los representantes que superan su cuota y generando una lista de los nmeros de empleado de sus jefes. SQL puede centrar su atencin ahora en la consulta principal, seleccionando los jefes cuyos nmeros de empleado aparecen en la lista generada. Si se desea usar una referencia externa dentro de una subconsulta como la del ejemplo anterior. se debe usar un alias de tabla para forzar
230
231
la referencia externa. Esta solicitud, que aade una condicin ms a la anterior, muestra cmo hacerlo:
re
Sil
Listar los jefes mayores de 40 aos y que dirigen a un representante que supecuota y que no trabaje en la misma oficina de ventas que el jefe.
. SELECT NOMBRE
FROM REPRESENTANTES JEFES

WHERE EDAD> 40
AND JEFES.NUM_EMPL IN (SELECT JEFE FROM REPRESENTANTES EMPS WHERE EMPS.CUOTA > EMPS.VENTAS AND EMPS.OFICINA_REP <> JEFES.OFICINA_REPl NOMBRE
samuel Clavel Len Freire
La copia de la tabla REPRESENTANTES usada en la consulta principal tiene ahora la etiqueta JEFES, y la copia de la subconsulta tiene la etiquet~ EMPS. La su~bcon sulla contiene una condicin de bsqueda adicional, que reqUIere que el numero de oficina del empleado no coincida con el del jefe. El nombre de columna calificado JEFES. OFICINA de la subconsulta es una referenci~ externa, y esta subconsulta es correlacionada.
La Figura 9.7 muestra conceptualmente cmo funciona esta consulta. La subconsu Ita calcula la media general del importe de los pedidos. Es una subconsulta simple y no contiene referencias externas, as que SQL puede calcular la media una vez y despus usarla repetidamente en la clusula HAVING. La consulta principal recorre la tabla PEDIDOS, hallando todos los pedidos de los productos ACI, y agrupndolos por representante. La clusula HAVING comprueba a continuacin cada grupo de filas para ver si el pedido medio en ese grupo es mayor que la media de todos los pedidos, calculada anteriormente. Si es as, el grupo de filas se conserva; si no, el grupo de filas se descarta. Finalmente, la clusula SELECT produce una fila de resumen para cada grupo, mostrando el nombre del representante y el importe medio de los pedidos de cada uno. Tambin se puede usar una subconsulta correlacionada en la clusula HAVING. Dado que la subconsulta se evala una vez por cada grupo de filas, sin embargo, todas las referencias externas de la subconsulta correlacionada deben tener un solo valor en cada grupo de filas. Efectivameme esto significa que la referencia externa debe ser a una referencia a una columna de agrupacin de la consulta externa, O estar contenida en una funcin de columna. En el ltimo caso, el valor de la funcin de columna del grupo de filas que se comprueba se calcula como parte del procesamiento de subconsultas.
Tlbla REPRESENTAm'ES
Tabla PEDlOOS
Subconsultas en la clusula HAVING*

Aunque las subconsultas se encuentran a menudo en la clusula WHERE, tambin se pueden usar en la clusula HAVING de una consulta. Cuando. aparece una subconsulta en la clusula HAVING, funciona como parte de la seleccIn de grupos de filas realizada por la clusula HAVING. ~onsidrese esta consulta con una subconsulta:
JOIN
GROUP
"
Tabla AGRUPADA NUliJ'EDlOO
112!168 113055
Listar los representantes cuyos importes medios de pedidos para los productos fabricados por AC/ sea superior al importe medio de los pedidos.
SELECT FROM WHERE AND GROUP HAVING NOMBRE, AVG(IMPORTE) REPRESENTANTES, PEDIDOS NUM_EMPL = REP FAB = 'ACI' BY NOMBRE AVG(IMPORTE} > (SELECT AVG(IMPORTE) FROM PEDIDOS) AVG(IMPORTE) lS.OOO,OO 22.S00,OO
""""" Rui~:: Daniel

Daniel Ruidr
anu>o ArlOe"v" Bruno ArlOe"g" Bruno ArlOeaa
",. ..," "" 1<

~,
Tabla PEDlOOS
3.978.110E 150.011E
"""""
112963 112983 112981 113012 113027
~,
:~:~ ~~~::~:
'"
~,
'" 1<
~)
3.216.1111 1112.1111 27.51111.011 3.745,01l 4 .1114 OO
NOMBRE
Susana Santos Toms Saz
Figura 9.7.
Funcionamiento de la subconsulta en la clusula HAVING.
1L
232
saL.
233
HAVING
Si la solicitud anterior se cambia ligeramente, la subconsulta de la clusula se convierte en una subconsulta correlacionada:
Listar lodos los representantes cuyos importes medios de pedidos para los profabricados por AC/ sean al menos como el importe medio general de los pedidos del representante.
dUCIOS
SELECT NOMBRE, AVG(IMPORTE) FROM REPRESENTANTES, PEDIDOS WHERE NUM_EMPL = REP ANO FAS = 'ACI' GROUP BY NOMBRE, NUM_EMPL HAVING AVG(IMPORTE) >= (SELECT AVG(IMPORTE)
FROM PEDIDOS
La forma de subconsulta del test de pertenencia a conjuntos (IN) compara un valor de test con el conjunto de valores que devuelve la subconsulta. El test de existencia (EXISTS) comprueba si una subconsuha devuelve algn valor. Los tests cuantificados (ANY y ALL) usan uno de los operadores simples de comparacin para compara un valor de test con todos los valores devuehos por la subconsulta, comprobando si se cumple la comparacin para alguno o para todos los valores. Una subconsuha puede incluir una referencia externa a una tabla en cual quiera de las consultas que la contienen, vinculando la subconsulta a la fila actual de la consulta. La Figura 9.8 muestra la versin final de las reglas para el procesamienlo de. consultas SQL, extendidas para incluir subconsultas. Proporciona una definicin completa de los resultados producidos por una instruccin SELECT.
WHERE REP = NUM_EMPLl NOHBRE

Bruno Arteaga susana Santos
AVG (IMPORTE)
7.B65,4a
15.00Q,QO
Toms Saz
22.S00,OO
Para generar los resultados de una consulta de una instruccin SELECT: 1. Si la instruccin es la UNION de instrucciones SELECT, aplicar los pasos del 2 al 7 a cada una de las instrucciones para generar sus resultados individuales. 2. Formar el producto de las tablas listadas en la clausula FROM. Si la clusula FROM lista una nica tabla, el producto es esta tabla. 3. Si hay una clusula WliERE, aplicar su condicin de bsqueda a cada fila de la tabla pro ducto, conservando las filas para las que la condicin de bsqueda es TRUE (y descartando aquellas para las que la condicin es F....LSE o NULL). Si la clusula H ....VING contiene una subconsulta, sta se ejecuta por cada fila que se este comprobando. 4. Si hay una clusula GROUPBY, organizar las filas restantes de la tabla producto en dos grupos, de forma que las filas de cada grupo tengan identicos valores en todas las columnas de agrupacin. 5. Si hay una clausula HAVING. aplicar su condicin de bsqueda a cada grupo de filas, conservando los grupos para los que la condicin de bsqueda es TRUE (y descartando aqullos para los que la condicin es FALSE o NULL). Si la clusula HAVING contiene una subconsulta, sta se ejecuta por cada fila que se est comprobando. 6. Para cada fila restante (o grupo de filas), calcular el valor de cada elemento de la lista de seleccin para producir una nica fila de resultados. Para una referencia a columna simple, usar el valor de la columna en la fila actual (o grupo de filasl. Para una funcin de columna, usar el grupo actual de filas como argumento si se especific GROUP BY; en caso contrario, usar el conjunto completo de resultados. 7. Si se especifica SELECT DISTINCT, eliminar cualquier fila duplicada que se haya producido en el resultado. 8. Si la instruccin es una UNION de instrucciones SELECT, mezclar los resultados de la consulta de las instrucciones individuales en una nica tabla de resultados. Eliminar las fijas duplicadas a menos que se especifique UNION ALL. 9. Si hay una clusula aRDER BY, ordenar los resultados de la consulta como se especifique. las filas generadas por este procedimiento forman los resultados de la consulta.
En este nuevo ejemplo, la subconsulta debe producir un importe medio general de pedidos para el representante cuyo grupo de filas se est comprobando en el momento en la clusula HAVING. La subconsulta selecciona pedidos para ese representante en concreto, usando la referencia externa NUM_EMPL. La referencia externa es legar porque NUM_EMPL tiene el mismo valor en todas las filas de un grupo producidas por la consulta principal.
Resumen de fas subconsuftas

Este captulo ha descrito las subconsultas, que permiten usar los resultados de una consulta para ayudar en la definicin de otra. Antes de continuar con las consultas avanzadas de la especificacin SQL2, se resumirn las subconsultas: Una subconsulta es una consulta dentro de otra. Las subconsultas aparecen dentro de las condiciones de bsqueda de las subconsultas en la clusula WHERE o HAVING. Cuando aparece una subconsulta en la clusula WHERE, los resultados de la subconsulta se usan para seleccionar filas individuales que aportan datos a los resultados de la consulta. Cuando aparece una subconsulta en una clusula HAVING, los resultados de la subconsulta se usan para seleccionar los grupos de filas que aportan datos a los resultados de la consulta. Las subconsultas se pueden anidar dentro de otras_ La forma de subconsulta del test de comparacin usa uno de los operadores simples de comparacin para contrastar un valor de test con el nico valor que devuelve la subconsulta.
Figura 9.8.
Reglas de procesamiento de consultas SOL (versin final).
234
235
Consultas avanzadas en SQL2*

Las consultas SQL descritas hasta aqu en los captulos 6 al 9 son las caractersticas principales proporcionadas por la mayora de implementaciones SQL. La combinacin de caractersticas que representan -la seleccin de columnas en la clusula SELECT, el criterio de seleccin de filas de la clusula WHERE, las reuniones mullitabla de la clusula FROM, las consultas de resumen en las clusulas GRQUP BY y HAVING. y las subconsulLas para solicitudes ms complejas- dan al usuario un potente conjunto de posibilidades de recuperacin y anlisis de datos. Sin embargo, los expertos en bases de datos han indicado varias limitaciones de estas caractersticas, incluyendo las siguientes: No hay toma de decisiones dentro de las subconsultas. Supngase que se desea generar un informe de dos columnas de la base de dalOs de ejemplo que muestre el nombre de cada oficina de ventas, as como el objetivo de ventas anual o las ventas del ao, segn el que sea mayor. Con las caractersticas estndar de las consultas es difcil de hacer. O bien supngase que se tiene una base de datos que almacena las ventas por trimestre (cuatro columnas de datos para cada oficina) y que se desea escribir un programa que muestre oficinas y sus ventas por cuatrimestre (especificado por el usuario). De nuevo, este programa es ms difcil de escribir usando consultas SQL estndar. Se debe incluir cuatro consultas SQL separadas (una por cada trimestre) y el programa debe seleccionar la consulta a ejecutar en trminos de la entrada del usuario. Este caso simple no es muy difcil, pero en un caso ms general, el programa podra llegar a ser ms complejo. Uso limitado de subconsultas. El ejemplo ms simple de esta limitacin es la restriccin de SQLI que establece que una subconsulta slo puede aparecer en el lado derecho de un test de comparacin en una clusula WHERE. La solicitud a la base de datos listar las oficinas donde la suma de las cuotas de los representantes sea superior al objetivo de la oficina se expresa de forma ms directa con esta consulta:
SELECT OFICINA FROM OFICINAS WHERE (SELECT SUM{CUOTA) FROM REPRESENTANTES WHERE OFICINA_REP ~ OFICINA)
En este simple ejemplo no es difcil invertir la lgica, pero la restriccin es cuando ~enos una molestia, e impide comparar los resultados de dos subconsultas, por ejemplo. Expresio~es de fila Ii~itadas. Supngase que se desea listar los proveedores, los ~umeros de articulos y los precios de un conjunto de productos que son SUStI~utos .unos .de otros. Conceptualmente, son un conjunto de productos ~uya IdentIficaCIn (un par ID fabricante I ID producto) coincide con un conjunto de valores y sera natural escribir la consulta usando un test de pertenencia a conjuntos como:
SELECT ID_FAB, ID_PRODUCTO, PRECIO FROM PRODUCTOS WHERE 1ID_FAB , ID_PRODUCTO) IN (('ACI',41003),('BIC',41089),_ ... )
El estndar SQLl no penn~te esta clase de test de pertenencia a conjuntos. En su lugar se debe construlf la consulta como un gran conjunto de comparaciones individuales conectadas con AND y DR. Expresiones de tabla limitadas. SQL permite definir una vista como sta para grandes pedidos:
SELECT FROM PRODUCTOS WHERE IMPORTE > 10000
y despus usar la vista como si fuera una tabla real en la clusula FROM de una consulta para detenninar los productos y cantidades que fueron fonnulados en estos grandes pedidos:
SELECT FAB, PRODUCTO, SUM(CANTIDADj FROM PEDIDOSGRANDES GROUP BY FAB, PRODUCTO
Conceptualmente, SQL permitira que se sustituyese la definicin de la vista en la consulta, como en:
SELECT FAS, PRODUCTO, SUM(CANTIDAD) FROM (SELECT * FROM PEDIDOS WHERE IMPORTE > 10000) GROUP BY FAB, PRODUCTO
>
OBJETIVO
Pero sta no es una instruccin SQLI legar. En su lugar hay que dar la vuelta a la desigualdad:
SELECT OFICINA FROM OFICINAS WHERE OBJETIVO
<
ISELECT SUM(CUOTA) FROM REPRESENTANTES WHERE OFICINA_REP ~ OFICINA)
Pero el estndar SQLI no permite una subconsulta en esta posicin de la clusula WHERE. Ms claramente, el SGBD debera ser capaz de determinar el significado .de esta consulta, dado que debe hacer bsicamente el mismo procesamiento para Interpretar la definicin de la vista PEDIDOSGRANDES. . Como m~estran estos ejemplos, el estndar SQLl y los productos SGBD prinCIpales que Implementan este nivel del estndar son relativamente restrictivos en su ~so permitido de expresiones que contengan elementos individuales de datos, con~u~~os de elementos de datos, filas y tablas. El estndar SQL2 incluye varias pOSIbIlIdades de consultas avanzadas que se centran en la eliminacin de estas
236
Capitulo 9: Subconsultas y expresiones de consultas
237
restricciones y en hacer ms general el lenguaje SQL. El espritu de estas caractersticas de SQL2 tiende a ser que un usuario sea capaz de escribir una expresin de consulta que tenga sentido y que la expresin de consulta sea una consulta legal. Dado que estas capacidades de SQL2 constituyen la expansin principal del lenguaje sobre el estndar SQL 1, la mayora de ellas se requieren slo en el nivel completo del estndar.
Expresiones escalares (50L2)

Las capacidades de consultas extendidas de SQL2 son las que proporcionan ms potencia de manipulacin y clculo de datos entre valores de datos individuales (denominados escalares en el estndar SQL2). Dentro del lenguaje SQL, los valores de datos individuales tienden a tener tres fuentes: El valor de una columna individual dentro de una fija individual de una tabla. Un valor lileral, como 125.7 o ABC. Un valor definido por el usuario, introducido en un programa. En esta consulta SQL:
SELECT NOMBRE, NUM_EMPL, FECHA_CONTRATO, (CUOTA * FROM REPRESENTANTES WHERE (OFICINA_REP = 13) OR PUESTO = 'VP VENTAS' .9)
menle tipos de datos similares, como los enteros de 2 y 4 bytes. Sin embargo, si se intenta comparar los datos numricos y de caracteres, por ejemplo, el estndar dice que el SGBD debera generar un error. El estndar considera que esto es una condicin de error incluso si la cadena de caracteres contiene datos numricos. Se puede, sin embargo, pedir explcitamente que el SGBD convierta tipos de datos usando la expresin CAST, cuya sintaxis se muestra en la Figura 9.9. La expresin CAST tiende a tener poca importancia cuando se estn escribiendo directamente instrucciones en una interfaz interactiva de SQL. Sin embargo, puede ser crtico cuando se use SQL desde un lenguaje de programacin cuyos lipos de datos no coincidan con los tipos de datos incluidos por el estndar SQL. Por ejemplo, la expresin CAST de la clusula SELECT de esta consulta convierte los valores de OFICINA~REP (enteros en la base de datos de ejemplo) y FECHA_CONTRATO (una fecha en la base de datos de ejemplo) en cadenas de caracteres para los resultados de la consulta:
SELECT NOMBRE, CAST OFICINA_REP AS VARCHAR, FROM REPRESENTANTES FECHA_CONTRATO AS VARCHAR
La expresin CAST puede aparecer generalmente en cualquier lugar en el que pueda aparecer una expresin escalar en una instruccin SQL. En este ejemplo ~e usa en la clusula WHERE para convertir un nmero de cliente en cadena de caracteres en un entero, de forma que se pueda comparar con los datos de la base de datos:
SELECT PRODUCTO, CANTIDAD. IMPORTE PROM PEDIDOS WHERE CLIENTE = CAST '2107' AS INTEGER
los nombres de columna NOMBRE, NUM_EMPL, FECHA_CONTRATO Y CUOTA generan valores de datos individuales por cada fila de resultados, como lo hacen los nombres de columna OFICINA_REP y PUESTO en la clusula WHERE. Los nmeros 9 y 13 Yla cadena de caracteres VP VENTAS generan, de forma similar, valores de datos individuales. Si esta inslruccin SQL apareciese dentro de una programa SQL incorporado (descritos en el Captulo 17), la variable de programa num_oficina podra contener un valor de datos individual, y la consulta podra se como:
SELECT NOMBRE, NUM_EMPL, FECHA_CONTRATO, (CUOTA * .9) FROM REPRESENTANTES WHERE (OFICINA_REP = :num_oficina) OR PUESTO = 'VP VENTAS'
En lugar de especificar un tipo de datos en la expresin CAST, se puede especificar un dominio SQL2. Los dominios son colecciones especficas de valores de datos legales que se pueden definir en la base de datos bajo el estndar SQL2. Se describen completamente en el Captulo 11 debido al papel que desempean en la inlegri dad de datos de SQL. Ntese que tambin se puede generar un valor NULL del tipo de datos apropiado para usar en las expresiones SQL usando la expresin CASTo Los usos ms comunes de la expresin CAST son: Convertir datos de una tabla de la base de datos en la que se define la colum na con el tipo de datos incorrecto. Por ejemplo, cuando se define una columna
Como han mostrado esta consulta y muchos ejemplos anteriores, los valores de datos individuales se pueden combinar en expresiones simples, como el valor calculado CUOTA * .9. Para estas expresiones SQLl bsicas, SQL2 aade el operador CAST para la conversin explcita de datos, el operador CASE para la toma de decisiones, la operacin NULLIF para crear condicionalmente un valor NULL, y el operador COALESCE para crear condicionalmeme valores distintos de NULL.
La expresin CAST (SQL2)
f---CAST
(TeXP'e5'n-de-vaIO'T
NULL
AS
T'ipa-da-da,as})
~.
Lnomb~e-.dedomIniO
El estndar SQL tiene reglas bastante restrictivas sobre la combinacin de datos de tipos diferentes en expresiones. Especifica que el SGBD convertir automtica-
Figura 9.9.
Diagrama sintctico de la expresin CAST de SQL2.
238
Captulo 9: Subconsu/tas y expresiones de consultas
239
como una cadena de caracteres, pero se sabe que realmente contiene nmeros (es decir, cadenas de dgitos) o fechas (cadenas que se pueden interpretar como da/mes/ao). Convertir datos de tipos de datos albergados por el SGBD que no son admilidos por el lenguaje de programacin anfitrin. Por ejemplo, la mayora de lenguajes de programacin anfitriones no tienen tipos de datos explcitos para la fecha y la hora, y requieren que los valores de fecha/hora se conviertan en cadenas de caracteres que maneje el programa. Eliminar diferencias entre tipos de datos de dos tablas diferentes. Por ejem~ pIo, si una fecha de un pedido se almacena en una tabla como datos DATE, pero la fecha de disponibilidad se almacena en una tabla diferente como una cadena de caracteres, todava se pueden comparar las columnas de las dos tablas aplicando CAST sobre una de las columnas para obtener el tipo de datos de la otra. De forma similar, si se desea combinar datos de dos tablas diferentes con una operacin UN10N, sus columnas deben tener tipos de datos idnticos. Esto se puede conseguir con el uso de CAST en las columnas de una de las tablas.
La expresin CASE (SQL2)
crdito y asignar una clasificacin A, B o C. Al usar la expresin puede hacer que el SGBD haga el trabajo:
CASE
de SQL2 se
SELECT EMPRESA, CASE WHEN LIMITE_CREDITO > 60000 THEN 'A' WHEN LIM1TE_CREDITO > 30000 THEN '8' EL SE 'c' PROM CLIENTES
La expresin CASE de SQL2 proporciona una toma de decisiones limitada dentro de expresiones SQL. SU estructura bsica, mostrada en la Figura 9.10, es similar a la instruccin 1F ... THEN ... ELSE que se encuentra en muchas lenguajes de programacin. Cuando el SGBD encuentra una expresin, evala la primera condicin de bsqueda, y si es TRUE, entonces el valor de la expresin CASE es el yalor de la primera expresin resultado. Si el resultado de la primera condicin de bsqueda no es TRUE, el SGBD procede con la segunda condicin de bsqueda y comprueba si es TRUE. Si lo es, el valor de la expresin CASE es el valor de la segunda expresin resultado, y as sucesivamente, A continuacin se estudia un ejemplo simple del uso de la expresin CASE. Supnganse que se desea un anlisis AlBIC de los clientes de la base de datos de ejemplo de acuerdo con sus lmites de crdito. Los clientes A son los que tienen lmites de crdito superiores a 60.000 , los clientes B son los que tienen lmites de crdito superiores a 30.000 , Y los clientes e son el resto. Al usar SQL1, habra que obtener los nombres de cliente y los lmites de crdito de la base de datos y despus usar un programa de aplicacin que buscase los valores de los lmites de
Por cada fila de resultados, el SOBD evala la expresin CASE comparando primero el lmite de crdito de 60.000, y si la comparacin es TRUE, devuelve A en l~ segunda columna de los resultados" Si la comparacin falla, se hace la comparacin con 30.000 y se devuelve B si esta segunda comparacin es TRUE. En caso contrario, la tercera columna de los resultados contendr C ste es un ejemplo muy simple de la expresin CASE". Los resultados de la expresin CASE son lodos literales aqu, pero en general pueden ser cualquier expresin SQL. De forma anloga, no hay requisito respecto a que las comprobaciones en cada clusula WHEN sean similares, como lo son aqu. La expresin CASE tambin puede aparecer en otras clusulas de una consulta. A continuacin se muestra un ejemplo de una consulta donde es til en la clusula WHERE. Supngase que se desea halJar el total de las ventas de los representantes por oficina. Si un representante no ha sido asignado an a una oficina, esa persona debera eslar incluida en el total de la oficina de su jefe. A continuacin se muestra una consulta que genera las agrupaciones adecuadas de oficinas:
SELECT CIUDAD, SUM{VENTAS} FROM OFICINAS, REPRESENTANTES WHERE OFICINA CASE WHEN (OFICINA_RtP 1S NOT NULL) THEN OFIC1NA_REP ELSE (SELECT OFICINA_REP FROM REPRESENTANTES AS JEFES WHERE JEFES,NUM_EMPL = JEFE)
El estndar SQL2 proporciona una versin abreviada de la expresin CASE para la situacin habitual en la que se desea comparar un valor de alguna clase con una secuencia de valores de datos (usualmente literales), Es(a versin de la sintaxis de CASE se muestra en]a Figura 9.11. En lugar de repelir una condicin de bsqueda de la forma: valor_de_comprobacin ;:: valor]
1- CASE -
WHEN
condicin-debsqueda
THEN T
expresinresultado
-.r-------,.,----.... expresinELSE , - - resultado L - NULL
t- CASE _ comprobaclon valor-de-..
CASE valor THEN.,- resultado -;rr-----::==;:--...
expresin-
' - NULL
L-
NULL
ELSE
-r- resultado
l-NULL
expresin-
Figura 9.10.
Diagrama sintctico de la expresin CASE de SQL2.
Figura 9,11.
Sintaxis alternativa de la expresin CASE de SOL2.
240
241
en cada clusula WHEN, permite especificar una sola vez el clculo valor_de_comprobacin. Por ejemplo supngase que se desea generar una lista de todas las oficinas mostrando los nombres de sus jefes y las ciudades y provincias en las que estn ubicados. La base de datos de ejemplo no incluye los nombres de las provincias, por lo que la consulm debe generar esta informacin por s misma. A conti-
el valor de la expresin COALESCE. Si el primer valor es NULL, el SGBD va al segundo valor y comprueba si es NULL. Si no lo es, es el valor de la expresin. En caso contrario, el SGBD va al tercer valor, y as sucesivamente. A continuacin se muestra el mismo ejemplo anterior expresado mediante COALESCE, en lugar de con la expresin CASE:
SELECT NOMBRE, COALESCE (CUOTA, VENTAS, PROM REPRESENTANTES 0.00)
nuacin se muestra una consulta con una expresin

hace el trabajo:
SELECT NOMBRE, CIUDAD, CASE OFICINA WHEN WHEN WHEN WHEN WHEN FROM OFICINAS, REPRESENTANTES WHERE JEF = NUM_EMPL 11 12 13 21 22
CASE
en la lista
SELECT
que
THEN THEN THEN THEN THEN
'Navarra' 'Sevilla' 'Barcelona' 'cdiz' 'Madrid'
Como se puede ver comparando las dos consultas, la simplicidad de la sintaxis de COALESCE hace que el significado de la consulta sea ms sencillo de ver en un primer vistazo. Sin embargo, la operacin de las dos consultas es idntica. La expresin COALESCE aade simplicidad, pero no nuevas capacidades al lenguaje SQL2.
La expresin NULLIP SQL2)
La expresin COALESCE SQL2)
Uno de Jos usos ms comunes de la capacidad de toma de decisiones de la expresin CASE es el manejo de valores NULL dentro de la base de datos. Por ejemplo. a menudo es deseable tener un valor NULL de la base de datos representado por algn valor literal (tal como la palabra ausente) o por algn valor predeterminado cuando se use SQL para generar un informe. A continuacin se muestra un informe que lista los representantes y sus cuotas. Si un representante no tiene an asignada una cuota, se asume que se debe listar en su lugar las ventas actuales del representante. Si por alguna razn las ventas actuales fuesen tambin NULL (desconocidas), se debera listar un importe de O. La instruccin CASE genera la lgica IF ... TREN ... ELSE deseada:
SELECT NOMBRE, CASE WHEN (CUOTA IS NOT NULL) THEN CUOTA WHEN (VENTAS IS NOT NULL) THEN VENTAS ELSE 0.00 FROM REPRESENTANTES
Este tipo de lgica de gestin de valores NULL se necesita frecuentemente, as que el estndar SQL2 incluye una forma especializada de la expresin CASE, la expresin COALESCE, para ello. La sintaxis de la expresin COALESCE se muestra en la Figura 9.12. Las reglas de procesamiento de la expresin COALESCE son muy sencillas. El SOBD examina el primer valor de la lista. Si su valor no es NULL, es
Si bien la expresin COALESCE se usa para eliminar valores NULL cuando no se desean para el procesamiento, a veces es necesario crear valores NULL. En muchas aplicaciones de procesamiento de datos (especialmente algunas antiguas desarro lladas antes de que las bases de datos relacionales fueran populares), los datos ausentes no se representaban con valores NULL. En su lugar se utilizaba un cdigo especial que se usa para indicar que el dato estaba ausente. Por ejemplo, supngase, en la base de datos de ejemplo, la situacin en la que un representante no tuviese an asignado un jefe se indica con un valor de cero (O) en la columna JEFE en lugar de un valor NULL. En algunas circunstancias se puede desear detectar esta situacin en una consulta SQL y sustituir ese valor NULL por el cdigo cero. La expresin NULLIF, mostrada en la Figura 9.13, se usa para este propsito. Cuando el SGBD encuentra una expresin NULLIF, examina el primer valor (usualmente, un nombre de columna) y lo compara con el segundo valor (usualmente, el valor usado para indicar los datos ausentes). Si los dos valores son iguales, la expresin genera un valor NULL. En caso contrario. la expresin genera el primer valor. A continuacin se muestra una consulta que maneja el caso en el que los nmeros ausentes de oficina se representan con un cero:
SELECT FROM WHERE GROUP CIUDAD, SOM(VENTASl OFICINAS, REPRESENTANTES OFICINA ~ (NULLIF OFICINA_REP, BY CIUDAD
O)
t-COALESCE (C~:::...==r)
.
Figura 9.13.
t-NULLIF(C:::==rl
Figura 9.12.
Diagrama sintctico de la expresin COALESCE de SOL2.
Diagrama sintctico de la expresin NULLIF de SOL2.
242
243
En conjunto. las expresiones CASE, COALESCE y NULLIF proporcionan una slida capacidad de toma de decisiones para su uso en las instrucciones SQL. No proporcionan toda la potencia de las constructoras de flujo de control aportadas por la mayora de lenguajes de programacin (bucles, bifurcaciones, etc.), pero s una gran flexibilidad en las expresiones de consulta. El resultado neto es que el SaBD puede hacer ms trabajo de procesamiento, reflejndose en los resultados de las consultas, y dejando menos trabajo para el usuario humano o el programa de aplicacin.
, ,
(1exp,"s:~:~.vaJO' )~.
CEFAULT
,
I--------,-expresin-de-valor.---------l
-NULL-
Expresiones de filas (SQL2)

Aunque las columnas y los valores de datos escalares que contienen son los bloques constructores de una base de datos relacional, la estructuracin de columnas en filas que representan entidades del mundo real, tales como oficinas individuales, clientes o pedidos, es una de las ms importantes caractersticas del modelo relacional. El estndar SQLl, y la mayora de los principales productos comerciales de bases de datos, reflejan ciertamente esta estructura fila/columna, pero pro-porcionan una capacidad muy limitada para manipular realmente filas y grupos de filas. Bsicamente, las operaciones SQLl permiten insertar una fila en una tabla, o recuperar, actualizar o eliminar grupos de filas de una base de datos (usando las instrucciones SELECT, UPDATE o DELETE). El estndar SQL2 va ms all de estas capacidades, permitiendo utilizar generalmente filas en las expres"iones SQL de forma muy parecida al uso de valores escalares. Proporciona una sintaxis para construir filas de datos. Permite subconsultas que devuelven filas. Y define significados de filas para los operadores de comparacin SQL y otras estructuras SQL.
La constructora de filas (SQL2)
-DEFAULT-
' - - - - - - subconsulta-que-devuelve-filas - - - - - - - '
Figura 9.14.
Diagrama sintctico de la constructora de filas de SQL2.
Cuando una constructora de filas se usa en la clusula WHERE de una instruccin SQL, los nombres de columna tambin pueden aparecer como elementos de datos individuales dentro de la constructora de filas o como parte de una expresin dentro de la constructora de filas. Por ejemplo, considrese esta consulta:
Listar el mmero de pedido, la cantidad y el importe de todos los pedidos de zapatas ACI-41002.
SELECT NUM_PEDIDO, CANTIDAD, IMPORTE FROM PEDIDOS WHERE (FAB, PRODUCTO) '" ('ACI', '41002')
SQL2 permite especificar una fila de valores de datos usando una constructora de filas, cuya sintaxis se muestra en la Figura 9.14. En su forma ms habitual. la constructora de filas es una lista separada por comas de valores literales o expresiones. Por ejemplo, a continuacin se muestra una constructora de filas para una fila de datos cuya estructura coincide con la tabla OFICINAS de la base de datos de ejemplo:
(23, 'San Diego', 'Oeste', NULL, DEFAULT, 0.00)
El resultado de esta expresin es una nic~ fila de datos con seis columnas. La palabra clave NULL en cuarta posicin indica que la cuarta columna de la fila cons. truida debe contener una valor NULL (desconocido). La palabra clave DEFAULT de la quinta posicin indica que la quinta fila construida debera contener el valor predeterminado de la columna. Esta palabra clave puede aparecer en una constructora de filas s6lo en ciertas situaciones -por ejemplo, cuando la constructora aparece en una instruccin ISERT para aadir una nueva fila a una tabla.
Bajo las reglas nonnales del procesamiento de consultas SQL, la clusula WHERE se aplica a cada fila de la tabla PEDIDOS, una a una. La primera constructora de la clusula WHERE (a la izquierda del signo igual) genera una fila de dos columnas que contiene el cdigo de fabricante y el nmero de producto del pedido considerado en ese momento. La segunda constructora (a la derecha del signo igual) genera una fila de dos columnas que contiene el cdigo (literal) del fabricante ACI y el nmero de producto 41002. El signo igual compara ahora dos filas de valores, no dos valores escalares. El estndar SQL2 define este tipo de comparacin de filas para la igualdad, que se procesa comparando una por una cada columna de las dos filas. El resultado de la comparacin es TRUE s6lo si todas las comparaciones de columnas son TRUE. Por supuesto, es posible escribir la consulta sin las constructoras de filas, corno:
Listar el nmero de pedido, la cantidad y el importe de todos los pedidos de zapatas ACf-41002.
244

IMPORTE
'41002')

SELECT NUM_PEDIDO,
FROM PEDIDOS
245
SELECT NUM_PEDIDO, CANTIDAD,

FROM PEDIDOS
FECHA_PEDIDO
: (SELECT ID_FAS, ID_PRODUCTO FROM PRODUCTOS WHERE PRECIO = (SELECT MAX(PRECIO) PROM PRODUCTOS
WHERE
(FAS = 'ACI')
AND
(PRODUCTO =
WHERE {FAB,
PRODUCTO}
y en este simple ejemplo el significado de la consulta es, con toda probabiliodad, igualmente claro en cualquiera de las dos formas. Sin embargo, las constructoras de filas pueden ser muy tiles en la simplificacin de la apariencia de consultas ms complejas, y pueden llegar a ser incluso ms tiles al combinarlas con sub consultas que devuelven filas. 5ubconsultas que devuelven filas 150L2) Como se ha descrito anteriormente en este captulo, el estndar SQLI proporciona las subconsultas para expresar consultas ms complejas a la base de datos. La subconsulta toma la misma forma que una consulta SQL (es decir, una instrucci6n SELECT), pero una subconsulta SQLl debe tener un valor escalar -es decir, debe producir un nico valor de datos como resultado. El valor generado por la subconsulta se usa entonces corno parte de una expresin dentro de la instruccin SQL principal que contiene la subconsulta. Este uso de subconsultas se incluye actualmente en los principales sistemas de bases de datos relacionales de clase empresarial. El estndar SQL2 expande drsticamente la capacidad de las subconsultas incluyendo el soporte de subcollsultas que devuelven filas. Una subconsulta que devuelve filas devuelve no slo un nico elemento de datos, sino una fila de elementos de datos que se puede usar en las expresiones SQL2 y compararse con otras filas. Por ejemplo, supngase que se desea mostrar los nmeros de pedido y las fechas de todos los pedidos formulados del producto ms caro de la base de datos de ejemplo. Una forma lgica de empezar a construir la consulta SQL apropiada sera encontrar una expresi6n que proporcione la identidad (ID de fabricante y de producto) del producto ms caro en cuesti6n. A continuacin se muestra una consulta que halla el producto correcto:
La clusula WHERE ms externa de esta consulta contiene una comparacin de filas. En la parte izquierda del signo igual hay una constructora de filas que consiste en dos nombres de columna. Cada vez que se examina la clusula WHERE para resolver la consulta externa, el valor de esta expresin de filas es un par ID de fabricante/ID de producto de una fila de la tabla PEDIDOS. En la parte derecha del signo igual est la subconsuha que genera la identidad del producto con el mayor valor. El resultado de esta subconsulta es de nuevo un valor de fila, con dos columnas, cuyos tipos de datos coinciden con los de la expresin de filas de la parte izquierda del signo igual. Es posible expresar esta consulta sin la subconsulta que devuelve filas, pero la consulta resultante sera mucho menos inmediata:
Listar los nmeros y fechas de lodos los pedidos formulados para el producto con el mayor precio unitario.
SELECT NUM_PEDIDO, FECHA_PEDIDO FROM PEDIDOS WHERE {FAB = (SELECT ID_FAB FROM PRODUCTOS WHERE PRECIO = (SELECT MAX(PRECIO) FROM PRODUCTOSl)) ANO {PRODUCTO {SELECT ID_PRODUCTO FROM PRODUCTOS WHERE PRECIO = (SELECT MAX(PRECIO) FROM PRODUCTOS))
Hallar el ID de fabricante y del producto con el mayor precio unitario.

SELECT ID_FAB, ID_PRODUCTO FROM PRODUCTOS WHERE PRECIO = (SELECT MAX{PRECIO) FROM PRODUCTOS)
En lugar de una comparacin de una nica fila en la clusula WHERE, la consulta resultante tiene dos comparaciones separadas de valores escalares, una para el ID de fabricante y otra para el ID de producto. Dado que la comparacin se debe dividir, la subconsulta interna para hallar el precio mximo se debe repetir tambin. En general. la forma de la consulta que usa la expresin de filas es una traduccin ms directa de la solicitud en lenguaje natural, y es ms fcil de leer y comprender. Comparaciones de filas (50L2) El uso ms habitual de las expresiones de filas en la clusula WHERE o HAVING es dentro de un test de igualdad, como se ilustr en los ltimos ejemplos. Una fila construida (a menudo consistente en valores de columna de una fila candidata de resultados) se compara con otra fila construida (quizs una fila de resultados de subconsulta o una fila de valores literales), y si las filas son iguales, la fila candidata se incluye en los resultados de la consulta. El estndar SQL2 tambin pro-
Ignorando la posibilidad de varios productos con el mismo precio mximo, esta consulta generar una nica fila de resultados que contenga dos columnas. Al usar las subconsultas que devuelven filas de SQL2, se puede incorporar esta consulta completa como una subconsulta dentro de una instruccin SELECT para obtener la informacin del pedido:
Listar los .nmeros y fechas de lodos los pedidos formulados para el producto con el mayor precio unitario.
246
247
pordona dos formas para los tests de comparacin de desigualdad y de rangos. Al comparar dos filas segn su igualdad, SQL2 usa las mismas reglas que se usaran para ordenar las filas. Compara los contenidos de la primera columna de las dos filas y. si son distintos, los usa para ordenar las filas. Si son iguales, la comparacin se centra en la segunda fila, despus en la tercera y as sucesivamente. A continuacin se muestran las comparaciones resultantes de las filas construidas de
tres columnas derivadas de la tabla
PEDIDOS:
Aadir tres oficinas a la tabla
OFICINAS.
INSERT INTO OFICINAS (OFICINA,CIUDAD.REGION,JEF,VENTASI VALUES (23, 'Santander', 'Oeste', 108, 0.00), (24, 'Sevilla', 'Oeste', 104, 0.00), (14, 'Brihuega', 'Este, NULL, 0.00)
('ACI','4J002',54) < ('REI','2A44R',5)- basada en la primera columna ('ACI','41002',54) < ('ACI','41003',35)- basada en la primera columna ('ACI','41002',IO) < ('ACI','41002',54)- basada en la primera columna
Ntese que las filas individuales de la constructora de tablas no se restringen a slo ciertos valores literales. La fuente de un valor de datos puede ser una subconsulta que devuelve escalares; o una fila completa puede ser el resullado de una subconsulta que devuelve filas. Aunque no tiene mucho sentido en la base de datos de ejemplo. sta es una instruccin legal INSERT de SQL2 que ilustra estas capacidades:
Expresiones de tablas (50L2)

Aadir tres oficinas a la tabla
Adems de las capacidades extendidas para las expresiones que contienen valores simples de datos escalares y valores de filas, el estndar SQL2 ampla espectacularmente las capacidades de procesamiento de consultas SQL para el procesamiento de tablas. Proporciona un mecanismo para la construccin de una tabla de valores de datos dentro de una instruccin SQL. Permite subconsultas que devuelven tablas y amplia los test de las subconsultas SQLl para manejarlas. Tambin permite que aparezcan subconsultas en muchos otros lugares dentro de llna instruccin SQL -por ejemplo, una subconsulta puede aparecer en la clusula FROM de una instruccin SELECT como sus tablas fuente-o Finalmente, proporciona capacidades desarrolladas para la combinacin de tablas, incluyendo las operaciones UNIaN,
INTERSECTION
OFICINAS.
INSERT INTO OFICINAS (OFICINA,CIUDAD,REGION,JEF,VENTASI VALUES (23, 'Santander', 'Oeste', 108, 0.00). (24, 'Sevilla', 'Oeste', (SELECT JEFE FROM REPRESENTANTES WHERE NUM_EMPL : lOS), 0.00) , (SELECT 'BRIHUEGA'. 'ESTE', REGION, JEF, 0.00 FROM OFICINAS WHERE OFICINA: 12)
y DIFFERENCE.
La constructora de tablas (SQL2)
SQL2 permite especificar una tabla de valores de datos dentro de una instruccin SQL usando una expresin constructora de tablas, cuya sintaxis se muestra en la Figura 9.15. En su forma ms simple, la constructora de tablas es una lista separada por comas de constructoras de filas, cada una de las cuales contiene una conjunto de literales separados por comas que forman los valores individuales de columna. Por ejemplo, la instruccin INSERT de SQL2 usa una constructora de tablas como la fuente de datos a insertar en una base de datos. Mientras que la instruccin INSERT de SQLI (descrita en el Captulo 10) permite insenar slo una nica fila de datos; la instruccin INSERT de SQL2 insena tres filas en la tabla OFICINAS.
Como en el ejemplo anterior, la clusula VALUES de esta instruccin INSERT genera una tabla de tres filas para insertar. La primera fila se especifica con valores literales. En la segunda fila, la cuarta columna se especifica como una subconsulta que devuelve escalares que obtiene el jefe del empleado con nmero 105. En la tercera fila, la fila completa se genera por una subconsulta que devuelve filas. En este caso, tres de los valores de la clusula SELECT de la subconsulta son realmente valores literales. pero la tercera y cuarta columnas se producen en la subconsulta. que obtiene el jefe y la regin de la oficina de Navarra (nmero 12).
Subconsultas que devuelven tablas (SQL2)
~VALUESlconstructo:a-de-fiIasJ
lO
As como SQL2 expande el uso de subconsultas que devuelven escalares en subconsuItas que devuelven filas, tambin extiende las subconsultas SQL para admitir subconsultas que devuelven tablas --es decir, subconsultas que devuelven una tabla completa de resultados-o Un papel til de las subconsultas que devuelven tablas es dentro de la clusula WHERE o HAVING, donde se combina con formas extendidas de los tests de subconsultas. Por ejemplo, supngase que se desea listar las descripciones y precios de todos los productos con pedidos que superen 20.000 en la base de datos de ejemplo. Quizs la forma ms inmediata de expresar esta solicitud sea en esta instruccin SQL2 que usa una subconsulta que devuelve tablas:
Figura 9.15.
"Diagrama sintctico de la constructora de tablas SOL2.
Listar la descripcin y el precio de todos los productos con pedidos individuales superiores a 20.000 .
248

PRECIO IN (SELECT FAB, PRODUCTO
249
SELECT DESCRIPCION.
FROM PRODUCTOS
WHERE (ID_FAB.
ID_PRODUCTO)
FROM PEDIDOS
r--
SELECT
WHERE IMPORTE> 20000.00l
nombre-de-tabla
expresin-de valor
*rl
I
~
La consulta externa es una representacin inmediata de la solicitud en lenguaje natural-pide la descripcin y el precio de los productos cuya identificacin (como en los ejemplos previos, un par ID de fabricante/ID de producto) coincide con algn conjunto de productos. Esto se expresa corno un test de pertenencia a conjuntos de la subconsulta en la clusula WHERE. La subconsulta genera una tabla de dos columnas de resultados, que son los identificadores de los productos que se ajustan al criterio establecido sobre los pedidos. Es ciertamente posible expresar esta consulta de otras formas. Del estudio del Captulo 7 se desprende que se puede expresar como la reunin de las tablas PRODUCTOS Y PEDIDOS con una condicin de bsqueda compuesta:
PROM
- respeCifjca';.c~;o:n=.:d:e=':::r-----------------l tab'!J I
f
[GROUP BY
Listar la descripcin y el precio de lOdos los productos con pedidos individua les superiores a 20.000 .
SELECT FROM WHERE ANO ANO DESCRIPCION. PRECIO PRODUCTOS. PEDIDOS (ID_FAB = FAB) (ID_PRODUCTO = PRODUCTO) (IMPORTE> 20000.00)
[ WHERE condicinde
bsqueda
listadecolumnas
TIHAVING
condicin-de j bsqueda
Figura 9.16.
Especificacin de consulta en SQL2: definicin formal.
sta es una instruccin igualmente vlida, pero se ha eliminado ms de la con sulta en lenguaje natural y por tanto es ms difcil de comprender para la mayora de las personas. Al hacerse ms complejas las consultas, la capacidad de usar sub consultas que devuelven tablas llega a ser incluso ms til que la simplificacin y clarificacin de solicitudes SQL.
La especificacin de consulta en SQL2
La clusula FROM especifica las tablas que contribuyen a los resultados de la consulta. La clusula WHERE describe cmo el SGBD debera determinar las columnas que se incluyen en los resultados y las que se descartan. Las clusulas GROUP BY y HAVING unidas controlan la agrupacin de resultados de consultas individuales en una consulta de agrupacin, y la seleccin de grupos de filas para la inclusin o exclusin en los resultados finales. La especificacin de una consulta es el bloque constructor bsico en el estn dar SQL2. Conceptualmente describe el proceso de combinar datos de las tablas de la clusula FROM en una tabla de filas y columnas de resultados. El valor de la especificacin de una consulta es una tabla de datos. En el caso ms simple, una especificacin de consulta en SQL2 consiste en una especificacin simple de consulta. En un caso un poco ms complejo, se usa una especificacin de consulta para describir una subconsulta, que aparece dentro de otra especificacin de consulta (externa). Finalmente, las especificaciones de consulta se pueden combinar usando operaciones de tablas para formar expresiones de consulta de propsito general, como se describe en la siguiente seccin.
El estndar SQL2 formaliza la definicin de lo que informalmente hemos estado denominando instruccin SELECT o una consulta en los ltimos tres captulos en un bloque constructor denominado especificacin de consulta. Para una completa comprensin de las capacidades de expresin de tablas en SQL2, es til comprender esta definicin formal. La forma de una especificacin de consulta en SQL2 se muestra en la Figura 9.16. Sus componentes deberan resultar familiares por los captulos anteriores: Una lista de seleccin especifica las columnas de los resultados. Cada columna se especifica con una expresin que dice al SGBD cmo calcular su valor. Se puede asignar un alias opcional a la columna con una clusula AS . Las palabras clave ALL y UNIQUE controlan la eliminacin de filas duplicadas de los resultados.
Expresiones de consulta (SOL2)

El estndar SQL2 define una expresin de consulta como la forma completa y de propsito general con la que se puede especificar una tabla de resultados en el
250

(SELECT FAS, PRODUCTO FROM PEDIDOS WHERE IMPORTE> 30000.00) UNION (SELECT ID_FAB. ID_PRODUCTO FROM PRODUCTOS WHERE (PRECIO * STOCK) > 30000)
251
lenguaje SQL2. Los bloques constructores bsicos que se pueden usar para crear una expresin de consulta son los siguientes: Una especificacin de consulta, como se describi en la secclOn anterior (SELECT ... FROM ... ). SU valor es una tabla de resultados de una consulta. Una constructora de tablas, como se describi previamente (VALUES ... ). Su valor es una tabla de valores construidos. Una referencia explcita a tabla (TABLE nombre-tabla). Su valor son los contenidos de la tabla listada. Al usar estos bloques constructores, SQL2 permite combinar sus valores de tabla usando las siguientes operaciones: SQL2 proporciona soporte explcito para las reuniones completas de producto cruzado (reuniones cruzadas), reuniones naturales, reuniones internas y todos los tipos de reuniones externas' (izquierda, derecha y completa), como se describieron en el Captulo 7. Una operacin JOIN toma dos tablas como entrada y produce una tabla de resultados de consulta combinados de acuerdo con la especificacin de la reunin. UNION. La operacin UNION de SQL2 proporciona soporte explcito para la mezcla de filas de dos tablas compatibles (es decir, dos tablas con el mismo nmero de columnas y con los mismos tipos de datos en las columnas correspondientes). La operacin UNION toma dos tablas como entrada y produce una nica tabla mezclada de resultados de consulta. DIFFERENCE. La operacin EXCEPT de SQL2 toma dos tablas como entrada y produce como salida una tabla que contiene las filas que aparecen en la primera tabla pero que no aparecen en la otra -es decir, las filas ausentes de la segunda. Conceptualmente, la operacin EXCEPT es como una resta de tablas. Las filas de la segunda tabla se eliminan de las filas de la primera, y la respuesta son las filas restantes de la primera tabla. INTERSECT. La operacin INTERSECT de SQL2 toma dos tablas como entrada y produce como salida una tabla que contiene las filas que aparecen en las dos tablas de entrada.
JOIN.
Mostrar todos los productos para los que hay un pedido superior a 30.000 Y ms de 30.000 de stock disponible.
(SELECT FAB, PRODUCTO FROM PEDIDOS WHERE IMPORTE> 30000.00) INTERSECT (SELECT ID_FAS. ID_PRODUCTO FROM PRODUCTOS WHERE (PRECIO * STOCK) > 30000)
Mostrar todos los productos para los que hay excepto los que se venden por menos de 1.000 .
(SELECT FAB, PRODUCTO FROM PEDIDOS WHERE IMPORTE> 30000.00) EXCEPT (SELE~T ID_FAS, ID_PRODUCTO FROM PRODUCTOS WHERE PRECIO < 100,00)
UII
pedido superior a 30.000 .
Las operaciones UNION, INTERSECT y DIFFERENCE de SQL2 Las operaciones UNION, INTER5ECT y DIFFERENCE de SQL2 proporcionan operaciones de conjunto para la combinacin de dos tablas de entrada para formar una tabla de salida. Las tres operaciones requieren que las dos tablas de entrada sean compatibles bajo unin -deben tener el mismo nmero de columnas, y las columnas correspondientes de cada tabla deben tener tipos de datos idnticos-o A continuacin se muestran unos ejemplos simples de expresiones de consulta en SQL2 con las operaciones UNlN, INTERSECT y DIFFERENCE en trminos de la base de datos de ejemplo:
Mostrar todos los productos para los que hay un pedido superior a 30.000 o ms de 30.000 de stock disponible.
De manera predeterminada, las operaciones UNION, INTERSECT y EXCEPT eliminan las filas duplicadas durante su procesamiento. ste es usualmente el resultado deseado, como en estos ejemplos, pero ocasionalmente puede ser necesario suprimir la eliminacin de filas duplicadas. Esto se puede hacer especificando las formas UNION ALL, INTERSECT ALL y EXCEPT ALL de las operaciones. Ntese que cada uno de estos ejemplos produce una tabla de dos columnas de resultados. Los resultados vienen de dos tablas fuente diferentes de la base de datos -la tabla PEDIDOS y la tabla PRODUCTOS-o Sin embargo, las columnas seleccionadas en estas tablas tienen los mismos tipos correspondientes, as que se pue den combinar usando estas operaciones. En la base de datos de ejemplo las columnas correspondientes tienen nombres diferentes en las dos tablas. (La columna del ID de fabricante se denomina FAB en la tabla PEDIDOS, pero se denomina ID_FAB en la tabla PRODUCTOS.) Sin embargo, columnas correspondientes como stas tendrn siempre el mismo nombre en cada una de las tablas a combinar. Como conveniencia, SQL2 permite especificar las columnas correspondientes en una clusula CORRESPONDING unida a la operacin UNION, INTERSECT o EXCEPT. A continuacin se muestra el ejemplo anterior de UNJON modificado para la situacin en la que las tabla~ PEDIDOS Y PRODUCTOS tienen nombres de columna paralelos para el ID de fabricante y de producto:
M
252

Expresiones de consulta en la clusula FRDM
253
Mostrar rodos los productos para los que hay un pedido superior a 30.000 o superior a 30.000 de stock.
(SELECT FROM PEDIDOS
WHERE IMPORTE> 30000.00) UNION CORRESPONOING BY (FAB.

SELECT
PROM PRODUCTOS
PRODUCTO)
WHERE (PRECIO STOCK)
>
30000)
En un caso como ste, en el que todas las columnas correspondientes (es decir, con los mismos nombres) de las dos labias participan en la operacin UNION, SQL2 incluso permite dejar vaca la lista explcita de nombres de columna:
Mostrar todos los productos para los que hay un pedido superior a 30.000 o superior a 30.000 de stock.
(SELECT FROM PEDIDOS
Las expresiones de consulta SQL2 proporcionan un mtodo mucho ms potente y flexible para generar y combinar tablas de resullados que la simple subconsulta y las operaciones UNION proporcionadas por el estndar SQL l. Para hacer que las expresiones de consulta sean incluso ms tiles y de propsito general, el estndar SQL2 permite que aparezcan casi en cualquier lugar en que pueda aparecer una referencia a tabla en una consulta SQL1. En panicular, una expresin de consulta puede aparecer en lugar del nombre de una tabla en la clusula FROM. A continuacin se muestra un ejemplo simple de una consulta SQL2 para la base de datos de ejemplo que usa esta caracterstica:
Mostrar los Ilombres y el total de los mejores pedidos de los cliellles con lmires de crdito superiores a 50.000 f.
SELECT EMPRESA, TOT_PEDIDOS PROM CLI~NTES, (SELECT CLIENTE, SUM(IMPORTE) AS TOT_PEDIDOS FROM PEDIDOS GROUP BY CLIENTE), WHERE (LIMITE_CREDITO > 50000.00) AND (NUM_CLI ~ CLIENTE)
WHERE IMPORTE> 30000.00) UNION CORRESPONDING {SELECT FROM PRODUCTOS
WHERE (PRECIO * STOCK)
>
30000)
Finalmente, merece la pena destacar que la capacidad de los alias de columna de la especificacin de una consulta se puede usar para renombrar o asignar nombres a las columnas de resultados de consultas individuales que se combinan con la operacin UNION. Si se elimina el supuesto de que las tablas PRODUCTOS y PEDIDOS usan los mismos nombres de columna, an es posible usar la forma coRRESPONDING de la operacin UNION en esta consulta simplemente renombrando las columnas en una de las tablas:
Mostrar todos los productos para los que hay un pedido superior a 30.000 o superior a 30.000 de slOck.
(SELECT FROM WHERE UNION (SELECT FROM WHERE
PEDIDOS IMPORTE> 30000,OO CORRESPONDING ID_FAB AS FAB, ID_PRODUCTO AS PRODUCTO PRODUCTOS (PRECIO * STOCK) > 30000)
En este ejemplo simple no hay mucha ventaja al usar esta constructora, pero en el caso ms general en que las consultas conllevan columnas calculadas o son consultas de agrupacin, la clusula CORRESPQNDING y los alias de columna pueden ayudar a clarificar el significado de la consulta.
El segundo <<nombre de tabla de la clusula FROM en la consulta principal no es un nombre de tabla en absoluto, sino una expresin de consulta completa. De hecho, la expresin podra haber sido mucho ms compleja, incluyendo operacio~ nes UNION o JOIN. Cuando aparece una expresin de consulta en la clusula FROM, como ocurre aqu, el SGBO la resuelve conceptualmente primero, antes de ningn otro procesamiento de la consulta, y crea una tabla temporal de resultados generados por la expresin de consulta. En este caso, esta tabla temporal consiste en dos columnas que listan cada nmero de cliente y el total de pedidos para ese nmero de cliente. Esta tabla temporal acta a continuacin como una de las tablas fuente de la consulta principal. En este ejemplo, sus contenidos se renen con la tabla CLIENTES para obtener el nombre de la empresa y generar la respuesta a la pre. gunta principal. Hay muchas otras formas en las que se podra haber escrito esta consulta. La consulta completa se podra haber escrito como una consulta de agrupacin externa que reuniese las tablas CLIENTES y PEDIDOS. La operacin reunin podra haberse hecho explcita con un operador JO IN de SQL2, y despus los resultados de la reunin se podran haber agrupado en la consulta externa. Como muestra este ejemplo, una de las ventajas de la expresin de consultas en SQL2 es que normalmente proporcionan varias formas diferentes de obtener los mismos resultados de la consulta. La filosofa general detrs de las capacidades de SQL2 en esta rea es que el lenguaje SQL debera proporcionar la flexibilidad de expresar una consulta de la forma ms natural. El SGBD subyacente debe ser capaz de tomar la consuha, como se haya expresado, descomponerla en sus piezas fundamentales y despus determinar la forma ms eficiente de resolver la consulta. Este plan de ejecucin inter-
254
no de consultas puede ser muy diferente del plan aparente de la instruccin SQL real, pero al producir los mismos resultados, el efecto neto es trasladar la sobrecarga debida a la optimizacin de las personas al SGBD.
Consultas SaL: un resumen final

Esto concluye el estudio de las consultas SQL y de la instruccin SELECT que comenz en el Captulo 6. Como se describi en los captulos 6 al 9, las clusulas de la instruccin SELECT proporcionan un conjunto potente y flexible de capacidades para la recuperacin de datos de la base de datos. Cada clusula desempea un papel especfico en la recuperacin de datos: La clusula FRQM especifica las tablas fuente que aportan datos a los resultados. Cada nombre de columna en el cuerpo de la instruccin SELECT debe identificar sin ambigedades una columna de estas tablas, o debe ser una referencia externa a una columna de una tabla fuente de una consulta externa. La clusula WHERE, si se encuentra, selecciona combinaciones individuales de filas de las tablas fuente para participar en los resultados de la consulta. Las subconsultas en la clusula WHERE se evalan para cada fila individual. La clusula GROUP BY, si se encuentra, agrupa las filas individuales seleccionadas por la clusula WHERE en dos grupos. La clusula HAVING, si se encuentra, selecciona grupos de filas para participar en los resultados de la consulta. Las subconsultas en la clusula HAVING se evalan por cada grupo de filas. La clusula SELECT determina los valores de datos que aparecen finalmente como columnas en los resultados de la consulta. La palabra clave DISTINCT, si se encuentra, elimina filas duplicadas de los resultados de la consulta. El operador UNION, si se encuentra, mezcla los resultados de la consulta producidos por las instrucciones SELECT individuales en un nico conjunto de resultados. La clusula ORDER BY, si se encuentra, ordena los resultados finales en trminos de una o ms columnas. Las capacidades de expresin de consultas en SQL2 aaden expresiones de filas y de tablas y operaciones INTERSECT y EXCEPT a las capacidades de SQLl. El flujo fundamental del procesamiento de consultas no se modifica, pero la capacidad de expresar consultas dentro de otras se mejora notablemente.
Parte flI
ACTUALIZACiN DE DATOS
SQL no es slo un lenguaje de consultas, sino que adems es un lengu,aje completo para recuperar y modificar datos de la base de datos. Los capIt~ los 10 al 12 se centran en las actualizaciones de las bases de datos. El CapItulo 10 describe las instrucciones SQL que aaden, eliminan y modifican datos de una base de datos. El Captulo II describe la forma en que SQL mantiene la integridad de los datos almacenados cuando stos se modi~can. El Captulo 12 describe las caractersticas de procesamiento de transaccI~nes con SQL que permiten actualizaciones simultneas de la base de datos debidas a diferentes usuarios.
1:
CAPTULO
10
'.
Actualizaciones de la base de datos
SQL es un lenguaje completo para la manipulacin de datos que no slo se utiliza para las consultas a bases de datos, sino tambin para modificar y actualizar los mismos. En comparacin con la complejidad de la instruccin SELECT. que admite las consultas de SQL, las instrucciones de SQL que modifican el contenido de las bases de datos son extremadamente sencillas. No obstante, las actualizaciones plantean algunos retos a los SGBD aparte de los presentados por las consultas a las bases de datos. El SGBD debe proteger durante las modificaciones la integridad de los datos almacenados. asegurando que s610 se introduzcan en la base de datos datos vlidos y que la base de datos siga siendo autoconsistente, incluso en caso de fallos del sistema. El SGBD tambin debe coordinar las actualizaciones simultneas realizadas por varios usuarios, asegurndose de que los usuarios y sus modificaciones no interfieran entre s. Este captulo describe las tres instrucciones de SQL que se utilizan para modificar el contenido de las bases de datos:
INSERT. DELETE. UPDATE.
Aade nuevas filas de datos a las tablas. Elimina filas de datos de las tablas. Modifica los datos de las bases de datos.
En el Captulo 11 se describen los servicios de SQL para el mantenimiento de la integridad de los datos. El Captulo 12 trata del soporte de SQL cuando concurren varios usuarios.
Adicin de datos a la base de datos

Se suele aadir una fila de datos a la base de datos relacional cuando aparece en el mundo e~terior una nueva entidad representada por esa fila. Por ejemplo, en la base de datos de ejemplo:
..
257
258
Captulo 10: Actualizaciones de la base de datos
259
Cuando se contrata a un nuevo representante, hay que aadir una fila nueva a la tabla REPRESENTANTES para almacenar sus datos. Cuando un representante suscribe a un nuevo cliente, hay que aadir una fila nueva a la tabla CLIENTES, que representa a ese cliente nuevo. Cuando un cliente realiza un pedido, hay que aadir una fila nueva a la tabla PEDIDOS para que contenga los datos de ese pedido.
Supongamos que se acaba de contratar a un nuevo representante, Herminio Jurez, con los datos personales siguientes: Nombre: Edad: Nmero de empleado: Puesto: Oficina: Fecha de contratacin: Cuota: Ventas durante el ao en curso: sta es la instruccin ejemplo:
INSERT
Herminio Jurez
36
111 Jefe de ventas Almera (oficina nmero 13) 25 de julio de 1990 Por asignar 0,00
En cada caso se aade la fila nueva para que la base de datos siga siendo un modelo preciso del mundo real. La unidad de datos ms pequea que puede aadirse a una base de datos relacional es una sola fila. En general, los SGBD basados en SQL proporcionan tres maneras de aadir filas de datos a las bases de datos:
sobre una nica fila. La instruccin INSERT sobre una nica fila aade una sola fila de datos nueva a una tabla. Suele emplearse en las aplicaciones cotidianas -por ejemplo, programas de introduccin de datos. INSERT sobre varias filas. La instruccin INSERT sobre varias filas extrae filas de datos de otra parte de la base de datos y las aade a una tabla. Suele emplearse en procesamientos de fin de mes o de fin de ao, cuando se desplazan a una tabla inactiva las filas de una tabla que ya no van a ser necesarias. Carga masiva. Una utilidad de carga masiva aade datos a una tabla desde un archivo externo a la base de datos. Suele emplearse para cargar inicialmente la base de datos o para incorporar dalas descargados desde otro sistema infonntico o recopilados desde varios sitios.
INSERT
que aade a Don Herminio a la base de datos de
AJiadir a Herminio Jurez como nuevo representante.

INSERT INTO REPRESENTANTES (NOMBRE, EDAD, NUM_EMPL, VENTAS, PUESTO, FECHA_CONTRATO, OFICINA_REP) VALUES (' Herminio Jurez', 36, 111, 0.00, 'Jefe Ventas', '25-JUL-90', 13)
1 fila insertada.
La instruccin IN5ERT sobre una sola fila

La instruccin INSERT sobre una sola fila, que puede verse en la Figura 10.1, aade una fila nueva a una tabla. La clusula INTD especifica la tabla que recibe la nueva fila (la tabla destino), y la clusula VALUES especifica los valores de datos que contendr la nueva fila. La lista de columnas indica el valor de datos que va a cada columna de la fila nueva.
~INSERT INTO nombredetabla
---r----------:r-----,
nombre-de(~/um~)
La Figura 10.2 ilustra de manera grfica el modo en que SQL ejecuta la instruccin IN5ERT. Conceptualmente, la instruccin INSERT crea una sola fila de datos que coincide con la estructura de columnas de la tabla, la rellena con los datos de la clusula VALUES y, luego, aade la nueva fila a la tabla. Las filas de las tablas no estn ordenadas, por lo que no existe el concepto de insercin de la fila en la parte superior de la tabla, en la inferior o entre dos filas. Tras la instruccin INSERT la nueva fila es, sencillamente, parte de la tabla. Una consulta posterior a la tabla REPRESENTANTES incluir la nueva fila, pero puede aparecer en cualquier parle enlre las filas de los resultados de la consulta. Supngase que Don Herminio recibe ahora su primer pedido, de InterCorp, un nuevo cliente al que se le asigna el nmero de cliente 2126. El pedido es de veinte cables ACI-41004, con un importe total de 2.340 Y se le ha asignado el nmero de pedido 113069. stas son las instrucciones INSERT que aaden a la base de datos el nuevo cliente y el pedido:
Insertar un nuevo cliente y un pedido par'!.. Don Herminio.

INSERT INTO CLIENTES (EMPRESA. NUM_CLI. LIMITE_CREDITO, VALUES ('InterCorp'. 2126, 15000.00. 111) REP_CLI)
VALUES ( T I c o n s t a n t 8 1 1 ) - - - - - - - - - - - -__
fila insertada. (IMPORTE, FAB, PRODUCTO, CANTIDAD, FECHA_PEDIDO, NUM_PEDIDO, CLIENTE, REP) VALUES (2340. OO. 'ACI'. '41004', 20. CURRENT_DATE. 113069, 2126, 111)
~NULL~
INSERT INTO PEDIDOS
Figura 10.1.
Diagrama sintctico de la instruccin INSERT sobre una sola fila.
1 fila insertada.
260
261
Instruccin saL
INSERT Im'O REPRESENTI<m'&S lNOHBRE.
V~WES
25~JU'-90.
EDAD. r.'tnLEMPL.
. .. 1
l' t1enoinio ';u6..-e:. 36. lU. O. oo.

1))
'Jefe Ventll.s.
fila nueva
111
IHera.inio Jurnl
1
r ~ _
36
/
Tabla REPRESENTA/trES
III.Ol...D1PL
~ ~
"
Jefe venusl 25-,JUL-1990
""" I
NULLI
0.00
en esa tabla, o la instruccin INSERT fallar. El esquema de seguridad y los permisos de SQL se describen en el Captulo 15. La finalidad de la lista de columnas de la semencia INSERT es que coincidan Jos valores de los datos de la clusula VALUES con las columnas que los van a recibir. La lista de valores y la lista de columnas deben contener el mismo nmero de elementos, y el tipo de datos de cada valor debe ser compatible con el tipo de datos de la columna correspondiente, o se producir un error. El estndar ANSI! ISO obliga a que haya nombres de columnas no calificados en la lista de columnas, pero muchas implementaciones permiten nombres calificados. Por supuesto, no puede haber ninguna ambigedad en los nombres de las columnas, ya que todos deben hacer referencia a nombres de columnas en la tabla destino.
Insercin de valores NULL
."
", ". ", ." ". ",
'" ",
'"'
Bruno
Ko.de Jil>O!M: SUsal\ll s.ntos ~.l Cbvel
Be.-""...sc
Sinc~e1
D.>niel Ruld<obo Taoofos 5&1 I.e:l PTdn hbl .. CNs

~.u~4.uu
.. ."" .. "
" "
OFlCIta.REP
"",,-~ro
U
U
."
" ,= "
"
U
bprese:l,anu 12-OCT_89 Repre.""tanu IO-DIC-86

U-JUN-88 J9-MI,Y67 bp<es""t...te :.IO-OCT-86 ~"enunte lJ-Em:-'O Jde Vo:nl:U U-OCT-" !lepreseotante Ol-KU87 tepns..,t.ant. 14-NOV-88
~u'""tantt
12-I'EB-U
J.r. ven,..
VP VerltU
".
'"
'" '" ", ."
~.
~~
~u
'" ", ",
3S0.00G,OO
lOO.OOO.Dae
367.U1.00
J92.125,OO
350.000,ooE
474.050,OO
299.H2.DaE
2Do.oaO,ooe
275.000.00
H2.59 00
30S.613.00
lOO.OaO.OOE
"
" "
3S0.0aO.ooe 275.000.00 lOO.OOG.GG
,=,
Cuando SQL inserta en una tabla una nueva fila de datos, asigna de manera automtica un valor NULL a todas las columnas cuyo nombre no se halle en la lista de columnas de la instruccin INSERT. En esta instruccin INSERT, que aadi a Don f{erminio a la tabla REPRESENTANTES, se omitieron las columnas CUOTA y JEFE:
INSERT INTD REPRESENTANTES (NOMBRE, EDAD, NUM_EMPL, VENTAS, PUESTO, FECHA_CONTRATO, OFICINA_REP) VALUES ('Herminio Jurez' , 36, 111. 0.00, 'Jefe Ventas', '25-JUL-90', 13)
15".85.00 361.165.00 211i.715.GG 186.0'2.GO
Figura 10.2.
Insercin de una sola fila.
Como muestra este ejemplo, la instruccin INSERT puede hacerse muy larga si hay muchas columnas de datos, pero su formato sigue siendo muy directo. La segunda instruccin INSERT utiliza la constante de sistema CURRENT_DATE en su clusula VALUES, lo que hace que se inserte la fecha actual como fecha del pedido. Esta constante del sistema se especifica en el estndar SQL2 y la incluyen muchos de los productos SQL ms populares. Otras marcas de SGBD ofrecen otras constantes del sistema o funciones incorporadas para obtener la fecha y la hora actuales. Se puede utilizar la instruccin INSERT con SQL interactivo para aadir filas a una tabla que aumenta de tamao muy raras veces, como la tabla OFICINAS. En la prctica, sin embargo, los datos sobre los nuevos clientes, pedidos o representantes se aaden casi siempre a la base de datos mediante un programa de introduccin de datos orientado a los formularios. Cuando se concluye la introduccin de datos, el programa de aplicacin inserta la nueva fila de datos empleando SQL para programacin. Independientemente de si se emplea SQL interactivo o para programacin, la instruccin INSERT es la misma. El nombre de tabla especificado en la instruccin INSERT suele ser un nombre de tabla no calificado, que especifica una tabla que posee el usuario. Para insertar datos en una .tabla poseda por otro usuario se puede especificar un nombre de tabla calificado. Por supuesto, tambin hay que tener permiso para insertar los datos
En consecuencia, la fila recin aadida tiene un valor NULL en las columnas y JEFE. como puede verse en la Figura 10.2. Se puede hacer ms explcita la asignacin de valores NULL incluyendo estas columnas en la lista de columnas y especificando la palabra clave NULL en la lista de valores. Esta instruccin INSERT tiene exactamente el mismo efecto que la anterior:
CUOTA
INSERT INTO REPRESENTANTES (NOMBRE, EDAD, NUM_EMPL, VENTAS, CUOTA, PUESTO, JEFE, FECHA_CONTRATO, OFICINA_REP) VALU,?S ('Herminio Jurez' , 36, 111, 0.00, NULL, 'Jefe Ventas', NULL, '25-JUL-90' ,13)
Insercin de todas las columnas
Como un servicio ms, SQL permite omitir la lista de columnas de la instruccin INSERT. Cuando se omite la lista de columnas, SQL genera de !llanera automtica una lista de columnas consistente en todas las columnas de la tabla, ordenadas de izquierda a derecha. Se trata de la misma secuencia de columnas que genera SQL cuando se utiliza una consulta SELECT *. Empleando este atajo se puede reescribir de manera equivalente la instruccin INSERT anterior como:
INSERT INTO REPRESENTANTES VALUES (111, 'Herminio Jurez' , 36, 13, '25-JUL-90', NULL. NULL, 0.00) 'Jefe Ventas'-,
262
263
Cuando se omite la lista de columnas hay que utilizar la palabra clave NULL en la lista de valores para asignar de manera explcita valores NULL a las columnas, como puede verse en el ejemplo. Adems, la secuencia de valores de datos debe corresponder exactamente con la secuencia de columnas de la tabla. La omisin de la lista de columnas es conveniente en SQL interactivo porque reduce la longitud de la instruccin INSERT que hay que escribir. Para SQL con programacin la lista de columnas se debe especificar siempre, ya que bace el programa ms fcil de leer y de comprender. Adems, las estructuras de las tablas suelen cambiar con el tiempo para incluir columnas nuevas o eliminar las que ya no se utilizan. Un programa que contenga instrucciones INSERT sin una lista explcita de columnas puede funcionar bien durante meses o aos y. de repente. comenzar a generar errores si algn administrador de la base de datos modifica el nmero o los tipos de datos de las columnas.
La instruccin INSERT sobre varias filas

La segunda forma de la instruccin INSERT, que puede verse en la Figura 10.3. aade varias filas de datos a su tabla destino. En esta forma de la instruccin INSERT los valores de los datos de las filas nuevas no se especifican de manera explcita dentro del texto de la instruccin. En vez de eso. el origen de las nuevas filas es una consulta a una base de datos, especificada en la instruccin. La adicin de filas cuyos valores provienen de la misma base de datos puede parecer, en principio, extraa, pero resulta muy til en algunas situaciones especiales. Por ejemplo, supngase que se desea copiar el nmero de pedido, la fecha y el importe de todos los pedidos realizados antes del primero de enero de 1990, desde la tabla PEDIDOS a otra tabla, denominada PEDIDOSANTIGUOS. La instruccin INSERT sobre varias filas proporciona una manera concisa y eficiente de copiar los datos:
Esta instruccin INSERT parece complicada, pero, realmente, es muy sencilla. La instruccin identifica la tabla que va a recibir las filas nuevas (PEDIDOSANTIGUOS) y las columnas que van a recibir los datos. igual que en la instruccin INSERT sobre una sola fila. El resto de la instruccin es una consulta que recupera los datos de la tabla PEDIDOS. La Figura 10.4 ilustra grficamente la opera tiva de esta instruccin INSERT. Conceptualmente, SQL realiza en primer lugar la consulta de la tabla PEDIDOS y luego inserta Jos resultados de la consulta en la tabla PEDIDOSANTIGUOS. Veamos otra situacin en la que se puede utilizar la instruccin INSERT sobre varias filas. Supngase que se desean analizar los patrones de compra de los clientes averiguando los clientes y los vendedores que son responsables de los grandes pedidos -por encima de los 15.000 -. Las consultas que se ejecutarn combinarn datos de las tablas CLIENTES, REPRESENTANTES Y PEDIDOS. Estas consultas a las tres tablas se ejecutarn bastante rpido en nuestra pequea base de datos de ejemplo, pero en una base de datos empresarial real, con muchos millares de filas. tardaran mucho tiempo. En lugar de ejecutar muchas consultas largas a las tres tablas, se puede crear una nueva tabla, denominada PEDIDOSGRANDES. que contenga los datos necesarios, y que venga definida como se indica en la pgina siguiente:
TbI a PEDIDOS
tML.PEDIOO fECI\A.-PEDlOO CLIE:lrn: 112961 113012 112989 113051 n-DIC-89 11-eNE-90 03-DQ';-90 10-FEB-90 2117 2111 2101 2118
''''" "" '" '" ,,, '" m '" '" ,,,,,, '" Q"
PROOOC'!'t 2A44L 41003
""'~
, , "
2
IMPORTE 31.500.00 3.745.00 1.458,00 1.420,00
1"
Consulta
SELECT NUloLPEDIDO. FECIlA....PEOlOO, IMPORTE FROM PEDIDOS WHERE FECf!A.-PEDlDO <: 01-ENE-90'
Copiar los pedidos antiguos a la tabla PEDIDOSANTIGUOS.

INSERT INTO SELECT FROM WHERE PEDIDOSANTIGUOS (NUM_PEDIDO, FECHA_PEDIDO, NUM_PEDIDO, FECHA_PEDIDO, IMPORTE PEDIDOS FECHA_PEDIDO < 'Ol-ENE-90' IMPORTE)
113049 112987 113057 113042
10-FEB-90 31-DIC-89 lB-FEB-90 02-FEB-90
2118
2103 2111 2113
'" '" '" '"' '"
'"
,C> 4l00Y
4l00X 2A44R
Q" XK47
",
31.500.00 27.500,00 600,00 22.500.00
9 filas insertadas.
Tabla PEDIDOSjoNI'IGUOS f,'UM..-PEDIDO FECHA.-PEDIDO IMPORTE
NUlLPEDI FECI\A.-PEDlOO 112961 17-DIC-B9 112968 12--ocT-89 IH.PORTE 31.500.00 3.978.00
1- INSERT
INTO nombre-tablaT
nombre
(~um~)
I
=oJ-consulta~.
,
112993 04-ENE-89 112987 3l-DIc-89 1.896.00 27.500.00
Figura 10.3.
Diagrama sintctico de la instruccin INSERT
sob~e
varias filas.
Figura 10.4.
Insercin de varias filas.
111
264
265
Informacin sobre las columnas

IMPORTE EMPRESA NOMBRE REND
FAB
PRODUCTO CANTIDAD
Importe del pedido (de PEDIDOS) Nombre del cliente (de CLIENTES) Nombre del representante (de REPRESENTANTES) Diferencia por debajo o por encima de la cuota (calculada a partir de REPRESENTANTES) Identificador del fabricante (de PEDIDOS) Identificador del producto (de PEDIDOS) Cantidad encargada (de PEDIDOS)
IN-
Los resultados de la consulta deben contener el mismo nmero de columnas que la lista de columnas de la instruccin INSERT (o que toda la tabla destino, si se omite la lista de columnas), y los tipos de datos deben ser compatibles, columna a columna. La consulta no puede ser la UNION de varias instrucciones SELECT diferentes. Slo se puede especificar una instruccin SELECT. La tabla destino de la instruccin INSERT no puede aparecer en la clusula FROM de la consulta ni de ninguna subconsulta que pueda conte::", r. Esto prohbe la insercin en la propia tabla de una parte de s. Las dos primeras restricciones son estructurales, pero las dos ltimas se incluyeron en el estndar simplemente para evitar complejidades. En consecuencia, estas restricciones se relajaron en el estndar SQL2. El estndar permite hoy en da operaciones UNION y JO IN y expresiones en la consulta, permitiendo bsicamente que los resultados de una consulta general a la base de datos se recuperen y se inserten en una tabla con la instruccin INSERT. Tambin permite varias formas de autoinsercin, en las que la tabla origen de los datos que hay que insertar y la tabla destino son la misma.
Una vez creada la tabla PEDIDOSGRANDES. se puede utilizar la instruccin SERT sobre varias filas para rellenarla:
Cargar los datos para su anlisis en la tabLa

INSERT INTO PEDlDOSGRANDES SELECT FAS, WHERE AND AND
PEDIDOSGRANDES.
(IMPORTE, EMPRESA, NOMBRE. RENO, PRODUCTO, FAS. CANTIDAD) IMPORTE, EMPRESA, NOMBRE. (VENTAS - CUOT~l. PRODUCTO, CANTIDAD FROM PEDIDOS. CLIENTES, REPRESENTANTES CLIENTE ~ NUM_CLI REP : NUM_EMPL IMPORTE> 15000.00
,
Utilidades de carga masiva
Los datos que hay que insertar en una base de datos suelen descargarse de otro sistema informtico o reunirse de otros sitios y almacenarse en un archivo secuencial. Para cargar los datos en una tabla se puede escribir un programa con un bucle que lea cada registro del archivo y utilice la instruccin INSERT sobre una sola fila para aadir esa fila a la tabla. Sin embargo, la sobrecarga derivada de hacer que el SGBD ejecute de manera repetida instrucciones INSERT sobre una sola fila puede ser muy elevada. Si la insercin de una sola fila tarda medio segundo .con una carga de sistema habitual, eso probablemente sea un renclimiento aceptable para un programa interactivo. Pero ese rendimiento se vuelve rpidamente inaceptable cuando se aplica a la tarea de carga masiva de cincuenta mil filas de datos. En ese caso, la carga de los datos necesitaria ms de seis horas. Por este motivo la mayor parte de los productos SGBD comerciales incluyen una caracterstica de carga masiva que carga en una tabla los datos de un archivo a gran velocidad. El estndar SQL ANSI/ISO no incluye esta funcin, y suele ofrecerse ms bien como un programa de utilidad independiente que como parte del lenguaje SQL. La utilidad de cada fabricante ofrece un conjunto de caractersticas, funciones y comandos ligeramente diferente. Cuando se utiliza SQL desde el interior de un programa de aplicacin 'se suele ofrecer otra tcnica para insertar de manera ms eficiente una gran cantidad de datos en una base de datos. La instruccin de programacin INSERT estndar inserta una sola fila de datos, al igual que las instrucciones interactivas INSERT sobre una sola fila de los ejemplos anteriores. Pero muchos productos SOBD comerciales permiten que se proporcionen los datos de dos o ms filas (a menudo hasta de centenares de filas) como parte de una sola instruccin INSERT masiva. Todos los
6 filas insertadas.
En una base de datos de gran tamao esta instruccin INSERT puede tardar un rato en ejecutarse porque implica una consulta a tres tablas. Cuando se complete la instruccin, los datos de la tabla PEDIDOSGRANDES duplicar la infonnacin de otras tablas. Adems, la tabla PEDIDOSGRANDES no se actualizar de manera automtica cuando se agreguen a la base de datos nuevos pedidos, por lo que sus datos se pueden quedar rpidamente desactualizados. Cada uno de estos factores parece un inconveniente. Sin embargo, las consultas para el anlisis de los datos posteriores a la tabla PEDIDOSGRANDES pueden expresarse de manera muy sencilla -se transforman en consultas a una sola tabla. Adems, cada una de estas consultas se ejecutar mucho ms rpido que si fuera una reunin de tres tablas. En consecuencia, probablemente se trate de una buena estrategia para llevar a cabo el anlisis, especialmente si las tres tablas originales son de gran tamao. En esta situacin es probable que la tabla PEDlOOSGRANDES se utilice como tabla temporal para la realizacin del anlisis. Se crear y llenarde datos, que representarn una instantnea del estado de los pedidos en un momento dado, se ejecutarn los programas de anlisis y luego la tabla se vaciar o se desechar. El estndar SQLI especifica varias restriccioes lgicas para la consulta que aparece dentro de la instruccin INSERT sobre varias filas: La consulta no puede contener ninguna clusula ORDER BY. En todo caso, resulta intil ordenar los resultados de la consulta, ya que se van a insertar en una_tabla que, como todas las tablas, carece de orden.
266
267
datos proporcionados deben ser para filas nuevas de la nica tabla que es el destino de la instruccin INSERT, y debe nombrarse en la clusula INTO. La ejecucin de una instruccin INSERT masiva para cien filas de datos tiene exactamente el mismo efecto que ejecutar cien instrucciones INSERT sobre una sola fila. No obstante, suele resultar mucho ms eficiente. ya que slo supone una llamada al SGBD. Resultan habituales mejoras de la eficiencia entre un veinte y un treinta por ciento, y hasta un trescientos por ciento o ms respecto de las instrucciones INSERT sobre una sola fila, en funcin de la marca del SGBD y del tipo concreto de datos que se est insertando.
~DELETE FROM nombre-tabla-r
.
Figura 10.5.
WHERE
c~ndici6n~bSqUeda]
.--------+
Diagrama sintctico de la instruccin DELETE.
Eliminacin de datos de la base de datos

Se suele eliminar una fila de datos de una base de datos cuando la entidad representada por la fila desaparece del mundo exterior. Por ejemplo, en la base de datos de ejemplo: Cuando un cliente cancela un pedido, h~y que eliminar la fila correspondiente de la tabla PEDIDOS. Cuando un representante abandona la empresa, hay que eliminar la fila correspondiente de la tabla REPRESENTANTES. Cuando se cierra una oficina comercial, hay que eliminar la fila correspondiente de la tabla OFICINAS. Si se despide a los representantes de esa oficina, tambin hay que eliminar sus filas de la tabla REPRESENTANTES. Si se los traslada, hay que actualizar sus columnas OFICIN~REP. En cada caso se elimina la fila para hacer que la base de datos siga siendo un modelo preciso del mundo reaL La unidad de datos ms pequea que puede eliminarse de una base de datos relacional es una sola fila.
La clusula WHERE de este ejemplo identifica una sola fila de la tabla REPREque SQL elimina de la tabla. La clusula WHERE debera tener un aspecto familiar -se trata, exactamente, de la misma clusula WHERE que se especifica en las sentencias SELECT para recuperar la misma fila de la tabla-. Las condiciones de bsqueda que pueden especificarse en la clusula WHERE de la instruccin DELETE son las mismas disponibles en la clusula WHERE de la instruccin SELECT, como se describe en los captulos 6 y 9. Recurdese que las condiciones de bsqueda de la clusula WHERE de las sentencias SELECT puede especificar una sola fila o un conjunto de filas, segn la condicin de bsqueda concreta. Lo mismo puede decirse de la clusula WHERE de las sentenCias DELETE. Supngase, por ejemplo. que el cliente de Don Herminio, InterCorp (nmero de cliente 2126), ha llamado para cancelar todos sus pedidos. A continuacin se muestra la sentencia DELETE que elimina los pedidos de la tabla
SENTANTES,
PEDIDOS:
Eliminar todos los pedidos de InterCorp (nmero de cliente 2126).

DELETE FROM PEDIDOS WHERE CLIENTE ~ 2126 2 filas eliminadas.
La instruccin
DELETE En este caso, la clusula WHERE selecciona varias filas de la tabla PEDIDOS, y SQL elimina de la tabla todas las filas seleccionadas. Conceptualmente, SQL aplica la clusula WHERE a cada fila de la tabla PEDIDOS, elimina aquellas en las que la condicin de bsqueda da un resultado TRUE y conserva aquellas en las que la condicin de bsqueda da un resultado FALSE o NULL. Como este tipo de instruccin DELETE busca en la tabla las filas que hay que eliminar, a veces se denomina instruccin DELETE con bsqueda. Este trmino se usa para diferenciarla de otra forma de la instruccin DELETE, denominada instruccin DELETE posicionada, que siempre elimina una sola fila. La instruccin DELETE posicionada slo se aplica a SQL para programacin y se describe en el Captulo 17. A continuacin se ofrecen varios ejemplos ms de instrucciones DELETE con bsqueda:
La instruccin DELETE, que puede verse en la Figura 10.5, elimina las filas de datos seleccionadas de una sola tabla. La clusula FROM especifica la tabla destino que contiene las filas. La clusula WHERE especifica las filas de la tabla que deben eliminarse. Supngase que Herminio Jurez, el nuevo representante contratado anteriormente en este captulo, acaba de decidir abandonar la empresa. La instruccin DELETE que elimina su fila de la tabla REPRESENTANTES se muestra a continuacin.
Eliminar a Herminio Jurez de la base de datos.

DELETE FROM REPRESENTANTES WHERE NOMBRE ~ 'Herminio Jurez' 1 fila eliminada.
268
269
WHERE
Eliminar todos los pedidos realizados antes del 15 de noviembre de 1989.

DEL~TE
se de que son las que se desea eliminar y, s610 enlonces, utilizar la clusula en una instruccin DELETE.
FROM PEDIDOS WHERE FECHA_PEDIDO
<
'lS-NOV-89'
5 filas eliminadas.
DELETE con subconsulta
Eliminar lodas las filas de los clientes atendidos por Bruno Arteaga, Mara Jimnez o Daniel Ruidrobo (nmeros de empleado 105, 109 Y JOl).
DELETE FROM CLIENTES
WHERE REP_CLI IN (lOS, 109,
101)
7 filas eliminadas.
Las instrucciones DELETE con condiciones de bsqueda sencillas, como las de los ejemplos anteriores, seleccionan las filas para su eliminacin con base nicamente en el contenido de las propias filas. A veces la seleccin de filas debe hacerse en trminos de datos de otras tablas. Por ejemplo, supngase que se desea eliminar todos los pedidos tramitados por Susana' Santos. Sin conocer su nmero de empleado no se pueden hallar esos pedidos consultando nicamente la tabla PEDIDOS. Para hallar los pedidos se puede utilizar una consulta a dos tablas:
Eliminar todos los representantes contratados antes de julio de 1988 a los que no se les ha asignado todava cuota.
DELETE FROM REPRESENTANTES WHERE FECHA_CONTRATO < 'Ol-JUL-8S' AND CUOTA 15 NULL o filas eliminadas.
Hallar los pedidos tramitados por Susana Santos.

SELECT FROM WHERE AND NUM_PEDIDOS, IMPORTE PEDIDOS, REPRESENTANTES REP = NUM_EMPL NAME = 'Susana Santos' IMPORTE lS.OOO,ooE:
2.130,OO 1.896,OOE: 3.7S0.00 DELETE.
NUM_PEDIDO 112979 11306s 112993 113048
Eliminacin de todas las filas

La clusula WHERE de las instruccin DELETE es opcional, pero casi siempre se halla presente. Si se omite la clusula WHERE de una instruccin DELETE, se eliminan todas las filas de la tabla destino, como ocurre en este ejemplo:
Pero no se puede utilizar una reunin en una instruccin cin DELETE paralela es ilegal:
DELETE FROM PEDIDOS, REPRESENTANTES WHERE REP = NUM_EMPL ANO NOMBRE = 'Susana Santos'
La instruc-
Eliminar todos los pedidos.

DELETE FROM PEDIDOS 30 filas eliminadas.
Error: se ha especificado ms de una tabla en la clusula FROM
Aunque la instruccin DELETE produce una tabla vaca, no elimina la tabla PEDIDOS de la base de datos. La definicin de la tabla PEDIDOS y de sus columnas sigue almacenada en la base de datos. La tabla sigue existiendo y se puede seguir insertando filas nuevas en la tabla PEDIDOS con instrucciones INSERT. Para eliminar de la base de datos la definicin de la tabla hay que utilizar la instruccin DROP TASLE (que se describe en el Captulo 13). Debido al dao potencial que puede causar una instruccin DELETE de este tipo hay que tener la precaucin de especificar siempre una condicin de bsqueda y de asegurarse de que realmente selecciona las filas que se desea eliminar. Al utilizar SQL interactivo resulta una buena idea emplear primero la clusula WHERE en una instruccin SELECT para mostrar las filas seleccionadas. Hay que asegurar-
La manera de tratar esta solicitud es utilizar una de las condiciones de bsqueda de la subconsulta. A continuacin puede verse una forma vlida de la instruccin DELETE que maneja la solicitud:
Eliminar los pedidos tramitados por Susana Santos.

DELETE FROM PEDIDOS WHERE REP = (SELECT NUM_EMPL FROM REPRESENTANTES WHERE NOMBRE = 'Susana Santos') 4 filas eliminadas.
270
271
La subconsulta halla el nmero de empleado de Susana Santos, y la clusula WHERE selecciona los pedidos con el valor correspondiente. Como muestra este ejemplo, las subconsultas pueden desempear un papel importante en la instruccin DELETE, porque permiten eliminar filas en trminos de la informacin de otras tablas. A continuacin se ofrecen dos ejemplos ms de instrucciones DELETE que milizan condiciones de bsqueda con subconsullas:
Eliminar los clientes atendidos por representames cuyas ventas no lleguen al ochenta por ciento de su cuota.
DELETE FROM CLIENTES WHERE REP_CLI IN (SELECT NUM_EMPL FROM REPRESENTANTES
"/HERE VENTAS < (.8
CUOTA))
2 filas eliminadas.
Eliminar cualquier representante cuyos pedidos actuales sean menos del dos por ciento de su cuota.
DELETE FROM REPRESENTANTE WHERE (.02 * CUOTA) > (SELECT SUM(IMPORTE) FROM PEDIDOS WHERE REP = NUM_EMPL)
de la fila de la tabla CLIENTES que est examinando la instruccin DELETE. La subconsulta de este ejemplo es una subconsulta correlacionada, como se describe en el Captulo 9. Las referencias externas suelen hallarse en las subconsultas de las instrucciones DELETE, ya que implementan la reunin entre la(s) tablas(s) de la subconsulta y la tabla destino de la instruccin DELETE. En el estndar SQL1, una restriccin del emple<? de las subconsultas en las instrucciones DELETE evita que la tabla destino aparezca en la clusula FROM de una .subconsulta o de cualquiera de sus subconsultas en cualquier nivel de anidamiento. Esto evita que las subconsultas hagan referencia a la tabla destino (algunas de cuyas filas pueden haberse eliminado ya), salvo para las referencias externas a la fila que est examinando en ese momento la condicin de bsqueda de la instruccin DELETE. El estndar SQL2 elimina esta restriccin al especificar que la instruccin DELETE debe tratar las subconsultas de ese tipo como si se aplicara a toda la tabla destino, antes de que se haya eliminado ninguna fila. Esto provoca una mayor sobrecarga del SGBD (que debe tratar el procesamiento de la subconsulta y la eliminacin de las filas con ms cuidado), pero el comportamiento de esta instruccin queda bien definido por el estndar.
Modificacin de datos de la base de datos

Generalmente, los valores de los elementos de datos almacenados en las bases de datos se modifican cuando se producen cambios equivalentes en el mundo exterior. Por ejemplo. en la base de datos de ejemplo: Cuando un cliente llama para modificar la cantidad de un pedido, hay que modificar la columna CANTIDAD de la fila correspondiente de la tabla PEDIDOS. Cuando un jefe se traslada de una oficina a otra, hay que modificar la columna JEF de la tabla OFICINAS y la columna OFICINA_REP de la tabla REPRESENTANTES para que reflejen el nuevo puesto. Cuando se elevan un cinco por ciento las cuotas de ventas en la oficina comercial de Navarra, hay que modificar la columna CUOTA de las filas correspondientes de la tabla REPRESENTANTES. En cada caso los valores de los datos de. la base de datos se actualizan para hacer que la base de datos siga siendo un modelo preciso del mundo real. La unidad mnima de datos que puede modificarse en una base de datos es una sola columna de una nica fila.
1 fila eliminada.
Las subconsultas en la clusula WHERE pueden anidarse igual que en la clusula WHERE de la instruccin SELECT. Tambin pued.en contener referencias externas a la tabla destino de la instruccin DELETE. A este respecto, la clusula FROM de la instruccin DELETE funciona igual que la clusula FROM de la instruccin SELECT. A continuacin se ofrece un ejemplo de solicitud de eliminacin que necesita una subconsulta con una referencia externa:
Eliminar los clientes que no hayan realizado pedidos desde ellO de noviembre de 1989.
DELETE PROM CLIENTES WHERE NOT EXISTS (SELECT PROM PEDIDOS WHERE CLIENTE = NUM_CLI AND FECHA_PEDIDO < 'lO-NOV-89')
16 filas eliminadas.
TES
Conceptualmente, esta instruccin DELETE opera fila a fila por la tabla CLIENY verificando la condicin de bsqueda. Para cada cliente la subconsulta selecciona los pedidos realizados antes de la fecha de corte. La referencia a la columna NUM_CLI de la subconsulta es una referencia externa al nmero de cliente
La instruccin
UPDATE
La instruccin UPDATE, que puede verse en la Figura 10.6, modifica los valores de una o varias columnas de las filas seleccionadas de una sola tabla. La tabla destino
272

WHERE OFICINA_REP = 12
273
l- UPDATE nombre-tabla SET
fnombre-co,umna
I
expresin
3 filas actualizadas.
WHERE condicin-de-bsqueda
Figura 10.6. Diagrama sintctico de la instruccin

UPDATE.
En este caso la clusula WHERE selecciona varias filas de la tabla REPRESENY se modifican en todas ellas los valores de las columnas OFICINA_REP y CUOTA. Conceptualmente, SQL procesa la instruccin UPDATE recorriendo la tabla REPRESENTANTES fila a fila, actualizando las filas para las que la condicin de bsqueda da un resultado TRUE y saltando aquellas para las que da un resultado FALSE o NULL. Como busca en la tabla, esta modalidad de la instruccin UPDATE se denomina a veces sentencia UPDATE con bsqueda. Este trmino la distingue de una forma diferente de la instruccin UPDATE, denominada instruccin UPDATE posicionada, que siempre actualiza una sola fila. La instruccin UPDATE slo se aplica a SQL para programacin y se describe en el Captulo 17. A continuacin se ofrecen varios ejemplos ms de instrucciones UPDATE con bsqueda:
TANTES
que hay que actualizar se nombra en la instruccin, y hay que tener los permisos necesarios para actualizar la tabla y cada una de las columnas que vayan a modificarse. La clusula WHERE selecciona las filas de la tabla que hay que modificar. La clusula SET especifica las columnas que se van a actualizar y calcula sus nuevos valores. A continuacin se ofrece un ejemplo de la instruccin que cambia el lmite de crdito y el representante de un cliente:
Reasignar todos los clientes atendidos por los nmeros de empleado 105, 106 o 107 al empleado nmero 102.
UPDATE CLIENTES SET REP_CLI = 102 WHERE REP_CLI IN (105, 106, 107) 5 filas actualizadas.
Elevar el lmite de crdito de Acme a 60.000 Y reasignarlo a Mara Jimnez (nmero de empleado 109).
UPDATE CLIENTES
Asignar una cuota de 100.000 a cualquier representante que no tenga cuota actualmente.
UPDATE REPRESENTANTES SET CUOTA = 100000.00 WHERE CUOTA 15 NULL 1 fila actualizada.
SET LIMITE_CRED1TO = 60000.00, WHERE EMPRESA = 'Acme' 1 fila actualizada.
REP_CLI
109
En este ejemplo la clusula WHERE identifica una sola fila de la tabla CLIENTES, y la clusula SET asigna valores nuevos a dos de las columnas de esa fila. La clusula WHERE es exactamente la misma que se utilizara en una instruccin DELETE o SELECT para identificar la fila. De hecho, las condiciones de bsqueda que pueden aparecer en la clusula WHERE de las instrucciones UPDATE son exactamente las mismas que las disponibles en las instrucciones SELECT y DELETE. Al igual que la instruccin DELETE, la instruccin UPDATE puede actualizar varias filas al tiempo con la condicin de bsqueda adecuada, como en este ejemplo:
Trasladar a todos los representantes de la oficina de Castelln (nmero 12) a la oficina de Navarra (nmero 11) Y bajar sus cuotas un diez por ciento.
UPDATE REPRESENTANTES SET OFICINA_REP = 11, CUOTA .9 * CUOTA
La clusula SET de la instruccin UPDATE es una lista de asignaciones separadas por comas. Cada asignacin identifica una columna destino que hay que actualizar y especifica el modo de calcular su nuevo valor. Cada columna destino slo debe aparecer una vez en la lista; no debe haber dos asignaciones para la misma columna destino. La especificacin ANSmSO obliga a que se utilicen nombres no cualificados para las columnas destino, pero algunas implementaciones de SQL permiten los nombres de columna cualificados. En todo caso, no puede haber ninguna ambigedad en los nombres de las columnas, ya que deben hacer referencia a las columnas de la tabla destino. La expresin de cada asignacin puede ser cualquier expresin de SQL vlida que d como resultado un valor del tipo de datos adecuado para la columna destino. La expresin debe ser calculable en trminos de los valores de la fila que se
274

UPDATE CLIENTES SET LIMITE_CREDITO = LIMITE_CREDITO + SOOO.OO WHERE NUM_CLI IN (SELECT DISTINCT CLIENTE FROM PEDIDOS WHERE IMPORTE> 25000.00)
275
est actualizando en la tabla destino. En la mayor parle de las implementaciones de los SGBD la expresin no puede incluir funciones de columna ni subconsultas. Si una expresin de la lista de asignaciones hace referencia a una de las columnas de la tabla destino, el valor utilizado para calcular la expresin es el valor de esa columna en la fila actual antes de que se aplique ninguna actualizacin. Lo mismo ocurre con las referencias a columnas que tienen lugar en la clusula WHERE. Por ejemplo, considrese la instruccin UPDATE (algo foriada):
UPDII.TE OFICINAS
Reasignar todos los clientes atendidos por representantes cuyas ventas estn por debajo del ochenta por ciento de su cuota.
400000.00, 400000.00 VENTAS
5ET CUOTA WHERE CUOTA
CUOTA UPDATE CLIENTES SET REP_CLI : lOS WHERE CUST_REP IN (SELECT NUM_EMPL FROM REPRESENTANTES WHERE VENTAS < (.8 CUOTAl)
<
Antes de la actualizacin, Bruno Arteaga tena un valor de CUOTA de 350.000 Y un valor de VENTAS de 367.911 . Tras la actualizacin su fila tiene un valor de VENTAS de 350.000 , no de 400.000 . El orden de las asignaciones en la clusula, por tanto, carece de importancia; las asignaciones pueden especificarse en cualquier orden.
Actualizacin de todas las filas

La clusula WHERE de la instruccin qPDATE es opcional. Si se omite la clusula WHERE, se actualizan todas las filas de la tabla destino, como en este ejemplo:
Hacer que todos los representantes que atienden a ms de tres cliellles informen directamente a Samuel Clavel (nmero de empleado /06).
UPDATE REPRESENTANTES SET JEFE = 106 WHERE 3 < (SELECT COUNT{*) FROM CLIENTES WHERE REP_CLI
/ncremenrar todas las cuotas un cinco por ciento.

UPDATE REPRESENTANTES SET CUOTA = 1.05 * CQUOTA 10 filas actualizadas.
NUM_EMPL)
1 fila actualizada.
A diferencia de la instruccin DELETE, en la que la clusula WHERE casi nunca se omite. la instruccin UPDATE sin clusula WHERE lleva a cabo una labor til. Bsicamente, realiza una actualizacin masiva de toda la tabla, como se demuestra en el ejemplo anterior.
UPDATE
con subconsulta
Al igual que con la instruccin DELETE, las subconsultas pueden desempear un papel importante en la instruccin UPDATE, ya que permiten seleccionar las filas que hay que actualizar con base en la informacin contenida en otras tablas. A continuacin se ofrecen varios ejemplos de instrucciones UPDATE que utilizan subconsultas:
/ncrement.ar en 5.000 el lmile de crdito de todos los clientes que hayan realizado pedidos por encima de 25.000 f.
Al igual que en la instruccin DELETE, las subconsultas de la clusula WHERE de la instruccin UPDATE pueden anidarse a cualquier nivel y pueden contener re ferencias externas a la tabla destino de la instruccin UPDATE. La columna NUM_EMPL de la subconsulta del ejemplo anterior es una de esas referencias externas; hace referencia a la columna NUM_EMPL de la fila de la tabla REPRESENTANTES que est verificando la instruccin UPDATE. La subconsulta de este ejemplo es una subconsuIta correlacionada, como se describe en el Captulo 9. Las referencias externas suelen hallarse en las subconsultas de las instrucciones UPDATE, ya que implementan la reunin entre las tablas de la subconsulla y la tabla destino de la instruccin UPDATE. Se aplica la misma restriccin de SQLI que a la instruccin DELETE: la tabla destino no puede aparecer en la clusula FROM de ninguna subconsulta en ningn nivel de anidamiento. Esto evita que las subconsultas hagan referencia a la tabla destino (algunas de cuyas filas puede que ya se hayan actualizado). Por ello, todas las referencias en las subconsultas a la tabla destino son referencias externas a la fila de la tabla destino que est verificando la clusula WHERE de la instruccin UPDATE. El estndar SQL2 tambin elimin esta restriccin y especifica que las referencias a la tabla destino en las subconsultas se evalan como si no se hubiera actualizado ninguna fila de la tabla destino.
276
Resumen
Este captulo describe las instrucciones de SQL que se utilizan para modificar el contenido de las bases de datos:
CAPTULO
11
La instruccin INSERT sobre una sola fila aade una fila de datos a una tabla. Los valores para la nueva fila se especifican en la instruccin como constantes. La instruccin INSERT sobre varias filas aade cero o ms filas a una tabla. Los valores para las nuevas filas provienen de una consulta, que se especifica como parte de la instruccin INSERT. La instruccin DELETE elimina cero o ms filas de datos de una tabla. Las filas que hay que eliminar se especifican mediante una condicin de bsqueda. La instruccin UPDATE modifica los valores de una o ms columnas en cero O ms filas de una tabla. Las filas que hay que actualizar se especifican mediante una condicin de bsqueda. Las columnas que hay que actualizar y las expresiones que calculan sus nuevos valores se especifican en la instruccin UPDATE. A diferencia de la instruccin SELECT. que puede operar sobre varias tablas, las instrucciones INSERT, DELETE y UPDATE slo trabajan sobre una tabla a la vez. La condicin de bsql!eda utilizada en las instrucciones DELETE y UPDATE tiene la misma forma que la condicin de bsqueda de las instrucciones
SELECT.
Integridad de datos
La expresin integridad de los datos hace referencia a la correccin y completitud de los datos de una base de datos. Cuando se modifica el contenido de una base de datos con las instrucciones INSERT, DELETE O UPDATE, se puede perder, de muchas maneras diferentes. la integridad de los daLas almacenados. Por ejemplo: Se pueden aadir a la base de datos datos no vlidos, como puede ser un pedido que especifique un producto inexistente. Se pueden modificar los datos existentes y asignarles valores incorrectos, corno puede ocurrir al trasladar a un representante a una oficina inexistente. Se pueden perder las modificaciones realizadas en la base de datos debido a un error del sistema o a un fallo del suministro elctrico. Se pueden aplicar las modificaciones realizadas slo parcialmente, como puede ocurrir al aadir un pedido para un producto sin ajustar la cantidad disponible para la venta. Uno de los papeles ms importantes de los SGBD relacionales es el mantenimiento de la integridad de los datos almacenados en la medida en que sea posible. Este captulo presenta las caractersticas del lenguaje SQL que ayudan en esta tarea al SGBD.
Concepto de la integridad de datos

Para mantener la consistencia y correccin de los datos, los SGBD relacionales suelen imponer una o varias restricciones de integridad de datos. Estas restricciones limitan los valores de datos que pueden introducirse en la base de datos o crearse mediante una actualizacin de la base de datos. En las bases de datos relacionales se suelen encontrar diferentes tipos de restricciones de integridad de datos, entre ellas las siguientes:
277
~
278
Captulo 11: Integridad de datos
279
Datos requeridos. Algunas columnas de la base de dalOs deben contener un valor de datos vlido en cada fila; no se permite que estn en blanco o contengan valores NULL. En la base de datos de ejemplo cada pedido debe tener un cliente asociado que lo realice. Por tanto, la columna CLIENTE de]a tabla PEDIDOS es una columna requerida. Se puede pedir al SGBD que impida los valores NULL en esta columna. Comprobacin de la validez. Cada columna de una base de dalos tiene un dominio, un conjunto de valores de datos que son legales para esa columna. La base de datos de ejemplo utiliza nmeros de pedido a partir de 100001,
de modo que el dominio de la columna NUM_PEDIDO son los enteros positi-
Consistencia. Muchas transacciones del mundo real provocan mltiples actualizaciones de las bases de datos. Por ejemplo, la aceptacin del pedido de un cliente puede suponer la adicin de una fila a la tabla PEDIDOS, el incremento de la columna VENTAS de la tabla REPRESENTANTES para la persona que haya tramitado el pedido y el incremento de la columna VENTAS de la tabla OFICINAS para la oficina a la que est asignado ese representante. Las operaciones INSERT y UPDATE deben realizarse todas en orden para que la base de datos contine en un estado consistente y correcto. Se puede pedir al SGBD que haga cumplir este tipo de regla de consistencia o que incluya aplicaciones que implementen este tipo de reglas. El estndar ANSI/ISO de SQL especifica algunas de las restricciones de integridad de datos ms sencillas. Por ejemplo, alberga la restriccin de datos necesarios y se implementa de una manera uniforme en casi todos los productos comerciales de SQL. Las restricciones ms complejas, como la de las reglas de negocio, no vienen especificadas en el estndar ANSI/lSO, y hay una amplia variacin en las tcnicas y en la sintaxis de SQL utilizadas para albergarlas. Las.caractersticas de SQL que alojan las cinco primeras restricciones de integridad se describen en este captulo. El mecanismo de las transacciones de SQL, que alberga la restriccin de consistencia, se describe en el Captulo 12.
vos mayores de cien mil. De manera parecida, los nmeros de empleado de la columna NUM_EMPL deben hallarse en el rango de 101 a 999. Se puede pedir al SGBD que evite otros valores de datos en estas columnas. Integridad de las entidades. La clave primaria de una tabla debe contener en cada fila un valor nico que sea diferente de los valores del resto de las filas. Por ejemplo, cada fila de la tabla PRODUCTOS tiene un conjunto nico de valores en sus columnas ID_FAS e ID_PRODUCTO, que identifican de ma.nera unvoca al producto representado por esa fila. Los valores duplicados son ilegales, ya que no permitiran que la base de datos distinguiera un producto de otro. Se puede pedir al SGBD que haga cumplir esta restriccin de unicidad de los valores. Integridad referencial. Las claves externas de las bases de datos vinculan cada fila de la tabla hijo que contenga la clave externa con la fila de la tabla padre que contiene el valor correspondiente de la clave primaria. En la base de datos de ejemplo, el valor de la columna OFICINA_REP de cada fila de la tabla SALESREPS relaciona al representante representado por esa fila con la oficina en la que trabaja. La columna OFICINA_REP debe contener un valor vlido de la columna OFICINA de la tabla OFICINAS, o el representante estar asignado a una oficina no vlida. Se puede pedir al SGBD que haga cumplir esta restriccin de claves externa/primaria. Otras relaciones de datos. La situacin del mundo real modelada por una base de datos suele tener restricciones adicionales que regulan los valores legales de los datos susceptibles de aparecer en la base de datos. En particular. en la base de datos de ejemplo. puede que el vicepresidente comercial desee asegurarse de que la cuota objetivo de cada oficina no supera el total de las cuotas objetivo de los representantes de esa oficina. Se puede pedir al SGBD que compruebe las modificaciones de las cuotas objetivo de la oficina y de los representantes para asegurarse de que sus valores estn restringidos de esta manera. Reglas de negocio. Las actualizaciones de las bases de datos pueden quedar restringidas por las reglas de negocio que regulan las transacciones del mundo real que se representan mediante las actualizaciones. Por ejemplo, puede' que la empresa que utiliza la base de datos de ejemplo tenga una regla de negocio que prohba la aceptacin de pedidos para los que no haya existencias suficientes. Se puede pedir al SGBD que compruebe cada nueva fila que se aada a la tabla PEDIDOS para asegurarse de que el valor de su columna CANTIDAD no viola esta regla de negocio.
Datos requeridos
La restriccin para la integridad de los datos ms sencilla exige que las columnas contengan valores que no sean NULL. El estndar ANSI/lSO y la mayor parte de los productos comerciales de SQL admiten esta restriccin al permitir que se declare una columna como NOT NULL cuando se crea la tabla que contiene esa columna. La restriccin NOT NULL se especifica como parte de la instruccin CREATE TABLE, que se describe en el Captulo 13. Cuando se declara una columna como NOT NULL, el SGBD hace que se cumpla la restriccin asegurndose de que: Cada instruccin INSERT que aada filas nuevas a la tabla debe especificar un valor de datos que no sea NULL para esa columna. Los intentos de insertar una fila que contenga un valor NULL (tanto explcita como implcitamente) da lugar a un error. Cada instruccin UPDATE que actualice la columna debe asignarle un valor de datos que no sea NULL. Los intentos de actualizar la columna con un valor NULL tambin dan lugar a un error. Un inconveniente de la restriccin NOT NULL es que generalmente se debe especificar cundo se crea la tabla. Generalmente no se puede ir a una tabla ya creada y desautorizar los valores NULL en una columna. Habitualmente este inconveniente no es importante, porque al crear la tabla resulta evidente qu columnas deben permitir valores NULL y cules no. Tambin hay un problema lgico poten-
---!...-
280
281
cial con la adicin de restricciones NOT NULL a tablas ya existentes. Si una o varias columnas de la tabla ya contienen valores NULL, hay que indicar al SGBD lo que
debe hacer con esas filas. Representan objetos del mundo real, pero desde ese
momento violan la restriccin de datos (recin) impuesta. La imposibilidad de adicin de restricciones NOT NULL a las tablas ya existentes tambin es consecuencia, en parte, del modo en que la mayor parte de los SGBD implementan internamente los valores NULL. Generalmente, los SGBD reservan un byte extra por cada columna en cada fila de datos almacenada que permite valores NULL. El byte extra sirve como indicador de valor nulo para la columna, y se le da un valor especificado para indicar los valores NULL. Cuando se define una columna como NOT NULL, el byte indicador nose halla presente, lo que aborra espacio de almacenamiento en disco. La adicin y eliminacin dinmica de restricciones NQT NULL exigira, por tanto, la reconfiguracin sobre la marcha de las filas almacenadas en el disco, lo que no resulta prctico en bases de datos de gran tamao.
datos, por lo que no se puede utilizar para buscar valores nicos o relaciones entre claves primarias y externas. SQL Server tambin ofrece una posibilidad de validacin de datos al permitir la creacin de reglas que determinen los valores de los datos que pueden introducirse legalmente en cada columna. SQL Server comprueba la regla cada vez que se intenta aplicar INSERT O UPDATE a la tabla que contiene esa columna. A diferencia de los procedimientos de validacin de DB2, las reglas de SQL Server se escriben en el dialecto de Transacl-SQL que utiliza SQL Server. Por ejemplo, a continua cin se muestra una instruccin de Transact~SQL que establece una regla para la columna CUOTA de la tabla REPRESENTANTES:
CREATE RULE LIMITE_CUOTA AS @VALUE BETWEEN 0.00 AND 500000.00
Comprobacin simple de validez

El estndar SQLl ofrece un soporte limitado de las restricciones de los valores legales que pueden aparecer en las columnas. Cuando se crea una tabla se le asigna un tipo de datos a cada una de las columnas, y el SGBD se asegura de que slo se introduzcan en esa columna datos del tipo especificado. Por ejemplo, la columna NUM_EMPL de la tabla REPRESENTANTES est definida como INTEGER, y el SGBD generar un mensaje de error si alguna instruccin INSERT o UPDATE intenta almacenar en esa columna una cadena de caracteres o un nmero decimal. No obstante, el estndar SQLI y muchos productos comerciales de SQL no ofrecen ningn modo de restringir una columna a determinados valores de datos. El SGBD no ofrecer ningn obstculo a la insercin en una fila de REPRESENTANTES del nmero de empleado 12345, aunque los nmeros de empleados de la base de datos de ejemplo tengan, por convenio, slo tres cifras. Tambin se aceptara una fecha de contratacin de 25 de diciembre, aunque la empresa est cerrada el da de Navidad. Algunas implementaciones comerciales de SQL ofrecen caractersticas suplementarias para la comprobacin de los valores legales de los datos. En DB2, por ejemplo, se puede asignar a cada tabla de la base de datos el procedimiento de validacin correspondiente, un programa escrito por el usuario que comprueba si los valores de los datos son vlidos. DB2 invoca el procedimiento de validacin cada vez que una instruccin de SQL intenta modificar una fila de la tabla o insertar una nueva y presenta al procedimiento de validacin los valores de las columnas propuestos para esa fila. El procedimiento de validacin comprueba los datos e indica, mediante el valor de su respuesta, si son aceptables. El procedimiento de validacin es un programa convencional (escrito en ensamblador S/370 o en PUl, por ejemplo) que puede llevar a cabo las comprobaciones de valores que hagan falta, incluy~ndo comprobaciones de rangos y de consistencia interna de la fila. No obstante, el procedimiento de validacin no puede tener acceso a la base de
Esta regla evita que se introduzca o se actualice una cuota con un valor negativo o mayor de 500.000 . Como se muestra en el ejemplo, SQL Server permite asignar un nombre a la regla (LIMITE_CUOTA, en este caso). Sin embargo, corno ocurre con los procedimientos de validacin de DB2, las reglas de SQL Server no pueden hacer referencia a columnas ni a otros objetos de la base de datos. El estndar SQL2 ofrece un soporte ms amplio de las comprobaciones de validez mediante dos caractersticas diferentes -las restricciones de comprobacin de las columnas y los dominios. Los dos dan al creador de la base de datos una manera de indicar al SGBD el modo de determinar si un valor de datos concreto es vlido. La caracterstica de la comprobacin de restriccion~ especifica la prueba de validez de los datos para una sola columna. La caracter~tica del dominio permite especificar una sola vez la prueba de validez y reutilizarla en la definicin de muchas columnas diferentes cuyos valores legales de datos sean iguales..
Restricciones de comprobacin de columnas (SQL2)

Las restricciones de comprobacin de SQL2 son condiciones de bsqueda, como las condiciones de bsqueda de las clusulas WHERE, que producen valores verdadero o falso. Cuando se especifica una restriccin de comprobacin para una columna, el SGBD comprueba de manera automtica el valor de esa columna cada vez que se inserta o que se actualiza una fila para asegurarse de que la condicin de bsqueda se cumple. En caso contrario, la instruccin INSERT o UPDATE falla. Las restricciones de comprobacin de las columnas se especifican como parte de la definicin de las columnas en la instruccin CREATE TABLE, que se describe en el Captulo 13. Considrese este fragmento de una instruccin CREATE TABLE, modificado a partir de la definicin de la base de datos de ejemplo para incluir tres restricciones de comprobacin:
CREATE TABLE REPRESENTANTES (NUM_EMPL INTEGER NOT NULL
282

CHECK (NUM_EMPL BETWEEN 101 AND 199), EDAD INTEGER CHECK (EDAD >= 18), CREATE TABLE REPRESENTANTES (NUM_EMPL ID_EMPLEADO_VALIDO, EDAD INTEGER CHECK (EDAD >= 18),
Capitulo 11: Integridad de datos
283
CUOTA MONEY CHECK (MONEY >= 0.01
CUOTA MONEY CHECK (MONEY >= 0.0)
La primera restriccin (para la columna NUM_EMPL) exige que los nmeros de empleado vlidos sean nmeros de tres cifras comprendidos entre 101 y 199. La segunda restriccin (para la columna EDAD) evita de manera parecida la contratacin de menores de edad. .La tercera restriccin (para la columna CUOTA) evita que un representante tenga una cuota inferior a 0,00 . Estas tres restricciones de comprobacin de columnas son ejemplos muy sencillos de la posibilidad especificada por el estndar SQL2. En general, los parntesis que siguen a la palabra clave CHECK pueden contener cualquier condicin de bsqueda vlida que tenga sentido en el contexto de la definicin de una columna. Con esta flexibilidad las restricciones de comprobacin pueden comparar varios valores de dos columnas diferentes de la tabla o, incluso, comparar un valor de datos propuesto con otros valores de la base de datos. Estas posibilidades se describen con mayor detalle en el apartado Restricciones avanzadas, ms adelante en este mismo captulo.
La ventaja de emplear un dominio es que, si las columnas de otras tablas contienen tambin nmeros de empleado, se puede utilizar varias veces el nombre del dominio, lo que simplifica las definiciones de las tablas. La tabla OFICINAS contiene una de esas columnas:
CREATE TABLE OFICINAS (OFICINA INTEGER NOT NULL, CIUDAD VARCHAR(15) NOT NULL, REGION VARCHAR(lOj NOT NULL, JEF ID_EMPLEADO_VALIDO, OBJETIVO MONEY, VENTAS MONEY NOT NULL
Dominios (SQL2)
Los dominios de SQL2 generalizan el concepto de restriccin de comprobacin y permiten aplicar de manera sencilla la misma restriccin de comprobacin a muchas columnas diferentes de una base de datos. Un dominio es un conjunto de valores legales de datos. Tanto para especificar un dominio como para asignarle un nombre de dominio se emplea la instruccin de SQLZ CREATE OOMAIN, que se describe en el Captu!o 13. Al igual que con la definicin de restriccin de com~ probacin, se emplea una condicin de bsqueda para definir el rango de los valores legales de los datos. Por ejemplo, a continuacin se ofrece una instruccin CREATE DOMAIN de SQL2 para crear el dominio ID_EMPLEADO_VALIDO, que incluye a todos los nmeros de empleado:
CREATE DOMAIN ID_EMPLEADO_VALIDO INTEGER CHECK (VALUE BETWEEN 101 AND 199)
Otra ventaja de los dominios es que la definicin de los datos vlidos (como los nmeros de empleado vlidos de este ejemplo) se almacena en un punto central de la base de datos. Si la definicin se modifica posteriormente (por ejemplo, si la empresa crece y se deben permitir nmeros de empleados del rango 200-299), resulta mucho ms sencillo modificar una definicin de dominio que muchas restricciones de columnas dispersas por toda la base de datos. En las grandes bases de datos empresariales puede haber literalmente cientos de dominios definidos, y las ventajas de los dominios de SQL2 en la gestin de los cambios pueden ser muy notables.
Integridad de las entidades

La clave primaria de cada tabla debe tener un valor nico para cada fila de la tabla, o la base de datos perder su integridad como modelo del mundo exterior. Por ejemplo, si dos filas de la tabla REPRESENTANTES tuvieran el valor 106 en la columna NUM~EMPL, resultara imposible distinguir la fila que representa realmente a la entidad del mundo real asociada con ese valor de la clave -Bruno Arleaga, que es el empleado nmero 106-. Por este motivo, el requisito de que las claves prima. rias tenganvalores nicos se denomina restriccin de integridad de las entidades.
Una vez definido el dominio ID_EMPLEADa_vALIDO, puede que se emplee para definir las columnas de las tablas de la base de datos en lugar del tipo de datos. Aprovechando esta posibilidad, la instruccin CREATE TABLE de ejemplo para la tabla REPRESENTANTES tendra el aspecto siguiente:
284
285
En las primeras bases de datos comerciales de SQL no se daba soporte a las claves primarias, pero hoy en da resulta muy frecuente. Se aadi a DB2 en 1988 y al estndar ANSlIISO original en una actualizacin intermedia, antes de que apareciera el estndar SQL2 completo. La clave primaria se especifica como parte de la instruccin CREATE TABLE, que se describe en el Captulo 13. La definicin de la base de datos de ejemplo del Apndice A incluye definiciones de claves primarias para todas las tablas, siguiendo la sintaxis del estndar ANSI/ISO. Cuando se especifica una clave primaria para una tabla, el SGBD comprueba de manera automtica la unicidad del valor de la clave primaria de cada instruccin INSERT o UPDATE ejecutada sobre la tabla, Los intentos de insertar una fila con un valor duplicado de la clave primaria o de actualizar una fila de modo que su clave primaria sea un valor duplicado fallarn y generarn un mensaje de error.
al valor NULL el SGBD no puede decidir de manera concluyente si la clave primaria duplica otro valor que ya se halle en la tabla. La respuesta debe ser quizs, en funcin del valor real de los datos que faltan (NULL). Por este motivo, el estndar SQL exige que cada columna que forme parte de una clave primaria se declare como NOT NULL. Se aplica la misma restriccin a cada columna que figure en una restriccin de unicidad. Conjuntamente, estas restricciones aseguran que las columnas que se supone que contienen valores nicos en cada fila de la tabla lo hagan realmente.
Integridad referencial
El Captulo 4 estudiaba las claves primarias, las claves externas y las relaciones padre/hijo que crean entre las tablas. La Figura 11.1 muestra las tablas REPRESENTANTES Y OFICINAS e ilustra el modo en que trabajan las claves primarias y las externas. La columna OFICINA es la clave primaria de la tabla OFICINAS. e identifica de manera unvoca cada fila. La columna OFICINA_REP, de la tabla REPRESENTANTES, es una clave externa de la tabla OFICINAS. Identifica la oficina a la que est asignado cada representante. Las columnas OFICINA_REP y OFICINA crean una relacin padrelhijo entre las filas OFICINAS y REPRESENTANTES. Cada fila OFICINAS (padre) tiene cero o
Otras restricciones de unicidad

A veces resulta adecuado exigir que una columna que no es la clave primaria de la tabla contenga un valor nico en cada fila. Por ejemplo, supngase que se desea restringir los datos de la labIa REPRESENTANTES de modo que dos representantes no puedan tener exactamente el mismo nmero en la tabla. Este objetivo se puede conseguir imponiendo una restriccin de unicidad a la columna NOMBRE. El SGBD hace que se cumpla la restriccin de unicidad del mismo modo en que hace que se cumpla la restriccin de clave primaria. Cualquier intento de insertar o actualizar una fila de la tabla que viole la restriccin de unicidad fracasar. El estndar ANSUISO para SQL utiliza la instruccin CREATE TABLE para especificar las restricciones de unicidad para las columnas o combinaciones de columnas. No obstante, las restricciones de unicidad se implementaron en DB2 mucho antes de la publicacin del estndar ANSIIISO, y DB2 las transform en parte de su instruccin CREATE INDEX. Esta instruccin es una de las instrucciones para administracin de la base de datos que tratan del almacenamiento fsico de la base de datos en el disco. Normalmente, el usuario de SQL no tiene que preocuparse de estas instrucciones en absoluto; slo las utiliza el administrador de la base de datos. Muchos productos comerciales de SQL siguieron la prctica original de DB2 en lugar del estndar ANSrnSO para las restricciones de unicidad y exigieron el empleo de una instruccin CREATE INDEX. Las versiones posteriores de DB2 aadieron una restriccin de unicidad a la instruccin CREATE TABLE. La mayor parte de los otros fabricantes comerciales han seguido el mismo camino y, hoy en da, incluyen el estndar ANSurSO para la restriccin de unicidad.
Tabl Ul'.1C~NAl::i .......a OFICINAS CIUDAD 22 Daimiel 11 Navarra 12 Castelln 13 Almera 21 Len
REGIN Oeste Este Este Este Oeste
JEF
OBJETIVO
300.000,00 186.042,00 575.000,00 692.637,00 lO' aoo.ooo,OO 735.042,00 NULL 350.000,OO 367.911,00 108 725.000,OO 835.915,OO
108 106
t
incipal
Refer
Unicidad y valores NULL

Los valores NULL plantean un problema cuando aparecen en la clave primaria de una tabla o en una columna especificada en una restriccin de unicidad. Supngase que se in,tenta insenar una fila con una clave primaria que sea NULL (o parcialmente NULL, si la clave primaria est compuesta por ms de una ~olumna). Debido
Tabla REPRESENTANTES I NUM EMPL NOMBRE 105 Bruno Arteaga 109 Maria Jimnez 102 Susana Santos 106 samuel Clavel lO' Bernardo Snchez 101 Daniel Ruidrobo 110 Toms Saz 108 Len Freire 103 Pablo Cruz 107 Neus Azcrate
EDlID
37 31 '8 S2 33 45
"
62 29 49
.... , " .... , , .... OFICINA REP PUESTO 13 Representante 11 Representante 21 Representante 11 VP Ventas 12 Jefe Ventas 12 Representante NULL Representante 21 Jefe Ventas 12 Representante
........
22 Re~resentante
Figura 11.1.
Una referencia a clave primaria/clave externa.
---"--
286
287
ms filas REPRESENTANTES (hijos) con nmeros de oficina coincidentes. De manera parecida, cada fila REPRESENTANTES (hijo) tiene exactamente una fila OFICINAS (padre) con un nmero de oficina coincidente. Supngase que se ha intentado insertar una nueva fila en la tabla REPRESENTANTES que contena un nmero de oficina no vlido, como en este ejemplo:
INSERT INTQ REPRESENTANTES
VALUES (115,
(NUM_EMPL, NOMBRE. OFICINA_REP, FECHA_CONTRATO, VENTAS)

31, 37, 'Ol-ABR-90',
EDAD,
'Gabriel Surez',
0.00)
l'
l'
Aparentemente, no hay nada errneo en esta instruccin INSERT. De hecho, muchas implementaciones de SQL aadirn la fila con xito. La base de datos mostrar que Gabriel Surez trabaja en la oficina nmero 31, aunque no aparezca ninguna oficina nmero 31 en la tabla OFICINAS. La fila recin insertada rompe claramente la relacin padrelhijo entre las tablas OFICINAS y REPRESENTANTES. De hecho, el nmero de oficina de la instruccin INSERT es probable que sea un error -puede que el usuario pretendiera escribir el nmero de oficina 11, 21 o 13. Parece claro que se debe obligar a que cada valor legal de la columna OFICINA_REP coincida con algn valor que aparezca en la columna OFICINA. Esta regla se conoce como restriccin de integridad referencial. Asegura la integridad de las relaciones padre/hijo creadas por las claves primarias y externas. La integridad referencial ha sido una parte principal del modelo relacional desde que Codd la propuso por primera vez. Sin embargo. las restricciones de integridad referencial no se incluyeron en el prototipo de IBM del SGBD SystemIR, ni en las primeras versiones de DB2 ni de SQUDS. IBM aadi el soporte de la integridad referencial a DB2 en 1989, y la integridad referencial se aadi al estndar SQLl tras su edicin inicial. La mayor parte de los fabricantes de SGBD de hoy en da soportan las restricciones de integridad referencial.
Actualizacin la clave externa de una fila hijo. Se trata de una forma diferente del problema anterior. Si la clave externa (OFICINA_REP) se modifica mediante una instruccin UPDATE, el nuevo valor debe coincidir con uno de la clave primaria (OFICINA) de la tabla padre (OFICINAS). En caso contrario, la fila actualizada ser hurfana. Eliminacin de una fila padre. Si se elimina una fila de la tabla padre (OFICINAS) que tenga uno o varios hijos (en la tabla REPRESENTANTES), las filas hijos se transforman en hurfanos. Los valores de la clave externa (OFICINA_REP) de estas filas ya no coincidirn con ningn valor de la clave primaria (OFICINA) de la tabla padre. Obsrvese que la eliminacin de una fila de la tabla hijo no plantea ningn problema; el padre de esa fila simplemente tiene un hijo menos tras esa eliminacin. Actualizacin de la clave primaria de una fila padre. Se trata de una forma diferente del problema anterior. Si se modifica la clave primaria (OFICINA) de una fila de la tabla padre (OFICINAS), todos los hijos existentes de esa fila se transforman en hurfanos debido a que sus claves externas ya no coinciden con ningn valor de la clave primaria. Las caractersticas de integridad referencial del estndar ANSI/ISO de SQL trata cada una de estas cuatro situaciones. El primer problema (INSERT en la tabla hijo) se aborda comprobando los valores de las columnas de la clave externa antes de autorizar la instruccin INSERT. Si no coinciden con un valor de la clave primaria, se rechaza la instruccin INSERT. En la Figura 11.1 esto significa que antes de que se pueda aadir un representante nuevo a la tabla REPRESENTANTES, ya debe estar en la tabla OFICINAS la oficina a la que se le asigne. Como puede verse, esta restriccin tiene sentido en la base de datos de ejemplo. El segundo problema (UPDATE de la tabla hijo) se resuelve de manera parecida comprobando el valor actualizado de la clave externa. Si no hay ningn valor coincidente en la clave primaria, la instruccin UPDATE se rechaza con un mensaje de error. En la Figura 11.1 esto significa que antes de poder reasignar a un represen tante a una oficina diferente, esa oficina ya debe estar en la tabla OFICINAS. Una vez ms, esta restriccin tiene sentido en la base de datos de ejemplo. El tercer problema (DELETE de una fila padre) es ms complejo. Por ejemplo, supngase que se cerrara la oficina de Len y se quisiera eliminar la fila correspondiente de la tabla OFICINAS en la Figura 11.1. Cabra preguntarse lo que ocurrir con las dos filas hijos de la tabla REPRESENTANTES que representan a los representantes asignados a la oficina de Len. En funcin de la situacin se desear: Evitar que se elimine la oficina hasta que se haya reasignado a los representantes. Eliminar tambin de manera automtica a los dos representantes de la tabla
REPRESENTANTES.
Problemas de integridad referencial

Hay cuatro tipos de actualizaciones de las bases de datos que pueden afectar a la integridad referencial de las relaciones padre/hijo de una base de datos. Utilizando las tablas OFICINAS y REPRESENTANTES de la Figura 11.1 como ejemplo, tenemos las siguientes cuatro situaciones de actualizacin: Insercin de una fila hijo nueva. Cuando una instruccin INSERT aade una nueva fila a la tabla hijo (REPRESENTANTES), el valor de su clave externa (OFICINA_REP) debe coincidir con uno de los de la clave primaria (OFICINA) de la tabla padre (OFICINAS). Si el valor de la clave externa no coincide con ninguno de los de la clave primaria, la insercin de la fila deteriorar la base de datos, ya que habr un hijo sin padre (un hurfano). Obsrvese que la insercin de una fila en la tabla padre no supone nunca un problema; sencillamente, se transforma en un padre sin hijos.
Definir la columna OFICINA_REP de los dos representantes como NULL, indicando que se desconoce su asignacin de oficina. Definir la columna OFICINA_REP de los dos representantes con algn valor predeterminado, como el nmero de oficina de la oficina central de Navarra,
288
SaL. Manual de referencia
289
indicando que los representantes se reasignan de manera automtica a esa oficina.

El cuarto problema (UPDATE de la clave primaria de la tabla padre) tiene una complejidad parecida. Por ejemplo, supngase que, por alguna razn, se desea modificar el nmero de la oficina de Len del 21 al 23. Al igual que en el ejemplo anterior, la pregunta es lo que debe ocurrir con las filas hijo de la tabla REPRESENTANTES que representan a los representantes de la oficina de Len. Una vez ms hay cuatro posibilidades lgicas:
Evitar que el nmero de oficina se modifique hasta que se haya reasignado a los representantes. En este caso, primero habra que aadir una fila nueva a la tabla OFICINAS con el nuevo nmero de oficina de Len, luego actualizar la tabla REPRESENTANTES y, finalmente, eliminar la fila antigua de la tabla OFICINAS para Len. Actualizar de manera automtica el nmero de oficina de los dos representantes en la tabla REPRESENTANTES, de modo que sus filas sigan vinculadas con la fila de Len de la tabla OFICINAS, mediante su nuevo nmero de oficina: Definir la columna OFICINA_REP de los dos representantes como NULL, indicando que su asignacin de oficina es desconocida. Definir la columna OFICINA_REP de los dos representantes con un valor predeterminado, corno el nmero de oficina de la cenrral de Navarra, indicando que los representantes se reasignan de manera automtica a esa oficina.
Aunque algunas de estas opciones puedan parecer ms lgicas que otras en este ejemplo concreto, resulta relativamente sencillo encontrar ejemplos en que cualquiera de las opciones sea la solucin correcta, si se desea que la base de datos modele con precisin la situacin del mundo real. El estndar SQLI slo ofreca la primera posibilidad para los ejemplos anteriores -prohiba la modificacin de los valores en uso de las claves primarias y la eliminacin de filas que contuvieran una clave primaria-o DB2, sin embargo, permita otras opciones mediante su concepto de reglas de eliminacin. El estndar SQL2 ha ampliado estas reglas de eliminacin a reglas de eliminacin y actualizacin, que tratan tanto la eliminacin de filas padre como la actualizacin de las claves primarias.
nes DELETE que intenten eliminar una de estas filas padres se rechazarn con un mensaje de error. De este modo se restringen las eliminaciones de la tabla padre a las filas sin hijos. Aplicada a la Figura 1 J .1, esta regla puede resumirse as: No se puede eliminar una oficina si tiene representantes asignados. Regla de eliminacin CASCADE. La regla de eliminacin CASCADE indica al SGBD que cuando se elimine una fila padre, tambin se deben eliminar automticamente de la tabla hijo todas sus filas hijos. Para la Figura 11.1 esta regla puede resumirse as: La eliminacin de una oficina elimina de manera automtica a todos los representantes asignados a esa oficina. Regla de eliminacin SET NULL. La regla de eliminacin SET NULL indica al SGBD que cuando se elimine una fila padre se debe definir automticamente como NULL el valor de la clave externa de todas sus filas hijo. Las eliminaciones en la tabla padre generan, por (anta, una actualizacin definir como NULL en las columnas correspondientes de la tabla hijo. Para las tablas de la Figura 11.1 esta regla puede resumirse as: Si se elimina una oficina, hay que indicar que se desconoce la asignacin actual de oficina de sus representantes. Regla de eliminacin SET DEFAULT. La regla de eliminacin SET DEFAULT indica al SGBO que, cuando se elimina una fila padre. el valor de la clave externa de sus filas hijos debe definirse automticamente como el valor predeterminado de esa columna concreta. Las eliminaciones de la tabla padre provocan, por tanto, una actualizacin definir como DEFAULT de las columnas correspondientes de la tabla hijo. Para las tablas de la Figura 11.1 esta regla puede resumirse as: Si se elimina una oficina, hay que indicar que la asignacin actual de oficina de sus representantes es la oficina predeterminada especificada en la definicin de la tabla REPRESENTANTES. Hay unas pequeas diferencias entre las implementaciones de SQL2 y de DB2 de las reglas de eliminacin. La implementacin actual de DB2 no incluye la regla SET DEFAULT; sta slo viene especificada en el estndar SQL2. El estndar SQL2 llama realmente NO ACTION ala regla RESTRICT ya descrita. La denominacin de SQL2 es algo confusa. Significa: Si se intenta eliminar una fila padre que todava tenga hijos, el SOBD no emprender ninguna accin sobre esa fila. No obstante, el SGBD generar un cdigo de error. De manera intuitiva, el nombre de DB2 para esta regla, restrict, parece una descripcin mejor de la situacin -el SGBD restringir (impedir) la operacin DELETE y generar un cdigo de error. Las versiones recientes de DB2 admiten tanto la regla de eliminacin RESTRICT como la regla de eliminacin NO ACTION. La diferencia entre ellas es el momento de aplicacin de la regla. La regla RESTRICT se aplica antes que ninguna otra restriccin; la regla NO ACTION se aplica despus de las dems restricciones referenciales. En casi todas las circunstancias las dos reglas operan de manera idntica. Al igual que la regla de eliminacin indica al SOBO lo que debe hacer cuando un usuario intente eliminar una fila de la tabla padre, la regla de. actualizacin indica al SOBO lo que debe hacer cuando un usuario intente actualizar el valor de
Reglas de eliminacin y actualizacin
Para cada relacin padre/hijo creada por una clave externa de una base de datos, el estndar SQL2 permite especificar una regla de eliminacin y una regla de actualizacin asociadas. La regla de eliminacin indica al SOBD lo que debe hacer cuando un usuario intente eliminar una fila de la tabla padre. Se pueden especificar estas cuatro reglas de eliminacin: Regla de eliminacin RESTRICT. La regla de eliminacin RESTRICT evita que se elimine una fila de la tabla padre si esa fila tiene hijos. Las instruccio-
290
SOL. Manual de referencia'
291
una de las columnas de la clave primaria de la tabla padre. Una vez ms, hay cuatro posibilidades, que recuerdan a las disponibles para las reglas de eliminacin: Regla de actualizacin RESTRICT. La regla de actualizacin RESTRICT evila que se actualice la clave primaria de una fila de la tabla padre si esa fila tiene hijos. Las instrucciones UPDATE que intenten modificar la clave primaria de una fila padre de este tipo se rechazarn con un mensaje de error. En consecuencia, las modificaciones de las claves primarias de la tabla padre quedan restringidas a las filas sin hijos. Aplicada a la Figura 11.1 esta regla puede resumirse as: No se puede modificar el nmero de una oficina si tiene asignados representantes. Regla de actualizacin CASCADE. La regla de actualizacin CASCADE indica al SGBD que cuando se modifique el valor de la clave primaria de una fila padre, el valor correspondiente de la clave externa de sus filas hijo debe modificarse tambin de manera automtica en la tabla hijo para que coincida con la nueva clave primaria. Para la Figura 11.1 esta regla puede resumirse as: La modificacin del nmero de una oficina modifica automticamente el nmero de oficina de todos los representantes que tenga asignados. Regla de actualizacin SET NULL. La regla de actualizacin SET NULL indica al SGBD que cuando se actualice el valor de la clave primaria de una fila padre, se debe definir de manera automtica como NULL el valor de la clave externa de todas sus filas hijos. Las modificaciones de la clave primaria generan, por tanto, una actualizacin definir como NULL de las columnas correspondientes de la tabla hijo. Para las tablas de la Figura 11.1 esta regla puede resumirse as: Si se modifica el nmero de una oficina, hay que indicar que la asignacin actual de oficina de sus representantes es desconocida. Regla de actualizacin SET DEFAULT. La regla de actualizacin SET DEFAULT indica al SGBD que, cuando se actualice el valor de la clave'primaria de una fila padre, el valor de la clave externa de todas sus filas hijos debe definirse automticamente como el valor predeterminado de esa columna concreta. Por tanto, las modificaciones de la clave primaria de la tabla padre generan una actualizacin definir como DEFAULT de las columnas correspondientes de la tabla hijo. Para las tablas de la Figura 11.1 esta regla puede resumirse as: Si se modifica el nmero de una oficina, hay que cambiar de manera automtica la asignacin de oficina de sus representantes a la oficina predeterminada especificada en la definicin de la tabla REPRESENTANTES. Las mismas diferencias entre DB2 y el estndar SQL2 descritas para las reglas de eliminacin son aplicables para las reglas de actualizacin. La regla de actualizacin SET DEFAULT slo se halla presente en el estndar, no en la implementacin actual de DB2. La regla de actualizacin RESTRICT es un convenio de denominacin de DB2; el estndar SQL2 tambin llama NO ACTION a esta regla de actualizacin. Se pueden especificar dos reglas diferentes, como regla de eliminacin y regla de actualiza-ci6n de una relaci6n padre/hijo, aunque, en la mayor parte de los ca-
SOS, las dos reglas sern idnticas. Si no se especifica ninguna regla, el valor predeterminado es la regla RESTRICT, ya que presenta el riesgo mnimo de destruccin o modificacin accidental de los datos. Cada una de estas reglas resulta adecuada en situaciones diferentes. Generalmente, el comportamiento del mundo real modelado por la base de datos indicar la regla que resulta apropiada. En la base de datos de ejemplo, la tabla PEDIDOS contiene tres relaciones clave externa/clave primaria, como puede verse en la Figura 11.2. Estas tres relaciones vinculan cada pedido con: El producto encargado. El cliente que realiz el pedido. El representante que tramit el pedido. Para cada una de estas relaciones parecen adecuadas reglas diferentes: Es probable que, para la relacin entre un pedido y el vendedor, deba utilizar la regla RESTRICT para eliminacin y actualizacin. No debera resultar posible eliminar de la base de datos informacin de productos ni modificar
T ., a CLIENTES NUM.-CLI EMPRESA
Tabla REPRESEm'ANTES NIDLEHPL """"RE
Tabla PRODUCTOS
IDJAB ID PRODUC"l'O DESCRIPCIN
2108 HeZ'lche " L6pez 2117 J.P. Sotoca 2122 Toledo S.A.
106 Sou:Iel Clavel
>O. Bernardo SDcbe:

101
AC> AC'
D.lniel R'Jidrobo
"41003 4100441003
Serie J. cable Serie 4. cable Hlice
CASCAD"
(eliminar hijo cuando se elimine al padre)
Tabla PEDIDOS
NrnLPEDIDO FECHA PEDIDO CLIEm'E RE'
~'7
'AB
2108 2120 2106 101 AC' 4100X 102 'MM 179C 101 2A45C
(definir el hijo como NULL cuando se elimine RESTRIC1' al padrel (prohibir la eliminacin del padre)
PRODUCTO
113055 l5-FEB-90 113048 10-FEB-90 112993 04-ENE-S9
""
Figura 11.2.
Las reglas DELETE en accin.
292
293
su nmero de producLO si sigue habiendo pedidos pendientes de esos pro duetos. Para la relacin entre un pedido y el cliente que lo formul, es probable que deba utilizar la regla CASCADE para eliminaciones y actualizaciones. Probablemente s610 se elimine una fila de cliente de la base de datos si el cliente est inactivo o si ha concluido su relacin con la empresa. En ese caso, al eliminar al cliente, tambin habr que eliminar los pedidos pendientes de ese cliente. De manera parecida, las modificaciones del nmero de cliente deben transmitirse de manera automtica a los pedidos de ese cliente. Para la relacin entre un pedido y el representante que lo tramit, es probable que deba utilizar la regla SET NULL. Si el representante abandona la empre sa, los pedidos que haya tramitado pasan a ser responsabilidad de un representante desconocido hasta que se reasignen. De manera alternativa podra utilizarse la regla SET DEFAULT para asignar de forma automtica esos pedidos al vicepresidente de ventas. Es probable que esta relacin deba utilizar la regla de actualizacin CASCADE, para que las modificaciones en los nmeros de empleado se transmitan automticamente a la tabla PEDIDOS.
Tabla OFICINAS
OFICINA 22 11 12 CIUDAD Daimiel Navarra Castelln 13 Almeria 21 Len REGIN Oeste Este Este Este Oeste
JEF 108 106 104
OBJETIVO 300.000,OO" S7S.000,OO 800.000,OO NOLL 350.000,OO 108 725.000,OO
VENTAS
186.042,OO 692.637,OO 735.042,OO 367.911,OO 835.915,OO
"
Eliminaciones y actualizaciones en cascada
La regla RESTRICT para eliminaciones y actualizaciones es una regla de un solo nivel -slo afecta. a la tabla padre de la relacin-o La regla CASCADE, por otra parte, puede ser una regla multinivel, como puede verse en la Figura 11.3. Supngase para esta discusin que las relaciones OFICINAS/REPRESENTANTES Y REPRESENTANTES/PEDIDOS que aparecen en la figura tienen reglas CASCADE. Plantemonos lo que ocurre cuando se elimina la oficina de Len de la tabla OFICINAS. La regla CASCADE de la relacin OFICINAS/REPRESENTANTES indica al SGBD que elimine tambin de manera automtica todas las filas de REPRESENTANTES que hagan referencia a la oficina de Len (oficina nmero 21). Pero la eliminacin de la fila de Susana Santos de REPRESENTANTES pone en funcionamiento la regla CASCADE para la relacin REPRESENTANTES/PEDIDOS. Esta regla indica al SGBD que elimine de manera automtica todas las filas de PEDIDOS que hagan referencia a Susana (nmero de empleado 102). La eliminacin, por tanto, genera una eliminacin en cascada de representantes, lo que causa una eliminacin en cascada de pedidos. Como muestra el ejemplo, las reglas de eliminacin CASCADE deben especificarse con cuidado, ya que pueden generar una eliminacin automtica generalizada de datos si se utilizan de manera incorrecta. Las reglas de actualizacin en cascada pueden crear actualizaciones multinivel parecidas si la clave externa de la tabla hijo tambin es su clave primaria. En la prctica, esto no resulta muy frecuente, por lo que las actualizaciones en cascada suelen tener efectos de menor alcance que las eliminaciones en cascada. Las reglas de actualizacin y de eliminacin SET NULL y SET DEFAULT son reglas de dos niveles; su impacto acaba en la tabla hijo. La Figura 11.4 muestra nuevamente las tablas oFicINAS, REPRESENTANTES y PEDIDOS, con una regla d.e eliminacin SET
Figura
11,3.
Dos niveles de las reglas
CASCADE.
para la relacin OFICINAS/REPRESENTANTES. Esta vez, cuando se elimina la oficina de Len, la regla de eliminacin SET NULL indica al SGBD"que defina la columna OFICINA_REP como NULL en las filas de REPRESENTANTES que hacen referencia a la oficina nmero veintiuno. No obstante, las filas siguen en la tabla REPRESENTANTES, Yla repercusin de la operacin de eliminacin slo llega a la tabla hijo.
NULL
294
Capitulo 11: Integridad de datos
295
T a bla OFICINAS
OFICINA CIUDAD
22 11 12 13 21
REGIN
JEF
108 106 lO'
OBJETIVO
VENTAS
Daimiel
Navarra
Castelln
Oeste
Este Este Este
Almeria Len
Oeste
300.000,00 186 042,OO: 575.QOQ,QO 692.637,QO aoo. 000,00 735.042,QO NULL 350.00Q,QO 367.91l,OO 725.000,OO 835.915,OO 108
SET NULL
Tabla REPRESENTANTES NUM EMPL NOMBRE
tiene la columna JEF, una clave externa de la tabla REPRESENTANTES. Como puede verse en la Figura 11.5, estas dos relaciones forman un ciclo referencial. Cualquier fila dada de la tabla REPRESENTANTES hace referencia a una fila de la tabla OFICINAS, que hace referencia a una fila de la tabla REPRESENTANTES, etc. Este ciclo slo incluye dos tablas, pero tambin es posible crear ciclos de tres o ms tablas. Independientemente del nmero de tablas que impliquen, los ciclos referenciales plantean problemas especiales para las restricciones de la integridad referencial. Por ejemplo, supngase que los valores NULL no estuvieran permitidos en las claves primarias O externas de las dos tablas de la Figura 11.5. (No se trata, en realidad, del modo en que se halla definida la base de datos de ejemplo, por motivos que se harn evidentes en un momento). Considrese esta solicitud de actualizacin de la base de datos y las instrucciones INSERT que intentan implementarla:
EDAD OFICINA REP PUESTO
109 Maria Jimnez 102 Susana Santos 106 Samuel Clavel
31 48 52
11 21 11
Representante
Representante
Jefe Ventas
Clave externa Tabla OFICINAS OFICINA I CIUDAD 22 Daimiel 11 Navarra 12 Castelln 13 Almera 21 Len
CLIENTE REP FAB
I
REGIN oeste Este Este Este Oeste
JEF
108 lO. lO'
OBJETIVO
300.000,OOe: 575.000,Oa aao.oaa,oae: 350.000.00e: 725.000,OO
VENTAS
CASCADE
NULL
108
186.a42,aa 692.637,aa 735.042.00 367.911,OOe: a35.915,OO
Tabla PEDIDOS
NUM PEDIDO
FEC~PEOI
Clave prima ria
Referencia
Referencia
113055 lS-FEB-90 113048 lO-FEB-90 112993 Q4-ENE-89
2108 2120 2106
101 102 102
Ael lMM REl
Figura 11.4.
Una combinacin de reglas de eliminacin DELETE.
Clave externa Tabla REPRESENTANTES NUM-EMPL NOMBRE EDAD OFICINA REP PUESTO 37 105 Bruno Arteaga 13 Representante 109 Mara Jimnez 31 11 Representante 102 Susana Santos .8 21 Representante 106 Samuel Clavel 52 11 VP Vent.as 33 12 Jefe Ventas lO' Bernardo Snchez 101 Daniel Ruidrobo 12 Representante 45 110 Toms Saz 41 NULL Representante lOa Le6n Freire .2 21 Jefe Ventas 103 Pablo Cruz 29 12 Representante 107 Neus Azcrate 22 Representante 49 Clave primaria
Ciclos referenciales
OFICINA_REP,
En la base de datos de ejemplo. la tabla REPRESENTANTES contiene la columna una clave externa de la tabla OFICINAS. La tabla OFICINAS con-
Figura ".5.
Un ciclo referencial.
296
297
Se acaba de contralar a U!l representante, Benjamn Alez (nmero de empLeado 115), que es el jefe de una oficina nueva de Dos Hermanas (nmero de oficina 14).
INSERT INTO REPRESENTANTES
VALUES
(NUM_EMPL, NOMBRE, OFICINA_REP, FECHA_CONTRATO, VENTAS)

'Ol-ABR-90'. 0.00)
(115, 'Benjamn Alez' , 14,
INSERT INTO OFICINAS (OFICINA, CIUDAD, REGlDN. JEF, OBJETIVO, VENTAS) VALUES (14, 'Dos Hermanas', 'Este', 1~5. 0.00, 0.00)
Por desgracia, la primera instruccin INSERT (para Benjamn Alez) fallar. Por qu? Porque la fila nueva hace referencia a la oficina nmero 14, que todava nO,se halla en la base de datos. Por supuesto. la inversin del orden de las instrucciones INSERT no ayuda:
INSERT INTO OFICINAS (OFICINA, CIUDAD, REGION, JEF, OBJETIVO, VENTAS) VALUES (14, 'Dos hermanas', 'Este', 115, 0.00, 0.001 INSERT INTO REPRESENTANTES (NUM_EMPL, NOMBRE, OFICINA~REP, FECHA_CONTRATO, VENTAS) VALUES (lIS, 'Benjamn Alez', 14, 'Ol-ABR-90', 0.00)
Los ciclos referenciales tambin restringen las reglas _de eliminacin y de actualizacin que pueden especificarse para las relaciones que fonnan el ciclo. Considrense las tres tablas del ciclo referencial que se muestran en la Figura 11.6. La tabla MASCOTAS muestra tres mascotas y los chicos que les gustan; la tabla CHICAS muestra a tres chicas y las mascotas que les gustan, y la tabla NIOS muestra a cuatro chicos y las chicas que les gustan, que forman un ciclo referencia~.--Las tres relaciones del ciclo especifican la regla de eliminacin RESTRICT. Obsrvese que la fila de Gustavo es la nica fila que se puede eliminar de las tres tablas. El resto de las filas es padre de alguna relacin y, por tanto, est protegida de la elimina cin por la regla RESTRICT. Debido a esta anomala no se debe especificar la regla RESTRICT para todas las relaciones de un ciclo referencial. La regla CASCADE presenta un problema parecido, como puede verse en la Figu ra 11.7. Esta figura contiene exactamente los mismos datos que la Figura 11.6, pero
Clave externa Tabla MASCOTAS I GUSTA NOMBRE Fino Samuel Ringo Benito Simbad Jos
La primera instruccin INSERT (para Dos Hermanas, en este caso) seguir fallando, ya que la nueva fila hace referencia al empleado nmero 115 como jefe de la oficina, y Benjamn Alez no se halla todava en la base de datos. Para evitar este bloque de inserciones, como mnimo una de las claves externas del ciclo referencial debe permitir los valores NULL. En la definicin real de la base de datos de ejemplo la columna JEF no permite los valores NULL, pero la columna OFICINA_REP s lo hace. La insercin de las dos filas puede lograrse con dos instrucciones INSERT y una instruccin UPDATE, como puede verse a continuacin:
INSERT INTO REPRESENTANTES (NUM_EMPL, NOMBRE, OFICINA_REP, FECHA_CONTRATO, VENTAS) VALUES (lI5,'Benjamn Alez', NULL, '01.-ABR-90' , 0.00)
el
pnmaria
"':S'
CI~ve
pnmana
.
RESTRICT
Clave externa
Tabla CHICAS NOMBRE GUSTA Fino Susana Juanita Simbad Beatriz Ringo
INSERT INTO OFICINAS (~FICINA, CIUDAD, REGlaN, JEF, OBJETIVO, VENTAS) VALUES (14, 'Dos Hermanas', 'Este', 115, 0.00. 0.00) UPDATE REPRESENTANTES SET OFICINA_REP = 14 WHERE NUM_EMPL = 115
primaria a ~
RESTRICT
Como muestra el ejemplo, hay veces en que sera conveniente que no se comprobara la restriccin de integridad referencial hasta que se realice una serie de actualizaciones interrelacionadas. Por desgracia, este tipo de comprobacin compleja dif~rida no lo proporciona la mayor parte de las implementaciones actuales de SQL. El estndar SQL2 especifica algunas posibilidades de comprobacin diferida, com9 se describe ms adelante en el apartado Comprobacin diferida de restricciones.
Clave externa Tabla CHICOS GUSTA NOMBRE Benito Juanita Beatriz Samuel Jos Susana Gustavo Juanita
RESTRICT
Figura 11.6.
Un ciclo con todas las reglas RESTRICT.
298
299
Claves externas y valores

Clave
externa
Tabla MASCOTAS
NULL
NOMBRE
Fino
Ringo
GUSTA Samuel Benito

Jos
Simbad
el
P'imaria
,.,~
CASCADE
Clave externa Tabla CHICAS NOMBRE GUSTA Susana Fino Juanita Simbad
Beatriz Ringo
a_.~
primaria
CASCADE
Clave
Tabla CHICOS
externa
NOMBRE
Benito
GUSTA Juanita
Beat.riz Susana Gustavo Juanita
Samuel Jos
CI~ve
. primaria
CASCADE
Figura 11.7.
Un ciclo ilegal con todas las reglas CASCADE.
las tres reglas de eliminacin se han cambiado a CASCADE. Supngase que se intenta eliminar a Benito de la tabla CHICOS. Las reglas de eliminacin obligan al SGBD a eliminar a Ringo (al que le gusta Benito) de la tabla MASCOTAS, lo que obliga a eliminar a Beatriz (a la que le gusta Ringo) de la tabla CHICAS, 10 que obliga a eliminar a Samuel (al que le gusta Beatriz), etc., hasta que todas las filas de las tres tablas se hayan eliminado. Para estas tablas pequeas pudiera resultar prctico, pero para una base de datos de produccin con millares de filas, rpidamente se volvera imposible realizar un seguimiento de las eliminaciones en cascada y conservar la integridad de la base de datos. Por este motivo DB2 hace que se cumpla una regla que evita los ciclos referenciales de dos o ms tablas en que todas las reglas de eliminacin sean CASCADE. Como mnimo, una de las relaciones del ciclo debe tener una regla de eliminacin RESTRICT o SET NULL para romper el ciclo de eliminaciones en cascada.
A diferencia de las claves primarias, las claves externas de las bases de datos relacionales pueden contener valores NULL. En la base de daLaS de ejemplo la clave externa DFICINA_REP de la tabla REPRESENTANTES permite valores NULL. De hecho, esta columna contiene un valor NULL en la fila de Toms Saz, ya que a Toms todava no se le ha asignado ninguna oficina. Pero el valor NULL plantea una pregunta interesante sobre la restriccin de integridad referencial creada por la relacin entre la clave primaria y la clave externa. Coincide el valor NULL con alguno de los valores de la clave primaria? La respuesta es quizs -depende del valor real de los datos que faltan o son desconocidos. El estndar SQLl de ANSI/ISO da por supuesto de manera automtica que una clave externa que contiene un valor NULL satisface ]a restriccin de integridad referencial. En otras palabras, da a la fila el beneficio de la duda y le permite ser parte de la labia hijo, aunque el valor de su clave externa no coincida con ninguna fila de la tabla padre. Resulta interesante que se suponga que la restriccin de integridad referencial se cumple si cualquier parle de la clave externa tiene un valor NULL. Esto puede provocar un comportamiento inesperado y no intuitivo de las claves externas compuestas, como la que vincula la tabla PEDIDOS con la tabla PRODUCTOS. Supngase por un momento que la tabla PEDIDOS de la base de datos de ejemplo permitiera valores NULL en la columna PRODUCTO, y que la relacin PRODUCTOS/PEDIDOS tuviera una regla de eliminacin SET NULL. (No se trata de la estructura real de la base de datos de ejemplo, por los motivos que se expondrn en este ejemplo.) Se pueden insertar con xito en la tabla PEDIDOS un pedido de un producto con el identificador de fabricante (FAB) ABe y un identificador de producto (PRODUCT) NULL debido al valor NULL de ]a columna PRODUCTO. DE2 Y el estndar ANSI/ISO dan por supuesto que la fila cumple la restriccin de integridad referencial para PEDIDOS y para PRODUCTOS, aunque ningn producto de la tabla PRODUCTOS tenga el identificador de fabricante ABe. La regla de eliminacin SET NULL puede producir un efecto parecido. La eliminacin de una fila de la tabla PRODUCTOS har que el valor de la clave externa de todas sus filas hijos de la tabla PEDIDOS se defina como NULL. Realmente, slo las columnas de la clave externa que acepten valores NOLL se definirn como NULL. Si hubiera una sola fila en la tabla PRODUCTOS para el fabricante DEF, la eliminacin de esa fila hara que sus filas hijos de la tabla PEDIDOS pasaran a tener su columna PRODUCTO definida como NULL, pero su columna FAB seguira teniendo el valor DEF. En consecuencia, las filas tendran un valor de FAB que no coincidira con ninguna fila de la tabla PRODUCTOS. Para evitar crear esta situacin se debe ser muy cuidadoso con los valores NULL en las claves externas compuestas. Una aplicacin que introduzca o actualice los datos de la tabla que contienen la clave externa deber normalmente hacer cumplir la regla todos NULL o ninguno NULL en las columnas de la clave externa. Las claves externas que son parcialmente NULL y parcialmente no NULL pueden crear problemas con facilidad. El estndar SQL2 aborda este problema dando al administrador de la base de datos ms control sobre el manejo de los valores NULL en las claves externas para
300
301
las restricciones de integridad. La restriccin de integridad de la instruccin CREATE TP.BLE ofrece dos opciones:
datos. Conceptualmente, los asertos especifican relaciones entre valores de datos que abarcan varias tablas de la base de datos. Cada uno de los cuatro tipos diferentes de restricciones tiene su propio objetivo conceptual y aparece en una parte diferente de la sintaxis de las instrucciones de SQL2. No obstante, las distinciones entre ellas son algo arbitrario. Cualquier restriccin de columna que aparezca para la definicin de una columna dada puede especificarse tambin como aserto. En la prctica, probablemente sea mejor espe cificar cada restriccin de la base de datos donde parezca que encaja de manera ms natural, dada la situacin del mundo real que la base de datos est intentando modelar. Las restricciones que se apnquen globalmente a toda la situacin (procesos comerciales, relaciones entre clientes y productos, etc.) deberan aparecer como asertos. Las restricciones que se apliquen a un tipo concreto de entidad (un cliente o un pedido) deberan aparecer como restricciones de tabla O de columna en la tabla correspondiente que describa ese tipo de entidad. Cuando la misma restriccin se aplique a muchas columnas diferentes de la base de datos que se refieran al mismo tipo de entidad, resultar apropiado un dominio.
Opcin MATCH FULL. La opcin MATCH FULL exige que las claves externas de las tablas hijos coincidan totalmente con la clave primaria de la tabla padre. Con esta opcin ninguna parte de la clave externa puede contener valor NULL, por lo que no se presenta el problema del tratamiento de los valores NULL en las reglas de eliminacin y de actualizacin. Opcin MATCH PARTIAL. La opcin MATCH PARTIAL permite valores NULL en algunas parles de las claves externas, siempre que los valores no NULL coincidan con las partes correspondientes de alguna clave primaria de la tabla padre. Con esta opcin el manejo de los valores NULL en las reglas de eliminacin y de actualizacin se realiza como ya se ha descrito.
Restricciones avanzadas (SQL2j

Las restricciones de clave principal y de clave externa, las restricciones de unicidad y las restricciones de los valores ausentes (NULL) ofrecen comprobaciones de la integridad de los datos para estructuras y situaciones de las bases de datos muy especficas. El estndar SQL2 va ms all de estas posibilidades para incluir una posibilidad mucho ms general de especificar y hacer cumplir las restricciones de integridad de los datos. El esquema completo incluye cuatro tipos de restricciones: Restricciones de columna. Se especifican como parte de la definicin de las columnas al crear la tabla. Conceptualmente restringen los valores legales que pueden aparecer en la columna. Las restricciones de columna aparecen en la definicin de cada columna en la instruccin CREATE TABLE. Dominios. Una forma especializada de restriccin de columna. Ofrecen una posibilidad limitada de definicin de tipos nuevos de datos dentro de la base de datos. En efecto, un dominio es uno de los tipos predefinidos de tipos de la base de datos con alguna restriccin adicional, que se especifica como parte de la definicin del dominio. Una vez definido con nombre un dominio, el nombre del dominio se puede utilizar en lugar de un tipo de datos para definir nuevas columnas. Las columnas heredan las restricciones del dominio. Los dominios se definen, aparte de las definiciones de tablas y columnas de la base de datos, empleando la instruccin CREATE DOMAIN. Restricciones de tabla. Se especifican como parte de la definicin de las tablas al crearlas. Conceptualmente restringen los valores legales que pueden aparecer en las filas de la tabla. Las restricciones de tabla se especifican en la instruccin CREATE TABLE que define cada tabla. Generalmente aparecen como un grupo tras las definiciones de las columnas, pero el estndar SQL2 les permite aparecer intercaladas con las definiciones de las columnas. Aser~os. El tipo ms general de restriccin de SQL2. Al igual que los dominios, se especifican aparte de la estructura de tablas y columnas de la base de
Asertos
En apartados anteriores de este captulo ya han aparecido ejemplos de los tr~s primeros tipos de restricciones. Los asertos se especifican mediante la instruccin de SQL2 CREATE ASSERTION. A continuacin se rnuestr"'3 un aserto que pudiera resullar til en la base de datos de ejemplo: Asegurarse de que el objetivo de cuota de cada oficina no supera la suma de las cuotas de sus representantes.
CREATE ASSERTION cuota_valida CHECK ((OFICINAS.CUOTA <= SUM(REPRESENTANTES.CUOTA)) AND (REPRESENTANTES.OFICINA_REP = OFICINAS.OFICINA))
Como es un objeto de la base de datos (como las tablas o las columnas), hay que dar un nombre al aserto (en este caso, es cuota_valida). El nombre se utiliza en los mensajes de eITor generados por el SGBD cuanlo se viola el aserto. El aserto que causa el error puede resultar obvio en una base de datos pequea de ejemplo, pero en una base de datos de gran tamao que puede contener docenas o centenares de asertos, resulta fundamental conocer el aserto que se ha violado. A continuacin se ofrece otro ejemplo de aserto que puede resultar til en la base de datos de ejemplo: Asegurarse de que el total de los pedidos de cualquier cliente lmite de crdito:
CREATE ASSERTION credito-pedidos CHECK (CLIENTE.LIMITE_CREDITO <=
110
supera su
302

SELECT SUM(PEDIDOS.IMPORTE) FROM PEDIDOS WHERE PEDIDOS.CLIENTE = CLIENTE NUM_CLIJ
303
Como muestran estos ejemplos. los asertos de SQL2 se definen mediante una condicin de bsqueda, que se encierra entre parntesis y a la que sigue la palabra clave CHECK. Siempre que se realiza un intento de modificar el contenido de la base de datos, mediante una instruccin INSERT, UPDATE o DELETE, se contrasta la condicin de bsqueda con la modificacin (propuesta) del contenido de la base de datos. Si la condicin de bsqueda sigue siendo TRUE, se permite la modificacin. Si la condicin de bsqueda pasara a ser falsa. el SGBD no llevar a cabo la modificacin propuesta y se devolver un cdigo de error, que indicar la viola cin de un aserto. En teora, los asertos pueden ocasionar una sobrecarga de procesamiento de la base de datos muy grande, ya que se comprueba cada instruccin que pueda modificar la base de datos. En la prctica, el SGBD analiza el aserto y determina las tablas y columnas a las que afecta. Slo las modificaciones que afecten a esas tablas o columnas en concreto activarn la condicin de bsqueda. Pese a todo, los aser tos deben definirse con mucho cuidado para asegurarse de que suponen una sobrecarga razonable para la ventaja que ofrecen.
nes de clave externa en un mismo sitio en la definicin de la tabla, en lugar de tenerlas dispersas por las definiciones de las columnas. Restriccin CHECK. La restriccin CHECK puede aparecer como restriccin de columna o de tabla. Tambin es el nico tipo de restriccin que forma parte de la definicin de dominios o de asertos. La restriccin de comprobacin se especifica como condicin de bsqueda, al igual que la condicin de bsqueda que aparece en la clusula WHERE de las consultas a las bases de datos. La restriccin se cumple si la condicin de bsqueda tiene el valor TRUE. A cada restriccin de la base de datos (independientemente de su tipo) se le puede asignar un nombre de restriccin para identificarla de manera unvoca frente a las otras restricciones. Probablemente no sea necesario asignar nombres de restriccin en bases de datos sencillas en que cada restriccin se halle claramente asociada con una sola tabla, columna o dominio, y en las que haya poca posibilidad de error. En bases de datos ms complejas, que tengan varias restricciones en una misma tabla o columna, puede resultar muy til identificar cada restriccin por su nombre (especialmente cuando comiencen a producirse errores). Obsrvese que la restriccin de comprobacin de los asertos debe tener un nombre de restriccin; este nombre se convierte de manera efectiva en el nombre del aserto que contiene esa restriccin.
Tipos de restricciones en SQL2 Comprobacin diferida de restricciones

Los tipos de restricciones que pueden especificarse en SQL2 y el papel representado por cada una de ellas puede resumirse de la manera siguiente: Restriccin NOT NULL. La restriccin NOT NULL slo puede aparecer como restriccin de columna. Evita que se asigne a la columna un valor NULL. Restriccin PRIMARY KEY. La restriccin PRIMARY KEY puede aparecer como restriccin de columna o de tabla. Si la clave primaria consta de una sola columna, puede que resulte ms conveniente la restriccin de columna. Si consta de varias columnas, debe especificarse como restriccin de tabla. Restriccin UNIQUE. La restriccin UNIQUE puede aparecer como restriccin de columna O de tabla. Si la restriccin de unicidad de valores slo se aplica a una columna, la restriccin de columna es la manera ms sencilla de especificarla. Si la restriccin de unicidad de valores se aplica a dos o ms columnas (es decir, la combinacin de valores de esas columnas debe ser nica en todas las filas de la tabla), entonces se debe utilizar la modalidad de restriccin de tabla. Restriccin referencial (FOREIGN REY). La restriccin referencial (FOREIGN KEY) puede aparecer como restriccin de columna o de tabla. Si la clave externa consta de una sola columna, puede que resulte ms adecuada la restriccin de columna. Si consta de varias columnas, debe especificarse como restri~cin de tabla. Si una tabla tiene muchas relaciones de clave externa con otras tablas, puede que resulte ms adecuado reunir todas sus restriccioEn su forma ms sencilla, las diversas restricciones especificadas en una base de datos se verifican cada vez que se intenta modificar el contenido de la base de datos -es decir, du~ante el intento de ejecucin de cada instruccin INSERT, UPDATE o DELETE-. En los sistemas de bases de datos que slo manifiestan una conformidad de nivel intermedio o inicial con el estndar SQL2, se trata del nico modo de operacin permitido para las restricciones de la base de datos. La conformidad plena con el estndar SQL2 especifica una posibilidad adicional de comprobacin diferida de las restricciones. Cuando se difiere la comprobacin de las restricciones no se comprueban las restricciones para cada instruccin de SQL. En lugar de eso, la comprobacin de las restricciones se mantiene en suspenso hasta el final de cada transaccin SQL. (El procesamiento de las transacciones y las instrucciones SQL asociadas se describe con detalle en el Captulo 12). Cuando la instrucci6n de SQL CQMMIT indica que se ha completado la transaccin, el SaBD comprueba las restricciones diferidas. Si se cumplen todas las restricciones, se puede seguir adelante con la instruccin CQMMIT y la transaccin puede completarse con normalidad. En ese momento las modificaciones realizadas a la base de datos durante la transaccin se hacen permanentes. Si, no obstante, la transaccin propuesta violara alguna de las restricciones, la instruccin COMMIT fallara y la transaccin retrocedera -es decir, se desharan todos las modificaciones de la base de datos propuestas, y la base de datos volvera a su estado previo al comienzo de la transaccin.
304
305
La comprobaci6n diferida de las restricciones puede resultar muy importante cuando se deben realizar simultneamente varias actualizaciones de la base de datos para conservarla en un estado consistente. Por ejemplo, supngase que la base de datos de ejemplo contuviera este aserto: Asegurarse de que el objetivo de cuota de cada oficina es igual a la suma de las cuolas de sus represelllantes.
CREATE ASSERTION totales_cuota CHECK ((OFICINAS.CUOTA : SUM(REPRESENTANTES.CUOTA) AND (REPRESENTANTES.OFICINA_REP = OFICINAS.OFICINA)
tante es DEFERRABLE si se desea diferir su operacin. Obsrvese tambin que estos atributos de restriccin slo definen la diferibilidad de una restriccin ---es decir, si su operacin puede diferirse-. La definicin de la restriccin tambin puede especificar el estado inicial de la restriccin: Restriccin INITIALLY IMMEDIATE. Las restricciones INITIALLY IMMEDIATE son las que se inician como restricciones inmediatas; es decir, se comprobar de manera inmediata para cada instruccin de SQL. Restriccin INITIALLY DEFERRED. Las restricciones INITIALLY DEFERRED son las que se inician como restricciones diferidas; es decir, su comprobacin se difiere hasta el final de las transacciones. Por supuesto, esta opcin no puede especificarse si la restriccin se define como NOT DEFERRABLE. La restriccin se pone en el estado inicial especificado cundo se crea. Tambin se vuelve a colocar en su estado inicial al comienzo de cada transaccin. Dado que ofrece la comprobacin de integridad ms restrictiva, el valor predeterminado es INITIALLY IMMEDIATE. Las restricciones se deben declarar de manera explcita INITIALLY DEFERRED si se de:sea que inicie de manera automtica cada transaccin en estado diferido. . SQL2 afj.ade otro mecanismo ms para controlar el procesamiento inmediato o diferido de las restricciones. Se puede modificar de manera dinmica el procesamiento de las restricciones durante la operacin de la base de datos mediante la instruccin SET CONSTRAINTS. Por ejemplo, supngase que la base de. datos de eje~plo contiene este aserto:
CREATE ASSERTION totales_cuota CHECK ((OFICINAS.CUOTA : SUM(REPRESENTANTES.CUOTA) AND (REPRESENTANTES.OFICINA-REP = OFICINAS.OFICINA)) DEFERRABLE INITIALLY IMMEDIATE
Sin la comprobacin diferida de las constantes esta restriccin impedira de hecho la adicin de representantes a la base de datos. El motivo es que para con~ servar la cuota de la oficina y las de los representantes en la relacin correcta hay que aadir las filas de los nuevos representantes con sus cuotas correspondientes (mediante una instruccin INSERT) e incrementar la cuota de la oficina correspondiente en la misma cantidad (mediante la instruccin UPDATE). Si se intenta ejecutar la instruccin INSERT en la tabla REPRESENTANTES en primer lugar, la tabla OFICINAS no se habr actualizado todava, el aserto no ser TRUE y la instruccin fallar. De manera parecida, si se intenta ejecutar la instruccin UPDATE en la tabla OFICINAS en primer lugar, la tabla REPRESENTANTES no se habr actualizado todava, el aserto no ser TRUE y la instruccin fallar. La nica solucin a este dilema es posponer la comprobacin de las restricciones hasta que se hayan completado las dos instrucciones y comprobarlas luego para asegurarse de que las dos operaciones, tomadas en su conjunto, han dejado la base de datos en un estado vlido. El mecanismo de restricciones diferidas de SQL2 ofrece esta posibilidad y mucho ms. Cada restriccin (de cualquier tipo) de la base de datos puede identificarse al crearla o definirla como DEFERRABLE o NQT DEFERRABLE: Restriccin DEFERRABLE. Las restricciones DEFERRABLE son aquellas cuya comprobacin puede diferirse al final de las transacciones. El aserto del ejemplo anterior es una restriccin que debe ser diferible. Al actualizar las cuotas o aadir nuevos representantes a la base de datos resulta ciertamente deseable poder diferir la comprobacin de las restricciones, como mostraba el ejemplo. Restriccin NOT DEFERRABLE. Las restricciones NOT DEFERRABLE son aquellas cuya comprobacin no puede diferirse. La restriccin de clave primaria, una restriccin de unicidad, y muchas restricciones de comprobacin de columna suelen caer en esta categora. Estas comprobaciones de integridad de los datos no dependen de otras interacciones de la base de datos. Pueden y deben comprobarse despus de cada instruccin de SQL que intente modificar la base de datos. Dado que ofrece ]a comprobacin de integridad ms restrictiva, el valor predeterminado es NOT DEFERRABLE. Hay que declarar de manera explcita que una cons-
./
La comprobacin inmediata inicial hace que .se procese la restriccin, instruccin a instruccin, para todo el procesamiento normal de ]a base de datos. Sin embargo, para la transaccin especial que aade un nuevo representante a la base de datos, har falta diferir de manera temporal el procesamiento de la restriccin. Esta secuencia de instrucciones logra el objetivo:
SET CONSTRAINTS totales_cuota DEFERRED INSERT INTO REPRESENTANTES (NUM_EMPL, NOMBRE, OFICINA_REP, FECHA-CONTRATO, CUOTA, VENTAS). VALUES (:num, : nombre, : numero_oficina , :fecha, : importe, O) UPDATE OFICINAS SET OBJETIVO = OBJETIVO + :importe WHERE (OFICINA: :numero_oficina) COMMIT
Una vez que la instruccin COMMIT finaliza la transaccin, se vuelve a colocar la restriccin totales_cuota en modo IMMEDIATE, debido a la especificacin
306
307
INITIALLY IMMEDIATE. Si hubiera ms trabajo que hacer tras la instruccin upDATE previa al final de la transaccin, se podra volver a poner manualmente de nuevo en modo IMMEDIATE empleando esta instruccin:
SET CQNSTRAINTS totales_cuota IMMEDIATE
base de datos. Para la base de datos de ejemplo, probablemente tengan sentido estas reglas: Siempre que se acepte un nuevo pedido, la columna VENTAS del representante que lo tramit y de la oficina en la que trabaja deben incrementarse en el importe del pedido. La eliminacin del pedido o la modificacin de su importe tambin debe hacer que se ajuste las columnas VENTAS. Siempre que se acepte un nuevo pedido se debe disminuir la columna STOCK del producto solicitado en la cantidad pedida. La eliminacin de pedidos, la modificacin de la cantidad o el cambio de producto tambin deben pravo car los ajustes correspondientes en la columna STOCK. Estas reglas caen fuera del mbito del lenguaje SQL, tal y como lo defina el estndar SQLl y lo implementan muchos productos SGBD basados en SQL de hoy en da. El SGBD asume la responsabilidad del almacenamiento.y ~a organizacin de los datos y de asegurar su integridad bsica, pero el cumplimIento de las reglas de negocio es responsabilidad de los programas de aplicacin que tienen acceso a la base de datos. Depositar la carga del cumplimiento de las reglas de negocio en los programas de aplicacin que tienen acceso a la base de datos presenta varios inconvenientes: Duplicacin del esfuerzo. Si seis programas diferentes tratan con diferentes actualizaciones de la tabla PEDIDOS, cada uno de ellos debe incluir cdigo que haga que se cumplan las reglas relativas a las actualizaciones de PEDIDOS.
Se puede definir el mismo modo para varias restricciones diferentes incluyendo sus nombres en una lista separada por comas:
SET CONSTRAINTS totales_cuota, totales_rep IMMEDIATE
Finalmente, se puede definir el modo de procesamiento de todas las restricciones con una sola instruccin:
SET CQNSTRAINTS ALL DEFERRED
Las posibilidades de SQL2 para la comprobacin diferida de restricciones forman un servicio muy completo para la gestin de la integridad de las bases de datos. Al igual que ocurre con muchas de las posibilidades de SQL2, cada una de las partes de las posibilidades de SQL2 se tomaron de implementaciones de SQL ya existentes, y algunas de eIJas han tenido acogida en otras implementaciones desde la publicacin del estndar. DB2, de IBM, por ejemplo, incluye la posibilidad de comprobacin diferida de las restricciones y alberga las opciones de aplazamiento tipo SQL2. No obstante, su instruccin SET CONSTRAINTS, se aparta del estndar SQL2. Opera en las tablas de la base de datos, activando y desactivando el aplazamiento de la comprobacin de las restricciones asociadas con el contenido de cada tabla.
Reglas de negocio
Muchos de los problemas de integridad de datos en el mundo real tienen que ver con las reglas y con los procedimientos de cada organizacin. Por ejemplo, puede que la empresa modelada por la base de datos de ejemplo tenga reglas como las siguientes: No se permite a ningn cliente formular pedidos que excedan su lmite de crdito. Se debe informar al vicepresidente de ventas siempre que se conceda a un cliente un lmite de crdito superior a 50.000 . Los pedidos slo pueden conservarse en los libros durante seis meses; los pedidos con ms de seis meses de antigedad deben cancelarse y volver a formularse. Adems, suele haber reglas de contabilidad que deben seguirse para conservar la integridad de los totales, las cuentas y otros importes almacenados en la
Falta de consistencia. Si varios programas escritos por programadores diferentes tratan las actualizaciones de las tablas, probablemente hagan cumplir las reglas de modo diferente. Problemas de mantenimiento. Si las reglas de negocio se modifican, los programadores debern identificar todos los programas que hacen que se cumplan las reglas. localizar el cdigo y modificarlo de manera correcta. Complejidad. Suele haber muchas reglas que recordar. Incluso en ]a pequea base de datos de ejemplo un programa que maneje las modificaciones de los pedidos debe preocuparse de hacer cumplir los lmites de crdito, ajustar los totales de ventas de los representantes y de las oficinas y ajustar los stocks. Un programa que maneje actualizaciones sencillas puede volverse complejo con gran rapidez.
El requisito de que los programas de aplicacin hagan cumplir l~s reglas de negocio no es exclusivo de SQL. Los programas de aplicacin han teOldo ~sa responsabilidad desde los primeros das de los programas de COBOL y_los sIstemas de archivos. No obstante. hay una lenta tendencia a 10 largo de los anos a atnbUlr ms comprensin de los datos y ms responsabilidad hacia su integridad en la propia base de datos. En 1986, el SGBD Sybase introdujo ~1 concepto de disparador como un paso hacia la inclusin de las reglas de negoclO en las bases de ~atos relacionales. El concepto se hizo muy popular, por 10 que el soporte de los dlspa-
'1
308
SOL. Manual de. referencia
309
radores comenz a aparecer en muchos productos SGBD de SQL a comienzos de los aos noventa del siglo pasado, entre ellos en los de los principales fabricantes de SOBD para empresas. Los disparadores y el cumplimiento de las reglas de negocio que proporcionan ha resultado especialmente til en los entornos de bases de datos de las empresas. Cuando docenas de programadores de aplicaciones desarrollan o modifican centenares de programas de aplicacin cada ao, la posibilidad de centralizar la definicin y la administracin de las reglas de negocio puede resultar muy til.
Concepto de disparador
El concepto de disparador es relativamente sencillo. Para cada evento que provoque una modificacin del contenido de una tabla, el usuario puede especificar una accin ~sociada que deba ejecutar el SGBD. Los tres eventos que pueden desencadenar una accin son los intentos de INSERT. DELETE o UPDATE las filas de una tabla. La accin desencadenada por cada evento viene especificada mediante una secuencia de instrucciones de SQL. Para comprender el modo de funcionamiento de los disparadores conviene examinar un ejemplo concreto. Cuando se aade un pedido' nuevo a la tabla PEDIDOS; tienen lugar las dos modificaciones siguientes de la base de datos:
La columna VENTAS del representante que tramit el pedido debe incremen-
una para la tabla REPRESENTANTES y la otra para la tabla PRODUCreferencia a la fila que se inserta mediante el nombre de pseudotabla insertado dentro de las instrucciones UP.DATE. Como muestra el ejemplo, SQL Server ampla de manera sustancial el lenguaje SQL para dar soporte a los disparadores. Entre otras extensiones no mostradas aqu estn as pruebas iF/THEN/ELSE, los bucles, las llamadas a procedimientos e, incluso, las instrucciones PRINT que muestran mensajes de usuarios. La posibilidad de los disparadores, aunque popular en muchos productos SGBD, no forma parte del estndar ANSI/ISO SQL2. Al igual que ocurre con otras caractersticas de SQL cuya popularidad antecedi a su normalizacin,. sta ha provocado una considerable divergencia en el soporte de los disparadores entre diferentes marcas de SGBD. Algunas de las diferencias entre las marcas son meramente de sintaxis. Otras reflejan autnticas diferencias en las posibilidades subyacentes. El soporte de los disparadores en DB2 ofrece un ejemplo instructivo de estas diferencias. A continuacin puede verse la misma definicin de disparador mostrada anteriormente para SQL Server, esta vez con la sintaxis de DB2: nes UPDATE, TOS. Se hace
CREATE TRIGGER AFTER REFERENCING FOR BEGIN .UPDATE SET WHERE UPDATE SET WHERE AND ENO PEDIDONUEVO INSERT ON PEDIDO NUEVO AS PEDIDO_NUEVO EACH ROW MODE DB2SQL ATOMIC REPRESENTANTES VENTAS = VENTAS + PEDIDO NUEVO. IMPORTE REPRESENTANTES.NUM_EMPL = PEDIDO~NUEVO.REP: PRODUCTOS STOCK = STOCK - PEDIDO_NUEVO. CANTIDAD PRODUCTOS.ID_FAB = PEDIDO_NUEVO.FAB PRODUCTOS. ID_PRODUCTO = PEDIDO_NUEVO. PRODUCTO;
tarse en el importe del pedido. La columna STOCK del producto solicitado debe disminuir en la cantidad encargada.
Esta instruccin de Transact-SQL define un disparador de SQL Server, denominado PEDIDONUEVO, que hace que las actualizaciones de la base de datos se produzcan de manera automtica:
CREATE ON FOR AS TRIGGER PEDIDONUEVO PEDIDOS INSERT UPDATE ~EPRESENTANTES SET VENTAS = VENTAS + INSERTED.IMPORTE FROM REPRESENTANTES, INSERTED' WHERE REPRESENTANTES.NUM_EMPL = INSERTED.REP UPDATE PRODUCTOS SET STOCK = STOCK - INSERTED.CANTIDAD FROM PRODUCTOS, INSERTED WHERE PRODUCTOS.ID_FAB = INSERTED.FAB AND PRODUCTOS. ID_PRODUCTO = INSERTED.PRODUCTO
El comienzo de la definicin del disparador incluye los mismos elementos que la defi1icin de SQL Server, pero los reordena. Indica de manera explcita a DB2 que hay que invocar al disparador despus de que se inserte en la base de datos cada pedido nuevo. DB2 tambin permite especificar que hay que ejecutar el disparador antes de que la accin desencadenante se aplique al contenido de la base de datos. Esto no tiene sentido en este ejemplo, ya que el evento desencadenante es una operacin INSERT, pero lo tiene para las operaciones UPDATE o
DELETE.
La primera parte de la definicin del disparador indica a SQL Server que el disparador debe invocarse siempre que se intente ejecutar una instruccin INSERT sobre la tabla PEDIDOS. El resto de la definicin (tras la palabra clave AS) define la acdn del disparador. En este caso, la accin es una secuencia de dos instruccio-
La clusula REFERENCING de DB2 especifica un alias de tabla (PEDIDO_NUEVO) que se utilizar para hacer referencia a la fila que se va a insertar a 10 largo del resto de la definicin del disparador. Tiene la misma funcin que la palabra clave INSERTED en el disparador de SQL Server. La instruccin hace referencia a los valores nuevos de la fila insertada porque se trata de un disparador de la operacin INSERT. En los disparadores de la operacin DELETE se hace referencia a los valores antiguos. En los disparadores de la operacin UPDATE DB2 ofrece la posibilidad de hacer referencia tanto a los valores viejos (previos a UPDATE) como a los nuevos (posteriores a UPDATE).
310
311
,
"
BEGIN ATOMIC y END sirven como parntesis alrededor de la secuencia de instrucciones SQL que definen la accin desencadenada. Las dos instrucciones upDATE con bsqueda del ncleo de la definicin del disparador son modificaciones directas de sus equivalentes en SQL Server. Siguen la sintaxis estndar de SQL para las instrucciones UPDATE con bsqueda, empleando el alias de tabla especificado por la clusula REFERENCING para identificar la fila concreta de las tablas REPRESENTANTES y PRODUCTOS que se va a actualizar. Se hace referencia a la fila que se va a insertar empleando el nombre de pseudotabla insertado en las instrucciones UPDATE. A continuacin se ofrece otro ejemplo de definicin de disparador, esta vez empleando lnformix Universal Server: CREATE TRIGGER PEDIDONUEVO INSERT N PEDIDOS AFTER (EXECUTE PROCEDURE PEDIDO_NUEVO)
Los disparadores tambin pueden emplearse para ofrecer formas ampliadas de integridad referenciaL Por ejemplo, DB2 ofreca inicialmente eliminaciones en cascada mediante su regla de eliminacin CASCADE, pero no soportaba las actualizaciones en cascada si se modificaba el valor de alguna clave primaria. Esta limitacin, sin embargo, no hace falta aplicarla a los disparadores. El siguiente disparador de SQL Server hace que la actualizacin de la columna OFICINA de la tabla OFICINAS pase en cascada a la columna OFICINA_REP de la tabla REPRESENTANTES:
CREATE ON FOR AS TRIGGER CAHBIO_OFICINA_REP OFICINAS UPDATE IF UPDATE (OFICINA) BEGIN UPDATE REPRESENTANTES SET REPRESENTANTES.OFICINA_REP = INSERTED.OFICINA FROM REPRESENTANTES, INSERTED. DELETED WHERE REPRESENTANTES.OFICINA_REP = DELETED.OFICINA END
Este disparador vuelve a especificar una accin que tiene que realizarse despus de que se inserte el nuevo pedido. En este caso, las diferentes instrucciones de SQL que forman la accin desencadenada no pueden especificarse directamente en la definicin del disparador. En vez de eso, las instrucciones desencadenadas se ubican en un procedimiento almacenado de Inforrnix, denominado PEDIDO_NUEVO, y el disparador hace que se ejecute ese procedimiento almacenado. Como muestran este ejemplo y los anteriores, aunque los conceptos fundamentales del mecanismo de los disparadores son muy consistentes de unas bases de datos a otras, las particularidades varan bastante. Los disparadores, ciertamente, se hallan entre los aspectos menos transportables de las bases de datos de SQL de hoy en da.
Como en el ejemplo anterior de SQL Server, las referencias DELETED. OFICINA INSERTED. OFICINA del dispaqldor hacen mencin a los valores de la columna OFICINA antes y despus de la instruccin UPDATE, respectivamente. La definicin
del disparador debe poder diferenciar entre estos valores anteriores y posteriores para poder llevar a cabo las correspondientes acciones de bsqueda y actualizacin especificadas por el disparador.
Ventajas e inconvenientes de los disparadores

Durante los ltimos aos los mecanismos de los disparadores de muchos productos SaBD comerciales se han expandido de manera significativa. En muchas implementaciones comerciales las distinciones entre los disparadores y los procedimientos almacenados (que se describen en el Captulo 20) se han difuminado, por lo que la accin desencadenada por una sola modificacin de la base de datos puede estar definida por centenares de lneas de programacin de procedimientos almacenados. El papel de los disparadores, por tanto, ha evolucionado ms all del cumplimiento de la integridad de los datos hacia una posibilidad de programacin dentro de la base de datos. Un estudio 'completo de los disparadores cae fuera del mbito de este libro, pero incluso estos ejemplos sencillos muestran la potencia del mecanismo de los disparadores. La principal ventaja de los disparadores es que las reglas de negocio se pueden almacenar y hacer cumplir de manera consistente en cada actualizacin de la base de datos. Esto puede reducir espectacularmente la complejidad de los programas de aplicacin que tienen acceso a la base de datos. Los disparadores tambin tienen algunos inconvenientes, entre los cuales se hallan: Complejidad de la base de datos. Cuando las reglas se desplazan al interior de la base de datos, la configuracin de la base de datos se hace una tarea ms
Disparadores e integridad referencial

Los disparadores ofrecen una manera alternativa de implementar las restricciones de integridad referencial proporcionadas por las claves externas y las claves primarias. De hecho, los defensores de los disparadores sealan que el mecanismo de los disparadores es ms flexible que la integridad referencial estricta proporcionada por el estndar ANSI/ISO. Por ejemplo, a continuacin se ofrece un disparador que hace que se cumpla la integridad referencial en la relacin OFICINAS/REPRESENTANTES, Y muestra un mensaje cuando falla algn intento de actualizacin:
CREATE ON FOR AS TRIGGER ACTUALIZAR_REP REPRESENTANTES INSERT, UPDATE IF ((SELECT COUNT(*) FROH OFICINAS, INSERTED WHERE OFICINAS.OFICINA = INSERTED.OFICINA_REPI BEGIN PRINT -Nmero de oficina especificado no vlido." ROLLBACK TRANSACTION ENn
O)
ji
312
SOL. .Manual.de referencia
313
compleja. Los usuarios de los que se poda esperar razonablemente que crearan pequeas aplicaciones ad hoc con SQL hallarn que la lgica de programacin de los disparadores hace la tarea mucho ms difcil.. Reglas ocultas. Con las reglas ocultas en el interior de la base de datos los programas que parecen realizar actualizaciones sencillas de la base de datos pueden, en realidad, generar una enorme cantidad de actividad de la base de datos. Los programadores ya no tienen el control total de 10 que le ocurre a la base de datos. En vez de eso, una accin de la base de datos iniciada por un programa puede generar otras acciones ocultas.
oficiales de SQL. Independientemente de la posicin oficial, los disparadores se han hecho una parte cada vez ms importante del lenguaje SQL en las aplicaciones empresariales durante los ltimos aos.
Resumen
El lenguaje SQL ofrece varias caractersticas que ayudan a proteger la integridad de los datos almacenados en bases de datos relacionales: Las columnas requeridas pueden especificarse al crear cada tabla, y el SGBD evitar la presencia de valores NULL en esas columnas. La validacin de los datos en SQL estndar se limita a la comprobacin del tipo de datos, pero muchos productos SGBD ofrecen'\otras caractersticas de validacin. Las restricciones de integridad de las entidades aseguran que la clave primaria identifique de manera unvoca cada entidad representada en la base de datos. Las restricciones de integridad referencial aseguran que las relaciones entre las entidades de la base de datos se conserven durante las actualizaciones de la base de datos. El estndar SQL2 y las implementaciones ms recientes ofrecen un amplio soporte a la integridad referencial, como las reglas de eliminacin y de actualizacin que indican al SGBD el modo en que debe tratar la eliminacin y la modificacin de las filas a las que hagan referencia otras filas. El SGBD puede hacer que se cumplan las reglas de negocio mediante el mecanismo de los disparadores, popularizado por Sybase y SQL Server. Los disparadores permiten que el SGBD emprenda acciones complejas en respuesta a eventos como los intentos de ejecucin de las instrucciones INSERT, DELETE o UPDATE. "Las restricciones de comprobacin ofrecen una manera ms limitada de incluir las reglas de negocio en la definicin de las bases de datos y hacer que el SGBD consiga que se cumplan.
Implicaciones ocultas para el rendimiento. Con los disparadores almacenados en el interior de la base de datos las consecuencias de la ejecucin de las instrucciones de SQL ya no son completamente visibles para los programadores. En especial, una instruccin de SQL aparentemente sencilla puede, tericamente, desencadenar un proceso que implique la bsqueda secuencial de una tabla de la base de datos de tamao muy grande, lo que tardara mucho en completarse. Estas implicaciones para el rendimiento de cualquier instruccin SQL resultan invisibles para los programadores.
Disparadores y el estndar SOL

Los disparadores fueron una de las caractersticas ms ampliamente alabadas y anunciadas de SQL Server de Sybase cuando se introdujo en el mercado, y desde entonces han hallado acomodo en muchos productos comerciales de SQL. Aunque el estndar SQL2 ofreci una oportunidad para normalizar la implementacin de los disparadores en los SGBD, el comit de normalizaCin introdujo en su lugar las restricciones de comprobacin. Como muestran los ejemplos de disparadores y de restricciones de comprobacin de los apartados anteriores, las restricciones de comprobacin pueden emplearse de manera efectiva para limitar los datos que pueden aadirse a las tablas o modificarse en ellas. Sin embargo, a diferencia de los disparadores, carecen de la capacidad de generar acciones independientes en las bases de datos, como el aadido de filas o la modificacin de elementos de datos de otras tablas. La capacidad adicional ofrecida por los disparadores ha llevado a varios expertos de la industria a defender que se incluyan en un futuro estndar SQL3. Otros expertos han argumentado que los disparadores suponen una contaminacin de la funcin de gestin de datos de las bases de datos, y que las funciones desempeadas por los disparadores corresponden a los lenguajes de cuarta generacin (Fourth Generation Languages, 4GLs) y a otras herramientas de las bases de datos, ms que a los propios SGBD. Mientras contina el debate, los productos de SGBD han experimentado nuevas posibilidades de disparadores que se extienden ms all de las propias bases de datos. Estas posibilidades ampliadas de los disparadores permiten que las modificaciones de los datos de una base de datos generen de manera automtica acciones como el envo de correo, el aviso a un usuario o ellanzamiento de otro programa para la realizacin de una tarea. Esto hace a los disparadores todava ms "tiles y se sumar al debate sobre su inclusin en futuros estndares
CAPTULO
Las actualizaciones de las bases de datos suelen ser desencadenadas por eventos del mundo real, como la recepcin de un pedido nuevo de un cliente. De hecho, la recepcin de un pedido nuevo no genera una actualizacin, sino esta serie de cuatro actualizaciones en la base de datos de ejemplo: Aadir el nuevo pedido a la tabla PEDIDOS. Actualizar el total de ventas del representante que tramit el pedido. Actualizar el lOtal de ventas de la oficina del representante. Actualizar el stock del producto solicitado.
12
Para dejar la base de datos en un estado autoconsistente. las cuatro actualizaciones deben producirse como si fueran una unidad. Si un fallo del sistema u otro error crean una situacin en que alguna de las actualizaciones se procesa y el resto no, se perder la integridad de la base de datos. De manera parecida, si otro usuario calcula totales o relaciones durante la secuencia de actualizaciones, sus clculos sern incorrectos. La secuencia de actualizaciones, por tanto, debe ser una proposicin todo o nada de la base de datos. SQL ofrece precisamente esta posibilidad mediante sus caractersticas de procesamiento de transacciones, que se describen en este captulo.
Concepto de transaccin
Una transaccin es una secuencia de una o varias instrucciones de SQL que forman conjuntamente una unidad lgica de trabajo. Las instrucciones de SQL que fonnan la transaccin suelen estar ntimamente relacionadas y llevan a cabo acciones interdependientes. Cada instruccin de la transaccin lleva a cabo una parte de la tarea, y todas ellas son necesarias para completarla. La agrupacin de las instrucciones como una sola transaccin indica al SGBD que toda la secuencia de
315
316

~
Captulo 12: Procesamiento de transacciones
317
instruccin debe ejecutarse de forma atmica -se deben completar todas las instrucciones para que la base de datos quede en un estado consistente. A continuacin se ofrecen algunos ejemplos de transacciones tpicas para la base de datos de ejemplo, junto con la secuencia de instrucciones_ de SQL que comprende cada transaccin: Aadir un pedido. Para aceptar el pedido de un cliente, el programa de introduccin de pedidos debe (a) consultar la tabla PRODUCTOS para asegurarse de que hay existencias del producto, (b) insertar el pedido en la tabla PEDIDOS, (c) actualizar la tabla PRODUCTOS, restando la cantidad encargada del stock del producto, (d) actualizar la tabla REPRESENTANTES, aadiendo el importe del pedido a las ventas totales del representante que ha tramitado el pedido y (e) actualizar la tabla OFICINAS, aadiendo el importe del pedido a las ventas totales de la oficina en que trabaja ese representante. Cancelar un pedido. Para cancelar el pedido de un cliente, el programa debe <a) eliminar el pedido de la tabla PEDIDOS, <b) actualizar la tabla PRODUCTOS, ajustando el stock del producto, (e) actualizar la tabla REPRESENTANTES, restando el importe del pedido de las ventas totales del representante y (d) actualizar la tabla OFICINAS, restando el importe del pedido del total de ventas de la oficina. Reasignar un cliente. Cuando se reasigna un cliente de un representante a otro, el programa debe <a) actualizar la tabla CLIENTES para reflejar la modificacin, (b) actualizar la tabla PEDIDOS para mostrar el nuevo representante en todos los pedidos realizados por el cliente, (e) actualizar la tabla REPRESENTANTES, reduciendo la cuota del representante que pierde al cliente, y (d) actualizar la tabla REPRESENTANTES, elevando la cuota del representante que gana el cliente. En cada uno de los casos se necesita una secuencia de cuatro o cinco acciones, en la que cada accin consiste en una instruccin de SQL diferente, para tratar la transaccin lgica. El concepto de transaccin resulta fundamental para los programas que actualizan las bases de datos, ya que asegura la integridad de las bases de datos. -Los SOBO basados en SQL realizan este compromiso respecto de las instrucciones de cada transaccin: Las instrucciones de cada transaccin se ejecutarn en la base de datos como una unidad atmica de trabajo. O se ejecutan con xito todas las -ins~ trucciones, o no se ejecuta ninguna. El SGBD es responsable de conservar este compromiso, aunque el programa de aplicacin aborte o se produzca un fallo de hardware en mitad de la transaccin, como puede verse en la Figura 12.1 En cada caso el SOBD debe asegurarse de que, cuand,o se complete la recuperacin del fallo, la base de datos no refleje una transaccin parcial.,
r
Estado de la base de datos antes de la transaccin
~
'-.
- !SELECT UPDATE UPDATE
!SELECT UPDATE
!
SELECT UPDATE
Transaccin (
UPDATE
DELETE
DELETE El SGBD deshace todas las modificaciones
INSERT
Estado de la base
de datos despus de la transaccin .,
El SGBD
deshace todas las modificaciones
Figura 12.1.'
El concepto de transaccin de SOL
COMMIT
y ROLLBACK
SQL acoge las transacciones de las bases de datos mediante dos instrucciones de procesamiento de transacciones de SQL, que pueden verse en la Figura 12.2:
COMMIT.
La instruccin COMMIT seala la conclusin con xito de una transaccin. Indica al SGBO que la transaccin se ha completado; se han ejecutado todas las instrucciones que confonnan la transaccin, y la base de datos es autoconsistente. ROLLBACK. La instruccin ROLLBACK seala el -fracaso de una transaccin. Indica al SOBO que el usuario no desea completar la transaccin; en lugar de ello, el SGBD debe volverse atrs de las modificaciones realizadas en la base de datos durante la transaccin. En efecto, el SGBD devuelve la base de datos a su estado previo al comienzo de la transaccin.
Las instrucciones COMMIT y ROLLBACK son instrucciones de SQL ejecutables, igual que SELECT, INSERT Y UPDATE. A continuacin se ofrece un ejemplo de una transaccin de actualizacin con xito que modifica la cantidad y el importe de un
]
318
319
I
I
'-
COMMIT - - - - -
I
I I
Modificar la cantidad del pedido nmero J13051 de 4 a /0, lo que incrementa su imporle desde 1458 a 3550 . El pedido es de reducloras QAS-XK47 y lo tramit Len Freire (empleado nmero /08), que trabaja en Len (oficina nmero 21).
UPDATE PEDIDOS 10. IMPORTE SET CANTIDAD WHERE NUM_PEDIDO ~ 113051 UPDATE REPRESENTANTES SET VENTAS ~ VENTAS - 1458.00 WHERE NOM_EMPL = 108 3550.00
f----
ROLLBACK - - - -
Lwo.. -.J Lwo.. -.J
3550.00
Figura 12.2.
Diagramas de sintaxis de las instrucciones COMMIT y ROLLBACK.
UPDATE OFICINAS SET VENTAS ~ VENTAS - 1458.00 + 3550.00 WHERE OFICINA ~ 21 UPDATE SET WHERE ANO PRODUCTOS STOCK ~ STOCK + 4 - 10 ID_FAS = 'QAS' ID_PRODUCTO ~ 'XK47'
pedido y ajusta los totales del producto, del representante y de la oficina asociados con el pedi~o. U~a modific~cin como sta la manejara normalmente un programa de modlficacI6n de pedidos basado en formularios, que ulilizara SQL para programacin para ejecutar las instrucciones que se muestran.
... Vaya! El fabricante es QSA, no QAS...

.Modificar La cantidad del pedido nmero 113051 de 4 a JO, lo que incrementa su Imporle de 1.458 a 3.550 . El pedido es de reducloras QSA-XK47 y lo lrami16 Le61l Frere (empleado Ilmero 108), que Irabaja ell Le61l (oficilla Ilmero 21).
UPDATE PEDIDOS
ROLLBACK WORK
El modelo de transacciones ANSI/ISO

3550.00
SET CANTIDAD = 10, IMPORTE WHERE NUM_PEDIDO = 113051
UPDATE REPRESENTANTES SET VENTAS = VENTAS 1458.00 + 3550.00 WHERE NUMERO_EMPL ~ loa UPDATE OFICINAS SET VENTAS: VENTAS - 1458.00 + 3550.00 WHERE OFICINA : 21 UPDATE SET WHERE ANO PRODUCTOS STOCK : STOCK + 4 - 10 ID_FAS: 'OSA' ID_PRODUCTO ~ 'XK47'
--
El estndar ANSI/ISO de SQL define un modelo de IrallSacci6n para SQL y los papeles de las instrucciones COMMIT y ROLLBACK, La mayor parte de los productos comerciales de SQL, pero no todos, utilizan este modelo de transaccin, que se basa en el soporte de las transacciones de las primeras versiones de DB2. El estndar especifica que cada transaccin de SQL comienza de manera automtica con la primera instruccin de SQL que ejecuta un usuario o un programa. La transaccin contina con las instrucciones de SQL siguientes hasta que concluye de una de las cuatro maneras siguientes:
COMMIT.
... confirmar por ltima vez la modificacin con el cliente...

COMMIT WORK
A. continuacin se ofrece la misma transaccin, pero esta vez supngase que el usuano comete un error al i~~ucir el nmero de producto. Para corregir el error, se hace retroce~er la transacclOn, de modo que pueda volver a introducirse de manera correcta:
La instruccin COMMIT concluye las transacciones con xito, haciendo permanentes las modificaciones de la base de datos. Tras la instruc cin COMMIT comienza de manera inmediata una nueva transaccin. ROLLBACK. La instruccin ROLLBACK aborta la transaccin, volvindose atrs de las modificaciones en la base de datos. Tras la instruccin ROLLBACK comienza de manera inmediata una nueva transaccin. Terminacin con xito del programa. Para el lenguaje SQL para programacin, la terminacin con xito de un programa conlleva que concluya tambin con xito la transaccin, igual que si se hubiera ejecutado la instruccin COMMIT. Como ha concluido el programa, no hay ninguna transaccin ms que comenzar.
320
"-Captulo 72: Procesamiento de transacciones
321
Terminacin anormal del programa. Para el lenguaje SQL para programacin la terminacin anormal de un programa hace que aborte la transaccin, igual que si se hubiera ejecutado la instruccin ROLLBACK. Como ha concluido el programa, no hay ninguna transaccin ms que Comenzar.
La Figura 12.3 muestra transacciones tpicas que ilustran estas cuatro condiciones. Obsrvese que el usuario o el programa se hallan siempre en una transaccin segn el modelo de transaccin ANSI/ISO. No se necesita ninguna accin explcita para comenzar una transaccin; comienza de manera automtica con la primera instruccin de SQL o inmediatamente despus de que acabe la transaccin anterior. Recurdese que el estndar ANSIIISO para SQL est pensado sobre todo parn el lenguaje SQL para programacin con el fin de emplearlo en programas de aplicacin. Las transacciones desempean un papel importante en SQL para programacin. ya que incluso los programas de aplicacin sencillos necesitan a menudo
ejecutar secuencias de dos o tres instrucciones de SQL para desempear su tarea. Como los usuarios -pueden cambiar de opinin y pueden darse otras condiciones (como la falta de existencias de un producto que desee encargar un cliente), los programas de aplicacin deben poder realizar las transacciones parcialmente y luego escoger entre abortarlas o continuar. Las instrucciones CQMMIT y RQLLBACK ofrecen, precisamente, esta posibilidad. Las instrucciones COMMIT y ROLLBACK tambin pueden utilizarse en SQL interactivo, pero, en la prctica, se ven rara vez en ese contexto. SQL interactivo suele utilizarse para las consultas a la base de datos; las actualizaciones son menos frecuentes, y casi nunca se llevan a cabo actualizaciones con varias instrucciones mediante la anotacin de las instrucciones en una instalacin para SQL interactivo. En consecuencia, las transacciones suelen constituir una preocupacin de orden menor en SQL interactivo. De hecho, muchos productos de SQL interactivo toman como valor predeterminado un modo de compromiso automtico, en el que se ejecuta de manera automtica una instruccin COMMIT tras cada instruccin de SQL escrita por el usuario. Esto transforma de hecho cada instruccin de SQL interactivo en su propia transaccin.
Base de dato..!.,..
consistente
~
Otros modelos de transacciones
UPDATE
Transaccin (
UPDATE
Base de datos consistente - .
- !INSERT
DELETE
! - ! ! !
"'1
COMMIT
COMMIT
-! i
-!
-!
UPDA~E
UPDATE
COHMIT
COMMIT
!
-
!
INSERT
! !
uOSCantos productos comerciales de SQL se separan del modelo de transacciones ANSI/ISO para ofrecer posibilidades adicionales de procesamiento de transacciones a sus usuarios. El SGBD Sybase, que est diseado para aplicaciones de procesamiento en lnea de transacciones, es un ejemplo. SQL Server, que se cre a partir del producto de Sybase, tambin utiliza el modelo de transacciones de Sybase. El dialecto Transact-SQL empleado por Sybase incluye cuatro instrucciones para el procesamiento de transacciones:
BEGIN TRANSACTION. La instruccin BEGIN TRAN8ACTION
Transaccin
l.
el
INSERT
(-!
INSERT
.ROLLx
!
DELETE
I
\Ci
programa aborta
COMMIT
Basededat~
consistente
Figura 12.3.
Transacciones comprometidas y que se han hecho retroceder.
seala el comienzo de una transaccin. A diferencia del modelo de transacciones ANSI/ISO, que da comienzo de forma explcita a una transaccin nueva cuando concluye la anterior, Sybase exige una instruccin explcita para iniciar una transaccin. COMMIT TRANSACTION. Seala la finalizacin con xito de una transaccin. Al igual que en el modelo ANSI/ISO, todas las modificaciones de la base de datos realizadas durante la transaccin se vuelven permanentes. No obstante, no se inicia de manera automtica una transaccin nueva. SAVE TRANSACTION. Establece un punto de revisin en mitad de una transaccin. Sybase guarda el estado de la base de datos en ese momento de la transaccin y asigna al estado guardado un nombre de punto de revisin, que se especifica en la instruccin. ROLLBACK TRANSACTION. Tiene dos cometidos. Si en la instruccin ROLLBACK se asigna un nombre a un punto de revisin, Sybase se vuelve atrs de las modificaciones de la base de datos realizadas desde el punto de revisin, lo que de hech9 hace retroceder la transaccin hasta el punto en .que se ejecut la instruccin 8AVE TRANSACTION. Si no se asigna nombre a ningn
322
SOL. Manual de referencia punto de revisin, la instruccin ROLLBACK se vuelve atrs de rodas las mo-
323
dificaciones en la base de datos desde la instruccin
BEGIN TRANSACTION.
El mecanismo de puntos de revisin de Sybase resulta especialmente til en las transacciones complejas que implican a muchas instrucciones, como puede verse en la Figura 12.4. El programa de aplicacin de la figura guarda de manera peri-
Estado de la base
de datos aotes---+
de la transaccin BEGIN TRANSACTIQN
SAVE
+ + INSERT + DELETE + TRANSACTION A ---------+ +

UPDATE
Punto de revisin A
->
DELETE
SAVE TRANSACTION B - - - -
ROLLBACK 70 B
+ + UPDATE + INSERT +
Punto de revisin B
->1.
UPDATE
OELETE
COMMIT TRANSACTION
..
Estado de la base
dica su estado a medida que la transaccin avanza, estableciendo dos puntos de revisi6n con nombre. Si surgen problemas en un momento posterior de la transaccin, el programa de aplicacin no tiene que abortar toda la transacci6n. En lugar de eso, puede hacer que la transacci6n retroceda a cualquiera de los puntos de revisi6n y continuar desde all. Todas las instrucciones ejecutadas antes del punto de revisin siguen vigentes; la operacin de retroceso deshace las ejecutadas a partir del punto de revisin. Obsrvese que toda la transaccin sigue siendo la unidad lgica de trabajo de Sybase, al igual que ocurre con el modelo ANSI/ISO. Si se produce un fallo del sistema o de hardware en mitad de una transaccin, por ejemplo, la base de datos deshace toda la transaccin. Por tanto, los puntos de revisin son una comodidad para el programa de aplicacin, pero no suponen una modificacin fundamental del modelo de transacciones ANSIIISO. El empleo explcito de una instruccin BEGIN TRANSACTION supone, sin embargo, una desviacin significativa del modelo ANSI/ISO. Las instrucciones de SQL que se ejecutan fuera de las transacciones (es decir, que no aparecen entre los pares de instrucciones BEGIN/COMMIT o BEGIN/ROLLBACK) se manejan de hecho en modo de compromiso automtico. Cada instruccin se compromete en cuanto se ejecuta; no hay manera de hacer que la instruccin retroceda una vez que ha tenido xito. Algunas marcas de SOBD que utilizan un modelo de transacciones del estilo de Sybase prohben que las instrucciones que modifican la estructura o la seguridad de la base de datos (como CREATE TABLE, ALTER TABLE Y DRQP TABLE, que se estudian en el Captulo 13, o GRANT y REVOKE, que se estudian en el Captulo 15) aparezcan dentro de las transacciones. Estas instrucciones deben ejecutarse fuera de las transacciones. Esta restriccin hace ms sencillo de implementar el modelo de transacciones, ya que asegura que la estructura de la base de datos no se modifique durante la transaccin. Por el contrario, en una implementacin completa del modelo de transacciones del estilo ANSI/ISO, la estructura de la base de datos puede modificarse de manera significativa durante una transaccin. (Las tablas pueden descartarse, crearse y llenarse, por ejemplo.) El SOBD debe poder deshacer todas estas modificaciones, incluidas las modificaciones e$tructurales, si el usuario decide posteriormente hacer que la transaccin retroceda. En la prctica esto puede resultar difcil de implementar, y muchos productos de SGBD populares introducen restricciones simplificadoras. Una restriccin frecuente es que las modificaciones de ]a estructura de la base de datos no puedan entremezclarse cpu operaciones de acceso a la base de datos dentro de una transaccin. Otra restriccin habitual es que las transacciones que modifican la estructura de la base de datos slo puedan contener una nica i.ostruccin de SQL (como la instruccin CREATE TABLE o DROP TABLE).
de dats despus-----+
de la transaccin
Transacciones: entre bastidores*

Figura 12.4. . Un modelo alternativo (explcito) de transacciones utilizado por Sybase. .
El compromiso de todo o nada que el SGBD realiza con cada transaccin parece casi mgico para los usuarios nuevos de SQL. Cmo puede el SGBD echarse
324
,----
325
atrs de las modificaciones realizadas en la base de datos si se produce un fallo del sistema en el transcurso de la transaccin? Las tcnicas concretas empleadas por las diferentes marcas de SOBO varan, pero casi todas se basan en un registro de transacciones, como puede verse en la Figura 12.5. 'As es como funciona el registro histrico de transacciones: de una manera simplificada y conceptual. Cuando el usuario ejecuta una instruccin de SQL que modifica la base de datos, el SOBO escribe de manera automtica un registro en el registro histrico de transacciones, en el que muestra dos copias de cada fila afectada por la instruccin. Una copia muestra la fila antes de la modificacin y la otra muestra la fila tras la modificacin. Slo despus de haber escrito el registro histrico, el SOBD modifica realmente la fila en el disco. Si el usuario ejecuta posteriormente una instruccin COMMIT, el fi~al de la transaccin se anota en el registro de transacciones. Si el usuario ejecuta una instruccin ROLL-
.Secuencia de instrucciones SOL

.L.VI
.
Registro histrico de transacciones
UPDATE OFICINAS
f---+
12:04

SGBD
Ubicacin de la fila:_ Antes:-,-,-,--,....I--'_ Despus:_,...............:"'_,_ Ubicacin de la fila:_ Antes:.......I....I_ Despus: (Vaca) Ubicacin dela fila:_ Antes:--,--,-,_ Despus: (Vaca)
DELETE FROM CLIENTES
BACK, el SOBO examina el registro.histrico para hallar las imgenes previas de las filas que se hayan modificado desde el comienzo de la transaccin. Mediante estas imgenes el SOBO devuelve las filas a su estado anterior, deshaciendo todas las modificaciones de la base de da lOS realizadas durante la transaccin: Si se produce un falJo del sistema, el operador del sistema suele recuperar la b.ase de datos ejecutando una utilidad de recuperacin especial proporcionada con el SOBO. La utilidad de recuperacin examina el final del registro histrico de transacciones, buscando las transacciones no comprometidas antes del fallo. La utilidad deshace cada una de las transacciones incompletas, de modo que slo se reflejen en la base de datos las transacciones comprometidas; las transacciones en curso en el momento del fallo se han hecho retroceder. El empleo de un registro histrico de transacciones impone obviamente una sobrecarga a las actualizaciones de la base de datos. En la prctica, los principales productos comerciales de SOBD utilizan tcnicas de registro histrico mucho ms sofisticados que el esquema sencillo a<)u descrit para minimizar esa sobrecarga. Adems, el registro de transacciones suele 'almacenarse en una unidad rpida de disco, diferente del que almacena la base de datos, para minimizar la disputa por el acceso a disco. Algunas marcas de SOBD para computadoras personales penniten desactivar el registro histrico de transacciones para incrementar el rendimiento del SGBD. Las bases de datos especializadas, como las bases de datos residentes en memoria o las copias de la base de datos guardadas en la cach, tambin pueden utilizar esta arquitectura sin registro histrico., Tambin puede suponer una alternativa aceptable para las bases de datos especializadas para produccin; por ejem plo, en las que el contenido de la base de datos se halla reproducido en un sistema informtico duplicado. En las bases de datos de produccin ms frecuentes, sin embargo, el esquema de registro histrico y su sobrecarga constituyen parte iote gral de la operacin de la base de datos.
12:05
INSERT INTO PRODUCTOS
Transacciones y procesamiento multiusuario

Cuando dos o ms usuarios tienen acceso, de manera simultnea, a la base de datos, el procesamiento de las transacciones adopta una dimensin nueva. Ahora el SGBD no slo debe recuperarse de manera adecuada de los fallos o de los errores del sistema, sino que tambin debe asegurar que las acciones de los usuarios no interfieran entre s. Idealmente, cada usuario debera poder tener acceso a la base de datos corno si tuviera acceso exclusivo, sin preocuparse de las acciones de otros usuarios. El modelo de transacciones de SQL permite que los SOBO basados en SQL aslen a los usuarios entre s de esta manera. La mejor manera de comprender el modo en que SQL trata las transacciones concurrentes es examinar los problemas que se producen si las transacciones no se tratan de manera adecuada. Aunque pueden manifestarse de muchas maneras diferentes, se pueden producir cuatro problemas fundamentales. Los cuatro apartados siguientes dan un ejemplo sencillo de cada problema.
12:06
Ubicacin de la fila:_ Antes: (Vada) Despus:...--'.........._
I
Figura 12.5.
COMMIT
Transaccin comprometida
El registro histrico de transacciones.
326
327
El problema de la actualizacin perdida

La Figura] 2.6 muestra una aplicacin sencilla en la que dos usuarios aceptan. pe-
didos telefnicos de los clientes. El programa de introduccin de pedidos com~ prueba en el archivo PRODUCTOS si hay un inventario adecuado antes de aceptar el pedido del cliente. En la figura, Jos comienza a introducir un pedido de cien cables ACI-41004 de su cliente. Al mismo tiempo. Mara comienza a introducir el pedido de su cliente de ciento veinticinco cables ACI-41004. Cada programa de introduccin de pedidos realiza una consulta del archivo PRODUCTOS, y los dos encuentran que hay 139 cables en stock -ms que suficiente para cubrir la solicitud del cliente-o Jos pide a su cliente que confirme el pedido. y su copia del programa de introduccin de pedidos actualiza el archivo PRODUCTOS para que muestre (139 - 100);:;: 39 cables pendientes de venta, e inserta un nuevo pedido de cien cables en la tabla PEDIDOS. Pocos segundos ms tarde, Mara pide a su cliente que confirme el pedido. Su copia del programa de introduccin de pedidos actualiza el archivo PRODUCTOS para que muestre (139 - 125) ;:;: 14 cables todava en stock. e inserta un pedido nuevo de ciento veinticinco cables en la tabla PEDIDOS.
El tratamienlo de los dos pedidos ha dejado. evidentemente. la base de datos en un estado inconsistente. La primera de las dos actualizaciones del archivo PRODUCTOS. se ha p,erdido. Los pedidos de los dos clientes se han aceptado. pero no hay en mventano suficientes cables para satisfacerlos. Adems, la base de datos ~uestra que sigue habiendo todava catorce cables para la venta. Este ejemplo Justra el problema de la actualizacin perdida que puede darse siempre que dos programas lean de la base de datos los mismos datos, utilicen esos datos como base para un clculo y traten de actualizar los datos.
I
El problema de los datos no comprometidos
L~ Figura 12.7 muestra la misma aplicacin de procesamiento de pedidos que la Figura 12.6. Jos vuelve a comenzar aceptando de su cliente un pedido de cien ca-
Programa de Jos
12: 00
Tabla PRODUCTOS
IO_FAB ID_PRODUCTO
STOCK
Programa de Maria
Programa de Jos
12: ......
ID FA!!
Tabla PRODUCTOS
ID PRODUCTO
STOCK
Programa de Maria
ACl
41004
'"
ACI
41004
1J9
12 01
SELECT STOCK FROM PRODUCTOS
e',:'::'O",'~-;::=:-::=., ~/ SELtcT STOCX FROM

PRODUCTOS
"-r'~'='o~'=-==:-::=--, '---+ SELECT STOCK FROM

PRODUCTOS
Respuesta: 139
Respuesta: 139
Respuesta: 139
1
(AcePtar pedido de 100
12 :04
ID_P"AB ID_PRODUCTO
STOCK
( Aceptar pedido de 100)
12 :04
IDJAS ID PRQOUCTO
STOCK
Aceptar pedido de 125

12: 04
12 :04
/
UPDATE PRODUC'1'OS SET STOCK = 39
ACl
41004
"
12: 05
r
I
1
UPDATE PRODUCTOS SET STOCK e 39
:
ACl
41004
39
12: 05
SELEC'T STOCK FROM PRODUCTOS
"-.
12: 06
IDJAS ID PRODUCTO
STOCK
Respuesta: 139
: OS ID FAB
I
ID PRODUCTO
STOCK
UPDATE PRODUCTOS SET STOCK = 14
:
ACl
41004
14
"
06
ROLLB1l.CK
(Recaha~ar pedido de 125)
1
1
1/
ACl
41004
'"
( Nota: Comprar mlls1 ")
Figura 12.6~
El problema de la actualizacin perdida.
Figura 12.7.
El problema de los datos no comprometidos.
328
--Programa de Jos
12:01 SELECT STOCK PROM PRODUCTOS Respuesta, 139
329
bies ACI-41004. Esta vez, su copia del programa para el procesamiento de pedidos consulta la tabla PRODUCTOS, halla 139 cables y actualiza la tabla PRODUCTOS para mostrar los 39 cables restantes tras el pedido del cliente. Luego, Jos comienza a discutir con el cente las ventajas relativas de los cables ACI-41004 y ACI-4100S. Entretanto, el cliente de Mara intenta encargar ciento veinticinco cables ACI41004. La copia de Mara del programa de procesamiento de pedidos consulta la tabla PRODUCTOS; s610 halla 39 cables disponibles y rechaza el pedido. Tambin genera un aviso que indica al jefe de compras de que debe comprar ms cables ACI-41004, que se piden mucho. En este momento el cliente de Jos decide no encargar los cables finalmente, y el programa de procesamiento de pedidos de Jos realiza un ROLLBACK para abortar su transaccin. Como se permiti al programa de procesamiento de pedidos de Mara que viera la actualizacin no comprometida del programa de Jos, se rechaz el pedido del cliente de Mara, y. el jefe de compras encargar ms cables, aunque todava queden 139 en stock. La situacin hubiera sido todava peor si el cliente de Mara hubiera decidido conformarse con los 39 cables. En ese caso, el programa de Ma-. ra hubiera actualizado la tabla PRODUCTOS para que mostrara cero unidades dis ponibles. Pero cuando se hubiera producido el RQLLBACK de la lransaccin de Jos, el SGBD hubiera situado las existencias disponibles de nuevo en 139 cables, aunque 39 de ellos estuvieran comprometidos con el cliente de Mara. . El problema de este ejemplo es que se ha autorizado al programa de Mara a ver las actualizaciones no comprometidas del programa de Jos y ha actuado sobre ellas, lo que ha generado el resultado errneo. El estndar SQL2 hace referencia a este problema como Pi, tambin denominado problema de la lectllra desfasada. En la jerga del estndar, los datos que ha visto el programa de Mara estn desfasados porque el programa de Jos no los ha comprometido.
Tabla PRC?OUCTOS
12: OQ
Programa de Maria
STOCK
ID_FAS
ID PRODUCTO
AC>
41004
'"
./
SELECT STOCK FROH PRODUCTOS. ID 41004 Respuesta: 139
( Aceptar pedido de 100
12:03 SELEe'I' STOCK FROH PRODUCTOS ID '" 41005
12:04
12,05 UPOATe PRODUCTOS

SET STOCK'" 39
12:04 ID FAB
ID PROOt./CTO
SELECT STOCK FROl'l PRODUCTOS ID " 41004 l'lespuestll: 39

STOCK
AC>
41004
39
El problema de los datos inconsistentes

La Figura 12.8 muestra una vez ms la aplicacin de procesamiento de pedidos. Nuevamente, Jos comienza aceptando un pedido de su cliente de' cien cables ACI41004. Poco despus, Mara tambin comienza a hablar con su cliente sobre los mismos cables y su programa realiza una consulta de una sola fila para averiguar la cantidad disponible. Esta vez el cliente de Mara pregunta por los cables ACI41005 como alternativa, y el programa de Mara realiza una consulta sobre esa nica fila. Mientras tanto, el cliente de Jos decide encargar los cables, por lo que su programa. actualiza esa fila de la base de datos y realiza un COMMIT en la base de datos para finalizar el pedido. Tras considerar como alternativa los cables ACI-41.00S, el cliente de Mara decide encargar los cables ACI-41004 que Mara propuso inicialmente. Su programa realiza otra consulta de una soja fila para obtener nuevamente la informacin de los cables ACI-41004. Pero, en vez de hallar los 139 cables que haba en stock slo un momento antes, la nueva consulta s610 muestra 39. En este. ejemplo, a diferencia de los dos anteriores, el estado de la base de datos no ha dejado de ser un modelo preciso de la situacin del. mundo real. S610
Fi9l:'ra 12.8. El problema de los .datos inconsistentes.
quedan 39 cables ACI-41004 porque el cliente de Jos ha adquirido cien. No hay ningn problema con que Mara haya visto datos no comprometidos del programa de Jos. -el pedido se complet y se comprometi con la base de datos-o No obstante, desde el punto de vista del programa de Mara, la base de datos no se mantuvo consistente durante su transaccin. Al comienzo de la transaccin una fila contena unos datos determinados, y ms adelante, en la misma transaccin, contena unos datos diferentes, por lo que los eventos externos han interferido con su vista consisten~e de la base de datos. Esta inconsistencia puede causar problemas aunque el programa de Mara no intente nunca actualizar la base de datos basndose en los resultados de la primera consulta. Por ejemplo, si el programa est acumulando totales O calculando estadsticas, no puede estar seguro de que las estadsticas reflejen una vista estable y consistente de los datos. El problema en este caso es que se ha permitido al programa de
330
331
Mara que vea unas actualizaciones no comprometidas del programa de Jos que afectan a filas que ya ha examinado. El estndar SQL2 se refiere a este problema como P2, tambin denominado problema de la lectura no repetible. El nombre se deriva del hecho de que el programa de Mara no puede repetir el mismo acceso de lectura a la base de datos y obtener los mismos resultados.
El problema de la insercin fantasma

La Figura 12.9 muestra nuevamente una aplicacin de procesamiento de pedidos. Esta vez, el jefe de ventas ejecuta un programa de informes que explora la tabla
Programa de actualizacin
Tabla PEDIDOS
Programa de informes
12:00 NUM_PEDlDO IMPORTE 112961 31.S00,OO

113012
J. 745, OO
12:00
SELECT
PEDIDOS
FROM
PEDIDOS, imprime una lista de los pedidos de los clientes de Bruno Arteaga y calcula el total. Mientras tanto. un cliente llama a Bruno para realizar un pedido adicional de 5.000 . Se inserta el pedido en la base de datos y se compromete la transaccin. Poco despus el programa del jefe de ventas (que sigue operando dentro de su transaccin inicial) vuelve a explorar la tabla PEDIDOS, ejecutando la misma consulta. Esta vez hay un pedido adicional y el total es 5.000 superior al de la primera consulta. Como en el ejemplo anterior, el problema aqu son los datos inconsistentes. La base de datos sigue siendo un modelo preciso de la situacin del mundo real y su integridad est intacta, pero la misma consulta realizada dos veces durante la misma transaccin da dos resultados diferentes. En el ejemplo anterior la consulta era una consulta de una sola fila y la inconsistencia de los datos la causaba una instruccin UPDATE. En el ejemplo de la Figura 12.9 el problema lo causa una instruccin INSERT comprometida. La fila adicional no particip en la primera consulta, pero aparece cs>mo si fuera una fila fantasma que surgiera de ninguna parte en la segunda consulta. Al igual que en el problema de los datos inconsistentes, las consecuencias del problema de la insercin fantasma pueden ser clculos inconsistentes e incorrectos. El estndar SQL2 se refiere a esto como P3, y tambin utiliza el trmino fantasma para describirlo.
Respuesta: 112961,31.500
Transacciones simultneas
12:04 INSERT INTO PEDIDOS VALUES fllS102, ... , 5.000,00) 12:04 NUM_PEDIDO IMPORTE 112961 31.S00,00E 118102 s.ooo,ooE 113012 3.745,OOE
Respuesta:
113012,3.745
12:10 SELECT FROM PEDIDOS
Como muestran los tres ejemplos de actualizaciones con varios usuarios, cuando los usuarios comparten el acceso a la base de datos y uno o varios actualizan los datos, existe la posibilidad de corrupcin de la base de datos. SQL utiliza su mecanismo de transacciones para eliminar esta fuente de corrupcin de la base de datos. Adems del compromiso de todo o nada para las instrucciones de cada transaccin, los SGBD basados en SQL realizan este compromiso para las transacciones:
Respuesta:
112961,31.500
Durante una transaccin el usuario ver una vista completamente consistente de la base de datos. El usuario no ver nunca las modificaciones no comprometidas de otros usuarios, y ni siquiera las modificaciones comprometidas realizadas por otros usuarios afectarn a los datos vistos por el usuario durante la transaccin.
Las transacciones son, por tanto, la clave de la recuperacin y del control de la simultaneidad en las bases de datos de SQL. El compromiso anterior puede reformularse de manera explcita en trminos de la ejecucin de transacciones concurrentes:
Respuesta:
118102,5.00E 12:13
Respuesta:
111312,3.745
Figura 12.9.
El problema de la insercin fantasma.
Si dos transacciones, A y B, se ejecutan de manera simultnea, el SGBD asegura que el resultado ser el mismo que si (a) la transaccin A se ejecutara primero y la transaccin B despus o (b) la transaccin B se ejecutara primero y la transaccin A despus.
332
333
I!
1
11
:1
Este concepto se conoce como secuenciabilidad de las transacciones. Efectivamente, significa que cada usuario de la base de datos puede tener acceso a ella como si ningn otro usuario tuviera acceso a la base de datos de manera concurrente. En la prctica, se pueden estar ejecutando docenas o centenares de transacciones-de manera simultnea dentro de las grandes bases de datos de produccin. El concepto de secuenciabilidad puede ampliarse directamente para abarcar esta situacin. La secuenciabilidad garantiza que, si se est ejecutando un nmero N de transacciones simultneas, el SOBD debe asegurar que el resultado sea el mismo que si se hubieran ejecutado en una secuencia dada, una a una. El concepto no especifica la secuencia de transacciones que debe emplearse, slo que el resultado debe coincidir con el de alguna secuencia. El hecho de que el SGBD asle al usuario de las acciones de otros usuarios concurrentes no significa que se pueda olvidar totalmente de ellos. De hecho, la situacin viene a ser la contraria. Como los otros usuarios desean actualizar de manera concurrente la base de datos, hay que hacer que las transacciones sean lo ms cortas y sencillas posible, para maximizar la cantidad de procesamiento en paralelo que se pueda realizar. Supngase, por ejemplo, que se ejecuta un programa que lleva a cabo una secuencia de tres consultas de gran tamao. Dado que el programa no actualiza la base de datos, pudiera parecer que no hay que preocuparse de las transacciones. Ciertamente, parece innecesario utilizar las instrucciones COMMIT. Pero, de hecho, el programa debe utilizar una instruccin COMMIT despus de cada consulta. El motivo? Recurdese que SQL comienza de manera automtica una Jransaccin con la primera instruccin SQL de cada programa. Sin una instruccin COMMIT, la rransaccin contina hasta que el programa concluye. Adems, SQL garantiza que los datos recuperados durante una transaccin sean autoconsistentes y no se vean afectados por las transacciones de otros usuari"os. Esto significa que, una vez que el programa recupera una fila de la base de datos, ningn otro usuario puede modificar esa fila hasta que concluya la transaccin, ya que pudiera intentarse volver a recuperar la fila ms adelante en la transaccin, y el SGBD debe garantizar que se vean los mismos datos. Por tanto, mientras el programa realiza sus tres consultas, evitar que otros usuarios actualicen fragmentos cada vez mayores de la base de datos. La moraleja de este ejemplo es sencilla: al escribir programas para bases de datos de SQL de produccin hay que preocuparse siempre de las transacciones. Las transacciones deben ser siempre todo lo breves que sea posible. COMMIT rpido y COMMIT a menudo es un buen consejo cuando se emplea SQL para programacin. En la prctica, la implementacin de un modelo estricto de transacciones multiusuario puede suponer una sobrecarga considerable en la operacin de una base de datos con docenas, centenares o millares de usuarios concurrentes. Adems, puede que las particularidades de la aplicacin no exijan el aislamiento absoluto entre los programas de usuario que implica el modelo de transacciones de SQL. Por ejemplo; puede que el diseador de la aplicacin sepa que se ha diseado el programa de bsqueda de pedidos de modo que nunca intente leer y volver a leer una fila de la base de datos durante cada transaccin. En este caso, el problema de
los datos inconsistentes no puede darse, debido a la estructura del programa. De manera alternativa, puede que el diseador de la aplicacin sepa que todos los accesos de un programa a tablas concretas de la base de datos son de slo lectura. Si el programador puede transmitir infonnacin de este tipo al SGBD, se puede eliminar parte de la sobrecarga de las. transacciones de SQL. El estndar SQLl no abordaba este problema del rendimiento de las bses de datos, y la mayor parte de las marcas de SGBD implementaban esquemas propietarios para mejorar el rendimiento de las transacciones de SQL. El estndar SQL2 especific una nueva instruccin SET TRANSACTION cuya funcin es especificar el nivel de soporte del modelo de transacciones de SQL que necesita cada aplicacin. No hace falta utilizar la instwccin SET TRANSACTION para el empleo ocasional de SQL ni para el procesamiento de transacciones de SQL sencillas o de poco volumen. Para comprender completamente esta operacin, resulta til comprender los cierres y otras tcnicas empleadas por los productos de SGBD comerciales para implementar transacciones de SQL multiusuario. El resto de este captulo estudia los bloqueos, las posibilidades de optimizacin de rendimientode SQL2 y las diferentes Iarcas de SGBD que dependen de ello.
Bloqueo
La mayor parte de los principales productos de SGBD utilizan tcnicas de bloqueo sofisticadas para manejar las transacciones de SQL simultneas para muchos usuarios concurrentes. No obstante, los conceptos bsicos de los bloqueos y de las transacciones son muy sencillos. La Figura 12.10 muestra un esquema de bloqueo sen cilla y el modo en que maneja la disputa entre dos transacciones simultneas. Cuando la transaccin A de la figura tiene acceso a la base de datos, el SGBD bloquea de manera automtica cada parte de la base de datos que la transaccin recupera. o modifica. La transaccin B sigue adelante en paralelo, y el SGBD bloquea tambin las partes de la base de datos a las que tiene acceso. Si la transaccin B intenta tener acceso a la parte de la base de datos que ha bloqueado la transaccin A, el SGBD bloquea la transaccin B, lo que hace que espere a que se desbloqueen los datos. El SGBD slo libera los bloqueos establecidos por la transaccin A cuando concluye con una operacin COMMIT o ROLLBACK. El SGBD desbloquea entonces la transaccin B, lo que le permite seguir adelante. La transaccin B puede bloquear ahora esa parte de la base de datos por s misma, protegindola de los efectos de otras transacciones. Como muestra la figura, la tcnica de los bloqueos concede de manera temporal a una transaccin acceso exclusivo a una parte de la base de datos, evitando que otras transacciones modifiquen los datos bloqueados. Los bloqueos, por tanto, resuelven todos los problemas de las transacciones concurrentes. Evitan que las actualizaciones perdidas, los datos no comprometidos y los datos inconsistentes corrompan la base de datos. Sin embargo, los bloqueos introducen un problema nuevo ----,-pu~de que haga que una transaccin espere un tiempo muy largo mientras los fragmentos de la base de datos a los. que desea. tener acceso estn bloqueados por otras transacciones.
334
335
Transaccin A
SGBD
Transaccin B
PRQJ){ICTOS
12,01
desbloqueada desbloqueada desbloqueada I I I , I I

T I
~ ~
Bloq"..d.
UPDATE PEDIroS
I~ Proced~~ra A
~
Bloqueada
para B P
d
~UPDATE
12'"
.:12::'O::2:.....~.,--...,...,.,
PRODUCTOSI
12:03
SELECT.
FOH OFICINAS....-------
~ Pro--d.,
.....
Bloqueada
para A
cooo "
1
I
Esperar.......-i SELECT...
12:05
UPDATE PEDIDOS
I~
Proceder
12:06
1UPDATE OFlCINASI~ Proceder

12:07
:'::::""'CO=MM"'=T:---'--+
desbloqueada desbloqueada _:.....:.:::=:.....--J~ Proceder I I I Bloqueada para B
+ +
1 I T
Proceder
1----'-=--,
12:07 12:08
I
I I I I I I I I I I I
--tof
FOH OFICINAS ,
: I
I I
desbloqueada desbloqueada Proceder,_..... ::J'--_..:C..:OMM=':.:T_--J1

I I
Figura 12.10.
Bloqueo con dos transacciones concurrentes.
Niveles de bloqueo
Los bloqueos pueden implementarse en varios niveles de la base de dalos. En su forma ms bsica. el SGBD podria bloquear toda la base de datos para cada transaccin. Esta estrategia de bloqueo sera sencilla de implementar, pero slo pemiitira el procesamiento de las transacciones una a una. Si la transaccin incluye algn tiempo muerto (como puede ser tiempo para discutir un pedido con un cliente), todos los dems accesos a la base de datos se bloquearan durante ese tiempo, lo que llevara a un rendimiento inaceptablemente bajo. No obstante, el bloqueo en
el nivel de la base de datos puede resultar adecuado para ciertos tipos de transacciones, como las que modifican la estructura de la base de datos o para consultas complejas que deben explorar muchas tablas de gran tamao. En esos casos puede resultar ms eficiente realizar rpidamente una nica operacin de bloqueo, ejecutar rpidamente la operacin y volver a desbloquear la base de datos que bloquear docenas de tablas una a una. Una forma mejorada de bloqueo es el que se produce en eln;vel de tablas. En este esquema el SGBD slo bloquea las tablas a las que tiene acceso una transaccin. Otras transacciones pueden tener acceso de manera concurrente a otras tablas. Esta tcnica permite ms procesamiento paralelo, pero todava puede llevar a un rendimiento inaceptablemente bajo en aplicaciones como la introduccin de pedidos, en las que muchos usuarios deben compartir el acceso a las mismas tablas. Muchos productos de SGBD implementan los bloqueos en el nivel de pginas. En este esquema el SGBD bloquea bloques de datos (pginas) desde el disco a medida que una transaccin tiene acceso a ellas. Se evita que otras transacciones tengan acceso a las pginas bloqueadas, pero pueden tener acceso (y bloquear para ellas mismas) otras pginas de datos. Se utilizan frecuentemente tamaos de pginas de 2KB, de 4KB y de 16KB. Dado que las tablas de gran tamao se extienden a Jo largo de cientos o de millares de pginas, dos transacciones que intenten tener acceso a dos fiJas diferentes de una tabla tendrn normalmente acceso a dos pginas diferentes, lo que permite que dos transacciones sigan adelante en paralelo. En los ltimos aos la mayor parte de los SaBD comerciales han ido ms all del bloqueo en el nivel de pgina: hasta los bloqueos en el nivel de filas. Los blo~ queos en el nivel de filas permiten que dos transacciones concurrentes que tienen acceso a dos filas diferentes de una tabla sigan adelante en paralelo, aunque las dos filas se hallen en el mismo bloque del disco. Aunque esto pueda parecer una posibilidad remota, puede suponer un problema real con las tablas de pequeo tamao que contienen registros pequeos, como la tabla OFICINAS de la base de datos de ejemplo. Los bloqueos en el nivel de filas ofrecen un grado elevado de ejecucin paralela de las transacciones. Por desgracia, el seguimiento de los bloqueos de fragmentos de la base de datos de longitud variable (en otras palabras, de filas), en lugar de las pginas de tamao fijo, resulta una tarea mucho ms compleja, por lo que el mayor paralelismo llega a costa de una lgica de bloqueos ms sofisticada y de una mayor sobrecarga. De hecho, para ciertas transacciones O aplicaciones, la sobrecarga de los bloqueos en el nivel de filas puede ser mayor que las ganancias de rendimiento al permitir ms operaciones en paralelo dentro de la base de datos. Algunos productos de SGBD abordan esta situacin promoviendo de manera automtica muchos bloqueos en el nivel de tablas a bloqueos en el nivel de pginas, o de tablas cuando el nmero de bloqueos en el nivel de filas de una transaccin dada superan cierto lmite. Como muestra este ejemplo, no ocurre siempre que un nivel de implementacin de bloqueos ms granular (menor) sea mejor; el mejor esquema depende enormemente de las transacciones concretas y de las operaciones de SQL que puedan contener. Resulta posible tericamente ir ms all de los bloqueos en el nivel de filas, hasta los bloqueos en el nivel de los elementos de datos. En teora, esto ofrecera todava ms paralelismo que los bloqueos en el nivel de filas, ya que permitira el acceso si-
336
337
rnultneo a la misma fila por dos transacciones diferentes, siempre que tuvieran acceso a conjuntos de columnas diferentes. Sin embargo, la 'sobrecarga del manejo de los bloqueos en el nivel de los datos, ha sobrepasado hasla ahora sus ventajas potenciales. Ningn 'SGBD comercial de SQL utiliza bloqueos en el nivel de los elementos de
datos. De hecho, los bloqueos constituyen un rea de investigacin considerable en la

tecnologa de las bases de d'J-tos. y los esquemas de bloqueo utilizados en los productos de SGBD comerciales son mucho' ms sofisticados que el esquema fundamental aqu descrito. El ms directo de estos esquemas avanzados de bloqueo, que utiliza bloqueos compartidos y bloqueos exclusivos, se describe en el apartado siguiente.
Bloqueos compartidos y exclusivos

Para incrementar el acceso simultneo a las bases de datos, la mayor parte de los productos de SGBD comerciales utilizan un esquema de bloqueo con ms de un tipo de bloqueo. Los esquemas que utilizan bloqueos compartidos y bloqueos exclusivos resultan bastante frecuentes: Bloqueo compartido. Utilizado por el SGBD cuando una transaccin desea leer datos de la base de datos. Otra transaccin concurrente puede adquirir tambin un bloqueo compartido sobre los mismos datos, lo que permite que la otra transaccin lea tambin los datos. Bloqueo exclusivo. Utilizado por el SGBD cuando una transaccin desea actualizar los datos de la base de datos. Cuando una transaccin tiene un bloqueo exclusivo sobre algunos datos, las dems transacciones no pueden adquirir ningn tipo de bloqueo (ni compartido ni exclusivo) sobre esos datos. La Figura 12.11 muestra las reglas de este esquema de bloqueo y las combinaciones de bloqueos permitidas que pueden tener dos transacciones concurrentes.
Obsrvese que una transaccin slo puede adquirir un bloqueo exclusivo si ninguna otra transaccin tiene en ese momento un bloqueo ni compartido ni exclusivo sobre esos datos. Si una transaccin intema adquirir un bloqueo no permitido por las reglas de la Figura 12.11, se bloquea hasta que las dems transacciones desbloqueen los datos que necesita. La Figura 12.12 muestra las mismas transacciones que pueden verse en la Figura 12.10, esta vez empleando bloqueos compartidos y bloqueos exclusivos. Si se comparan las dos figuras, se puede ver el modo en que el nuevo esquema mejora el acceso simultneo a la base de datos. Los productos de SGBD maduros y complejos, como DB2, tienen ms de dos tipos de bloqueos y utilizan diferentes tcnicas de bloqueo en diferentes niveles de la base de datos. Pese a su mayor complejidad, el objetivo de los esquemas de bloqueo sigue siendo el mismo: evitar interferencias no
Trans.accin A
SGBO
Transaccin B
fEllIOQO
Desbloqueada
~ Desbloqueada
PRODUCTOS
Desbloqueada
12:01
UPOATE PEDIDOS
I~
Bloqueo exclusivo para A Proceder
..
,
I I I I I I I
I I I I
12:03
S';(..ECT.
FROM OFICINAS
~Iproceder
Bloqueo compar1ido para A
Bloqueo exclusivo para B Proceder
12:02
UPDATE PlI.ooucros
Bloqueo companido para A. B
12:04
Proceder
1
COXMIT
SELECT . FROM OFICINAS
12:05
Sin bloqueo
Bloqueo compartido
Bloqueo excusivo
UPOATE PEDIDOS
I~I
Proceder
I I
1
Bloqueo companido para A
DesblOq~eada
I I I I I I
I
~12:05
P/oceder
Sin bloqueo Transaccin 1
OK OK OK
OK OK NO
OK NO NO
I","
12:07
UPOATE
OFICINASI~
Proceder
Bloqueo exclusivo pareA
Bloqueo compartido
Bloqueo exclusivo
""'UT
1-1
+-- Proceder
o...,;,'"''
Figura 12.12.
I
".,J,~."
I
I
I
I
,.,
I I I
Figura 12.11.
Reglas para los bloqueos compartidos y exclusivos.
Bloqueos compartidos y exclusivos.
338
339
deseadas entre las transacciones, al tiempo que ofrecer el mayor acceso simultneo posible a la hase de datos. todo ello con la sobrecarga de bloqueos mnima.
Interbloqueos
Por desgracia. el empleo de cualquier esquema de bloqueo para albergar las transacciones de SQL concurrentes lleva a un problema denominado interbloqueo. La Figura 12.13 ilustra una situacin de interbloqueo. El programa A actualiza la tabla PEDIDOS. por lo que bloquea parte de la tabla. Mientras tanto, el programa B actualiza la tabla PRODUCTOS, bloqueando parte de la
Transaccin A
~
SGBO
PROpUqpS
Desblo~ueada
Transaccin B
Desbl~ueada
12;01
UPDATE PEDIDOS
1-
Proceder
Bloqueo exclusivo para A Bloqueo exclusivo para B
I I I I I
12:02
Proceder
IUPDATE
12:03
--aJ UPDATE
PRODUCTOS
PRODUCTOS
~ Esperar
12:04
Esperar ~ UPDATE PEDIDOS -)
Figura 12.13: Un interbloqueo de transacciones.
I I I I I I I I I I
tabla. Ahora el programa A intenta actualizar la tabla PRODUCTOS y el programa B intenta actualizar la tabla PEDIDOS, pretendiendo en cada caso actualizar una parte de la tabla que ha estado bloqueada previamente por el otro programa (la misma fila o la misma pgina, en funci6n del tipo de bloqueo implementado). Sin intervencin exterior cada programa esperar de manera indefinida a que el otro programa comprometa su transaccin y desbloquee los datos. La situacin de la figura es un interbloqueo sencillo entre dos programas, pero se pueden dar situaciones ms complejas en las que tres, cuatro o ms programas se hallen en un ciclo de bloqueos y cada uno de ellos espere datos que estn bloqueados por alguno de los otros programas. Para tratar con los interbloqueos, los SGBD suelen incluir lgica que comprueba de manera peridica (por ejemplo, cada cinco segundos) los bloqueos mantenidos por diferentes transacciones. Cuando detecta un interbloqueo, el SGBD escoge de manera arbitraria una de las transacciones como perdedora del interbloqueo y hace que retroceda. Esto libera los bloqueos mantenidos por la transaccin perdedora, lo que permite continuar a la vencedora del interbloqueo. El programa perdedor recibe un cdigo de error que infonna de que ha perdido un interbloqueo y de que se ha hecho retroceder a su transaccin. Este esquema de rotura de interbloqueos significa que cualquier instruccin de SQL puede devolver un cdigo de error de prdida de interbloqueo, aunque no haya nada errneo en la instruccin en s misma. Por tanto, aunque COMMIT y ROLLBACK son las instrucciones de procesamiento de transacciones de SQL. resulta posible que otras instrucciones de SQL -una instruccin INSERT. por ejemplo. o incluso una instruccin SELECT- resulten perdedoras de un interbloqueo. Se hace retroceder a la transaccin que intenta realizar la instruccin sin que haya cometido ningn error. slo debido al resto de la actividad concurrente de la base de datos. Puede que esto parezca injusto. pero. en la prctica. resulta mucho mejor que las otras dos alternativas -interbloqueos eternos o corrupcin de la base de datos. Si se produce un error de prdida de interbloqueo en SQL interactivo, el usuario puede, sencillamente. volver a escribir las instrucciones de SQL. En SQL para programacin el programa de aplicacin debe estar preparado para manejar el cdigo de error de prdida de interbloqueo. Generalmente, el programa responder advirtiendo al usuario o volviendo a intentar la transaccin de manera automtica. La probabilidad de los interbloqueos puede reducirse de manera espectacular planificando con cuidado las actualizaciones de la base de datos. Todos los programas que actualizan varias tablas durante una transaccin deben, siempre que sea posible, hacerlo en el mismo orden. Esto permite a los bloqueos fluir con suavidad por las tablas. minimizando la posibilidad de interbloqueo. Adems. algunas de las caractersticas de bloqueo avanzadas que se describen en apartados posteriores de este captulo pueden utilizarse para reducir an ms el nmero de interbloqueos que se producen.
Tcnicas avanzadas de bloqueo
Muchos productos comerciales de bases de datos ofrecen caractersticas avanzadas de bloqueo que superan ampliamente las proporcionadas por las transacciones estndar de SQL. Se incluyen:
340
---
341
Bloqueos explcitos. Un programa puede bloquear de manera explcita toda una tabla o alguna otra parte de la base de datos si va a tener acceso a ella repetidas veces. Niveles de aislamiento. Se puede indicar al SGBD que un programa concreto no volver a recuperar datos durante una. transaccin, lo que permite al SGBO liberar los bloqueos antes de que concluya la transaccin. Parmetros de bloqueo. El administrador de la base de datos puede ajustar de manera manual el tamao del fragmento bloqueable de la base de datos y olros parmetros de bl<:,queo para ajustar el rendimiento de los bloqueos.
t- LOCK
TABLE nombre-tabla IN
---r--
SHARE
.-J
MODE ----..
L- EXCLUSIVE
Figura"12.14. Diagrama sintctico de la instruccin LOCK TABLE.
Estas caractersticas no suelen ser estndar y dependen de cada producto. No obstante, varias de ellas, especialmente las introducidas inicialmente en las versiones de DB2 para grandes sistemas hace aos, se han implementado en varios productos comerciales de SQL y han conseguido generalizarse, aunque no sean estndar. De hecho, las caractersticas de los niveles de aislamiento introducidas en DB2 han logrado incorporarse al estndar SQL2.
Bloqueos explcitos
gn motivo mientras se mantenga el bloqu~o. Es el modo que se suele solicitar para transacciones de actualizacin masiva. El modo SHARE adquiere un bloqueo compartido sobre toda la tabla. Otras transacciones pueden leer partes de la tabla (es decir, tambin pueden adquirir bloqueos compartidos), pero no pueden actualizar ninguna parte de la tabla. Por supuesto, si la transaccin que emite la instruccin LOCK TABLE actualiza parte de la tabla, seguir creando la sobrecarga que supone adquirir bloqueos exclusivos sobre las partes de la tabla que actualice. Se trata del modo en que se. suele solicitar si se desea una instantnea de la tabla, exacta en un momento dado. Oracle tambin alberga una instruccin LQCK TABLE de tipo DB2. Se puede lograr el mismo efecto en Ingres con una instruccin diferente. Otr.os sistemas de gestin de bases de datos no admiten en absoluto los bloqueos explcitos, y prefieren, en su lugar, optimizar sus tcnicas de bloqueo implcito.
Si una transaccin tiene acceso a una tabla repetidas veces, la sobrecarga de la adquisicin de pequeos bloqueos sobre muchas partes de la tabla puede ser importante. Un programa de actualizacin masiva que recorra cada fila de la tabla, por ejemplo, bloquear toda la tabla, fragmento a fragmento. segn avance. Para este tipo de transaccin el programa debera bloquear de manera explcita toda la tabla, procesar las actualizaciones y luego desbloquear la tabla. El bloqueo de toda la tabla tiene tres ventajas: Elimina la sobrecarga de los bloqueos fila a fila (o pgina a pgina). Elimina la posibilidad de que otra transaccin bloquee parte de la tabla y obligue a la transaccin de actualizacin masiva a esperar. Elimina la posibilidad de que otra transaccin bloquee parte de la tabla e interbloquee la transaccin de actualizacin masiva, lo que la obligara a reiniciarse. Por supuesto, el bloqueo de la tabla tiene el inconveniente de que todas las dems transacciones que intenten tener acceso a la tabla debern esperar mientras se realiza la actualizacin. Sin embargo, como la transaccin de actualizacin masiva puede avanzar mucho ms rpidamente, el flujo global del SGBD puede incrementarse bloqueando la tabla de manera explcita. En las bases de datos de IBM se emplea la instruccin LOCK TABLE, que puede verse en la Figura 12.14, para bloquear de manera explcita toda una tabla. Ofrece dos modos de bloqueo: El mod.o EXCLUSIVE adquiere un bloqueo exclusivo sobre toda la tabla. Ninguna otra transaccin puede tener acceso a ninguna parte de la tabla por nin-
Niveles de aislamiento *
Bajo la estricta definicin de las transacciones de SQL no se permite que ninguna accin de una transaccin que se ejecute de- manera simultnea afecte a los datos visibles en el curso de la transaccin. Si el programa lleva a cabo una consulta de la base de datos durante una transaccin. sigue adelante con otra tarea y, posteriormente, lleva a cabo la misma consulta de la base de datos por segunda vez, el mecanismo de las. transacciones de SQL garantiza que los datos devueltos por las dos consultas sern idnticos (a menos que la transaccin que se est llevando a cabo actuara para modificar los datos). Esta posibilidad de volver a recuperar de manera digna~ de confianza una fila durante una transaccin es el nivel de aislamiento ms elevado que el programa puede tener respecto de otros programas y usuarios. El nivel de aislamiento se denomina nivel de aislamiento de la transaccin. Este aislamiento absoluto de la transaccin respecto de todas las dems transacciones que se ejecutan de manera simultnea resulta muy costoso en trminos de bloqueos de la base de datos y de prdida de simultaneidad de la base de datos. A medida que el programa lee cada fila de los resultados de la consulta el SGBD debe bloquear la fila (con un bloqueo compartido) para evitar que las transacciones simultneas modifiquen sta. Estos bloqueos deben mantenerse hasta el final de la transaccin, por si acaso el programa volviera a realizar la consulta. En mu-
342
343
chos casos, el SGBD puede reducir de manera significativa la sobrecarga de bloqueos si conoce con anticipacin el modo en que el programa tendr acceso a la base de datos durante las transacciones. Para obtener esta eficiencia las principales bases de datos para grandes sistemas de IBM aadieron el soporte del concepto de nivel de aislamiento especificado por el usuario, que concede al usuario el control sobre el equilibrio entre aislamiento y eficiencia de procesamiento. La especificacin SQL2 formaliz el concepto de nivel de aislamiento de IBM y lo ampli para incluir cuatro niveles de aislamiento, que pueden verse en la Figura 12.]5. Los niveles de aislamiento se relacionan directamente con los problemas fundamentales de actualizaciones multiusuario ya estudiados en este captulo. A medida que disminuye el nivel de aislamiento (segn se baja por las filas de la tabla), el SGBD asla al usuario de menos problemas de las actualizaciones multiusuario. El nivel de aislamiento SERIALIZABLE es el nivel ms elevado que se ofrece. En este nivel, el SGBD garantiza que los efectos de la ejecucin simultnea de transacciones son exactamente los mismos que si se ejecutaran una despus de otra. Se trata del nivel de aislamiento predeterminado especificado en el estndar ANSI/ISO SQL, ya que es el modo en que se supone que funcionan las bases de datos de SQL. Si el programa necesita llevar a cabo dos veces la misma consulta de varias filas durante una transaccin y que se le garantice que los resultados sern idnticos independientemente del resto de actividades de la base de datos, se debe utilizar el nivel de aislamiento SERIAL!ZABLE.
Problema de las actualizaciones multiusuario
Nivel de aislamiento
Actualizacin perdida Enviado por el
Datos no comprometidos Enviado por el
Datos inconsistentes Enviado por el
Insercin fantasma Enviado por el
SERIALIZABLE
SGBD
REPEATABLE READ
Enviado por el
SGBD
Enviado por el
SGBD
Enviado por el
SGBD
Puede producirse Puede producirse
SGBD
READ COMMITED
SGBD
Enviado por el
SGBD
Puede producirse
Enviado por el
SGBD
READ UNCOMMITED
Enviado por el
SGBD
Puede producirse
SGBD
Puede producirse
Puede producirse
Figura 12.15.
Niveles de aislamiento y actualizaciones multiusuario.
El nivel de aislamiento REPEATABLE READ es el segundo nivel ms elevado. En este nivel no se permite a la transaccin ver actualizaciones de otras transacciones ni comprometidas ni sin comprometer, y no se pueden producir problemas por l~ modificacin de los datos. No obstante, puede que una fila insertada en la base de datos por otra transaccin concurrente se haga visible durante la transaccin. En consecuencia, puede que una consulta de varias filas ejecutada previamente en la transaccin d r~sultados diferentes que la misma consulta ejecutada posteriormente en la misma transaccin (problema de la insercin fantasma). Si el programa no depende de la posibilidad de repetir una consulta de varias filas durante una transaccin, se puede utilizar con seguridad el nivel de aislamiento REPEATABLE READ para mejorar el rendimiento del SGBD sin sacrificar la integridad de los datos. Se trata de uno de los niveles de aislamiento incluidos en los productos de bases de datos de IBM para grandes sistemas. El nivel de aislamiento READ COMMITTED es el tercer nivel ms elevado. En este modo no se permite que la transaccin vea actualizaciones no comprometidas de otras transacciones, por lo que los problemas de la actualizacin perdida y de los datos no comprometidos no pueden producirse. Sin embargo, las actualizaciones comprometidas por otras transacciones que se ejecuten de manera concurrente pueden hacerse visibles en el curso de la transaccin. El programa podra, por ejemplo, llevar a cabo una instruccin SELECT de una sola fila dos veces a lo largo de la transaccin y hallar que otro usuario ha modificado los datos de la fila. Si el programa no depende de la posibilidad de volver a leer una sola fila de datos durante la transaccin y no acumula valores totales ni realiza otro tipo de clculos que se basen en un conjunto de datos autoconsistente, puede utilizar tranquilamente el nivel de aislamiento READ COMMITTED. Obsrvese que si el programa intenta actualizar una fila que ya haya actualizado otro usuario, se har que la transaccin retroceda inmediatamente, para evitar que se produzca el problema de la actualizacin perdida. El nivel de aislamiento READ UNCOMMITTED es el nivel ms bajo especificado en el estndar SQL. En este modo, la transaccin puede verse afectada tanto por actualizaciones comprometidas como por actualizaciones no comprometidas de otras transacciones, por lo que se pueden producir los problemas de los datos no comprometidos, de los datos modificados y de la insercin fantasma. El SGBD sigue evitando el problema de la actualizacin perdida. Generalmente, el nivel READ UNCOMMITTED slo resulta adecuado para ciertas aplicaciones de consulta ad hoc en que el usuario puede tolerar el hecho de que el resultado de las consultas pueda contener datos desfasados (algunas marcas de SGBD llaman a este modo de aislamiento posibilidad de lectura sucia debido a esta posibilidad). Si resulta importante que el contenido de la consulta slo contenga informacin que, de hecho, se ha comprometido con la base de datos, el programa no debera utilizar este modo. El estndar SQL2 especifica la instruccin SET TRANSACTION, que puede verse en la Figura 12.16, que se emplea para establecer el nivel de aislamiento de cada instruccin. La instruccin SET TRANSACTION tambin permite especificar si la transaccin es READ ONLY (es decir, si slo realizar consultas a la base de datos) OREAD WRITE (puede consultar o actualizar la base de datos). El SGBD puede emplear esta informacin, junto con el nivel de aislamiento, para optimizar
344
~Captulo 12:
345
t-SET TRANSACTION
~
ISQLATIQN
LEVELlSERIALIZAB~E
REPEATABLE READ READ COMMITTED READ UNCOMMITTED
READ WRITE READ ONLY
j.
El SGBD logres ofrece una posibilidad parecida a los modos de aislamiento de las bases de datos de lBM, pero de una forma diferente. Mediante la instruccin SET LOCKMODE los programas de aplicacin pueden indicar a logres el tipo de bloqueo que debe utilizar al tratar las consultas a las bases de datos. Las opciones son las siguientes:
Figura 12.16.
Diagrama sintctico de la instruccin SET TRANSACTION.
Sin bloqueo. Parecido al modo de IBM CURSOR STABILITY que se acaba de describir. Bloqueo compartido. Parecido al modo de IBM REPEATABLE READ que se acaba de describir. Bloqueo exclusivo. Ofrece acceso exclusivo a la tabla durante la consulta, y una funcionalidad similar a la de la inslruccin de IBM LOCK TABLE. El valor predeterminado de lngres es el bloqueo compartido, que recuerda al valor predeterminado de lectura repetible del esquema de lBM. Obsrvese, no obstante, que los modos de bloqueo de lngres los define una instruccin ejecutable de SQL. A diferencia de los modos de lBM, que deben escogerse en el momento de la compilacin, los modos de logres pueden escogerse c.uando se ejecuta el programa e, incluso, cambiarse de una consulta a otra.
Parmetros de bloqueo
el procesamiento de la base de datos. El nivel de aislamiento predeterminado es SERIALIZABLE. Si se especifica el nivel de aislamiento READ UNCOMMITTED, se da por supuesto que es READ ONLY, Y no se pueden especificar transacciones READ WRITE. En caso contrario, el valor predeterminado son las transacciones READ WRITE. Estos valores predeterminados ofrecen la mxima seguridad para las transacciones, a expensas del rendimiento de la base de datos, pero evitan que los programadores de SQL poco experimentados sufran sin darse cuenta de alguno de los problemas del procesamiento de transacciones multiusuario. Obsrvese que la instruccin SET TRANSACTION especificada en el estndar SQL2 es una instruccin de SQL ejecutable. Resulta posible y, en ocasiones, muy deseable hacer que una instruccin d.el programa se ejecute en un modo y la siguiente en un modo diferente. Sin embargo, no se pueden modificar los niveles de aislamiento ni los modos de lectura y escritura en mitad de una transaccin. El estndar exige, de hecho, que la instruccin 5ET TRAN5ACTION sea la primera ins truccin de cada transaccin. Esto significa que debe ejecutarse como la primera instruccin tras COMMIT o ROLLBACK, o como la primera instruccin de un programa, antes de ninguna otra instruccin que afecte al contenido o a la estructura de la base de datos. Como ya se indic antes en el apartado Tcnicas avanzadas de bloqueo, muchos de los productos comerciales de SGBD implementaron sus esquemas de bloqueo y de mejora del rendimiento mucho antes de' la publicacin del estndar SQL2, y esas estrategias de bloqueo afectan al ncleo de la arquitectura y de la lgica internas de la base de datos. No resulta sorprendente que la adopcin en este terreno de estndar SQL2 haya resultado relativamente lenta en comparacin con algunas otras reas en que la implementacin era mucho ms sencilla. Por ejemplo, las bases de datos de IBM para grandes sistemas (DB2 y SQUDS) ofrecan histricamente la opcin entre dos niveles de aislamiento -REPEATAELE READ Y READ COMMITTED (denominado CURSOR STAEILITY en la termino~ loga de 1BM). En las implementaciones de IBM se realiza la opcin durante el proceso de desarrollo del programa, en el paso BIND, que se describe en el Ca~ pltulo 17. Aunque los modos no constituyan estrictamente parte del lenguaje SQL, la eleccin del modo afecta mucho a la menera en que se comporta la aplicacin y a la manera en que puede utilizar los datos recuperados.
Un SGBD maduro, como DB2, SQUDS, Orade, Inforrnix, Sybase o SQL Server, emplea tcnicas de bloqueo mucho ms complejas que las aqu descritas. El administrador de la base de datos puede mejorar el rendimiento de estos sistemas definiendo manualmente los parmetros de bloqueo. Entre los parmetros que pueden ajustarse normalmente se encuentran: Tamao de los bloqueos. Algunos productos de SGBD ofrecen la posibilidad de elegir el nivel de tablas, el nivel de pginas, el nivel de filas y otros tamaos de bloqueo. En funcin de cada aplicacin concreta puede resultar adecuado un tamao de bloqueo diferente. Nmero de bloqueos. El SGBD suele permitir que cada transaccin tenga un nmero finito de bloqueos. El administrador de la base de datos suele poder definir este limite, elevndolo para permitir transacciones ms complejas o disminuyndolo para promover una escalada temprana de los bloqueos. Aumento del nivel de bloqueo. El SGBD aumenta a menudo el nivel de los bloqueos de manera automtica, sustituyendo muchos bloqueos de pequeo tamao por un solo bloqueo de mayor tamao (por ejemplo, sustituyendo muchos bloqueos en el nivel de pgina por un bloqueo en el nivel de tabla). Puede que el administrador de la base de datos tenga algn control sobre este proceso de escalada. Caducidad de los bloqueos. Aunque una transaccin no est interbloqueada con otra, puede que espere mucho tiempo a que la otra transaccin libere sus bloqueos. Algunas marcas de SGBD implementan una caracterstica de
346
Capitulo 12: Procesamiento de transacciones
347
caducidad, en la que la instruccin de SQL falla con un cdigo de error de SQL si no puede obtener los bloqueos que necesita en un periodo de tiempo determinado. Normalmente, este periodo de caducidad puede definirlo el administrador de la base de datos.
Transacciones
Valores de la base de datos Una copia
Transacciones
t ACI
14100411391
)
j
!-~-
Versiones *
Las tcnicas de bloqueo descritas en los apartados anteriores son las ms utilizadas para el soporte del procesamiento de transacciones concurrentes multiusuario en los productos de SGBD relacionales. Los bloqueos se consideran a veces un consecuencia negativa de la concurrencia, ya que, al bloquear partes de la base de datos, el SGBD da por hecho de manera implcita que es probable que las transacciones simultneas interfieran entre sr. En los ltimos aos se ha implementado en diferentes productos de SOBO y ha ido ganando popularidad un enfoque diferente de la concurrencia, denominado versiones. Las versiones a veces se consideran consecuencia positiva de la concurrencia, ya que en este enfoque el SOBO da por hecho de manera implcita que las transacciones simultneas no interferirn entre s. Con una arquitectura de bloqueo (pesimista) el SOBD mantiene internamente una y slo una copia de los datos de cada fila de la base de datos. Cuando varios usuarios tienen acceso a la base de datos, el esquema de bloqueos arbitra el acceso a cada fila de datos entre los usuarios (ms exactamente, entre las transacciones concurrentes). Sin embargo, con una arquitectura de versiones (optimista), el SOBO crear dos o ms copias de los datos de cada fila de fa base de datos cuando algn usuario intente actualizarlas. Una copia de la fila contendr los datos viejos, previos a la actualizacin; las otras copias de la fila contendrn los nuevos datos de la fila, tras la actualizacin. El SOBO realiza un seguimiento interno de las transacciones que deben ver cada versin de la fila, en funcin de sus niveles de aislamiento.
o
I
Leer CANTIDAD
;- Una copia 1 ACI 1 4100411391

ActualizarCANTIDA0=39
139
Antes
I ACI 14100411391
I
Despus
1ACI 1410041 39 I
Leer CANTIDAD
;-
;-
Antes
(c
139
erCANTIDAD
ACII 410041 139
Antes ;ACI 1 41004\ 1391
139
1ACI 1410041
,
Leer CANTIDAD
I
+
;i
Despus
3.
COMMIT
Una copia
(E 39
COMMIT COMMIT
ACI
410041 39 1
Funcionamiento de las versiones *

La Figura 12.17 muestra en funcionamiento una sencilla arquitectura de versiones. La transaccin A inicia la accin, leyendo una fila de la tabla PRODUCTOS, y halla 139 unidades de cables ACI-41004 serie 4 disponibles. La lransaccin B llega a continuacin y actualiza la misma fila, reduciendo la cantidad disponible a 39 unidades. En consecuencia, el SOBO crea internamente una copia nueva de la fila. A partir de este momento, si la transaccin B vuelve a leer el contenido de la fila, ese contenido proceder de esta segunda copia, ya que refleja el stock actualizado por la transaccin B (39 unidades). A continuacin, la transaccin e llega e intenta leer la misma fila. Como todava no se ha comprometido la actualizacin de la transaccin B, el SOBO ofrece a la transaccin C los datos de la copia antigua de la fila, que muestran 139 unidades disponibles. Lo mismo ocurre pocos segundos ms tarde con la transaccin D; tambin ver disponibles 139 unidades. Ahora la transaccin B lleva a cabo una operacin CQMMIT, ha-
COMMIT
Figura 12.17.
Las transacciones concurrentes en una arquitectura de versiones.
ciendo permanente la actualizacin de la fila. Poco despus, la transac~in E intenta leer la fila. Con la actualizacin de la transaccin B ya comprometida, el SOBO ofrecer a la transaccin E los datos de la nueva copia, que muestran cien unidades. Finalmente, las Transacciones C, D y E finalizan su actividad en la base de datos con una operacin COMMIT. La actividad mostrada en la Figura 12.17 cumple el requisito de secuenciabilidad del funcionamiento adecuado del SGBD. La serie secuencial de transacciones
348
.--6aptulo 72: Procesamiento de transacciones
349
A-C-D-B-E producira el mismo resultado que se muestra en la Figura. (De hecho, la serie A-D-C-B-E tambin producira este resultado.) Adems, la implementacin de las versiones proporciona el funcionamiento correcto sin hacer que espere ninguna de las transacciones. No se puede decir lo mismo de la implementacin tpica de los bloqueos. como puede verse en la Figura 12.18. En la Figura 12.18 la transaccin A vuelve a iniciar la accin, hallando 139 unidades de cables ACI-41004 disponibles. Internamente, el SGBD mantiene un
Transacciones
Valores de /a base de dar. '"
T,
's
1ACl I 4I0041
LeerCANTIDAD
139
I
Actuafi.
I AeI I 41004 139 I

B/oqueo compartido
J
139
AeI
I 41004 I
=39
39
Bloqueo exclusivo
@ LeerCANTlDAD
. @eerCANTIDAI
Esperar
bloqueo
I bloqueo
1ACl 1
Esperar
, ,
'T' I
,
T
.,
39
COMMIT
3. 39
LeerCANTIDAD
1
(E
3.
COMHIT COMHIT COMMIT
1ACl I 410041
39
T T
T
I
T T
Figura 12.18.
Transacciones concurrentes en una arquitectura.de bloqueos.
bloqueo compartido sobre la fila. A continuacin, la transaccin B intenta actualizarla, reduciendo el stock a 39 unidades. Si la transaccin A est operando en un nivel de aislamiento estricto (como REPEATABLE READ), la transaccin B se ver retenida en este punto, ya que no puede adquirir el bloqueo exclusivo nece~ sario. Si la transaccin A est operando en un nivel de aislamiento menos estricto, el SGBD puede pettniLir que la transaccin B siga adelante, concedindole un bloqueo exclusivo sobre la fila y actualizando realmente los datos. La fila interna de la base de datos (recurdese que slo hay una copia de cada de cada fila en esta arquitectur.a de bloqueo) muestra ahora 39 unidades disponibles. Cuando llega la transaccin C, debe esperar a que la transaccin B libere su bloqueo, a menos que la transaccin e est operando en un nivel de aislamiento muy bajo (READ UNCOMMITTED). Puede decirse lo mismo de la transaccin D. Slo despus de que se hayan comprometido los cambios de, la transaccin B pueden seguir adelante las transacciones C y D. Comparando las operaciones de las Figuras 12.17 y 12.18, merece la pena destacar dos diferencias. En primer lugar, y sobre todo, el enfoque de las versiones de la Figura 12.17 permite que ms transacciones concurrentes sigan adelante en paralelo. El enfoque de los bloqueos de la Figura 12.18 har, en la mayor parte de las circunstancias, que dos o ms transacciones esperen que otras se completen y liberen sus bloqueos. La segunda, y ms sutil, diferencia, es que el orden efectivo de la ejecucin en serie de las transacciones es diferente en las dos figuras. Como se ha indicado, en la Figura 12.17, la secuencia de transacciones A-C-D-B-E produce el resultado. En la Figura 12.18, la secuencia A-B-C-D-E produce el resultado. Obsrvese que ninguna de ellas es correcta; el principio de la secuenciabilidad slo afirma que el resultado producido por el SGBD debe coincidir con alguna secuencia de transacciones en serie. El ejemplo de la Figura 12.17 slo incluye una transaccin de actualizacin, por lo que slo son necesarias dos copias de la fila actualizada (previa y posterior a la actualizacin). La arquitectura de versiones se ampla con facilidad para acoger ms actualizaciones concurrentes. Por cada intento de actualizar la fila, el SGBD puede crear otra fila nueva, que refleje la actualizacin. Con este enfoque de varias versiones la tarea de realizacin del-seguimiento de las_transacciones que deben ver cada versin de la fila; evidentemente, se vuelve ms compleja. En la prctica, la decisin sobre la versin de la fila que debe ser visible para cada transaccin concurrente no slo depende de la secuencia de las operaciones de la base de datos, sino tambin de los niveles de aislamiento solicitados para cada transaccin. Las versiones no eliminan completamente la posibilidad de los interbloqueos en la base de datos. Las dos transacciones de la Figura 12.13, con sus intentos entrelazados de actualizar dos tablas diferentes, cada una en un orden diferente, seguirn produciendo problemas, incluso al esquema de versiones. No obstante, para cargas de trabajo con una mezcla de operaciones READ y operaciones UPDATE de la base de datos, las versiones pueden reducir de manera significativa los bloqueos y los tiempos muertos de bloqueos o interbloqueos asociados con los bloqueos compartidos.
350
351
Ventajas e inconvenientes de las versiones *

La ventaja de la arquitectura de versiones es que, en las circunstancias adecuadas, puede incrementar de manera significativa el nmero de transacciones simultneas que pueden ejecutarse en paralelo. La ejecucin simultnea se est haciendo cada vez ms importante en las instalaciones de SGBD de gran tamao, especialmente en las que soportan sitios web que pueden tener millares o decenas de millares de usuarios concurrentes. Las versiones tambin se estn volviendo ms tiles a medida que el nmero de procesadores en los sistemas informticos servidores tpicos de SGBD aumenta. Los servidores que contienen diecisis O ms procesadores se estn haciendo cada vez ms frecuentes, y los servidores de SGBD de gran tamao pueden admitir sesenta y cuatro o ms procesadores en una configuracin de multiprocesamiento simtrico (symmetric multiprocessing, SMP). Estos servidores pueden ejecutar realmente en paralelo muchas aplicaciones de acceso a la base de datos, distribuyendo la carga de trabajo entre muchos procesadores. El inconveniente de la arquitectura de las versiones es la sobrecarga interna del SGBD que crea. Una sobrecarga anterior es el requisito aadido de memoria del almacenamiento de dos o ms copias de las filas que se estn actualizando. En la prctica, una sobrecarga ms seria es la gestin de memoria exigida para asignar memoria a cada copia temporal de una fila cuando se necesite (potencialmente, millares de veces por segundo) y luego liberar la memoria para que se reutilice cuando ya no se necesiten las copias viejas de cada fila. Una sobrecarga aclicional es el seguimiento de las transacciones que deben ver cada copia de las filas. De manera implcita, la arquitectura de versiones se basa en la asuncin implcita de que la mayor parte de las transacciones simultneas tiende a no interferir entre s. Si esta asuncin resulta exacta (por ejemplo, si las transacciones que se ejecutan de manera simultnea actualizan y tienen acceso sobre todo a filas diferentes, o si la carga de trabajo de la transaccin est dominada por operaciones READ en vez de por operaciones UPDATE). entonces la sobrecarga aadida del esquema de versiones se compensar con creces por un impulso significativo de la cantidad de trabajo paralelo que puede llevarse a cabo. Si la asuncin resulta inexacta (por ejemplo, si las transacciones que se ejecutan de manera concurrente tienden a actualizar y tener acceso a las mismas filas), la sobrecarga de la tcnica de las versiones tender a hacerse muy elevada, sobrepasando las ventajas de la simultaneidad.
.1
La instruccin ROLLBACK pide al SGBD que aborte una transaccin, haciendo retroceder todas las modificaciones de la base de datos. Las transacciones son la clave de la recuperacin de las bases de datos tras los falios del sistema; slo las transacciones comprometidas en el momento del fallo permanecen en la base de datos recuperada. Las transacciones son la clave del acceso simultneo en las bases de datos multiusuario. Se garantiza al usuario o programa que su transaccin no se ver interferida por otras transacciones concurrentes. Ocasionalmente, puede que un conflicto con otra transaccin que se ejecuta de manera simultnea haga que el SGBD obligue a retroceder una transaccin sin que sta tenga ninguna culpa. Los programas de aplicacin que utilizan SQL deben estar preparados para tratar esta situacin si se llega a producir. Las sutilezas de la gestin de las transacciones y su consecuencia en el rendimiento de los SGBD son una de las reas ms complejas del empleo y la operacin de bases de datos de produccin de gran tamao. Tambin es un rea en la que las principales marcas de SGBD divergen en sus posibilidades y opciones de ajuste. Muchas marcas de SGBD utilizan tcnicas de bloqueo para manejar las tran sacciones simultneas. Para estos productos los ajustes de los parmetros de bloqueo y las instrucciones de bloqueo explcito permiten ajustar el rendimiento del procesamiento de transacciones. Una tcnica alternativa de versiones para el manejo de las transacciones simultneas est ganando popularidad. Para los productos de SGBD que utilizan las versiones, los ajustes en la profundidad del esquema de versiones y en la propia mezcla de transacciones son las claves del ajuste del rendimiento.
Resumen
Este captulo describe el mecanismo de las transacciones ofrecido por el lenguaje SQL: Una transaccin es una unidad lgica de trabajo de las bases de datos basadas en SQL. Consiste en una secuencia de instrucciones de SQL que el SGBD ejecuta de hecho como una unidad. La instruccin COMMIT seala la finalizacin con xito de una transaccin, haciendo permanentes todas las modificaciones de la base de datos.
~ ~
Parte N
ESTRUCTURA DE LA BASE DE DATOS

1"
I
P
,E
..
Un papel importante de SQL es definir la estructura y organizacin de una base de datos. Los Captulos 13 al 16 describen as caractersticas de SQL que dan soporte a es.te papel. El Captulo 13 explica cmo crear una base de datos y sus tablas. El Captulo 14 analiza las vistas, una caracterstica importante de SQL que permite a los usuarios ver organizaciones alternativas de los datos de la base de datos. Las caractersticas de seguridad de SQL que protegen los datos almacenados se describen en el Captulo 15. Finalmente, el Captulo 16 estudia el catlogo del sistema, una coleccin de tablas del sistema que describen la estructura de una base de datos.
'i
lt
CAPTULO
13

Muchos usuarios de SQL no tienen que preocuparse de crear llna base de datos; utilizan SQL interactivo o para programacin para tener acceso a una base de da tos de informacin corporativa o a alguna otra base de datos que haya sido creada por olra persona. En las bases de datos corporativas tpicas, por ejemplo, el administrador de la base de datos puede conceder permiso para recuperar y, quizs, para actualizar los datos almacenados. Sin embargo, el administrador no permitir a cualquier usuario que cree bases de datos nuevas ni que modifique la estructura de las tablas existentes. Es probable que a medida que uno se vaya encontrando ms cmodo con SQL desee comenzar a crear tablas propias para almacenar datos personales como los resultados de las pruebas de ingeniera o las predicciones de ventas. Si se emplea una base de datos multiusuario, puede que se deseen crear tablas o, incluso, bases de datos completas que se compartirn con otros usuarios. Si se utiliza una base de datos en una computadora personal, es seguro que se desearn crear tablas y bases de datos propias para dar soporte a las aplicaciones personales. Este captulo describe las caractersticas del lenguaje SQL que permiten crear bases de datos y tablas y definir su estructura.
El lenguaje de definicin de datos

Las instrucciones SELECT, INSERT, DELETE, UPDATE, COMMIT y ROLLBACK descritas en las Partes TI y ID de este libro estn relacionadas con la manipulacin de los datos de las bases de datos. Estas instrucciones se denominan colectivamente Lenguaje de manipulacin de datos (LMD) de SQL. Las instrucciones LMD pueden modificar los datos almacenados en la base de datos, pero no pueden modificar su estructura. Por ejemplo, ninguna de estas instrucciones crea ni elimina tablas ni columnas. Las modificaciones de la estructura de la base de datos las maneja un conjunto diferente de instrucciones de SQL, generalmente denominado Lenguaje de definicin de datos (LDD) de SQL. Con las instrucciones LDD se puede: 355
356
Captulo 13: Creacin de bases de datos
357
Definir y crear nuevas tablas. Eliminar tablas que ya no sean necesarias. Modificar la definicin de tablas ya existentes. Definir tablas virtuales (o vistas) de los datos. Establecer controles de seguridad para las bases de datos. Crear ndices para hacer ms rpido el acceso a las tablas. Controlar. el almacenamiento fsico. de los ~alos por el SGBD. En su mayor parte, las instrucciones LDD aslan al usuado de los detalles de bajo nivel del modo ~n Rue se almacenan fsicamente los datos en las bases de datos. Manipulan objetos abstractos de las bases de datos, como tablas y columnas. No obstante, el LDD no puede evitar completamente aspectos del almacenamiento fsico, y. necesariamente, las instrucciones y clusulas LDD que controlan el almacenamiento fsico varan de un SGBD a Olro. El ncleo del lenguaje de definicin de datos se basa en tres verbos de SQL:
CREATE. Define y DROP. Elimina un ALTER.
tipos de instrucciones de SQL. (Denomina a las instrucciones LDD instruccio nes de esquema de SQL, y a las instrucciones de LMD, instrucciones de datos de SQL e instrucciones de transacciones de SQL.) No obstante, pone al estndar en lnea con la implementacin actual de productos populares de SQL al exigir que las instrucciones LDD se ejecuten de manera interactiva y mediante un programa. El estndar SQL2 slo especifica las partes LDD que son relativamente independientes de las estructuras de almacenamiento fsico, de dependencias del sistema operativo y de otras posibilidades propias de cada marca de SOBO. En la prctica, todas las marcas de SGBD incluyen ampliaciones significativas LDD estndar para tratar estos problemas y otras posibilidades mejoradas de las bases de datos. Las diferencias entre el estndar ANSUISO y la implementacin LDD de los productos populares de SQL se describen para cada instruccin de SQL durante este captulo.
crea un objeto de la base de daros. objeto ya existente de la base de datos. Modi.fi~a la definicin de un objeto de la base de dalas.

En la instalacin de un SGBD en un gran sistema informtico (maifljrame) o en un nivel empresarial, el administrador corporativo de la base de datos es el nico responsable de la creacin de bases de datos nuevas. En las instalaciones de SOBD para grupos de trabajo ms reducidos puede que se permita a cada usuario crear sus propias bases de datos personales, pero resulta mucho ms frecuente que las bases de datos se creen de manera centralizada y luego cada usuario tenga acceso a ellas. Si se utiliza un SGBD para computadoras personales, lo ms probable es ser a la vez el administrador de la base de datos y el usuario, y habr que crear personalmente las bases de datos que se utilicen. El estndar SQLl especificaba el lenguaje SQL utilizado para describir la estructura de las bases de datos, pero no el modo en que se crean las bases de datos, ya que cada marca de SOBD haba adoptado un enfoque ligeramente diferente. Estas diferencias persisten en los productos habituales de SGBD de hoy en da. Las tcnicas utilizadas por estos productos de SQL ilustran las diferencias: DB2 de IBM tiene una estructura de base de datos predeterminada sencilla. Las bases de datos de DB2 se asocian con una copia en ejecucin del software de servidor de DB2 y los usuarios tienen acceso a ellas conectndose al servidor de DB2. Por tanto, las bases de datos se definen de hecho mediante la instalacin del software de DB2 en un sistema informtico concreto. Oracle crea, de manera predeterminada. una base de dl;ltos como parte del proceso de instalacin del software de Oracle, al igual que DB2. En su mayor parte, las tablas de usuario se ubican siempre en esta nica base de datos que abarca todo el sistema, que se denomina segn un archivo de configuracin de Oracle y se asocia con esa copia concreta del software de servidor de Oracle. Las versiones de Orade ms recientes se han ampliado con una instruccin CREATE DATABA5E para la definicin de los nombres de las bases de datos.
En todos los principales productos de SGBD basados en SQL estos tres verbos LDD pueden utilizarse mientras se ejecuta el SGBD. Por tanto, la estructura de la base de datos es dinmica. El SGBD puede crear, eliminar o modificar, por ejemplo, la definicin de las tablas de la base de datos mientras ofrece de manera simultnea acceso a la base de datos a sus usuarios. Se trata de una importante ventaja de SQL y de las bases de datos relacionales respecto a sistemas anteriores. en los que haba que detener el SGBD antes de poder modificar la estructura de la base de datos. Significa que las bases de datos relacionales pueden crecer y modificarse fcilmente a lo largo del tiempo. El empleo para produccin de las bases de datos puede continuar mientras se aaden tablas y aplicaciones nuevas. Aunque LDD y LMD son dos partes diferentes del lenguaje SQL, en la mayor parte de los productos de SGBD basados en SQL, la separacin slo es conceptual. Generalmente, las instrucciones LDD y LMD se remiten al SGBD exactamente de la misma manera, y pueden entremezclars~ libremente tanto en las sesiones interactivas de SQL como en las aplicaciones de programacin de SQL. Si un programa o un usuario necesitan una tabla para almacenar sus resultados temporales, pueden crearla, renenarla, manipular sus datos y eliminarla. Nuevamente, se trata de una importante ventaja respecto de'modelos anteriores de datos, en los que la estructura de la base de datos se fijaba al crear la base de datos. Aunque casi todos los productos comerciales de SQL admiten LDD como parte 'integral del lenguaje SQL, el estndar SQLl no lo exigra, De hecho, el estndar SQLl implica una estricta separacin entre LMD y LDD, lo que permite a los fabricantes conseguir el cumplimiento con la parte de LMD del estndar mediante una capa de SQL ubicada por encima de una base de datos subyacente que no es de SQL. El estndar SQL2 sigue diferenciando entre distintos
358

CREATE DATA-
359
SQL Server de Microsoft y Sybase incluye una instruccin
Creacin de tablas (CREATE TABLE)

La instruccin CREATE TABLE, que puede verse en la Figura 13.1, define una nueva tabla en la base de datos y la prepara para que acepte datos. Las diferentes clusulas de la instruccin especifican los elementos de la definicin de la tabla. El diagrama sintctico de la instruccin parece complicado porque hay muchas partes de la definicin que especificar y muchas opciones para cada elemento. Adems, algunas de las opciones estn disponibles en algunas marcas de SGBD o en el estndar SQL2, pero no en otras marcas. En la prctica, la creacin de tablas nuevas resulta relativamente sencilla. Cuando se ejecuta una instruccin CREATE TABLE, uno se transforma en el propietario de la tabla recin creada, a la que se le otorga el nombre especificado en la instruccin. El nombre de la tabla debe ser un nombre legal en SQL. y no debe entrar en conflicto con el de ninguna tabla ya existente. La tabla recin creada est vaca, pero el SGBD la prepara para que acepte los datos aadidos con la instruccin INSERT.
Definicin de columnas
BASE como parte de su lenguaje de definicin de datos. La instruccin anexa

DROP DATABASE destruye anteriormenre las bases de datos ya creadas. Estas
instrucciones pueden utilizarse con SQL interactivo o de programacin. Los nombres de estas bases de datos se siguen en una base de datos maestra especial que est asociada con una sola instalacin de SQL Server. Los nombres de las bases de datos deben ser nicos en cada instalacin de SQL Server. Las opciones de la instruccin CREATE DATABAS E especifican el dispositivo de E/S en el que hay que ubicar la base de datos. Informix Universal Server alberga tambin las instrucciones de SQL CREATE
y DROP DATABASE. Una opcin de la instruccin CREATE DATApermite que se cree la base de datos en un dbspace concreto, que es un rea de almacenamiento de disco controlada por el software de Informix. Otra opcin controla el tipo de registro histrico de la base de datos que hay que llevar a cabo con la nueva base de datos, con equilibrios entre el rendimiento y la integridad de los datos durante los fallos del sistema.
DATABASE BASE
El estndar SQL2 evita de manera especfica la concrecin del trmino base de datos por 10 sobrecargado que se halla de significados contradictorios procedentes de los productos SGBD. SQL2 utiliza el trmino catlogo para describir un conjunto con nombre de tablas que la mayor parte de las marcas populares de SOBD denomina base de datos. (Ms adelante se ofrece informacin adicional sobre la estructura de la base de datos especificada por el estndar SQL2, en el apartado Estructura de la base de datos y el estndar ANSI/ISO). El estndar no especifica la forma de crear o destruir catlogos, y dice especficamente que depende de la implementacin. Tambin indica el nmero de catlogos que hay y si cada instruccin de SQL que puede tener acceso a los datos desde diferentes catlogos viene definida por la implementacin. En la prctica, como puede verse en los ejemplos anteriores, muchos de los principales fabricantes de SGBD han acabado utilizando la pareja de instrucciones CREATE DATABAS E/
DROP DATABASE.
Las columnas de la tabla recin creada se definen en el cuerpo de la instruccin Las definiciones de las columnas aparecen en una lista separada por comas encerrada entre parntesis. El orden de las definiciones de las columnas determina el orden de izquierda a derecha de las columnas en la tabla. En las instrucciones CREATE TABLE admitidas por las principales marcas de SOBD, cada definicin de columna especifica lo siguiente:
CREATE TABLE.
Definiciones de tablas
La estructura ms importante de las bases de datos relacionales es la tabla. En las bases de datos multiusuario de produccin, las principales tablas suele crearlas una sola vez el administrador de la base de datos, y se utilizan da tras da. A medida que se utiliza la base de datos, se suele considerar adecuado definir tablas propias para almacenar datos personales o datos extrados de otras tablas. Estas tablas pueden ser temporales, y slo durar una sesin de SQL interactivo, o ms permanentes y durar semanas o meses. En las bases de datos de computadoras personales, la estructura de tablas resulta todava ms fluida. Como se es a la vez usuario y administrador de la base de datos, se pueden crear y destruir tablas para adaptarse a las necesidades propias sin preocuparse por otros usuarios.
Nombre de )a columna. Se utiliza para hacer referencia a la columna en las instrucciones de SQL. Cada columna de la tabla debe tener un nombre nico, pero los nombres pueden repetir los de columnas de otras tablas. Tipo de datos. Identifica el tipo de datos que almacena la columna. Los tipos de dalos se estudiaron en el Captulo 5. Algunos tipos de datos, como VARCHAR y DECIMAL, exigen informacin adicional, como la longitud o el nmero de posiciones decimales de los datos. Esta informacin adicional se encierra entre parntesis a continuacin de la palabra clave que especifica el tipo de dalos. Datos requeridos. Determina si la columna contiene datos requeridos, y evita que aparezcan valores NULL en la columna; en caso contrario, se permiten los v~lores NULL. Valor predeterminado. Utiliza un valor predeterminado opcional para la columna cuando la instruccin INSERT para la tabla no especifica ningn valor. El estndar SQL2 permite varias partes adicionales a la definicin de una columna, que puede utilizarse para exigir que la columna contenga valores nicos, para especificar que la columna es una clave primaria o una clave externa o para restringir los valores de los datos que puede contener la columna. Se trata de ver-
360
361
~ CREATE TABLE
nombre-de-tabla
(Fdefinicin-de-columna?T)-'.
definicin-de-restriccin-de-tabla
siones de una sola columna de capacidades proporcionadas por otras clusulas de la instruccin CREATE TABLE, y se describen corno parte de esa instruccin en los apartados siguientes. A continuaci!1 se ofrecen algunas inslrucciones CREATE TABLE sencillas para las tablas de la base de datos de ejemplo: Definir la tabla OFICINAS y sus columnas.
CREATE TABLE (OFICINA CIUDAD REGION JEF OBJETIVO VENTAS OFICINAS INTEGER NOT NULL, VARCHAR(15) NOT NULL, VARCHAR(10} NOT NULL, INTEGER, MONEY, MONEY NOT NULL)
PEDIDOS
definicin-de-columna: - nombre-de-columna tipo-de-dalos
c=
DEE'AULT valor
==--:f L
NOT NULL
..
definicin-de-restriccin-de-labla:
--r---------------., -'rrestriccin-de-clave-primaria
CQNSTRAINT
..
nombre-de-restriccin
restriccin-de-c/ave-extema restriccin-de-unicidad resrriccin-de.comprobacin
I ,
..
:
,
INITIALLY IMMEDIATE
..
INITIALLY DEFERRED
Definir la tabla
CREATE TABLE (NUM_PEDIDO FECHA_PEDIDO CLIENTE REP FAS PRODUCTO CANTIDAD IMPORTE
DEFE:RRABLE
L-
y sus columnas.
restriccin-de-cl3ve-primaria:
- - - PRlMARY KEY
( t nombre-~e-columnaT)
restriccin-de-clave-externa:
- - FOREIGN KEY (~ , mbre-de-columna T ) REFERENCES
de-rebla
nombre-
[ (- nombre-da-columna
c:=,
f JI
PEDIDOS INTEGER NOT NULL, DATE NOT NULL, INTEGER NOT NULL, INTEGER, CHAR(3) NOT NULL, CHAR{S) NOT NULL, INTEGER NOT NULL, MONEY NOT NULL)
MATCH - , - FULL
L
ON OELETE
PARTIAL ;r
----r
CASCAOE
ON
UPDATE
1 1
SET NULL
SET DEFAULT
NO ACTION CASCADE
SET NULL SET DEFAULT NO ACTION
restriccln-de-u nicidad:
La instruccin CREATE TABLE para una tabla dada puede variar ligeramente de un SGBD a otro, ya que cada SGBD alberga su propio conjunto de tipos de datos y emplea sus propias palabras claves para identificarlos en las definiciones de las columnas. Adems, el estndar SQL2 permile especificar un dominio en lugar de un tipo de datos dentro de la definicin de una columna. (Los dominios se describieron en el Captulo 11.) Un dominio es un conjunto concreto de valores de datos vlidos que se define dentro de"la base de datos y al que se le asigna un nombre. La definicin de dominio se basa en uno de los tipos de datos soportados por el SGBD, pero lleva a cabo comprobaciones adicionales del valor de los datos que restringen los valores legales. Por ejemplo, si esta definicin de dominio apareciera en una base de datos bajo el estndar SQL2:
CREATE DOMAIN ID_OFICINA_VALIDA INTEGER CHECK (VALUE BETWEEN 11 ANO 99)
- - - UNIQUE
---e T
nombre-de,-columnaT}----...
entonces la definicin de la tabla OFICINAS podra modificarse para que fuera:

restriccin-de-comprobaci6n:
- - CHECK
(condicin-de-bUsqueda)
...
Definir la tabla OFICINAS y sus columnas.

CREATE TABLE OFICINAS (OFF ICE ID_OFICINA_VALIDA NOT NULL, CIUDAD VARCHAR(15) NOT NULL,
Figura 13.1. "Diagrama sintctico bsico de CREATE TABLE.
362

REGlON VARCHAR{lO) NOT NULL,
JEF INTEGER, OBJETIVO MONEY.
363
Definicin de clave primaria y de clave externa
VENTAS MONEY NOT NULL)
y el SGBD comprobara de manera automtica cualquier fila ,recin insertada 'p~a asegurarse de que su nmero de oficina se hall~ en el ran~o deslgna~o ..Los dommlOs resultan especialmente efectivos cuando se aplican las mIsmas restriCCIOneS de valores vlidos a muchas columnas diferentes de la base de datos. En la base de datos de ejemplo, los nmeros de oficina aparecen en la~ ~abl~s OFICINAS, y REPRESENTANTES, Y el dominio ID_OFICINA_VALIDA se utllizana para defimr las ~olumnas de estas dos tablas. En las bases de datos del mundo real puede haber docenas o centenares de columnas de este tipo cuyos datos se extraen del mismo dominio.
Valores ausentes y valores predeterminados
Adems de definir las columnas de cada tabla, la instruccin CREATE TABLE idenli. fica la clave primaria y las relaciones de la tabla con otras tablas de la base de datos. Las clusulas PRlMARY KEY Y FOREIGN KEY tratan estas funciones. SQL de IBM admite estas clusulas desde hace algn tiempo y se han aadido a la especificacin ANSI/ISO. La mayor parte de los principales productos de SQL las admiten. La clusula PRIMARY KEY especifica las columnas que forman la clave prima ria de la tabla. Recurdese del Captulo 4 que esta columna (o combinacin de columnas) sirve de identificador nico de cada fila de la tabla. El SGBD exige de manera automtica que el valor de la clave primaria sea nico en cada fila de la tabla. Adems, la definicin. de las columnas de cada columna de la clave primaria debe especificar que la columna es NOT NULL. La clusula FOREIGN KEY especifica una clave externa de la tabla y la relacin que crea con otra tabla de la base de datos (la tabla padre). La clusula especifica: Las columnas que forman la clave externa, ladas las cuales son columnas de la tabla que se est creando. La tabla a la que la clave externa hace referencia. Se trala de la tabla padre de la relaci6n; la tabla que se est definiendo es la tabla hija. Un nombre opcional para la relacin. El nombre no se utiliza en las instrucciones de manipulacin de datos de SQL, pero puede aparecer en mensajes de error y es necesario si se desea poder eliminar la clave externa ms adelante. El modo en que el SGBD debe tratar los valores NULL en una o ms columnas de la clave externa al compararla con las filas de la tabla padre. Una regla opcional de eliminacin de la relacin (CASCADE, SET NULL, SET DEFAULT o NO ACTION, como se describe en el Captulo 11), que determina la accin que hay que emprender cuando se elimina una fila padre. Una regla opcional de actualizaci6n de la relacin como se describe en el Captulo 11, que determina la acci6n que hay que emprender cuando se actualiza parte de la clave principal de una fila padre. Una restricci6n opcional de comprobacin, que restringe los datos de la tabla de modo que sus filas cumplan una condici6n de bsqueda especificada. A continuaci6n se ofrece un instrucci6n CREATE TABLE expandida para la tabla PEDIDOS. que incluye una definicin de su clave primaria y de las tres claves externas que contiene:
La definicin de cada columna dentro de la tabla indica al SGBD si se permite que los datos de la columna estn ausentes; es decir, si se permite que la columna tenga un valor NULL. En la mayor parte de las principales marcas de SGBD y en el estndar SQL, el valor predeterminado es permitir los daws ausentes en las columnas. Si la columna debe contener un valor legal de los datos en cada fila de la tabla, su definicin debe incluir la clusula NOT NULL. Los productos de SGBD de Sybase y SQL Server de Microsoft utilizan el convenio contrario, dando por supuesto que no se permiten los valores NULL a menos que la columna se declare de m~nera explcita como NULL, O el modo de autorizacin de valores NULL predetermmado se define para que permita de manera predeterminada valores NULL. El estndar SQL2 y muchos de los principales productos de SGBD de SQL admiten los valores predeterminados de las columnas. Si una columna tiene un valor predeterminado, se especifica en la definicin de la columna. Por ejemplo, a continuacin se ofrece una instruccin CREATE TABLE para la tabla OFICINAS que especifica los valores predeterminados:
Definir la tabla
CREATE TABLE (OFICINA CIUDAD REGION JEF OBJETIVO VENTAS
OFICINAS
con valores predeterminados (sintaxis ANSI/ISO).
OFICINAS INTEGER NOT NULL. VARCHAR(lSJ NOT NULL. VARCHAR(lOJ NOT NULL DEFAULT 'Este'. INTEGER DEFAULT 106. MONEY DEFAULT NULL. MONEY NOT NULL DEFAULT 0.00)
Con esta definicin de tabla slo hace falta especificar el nmero de oficina y la ciudad cuando se inserla una oficina nueva. El valor predeterminado de la regi6n es Este; el jefe de la oficina predeterminado es Samuel Clavel (empleado nmero 106); el valor predeterminado de las ventas es cero, y el valor predeterminado del objetivo es NULL. Obsrvese que el valor predeterminado del objetivo sera NULL aunque no existiera la especificacin DEFAULT NULL.
Definir la tabla
PEDIDOS
con su clave primaria y sus claves externas.
CREATE TABLE PEDIDOS (NUM_PEDIDO INTEGER NOT NULL, FECHA_PEDIDO DATE NOT NULL,
364

CLIENTE INTEGER NOT NULL.
REP INTEGER, FAB CHAR(31 NOT NULL. PRODUCTO CHAR(5) NOT NULL.
'-
365
Tabla CLIENTES
NOM_CLIENTE FORMULADO
CANTIDAD IMPORTE PRlMARY KEY CONSTRAINT FOREIGN KEY REFERENCES ON DELETE CONSTRAINT FOREIGN KEY REFERENCES ON DELETE CQNSTRAINT FOREIGN KEY
INTEGER NOT NULL, MDNEY NOT NULL. (NUM_PEDIDO). FORMULADO (CLIENTE) CLIENTES CASCADE, TRAMITADO (REP) REPRESENTANTES SET NULL, DE (FAB, PRODUCTO)
I EMPRESA
1 21 ,03
ACME
NUM EMPL TRAMITADO
lOS
NOMBRE Bruno Arteaga
REFERENCES PRODUCTOS ON DELETE RESTRICT)
Tabla PRODUCTOS
ID_FAB ACI
\
La Figura 13.2 muestra las tres relaciones creadas por esta instruccin y los nombres que les asigna. En general, conviene asignar un nombre de relacin, ya que ayuda a clarificar la relacin creada por la clave externa. Por ejemplo, cada pedido lo formul el cliente cuyo nmero aparece en la columna CLIENTE de la tabla PEDIDOS. La relacin creada por esta columna ha recibido el nombre de FORMULADO. Cuando el SGBD procesa la instruccin CREATE TABLE, contrasta cada defi nicin de clave externa con la definicin de la labIa a la que hace referencia. El SOBD se asegura de que la clave externa y la clave primaria de la tabla a la que se hace referencia coincidan en el nmero de columnas que contienen y en sus tipos de datos. La tabla a la que se hace referencia debe estar ya definida en la base de datos para que esta comprobacin tenga xito. Obsrvese que la clusula FOREIGN KEY tambin especifica las reglas de elimi nacin y actualizacin que hay que hacer cumplir para la relacin entre tabla padre y tabla hija que crea. Las reglas de eliminacin y de actualizacin, y las acciones que pueden desencadenarlas, se describen en el Captulo 11. El SGBD hace que se cumplan las reglas predeterminadas (NO ACTION) si no se especifica ninguna regla de manera explcita. Si se desea crear dos o ms tablas en un ciclo referencial (como las tablas OFICINAS y REPRESENTANTES de la base de datos de ejemplo), no se puede incluir la definicin de clave externa en la primera instruccin CREATE TABLE, por. que la tabla referenciada no existe an. El SGBD rechazar la instruccin CREATE TABLE con un error diciendo que la definicin de tabla se refiere a una tabla no definida. En su lugar, se debe crear la primera tabla sin la definicin de clave externa y aadir la clave externa ms tarde usando la instruccin ALTER TABLE. (El estndar SQL2 y varios de los principales productos SGBD ofrecen una solucin diferente a este problema con la instruccin CREATE SCHEMA, que crea un conjunto completo de tablas de una vez, Esta instruccin y los otros objetos de la base de datos que se incluyen dentro de un esquema SQL2 se describen ms tarde en la seccin Esquemas SQL2.)
ID_PRODUCTO 41004
J
DESCRIPCION Serie 4, cable
--
lbla PEDIDOS
HUM PEDIDO
112963
I
2103
I~
FAB
~
'Cl
FECHA...PEDIDO CLIENTE RE' 17-DIC-89

lOS
PRODUCTO
41004
CANTIDAD
28
IMPORTE
3.276.00
-Figura 13.2.
Nombres de las relaciones de la instruccin CREATE TABLE.
Restricciones de unicidad
El estndar SQL2 especifica que las restricciones de unicidad tambin se definen en la instruccin CREATE TABLE mediante la clusula UNIQUE, que puede verse en la Figura 13.1. A continuacin se ofrece una instruccin CREATE TABLE para la tabla OFICINAS, modificada para exigir valores nicos de CIUDAD:
Definir la tabla OFICINAS con una restriccin de unicidad.
CREATE TABLE (OFICINA CIUDAD REGION JEF OFICINAS INTEGER NOT NULL, VARCHAR(15) NOT NULL, VARCHAR(lO) NOT NULL, INTEGER,
_1
I 1,
366

OBJETIVO MONEY,
Captulo 1;J: Creacin de bases de datos

OBJETIVO VENTAS PRIMARY KEY CONSTRAINT FOREIGN KEY REFERENCES ON DELETE CHECK MONEY, MaNEY NOT NULL, (OFICINA), JEFEVENTAS (JEF) REPRESENTANTES SET NULL, (OBJETIVO >= 0.00))
367
VENTAS MONEY NOT NULL,

PRIMARY KEY (OFICINA),
CONSTRAINT FOREIGN KEY REFERENCES ON DELETE UNIQUE
JEFEVENTAS (JEF) REPRESENTANTES SET NULL. (CIUDAD))
Si la clave primaria, la clave externa, la restriccin de unicidad o la restriccin de comprobacin afecta a una sola columna, el estndar ANSI/lSO permite una forma abreviada de la definicin. Sencillameme, se aade la clave primaria, la clave externa, la restriccin de unicidad o la restriccin de comprobacin al final de la definicin de la columna, como se puede ver en este ejemplo:
Definir la tabla
CREATE TABLE (OFICINA CIUDAD REGION JEF INTEGER OBJETIVO VENTAS
OFICINAS con
una restriccin de unicidad (sintaxis ANSI/ISOJ.
Se puede especificar de manera opcional un nombre para la restriccin de comprobacin, que ser utilizada por el SGBD cuando comunique .un error si se viola la restriccin. A continuacin puede verse una restriccin de comprobacin ligeramente ms compleja para que la tabla REPRESENTANTES haga que se cumpla la regla A los representantes cuya fecha de contratacin sea posterior al 1 de enero de 1988 no se les asignarn cuotas superiores a 300.000 En. La instruccin CREATE TABLE denomina a esta restriccin TOPE_CUOTA:
CREATE TABLE REPRESENTANTES (NUM_EMPL INTEGER NOT NULL, NOMBRE VARCHAR (15) NOT NULL.
OFICINAS INTEGER NQT NULL PRlMARY KEY, VARCHAR(lS) NOT NULL UNIQUE, VARCHAR(lO) NOT NULL, REFERENCES REPRESENTANTES, MONEY, MONEY NOT NULL)
Varias de las principales marcas de SGBD, incluidas SQL Server, Informix, Sybase y DB2, admiten esta forma abreviada.
Restricciones de comprobacin
CONSTRAINT FOREIGN KEY REFERENCES ON DELETE CONSTRAINT
TRABAJAEN (OFICINA_REP) OFICINAS SET NULL TOPE_CUOTA CHECK
((FECHA_CONTRATO < "Ol-JAN-SS") OR (CUOTA <= 300000)))
Otra caracterstica de integridad de datos de SQL2, la restriccin de comprobacin (que se describe en el Captulo 11), tambin se especifica en la instruccin CREATE TABLE. Las restricciones de comprobacin especifican una condicin de comprobacin (idntica en su forma a las condiciones de bsqueda de las consultas de SQL) que se efecta cada vez que se realiza un intento de modificacin del contenido de la tabla (con una instruccin INSERT, UPDATE o DELETE). Si la condicin de comprobacin sigue siendo TRUE tras la modificacin, se autoriza; en caso contrario, el SGBD frustra el intento de modificar los datos y devuelve un cdigo de error. A continuacin puede verse una instruccin CREATE TABLE para la tabla OFICINAS, con una condicin de comprobacin sencilla para asegurarse de que el OBJETIVO para la oficina sea mayor de 0,00 .
Definir la tabla
CREATE TABLE (OFICINA CIUDAD REGlaN JEF
OFICINAS
Esta posibilidad de las restricciones de comprobacin la admiten muchas de las principales marcas de SGBD.
Definicin del almacenamiento fsico
La instruccin CREATE TABLE suele incluir una o varias clusulas opcionales que
con una restriccin de unicidad.
OFICINAS INTEGER NOT NULL, VARCHAR(15) NaT NULL, VARCHAR(lO) NOT NULL, INTEGER,
especifican las caractersticas del almacenamiento fsico de la tabla. Generalmente, estas clusulas slo las utiliza el administrador de la base de datos para optimizar el rendimiento de las bases de datos de produccin. Por su propia naturaleza, estas clusulas son muy especficas de cada SGBD en concreto. Aunque resultan de poco inters prctico para la mayor parte de los usuarios de SQL, las diferentes estructuras de almacenamiento fsico ofrecidas por los diferentes SGBD ilustran las diferentes aplicaciones para las que estn diseados y sus niveles de sofisticacin. La mayor parte de las bases de datos de las computadoras personales ofrecen mecanismos de almacenamiento fsico muy sencillos. Muchos productos de bases de datos para computadoras personales almacenan toda la base de datos en un solo archivo de Windows, o utilizan un archivo de Windows diferente para cada tabla de la base de datos. Puede que tambin necesiten que toda la tabla o toda la base de datos se almacenen en un solo volumen de disco fsico. Las bases
368
-----
369
de datos multiusuario suelen ofrecer esquemas de almacenamiento fsico ms sofisticados para admitir el rendimiento mejorado de la base de datos. Por ejemplo, logres permite que el administrador de la base de datos defina vari-as ubica~ ciones con nombre, que son directorios fsicos en los que pueden almacenarse los datos de la base de dalOs. Las ubicaciones pueden repartirse entre varios volmenes de disco para aprovechar las operaciones paralelas de entrada y salida de disco. Se pueden especificar de manera opcional una o varias ubicaciones para cada tabla en la instruccin de logres CREATE TABLE:
CREATE TABLE OFICINAS (definicin-de-tabla) WITH LOCATIQN ~ {AREA1, AREA2, AREA3)
ello es que estas instrucciones incluyen especificaciones dependientes del sistema operativo de nombres de archivos y de directorios, que varan de un sistema operativo admitido por DB2 a otro. Otras clusulas especifican el grupo de bfer que hay que usar, la sobrecarga y la tasa de transferencia del medio de almacenamiento y otras caractersticas ntimamente relacionadas con el medio de almacenamiento fsico. DB2 utiliza esta informacin en sus algoritmos de optimizacin del rendimiento.
Eliminacin de una tabla (DROP TABLE)

A lo largo del tiempo la estructura de las bases de datos crece y se modifica. Se crean nuevas tablas para que representen entidades nuevas, y algunas tablas viejas dejan de ser necesarias. Se puede eliminar de la base de datos una tabla no necesaria con la instruccin DROP TABLE, que puede verse en la Figura 13.3. El nombre de tabla de la instruccin identifica la tabla de la que se va a prescindir. Normalmente se prescinde de una tabla propia y se utiliza un nombre de tabla no calificado. Con los permisos adecuados, se puede prescin~ir tambin de tablas posedas por otros usuarios especificando un nombre de tabla calificado. A continuacin se ofrecen unos ejemplos de la instruccin DROP TABLE:
La tabla CLIENTES ha sido sustituida por dos tablas nuevas, INFO_CLIENTE e
INFO_CUENTA, )'
Al especificar varias ubicaciones, se puede dividir el contenido de cada tabla entre varios volmenes de disco para un mayor acceso paralelo a la tabla. Sybase ofrece un enfoque parecido, que permite al administrador de la base de dalos especificar varios dispositivos lgicos de La base de datos con nombre que se utilizan para almacenar los datos. La correspondencia entre los dispositivos lgicos de Sybase y los discos fsicos reales del sistema informtico la maneja un programa de utilidad de Sybase, y no el lenguaje SQL. La instruccin de Sybase CREATE DATABASE puede especificar que se almacene la base de datos en uno o varios dispositivos de la base de datos:
CREATE DATABASE DATOSOP ON ARCHIVOBDl, ARCHIVOBD2, ARCHIVOBD3
ya no es necesaria.
Dentro de cada dispositivo de la base de datos, Sybase permite que el adminis~ trador de la base de datos defina segmentos lgicos, utilizando uno de los procedimientos almacenados proporcionados por el sistema de Sybase. Finalmente, la instruccin de Sybase CREATE TABLE puede especificar el segmento en que hay que almacenar los datos de cada tabla:
CREATE TABLE OFICINAS ON SEGMENT SEGIA
(definicin-de-tabla)
DROP TABLE CLIENTES
Samuel concede permiso para prescindir de su tabla, denominada

DROP TABLE SAMUEL.CUMPLEA&OS
CUMPLEAOS.
DB2 ofrece un esquema general parecido para la administracin del almacena~ miento fsico, basado en los conceptos de espacios de tablas y de grupos nodales. Los espacios de tablas son contenedores de almacenamiento de nivel lgico, mientras que los grupos nodales se definen ms especficamente en trminos de almacenamiento fsico. Cuando se crea una tabla de DB2 se puede asignar, de manera opcional, a un espacio de tablas concreto:
CREATE TABLE OFICINAS (definici6n-de-tabla) IN ADMINDB.OPSPACE
Cuando la instruccin DROP TABLE elimina una tabla de la base de datos, se pierden su definicin y todo su contenido. No hay manera de recuperar los datos, y habra que utilizar una nueva instruccin CREATE TABLE para volver a crear la definicin de la tabla. Debido a sus graves consecuencias se debe utilizar la instruccin DROP TABLE con cuidado. El estndar SQL2 exige que la instruccin DROP TABLE incluya CASCADE o RESTRICT, que especifican el efecto de la eliminacin de una tabla en los dems
r
Figura 13.3.
DROP TABLE nombre-de-tabfa
r===r"
CASCADE RESTRICT
A diferencia de Sybase, DB2 pone la mayor parte de la administracin de estas entidades de almacenamiento en manos del propio lenguaje SQL, mediante las instrucciones CREATE TABLESPACE y CREATE NODEGROUP. Una consecuencia de
Diagrama sintctico de la instruccin DROP TABLE.
370
371
objetos de la base de datos (como las vistas, que se describen en el Captulo ]4) que dependen de esa labia. Si se especifica CASCADE. la instruccin DROP TABLE falla si otros objetos de la base de datos hacen referencia a la tabla. La mayor parte de los produclOs comerciales de SGBD aceptan la instruccin DROP TABLE sin especificar ninguna opcin.
~ ALTER TABLE nombre-de-tabla
ADD
definicin-de-co/umna ------~.
ALTER nombre-de-
columna
DROP
1 DROP
SET DEFAULT valor

DEFAULT
Cambio de la definicin de una tabla (ALTER TABLE)

AnD
Una vez que una tabla ha estado en uso durante algn tiempo; los usuarios suelen descubrir que desean almacenar informacin adicional sobre las entidades representadas en la tabla. As, en la base de datos de ejemplo, puede que se desee: Aadir el nombre y el nmero de telfono de una persona principal de contacto a cada fila de la tabla CLIENTES, a medida que se comienza a utilizar para establecer contacto con los clientes. Aadir una columna de nivel mnimo de inventario a la tabla PRODUCTOS, de modo que la base de datos pueda alertar de manera automtica cuando las existencias de un producto determinado sean bajas. Hacer de la columna REGION de la tabla OFICINAS una clave externa para la tabla REGIONES recin creada. cuya clave principal es el nombre de la regin. Prescindir de la definicin de clave externa que vincula la columna CLIENTE de la tabla PEDIDOS con la tabla CLIENTES, sustituyndola por dos definiciones de clave externa que vinculen la columna CLIENTE a las tablas INFO_CLIENTE e INFO_CUENTA recin creadas. Cada uno de estos cambios, y algunos otros, pueden llevarse a cabo con la instruccin ALTER TABLE, que puede verse en la Figura 13.4. Al igual que con la instruccin DROP TABLE, normalmente se utilizar la instruccin ALTER TABLE con una tabla propia. Con los permisos adecuados, no obstante, se puede especificar un nombre calificado de tabla y alterar la definici6n de una tabla de otro usuario. Como puede verse en la figura, la instruccin ALTER TABLE puede: Aadir la definicin de una columna a la tabla. Eliminar una columna de la tabla. Modificar el valor predeterminado de una columna. Aadir o eliminar la clave primaria de la tabla. Aadir o eliminar una clave externa de la tabla. Aadir o eliminar una restriccin de unicidad de la tabla. Aadir o eliminar una restriccin de comprobacin de la tabla.
nombre-decolumna
1 CASCADE RE5TRICT
--===ri
definicin-de-clave-primaria ~ definicin-de-clave-externa restriccin-de-unicidad restriccin-de-comprobacin
DROP CONSTRAINT
nombre.cfe- [CASCADE columna RESTRICT
Figura 13.4. Diagrama sintctico de la instruccin
ALTER TABLE.
tringe cada instruccin ALTER TABLE a una nica modificacin de la tabla. Aadir una columna y definir una nueva clave externa, por ejemplo, exige dos instrucciones ALTER TABLE diferentes. Varias marcas de SGBD relajan esta restriccin y permiten varias clusulas de acci6n en cada instruccin ALTER TABLE.
Adicin de columnas
El empleo ms frecuente de la instruccin ALTER TABLE es la adicin de una columna a una tabla ya existente. La clusula de definicin de columnas de la instruccin ALTER TABLE es exactamente igual que la de la instruccin CREATE TABLE, y funciona de la misma manera. La nueva columna se aade al final de las definiciones de columnas de la tabla, y aparece como la columna del extremo derecho de las posteriores consultas. El SGBD suele dar por supuesto un valor NULL para las columnas recin aadidas en todas las filas ya existentes de la tabl~. Si la columna se declara NOT NULL con un valor predetenninado, el SGBD da por supuesto, en su lugar, el valor predeterminado. Obsrvese que no se puede declarar simplemente la nueva columna como NOT NULL, ya que el SGBD dar por supuestos valores NULL para la columna en las filas ya existentes, lo que violara la restriccin de manera inmediata. (Cuando se aade una columna nueva el SGBD, no recorre realmente todas las filas de la tabla ya existentes aadiendo el valor NULL o el valor predeterminado. En vez de eso, detecta el hecho de que una fila ya existente es demasiado corta para la nueva definici6n de la tabla cuando se recupera la fila, y la ampla con el valor NULL o con el valor predeterminado antes de mostrarla o pasarla al programa del usuario.) He aqu algunas instrucciones ALTER TABLE de ejemplo que aaden columnas nuevas a las tablas:
Las clusulas de la Figura 13.4 se especifican en el estndar SQL. Muchas marcas de SGBD. no admiten algunas de estas clusulas u ofrecen clusulas exclusivas de cada SGBD. que alteran otras caractersticas de la tabla. El estndar SQL2 res-
372
373
Aadir un nombre y un nmero de telfollo de contacto a la tabla CLIENTES.

ALTER ADD ALTER ADD TABLE CLIENTES NOMBRE_CONTACTO VARCHAR{30 TABLE CLIENTES TELEFONO_CONTACTO CHAR(lOJ
PRODUCTOS.
Aadir una columna de nivel de inventario mnimo a la tabla

ALTER TABLE PRODUCTOS ADD CANTIDAD_MINlMA INTEGER NOT NULL WITH DEFAULT
que sea la clave primaria de alguna relacin, las columnas de la clave externa que hagan referencia a la columna eliminada dejan de ser vlidas. Un problema parecido puede surgir si se elimina una columna a la que se hace referencia en una res~ (ficcin de comprobacin: la columna que ofrece el valor de los datos para la comprobacin de la restriccin ha desaparecido. Se crea un problema parecido en las vistas que se definen con base en la columna eliminada. El estndar SQL2 trala estos problemas del mismo modo que trala los pro-
En el primer ejemplo, las columnas nuevas tienen el valor NULL para los clientes ya existentes. En el segundo ejemplo, la columna CANTIDAD_MINIMA tendr el valor cero (O) para los productos ya existentes, lo que resulta adecuado. Cuando la instruccin ALTER TABLE apareci por primera vez en las implementaciones de SQL, las nicas estructuras importantes dentro de las tablas eran las definiciones de las columnas, y quedaba muy claro lo que significaba la clu. sula ADD. Desde entonces, las tablas han crecido para incluir definiciones de cia. ves primarias y externas y restricciones, y las clusulas ADD para estos tipos de objetos especifican el tipo de objeto que se est aadiendo. Por consistencia; con estas otras clusulas ADD/DROP, el estndar SQL2 incluye la palabra clave opcio. nal COLUMN tras la palabra clave ADD. Con este aadido, el ejemplo anterior se convierte en:
Aiiadir una colulJlna de nivel de inventario mnimo a la tabla
PRODUCTS.
blemas potenciales de integridad de los datos planteados por las instrucciones y UPDATE: con una regla de eliminacin (llamada realmente comportamiento de eliminacin en el estndar) que opera igual que las reglas de eliminacin y de actualizaci6n. Se puede especificar una de estas dos reglas de eliminacin:
DELETE
RESTRICT.
Si algn otro objeto de la base de datos (clave externa, restricci6n, etc.) depende de la columna que se va a eliminar, la instruccin ALTER TABLE falla con un mensaje de error y la columna no se elimina. CASCADE. Cualquier otro objeto de la base de datos (clave externa, restricci6n, etc.) que dependa de la columna se elimina tambin como efecto de cascada de la instruccin ALTER TABLE.
El efecto CASCADE puede generar modificaciones de la base de datos muy espectaculares; por tanto, se debe utilizar con precaucin. Suele ser mejor idea utilizar el modo RESTRICT (eliminar de manera explcita las claves externas y las restricciones dependientes, empleando las instrucciones ALTER o DROP correspondientes) antes de eliminar la columna.
Modificacin de las claves primarias y externas
ALTER TABLE PRODUCTOS ADD COLUMN CANTIDAD_HINlMA INTEGER NOT NULL WITH DEFAULT O
Eliminacin de columnas
La instruccin ALTER TABLE puede utilizarse para eliminar una o varias columnas de una tabla ya existente cuando ya no se necesitan. A continuacin se ofrece un ejemplo que elimina la columna FECHA_CONTRATO de la tabla REPRESENTANTES:
Eliminar una columna de la tabla

ALTER TABLE REPRESENTANTES DROP FECHA_CONTRATO
REPRESENTANTES.
El estndar de SQL2 obliga a formular otra instruccin ALTER TABLE diferente si se desean eliminar varias columnas, pero varias de las principales marcas de SGBD permiten eliminar varias columnas con una sola instruccin. Obsrvese que la eliminacin de columnas plantea el mismo tipo de problemas de integridad d~ los datos que se describieron en el Captulo 11 para las operacio. nes de actualizacin de las bases de datos. Por ejemplo, si se elimina una columna
El otro empleo comn de la instruccin ALTER TABLE es modificar o aadir definiciones de claves primarias o externas a las tablas. Dado que el soporte de las claves primarias y externas se proporciona en las nuevas versiones de varios sistemas de bases de daros basados en SQL, esta modalidad de la instruccin ALTER TABLE resulta especialmente tiL Puede utilizarse para informar al SGBD sobre las rela ciones entre tablas que ya existen en la base de datos, pero que no se han especificado de manera explcita anteriormente. A diferencia de las definiciones de las columnas, las definiciones de claves primarias y externas pueden aadirse y eliminarse de las tablas con la instrucci6n ALTER TABLE. Las clusulas que aaden las definiciones de las claves primarias y externas son exactamente las mismas que las de la instrucci6n CREATE TABLE, y funcionan de la misma manera. Las clusulas que eliminan las claves primarias o externas son directas, como puede verse en los ejemplos siguientes. Obsrvese que s610 se puede eliminar una clave externa si se asign originalmente un nombre a la relaci6n que crea. Si la relaci6n careca de nombre, no hay manera de especificarla en la instrucci6n ALTER TABLE. En ese caso, no se puede eliminar la clave externa a menos que se elimine y se vuelva a crear la tabla, mediante el procedimiento descrito para eliminar columnas.
374
375
A continuacin se ofrece un ejemplo que aade una definicin de clave externa
Asertos
Los asertos son restricciones de la base de datos que limitan el contenido de la base de datos en su conjunto. Al igual que las restricciones de comprobacin, los asertos se especifican como condiciones de bsqueda. Pero, a diferencia de las restricciones de comprobacin, la condicin de bsqueda de los asertos pueden limitar el contenido de varias tablas y las relaciones de datos entre ellas. Por ese motivo, los asertos se especifican como parte de la definicin global de la base de datos, mediante la instruccin CREATE ASSERTION de SQL2. Supngase que se desea restringir el contenido de la base de datos de modo que los pedidos totales de cualquier cliente no puedan superar el lmite de crdito de ese cliente. Se puede implementar esa restriccin con la instruccin:
CREATE ASSERTION LIMITECRED CHECK ((CLIENTES.NUM_CLI ~ PEDIDOS.CLIENTE) AND (SUM (IMPORTE) <~ LIMITE_CREDITO))
a una tabla ya existente:

Hacer de la columna REGION de la tabla OFICINA una clave externa de la tabla REGIONES recin creada, cuya clave primaria es el nombre de la regin.
ALTER TABLE OFICINAS
ADD CQNSTRAINT FOREIGN KEY REFERENCES ENREGION (REGlON) REGIONES
A continuacin se ofrece un ejemplo de una instruccin ALTER TABLE que modifica una clave primaria. Obsrvese que la clave externa correspondiente a la clave primaria original debe eliminarse debido a que ya no es una clave externa de la tabla modificada:
Modificar la clave primaria de la tabla OFICINAS.
ALTER TABLE REPRESENTANTES
DROP CONSTRAINT TRABAJAEN FOREIGN KEY (OFICINA_REP) REFERENCES OFICINAS ALTER TABLE OFICINAS DROP PRIMARY KEY
Con el aserto denominado LIMITECRED como parte de la definicin de la base de datos, se exige que el SGBD compruebe que el aserto sigue siendo cierto cada vez que una instruccin de SQL intente modificar las tablas CLIENTES o PEDIDOS. Si, posteriormente, se determina que ya no se necesita el aserto, se puede eliminar empleando la instruccin DROP ASSERTION:
DROP ASSERTION LIMITECRED
(CIUDAD)
Definicin de restricciones
Las tablas de las bases de datos definen su estructura bsica, y en los primitivos productos comerciales de SQL, las definiciones de las tablas eran la nica especificacin de la estructura de las bases de datos. Con el advenimiento del soporte de las claves primarias y externas en DB2 y en el estndar SQL2, la definicin de la estructura de las bases de datos se ampli para incluir las relaciones entre las tablas de cada base de datos. Ms recientemente, mediante el estndar SQL2 y la evolucin de los productos comerciales, la definicin de la estructura de la base de datos se ha ampliado para incluir una nueva rea: las restricciones de las bases de datos que limitan los datos que pueden introducirse en la base de datos. Los tipos de restricciones y el papel que desempean en el mantenimiento de la integridad de la base de datos se describen en el Captulo lI. Hay cuatro tipos de restricciones de las bases de datos (restricciones de unicidad, restricciones de claves primarias y externas, y restricciones de comprobacin) estrechamente asociadas con una sola tabla de la base de datos. Se especifican como parte de la instruccin CREATE TABLE y pueden modificarse o eliminarse mediante la instruccin ALTER TABLE. Los otros dos tipos de restricciones de la integridad de la base de datos, asertos y dominios, se crean como objetos independientes dentro de cada base de datos, independientemente de cualquier definicin de una tabla concreta.
En SQL2 no hay ninguna instruccin ALTER ASSERTION. Para modificar la definicin de un aserto hay que descartar la definicin antigua y especificar una nueva con otra instruccin CREATE ASSERTION.
Dominios
El estndar SQL2 implementa el concepto formal de dominio como parte de la definicin de las bases de datos. Como se describe en el Captulo 11, un dominio es una coleccin con nombre de valores de datos que acta de hecho como otro tipo de datos, para su empleo en las definiciones de las bases de datos. Los dominios se crean con las instrucciones CREATE DOMAIN. Una vez creados, se puede hacer referencia a los dominios en las definiciones de columnas corno si fueran un tipo de datos. A continuacin se puede ver el empleo de una instruccin CREATE DOMAIN para la definicin de un dominio denominado IDS_EMPL_VALIDOS, que consiste en los nmeros de identificacin de empleado vlidos de la base de datos de ejemplo. Estos nmeros son enteros de tres cifras del rango 101 a 999, ambos incluidos:
CREATE DOMAIN IDS_EMPL_VALIDOS INTEGER CHECK {VALUE BETWEEN 101 AND 199}
376
377
Si se deja de necesitar un dominio, se puede eliminar empleando una de las modalidades de la instruccin DROP DOMAIN de SQL2:
OROP DOMAIN IDS_EMPL_VALIDOS CASCADE
Base de datos Tablas de Jorge

;'-
OROP DQMAIN IDS_EMPL_VALID RESTRICT
- -- "
\ I 11
Tablas de Samuel
/-
;'----------------- ' I ( PRODUCTOS

I I OFICINAS I I FFFf=Ff=I I I l' 1 REPRESENTANTES I 1 PEDIDOS CLIENTES
Tablas del ABD
Las reglas de eliminacin CASCADE y RESTRICT operan igual que para la eliminacin de columnas. Si se especifica CASCADE, cualquier columna definida en trminos del dominio eliminado se elimina a su vez de manera automtica. Si se especifica RESTRICT, el intento de eliminacin del dominio fallar si se basa en l alguna definicin de columna. Antes hay que eliminar o modificar las definiciones de las columnas de modo que ya no dependan del dominio antes de eliminarlo. Esto proporciona un margen de seguridad adicional contra la eliminacin accidental de columnas (y, sobre todo, de los datos que contienen).
:EEEI " ITJJ .J

1
11
LLLL.L...LJ
:D]
1 \
rn!![]JJ
I \
"
: []TI] WillU []JI: " ~11
FFffR11
1 I I I I I
'1
/
... _---------------_ ....
'
Alias y sinnimos
(CREATE/DROP ALIAS)
Figura 13,5.
Organizacin tpica de una base de datos de produccin.
Las bases de datos de produccin suelen organizarse como la copia de la base de datos de ejemplo que aparece en la Figura 13.5, con todas las tablas principales reunidas y de propiedad del administrador de la base de datos. El administrador de la base de datos concede permiso a otros usuarios para que tengan acceso a las tablas, empleando el esquema de seguridad de SQL que se describe en el Captulo 15. Recurdese, no obstante, que hay que utilizar nombres de tabla calificados para hacer referencia a las tablas de otros usuarios. En la prctica, esto significa que lodo consulta de las tablas principales de la Figura 13.5 debe utilizar nombres de tabla calificados, lo que hace que consultas como la siguiente sean largas y tediosas de escribir:
Crear sinnimos para dos tablas propiedad de otro usuario.

CREATE ALIAS REPRESENTANTES FOR OP_ADMIN.REPRESENTANTES CREATE ALIAS OFICINAS FOR OP_ADMIN.OFICINAS
Una vez definido un sinnimo o alias, se puede utilizar como si fuera un nombre de tabla en las consultas de SQL. La consulta anterior, por tanto, se transforma en:
SELECT NOMBRE, REPRESENTANTES.VENTAS, FROM REPRESENTANTES, OFICINAS OFICINA. OFICINAS.VENTAS
Hacer U1lQ lista del nombre, ventas, oficina y ventas de la oficina de todos los empleados.
SELECT NOMBRE, OP_ADMIN.REPRESENTANTES.VENTAS, OFICINA, OP_ADMIN.OFICINAS.VENTAS FROM OP_ADMIN.REPRESENTANTES, OP_ADMIN.OFICINAS
Para abordar este problema, muchos productos de SOBD de SQL ofrecen la posibilidad de utilizar un alias o sinnimo. Un sinnimo es un nombre que se define para sustituir el nombre de una tabla. En DB2 los alias se crean utilizando la instruccin CREATE ALIAS. (Las versiones ms antiguas de DB2 utilizaban en realidad la instruccin CREATE SYNONYM, y Gracle sigue utilizando esta modalidad de la instruccin, pero tiene el mismo efecto que la instruccin CREATE ALIAS.) Si se fuera el usuario. denominado Jorge, por ejemplo, de la Figura 13.5, se podra utilizar este par de instrucciones CREATE ALIAS:
El empleo de alias no modifica el significado de la consulta, y hay que seguir teniendo permiso para tener acceso a las tablas de otros usuarios. Sin embargo, los sinnimos simplifican las instrucciones de SQL que se utilizan y hacen que parezca que las tablas son propias. Si, ms adelante, se decide que ya no se desea utilizar los sinnimos, pueden eliminarse con la instruccin DROP ALIAS:
Eliminar los sinnimos creados a11leriormente.

DROP ALIAS REPRESENTANTES DROP ALIAS OFICINAS
378

O
379
DB2, Oracle e Inforrnix admiten los sinnimos dos en el estndar ANSI/ISO para SQL.
alias. No vienen especifica-
ndices
(CREATE/DROP INDEX)
Una de las estructuras de almacenamiento fsico que proporciona la mayor parte de los sistemas de gestin de bases de datos basados en SQL son los ndices, que son una estructura que ofrece un acceso rpido a las filas de las tablas con base en el v~lo~ de una o varias columnas. La Figura J 3.6 muestra la tabla PRODUCTOS y dos mdlces que se han creado para ella. Uno de Jos ndices ofrece acceso cn base en la clave primaria de la tabla, que es una combinacin de las columnas ID_FAB e
ID_PRODUCTO.
El SOBD utiliza el ndice igual que se podra utilizar el ndice de un libro. El ndice almacena valores de los datos, y punteros hacia las filas en las que se hallan esos valores. En el ndice, los valores de los datos se disponen en orden ascendente o descendente, de modo que el SOBD pueda examinarlo rpidamente al buscar un valor concreto. Luego puede seguir el puntero para localizar la fila que contiene ese valor. La presencia o ausencia de ndices es completamente transparente para el usuario de SQL que tiene acceso a la tabla. Por ejemplo, considrese esta instruccin
SELECT:
Buscar la cantidad y el precio de los cables de la serie cuatro.

SELECT STOCK, PRECIO FROM PRODUCTOS
WHERE DESCRIPTION
'Serie 4,
cable'
Tabla PRODUCTOS
ID FAB
ID PRODUCTO
DESCRIPCION
PRECIO
STOCK
r-;:: ..
lMM 'Cl 'Cl
779c
41003 41004
r=:
90-kg brazo
Serie 3, cable Serie 4, cable
1.875,OO
107,OO 117,OO
9 207
139
NDICE
NDICE
'Cl 41003 'Cl 41004
90-kg brazo
I
,
,
,
IMM 779C Serie 3. cable Serie 4, cable
I
,
.
Figura
13.6.
Dos
ndices para la tabla PRODUCTOS.
La instruccin no dice si hay un ndice de la columna DESCRIPCION, y el SGBD ejecuta la consulta en cualquier caso. Si no hubiera ndice de la columna DESCRIPCION, el SOBD se vera obligado a procesar la consulta explorando secuencialmente la tabla PRODUCTOS, fila por fila, examinando la columna DESCRIPCION de cada fila. Para asegurarse de que haba encontrado todas las filas que satisfacen la condicin de bsqueda, tendra que examinar todas las fijas de la tabla. En tablas de gran tamao, con millares o millones de filas, el examen de la tabla puede tardar minutos u horas. Con el ndice de la columna DESCRIPCION, el SOBD puede hallar los datos solicitados con mucho menos esfuerzo. Examina el ndice para hallar el valor solicitado (<<Serie 4, cable) y luego sigue el puntero para encontrar las filas de la tabla solicitadas. La bsqueda en el ndice es muy rpida porque el ndice est ordenado y sus filas son muy pequeas. El paso del ndice a las filas de la tabla es tambin muy rpido porque el ndice indica al SOBD la ubicacin de las filas en el disco. Como muestra este ejemplo, la ventaja de tener un ndice radica en que acelera enormemente la ejecucin de las instrucciones de SQL, con condiciones de bsqueda que hacen referencia a las columnas indexadas. Un inconveniente de tener un ndice es que consume espacio de disco adicional. Otro inconveniente es que hay que actualizar el ndice cada vez que se aade una fila a la tabla y cada vez que se actualiza la columna indexada de una fila ya existente. Esto supone una sobrecarga adicional a las instrucciones INSERT y UPDATE de la tabla. En general, resulta una buena idea crear un ndice de las columnas que se utilizan con frecuencia en las condiciones de bsqueda. La indexacin resulta tambin ms adecuada cuando las consultas a la tabla son ms frecuentes que las inserciones y las actualizaciones. La mayor parte de los productos de SGBD establecen siempre un ndice de la clave principal de cada tabla, ya que suponen que el acceso a la tabla se realizar con mayor frecuencia mediante la clave primaria. La mayor parte de los productos de SOBD establecen tambin de manera automtica un ndice de cada columna (o combinacin de columnas) definida con una restriccin de unicidad. El SGBD debe comprobar el valor de esas columnas en cada nueva fila que se inserte, o en cualquier actualizacin de una fila existente,
~
380
381
para cerciorarse de que su valor no duplica un valor ya contenido en la tabla. Sin un ndice de esas columnas, el SGBD tendra que examinar de manera secuencial cada fila de la tabla para comprobar la restriccin. Con un ndice, el SOBD puede usar sencillamente el ndice para hallar la fila (si es que existe) con el valor en cuestin, lo que supone una operacin mucho ms rpida que una bsqueda secuencial. En la base de datos de ejemplo estas columnas son buenas candidatas para ndices adicionales:
La columna EMPRESA de la tabla CLIENTES debera indexarse si se recuperan con frecuencia los daLOs de los clientes por el nombre de la empresa. La columna NOMBRE de la tabla REPRESENTANTES debe indexarse si los datos de los representantes se recuperan a menudo por el nombre del representante. La columna REP de la tabla PEDIDOS debe indexarse si los pedidos se recuperan con frecuencia segn el representante que los tramit. La columna CLIENTE de la tabla PEDIDOS debe indexarse de manera parecida si Jos pedidos se recuperan a menudo de acuerdo con el cliente que los formul. Las columnas FAB y PRODUCTO, conjuntamente, de la tabla PEDIDOS deben indexarse si los pedidos se recuperan con frecuencia segn el producto encargado.
f-- CREATE
L
UNIQUE
=-r
INDEX nomb,.-indice ON nomb,.-de-tab/a
nomb,.-de-co/vmna ~ )
~
Figura
13.7.
Diagrama
sintctico bsico de la instruccin
CREATE INDEX.
El estndar SQL2 no menciona los ndices ni la manera de crearlos. Trata los ndices de las bases de datos como un detalle de implementacin, que es ajeno al lenguaje SQL bsico y estandarizado. No obstante. el empleo de ndices resulta fundamental para conseguir un rendimiento adecuado en cualquier base de daws de clase empresarial de cieno tamao. En la prctica, la mayor parte de las marcas populares de SGBD (incluidas Gracle, Microsoft SQL Server, lnformix, Sybase y DB2) admiten los ndices mediante alguna modalidad de la instruccin CREATE INDEX, que puede verse en la Figura 13.7. La instruccin asigna un nombre al ndice y especifica la tabla para la que se ha creado. La instruccin tambin especifica las columnas que hay que indexar y si deben indexarse en orden ascendente o descendente. La versin de DB2 de la instruccin CREATE INDEX, que puede verse en la Figura 13.7, es la ms directa. Su nica opcin es la palabra clave UNIQUE, que se utiliza para especificar que la combinacin de columnas que se est indexando debe contener un valor nico para cada fila de la tabla. A continuacin se ofrece un ejemplo de una instruccin CREATE INDEX que crea un ndice de la tabla PEDIDOS con base en las columnas FAB y PRODUCTO, Y que exige que las combinaciones de columnas tengan un valor nico.
Crear un ndice de la tabla PEDIDOS.

CREATE UNIQUE INDEX IND_PROD_PED ON PEDIDOS (FAS, PRODUCTO)
En la mayor parte de los productos de SGBD la clusula CREATE INDEX incluye clusulas adicionales especficas del SGBD que detallan la ubicacin de disco del ndice y parmetros de ajuste del rendimiento. Los parmetros de rendimiento habituales incluyen el tamao de las pginas del ndice, el porcentaje de espacio libre que debe dejar el ndice para las filas nuevas, el tipo de ndice que hay que crear, si debe estar agrupado (una disposicin que ubica las filas de datos fsicas en el medio del disco en el mismo orden que el ndice), etc. Estas opciones hacen de la instruccin CREATE INDEX bastante dependiente del SOBD en su uso real. Algunos productos de SOBD incluyen dos o ms tipos diferentes de ndices, que estn optimizados para tipos diferentes de acceso a la base de datos. Por ejemplo, los ndices en rboles B utilizan una estructura de rbol de entradas de ndice y de bloques de ndice (grupos de entradas de ndice) para organizar los valores de los datos que contiene en orden ascendente o descendente. Este tipo de ndice ofrece una bsqueda eficiente de un solo valor o de un rango de valores, como la bsqueda exigida por el operador de comparacin de desigualdad o una operacin de comprobacin de rango (SETWEEN). Un tipo de ndice diferente, los ndices asociativos, utilizan una tcnica aleatoria para ubicar todos los valores posibles de los datos en un nmero moderado de cajones dentro del ndice. Por ejemplo, si hay diez millones de valores posibles de los datos, un ndice con quinientos cajones asociativos puede resultar adecuado. Como cada valor dado de los datos se ubica siempre en el mismo cajn, el SOBD puede hallar ese valor con slo ubicar el cajn correspondiente y buscar en l. Con quinientos cajones el nmero de elementos que hay que buscar se reduce. en promedio por un factor de quinientos. Esto hace que los ndices asociativos sean muy rpidos al buscar la coincidencia exacta con un valor de los datos. Pero la asignacin de los valores a los cajones no conserva el orden de los valores de los datos,
382
383
por lo que no se pueden utilizar los ndices asociativos para bsquedas de desigualdades ni de rangos. Otros tipos de ndices resultan adecuados para otras situaciones especficas de los SOBD. Por ejemplo, una variacin de los ndices de rboles B, conocida como ndices de rboles T. est optimizada para las bases de datos residentes en memoria. Los ndices de mapa de bits resultan tiles cuando hay un nmero de valores
de datos posibles relativamente pequeo. Cuando un SGBD incluye varios tipos de ndices, la instruccin CREATE INDEX no s6lo define y crea el ndice, sino que tambin define su tipo.
La Tabla 13.1 muestra el modo en que algunos de los productos ms populares de SQL utilizan los verbos CREATE, DROP y ALTER en su LDD ampliado. El estndar SQL2 adopta este mismo acuerdo para ocuparse de la creacin, destruccin y
modificacin de todos los objelos de las bases de dalos de SQL2.

Tabla 13.1.
Instrucciones LDD de los productos basados en SOL ms populares
Instrucciones LDD de SQL
Objeto gestionado
Si se crea un ndice para una tabla y ms adelante se decide que no es necesario, la instruccin DROP INDEX elimina el ndice de la base de dmos. Esta instruccin elimina el ndice creado en el ejemplo anterior:
Incluidas en casi todas las marcas

de SGBD
CREATE/DROP/ALTER TABLE CREATE/DROP/ALTER VIEW CREATE/DROP/ALTER INDEX
Tabla
Vista ndice Alias para una tabla o visla
Eliminar el ndice creado anteriormente.
Incluida:; en DB2
CREATE/DROP ALIAS
Gestin de otros objetos de la base de datos

Los verbos CREATE, DROP y ALTER forman la piedra angular del lenguaje de definicin de datos de SQL. Las instrucciones basadas en estos verbos se utilizan en todas las implementaciones de SQL para manipular tablas, ndices y vistas (que se describen en el Captulo 14). La mayor parte de los productos de SGBD populares basados en SQL utilizan tambin estos verbos para formar instrucciones LDD adicionales que crean, destruyen y modifican Otros objetos de la base de datos exclusivos de esa marca concreta de SGBD.
CREATE/DROP/ALTER BUFFERPOOL Conjunto de bferes de E/S utilizados por DB2 Tipo de datos distinto definido por el usuario CREATE/DROP DISTINCT TYPE CREATE/DROP FUNCTION CREATE/DROP/ALTER NODEGROUP DROP PACKAGE CREATE/DROP PROCEDURE CREATE/DROP SCHEMA Funcin definida por el usuario Grupo de particiones o nodos de la base de datos Mdulo de acceso a programas de DB2 Procedimiento almacenado de DB2 definido por el usuario Esquema de la base de datos
El SGBD de Sybase, por ejemplo, fue el primero en emplear disparadores y

procedimientos almacenados, que se tratan como objetos dentro de las bases de datos de SQL, junto con sus tablas, sus asertos, sus ndices y otras estructuras. Sybase aadi las instrucciones CREATE TRIGGER y CREATE PROCEDURE a su dialecto de SQL para definir estas nuevas estructuras de la base de datos, y las instrucciones DROP correspondientes para eliminarlas cuando ya no se necesiten. Cuando estas caracterslicas se popularizaron, otros productos de SGBD aadieron esa posibilidad, junto con sus propias variedades de las instrucciones CREATE TRIGGER y CREATE PROCEDURE. El acuerdo general de las marcas de SGBD es: a) el empleo de los verbos CREATElDROP/ALTER; b) la siguiente palabra de la instruccin es el tipo de objeto que se est gestionando, y e) la tercera palabra es el nombre del objeto, que debe obede~ cer a los acuerdos de denominaciones de SQL. Ms all de las tres primeras palabras las instrucciones se vuelven muy dependientes de cada SGBD y no siguen ningn estndar. Pese a todo, esta parte comn da una sensacin uniforme a los diferentes dialectos de SQL. Por lo menos, indica al usuario el lugar del manual de referencia en que debe buscar la descripcin de la nueva posibilidad. Si se encuentra un nuevo SGBD basado ~n SQL y se sabe que alberga un objeto conocido como BLOB, lo ms probable es que utilice las instrucciones CREATE BLOB, DROP BL08 Y ALTER 8L08.
CREATE/DROP/ALTER TABLESPACE Espacio de tablas (rea de almacenamiento para datos de DB2) CREATE/DROP TRIGGER Disparador de la base de datos Molde para la conversin de tipos de datos Base de datos de Informix con nombre Tipo de datos diferente deflOido por el usuario Funcin definida por el usuario Tipo de datos opaco definido por el usuario Mtodo de acceso al almacenamiento de disco definido por el usuario Procedimiento almacenado de Informix definido por el usuario
Incluidas en Infonnix
CREATE/DROP CAST CREATE/DROP DATABASE CREATE/DROP DISTINCT TYPE CREATE/DROP FUNCTION CREATE/DROP OPAQUE TYPE CREATE/DROP OPCLASS CREATE/DROP PROCEDURE
(comillla)
/
384
385
Tabla 13.1.
Instrucciones LDD de los productos basados en SOL ms populares (Continuacin)
Tabla 13.1.
Instrucciones LDD de los productos basados en SOL ms populares (Continuacin)

CREATE/DROP ROLE CREATE/OROP ROUTINE CREATE/DROP ROW TYPE CREATE SCHEMA CREATE/DROP SYNONYM CREATE/DROP TRIGGER
Objeto gestionado
Papel del usuario en la base de datos Procedimiento almacenado de lnforrnix definido por el usuario

CREATE SCHEMA
Objeto gestionado
Esquema de la base de datos
CREATE/DROP/ ALTER SQUENSE
Secuencia de valores definida por el usuario

Tabla de resultados de consultas slo para lectura
Sinnimo (alias) para una tabla o una vista
CREATE/DROP/ALTER SNAPSHOT
CREATE/DROP SYNONYM CREATE/DROP/ALTER TABLESPACE
Tipo de fila con nombre
(~xtensin
de objeto)
Esquema de la base de datos Sinnimo (alias) para una tabla o vista Disparador de la base de dalOS
Espacio de tablas (rea de almacenamiento para datos de Oracle) Disparador de la base de datos Tipo de datos abstfaClO definido por el usuario Mtodos para un tipo de datoS abstracto ID de usuario de aracle
Incluidas en Microsoft SQL Server

CREATE/ OROP / ALTER DATABASE CREATE!DROP DEFAULT CREATE/DROP/ALTER PROCEDURE CREATE/OROP RULE CREATE SCHEMA CREATE/DROP/ALTER TRIGGER
CREATE/ OROP / ALTER TRIGGER
Base de datos Valor predeterminado de la columna Procedimiento almacenado de SQL Server Regla de integridad de la columna Esquema de la base de datos Disparador almacenado
CREATE/DROP TYPE CREATE/DROP TYPE BODY CREATE/DROP/ALTER USER
Incluidas en Sybase
CREATE/OROP!ALTER DATABASE CREATE/DROP DEFAULT
Base de datos Valor predeterminado de la columna Copia local de una tabla remota ya existente Procedimiento almacenado de Sybase Papel del usuario en la base de datos Regla de integridad de la columna Esquema de la base de datos Disparador almacenado
Incluidas en Oracle
CREATE/DROP CLUSTER CREATE DATABASE CREATE/DROP DATABASE LINK CREATE/DROP DIRECTORY CREATE/DROP/ALTER FUNCTION CREATE/DROP LIBRARY CREATE/DROP/ALTER PACKAGE CREATE/DROP/ALTER PROCEDURE
Agrupacin de tablas para ajuste del rendimiento Base de datos de aracle con nombre Enlace de red para acceso remoto a las tablas Directorios del sistema operativo para almacenamiento de objetos de gran tamao Funcin definida por el usuario Funciones externas que pueden llamarse desde PUSQL Grupo de procedimientos de PUSQL que pueden compartirse Procedimiento almacenado de aracIe definido por el usuario Lmites del uso de recursos por la base de datos Papel del usuario en la base de datos rea de almacenamiento para la recuperacin de la base de datos
CREATE EXISTING TABLE CREATE/DROP PROCEDURE CREATE/DROP/ALTER ROLE CREATE/DROP RULE CREATE SCHEMA CREATE/DROP TRIGGER
Especificadas por el estndar

ANSI/ISO de SQL
CREATE/DROP ASSERTION
Restriccin de comprobacin para todo el esquema Conjunto de caracteres ampliado Secuencia de ordenamiento del conjunto de caracteres Especificacin de los valores vlidos de los datos Esquema de la base de datos Conversin entre conjuntos de caracteres
CREATE/DROP CHARACTER SET CREATE/DROP COLLATION
CREATE/DROP/ALTER PROFILE CREATE!OROP/ALTER ROLE CREATE/DROP/ALTER ROLLBACK SEGMENT
CREATE/DROP/ALTER DOMAIN CREATE/DROP SCHEMA CREATE/DROP TRANSLATION
(contina)
386
Captufo 13: Creacin de bases de datos
387
Estructura de la base de datos

El estndar SQL I especificaba una estructura sencilla para el contenido de la base de datos. que puede verse en la Figura 13.8. Cada usuario de la base de datos tiene un conjunLO de tablas, que son propiedad de ese usuario. Prcticamente todos los principales productos de SGBD incluyen este esquema, aunque algunos (especialmente los centrados en aplicaciones de finalidad especial o incrustadas, o en uso en computadoras personales) no admiten el concepto de propiedad de las tablas. En esos sistemas todas las tablas de la base de datos son parte de un gran conjunto. Aunque marcas diferenLes de sistemas de gestin basados en SQL ofrecen la misma estructura dentro de cada base de datos, hay una amplia variabilidad en el modo en que organizan y estructuran las diferentes bases de datos dentro de cada sistema informtico. Algunas marcas dan por supuesta una nica base de datos que abarca todo el sistema y almacena todos los datos de ese sistema. Otras marcas de SOBO admiten varias bases de datos en cada computadora, cada una de ellas identificada por un nombre. Otras marcas de SGBD, incluso, admiten varias bases de datos en el contexto del sistema de direcrorios de la computadora. Estas variaciones no afectan al modo en que se utiliza SQL para tener acceso a los datos de cada base de datos. Sin embargo, s que afectan al modo en que se organizan los datos; por ejemplo, si se mezclan en una sola base de datos el procesamiento de pedidos y los datos de contabilidad, o si se reparten en dos bases de datos. Tambin afectan al modo en que se obtiene acceso inicialmente a la base de datos; por ejemplo, si hay va~ias bases de datos, hay que indicar al SGBD la que se desea utilizar. Para ilustrar el modo en que las diferentes marcas de SGBD afrontan estos problemas, supngase que se ampla la base de datos de
ejemplo para albergar una aplicacin de nmina y una aplicaci6n de contabilidad, adems de las tareas de procesamiento de pedidos que ahora alberga.
Arquitectura de base de datos nica

La Figura 13.9 muestra la arquitectura de base de datos nica en la que el SOBD alberga una base de datos para todo el sistema. Las bases de datos de los grandes sistemas informticos y de las minicomputadoras (como la versin para grandes sis~ temas de DB2 y Gracle) han tendido hist6ricamente a utilizar este enfoque. Los datos del procesamiento de pedidos, de la contabilidad y de las nminas se almacenan en tablas de la base de datos. Las tablas principales de cada aplicaci6n se renen y son propiedad de un solo usuario, que probablemente sea la persona encargada de esa aplicacin en esa computadora. Una ventaja de esta arquitectura es que las tablas de las diferentes aplicaciones pueden hacer referencia con facilidad unas a otras. La tabla FICHAJES de la aplicaci6n de nminas, por ejemplo, puede contener una clave externa que haga referencia a la tabla OFICINAS, y las aplicaciones pueden utilizar esa relacin para calcular las comisiones. Con los permisos adecuados los usuarios pueden ejecutar consultas que combinen datos de las diferentes aplicaciones. Un inconveniente de esta arquitectura es que la base de datos se hace enorme con el transcurso del tiempo, ya que cada vez se le aaden ms aplicaciones. Son frecuentes las bases de datos de DB2 o de Oracle con varios centenares de tablas. Los problemas de la gestin de una base de datos de ese tamao -realizacin de copias de seguridad, recuperacin de datos, anlisis del rendimiento, etc.- suelen exigir un administrador de la base de datos a tiempo completo.
Base de datos Tablas de Jos

;"-
---,
\ I I I I
Tablas de Mara
/-
- - -,
f I
MASCOTAS
I I I I I I I
\
ELE!
PERSONAS
....
ITl -- -
I 1 I I
I
AMIGOS I 1 I I I MASCOTAS I I 1
ITIJ
CIIIJ
I I 1 I I I 1 11 I I 1 I I I I I 1
I
\
-------------- ....
OFICINAS
Tablas de Samuel
Base de datos nica del sistema

\
EEEEEE1
PEDIDOS
[I]],
....
_-------------
m
CUMPLE1illOS
m
PRODUCTOS
I I 1 I I I I 1 1 1 I
/
,---------,
I OFICINAS
Tablas de Jos
Tablas de Jorge Tablas de Mara ,---------, ,---------,

I
I
:
I~I I I
:::::::::::
[]]CUENrASI
I .
::
I I I I I I
I I I I J
mFICHAJES!
I
omPEDIDOS
I I I
: rnmBOLETIN
I I
mi
J
I PRODUCTOS 1 I I
LlJTISALARIOS:
,==
.. ,
1 I I I
: 1
: I
I
==-=_ . .
,--------_ ....
Figura 13.8. Organizacin de las bases de datos en SOLl.
Figura 13.9. Arquitectura de base de datos nica.
/
388
389
En la arquitectura de base de daros nica, la obtencin del acceso es muy sencilla: slo hay una base de datos, por lo que no hace falta realizar ninguna eleccin. Por ejemplo, la instruccin de SQL para programacin que conecta al usuario con una base de datos de Ofucle es
CONNECT, y
Jos usuarios tienden a hablar en
/ _ _ _TablasdeJo' _ se I 1 OFICINA: - ~- - - - .....

\
trminos de conexin con Oracle, ms que de conexin con una base de datos concreta. (De hecho, en esta arquitectura, la base de datos suele estar asociada con una sola copia en ejecucin del software del SOBD, por lo que en un sentido muy real, Jos usuarios se conectan con el SGBD.) Las instalaciones de OfacIe y de DB2 suelen ejecutar dos bases de datos diferentes. una para trabajo de produccin y otra para pruebas. Fundamentalmente, no obstante, todos los datos de produccin se hallan reunidos en una sola base de datos.
,
'I
I 1 LLLLLLJI I PRODUCTO S
I I
1 1 \
[[J]J m
PEDIDOS
I 1 1 I I
[TI]
-
... _ - - - - - -
1 1 -- I , I I ""1
1 I I 1 1 \ ,
rn
1 I I I 1 1 1
I
Arquitectura de mltiples bases de datos

La Figura 13.10 muestra una arquitectura de mltiples bases de datos en la que cada base de datos tiene asignado un nombre nico. Sybase, Microsoft SQL Server, lngres y otros muchos utilizan este esquema. Como puede verse en la figura, . cada una de las bases de datos de esta arquitectura suele estar dedicada a una aplicacin concreta. Cuando se aade una aplicacin nueva, probablemente se crea una nueva base de dalOs. La principal ventaja de esta arquitectura de mltiples bases de dalOs respecto de la arquitectura de base de datos nica es que divide las tareas de gestin de los dalOs en fragmentos de menor tamao, ms manejables. Cada persona responsable de una aplicacin puede ser ahora el administrador de su propia base de datos, con menores preocupaciones respecto de la coordinacin global. Cuando llega el momento de agregar una aplicacin nueva, puede desarrollarse en su propia base de datos, sin afectar a las bases de datos ya existentes. Es ms probable tambin que los usuarios y los programadores recuerden la estructura global de sus propias bases de datos. El principal inconveniente de la arquitectura de mltiples bases de datos es que cada base de datos puede transformarse en una isla de informacin, desconectada de las dems. Generalmente, las tablas de una base de datos no pueden contener referencias en claves externas a tablas de bases de datos diferentes. A menudo el SGBD no admite las consultas que saltan las fronteras de las bases de datos, 10 que hace imposible relacionar los datos de dos aplicaciones. Si se admiten las consultas a varias bases de datos, puede que impongan una sobrecarga importante o exijan la adquisicin al fabricante del SGBD de software distribuido adicional del SGBD. Si Un SGBD utiliza una arquitectura de mltiples bases de datos y admite las consultas entre bases de datos, debe ampliar los Convenios de denominacin de tablas y columnas de SQL. Los nombres calificados de tabla no slo deben especificar al propietario de la tabla, sino tambin la base de datos que contiene a esa tabla. Generalmente, el SGBD ampla la notacin con puntos de los nombres de las tablas anteponiendo el nombre de la base de datos al del propietario, separados
Base de datos PEDIDOS Tablas de Maria ------------..... , (CUENTAS
",,-
1 1
1 1 1 I I I
I
\
... _-----------"" '

Base de datos CONTABILIDAD Tablas de Jorge
[J]' m rtm:, [TI] ,

I
,
1
:11 1
1 1 1 1 I I
BOLETN
I 1 1 I
1 I
....
/------------....
:
I
1
1
",,-
mFICHAJES
----,
1 1
1 1 1 1
m
ITITl ... - - -I
1
1 1 1 1 I 1 1
:
I
[]J]SALl\RIOS
: :
1
1 1
... ~--_...:~---""
Base de datos NOMINAS
1, \
Figura 13.10. Arquitectura de mltiples bases de datos.
390

~e
391
por un punto (.). Por ejemplo, en una base esta referencia a una tabla:
PEDIDOS.JOSE.OFICINAS
datos de Sybase o de SQL Server,

Directorio de nivel superior
hace referencia a la tabla OFICINAS propiedad del usuario JOSE de la base de datos de procesamiento de pedidos denominada PEDIDOS, y la consulta siguiente vincula la tabla REPRESENTANTES de la base de datos de nminas con la tabla
OFICINAS:
SELECT PEDIDOS .JOSE .OFICINAS. CIUDAD,
Directorio DESARROLLO
NQMINAS.JORGE.REPRESENTANTES.NOMBRE
FROM PEDIDOS.JOSE.OFICINAS, NOMINAS.JORGE.REPRESENTANTES

WHERE PEDIDOS.JOSE.OFICINAS.JEF = NQMINAS.JORGE.REPRESENTANTES.NUM_EMPL
Afortunadamente, estas consultas a varias bases de datos constituyen la excepcin y no la norma, y se pueden utilizar generalmente los nombres predeterminados de bases de datos y de usuarios. Con la arquitectura de mltiples bases de datos, el acceso a las bases de datos se hace algo ms complicado, ya que hay que indicar al SGBD la base de datos que se desea utilizar. El programa de SQL interactivo del SOBD suelen mostrar una lista de las bases de datos disponibles o pedir que se introduzca el nombre de la base de datos junto con el nombre de usuario y la contrasea para obtener acceso. Para el acceso mediante programacin, el SGBD suele ampliar el lenguaje SQL incorporado con una instruccin que conecta al programa con una base de datos concreta. La modalidad de lngres para la conexin con la base de datos denominada PEDIDOS es:
CONNECT 'PEDIDOS'
Figura 13.11.
Arquitectura de ubicacin mltiple.
Para Sybase y Microsoft SQL Server, la instruccin equivalente es:

USE 'PEDIDOS'
Arquitectura de ubicacin mltiple

La Figura 13.11 muestra una arquitectura de ubicacin mltiple que admite varias bases de datos y utiliza la estructura de directorios del sistema informtico para organizarlas. Varias de las primeras bases de datos para minicomputadoras (entre ellas, RdbNMS e lnfonnix) utilizaban este esquema para albergar varias bases de datos. Al igual que con la arquitectura de mltiples bases de datos, cada aplicacin suele estar asignada a su propia base de datos. Como muestra la Figura 13.11, cada base de datos tiene un nombre, pero es posible que dos bases de datos diferentes en dos directorios distintos tengan el mismo nombre. La principal ventaja de la arquitectura de ubicacin mltiple es su flexibilidad. Resulta especi.almente adecuada en aplicaciones como la ingeniera y el diseo, en las que puede que muchos usuarios sofisticados del sistema informtico deseen
utilizar varias bases de datos para estructurar su propia informacin. Los inconvenientes de la arquitectura de ubicacin mltiple son los mismos que los de la ar quitectura de mltiples bases de datos. Adems, el SGBD no suele tener toda la informacin sobre las bases de datos que se han creado, que pueden repartirse por toda la estructura de directorios del sistema. No hay una base de datos maestra que realice un seguimiento de todas las bases de datos, lo que hace muy difcil la administracin centralizada de la base de datos. La arquitectura de ubicacin mltiple vuelve a hacer ms complejo el acceso a las bases de datos, ya que hay que especificar tanto el nombre de la base de datos como su ubicacin en la jerarqua de directorios. La sintaxis de SQL de VAX para el acceso a las bases de datos de RdbNMS es la instruccin DECLARE DATABASE. Por ejemplo, esta instruccin DECLARE DATABAS E establece una conexin c.on la base de datos, denominada PEDIDOS, del directorio de VAXNMS, denommado
M
SYS$ROOT: [DESARROLLO. PRUEBAS]:

DECLARE DATABASE FILENAME 'SYS$ROOT: {DESARROLLO.PRUEBASl PEDIDOS ,
392
/
393
Si la base de datos se halla en el directorio en curso del usuario (lo que suele ocurrir), la instruccin se reduce a:
DECLARE DATABA5E
Estructura de la base de datos y el estndar ANSI/ISO

El estndar ANSIIISO SQLJ realizaba una distincin tajante entre el lenguaje de manipulacin de datos y el lenguaje de definicin de datos de SQL, y los defina de hecho como dos lenguajes diferentes. El estndar no exiga que las instrucciones del LDD fueran aceptadas por el SGBD durante su operacin nor.:~:.t:. Una de las ventajas de esta separacin de LMD y LDD era que el estndar permita una estructura esttica de la base de datos como la utilizada por Jos productos de SGBD antiguos jerrquicos y de red, como puede verse en la Figura 13.12. La estructura de la base de datos especificada por el estndar SQLI era bastante directa. Se definan conjuntos de tablas en el esquema de la base de datos, asociados con usuarios concretos. En la Figura 13.12, la base de datos de ejemplo tiene dos esquemas. Uno de los esquemas est asociado con (1a terminologa habitual es es propiedad de) un usuario llamado Jos, y el otro es propiedad de Mara. El esquema de Jos contiene dos tablas, denominadas PERSONAS y LUGARES. El esquema de Mara tambin contiene dos tablas, denominadas COSAS y LUGARES. Aunque la base de datos contenga dos tablas denominadas LUGARES, resulta posible diferenciarlas porque tienen propietarios diferentes. El estndar SQL2 ampli de manera significativa el concepto de SQLl de definicin de base de datos y de esquema de la base de datos. Como se indic anteriormente, el estndar SQL2 exige que las instrucciones de definicin de datos sean ejecutables por usuarios interactivos de SQL o por programas de SQL. Con esta posibilidad, las modificaciones de la estructura de la base de datos pueden hacerse en cualquier momento, no slo al crear la base de datos. Adems, el concepto de SQLl de esquemas y usuarios (denominado oficialmente IDs de autorizacin en el estndar) se ampli de manera significativa. La Figura 13.13 muestra la estructura de alto nivel de la base de datos especificada por el estndar SQL2. La estructura de la base de datos de nivel superior descrita por el estndar SQL2 es el entorno de SQL. Se trata de un conjunto conceptual de entidades de la base de datos asociado con una implementacin del SGBD que sigue el estndar de SQL2. El estndar no especifica el modo en que se cran entornos de SQL; eso depende de cada implementacin concreta del SOBO. El estndar define estos componentes de los entornos de SQL: Software de SGBD que cumpla el estndar SQL2. Usuarios con nombre (denominados IDs de autorizacin en el estndar) que tienen los privilegios para llevar a cabo acciones concretas sobre los datos y las estructuras de la base de datos. Mdulos de programas que se utilizan para tener acceso a la base de datos. El estndar SQL2 especifica la ejecucin real de las instrucciones de SQL en trminos de un lenguaje de mdulos, que en la prctica no utilizan la mayor parte de los productos comerciales de SQL. No importa la manera en que se crean realmente los programas de SQL; sin embargo, el estndar indica que, conceptualmente, el entorno de SQL incluye el cdigo del programa para acceso a la base de datos. Catlogos que describen la estructura de la base de datos. Los esquemas de las bases de datos de estilo SQLl estn contenidos en estos catlogos.
FILENAME 'PEDIDOS'
Algunas de las marcas de SGBD que utilizan este esquema permiten tener acceso concurrente a varias bases de datos, aunque no incluyan las consultas que atraviesen las fronteras de las bases de datos. Una vez ms, la tcnica utilizada con ms frecuencia para distinguir entre varias bases de datos son los nombres de tabla supercalificados. Dado que dos bases de datos de dos directorios diferentes pueden tener el mismo nombre, tambin es necesario introducir un alias de la base de dalos para eliminar toda ambigedad. Estas instrucciones de SQL de VAX abren dos bases de datos diferentes de RdbNMS. que da la casualidad de que tienen el mismo nombre:
DECLARE DATABAS E FILENAME DECLARE DATABASE FILENAME PEDIOOSl 'SYSSROOT: (PROOUCCION\]PEDIOOS' PEDIOOS2 'SYS$ROOT: [DESARROLLO. PRUEBASj PEDIDOS'
Las instrucciones asignan los alias PEDIDOSl y PEDlDOS2 a las dos bases de datos, y estos alias se utilizan para calificar los nombres de las tablas en posteriores instrucciones de SQL de VAX. Como muestra esta discusin, puede haber una enorme variedad en el modo en que diferentes marcas de SGBD organizan sus bases de datos y ofrecen acceso a las mismas. Esta rea de SQL es una de las menos normalizadas y, pese a ello, suele ser la primera que se encuentra el usuario cuando intenta tener acceso a una base de datos por primera vez. Las inconsistencias tambin hacen imposible pasar de manera transparente los programas desarrollados para un SGBD a otro, aunque el proceso de conversin suele resultar ms tedioso que complicado.
Bases de datos en mltiples servidores

Con el aumento de los servidores de bases de datos y de las redes de rea local, el concepto de ubicacin de la base de datos incluida en la arquitectura de ubicacin mltiple se ampli al concepto de servidor fsico de la base de datos. En la prctica, parece que la mayora de los productos de SGBD de hoy en da convergen en una arquitectura de mltiples bases de datos implementada en un servidor (sico. En su nivel ms elevado, la base de datos se asocia con un servidor de la red con nombre. En el servidor puede haber varias bases de datos con nombre. La relacin entre los nombres de los servidores y las ubicaciones de los servidores fsicos la maneja el software de red. La relacin entre los nombres de las bases de datos y los archivos fsicos o los sistemas de archivos de un servidor la maneja el software del SGBD.
,
..L
394
395
Fase 1: Crear [a base de datos
Fase 11: Utilizar la base de datos
Esquema de la base de datos
Programa de aplicacin
t
=='---,
\ Instrucciones'
;LDD
I,,_====-,'
=_1"-
Programa creador de bases de datos
Tablas de Jos
/----, /----,
s
Tablas de Mara
[[ID ![ m ! -r:
I I I
I
:/[]]P~R;ON~S~I '( Wf -'

I
I I
I I I I I I I I I I I I
Programa : de aPliCaCj:J~
"""'"""'"
Programa de aplicacin J:
~
SGBD
".....""..j
. - Instrucciones de LMD
Tablas de Jos Tablas de Maria
Figura 13.13.
Estructura de una base de datos segn SQL2.
LElTI BJjj
LUGARES
II
LUGARES
I I 11
I I
I
,---_/ ,---_/
Base de datos
, I
' :: w : : ITID:: BJjj : ,----/ ,----/

I LUGARES I I LUGARES I
Catlogos en SQL2
En los entornos de SQL, la estructura de la base de datos se-define mediante uno o varios catlogos con nombre. La palabra catlogo en este caso se utiliza del mismo modo que se ha utilizado histricamente en los grandes sistemas informticos: para describir un conjunto de objetos (generalmente archivos). En los sistemas de minicomputadoras y de computadoras personales, el concepto es anlogo, grosso modo, a un directorio. En el caso de las bases de datos de SQL2, el catlogo es un conjunto de esquemas de la base de datos con nombre. El catlogo tambin contiene un conjunto de tablas del sistema (denominado a menudo, de manera que induce a error, catlogo del sistema) que describe la estructura de la base de datos. El catlogo es, por tanto, una entidad que se describe a s misma dentro de la base de datos. Esta caracterstica de los catlogos de SQL2 (que ofrecen todos los principales productos de SQL) se describe con detalle en el Captulo 16. El estndar SQL2 describe el papel del catlogo y especifica que cada entorno de SQL puede contener uno o varios (realmente, cero o ms) catlogos, cada uno de los cuales debe tener un nombre diferente. Indica explcitamente que el mecanismo para la creacin y la destruccin de los catlogos viene definido por la im-
Base de datos
Figura 13.12.
Un SGSD con LDD esttico.
Datos de la bases de datos, que gestiona el software del SGBD, a los que los usuarios tienen acceso mediante los programas, y cuya estructura se describe en los catlogos. Aunque el estndar describe conceptualmente los datos como externos a la estructura de los catlogos, es frecuente creer que los datos se contienen en una tabla, que est en un esquema, que est en un catlogo.
.J
/
396
397
plementacin. El estndar indica tambin que el grado en que el SGBD permite el acceso a otros catlogos viene definido por la implementacin. Especficamente, si una sola instruccin de SQL puede tener acceso a los datos desde varios catlogos, si una sola transaccin de SQL puede abarcar varios catlogos o, incluso, si una sola sesin de usuario con el SGBD puede cruzar las fronteras entre los catlogos )ion, todas ellas, caractersticas definidas por la implementacin. El estndar indica que cuando un usuario o programa establece contacto por primera vez con un entorno de SQL. uno de sus catlogos se identifica como catlogo predeterminado de la sesin. (Una vez ms, la manera en que se selecciona este catlogo viene definida por la implementacin.) Durante el curso de una sesin, el catlogo predeterminado puede cambiarse utilizando la instruccin SET
CATALOG.
Los esquemas se crean con la instruccin CREATE SCHEMA, que puede verse en la Figura 13.14. A continuacin se ofrece la definicin de un esquema sencillo de SQL2 para el esquema sencillo de dos tablas del usuario JOS E que puede verse en a Figura 13.12:
CREATE SCHEMA CREATE TABLE (NOMBRE EDAD CREATE TABLE (CIUDAD ESTADO GRANT ON TO GRANT ON TO ESQUEMAJOSE AUTORIZACION JOSE PERSONAS VARCHAR(30). INTEGER) LUGARES VARCHAR(30j. VARCHAR(30jj ALL PRIVILEGES PERSONAS PUSLIC SELECT LUGARES MARIA
Esquemas en SQL2
Los esquemas de SQL2 son el contenedor furidamental de alto nivel de los objetos de la estructura de 1.a base de datos. Los esquemas son entidades de la base de datos con nombre e incluyen las definiciones de los elementos siguientes: Tablas. Junto con sus estructuras asociadas (columnas, claves primarias y externas, restricciones de tabla, etc.), las tablas siguen siendo los elementos constitutivos bsicos de las bases de datos en los esquemas de SQL2. Vistas. Se trata de tablas virtuales, procedentes de las tablas reales definidas en el esquema, tal y como se describe en el Captulo 14. Dominios. Funcionan como tipos ampliados de datos para la definicin de columnas en las tablas del esquema, como se describe en el Captulo 11. Asertos. Estas restricciones de integridad de la base de datos restringen las relaciones de los datos entre las tablas del esquema, como ya se describi en el apartado Asertos. Privilegios. Los privilegios de la base de datos controlan las posibilidades que' se otorgan a los diferentes usuarios para el acceso a los datos de la base de datos y su actualizacin y para la modificaci6n de la estructura de la base de datos. El esquema de seguridad de SQL creado por estos privilegios se describe en el Captulo 14. Conjuntos de caracteres. Las bases de datos soportan diferentes idiomas y gestionan la representacin de caracteres no romnicos de esos idiomas (por ejemplo. la tilde diacrtica empleada por muchos idiomas europeos o las representaciones de dos bytes de los ideogramas utilizados en muchos idiomas asiticos) mediante conjuntos de caracteres definidos por el esquema. Ordenaciones. Trabajan mano a mano con los conjuntos de caracteres, definiendo la secuencia de ordenacin de cada uno de ellos. Traducciones. Controlan el modo en que los datos de texto se convierten de un conjupto de caracteres a otro, y la forma en que se realizan las comparaciones de datos de texto de diferentes conjuntos de caracteres.
1-
CREATE scnEMA
l:,".esquema
L
nombre-usuario
~
AUTHORIZATION
.-1
nombreusuario
AUTHORIZATION
L
I
-
DEFAULT CHARACTER SET
nombre-eonjunto-caracteres
CREATE TABLE CREATE VIEW CREATE DOMAIN
. resto de la definicin de la Ubllt ... resto de lit definicin de lit V;$tlt - - - ... re$to de lit definicin del dominio - - ... resto de lit definicin de/ltSfJno ." re$to de lit definicin del conjumo de C4rltCfe/'fJ$ ... resto de la definicin de lit SfJCUencilt de orOenacin... resto de lit definicin de lit lraduccin
CREATE ASSERTION
CREATE CHARACTER SET CREATE COLLATION CREATE TRANSLATION

GRANT privilegios
-
- - - - ... reslO de /11 definicin dI! los privilegios
Figura 13.14.
Diagrama sintctico de la instruccin CREATE SCHEMA.
398
399
El esquema define las dos tablas y concede a otros usuarios concretos permiso para tener acceso a ellas. No define ninguna estructura adicional, como las vistas o los asertos. Obsrvese que las instrucciones CREATE TABLE de la instruccin CREATE SCHEMA son instrucciones legtimas de SQL por s mismas. Si se escriben en un programa de SQL interactivo el SGBD crear las tablas especificadas en el esqlle ma predeterminado vigente para la sesin interactiva de SQL, de acuerdo con el estndar. Obsrvese que en SQL2 la estructura del esquema se relaciona con la estructura de IDs de usuario. pero es independiente de ella. Un usuario dado puede ser propietario de varios esquemas con nombres diferentes. No obstante, en aras de la compatibilidad con el estndar SQLl, el estndar SQL2 permite crear esquemas con: Un nombre de esquema y un ID de usuario (como en el ltimo ejemplo). S610 un nombre de esquema. En este caso, el usuario que ejecuta la instruccin CREATE SCHEMA se transforma de manera automtica en propietario del esquema. Slo una ID de usuario. En este caso, el nombre del esquema se transforma en la ID de usuario. Esto cumple el estndar SQL1, y la prctica de muchos productos comerciales de SGBD en los que conceptualmente hay un esquema por usuario. Los esquemas de SQL2 que ya no son necesarios pueden eliminarse utilizando la instruccin DROP SCHEMA, que puede verse en la Figura 13.15. La instruccin exige que se especifique una de las reglas de eliminacin para eliminar columnas que ya se han descrito: bien CASCADE, bien RESTRICT. Si se especifica CASCADE, todas las estructuras dentro de la definicin del esquema (tablas, vistas, asertos, etc.) se eliminan de manera automtica. Si se especifica RESTRICT, la instruccin no tendr xito si permanece dentro del esquema alguna de estas estructuras. De hecho, la regla RESTRICT obliga a eliminar las tablas, vistas y dems estructuras incluidas en el esquema antes de eliminar el propio esquema. Se trata de una proteccin contra eliminaciones accidentales de esquemas que contengan datos o definiciones de bases de datos an de valor. El estndar SQL2 no especifica ninguna tabla ALTER SCHEMA. En vez de eso, se puede alterar cada definicin de las estructuras incluidas en el esquema, mediante instrucciones como
ALTER TABLE.
En cualquier momento, mientras un usuario o un programa tiene acceso a una base de datos de SQL2, uno de sus esquemas queda identificado como esquema predeterminado de la base de datos. Las instrucciones LDD que se ejecuten para crear, eliminar o alterar estructuras de esquema se aplican de manera implcita a este esquema. Adems, se supone que todas las tablas con nombre de las instrucciones de manipulacin de datos de SQL2 son tablas definidas en este esquema predeterminado. El nombre del esquema califica de manera implcita los nombres de todas las tablas utilizadas en las instrucciones de SQL. Como se indicaba en el Captulo 5, se puede utilizar un nombre de tabla calificado para hacer referencia a las tablas de otros esquemas. De acuerdo con el estndar SQL2, el nombre utilizado para calificar el nombre de la tabla es el nombre del esquema. Por ejemplo, si la base de datos de ejemplo se creara como parte de un esquema denominado VENTAS, el nombre de tabla calificado para la tabla OFICINAS sera:
VENTAS. OFICINAS
Si s~ crea un esquema de SQL2 con slo un ID de usuario como nombre del esquema, el esquema de calificacin de las tablas se convierte exactamente en el esquema sencillo que se describe en el Captulo 5. El nombre del esquema es el nombre de usuario, y el nombre de tabla calificado especifica ese nombre antes del punto. La instruccin CREATE SCHENA de SQL2 tiene otra ventaja no tan evidente. Se recordar de la discusin anterior sobre la instruccin CREATE TABLE que no se poda crear con facilidad un ciclo referencial (dos o ms tablas que se hacen referencia entre s empleando relaciones de claves externas y primarias). En lugar de eso, haba que crear antes una de las tablas sin su definicin de la clave externa, y luego haba que aadir la definicin de la clave externa (con la instruccin ALTER TABLE), una vez creadas las otras tablas. La instruccin CREATE SCHENA evita este problema, ya que el SGBD no comprueba las restricciones de integridad referencial especificadas por el esquema hasta que se hayan creado todas las tablas que define. En la prctica, la instruccin CREATE seHEMA se utiliza generalmente para crear por primera vez un nuevo conjunto de tablas interrelacionadas. Posteriormente, cada tabla se aade, elimina o modifica empleando las posibilidades de CREATEf
DROP!ALTER TABLE.
f-
DROP SCHEMA
nombredeesquema
RESTRICT
~------_
CASCADE
--.J
DROP SCHEMA.
Figura 13.15.
Diagrama
sintctico de la instruccin
Muchas de las principales marcas de SGBD han pasado a adoptar alguna modalidad de la instruccin CREATE SCHENA, aunque hay variaciones significativas entre unas marcas y otras. La instruccin de Gracle CREATE SCHEMA permite crear tablas, vistas y privilegios, pero no las dems estructuras de SQL2, y exige que el nombre del esquema y el nombre de usuario coincidan. Informix Universal Server sigue una estructura similar; exige un ID de usuario como nombre del esquema y ampla los objetos incluidos en el esquema para abarcar los ndices, los disparadores y los sinnimos. Sybase ofrece posibilidades parecidas. En cada caso, las posibilidades ofrecidas cumplen los requisitos de la implementacin de nivel Inicial de SQL2. .
/
400
Resumen
Este captulo ha descrito las caractersticas del lenguaje de. definicin de datos de SQL que definen y modifican la estructuras de las bases de datos: La instruccin CREATE TABLE crea tablas y define sus columnas, sus claves primarias y sus claves externas. La instruccin DROP TABLE elimina de la base de datos tablas creadas anteriormente. La instruccin ALTER TABLE puede utilizarse para aadir columnas a tablas ya existentes y para modificar las definiciones de las claves primarias y externas. Las instrucciones CREATE INDEX y DROP INDEX definen los ndices, que ace:. leran las consultas a las bases de datos, pero aaden sobrecarga a las actualizaciones de las bases de datos. La mayor parte de las marcas de SGBD admiten otras instrucciones CREATE, DROP y ALTER, utilizadas con objetos especficos de cada SGBD. El estndar SQL2 especifica un esquema de base de datos que contiene un conjunto de tablas, que se manipula con las instrucciones CREATE SCHEMA y
DROP SCHEMA.
CAPTULO
14
Vistas
Las diversas marcas de SGBD utilizan enfoques muy diferentes para la organizacin de las bases de datos que administran, y estas diferencias afectan al modo en que se designan las bases de datos y se obtiene acceso a ellas.
Las tblas de las bases de datos definen la estructura y organizacin de los datos. No obstante, SQL tambin permite examinar los datos almacenados de otra manera, definiendo vistas alternativas de los datos. Una vista es una consulta de SQL que se almacena de manera permanente en la base de datos y a la que se le asigna un nombre. El resultado de la consulta almacenada es visible mediante la vista, y SQL perrite el acceso al resultado de esta consulta como si fuera, de hecho, una tabla autntica de la base de datos. Las vistas constituyen una parte importante de SQL por varios motivos: Las vistas penniten personalizar la apariencia de la base de datos de modo que usuarios diferentes la vean desde diferentes perspectivas. Las vistas penniten restringir el acceso a los datos. de tal fonna que usuarios diferentes slo vean ciertas filas o columnas de una tabla. Las vistas simplifican el acceso a la base de datos presentando la estructura de los datos almacenados de la manera ms natural para cada usuario. Este captulo describe la manera de crear vistas y el modo de emplearlas para simplificar el procesamiento y mejorar la seguridad de las bases de datos.
Concepto de vista
Las vistas son tablas virtuales de la base de datos cuyo contenido viene definido por una consulta, como se muestra en la Figura 14.1. Para los usuarios de la base de datos la vista tiene la misma apariencia que las tablas verdaderas, con un conjunto de columnas con nombre y filas de datos. Pero, a diferencia de las tablas verdaderas, las vistas no existen en la base de datos corno conjuntos almacenados de valores de datos. Por el contrario, las filas y las columnas de datos visibles mediante las vistas son el resultado de una consulta generado por la consulta que define cada vista. SQL crea la ilusin de la vista concediendo a las vistas nombres,
401
402
Captulo 14: Vistas
403
T bl a REPRESENTANTES
NUM EMPL
NOMBRE
EDAD
CUOTA
VENTAS
'OS Brullo Arteaga
'" >O, '" >O. '" no >O,
MlIra Jirnenez Susana Santos Samuel Clavel
Bernardo Snchez D<lniel Ruidrobo

Toms Saz
48 52 33
4S
~~ I <
350 300 350 275
DCO,DOE DOO,DOE DCO,DOE

DCO.DC
"O Dao,oaE
300 DCO,CeE
NULL
Len Freir"
" \\ 62
350 DCO,DOE
Vista DATOSREP
NOMBRE
CIUDAD
REGIN
CUOTA
//
VENTAS
'" ." '" 673.00 9aS,DoE '"
911.00 392 .125,OO

.OSO,DOE
que trabaja. Como puede verse en la figura, la vista tiene el aspecto de una tabla, y su contenido tiene el mismo aspecto que el resultado de la consulta que se obtendra si se ejecutara la consulta realmente. Una vez definida una vista, se puede utilizar en instrucciones SELECT, igual que las tablas verdaderas, como en esta consulta:
Listar los representantes que han superado su cuota, mostrando el nombre, la ciudad y la regin de cada uno.
SELECT NOMBRE, CIUDAD, FROM DATOSREP WHERE VENTAS > CUOTA NOMBRE CIUDAD REGlaN
299 912,OO 594,OO 305 15 865.00
REGlaN
Mara Jimnez Sarnuel Clavel
Navarra Navarra
Caste1l6n Caste1l6n Almeria Len Len Daimiel
.~
Bernardo Snchez Caste1l6n
Este Este Este
Pablo Cruz Daniel Ruidrobo
Este
Este Este Oeste Oeste Oeste
Bruno Arteaga Susana Santos Len Fl:."eire Neus Azcrate
300.000,OO 392 725,OO 275.000,OO 215 DCO,DOE 594,OO 200.DCO,DOE 275.000,OO 286 775,OO 300.000,OO 30S 673.00. 350.000,OO 361 911.00 .OSO,OO 350.000,OO 350.000,OO 865,OO 3S0.DOO,OO >8, 042,OO
'"
'"
'"
Mara Jimnez Samuel Clavel Daniel Ruidrobo Pablo Cruz Bruno Arteaga Susana Santos Len Freire
Navarra Navarra Castelln Castell6n Almera Len Len
Este Este Este Este Este Oeste Oeste
~
OFICINA CIUDAD
22 Daimiel 13 Navarra 12 Castelln 13 Almeria n Len
REGIN
Oeste Este Este Este Oeste
'" >O,
>O, >O. NULL >O,
I~
El nombre de la vista, DATOSREP, aparece en la sentencia FROM como si fuera el nombre de una tabla, y se hace referencia a las columnas de la vista en la instruccin SELECT igual que a las columnas de las tablas verdaderas. Para algunas vistas tambin se pueden utilizar las instrucciones INSERT, DELETE y UPDATE, con el fin de modificar los datos visibles mediante la vista, como si fuera una tabla verdadera. Por tanto, a todos los efectos prcticos, la vista puede utilizarse en las instrucciones de SQL como si fuera una tabla verdadera.
El manejo de las vistas por el SGBD

Cuando el SGBD encuentra una referencia a una vista en una instruccin de SQL, busca la definicin de la vista almacenada en la base de datos. Luego traduce la solicitud que hace referencia a la vista en una solicitud equivalente a'las tablas fuente de la vista y ejecuta la solicitud equivalente. As, el SGBD mantiene la ilusin de la vista al tiempo que conserva la integridad de las tablas fuente, En el caso de las vistas sencillas puede que el SGBD cree cada vista sobre la marcha, extrayendo de las tablas fuente los datos de las fijas. En el caso de vistas ms complejas, el SGBD debe materializar realmente la vista; es decir, el SGBD debe ejecutar realmente la consulta que define la vista y almacenar el resultado en una tabla temporal. El SGBD atiende las solicitudes de acceso a la vista desde esa tabla temporal y la descarta cuando ya no es necesaria. Independientemente del modo en que el SGBD maneja realmente cada vista concreta, el resultado es el mismo para los usuarios -se puede hacer referencia a la vista en las instrucciones de SQL exactamente igual que si fuera una tabla verdadera de la base de datos.
Figura 14.1.
Vista tpica con dos tablas fuente.
como los nombres de las tablas, y almacenando las definiciones de las vistas en la base de datos. La vista mostrada en la Figura 14.1 es tpica. Se le ha dado el nombre de DATOSREP y viene definida por esta consulta a dos tablas:
SELECT NOMBRE, CIUDAD, REGION, CUOTA, FROM REPRESENTANTES, OFICINAS WHERE OFICINA~REP ~ OFICINA REPRESENTANTES. VENTAS
Los datos de la vista provienen de las tablas REPRESENTANTES y OFICINAS. Estas tablas se denominan tablas fuente de la vista porque son la fuente de los datos que son visibles mediante la vista. Esta vista contiene una fila de informacin por cada representante, ampliada con el nombre de la ciudad y de la regin en
404
Captulo 14: Vistas
405
Ventajas de las vistas

Las vistas ofrecen una gran variedad de ventajas y pueden resultar tiles en muchos tipos diferentes de bases de datos. En las bases de datos para computadoras personales las vistas suelen ser una comod.idad, y se definen para simplificar las peticiones a la base de daLOs. En las instalaciones de las bases de datos de produccin las bases de datos desempean un papel fundamental en la definicin de la estructura de la base de datos para los usuarios y en el mantenimiento de la seguridad. Las vistas ofrecen estas ventajas principales:
Estos inconvenientes implican que no se pueden definir y utilizar las vistas de manera indiscriminada en lugar de las tablas fuente. En vez de eso, en cada caso hay que considerar las ventajas ofrecidas por el empleo de las vistas y compararlas con los inconvenientes.
Creacin de vistas
(CREA TE VIEW)
Seguridad. Se puede conceder permiso a cada usuario para que slo tenga acceso a la base de datos mediante un conjunto reducido de vistas que contengan los datos concretos que ese usuario est autorizado a ver, restringiendo as el acceso de los usuarios a los datos almacenados. Simplicidad de las consultas. Las vistas pueden extraer datos de varias tablas diferentes y presentarlas como si fueran una sola tabla, convirtiendo las consultas a varias tablas en consultas a una sola tabla formuladas a la vista. Simplicidad estructural. Las vistas pueden ofrecer a los usuarios una vista personalizada de la estructura de la base de datos, presentando la base de datos como un conjunto de tablas virtuales que tiene sentido para el usuario. Aislamiento de las modificaciones. Las vistas pueden presentar una imagen consistente y no modificada de la estructura de la base de datos, aunque las tablas fuente subyacentes se dividan, se reestructuren o cambien de nombre. Integridad de los datos. Si se tiene acceso a los datos y se introducen mediante vistas, el SOBD puede comprobarlos de manera automtica para asegurarse de que cumplen las restricciones de integridad especificadas.
La instruccin CREATE VIEW, que puede verse en la Figura 14.2, se emplea para crear vistas. La instruccin asigna un nombre a la vista y especifica la consulta que define la vista. Para crear la vista con xito hay que tener permiso para el acceso a todas las tablas a las que se hace referencia en la consulta. La instruccin CREATE VIEW puede asignar, de manera opcional, un nombre a cada columna de la vista recin creada. Si se especifica una lista de nombres de columna, debe tener el mismo nmero de elementos que el nmero de columnas generado por la consulta. Obsrvese que slo se especifican los nombres de las columnas; el tipo de datos, su longitud y otras caractersticas de cada columna se obtienen de la definicin de las columnas en las tablas fuente. Si se omite la lista de nombres de columna en la instruccin CREATE VIEW, cada columna de la vista adopta el nombre de la columna correspondiente de la consulta. La lista de nombres de columnas debe especificarse si la consulta incluye columnas calculadas o si genera dos columnas con nombres idnticos. Aunque todas las vistas se crean de la misma manera, en la prctica se utilizan normalmente distintos tipos de vista para finalidades diferentes. -Los-apartados siguientes examinan estos tipos de vistas y ofrecen ejemplos de la instruccin CREATE VIEW.
Vistas horizontales Inconvenientes de las vistas

Aunque las vistas ofrecen ventajas importantes, tambin 'hay dos inconvenientes: principales en el empleo de las vistas en lugar de tablas reales: Rendimiento. Las vistas crean el aspecto de tabla, pero el SOBD todava debe traducir las consultas a la vista en consultas a las tablas fuente subyacentes. Si se define la vista mediante una consulta a varias tablas, incluso una consulta sencilla a la vista se transforma en una reunin compleja y puede tardar mucho tiempo en completarse. Restricciones de actualizacin. Cuando un usuario intenta actualizar las filas de una vista, el SGBD debe traducir la solicitud en una actualizacin de las filas de las tablas fuente subyacentes. Esto es posible para las vistas sencillas,_ pero las vistas ms complejas no pueden actualizarse; son slo de lectura. Un empleo frecuente de las vistas es limitar el acceso de los usuarios solamente a las filas seleccionadas de las tablas. Por ejemplo, en la base de datos de ejemplo, puede que slo se desee permitir a un jefe de ventas ver las filas de la tabla REPRESENTANTES de los representantes de la misma regin que el jefe de
l- CREATE
VIEW
nombre-de-visrsl _(nombre-de-columnaL
J
t..-, ..-.J
AS
consufts-+.
Figura 14.2.
Diagrama sintctico de la instruccin CREATE VIEW.
406
Captulo 14: Vistas
407
ventas. Para conseguirlo, se pueden definir dos vistas, como se muestra a continuacin:
Crear una vista que muestre los representantes de la regi6n Este.

CREATE VIEW REPESTE AS SELECT PROM REPRESENTANTES WHERE OFICINA_REP IN (11, 12, 13)
zontalmente las tablas para crear cada vista. Todas las columnas de la tabla fuente forman parte de la vista, pero slo algunas de las filas son visibles mediante la vista. Las vistas horizontales resultan adecuadas cuando la tabla origen contiene datos que se relacionan con varias organizaciones o usuarios. Ofrecen una tabla privada para cada usuario, compuesta nicamente de las filas que ese usuario necesita. A continuacin se ofrecen algunos ejemplos ms de vistas horizontales:
Definir una vista que slo contenga las oficinas de la regin Este.
Crear una vista que muestre los representantes de la regin Oeste.

CREATE VIEW RE POESTE AS SELECT PROM REPRESENTANTES WHERE OFICINA_REP IN {21, 22} CREATE VIEW OFICINASESTE AS SELECT FROM OFICINAS WHERE REGION ~ 'Este'
Ahora se puede dar a cada jefe de ventas permiso para que tenga acceso a la vista REPESTE o a la vista REPOESTE y le niegue el permiso para el acceso a la otra vista y a la propia tabla REPRESENTANTES. Esto ofrece de hecho al jefe de ventas una vista personalizada de la tabla REPRESENTANTES, que slo muestra los representantes de la regin correspondiente. Las vistas como REPESTE O REPOESTE suelen denominarse vistas horizontales. Como se muestra en la Figura 14.3, las vistas horizontales fragmentan hori-
Definir una vista para Susana Santos (empleada nmero 102) que slo contenga los pedidos formulados por los clientes que tiene asignados.
CREATE VIEW PEDIDOSSUSANA AS SELECT PROM PEDIDOS WHERE CLIENTE IN (SELECT NUM_CLI FROM CLIENTES WHERE REP_CLI ~ 102)
Definir una vista que s610 muestre los clientes que tengan ms de 30.000 en pedidos actualmente en los libros.
V'15 t a REPE S TE
NUM_EMPL NOMBRE
DA 37 31 52
33 45
105 109 106 104 101 103
Bruno Arteaga Mara Jimnez Samuel Clavel Bernardo Snchez Daniel Ruidrobo Pablo Cruz
}~
29
}~
Tabla REPRESENTANTES NmLEMPL NOMBRE
SD"
VENTAS
CREATE VIEW GRANDESCLIENTES AS SELECT PROM CLIENTES WHERE 30000.00 < (SELECT SUM(IMPORTE) FROM PEDIDOS WHERE CLIENTE: NUM_CLI)
Vista REPOESTE NUM_EMPL NOMBRE
EDAD 48 62 49
102 Susana Santos 108 Len Freire 107 Neus Azcrate
if
lDS lD9 lD2 106 lD' lDl 110 108 10) lD7
Bruno Arteaga Maria Jimnez Susana Santos Samuel Clavel Bernardo Sm:hez Daniel Ruidrobo Toms Saz Len Freire Pablo Cruz Neus Azcrate
37 31 48 52
33 45
41
I<
62 49
291~
367 .911,OO 392 .725.00- 474 . O50,OO 299 .912,00 142 .594.00 30S. 673,00 '5 .985,OO 361 .865,OO 286.775.00 186.042.00
En cada uno de estos ejemplos la vista se ha obtenido de una sola tabla fuente . La vista se define mediante una consulta SELECT * y, por tanto, tiene exactamente las mismas columnas que la tabla fuente. La clusula WHERE determina las filas de la tabla fuente que son visibles en la vista.
Vistas verticales
Otro uso frecuente de las vistas es la limitacin del acceso de los usuarios slo a ciertas columnas de las tablas. Por ejemplo, en la base de datos de ejemplo, puede que el departamento de procesamiento de pedidos necesite tener acceso al nmero de empleado, el nombre y la asignacin de oficina de cada representante, ya que esa informacin puede ser necesaria para procesar correctamente los pedidos. Sin
Figura 14.3.
Dos vistas horizontales de la tabla REPRESENTANTES.
408
Captulo 14: Vistas
409
embargo, no hace falta que el personal de procesamiento de pedidos vea las ventas del ao corriente de cada representante ni su cuota. Esta vista selectiva de la tabla REPRESENTANTES puede construirse con la vista siguiente: Crear una vista que muestre informacin seleccionada de cada representante.
CREATE VIEW INFOREP AS SELECT NUM_EMPL, NOMBRE, OFICINA_REP FROM REPRESENTANTES
Ofrecen una tabla privada para cada usuario, compuesta nicamente de las columnas que ese usuario necesita. A continuacin se muestran algunos ejemplos de vistas verticales: Definir una vista de la tabla OFICINAS para el personal de procesamiento de pedidos que incluya la ciudad. el nmero de oficina y la regin de cada oficina.
CREATE VIEW INFOOFICINAS AS SELECT OFICINA, CIUDAD, FROM OFICINAS REGION
Al dar al personal de procesamiento de pedidos acceso a esta vista y denegarle el acceso a la tabla REPRESENTANTES, se restringe de hecho el acceso a los datos delicados de ventas y de cuotas. Las vistas como INFOREP suelen denominarse vistas verticales. Como puede verse en la Figura 14.4, las vistas verticales fragmentan las tablas fuente vertical mente para crear la vista. Las vistas verticales se hallan generalmente donde los datos almacenados en las tablas los utilizan varios usuarios o grupos de usuarios.
Definir una visla de la labla CLIENTES que slo incluya los nombres de los. clientes y su asignacin a los representantes.
CREATE VIEW INFOCLI AS SELECT EMPRESA, REP_CLI FROM CLIENTES
En cada uno de estos ejemplos la vista se ha obtenido de una sola tabla fuente.
La lista de seleccin en la definicin de la vista determina las columnas de la tabla
Tabla INFO
NU!'LDtPL
""....,"
~,
OFICIWJ\EP
fuente visibles en la vista. Como se trata de vistas verticales, todas las filas de la tabla fuente estn representadas en la vista, y la definicin de la vista no incluye ninguna clusula WHERE.
". ", '" ". no '"

>OS
>OS
Bruno Arteaga !'laria Jilrinez sus...... San&os S"",uel Clavel Bernardo Snchez D<lniel Ruidrobo
13 11
11 13 13
"
Vistas de subconjuntos de filas y columnas

Cuando se define una vista, SQL no limita al usuario a definir fragmentos puramente horizontales o verticales de las tablas. De hecho, el lenguaje SQL no incluye el concepto de vistas horizontales ni verticales. Estos conceptos simplemente ayudan a visualizar el modo en que la vista presenta la informacin de las tablas fuente. Resulta bastante frecuente definir vistas que fragmentan las tablas fue'nte tanto en la dimensin horizontal como en la vertical, como en este ejemplo: Definir una vista que contenga el nmero de cliente, el nombre de la empresa y el lfmite de crdIto de todos los clientes asignados a Bruno Arteaga (empleado nmero 105).
CREATE VIEW SELECT FROM WHERE CLIBRUNO AS NUM_CLI, EMPRESA, LIMIT&_CREDITO CLIENTES REP_CLI = 105
Toms Su
Len Freire Pahl0 Cruz Neus Azcrll&e
'" '" T
""" "
13
"
NUH.-EMPL NOMBRE Bruno Arteaoa l'Iada JiDnez Sllsana Sotntos $aII:lJ.el Clavel Ilen>ardo Snchez Daniel Ruidrobo
", ". '" ". '" 11. """ ~, '" '" '"
>OS
LeD
m~
.
" " n " " "
11
13
P'reirlr Pablo Crut NeU5 A%c6rate
. -
OFICINA.-REP 13 11 21 11 12
:L2
21 12 22
PUESTO Representante Representante J[r.>r_tante VP V~ws Jefe V...wa Represenwnte Represenwnte Jete ventas Representante Representante
FECH1\...CONTADO U-FES-88 U-OCT-89 lO-OIC-86 14-Jt./lI-88 19-KAY-81 20-OCT86 13-D<E-90 12-oc1'-89 l-MAR-81 14-NO\'-88
". '"
'"
".
COO>"A
"""AS
3S0.000.00 300.000.00E: >OS 3S0.000,00 21S.000.00 200.000,00 lOO.OOO,OO
'" ". ". "8
361.911,00E: 3!12.12S.00 C14.0S0,00 299.9l2.00 142.594.00 30S.613.00 1S.985.00 3S0.000,OOE: 361.86S,OOE: 21S.000.00 286.nS.OoE: 300.000,OO l86.042.00
Figura 14.4.
Vista vertical de la tabla REPRESENTANTES.
Los datos visibles mediante esta vista son un subconjunto de filas y columnas de la tabla CLIENTES. S610 son visibles mediante esta vista las columnas citadas expresamente en la lista de seleccin de la vista y las columnas que cumplen la condicin de seleccin.
410

Mara Jimnez Pablo Cruz
2
Captulo 74: Vistas

7.105,OO 2.7QO,OO
3.S52,SO
411
Vistas de agrupacin
GROUP BY.
1.350,OO
La consulta especificada en la definicin de una vista puede incluir una clusula Este tipo de vista se denomina vista de agrupacin, porq.ue los dat.os visibles mediante la vista son el resultado de una consulta de agrupacIn. Las VIStas de agrupacin desempean la misma funcin que las consultas de agrupacin; agrupan filas de datos relacionadas y generan una fila de resultados de la consulta
para cada grupo, que resume los datos de ese grupo. Las vistas d~ agrupacin muestran el resultado de estas consultas de agrupaCin en una tabla virtual, Jo que permite llevar a cabo consultas posteriores sobre esos datos.. A continuacin se ofrece un ejemplo de vista de agrupacin:
Definir una vista que contenga datos resumidos de los pedidos de cada representa1Ue.
CREATE VIEW PEDIDos_paR_REPRESENTANTE (QUIEN, CUANTOS, TOTAL, MINIMO. MAXIMO, PROMEDIO) AS SELECT REP. COUNT(*), SUM(IMPORTE) , MIN(IMPORTE) , MAX(IMPORTE) , AVG(IMPORTE) FROM PEDIDOS GROUP BY REP
A diferencia de las vistas horizontales o verticales, las filas de las vistas de agrupacin no tienen una correspondencia de uno a uno con las filas de la tabla fuente. La vista de agrupacin no es s610 un filtro de su tabla fuente que excluye ciertas filas y columnas, sino tambin un resumen de su tabla fuenre; por tanto, se necesita una cantidad considerable de procesamiento del SOBD para mantener la ilusin de la tabla virtual para las vistas de agrupacin. Las vistas de agrupacin pueden utilizarse en consultas igual que Olras vistas ms sencillas. Sin embargo, las vistas de agrupacin no pueden actualizarse. El motivo debera ser evidente a partir del ejemplo. Qu significara actualizar el tamao medio de los pedidos del representante nmero lOS? Como cada fila de una vista de reunin corresponde a un grupo de filas de las tablas fuente, y las columnas de las vistas de agrupacin suelen contener datos calculados, no hay manera de traducir la solicitud de actualizacin a las filas de las tablas fuenle. Las vistas de agrupacin, por tanto, actan como vistas slo de lectura, que pueden participar en consultas pero no en actualizaciones. Las vistas de agrupacin tambin estn sometidas a las restricciones de SQL respecto a las funciones de columna anidadas. Recurdese del Captulo 8 que las funciones de columna anidadas, corno:
MIN (HIN (A))
Como muestra este ejemplo, la definicin de una vista de agrupacin incluye siempre una lista de nombres de columnas. La lista asigna nombres a las columnas de la vista de agrupacin, que se obtienen mediante funciones de columna como SUM () y MIN ( ). Puede que tambin especifique un nombre modificado para una columna de agrupacin. En este ejemplo, la columna REP de la tabla PEDIDOS se transforma en la columna QUIEN de la vista PEDIDOS_POR_REPRESENTANTE. Una vez que se ha definido esta vista de agrupacin, puede utilizarse para simplificar las consultas. Por ejemplo, esta consulta genera un informe sencillo que resume los pedidos de cada representante:
no son legales en las expresiones de SQL. Aunque las vistas de agrupacin ocultan del usuario las funciones de columna en su lista de selecci6n, el SGBD sigue teniendo informacin sobre ellas y hace que se cumpla ]a restriccin. Considrese este ejemplo:
Para cada oficina de ventas mustrese el rango de tamaos promedio de los pedidos de todos los representantes que trabajan en esa oficina.
SELECT FROH WHERE GROUP Error: OFICINA_REP, MIN(PROMEDIO) , MAX(PROMEDIO) REPRESENTANTES. PEDIDos_paR_REPRESENTANTE NUM_EMPL : QUIEN BY OFICINA_REP Funciones de columna anidadas
Mostrar el nombre, el nmero de pedidos, el importe total de los pedidos y el tamao medio de los pedidos de cada representante.
SELECT FROM WHERE aRDER NOMBRE NAME, CUANTOS, TOTAL, PROMEDIO REPRESENTANTES, PEDIDOS_POR_REPRESENTANTE QUIEN : NUM_EMPL BY TOTAL DESC CUANTOS TOTAL PROMEDIO
---------------- --------7 ----------- ----------58.633,OO B. 316.14 Len Freire

5 3 2 3 2
4
Bruno Arteaga Neus Azcrate Samuel Clavel Daniel Ruidrobo Toms S., Susana Santos
39.321,OO 34.432,OO 32.958.00 26.628,OO 23.132,OO 22.176,OO
7 .865,40 11 .471,33 16 .419,OO B .816,OO 11 .566,OO 5 .694,OO
Esta consulta produce un error, aunque parezca perfectamente razonable. Se trata de una consulta a dos tablas que agrupa las filas de la vista PEDIDOS_POR-REPRESENTANTE de acuerdo con la oficina a la que est asignado cada representante. Pero las funciones de columna MIN () y MAX () de la lista de selecci6n provocan un problema. El argumento de estas funciones de columna, la columna PROMEDIO, es, a su vez, el resultado de una funcin de columna. La consulta verdadera que se solicita a SQL es:
SELECT OFICINA_REP, MIN(AVG(IMPORTE), FROM REPRESENTANTES, PEDIDOS MAX{AVG(IMPORTE))
412

GROUP BY NOMBRE_REP, EMPRESA NOMBRE_REP Bruno Arteaga Bruno Arteaga Daniel Ruidrobo Daniel Ruidrobo Daniel Ruidrobo Len Freire Len Freire Len Freire EMPRESA
Acme JCP S.A. Filas Henche " Lpez bero & Sagaz Mejorada Sistemas Orin Lt.d. Zet.a Producciones
Captulo 14: Vistas
413
WHERE NUM_EMPL = REP

GROUP BY REP
GROUP BY OFICINA_REP
SUM ( IMPORTE l
Esta consulta es ilegal debido a !as dos clusulas GROUP BY y las funciones de columna anidadas. Por desgracia. como muestra este ejemplo, una instruccin SELECT agrupada perfectamente razonable puede, de hecho, provocar un error si una de las tablas fuente resulta ser una vista de agrupacin. No hay m'UJcra de prever
esta situacin; slo hay que comprender el motivo del error cuando SQL]o comunique.
3S.582,OO 3.745,OO 3.978,OO lS0,OO 22.500,OO 3.608,00 7.100,OO 47.925,OO
Vistas de reunin
Uno de los motivos ms frecuentes de empleo de las vistas es la simplificacin de las consultas a varias tablas. Al especificar una consulta a dos o tres tablas en la definicin de la vista. se puede crear una vista de reunin que extrae los datos de dos .0 tres tablas diferentes y presenta ~l resultado de la consulta como una sola tabla virtual. Una vez definida la vista, se puede realizar a menudo una consulta de una sola tabla a la vista para solicitudes que, de otro modo, exigiran una reunin de dos o tres tablas cada una. Por ejemplo. supngase que Samuel Clavel, el vicepresidente de ventas, ejecuta a menudo consultas a la tabla PEDIDOS de la base de datos de ejemplo. Sin embargo, a Samuel no le gusta trabajar con los nmeros de cliente ni de empleado. En vez de eso, le gustara poder utilizar una versin de la tabla PEDIDOS que tuviera nombres en lugar de nmeros. A continuacin se ofrece una vista que satisface las necesidades de Samuel: Obsrvese que esta consulta es una instruccin SELEeT de una sola tabla, que es considerablemente ms sencilla que la instruccin SELECT de tres tablas equivalente para las tablas fuente:
SELECT NOMBRE, EMPRESA, SUM(IMMPORTE) FROM REPRESENTANTES, PEDIDOS, CLIENTES WHERE REP : NUM_EMPL AND CLIENTE : NUM_CLI GROUP BY NOMBRE, EMPRESA
De manera parecida, resulta fcil generar un informe de los pedidos de mayor tamao, que muestra quines los formularon y quines los tramitaron, con esta consulta a la vista:
Crear una vista de la tabla

CREATE VIEW SELECT FROM WHERE
PEDIDOS
con nombres en lugar de nmeros.

IMPORTE) AS
Mostrar los pedidos actuales de mayor tamao, ordenados por impone.

SELECT FROM WHERE aRDER EMPRESA EMPRESA, IMPORTE, NOMBRE_REP INFO_PEDIDOS IMPORTE> 20000.00 BY IMPORTE DESC IMPORTE NOMBRE_REP 45.000,OO 31.S00,OO 31.3S0,OO 27.S00,OO 22.S00,OO 22.S00,OO Len Freire Samuel Clavel Neus AzcArate Bruno Arteaga Toms Saz Daniel Ruidrobo
INFO_PEDIDOS (NUM_PEDIDO, EMPRESA, NOMBRE_REP, NUH_PEDIDO, EMPRESA, NOMBRE, IMPORTE PEDIDOS, CLIENTES, REPRESENTANTES CLIENTE : NUH_CLI ANO REP : NUM_EMPL
Esta vista viene definida por una reunin de tres tablas. Al igual que con las vistas de agrupacin, el procesamiento necesario para crear la ilusin de una tabla virtual para esta vista es considerable. Cada fila de la vista se obtiene de una combinacin de una fila de la tabla PEDIDOS. una fila de la tabla CLIENTES y una fila de la tabla REPRESENTANTES. Aunque tiene una definicin relativamente compleja, esta vista puede ofrecer algunas ventajas reales. A continuacin se ofrece una consulta a la vista que genera un infonne de los pedidos. agrupados por representantes:
Zeta Producciones J.P. Sotoca Chen Asociados Acme Ace Internacional bero & Sagaz
Mostrar los pedidos totales actuales de cada empresa por representante.

SELECT NOMBRE_REP, EMPRESA, FROM INFO_PEDIDOS SUM{IMPORTE)
La vista hace ms facd comprobar lo que ocurre en la consulta que si se expresara en la reunin de tres tablas equivalente. Por supuesto, el SGBD debe trabajar lo mismo para generar el resultado de la consulta de una sola tabla a la vista que para generar el resultado de la consulta de tres tablas equivalente. De hecho, el SGBD debe llevar a cabo un poco ms de trabajo para tratar la consulta a la vista. Sin embargo, para el usuario humano de la base de datos. resulta mu-
414
Captulo 14: Vistas
415
eho ms sencillo escribir y comprender la consulta a una sola tabla que hace referencia a la vista.
Definir una vista que contenga datos resumidos de los pedidos de cada representante.
CREATE VIEW PEDIDos_paR_REPRESENTANTE (QUIEN, CUANTOS, TOTAL, MINIMO, MAXIMO, PROMEDIO) AS SELECT REP, COUNT(*l, SUM(IMPORTEj, MIN(IMPORTE) , MAX(IMPORTE) , AVG(IMPORTEl FROM PEDIDOS GROUP BY REP
Actualizacin de vistas
Qu significa insertar una fija de datos en una vista, eliminar una fila de una vista o actualizar una fila de una vista? Para algunas vistas, estas operaciones pueden traducirse obviamente en operaciones equivalentes de las tablas fuente de la vista. Por ejemplo, considrese nuevamente la vista RE PESTE, definida anteriormente en este captulo:
Crear una vista que muestre los representantes de la regin Este.

CREATE VIEW REPESTE AS SELECT FROM REPRESENTANTES WHERE OFICINA_REP IN (11, 12, 13)
Se trata de una vista horizontal directa, obtenida a partir de una sola tabla fuente. Como puede verse en la Figura 14.5, tiene sentido hablar de la insercin de una fila en esta vista; significa que la fila nueva debe insertarse en la tabla REPRESENTANTES subyacente de la que se deriva. Tambin tiene sentido eliminar una fila de la vista REPESTE; eliminara la fila correspondiente de la tabla REPRESENTANTES. Finalmente, tiene sentido la actualizacin de una fila de la vista REPESTE; actualizara la fila correspondiente de la tabla REPRESENTANTES. En cada caso, la accin puede llevarse a cabo contra la fila correspondiente de la tabla fuente, conservando la integridad de la tabla fuente y de la vista. No obstante, considrese la vista de agrupacin PEDIDOS_POR_REPRESENTANTE, tal y como se defini anteriormente en el apartado Vistas de agrupacin:
No existe una correspondencia biunvoca entre las filas de esta vista y las filas de la tabla PEDIDOS subyacente, por lo que no tiene sentido hablar de insertar, eliminar ni actualizar filas de esta vista. La vista PEDIDOS~POR_REPRESENTANTE no es actualizable; se trata de una vista de slo lectura. Las vistas RE PESTE y PEDIDos_paR_REPRESENTANTE son dos ejemplos extremos en cuanto a la complejidad de sus definiciones. Hay vistas ms complejas que REPESTE en las que sigue teniendo sentido actualizar la vista, y hay vistas menos complejas que PEDIDOS_POR_REPRESENTANTE en las que las actualizaciones no tienen sentido. De hecho, las vistas que pueden y no pueden actualizarse han sido un importante problema de investigacin sobre las bases de datos relacionales a lo largo de los aos.
Actualizaciones de vistas y el estndar ANSI/ISO

El estndar ANSI/ISO de SQLI especifica las vistas de las de datos que proclaman su cumplimiento del estndar que deben ser actualizables. Segn el estndar, las vistas pueden actualizarse si las consultas que las definen cumplen todas estas restricciones: No se debe especificar DISTINCT; es decir, no se deben eliminar las filas duplicadas del resultado de la consulta. La clusula FROM slo debe especificar una tabla actualizable; es decir, la vista debe tener una sola tabla fuente para la que el usuario ha de contar con los privilegios necesarios. Si la tabla fuente es, a su vez, una vista, entonces esa vista debe cumplir estos criterios. Cada elemento de seleccin debe ser una referencia de columna sencilla; la lista se seleccin no puede contener expresiones, columnas calculadas ni funciones de columna. La clusula WHERE no debe incluir ninguna subconsulta; slo pueden aparecer condiciones de bsqueda sencillas fila a fila. La consulta no debe incluir ninguna clusula GROUP BY ni HAVING. El concepto fundamental tras estas restricciones es ms sencillo de recordar que las propias reglas. Para que las vistas sean actualizables, el SGBD debe poder realizar un seguimiento de todas las filas de la vista hasta su fila fuente de la tabla fuente. De mane-
ba~
Ista REPRESENTANTES NUM EMPL NOMBRE Vista REPESTE

NUM
EDAD
37 31
46 52 33
EMPL NOMBRE
105 109 106 104 101 103
Bruno Arteaga Mana JlInenez _ Samuel Clavel Bernardo Sanchez Damel RUldrobo Pablo Cruz -
UPDATE
UPDATE DELETE INSERT
~INSERT
105 109 102 106
ID'
101 110 108 103 107
Bruno Arteaga Mara Jimnez Susana Santos Samuel Clavel Bernardo snchez Daniel Ruidrobo Toms Saz Len Freire Pablo Cruz Neus Azcrate
I(
45
41 62 29 49
If
Figura 14.5.
Actualizacin de datos mediante una vista.
416
Captulo 14: Vistas
417
fa parecida, el SGBD debe poder realizar un seguimiento cada columna que haya que actualizar hasta su columna fuente en la tabla fuente. Si la vista supera esta prueba, es posible definir operaciones INSERT, DELETE Y UPDATE con significado para la vista en trminos de la tabla fuente.
Comprobacin de las actualizaciones en las vistas

(CHECK OPTION) Si se define una vista mediante una consulta que incluye una clusula WHERE, slo las filas que cumplan la condicin de bsqueda son visibles en la vista. Puede que otras filas estn presentes en las tablas fuentes de las que se obtiene la vista, pero no son visibles mediante la vista. Por ejemplo, la vista RE PESTE, que ya se describi en el apartado Vistas horizontales de este captulo, slo contiene las filas de la tabla REPRESENTANTES con determinados valores de la columna OFICINA_REP:
Actualizaciones de vistas en productos

SaL comerciales
Las reglas del estndar SQLl sobre las actualizaciones de las vistas son muy restrictivas. Muchas vistas se pueden actualizar en teora, pero no satisfacen todas las restricciones. Adems, algunas vistas pueden admitir algunas de las operaciones de actualizacin, pero otras no, y algunas vistas pueden admitir actualizaciones de ciertas columnas, pero no de otras. La mayor parte de las implementaciones comerciales de SQL tienen reglas de actualizacin de las vistas que resultan considerablemente ms permisivas que el estndar de SQL1. Por ejemplo, considrese esta vista:
Crear una vista que muestre los representantes de la regin Este.

CREATE VIEW REPESTE AS SELECT FROM REPRESENTANTES WHERE OFICINA_REP IN (11,
12, 13)
Se trata de una vista actualizable para la mayor parte de las implementaciones comerciales de SQL Se puede aadir un nuevo representante con esta instruccin
IHEH:
INSERT INTO RE PESTE (NUM_EMPL, NOMBRE, OFICINA_REP, VALUES (113, 'Jacobo Rent', 11, 43, 0.00) EDAD,
Crear una vista que muestre las ventas, la cuota y la diferencia entre las dos para cada representante.
CREATE VIEW RENDIMIENTO_REPRESENTANTES SELECT NUM_EMPL, VENTAS, FROM REPRESENTANTES CUOTA, (NUM_EMPL, VENTAS, DIFERENCIA) AS (VENTAS - CUOTA) CUOTA,
(
VENTAS)
El SGBD aadir la fila nueva a la tabla REPRESENTANTES subyacente, y la fila ser visible mediante la vista REPESTE. Pero considrese lo que ocurre cuando se aade un representante nuevo con la instruccin INSERT:
INSERT INTO REPESTE (NUM_EMPL, NOMBRE, OFICINA_REP, VALUES (l14, 'Francisco Ruiz', 21, 47, 0.00) EDAD, VENTAS)
El estndar SQL1 prohbe las actualizaciones de esta vista, ya que su cuarta columna es una columna calculada. No obstante, obsrvese que cada fila de la vista puede seguirse hasta una sola fila de la tabla fuente (REPRESENTANTES). Por este motivo, DB2 (y otras implementaciones comerciales de SQL) permite las operaciones DELETE en esta vista. Adems, DB2 permite las operaciones UPDATE de las columnas NUM_EMPL, VENTAS Y CUOTA porque se obtienen directamente a partir de la tabla fuente. Slo la columna DIFERENCIA no se puede actualizar. DB2 no permite la instruccin INSERT para la vista porque la insercin de valores en la columna DIFERENCIA no tendra ningn sentido. Las reglas concretas que determinan si una vista puede actualizarse varan de una marca de SGBD a otra, y suelen ser bastante detalladas. Algunas vistas, como las basadas en consultas de agrupacin, no pueden actualizarse en ningn SGBD porque las operaciones de actualizacin, sencillamente, no tienen sentido. tras vistas pueden ser actualizables en una marca de SGBD, parcialmente actualizables en otra y no actualizables en una tercera. El estndar SQL2 reconoci esto e incluye una definicin ms amplia de las vistas actualizables junto con una gran posibilidad de variacin entre las marcas de SGBD. La mejor manera de aprender sobre la posibilidad qe actualizacin en cada SGBD es consultar el manual de usuario o experimentar con diferentes tipos de vistas.
Se trata de una instruccin de SQL perfectamente legal, y el SGBD insertar una nueva fila en la tabla REPRESENTANTES con los valores de las columnas especificados. Sin embargo, la fila recin insertada no cumple la condicin de bsqueda de la vista. El valor (21) de su columna OFICINA_REP especifica la oficina de Len, que est en la regin Oeste. En consecuencia, si se ejecuta esta consulta inmediatamente despus de la instruccin INSERT:
SELECT NUM_EMPL, FROM RE PESTE NUM_EMPL NOMBRE 105 109 106 104 101 103 Bruno Arteaga Mara Jimnez Samuel Clavel Bernardo Snchez Daniel Ruidrobo Pablo Cruz NOMBRE, OFICINA_REP
OFICINA_REP
13
11 11 12 12 12
418
Captulo 14: Vistas
419
la fila recin aadida no aparece en la vista. Lo mismo ocurre si se modifica la asignacin de oficina de alguno de los representantes que se hallan en la vista. Esta instruccin UPDATE:
UPDATE RE PESTE
SET OFICINA_REP = 21 WHERE NUM_EMPL = 104
modifica una de las columnas de la fila de Bernardo Snchez y hace que desaparezca inmediatamente de la vista. Por supuesto, las dos filas desaparecidas aparecen en una consulta a la tabla subyacente:
SELECT NUM_EMPL, NOMBRE, FROM REPRESENTANTES NUM_EMPL NOMBRE
105 Bruno Arteaga 13
OFICINA_REP
109 102 106 104 101 110 108 103 107 114
Mara Jimnez Susana Santos Samuel Clavel

Bernardo Snchez Daniel Ruidrobo Toms Saz Len Freire Pablo Cruz Neus Azcrate Francisco Ruiz
11 21 11 21 12
NULL
21 12 22
21
cin. Esta opcin se aplica cuando se crea la vista, y su definicin no se basa en una tabla subyacente, sino en una o ms vistas. Las definiciones de estas vistas subyacentes podran, a su vez, basarse en otras vistas, etc. Cada una de las vistas subyacentes podran tener especificada la opcin de comprobacin. Si se crea la nueva vista WITH CASCADED CHECK OPTION, cualquier intento de actualizarla hace que el SGBD descienda por toda la jerarqua de definiciones de vistas en la que se basa y procese la opcin de comprobacin para cada vista en la que est especificada. Si se crea la nueva vista WITH LOCAL CHECK OPTION, el SOBD slo verifica esa vista; las vistas subyacentes no se verifican. El estndar SQL2 especifica CASCADED como valor predeterminado, si se emplea la clusula WITH CHECK OPTION sin especificar LOCAL ni CASCADEO. Probablemente quede claro de esta discusin que la opcin de comprobacin puede aadir una sobrecarga . . i~nificativa a las operacionSIsERT y UPDATE, especialmente si se actualizan \ islas definidas con base en varias capas de definiciones de vistas subyacentes. No obstante, la opcin de comprobacin desempea un papel importante en la garanta de la integridad de la base de datos. Despus de todo, si se pretenda aplicar la actualizacin a datos no visibles mediante la vista o intercambiar de hecho una fila de datos entre dos vistas, lgicamente, la actualizacin debe hacerse mediante una vista o tabla base subyacente. Cuando se crea una vista actualizable como parte de un esquema de seguridad, casi siempre resulta buena idea especificar la opcin de comprobacin. Evita que las modificaciones hechas a travs de la vista afecten a datos que, para empezar, no estn accesibles para el usuario.
El hecho de que las filas desaparezcan de la vista como consecuencia de una instruccin INSERT o UPDATE resulta desconcertante, como mnimo. Probablemente se desee que el SOBD detecte y evite que este tipo de INSERT o de UPOATE tenga lugar mediante esta vista. SQL permite especificar este tipo de verificacin de integridad para las vistas creando la vista con una opcin de comprobacin (Check option). La opcin de comprobacin se especifica en la instruccin CREATE VIEW, como puede verse en esta redefinicin de la vista REPESTE:
CREATE VIEW SELECT FROM WHERE WITH CHECK REPESTE AS REPRESENTANTES OFICINA_REP IN OPTION
Eliminacin de vistas
(DROP VIEW)
(11,
12,
13)
Cuando se solicita la opcin de comprobacin para una vista, SQL comprueba de manera automtica cada operacin INSERT y UPDATE de la vista para asegurarse de que las filas resultantes cumplen el criterio de bsqueda de la definicin de la vista. Si una fila insertada o modificada no cumpliera la condicin de bsqueda, la ... y la operacin no se llevara a cabo. instruccin INSERT o UPDATE fa El estndar SQL2 especifica un perfeccionamiento ms para la opcin de comprobacin: la opcin de aplicacin CASCAOED o LOCAL de la opcin de comproba-
Recurdese que el estndar SQLI trataba al lenguaje de definicin de datos de SQL como una especificacin esttica de la estructura de las bases de datos, incluidas sus tablas y sus vistas. Por este motivo, el estndar SQLl no ofreca la posibilidad de descartar las vistas cuando ya no se necesitaban. No obstante, todas las marcas principales de SGBD ofrecen esta posibilidad desde hace algn tiempo. Dado que las vistas se comportan corno las tablas y ninguna vista puede tener el mismo nombre que una tabla, algunas marcas de SOBD tambin utilizaban la instruccin DROP TABLE para descartar vistas. Otras implementaciones de SQL ofrecan una instruccin OROP VIEW independiente. El estndar SQL2 fonnaliz el soporte del descarte de las vistas mediante la instruccin OROP VIEW. Tambin ofrece el control detallado de lo que sucede cuando los usuarios intentan descartar una vista y la definicin de otra vista depende de ella. Por ejemplo, supngase que se han creado dos vistas de la tabla REPRESENTANTES mediante estas dos instrucciones CREATE VIEW:
CREATE VIEW RE PESTE AS SELECT PROM REPRESENTANTES WHERE OFICINA_REP IN
(11,
12, 13)
420
Captulo 14: Vistas
421
CREATE VIEW REPNAVARRA AS SELECT

FROM REPESTE
WHERE OFICINA_REP :
11
A modo de ejemplo, se define la vista REPNAVARRA e~ trminos de la vista aunque tambin se podra haber definido en trminos de la tabla subyacente. Segn el estndar SQL2, la siguiente instruccin DROP VIEW elimina de la base de datos las dos vistas:
RE PESTE,
DROP VIEW RE PESTE CASCADE
La opcin CASCADE indica al SGBD que no slo debe eliminar la vista citada, sino tambin todas las vistas que dependan de su definicin. Por el contrario, esta instruccin OROP VIEW:
DROP VIEW EASTREPS RESTRICT
falla con un mensaje de error, ya que la opcin RESTRICT indica al SOBD que s610 debe eliminar la vista si ninguna otra depende de ella. Esto ofrece una precaucin aadida contra los efectos secundarios no deseados de las instrucciones DROP VIEW. El estndar SQL2 exige que se especifique RESTRICT o CASCADE. Pero muchos productos comerciales de SQL admiten una versin de la instruccin DROP VIEW, sin necesidad de que se especifique una opcin de manera explcita, en aras de la compatibilidad con versiones anteriores de sus productos distribuidas antes de la publicacin del estndar SQL2. El comportamiento concreto de las vistas dependientes depende, en este caso, de cada marca de SGBD.
SGBD lleva a cabo la consulta solicitada contra la tabla temporal para obteer el resultado solicitado. Cuando ha concluido el procesamiento de la consulta, el SOBO descarta la tabla temporal. La Figura 14.6 muestra este proceso de materializacin. Evidentemente, la materializacin del contenido de las vislas puede ser una operacin que suponga una elevada sobrecarga. Si la carga de trabajo habitual de una base de dalaS contiene muchas consultas que exigen la materializacin de vistas, puede reducirse espectacularmente la capacidad total de flujo del SGBD. Para afrontar este problema algunos productos comerciales de SGBD incluyen las vistas materializadas. Cuando se define una vista como vista materializada, el SOBD ejecuta una vez la consulta que define la vista (generalmente, cuando se define la visla materializada), almacena el resultado (es decir, los datos que aparecen en la vista) en la base de datos, y luego mantiene de manera permanente esta copia de los datos de la vista. Para conservar la exactitud de los datos de la vista materializada, el SOBD debe examinar de manera automtica\cada cambio de los datos de las tablas fuente subyacentes y realIzar las modificacibhes en los datos de la vista materializada. Cuando el SGBD debe procesar una consulta sobre la vista materializada ya tiene los datos a mano y puede procesarla con gran eficiencia. La Figura 14.7 muestra la operacin del SGBD con vistas materializadas. Las vistas materializadas ofrecen un balance entre la eficiencia de las actualizaciones de los datos contenidos en la vista y la -eficiencia de las consultas de los
--
SGBO
Tablas base
Vistas materializadas *
Conceptualmente, una vista es una tabla virtual de la base de datos. Los datos de las filas y columnas de la vista no se almacenan fsicamente en la base de datos: se obtienen de datos reales de las tablas fuente subyacentes. Si la definicin de la vista es relativamente sencilla (por ejemplo, si la vista es un subconjunto sencillo . de filas y columnas de una sola tabla, o una reunin sencilla basada en relaciones de claves externas), resulta bastante sencillo para el SGBD la traduccin de las operaciones de la base de datos sobre la vista en operaciones sobre las tablas subyacentes. En esta situacin, el SGBD llevar a cabo la traduccin sobre la marcha, operacin a operacin, como procesa las consultas o actualizaciones de la base de datos. En general, las operaciones que actualizan la base de datos a travs de una vista (operaciones INSERT, UPDATE o DELETE) se ejecutan siempre de esta manera -traduciendo la operacin en una o varias operaciones sobre las tablas fuente. Si la definicin de la vista es ms compleja, puede que el SGBD necesite materializar realmente la vista para llevar a cabo una consulta sobre ella. Es decir, el SGBD llevar realmente a cabo la consulta que define la vista y almacenar el resultado de esa consulta en una tabla temporal de la base de datos. Entonces, el
SELEC" vista FROH
P".', Crear una tabla lemporal que contenga los datos
!'iF~fi~" '~
Paso 2: Resultado de fa consulta~ Responder a la consulta .. a partir de los datos de la tria temporal
Paso 3: Eliminar la tabla temporal
Figura 14.6.
Materializacin de vistas para el procesamiento de consultas.
422
Captulo 14: Vistas
423
SGBD
Tabla base
UPDATE
SELECT
FROM
vista
Vista
\o~
'3\\''3 \,,0\\.'0
e'
INSERT
materializada
Actualizacione
Paso 1:
UPDATE
ActualizaCio nes
Responder a la consulta
a partir de Jos datos de la vista materializada
Las vistas son tablas virtuales definidas por una consulta. Parece que las vistas contienen filas y columnas de datos, igual que las tablas verdaderas, pero los datos visibles mediante las vistas son, en realidad, el resultado de la consulta. Las vistas pueden ser subconjuntos sencillos de filas o columnas de una sola tabla, pueden resumir tablas (vistas agrupadas) o extraer sus datos de dos o ms tablas (vistas de reunin). Se puede hacer referencia a las vistas en las instrucciones SELECT, INSERT, DELETE o UPDATE igual que a las tablas autnticas. Sin embargo, las vistas ms complejas no pueden actualizarse; se trata de vistas de slo lectura. Las vistas suelen emplearse para simplificar la estructura aparente de las bases de datos, para simplificar consultas y para proteger ciertas filas o columnas de un acceso no autorizado. Las vistas materializadas pueden mejorar la eficiencia del procesamiento de la base de datos en situaciones en las que hay un elevag,o'volumen de actividad de consultas y una actividad de actualizaciones rlativamente reducida.
Figura 14.7.
Operacin con vistas materializadas.
datos de la vista. En las vistas no materializadas las actualizaciones de las tablas fuente de la vista no se ven afectadas por la definicin de la vista; siguen adelante a la velocidad de procesamiento normal del SGBD. Sin embargo, las consultas de las vistas no materializadas resultan mucho menos eficientes que las consultas de las tablas normales de la base de datos, ya que el SGBD debe realizar mucho trabajo sobre la marcha para procesar las consultas. Las vistas materializadas invierten este equilibrio de trabajo. Cuando se define una vista materializada, las actualizaciones de las tablas fuente de la vista resultan mucho menos eficientes que las actualizaciones de las tablas normales de la base de datos, ya que el SGBD debe calcular el efecto de esas actualizaciones y modificar la vista materializada a la misma velocidad que las consultas de las tablas verdaderas de la base de datos, ya que la vista materializada se representa en la base de datos de la misma manera que las tablas verdaderas. Por tanto, las vistas materializadas resultan ms tiles cuando el volumen de actualizaciones de los datos subyacentes es relativamente pequeo y el volumen de las consultas a la vista es relativamente elevado.
Resumen
Las vistas permiten redefinir la estructura de las bases de datos, dando a cada usuario una vista personalizada de la estructura y del contenido de la base de datos:
CAPTULO
15
Seguridad en SOL
Cuando se confan los datos a un sistema de gestin de datos, la dad de los datos almacenados es una preocupacin importante. La seguridad resul~ ta de especial importancia en los SGBD basados en SQL, ya que SQL interactivo hace muy sencillo el acceso a las bases de datos. Las exigencias de seguridad de las bases de datos de produccin tpicas son muchas y variadas: Los datos de cualquier tabla deben ser accesibles a algunos usuarios, pero se debe evitar el acceso de otros usuarios. Se debe permitir que algunos usuarios actualicen los datos de una tabla concreta; a otros s6lo debe permitrseles que recuperen datos. En algunas tablas el acceso debe restringirse por columnas. Se debe negar a algunos usuarios el acceso a algunas tablas mediante SQL interactivo, pero debe permitrseles el empleo de programas de aplicacin que actualicen esas tablas. El esquema de seguridad de SQL descrito en este captulo ofrece estos tipos de proteccin para los datos de las bases de datos relacionales.
d~ases
segurj~
Conceptos de seguridad en SOL

La implementacin de un esquema de seguridad y hacer que se cumplan las restricciones de seguridad son responsabilidades del software SGBD. El lenguaje SQL define un marco general para la seguridad de la base de datos, y las instrucciones SQL se utilizan para especificar las restricciones de seguridad. El esquema de seguridad SQL se basa en tres conceptos fundamentales: Usuarios. Los aclares de la base de datos. Cada vez que el SGBD recupera, inserta, elimina o actualiza datos lo hace en nombre de algn usuario. El SGBD autoriza o prohbe cada accin en funcin del usuario que realiza la solicitud.
425
426
Captulo 15: Seguridad en SOL
427
Objetos de la base de datos. Elementos a los que se puede aplicar la proteccin de la seguridad de SQL. La seguridad suele aplicarse a las tablas y a las vistas, pero tambin se pueden proteger otros objetos, como los formularios, los programas de aplicacin y bases de datos enteras. La mayor parte de los usuarios tiene permiso para utilizar algunos objetos de la base de datos, pero se les prohibir el empleo de otros. Privilegios. Acciones que se les permite llevar a cabo a los usuarios con cada objeto de la base de datos. Puede que un usuario tenga permiso para ejecutar SELECT e INSERT en las filas de una determinada tabla, por ejemplo, pero que carezca de permiso para ejecutar DELETE o UPOATE en esa misma tabla. Puede que otro usuario tenga un conjunto diferente de privilegios. La Figura 15.1 muestra el modo en que se pueden emplear estos conceptos de seguridad en un esquema de seguridad para la base de datos de ejemplo.
Al establecer el esquema de seguridad de una base de datos se utiliza la instruccin GRANT de SQL para especificar los usuarios que tienen cada privilegio sobre cada objeto de la base de datos. Por ejemplo, a continuacin se muestra una instruccin GRANT que permite a Samuel Clavel recuperar e insertar datos en la tabla OFICINAS de la base de datos de ejemplo:
Dejar que Samuel Clavel recupere e inserle datos en la tabla

GRANT SELECT, INSERT ON OFICINAS TD SAMUEL
OFICINAS.
La instruccin GRANT especifica una combinacin de identificador de usuario objeto (la tabla OFICINAS) y privilegios (SELECT e INSERT). Una vez concedidos, los privilegios pueden cancelarse posteriormente con la instruccin
(SAMUEL), REVOKE:
Departamento de procesamiento
Retirar los privilegios concedidos anteriormente a Samuel Clavel.

Departamento de cuentas
REVOKE SELECT, INSERT
~i~
Tabla PEDIOOS
SELECT,
Acceso; \. algunas SELECT/ completo \columnas I
UPDATE
INSERT,
~~
SELECT
ON OFICINAS FROM SAMUEL
\. algunas \columnas
Len Freire, jefe de la oficina de Len

ANTES SELECT .~.
[]lITID
Disponible para todos los usuarios Acceso completo \ a todos los dalas ' \ (
Tabla CLIENTES
Tra~b~la=RE=p~RE=S=ENT~ 1-
Las instrucciones GRANT y REVOKE se describen con detalle ms adelante en este captulo, en los apartados Concesin de privilegios y Retirada de privilegios.
aJg~n/ fila
Identificadores de usuario
Cada usuario de una base de datos basada en SQL suele tener asignado un identificador de usuario, un nombre corto que identifica al usuario ante el software del SGBD. Los identificadores de usuario se hallan en el corazn de la seguridad de SQL. Cada instruccin de SQL ejecutada por el SGBD se lleva a cabo en nombre de un identificador de usuario concreto. El identificador de usuario determina si el SGBD autoriza la ejecucin de la instruccin o la prohibe. En las bases de datos de produccin, los identificadores de usuario los asigna el administrador de la base de datos. Puede que cada base de datos de las computadoras personales tenga un solo identificador de usuario, que identifica al usuario que cre y posee la base de datos. En as bases de datos de propsito especial (por ejemplo, las diseadas para incrustarse dentro de las aplicaciones o de los sistemas de propsito especial) puede que no haga falta la sobrecarga adicional asociada con la seguridad de SQL. Estas bases de datos suelen operar como si s610 hubiera un identificador de usuario. En la prctica, las restricciones a los nombres que pueden escogerse como identificadores de usuario varan de implementacin a implementacin. El estndar SQLl permita identificadores de usuario de hasta dieciocho caracteres y exiga que fueran nombres de SQL vlidos. En algunos sistemas SGBD de centrales de
LEW
Tabla OFICINAS Acceso a todos los datos
'-J'-_-"--_-' filas
algUnaS~
Bernardo Snchez, jefe de la oficina de Castelln
SE~
t!
comPleto~i~
Samuel Clavel VP ventas
Gonzalo Walker VP marketing
Figura 15.1.
Esquema de seguridad para la base de datos de ejemplo.
428
429
computacin, los identificadores de usuario no pueden tener ms de ocho caracteres. En Sybase y SQL Server, los identificadores de usuario pueden tener hasta treinta caracteres. Si la portabilidad es importante, es conveniente limitar los identificadores de usuario a ocho caracteres o menos. La Figura 15.2 muestra a varios usuarios que necesitan tener acceso a la base de datos de ejemplo y se les asignan identificadores de usuario tpicos. Obsrvese que a todos los usuarios del departamento de procesamiento de pedidos puede asignrseles el mismo identificador de usuario, ya que han de tener los mismos privilegios en la base de datos. El estndar ANSI/ISO de SQL utiliza el trmino identificador de autorizacin en lugar de identificador de usuario, y este trmino se encontrar ocasionalmente en otra documentacin sobre SQL. Tcnicamente, identificador de autorizacin es un trmino ms exacto, ya que el papel del identificador es determinar las autorizaciones o privilegios en la base de datos. Hay situaciones, como en la Figura 15.2, en que tiene sentido asignar el mismo identificador de usuario a diferentes usuarios. En otras situaciones, puede que una sola persona utilice dos o tres identificadores de usuario. En las bases de datos de produccin, los identificadores de autorizacin pueden asociarse con programas y grupos de programas, ms que con usuarios humanos. En cada una de estas situaciones, identificador de autorizacin es un trmino ms exacto y que lleva a menos confusin que identificador de usua-
rio. No obstante, la prctica ms habitual es asignar un identificador de usuario diferente a cada persona, y la mayor parte de los SGBD basados en SQL utilizan el trmino identificador en su documentacin.
Autenticacin de usuarios
Departamento de procesamiento de pedidos
Departamento de cuentas
[~~~J
Identificador de usuario: USUARIOPP Directores de oficina
[JI]
Identificador de usuario: USUARIOCU Vicepresidentes Samuel Clavel VP ventas Identificador de usuario: SAMUEL
Len Freire Identificador de usuario: LEN
Bernardo Snchez Identificador de usuario: BERNARDO
Gonzalo Walker VP marketing Identificador de usuario: GONZALO
El estndar SQL especifica que los identificadores de usuario proporcionan la seguridad de la base de datos; no obstante, el mecanismo concreto para la asociacin entre Jos identificadores de usuario y las instrucciones de SQL es ajeno al mbito del estndar, ya que se puede tener acceso a las bases de datos de muchas maneras diferentes. Por ejemplo, cuando se escriben instrucciones de SQL en una utilidad de SQL interactivo, hay que establecer el modo en que el SGBD determina el identificador de usuario que est asociado con cada instruccin. Si se utiliza una entrada de datos basada en formularios o un programa de consulta, hay que establecer el modo en que el SGBD determina el identificador de usuario. En los servidores de bases de datos, puede preverse un programa de generacin de informes para que se ejecute cada tarde a una hora predeterminada, para lo cual hay que establecer el identificador de usuario, situacin en la)que no hay ningn usuario humano. Finalmente, hay que establecer cmo se manejan los identificadores de usuario cuando se tiene acceso a la base de datos mediante una red, en la que el identificador de usuario del sistema en que se trabaja de manera activa puede ser diferente del identificador de usuario establecido en el sistema en que reside la base de datos. La mayor parte de las implementaciones comerciales de SQL establece un identificador de usuario para cada sesin de la base de datos. En SQL interactivo la sesin comienza cuando se inicia el programa de SQL interactivo, y dura hasta que se sale del programa. En los programas de aplicacin que utilizan SQL para programacin, la sesin comienza cuando el programa de aplicacin conecta con el SGBD, y concluye cuando termina el programa de aplicacin. Todas las instrucciones de SQL utilizadas durante la sesin se asocian con el identificador de usuario especificado para la sesin. Generalmente hay que proporcionar tanto un identificador de usuario como la contrasea asociada al comienzo de cada sesin. El SGBD comprueba la contrasea para asegurarse de que, en efecto, se est autorizado a utilizar la identificador de usuario que se proporciona. Aunque los identificadores de usuario y las contraseas son frecuentes en la mayor parte de los productos de SQL, las tcnicas concretas empleadas. para especificar el identificador de usuario y la contrasea varan de un producto a otro. Algunas marcas de SGBD, especialmente las que estn disponibles en muchas plataformas de sistemas operativos diferentes, implementan su propia seguridad de identificador de usuario y contrasea. Por ejemplo, cuando se utiliza el programa de SQL interactivo de Oracle, denominado SQLPLUS, hay que especificar un nombre de usuario y la contrasea asociada en el comando que inicia el programa, como puede verse a continuacin:
SQLPLUS SANTI/TIGRE
Figura 15.2.
Asignacin de identificadores de usuario para la base de datos de
ejemplo.
--L
430
431
El programa interactivo de SQL de Sybase. denominado ISQL. tambin acepta un nombre de usuario y una contrasea, con este formato de comando:
ISQL IUSER=SANTI /PASSWORD=TIGRE
Grupos de usuarios
Las grandes bases de dalos de produccin suelen tener grupos de usuarios con necesidades parecidas. En la base de datos de ejemplo, las tres personas del departamento de procesamiento de pedidos forman un grupo de usuarios natural, igual que las dos personas del departamento de cuentas. Dentro de cada grupo todos los usuarios tienen necesidades idnticas de acceso a los datos y deben tener idnticos privilegios. De acuerdo con el esquema de seguridad de SQL de ANSI/ISO, se pueden manejar de dos maneras grupos de usuarios con necesidades parecidas: Se puede, asignar el mismo identificador de usuario a todas las personas de un grupo, como puede verse en la Figura 15.2. Este esquema simplifica la administracin de la seguridad, ya que permite especificar los privilegios de acceso a datos una sola vez par el nico identificador de usuario. No obstante, con este esquema, las persa as que comparten el identificador de usuario no pueden distinguirse unas de tras en las pantallas de los operadores del sistema ni en los informes del SGBD. Se puede asignar un identificador de usuario diferente a cada persona del grupo. Este esquema permite diferenciar los usuarios en los informes generados por el SGBD y permite establecer privilegios diferentes para cada usuario posteriormente. No obstante, hay que especificar individualmente los privilegios de cada usuario, 10 que hace la administracin de la seguridad tediosa y susceptible de errores.
En cada caso el SGBD valida el identificador de usuario (SANTI) y la contrasea (TIGRE) antes de comenzar la sesin interactiva de SQL. Otras muchas marcas de SGBD, incluidas Ingres e Informix, utilizan los nombres de usuario del sistema operativo de la computadora anfitriona como identificadores de usuario de la base de datos. Por ejemplo, cuando se inicia la sesin en un sistema informtico basado en UNIX, hay que proporcionar un nombre de usuario y una contrasea vlidos para UNIX para obtener acceso. Para iniciar la utilidad de SQL interactivo de logres basta con dar el comando:
ISQL BnVENTA5
donde BDVENTAS es el nombre de la base de datos de Ingres que se desea emplear. Ingres obtiene de manera automtica el nombre de usuario de UNIX y lo convierte en el identificador de usuario de lngres para esa sesin. Por tanto, no hace falta especificar un identificador de usuario y una contrasea diferentes. El SQL interactivo de DB2, que se ejecuta bajo MVSrrSO, utiliza una tcnica parecida. El nombre de inicio de sesin de TSO se transforma automticamente en el identificador de usuario de DB2 para la sesin de SQL interactivo. La seguridad de SQL tambin se aplica al acceso mediante programacin a las bases de datos, por lo que el SGBD debe determinar y autentificar el identificador de usuario de cada programa de aplicacin que intente tener acceso a la base de datos. Una vez ms, las tcnicas y reglas para el establecimiento del identificador de usuario varan de una marca de SGBD a otra. Para los programas de utilidades ms utilizados, como los de introduccin de datos o los de consulta, resulta frecuente que el programa pida al usuario el identificador de usuario y la contrasea al comienzo de la sesin, mediante un cuadro de dilogo en la pantalla. Para los programas ms especializados o escritos a medida, el identificador de usuario puede resultar evidente a partir de la aplicacin que hay que ejecutar y venir indicado en el programa. El estndar SQL2 tambin permite que los programas utilicen identificadores de autorizacin asociados con conjuntos especficos de instrucciones de SQL (denominados mdulos), en lugar de los identificadores de usuario de las personas que ejecuten el programa. Con este mecanismo se puede otorgar a un programa la posibilidad de llevar a cabo operaciones muy concretas en la base de datos en nombre de muchos usuarios diferentes, aunque esos usuarios no se hallen autorizados de otro modo para tener acceso a los datos objetivo. Se trata de una posibilidad conveniente que est abrindose camino en las principales implementaciones de SQL. Las caractersticas concretas de la seguridad de SQL para los programas de acceso a la base de datos se describen en el Captulo 17, que trata el SQL para programacin.
El esquema que se escoja depende de los equilibrios entre la base de datos concreta y la aplicacin. Varias marcas de SGBD, incluidas Sybase y SQL Server, ofrecen una tercera alternativa para el tratamiento de los grupos de usuarios parecidos. Albergan identificadores de grupo, que identifican los grupos de identificadores de usuario relacionados. Se pueden conceder privilegios tanto a los identificadores de usuario individuales como a los identificadores de grupo, y los usuarios pueden llevar a cabo acciones en la base de datos si lo autorizan los privilegios de su identificador de usuario o los de su identificador de grupo. Los identificadores de grupo, por tanto, simplifican la administracin de los privilegios concedidos a los grupos de usuarios. No obstante, no forman parte del estndar y puede que los diseos de bases de datos que los utilicen no sean portables a otras marcas de SGBD. DB2 tambin alberga los grupos de usuarios, pero adopta otro enfoque. Los administradores de bases de datos de DB2 pueden configurar DB2 de modo que, cuando se realice la primera conexin a DB2 y se proporcione el identificador de usuario (conocido como identificador de autorizacin primario), DB2 busque de manera automtica un conjunto de identificadores de usuario adicionales (conocidos como identificadores de autorizacin secundarios) que se puedan utilizar. Cuando DB2 comprueba posteriormente los privilegios, verifica los de todos los identificadores de autorizacin, tanto primarios como secundarios. En los grandes sistemas de lBM, los administradores de bases de datos de DB2 suelen configurar
432
433
los identificadores de autorizacin secundarios de modo que sean iguales que los nombres de los grupos utilizados por el servicio de control de acceso a recursos (Resource Access C011lrol Facility, RACF), el servicio de seguridad para grandes sistemas de IBM. Por tanto, el enfoque de DB2 proporciona de hecho identifi~ cadores de grupo, pero lo hace sin aadirlos al mecanismo de identificadores de usuario.
El privilegio DELETE permite eliminar filas de una tabla o vista. Con este privilegio se puede especificar la tabla o vista de la clusula FROM d~ una instruccin DELETE. El privilegio UPDATE permite modificar filas)de una tabla o vista. Con este privilegio se puede especificar la tabla o viJ.ta objetivo de una instruccin UPDATE. El privilegio UPDATE puede restringirse a columnas concretas de la tabla o vista, permitiendo actualizaciones de esas columnas pero impidindolas en el resto. Prcticamente todos los productos comerciales de SQL albergan estos cuatro privilegios.
Privifegios ampliados de SQL2
Objetos de seguridad
Las protecciones de la seguridad de SQL se aplican a objetos concretos contenidos en las bases de datos. El estndar SQLl especificaba dos tipos de objetos de seguridad: las tablas y las vistas. Por tanto, cada tabla y cada vista pueden protegerse individualmente. El acceso a las tablas o vistas puede permitirse para ciertos identificadores de usuario y prohibirse para otros. El estndar SQL2 ampli las protecciones de seguridad para incluir otros objetos, incluidos los dominios y los conjuntos de caracteres definidos por el usuario, y aadi un nuevo tipo de proteccin para el acceso a las tablas o vistas. La mayor parte de los productos comerciales de SQL albergan los objetos de seguridad adicionales. En las bases de datos de SQL Server, por ejemplo, los procedimientos almacenados son objetos importantes de la base de datos. El esquema de seguridad de SQL determina los usuarios que pueden crear y descartar procedimientos almacenados y los usuarios a los que se les permite ejecutarlos. En DB2 de IBM, los espacios de tablas fsicos en que se almacenan las tablas se tratan como objetos de seguridad. Los administradores de las bases de datos pueden conR ceder permiso a algunos identificadores de usuario para crear tablas nuevas en un espacio de tablas determinado, y denegrselo a otros identificadores de usuario. Otras implementaciones de SQL albergan otros objetos de seguridad. No obstante, el esquema de seguridad de SQL subyacente -de privilegios concretos aplicados a objetos determinados, concedidos o retirados mediante las mismas instrucciones de SQL- se aplica de manera casi universal.
Privilegios
El conjunto de acciones que puede llevar a cabo un usuario con un objeto de la base de datos se denomina privilegios para el objeto. El estndar SQLI especifica cuatro privilegios bsicos para tablas y vistas: El privilegio SELECT permite recuperar datos de una tabla o vista. Con este privilegio se puede especificar la tabla o vista de la clusula FROM de una instruccin o subconsulta SELECT. El privilegio INSERT permite insertar filas nuevas en una tabla o vista. Con este privilegio se puede especificar la tabla o vista de la clusula INTO de una instruccin INSERT.
El estndar SQL2 ampli los privilegios bsicos de SQLl en varias dimensiones. Aadi nuevas posibilidades a los privilegios INSERT y UPDATE de SQLl. Aadi un nuevo privilegio REFERENCES que restringe la capacidad de los usuarios para crear referencias a las tablas a partir de claves externas de otras tablas. Tambin aadi un nuevo privilegio USAGE que controla el acceso a las nuevas estructuras de las bases de datos de SQL2 de dominios, conjuntos de caracteres, secuencias de ordenacin y traducciones. Las ampliaciones de SQL2 de los privilegios INSERT y UPDATE son directas. Estos privilegios pueden concederse ahora para columnas concretas de cada tabla, en lugar de aplicarse a toda la tabla. La base de datos de ejemplo ofrece un ejemplo sencillo del modo en que esta posibilidad puede resultar til. Supngase que se quisiera conceder al director de recursos humanos la responsabilidad de insertar los empleados nuevos en la tabla REPRESENTANTES, una vez que se ha concluido el papeleo de la contratacin. El director de recursos humanos debe proporcionar el nmero de empleado, el nombre y dems informacin. Pero debera ser la responsabilidad del VP de ventas definir la columna .CUOTA de cada empleado nuevo. Los ajustes de la columna VENTAS para los empleados ya existentes se restringir de manera parecida. Con el empleo de las nuevas posibilidades de SQL2 se puede implementar este esquema concediendo al director de recursos humanos privilegios INSERT sobre las columnas correspondientes. Las dems columnas (como VENTAS y CUOTA) de los empleados recin insertados tendrn inicialmente el valor NULL. Con el privilegio UPDATE sobre las dems columnas, el VP de ventas puede definir la cuota correspondiente. Sin la posibilidad de especificar estos privilegios sobre columnas concretas habra que relajar las restricciones de acceso a las columnas o definir vistas extraas de la tabla simplemente para restringir el acceso. El estndar SQL2 no permite que se aplique el privilegio SELECT a columnas concretas, como las nuevas posibilidades INSERT y UPDATE; hay que seguir especificndolo para toda la tabla. Tericamente, esta posibilidad no se necesita realmente, ya que se puede conseguir el mismo efecto definiendo una vista de la tabla, limitando la vista a columnas concretas )j definiendo luego los privilegios correspondientes sobre la vista. No obstante, un privilegio SELECT sobre columnas con-
434
435
cretas puede ser un enfoque mucho ms directo. Conserva ms sencilla la estructura de la base de datos (menos definiciones de vistas) y concentra el esquema de seguridad ms estrictamente en un solo sitio (las instrucciones GRANT). Varias de las principales marcas de SOBD. incluidas Sybase y SQL Server, permiten especificar privilegios SELECT sobre columnas concretas, utilizando la misma sintaxis que para las instrucciones UPDATE e INSERT sobre columnas concretas. El estndar SQL2 incluye una nota que indica que se pretende considerar tambin esta posibilidad para futuras actualizaciones del estndar. El nuevo privilegio REFERENCES de SQL2 trata con un problema de seguridad de SQL ms sutil planteado por las posibilidades de las claves externas y las restricciones de comprobacin de SQL2. Empleando la base de datos de ejemplo como modelo, supngase que un empleado tiene la posibilidad de crear una tabla nueva en la base de datos (por ejemplo, una tabla que contenga informacin sobre los productos nuevos) pero no tiene acceso a la informacin sobre empleados de la tabla REPRESENTANTES. Podra suponerse que, dado este esquema de seguridad, no hay manera de que determine los nmeros de empleado utilizados ni si se ha contratado a algn empleado nuevo. No obstante, esto no es estrictamente cierto. El empleado puede crear una tabla nueva, con una columna que se defina como clave externa de la tabla REPRESENTANTES. (Recurdese que esto significa que los nicos valores legales para esta columna son los valores de la clave primaria de la tabla REPRESENTANTES --es decir, nmeros de empleado vlidos-.) Con esta nueva tabla el empleado puede intentar simplemente insertar filas nuevas con valores diferentes en la columna de la clave externa. Las instrucciones INSERT que tengan xito indicarn al empleado que ha descubierto un nmero de empleado vlido; las que fallen, representarn nmeros de empleado no vlidos. Una tabla nueva definida con una restriccin de comprobacin en una columna puede crear problemas todava ms serios. Por ejemplo, supngase que el empleado intenta ejecutar esta instruccin CREATE TABLE:
CREATE TABLE XYZ (PROBAR DINERO, CHECK ((5ELECT CUOTA FROM REPRESENTANTES WHERE TITLE = 'VP Ventas') BETWEEN 400000 AND 500000))
tiene el privilegio REFERENCES para esa columna. En las bases de datos que todava no implementan el privilegio REFERENCES pero admiten claves externas o restricciones de comprobac~n, se utiliza a ve_ces con esta funcin el privilegio SELECT. Finalmente, el estndar SQL2 especifica el privilegio USAGE para controlar el acceso a los dominios (conjuntos de valores legales para las columnas), de los conjuntos de caracteres definidos por los usuarios, de las secuencias de ordenacin y de las traducciones. El privilegio USAGE es un conmutador sencillo que permite o impide el empleo de estos objetos de las bases de datos de SQL2, por el nombre, para identificadores de usuario individuales. Por ejemplo, con el privilegio USAGE sobre un dominio, se puede definir una tabla nueva con una columna cuyo tipo de datos se defina como ese dominio. Sin el privilegio no se puede crear una definicin de columna de ese tipo. Estos privilegios estn dirigidos, sobre todo, a la simplificacin de la administracin de las grandes bases de datos corporativas que utilizan y modifican muchos equipos de desarrollo diferentes. No suelen presentar el mismo tipo de problemas de seguridad que los privilegios de acceso a tablas y columnas.
Privilegios de propiedad
Cuando se crea una tabla con la instruccin CREATE TABLE, el usuario que la crea se transforma en su propietario y recibe privilegios plenos para la tabla (SELECT, INSERT, DELETE, UPDATE y cualesquiera otros privilegios albergados por el SGBD). Los dems usuarios no tienen inicialmente ningn privilegio sobre la tabla recin creada. Si hay que concederles acceso a la tabla, hay que otorgarles privilegios de manera explcita, empleando la instruccin GRANT. Cuando se crea una vista con la instruccin CREATE VIEW, el usuario que la crea se transforma en el propietario de la vista, pero no recibe necesariamente privilegios plenos sobre ella. Para crear la vista con xito, hay que tener ya el privilegio SELECT sobre cada una de as tablas fuente de la vista; por tanto, el SGBD otorga al creador el privilegio SELECT para la vista de manera automtica. Para cada uno de los dems privilegios (INSERT, DELETE y UPDATE), el SOBO slo otorga el privilegio sobre la vista si ya se tiene ese mismo privilegio sobre todas las tablas fuente de la vista.
Otros privilegios
Debido a la restriccin de la columna vinculada con un valor de la tabla REsi esta instruccin tiene xito, significa que el VP de ventas tiene una cuota en el rango especificado. Si no tiene xito, el empleado puede seguir probando instrucciones CREATE TABLE parecidas, hasta que haya determinado la cuota correspondiente. Para eliminar este acceso clandestino a los datos, el estndar SQL2 especifica el nuevo privilegio REFERENCES. Al igual que los privilegios INSERT y UPDATE, el privilegio REFERENCES se concede para columnas concretas de la tabla. El usuario slo est autorizado a crear tablas nuevas que hagan referencia de alguna manera a una columna ya existente (por ejemplo, como objetivo de una referencia de clave externa o en una restriccin de comprobacin, como en los ejemplos anteriores) si
PRESENTANTES,
Muchos productos comerciales de SOBO ofrecen privilegios adicionales sobre tablas y vistas, adems de los privilegios bsicos SELECT, INSERT, DELETE y UPDATE. Por ejemplo, Oracle y las bases de datos de grandes sistemas de IBM albergan los privilegios ALTER e INDEX para las tablas. Los usuarios con el privilegio ALTER sobre una tabla concreta pueden utilizar la instruccin ALTER TABLE para modificar la definicin de esa tabla; los usuarios con el privilegio INDEX pueden crear un ndice para esa tabla con la instruccin CREATE INDEX. En las marcas de SOBO que no admiten los privilegios ALTER e INDEX, slo el propietario puede utilizar las instrucciones ALTER TABLE Y CREATE INDEX.
436
437
Con frecuencia se admiten privilegios adicionales para los objetos de seguridad del SGBD distintos de las tablas y las vistas. Por ejemplo, Sybase y SQL Server admiten el privilegio EXECUTE para los procedimientos almacenados, el cual determina si el usuario est autorizado a ejecutar ese procedimiento almacenado. DB2 admite, para los espacios de tablas, el privilegio USE, que determina si el usuario puede crear tablas en un espacio de tablas determinado.
USUARlOOCU
~ 1J
O
SELECT Vista INFOREP
N!Jl'l DlP'
~,
Las vistas y la seguridad en SOL

Adems de las restricciones al acceso a las tablas proporcionadas por los privilegios de SQL, las vistas tambin desempean un papel fundamental en la seguridad de SQL. Mediante una definicin cuidadosa de las vistas y otorgando a los usuarios permiso para tener acceso a las vistas, pero no a sus tablas fuente, se puede restringir de manera efectiva el acceso de los usuarios nicamente a las columnas y a las filas seleccionadas. Por tanto, las vistas ofrecen una manera de ejercer un control muy preciso de los datos que resultan visibles para cada usuario. Por ejemplo, supngase que se desea hacer cumplir esta regla de seguridad en la base de datos de ejemplo:
OFICINA...REP
'" ". '" '" lO'

lOO
102 106 110
",,1'
Bruno Arteaga
liada Jl_M:l
13
Susana santOS samu"l Clavel
Bernardo
~nche:;
Daniel Ruidrobo Tom!S Su Len Frere
Pablo Cruz
Neus Azcute
NOLL
11 21 11 12 12 12 21
'"
/'
22
",,'
,,/'/
,,,//
El personal del departamento de cuentas debe poder recuperar los nmeros de empleado, los nombres y los nmeros de oficina de la tabla REPRESENTANTES, pero no deben tener disponibles los datos de ventas ni de cuotas.
Esta regla de seguridad se puede implementar definiendo una vista de la manera siguiente:
CREATE VIEW INFOREP AS SELECT NUM_EMPL. NOMBRE, FROM REPRESENTANTES OFICINA_REP
/
",,/"
/,/'" //'
,,/"
NUlLEMPL
/",'"
,.",'"
/,/'
...-,,//
",;"';"/
,;"",,,,,/.
/~'
,;/"
",//
x
Sin acceso
,,/,....
./,,'
NOMBRE
Bruno
~/
///
",',/,;'
13 11
11
/"',""
/",/
I,~ OnCIlIA RE P
PUESTO
f~CO~
11-FEB-Se 12-OCT-88 lO-DIe-ae
JEFE
CUO'rJ,
VENTAS
102
106
".
lO'
Aneaga l\./lria Ji..onn SUsana santo.

sa:md eh".}
110
102 lO'
RIOCU,
yconcediendo el privilegio SELECT de la vista al identificador de usuario USUAcomo puede verse en la Figura 15.3. Este ejemplo utiliza una vista vertical para restringir el acceso a columnas concretas. Las vistas horizontales tambin son efectivas para hacer que se cumplan las reglas de seguridad, como la siguiente:
'" '" '"
Bernardo Sbehz oa..~iel llui4robo

Toais
su
Pabl<o en:: Neus Az<:.Iinte
LeOa Freire
" '" " 33 n " " ., "

H
Representante Representanta
VI'
21 Representllnta
ventn
14-JUN-Be
19-MAY-88 20-0C'1'-88 1J-ENE-88 12-OCT-88
Dl-KAR-88
~c
12 Jefe vntas
12 12 21
~C
". ". '"
350000,Cae 300 DOO,Ca 350000,DaE
368911,OO
392125.00 474.0S0,OO
299,.912.00 142.59<l,OO
Representante Representante
Jefa venUS
". ".
101
ns.ooo.OO
20D.OOO.DeE
3aO.DOO.De
~c
,OS
3DS.613.00 15.nS.OO
361.865,OO 286."'S.OO 186.0n,OO
3S0.000.00
275.000.00 JOO.OOO.OO
22
RepresC1Itanta Rl!present.ante
U-NOV88
10'
'"
Figura 15.3.
Empleo de vistas para restringir el acceso a columnas.
REPRESENTANTES
Los jefes de ventas de cada regin deben rener acceso completo a los dalOs de de los representantes asignados a esa regin.
Como puede verse en la Figura 15.4, se pueden definir dos vistas, REPESTE y que contienen datos de REPRESENTANTES de cada una de las dos regiones, y luego conceder a cada jefe de oficina acceso a la vista correspondiente. Por supuesto, las vistas pueden ser mucho ms complejas que los meros subconjuntos de filas y columnas de una sola tabla que pueden verse en estos ejemplos. Al definir una vista con una consulta de agrupacin, se puede conceder a los
REPOESTE,
usuarios acceso a datos resumidos, pero no a las fijas detalladas de la tabla subyacente. Las vistas tambin pueden combinar datos de dos o ms tablas, proporcionando exactamente los datos que necesita un usuario concreto y negndole el acceso al resto de los datos. La utilidad de las vistas para la implementacin de la seguridad de SQL queda limitada por las dos restricciones fundamentales ya descritas en el Captulo 14: Restricciones de actualizacin. El privilegio SELECT puede utilizarse con vistas de slo lectura para limitar la recuperacin de datos, pero los privilegios
438
439
VIS t a R EPESTE
NUM EMPL NOMBRE
SELECT
105 Bruno Arteaga 104 Bernardo Snchez 101 Daniel Ruidrobo 103 Pablo Cruz
,,
1',
1-- GRANT
SELECT----
DELETE~
.---r----------...
ON nombre-fabla
INSERT DELETE
lO' Kara Jimnez lO' Samuel Clavel
UPDATE
;>-. \\ ' Tabla REPRESENTANTES \ \ \\ NmLEMPL NOMBRE ,\ ' \ \ 105 Bruno Arteaga
\, \
INSERT-----, REFERENCES-l ,
UPDATE---I---'-_.inombre-eO!Umnar-I
'-------, -------'
ALL PRIVILEGES - - - - - - - - - - - - '
Sin acceso
"" ,, ",,, , , ,, 1
\\1 1
/1' 11 , 1/ /1 I 1
/ I
'y"v.,
102 Susana Santos lO' samuel Clavel 104 Bernardo SAnchez 101 Daniel Ruidrobo ~ 110 TaDs Saz 108 Len Freire 103 Pablo Cruz 107 Neus Azcrate
lO' Mara Jimnez
')
USAGE O N D O M A I N nombre-dominio CHARACTER SET no~~~~rt~e~O' COLLATION nombre-secuencia TRANSLATION nombre-traduccin
1>
TO
IS
SELECT
aR
EMPL
NOMBRE
INSERT DELETE UPDATE
102 Susana Sant.os 108 Len Freire 107 Neus Azcrate
5/
// /{ / / 1 11 1 11 11 11
/,
/,
l'
---nno~~"-"'~'ITT
L.=.::BLI:..=.J
J
WrTH GRANT OPTION
Figura 15.5. Figura 15.4. Empleo de vistas para restringir el acceso a las filas.
Diagrama sintctico de la instruccin GRANT.
Y UPDATE carecen de sentido para estas vistas. Si un usuario tiene que actualizar los datos visibles en una vista de slo lectura, hay que concederle permiso para actualizar las tablas subyacentes y debe utilizar las instrucciones INSERT, DELETE y UPDATE que hacen referencia a esas tablas. Rendimiento. Como el SGBD traduce cada acceso a la vista en el acceso correspondiente a sus tablas fuente, las vistas pueden aadir una sobrecarga significativa a las operaciones de la base de datos. Las vistas no se pueden utilizar de manera indiscriminada para restringir el acceso a la base de datos sin hacer que sufra el rendimiento general de la base de datos.
INSERT, DELETE
La instruccin GRANT que puede verse en el diagrama sintctico cumple el estndar ANSIIISO de SQL. Muchas marcas de SGBD siguen la sintaxis de DB2 para la instruccin GRANT, que es ms flexible. La sintaxis de DB2 permite especificar una lista de identificadores de usuario y una lista de talas, lo que hace ms sencilla la concesin simultnea de muchos privilegios. A continuacin se ofrecen algunos ejemplos de instrucciones GRANT sencillas para la base de datos de ejemplo:
Conceder a los usuarios de procesamiento de pedidos acceso completo a la tabla PEDIDOS.
GRANT SELECT, INSERT, ON PEDIDOS TO USUARIOPP DELETE, UPDATE
Concesin de privilegios (GRANT)

La instruccin GRANT bsica, que pu'ede verse en la Figura 15.5, se utiliza para conceder privilegios de seguridad sobre los objetos de la base de datos a usuarios concretos. Normalmente, la instruccin GRANT es utilizada por el propietario de una tabla o vista para conceder acceso a los datos a otros usuarios. Como puede verse en la figura, la instruccin GRANT incluye una lista especfica de los privilegios que se van a conceder, el nombre de la tabla a la que se aplican esos privilegios y el identificador de usuario al que se le conceden.
Los usuarios de cuentas deben poder recuperar los datos de los clientes y aadir clientes nuevos a la tabla CLIENTES, pero los usuarios de procesamiento de pedidos slo deben tener acceso de lectura.
GRANT SELECT, INSERT ON CLIENTES TO USUARIOCU
440
GRANT

SELECT
441
ON CLIENTES TO USUARIOPP
Los usuarios de procesamiento de pedidos deben poder modificar el nombre de las empresas y las asignaciones de representantes.
GRANT UPDATE (EMPRESA, ON CLIENTES TO USUARIOPP REP_CLI)
Permitir que Samuel Clavel inserte o elimine oficinas.

GRANT INSERT, DELETE ON OFICINAS T SAMUEL
Si se omite la lista de columnas, el privilegio se aplica a todas las columnas de la tabla o vista, como en este ejemplo:
Los usuarios de cuentas deben poder modificar cualquier informacin sobre ..-........ los clientes.
GRANT UPDATE ON CLIENTES TO USUARIOCU
Por comodidad, la instruccin GRANT ofrece dos atajos que se pueden utilizar al conceder muchos privilegios o al concedrselos a muchos usuarios. En lugar de hacer un listado de todos los privilegios disponibles para cada objeto concreto, se puede utilizar la palabra clave ALL PRIVILEGES. La instruccin GRANT concede a Sarnuel Clavel, vicepresidente de ventas, acceso completo a la tabla REPRESENTANTES:
Conceder todos los privilegios sobre la tabla Clavel.

GRANT ALL PRIVlLEGES ON REPRESENTANTES TO SAMUEL
REPRESENTANTES
a Samuel
En lugar de conceder privilegios a todos los usuarios de la base de datos uno a uno, se puede utilizar la palabra clave PUBLIC para conceder privilegios a cada usuario autorizado de la base de datos. La instruccin GRANT permite a todo el mundo recuperar datos de la tabla OFICINAS: Conceder a todos los usuarios acceso SELECT a la tabla OFICINAS.
GRANT SELECT ON OFICINAS TO PUBLlC
El estndar ANSI/ISO no permite una lista de columnas para el privilegio SEexige que el pr.ivilegio SELECT se aplique a todas las columnas de la tabla o vista. En la prctica, esto no supone una restriccin seria. Para conceder acceso a columnas concretas, primero hay que definir una vista de la tabla que slo incluya esas columnas, y luego conceder el privilegio SELECT slo para esa vista. No obs. tan te, las vistas definidas nicamente por motivos de seguridad pueden complicar la estructura de bases de datos, por lo dems sencillas. Por este motivo, algunas marcas de SGBD permiten una lista de columnas para el privilegio SELECT. Por ejemplo, la siguiente instruccin GRANT es legal para las marcas de SGBD Sybase, SQL Server e Informix:
LECT;
Conceder a los usuarios de cuentas acceso de slo lectura a las columnas del nmero de empleado, nombre y ventas de la tabla REPRESENTANTES.
GRANT SELECT (NUM_EMPL, ON REPRESENTANTES TO USUARlOCU NOMBRE, OFICINA_REP)
Obsrvese que esta instruccin GRANT concede acceso a todos los usuarios autorizados presentes y futuros; comnmente, no slo a los identificadores de usuario conocidos por el SGBD. Esto elimina la necesidad de conceder privilegios de manera explcita a los usuarios nuevos a medida que son autorizados.
"
Privilegios sobre columnas

El estndar SQLI permite conceder el privilegio UPDATE para columnas individuales de una tabla o vista, y el estndar SQL2 permite tambin una lista de columnas para los privilegios IN8ERT y REFERENCE8. Las columnas se relacionan tras la palabra UPDATE, INSERT o REFERENCES, y encerradas entre parntesis. A continuacin puede verse una instruccin GRANT que permite al departamento de procesamiento de pedidos actualizar slo las columnas del nombre de la empresa y del representante asignado de la columna CLIENTES: .
La instruccin GRANT elimina la necesidad de la vista INFOREP definida en la Figura 15.3 y, en la prctica, puede eliminar la necesidad de muchas vistas de las bases de datos de produccin. No obstante, el empleo de listas de columnas para el privilegio SELECT es exclusivo de ciertos dialectos de SQL y no est rermitido por el estndar ANSIIlSO ni por los productos SQL de IBM.
Transmisin de privilegios
(GRANT OPTION)
Cuando se crea un objeto de la base de datos y el usuario se hace su propietario, es la nica persona que puede conceder privilegios para utilizar el objeto. Cuando se conceden privilegios a otros usuarios, se les permite utilizar el objeto, pero no
442
443
pueden transmitir esos privilegios a otros ~suarios_ De este m?do. el p:opietario ~e cada objeto conserva un control muy estncto sobre los usuanos que .tIenen permIso para utilizar ese objeto y sobre las formas de a~c~so que se pern:ten. De manera ocasional puede que se desee pemullT a otros usuanos que conce dan privilegios sobre un objeto que se posee. Por ejemplo, cons~drense nuevamente las vistas REPESTE y REPOESTE de la base de datos de eJe~pl~. Samuel Clavel, el vicepresidente de ventas, cre estas vistas. y es su propletano: .Puede conceder al director de la oficina de Len, Len Frelre, permiso para utilIzar la vista REPOESTE con esta instruccin GRANT:
GAANT SELOCT ON RE PO ESTE TO LEON
@GRANT
WITH GRANT DPTION
SAMUEL
LEN
Se desea averiguar lo que ocurre si Len desea conceder a Susana Santos (con identificador de usuario SUSANA) permiso para tener acceso a.los datos ,de REPOESTE porque hace algunas previsiones de ventas para I~ ?fic~na de Le~n. Con la instruccin GRANT anterior no puede concederle el prIVilegIO necesarIo. Slo Samuel Clavel puede conceder ese privilegio, ya que es el propietario de la vista. Si Samuel desea concederle a Len discrecin sobre los usuarios que pueden utilizar la vista REPOESTE, puede utilizar esta variacin de la instruccin GRANT anterior:
GRANT ON TO WITH SELECT REPOESTE LEON GRANT OPTION
SUSANA
Figura 15.6.
Empleo de
GRANT
OPTION.
De manera alternativa, Len podra crear una vista para Susana que slo incluyera a los representantes de la oficina de Len y concederles acceso a esa vista:
CREATE VIEW REPLEON AS
SELECT FROM RE POESTE WHERE OFICINA = 21 GRANT ALL PRIVILEGES ON RE PLEON TO SUSANA
Debido a la clusula WITH GRANT OPTION, esta instruccin GRANT conlleva, junto con los privilegios especificados, el derecho a conceder esos privilegios a otros usuarios. Len puede ahora escribir esta instruccin GRANT:
GRANT SELECT ON REPOESTE TO SUSANA
que permite a Susana Santos recuperar datos de la vista REPOESTE. La Figura 15.6 ilustra orficamente el flujo de privilegios, en primer lugar desde SamlJel a Len, y lueg; de Len a Susana. Debido a que la instruccin GRAN: escrita por Len no inclua la clusula WITH GRANT DPTIDN, la cadena de permisos concluye con Susana; ella puede recuperar los datos.de REPOE~:E, pero no puede co~ ceder acceso a otros usuarios. No obstante, SI la conceSlOn por Lorenzo de pnvilegios a Susana hubiera incluido GRANT OPTION, la cad~na hubiera podido continuar ha~ta otro nivel, permitiendo que Susana concediera acceso a otros usuarios.
Len es el propietario de la vista REPLEON, pero no posee la vista REPOESTE de la que se obtiene esta nueva vista. Para hacer que la seguridad siga siendo efectiva, el SGBD exige que Len no slo tenga el privilegio SELECT sobre REPOESTE, sino que tenga RANT OPTION para ese privilegio antes de permitirle que conceda a Susana el privilegio SELECT sobre RE PLEON. Una vez concedidos ciertos privilegios a un usuario con GRANT OPTION, ese usuario puede conceder esos mismos privilegios y GRANT OPTION a otros usuarios. Esos usuarios pueden, a su vez, seguir concediendo tanto los privilegios como GRANT OPTION. Por este motivo, conviene tener mucho cuidado al conceder a otros usuarios GRANT OPTION. Hay que tener en cuenta que GRANT OPTION slo se aplica a los privilegios concretos mencionados en la instruccin GRANT. Si se desea conceder ciertos privilegios con GRANT OPTION y otros sin esa opcin, hay que utilizar dos instrucciones GRANT diferentes, como en el ejemplo siguiente:
Len Freire debe poder recuperar, insertar, actualizar y eliminar datos de la tabla REPOESTE, y conceder permiso de recuperacin para otros usuarios.
444
445
GRANT SELECT
N RE POESTE TO LEON WITH GRANT OPTION

GRANT INSERT,
ON REPOESTE
Conceder y luego retirar algunos privilegios sobre la tabla

GRANT SELECT. INSERT, UPDATE ON REPRESENTANTES TO USUARIOCU, USUARIOPP REVOKE INSERT, UPDATE ON REPRESENTANTES FROM USUARIOPP
REPRESENTANTES.
DELETE,
UPDATE
'\
INSERT y UPDATE
TO LEON
Retirada de privilegios (REVOKE)

En la mayor parte de las bases de datos basadas en SQL, los privilegios que se han concedido con la instruccin GRANT pueden retirarse con la instruccin REVOKE, que puede verse en la Figura 15.7. La instruccin REVOKE tiene una estructura que se asemeja bastante a la de la instruccin GRANT. que especifica un conjunto concreto de privilegios que hay que retirar, para un objeto de la base de dalas detenninado, de uno o varios identificadores de usuario. La instruccin REVOKE puede retirar todos o parte de los privilegios que se hayan concedido previamente a un identificador de usuario. Por ejemplo, considrese esta secuencia de instrucciones:
Primero se conceden los privilegios
sobre la tabla
REPRE-
SENTANTES a los dos usuarios y luego se le retiran a uno de ellos. No obstante, el
privilegio SELECT se conserva para los dos identificadores de usuario. A continuacin se ofrecen otros ejemplos de la instruccin REVOKE:
Retirar todos los privilegios concedidos anteriormente sobre la tabla

CINAS.
OFI-
REVOKE ALL PRIVILEGES ON OFICINAS FROM USUARIOCU
Retirar los privilegios
UPDATE
DELETE
de dos identificadores de usuario.
f- REVORE
-,-----:-~;::~;;-;;;~j. ~I
GRANT OPTION FQR
SELECT DELETE
INSERT
UPDATE T~ USAGE
~fnomb"H'OI"mn8T
1
,
REVOKE UPDATE, DELETE ON OFICINAS FROM USUARIOCU. USUARIOPP
REFERE_~N_C_E_S
Retirar todos los privilegios sobre la tabla teriormente a todos los usuarios.
REVOKE ALL PRIVILEGES ON OFICINAS FROM PUBLlC
OFICINAS
que se concedieron an-
ON
nombretabla OOMAIN nombre-dominio CHARACTER SET nomc~~~~~~ntoCOLLATION nombre-secuencia TRANSLATlQN nombre-traduccin
FRQM
l!;0mb" PUBLlC
"'"?Tl 3 ,
CASCADE
RESTRlCT
Cuando un usuario escribe una instruccin REVOKE, slo se pueden retirar los privilegios que ese usuario concedi anteriormente a otros usuarios. Puede que esos usuarios tengan tambin privilegios concedidos por otros usuarios; esos privilegios no se ven afectados por esta instruccin REVOKE. Obsrvese espeCficamente que si dos usuarios diferentes conceden el mismo privilegio sobre el mismo objeto a un usuario, y uno de ellos lo retira posterionnente, la concesin <Jel segundo usuario le seguir permitiendo el acceso al objeto. Este manejo de-las con~ cesiones de privilegios solapadas se ilustra en la siguiente secuencia de ejemplo. Supngase que Samuel Clavel, el vicepresidente de ventas, concede a Len Freire el privilegio SELECT sobre la tabla REPRESENTANTES, y los privilegios SELECT y UPDATE sobre la tabla PEDIDOS. empleando las instrucciones siguientes:
GRANT SELECT ON REPRESENTANTES
Figura 15.7.
Diagrama sintctico de la instruccin REVOKE.
446
447
TO LEDN
GRANT SELECT, UPDATE

ON PEDIDOS TO LEON
Pocos das ms tarde Gonzalo Walker, el vicepresidente de marketing, concede

a Len Jos privilegios
SELECT
DELETE
sobre la tabla PEDIDOS y el privilegio
SELECT sobre la tabla CLIENTES, empleando estas instrucciones:

GRANT SELECT, DELETE ON PEDIDOS TO LEON GRANT SELECT ON CLIENTES TO LEDN
GONZALO
G)GRANT
LEN
Obsrvese que Len ha recibido privilegios sobre la tabla PEDIDOS de dos fuentes diferentes. De hecho, el privilegio SELECT sobre la tabla PEDIDOS se lo han concedido las dos fuentes. Pocos das ms tarde. Samuel le retira a Len los privilegios que le haba concedido anterionnente sobre la tabla PEDIDOS:
REVOKE SELECT, UPDATE ON PEDIDOS
FROM LEON
SUSANA
Una vez que el SGBD procesa la instruccin REVOKE, Len sigue conservando el privilegio SELECT sobre la tabla REPRESENTANTES, los privilegios SELECT.Y DELETE sobre la tabla PEDIDOS, y el privilegio SELECT sobre la tabla CLIENTES, pero ha perdido el privilegio UPDATE sobre la tabla PEDIDOS.
Figura 15.8.
Retirada de los privilegios concedidos por dos usuarios.
REVOKE
y GRANT OPTION
Cuando se conceden privilegios con GRANT OPTION y posterionnente se retiran, la mayor parte de las marcas de SGBD retiran de manera automtica todos los privilegios derivados de la concesin original. Considrese nuevamente la cadena de privilegios de la Figura 15.6, desde Samuel Clavel, el vicepresidente de ventas, a Len Freire, el jefe de la oficina de Len, y luego a Susana Santos. Si Samuel retira los privilegios de Len sobre la vista REPOESTE, tambin se retira automticamente el privilegio de Susana. La situacin se complica an ms si dos o ms usuarios han concedido privile-. gios y uno de ellos los retira posteriormente. Considrese la Figura 15.8, una pequea variacin sobre el ltimo ejemplo. En este caso, Len recibe el privilegio SELECT con GRANT OPTION tanto de Samuel (el vicepresidente de ventas) como de Gonzalo (el vicepresidente de marketing) y concede privilegios a Susana. Esta vez, cuando Samuel retira los privilegios de Len, la concesin de privilegios por parte
de Gonzalo permanece. Adems, los privilegios de Susana tambin permanecen, ya que pueden proceder de la concesin de Gonzalo. No obstante, considrese otra variacin de la cadena de privilegios, con los eventos ligeramente reordenados, como puede verse en la Figura 15.9. En este caso, Len recibe de Samuel el privilegio con GRANT OPTION, concede el privilegio a Susana, y luego recibe la concesin, con GRANT OPTION, de Gonzalo. Esta vez, cuando Samuel retira los privilegios de Len, los resultados son ligeramente diferentes, y pueden variar de un SGBD a otro. Como en la Figura 15.8, Len conserva el privilegio SELECT sobre la vista REPOESTE porque la concesin de Gonzalo sigue intacta. Pero en las bases de datos de DB2 o de SQUDS, Susana pierde de manera automtica su privilegio SELECT sobre la tabla. El motivo es que la concesin de Len a Susana proceda claramente de la concesin de Samuel a Len, que acaba de retirarse. No poda proceder de la concesin de Gonzalo a Len, ya que e~a concesin no haba tenido lugar todava cuando se realiz la concesin de Len a Susana. En una marca diferente de SGBD los privilegios de Susana podran permanecer intactos, ya que la concesin de Gonzalo a Len sigue intacta. Por tanto, la
448
449
rn~ ~
h
r.\GRANT WITH
OPTION
GAANT
~::w
IJ'GAANT RANT OPTION
GONZALO
~
LEN
G)GAANT
estructura de la base de datos. La instruccin REVOKE, por tanto, no se halla incluida en el estndar SQLl, como sucede con la instruccin DROP TABLE. Pese a su ausencia del estndar SQLl. casi todos los productos comerciales de SOBD basados en SQL proporcionaban la instruccin REVORE desde las primeras versiones. Al igual que con las instrucciones DROP y ALTER, el dialecto DB2 de SQL ha definido de hecho el estndar para la instruccin REVOKE. El estndar SQL2 incluye una especificacin para la instruccin REVOKE basada en la instruccin de DB2, con algunas ampliaciones. Una de las ampliaciones concede al usuario un control ms explcito sobre el modo en que se retiran los privilegios cuando, a su vez, se han concedido a otros usuarios. La otra ampliacin proporciona una manera de retirar GRANT OPTION sin retirar los propios privilegios. Para especificar el modo en qu~l SGBD debe tratar la relirada de privilegios que, a su vez, se han concedido a otros usuarios, el estndar SQL2 exige que se especifique la opcin CASCADE o RESTRICT en cada instruccin REVOKE. (En el estndar SQL2 se aplica un requisito parecido a muchas de las instrucciones DROP, como se describe en el Captulo ]3.) Supngase que los privilegios SELECT y UPDATE sobre la tabla PEDIDOS se han concedido anteriormente a Len, con GRANT OPTION, y que Len, a su vez, ha concedido estas opciones a Bruno. Entonces, esta instruccin REVOKE:
REVOKE SELECT, UPDATE ON PEDIDOS FROM LEON CASCADE
~
SUSANA
Figura 15.9.
Retirada de los privilegios en una secuencia diferente.
no s610' retira los privilegios de Len, sino tambin los de Bruno. El efecto de la instruccin REVOKE, por tanto, repercute en todos los dems usuarios cuyos privilegios procedan de la instruccin GRANT original. Abora, sup6nganse las mismas circunstancias y esta instruccin REVOKE:
REVOKE SELECT. UPDATE ON PEDIDOS FROM LEON RESTRICT
secuencia temporal de las instrucciones GRANT y REVOKE, ms que los propios privilegios, puede determinar la trascendencia de una instruccin REVOKE. La concesin y la retirada de privilegios con GRANT OPTION debe tratarse con mucho cuidado, para asegurarse de que el resultado es el pretendido.
REVOKE
y el estndar ANSI/ISO
El estndar SQLl especificaba la instruccin GRANT como parte del lenguaje de definicin de datos de SQL (Data Definition Language, DDL). Recurdese del Captulo 13 que el estndar SQLl trataba el DDL como una definicin esttica e independiente de las bases de datos y no exiga que el SGBD permitiera modificaciones dinmicas en la estructura de las bases de datos. Este enfoque tambin se aplica a la seguridad de las bases de datos. Segn el estndar SQLl, la accesibilidad a las tablas y a las vistas de la base de datos viene determinada por una serie de instruccion~ GRANT incluida en el esquema de la base de datos. No hay ningn mecanismo para la modificacin del esquema de seguridad una vez definida la
En este caso, la instruccin REVOKE falla. La opcin RESTRICT indica al SGBD que no debe ejecutar la instruccin si afecta a cualesquiera otros privilegios de la base de datos. El mensaje de error resultante llama la atencin del usuario sobre el hecho de que hay efectos secundarios (posiblemente no buscarlos) de la instruccin REVOKE y permite que el usuario vuelva a considerar la accin. Si el usuario desea seguir adelante y retirar los privilegios, se puede especificar la opcin CASCADE. La versin de SQL2 de la instruccin REVOKE tambin concede al usuario un control independiente, ms explcito, sobre los privilegios, y GRANT QPTION para esos privilegios. Supngase nuevamente que se han concedido a Len privilegios sobre la tabla PEDIDOS, con GRANT OPTION para esos privilegios. La instruccin REVOKE habitual para esos privilegios:
REVOKE SELECT. UPDATE ON PEDIDOS FROM LEaN
450
retira tanto los privilegios como la posibilidad de concedrselos a otros usuarios. El estndar SQL2 permite esta versin de la instruccin REVOKE:
REVOKE GRANT OPTION FOR SELECT, UPDATE ON PEDIDOS FROM LEON CASCADE
CAPTULO
16
Si la instruccin tiene xito, Len perder su capacidad para conceder estos privilegios a otros usuarios, pero no los propios privilegios. ~omo antes, el estndar SQL2 exige la opcin CASCADE o RESTRICT para especlfi~ar el modo en que el SGBD debe tratar la instruccin si Len, a su vez, ha concedIdo GRANT OPTION a otros usuarios.
CatloflO del sistema
Resumen
El lenguaje SQL se utiliza para especificar las restricciones. de seguridad para las bases de datos basadas en SQL: El esquema de seguridad de SQL se construye alrededor de los privilegios (acciones permitidas) que pueden concederse sobre objetos concretos de la base de datos (como las tablas y las vistas) para identificadores de usuario determinados (usuarios o grupos de usuarios). Las vistas tambin desempean un papel fundamental en la seguridad de SQL, ya que pueden utilizarse para restringir el acceso a filas o columnas concretas de cada tabla. La instruccin GRANT se utiliza para conceder privilegios; los privilegios que se conceden a los usuarios con GRANT OPTION pueden, a su vez, ser concedidos por esos usuarios a otros usuarios. La instruccin REVOKE se utiliza para retirar los privilegios concedidos anteriormente con la instruccin GRANT. Los sistemas de gestin de bases de datos deben realizar el seguimiento de gran cantidad de informacin sobre la estructura de las bases de datos para llevar a cabo sus funciones de gestin de datos. En las bases de datos relacionales esta informacin suele almacenarse en el catlogo del sistema, un conjunto de tablas que el SGBD conserva para su propio uso. La informacin del catlogo del sistema describe las tablas, las vistas, las columnas, los privilegios y otras caractersticas estructurales de las bases de datos. Aunque el SGBD conserva el catlogo del sistema principalmente para sus propias finalidades internas, las tablas del sistema o las vistas basadas en ellas suelen ser accesibles tambin para los usuarios de la base de datos, mediante consultas SQL estndar. Las bases de datos relacionales, por tanto, se describen a s mismas; mediante consultas a las tablas del sistema se puede pedir a la base de datos que describa su propia estructura. Las partes visibles para los usuarios de las bases de datos de finalidad general, como las herramientas de consulta y los redactores de informes, utilizan esta capacidad de autodescripcin para generar listas de tablas y de columnas para su seleccin por el usuario que simplifican el acceso a la base de datos. Este captulo describe los catlogos del sistema proporcionados por varios productos de SGBD populares basados en SQL y la informacin que contienen esos catlogos. Tambin describe las posibilidades del catlogo del sistema especifICadas por el estndar ANSI/ISO de SQL2.
El concepto de catlogo del sistema

El catlogo del sistema es un conjunto de tablas especiales de la base de datos que posee, crea y mantiene el propio SGBD. Estas tablas del sistema contienen datos que describen la estructura de la base de datos. Las tablas del catlogo del sistema se crean de manera automtica al crear la base de datos. Suelen reunirse bajo 451
452
Captulo 16: Catlogo del sistema
453
un identificador de usuario especial del sistema con un nombre como SYSTEM, SYSIBM, MASTER o DBA. El SaBD hace referencia constantemente a los datos del catlogo del sistema mientras procesa las instrucciones de SQL. Por ejemplo, para procesar una instruccin SELECT de dos tablas, el SGBD debe: Comprobar que las dos tablas citadas existen realmente. Asegurarse de que el usuario tiene permiso para acceder a ellas. Comprobar si las columnas a las que se hace referencia en la consulta existen. Resolver cualquier nombre de columna no calificado en una de las tablas. Determinar el tipo de datos de cada columna.
ArchIVO
Base de datos
Consulta
Busqueda
Actuahzaclon
Salir
!lOO EJI
Seleccione una tabla: CUENTES

OfJ~NAS
PEDIDOS
PRODUCTOS REPRESENTANTES
Seleccione las columnas

)
NMERO DEL PEDIDO FECHA DEL PEDIOO CUENTE REPRESENTANTE
Al almacenar la informacin estructural en las tablas del sistema, el SGBD puede utilizar sus propios mtodos y lgica de acceso para recuperar de manera rpida y eficiente la informacin que necesita para llevar a cabo estas tareas. Si las tablas del sistema se utilizaran slo internamente al SGBD, resultaran de poco inters para los usuarios de la base de datos. No obstante, el SGBD suele poner tambin las tablas del sistema a disposicin de los usuarios. Si las tablas del sistema en s mismas no estn disponibles, el SGBD suele ofrecer vistas basadas en esas tablas que ofrecen un conjunto de informaciones del catlogo recuperables por los usuarios. Las bases de datos de computadoras personales y las de grupos de trabajo permiten casi siempre las consultas de los usuarios a los catlogos del sistema o a las vistas. Los productos para grandes sistemas y para SGBD de empresa tambin admiten estas consultas, pero el administrador de la base de datos puede restringir el acceso al catlogo del sistema para proporcionar medidas adicionales de seguridad de la base de datos. Al consultar los catlogos del sistema se puede hallar informacin sobre la estructura de la base de datos, aunque no se haya utilizado nunca antes. El acceso de los usuarios al catlogo del sistema es slo de lectura. El SGBD evita que los usuarios actualicen o modifiquen directamente las tablas del sist~ma porque esas modificaciones destruiran la integridad de la base de datos. En lugar de eso, el propio SGBD se ocupa de insertar, eliminar y actualizar las filas de las tablas del sistema cuando modifica la estructura de la base de datos. Las instrucciones del lenguaje de definicin de datos (LDD), como CREATE, ALTER, DROP, GRANT y REVOKE, provocan modificaciones de las tablas del sistema como subproducto de sus acciones. En algunos productos de SGBD, incluso las instrucciones del DML que modifican la base de datos, como INSERT y DELETE, pueden provocar modificaciones en las tablas del sistema, que realizan el seguimiento del nmero de filas de cada tabla.
FABRICANTE PRODUCTO CANTIDAD IMPORTE TOTAL
NMERO DEL PEDIDO CLIENTE
1129B1 113012 112989
J.P. Soloca JCP S. A.

Jarandilla lId.
REPflESENTANTE 1 Samu!IClav!1 Bruno M!aga ~

SlrlClavijo
'~
f'
Figura 16.1.
Herramienta de consulta fcil de utilizar por los usuarios.
tengan acceso a la base de datos de manera sencilla y transparente sin necesidad de que aprendan el lenguaje SQL. Generalmente, cada herramienta lleva al usuario por 'una serie de etapas parecida a sta: 1. 2. 3. 4. 5. 6. El usuario da un nombre y una contrasea para el acceso a la base de datos. La herramienta de consulta muestra una lista de las tablas disponibles. El usuario escoge una tabla, lo que hace que la herramienta de consulta muestre una lista de las columnas que contiene. El usuario escoge las columnas que le interesan, acaso pulsando su nombre segn aparecen en la pantalla de una computadora personal. El usuario escoge columnas de otras tablas o restringe los datos que hay que recuperar con una condicin de bsqueda. La herramienta de consulta recupera los datos solicitados y los muestra en la pantalla del usuario.
El catlogo y las herramientas de consulta

Una de las principales ventajas del catlogo del sistema es que hace posible que las herramientas de consulta sean fciles de usar por el usuario, como puede verse en la Figura 16.1. El objetivo de estas herramientas es permitir a ,los usuarios que
Las herramienlas de consulta de propsito general, como la que aparece en la Figura 16.1, son utilizadas por muchos usuarios diferentes, y se emplean para tener acceso a muchas bases de datos diferentes. La herramienta no puede cono-
1
~
454
455
cer con antelacin la estructura de la base de datos a la que tendr acceso durante cada sesin. Por tanto, debe poder aprender de manera dinmica sobre las tablas y las columnas de las bases de datos. Las herramientas utilizan con este fin las consultas al catlogo del sistema.
Privilegios. El ca.tlogo describe cada conjunto de privilegios concedido en l~ base de. d~to~, mcluyendo los nombres del concedente y del concesionan~, !os pnvlleglOS concedidos, el objeto sobre el que se han concedido los pnvllegIOs. etc. . La Tabla 16.1 muestra los nombres de las tablas del sistema que ofrecen esta InfOrmaCIn en cada~uno de lo~ principales productos SGBD basados en SQL. ~l .resto de este ~apItulo descnbe con ms detalle algunas tablas del sistema tlplcas y ofrece ejemplos de acceso al catlogo del sistema. Debido a las amplias variaciones en los callogos del sistema entre las diferentes marcas de . SGBD, tanto la descripcin completa de los catlogos del sistema como la exhaustividad en los ejemplos de todas ls marcas principales de SGBD qued~an fuera del objetivo de este hbro. Con la informacin aqu ofrecida se debena poder consultar la docum~ntacin del sistema de cada marca de SGBD y crear las consultas correspondlemes al catlogo del sistema.
El catlogo y el estndar ANSI/ISO

El estndar ANSI/ISO de SQLl no especificaba la estructura ni el contenido del catlogo del sistema. De hecho, el estndar SQL 1 no exige que haya catlogo del sistema. Sin embargo, todos los productos principales de SGBD basados en SQL ofrecen un catlogo del sistema de una forma o de otra. La estructura del catlogo y las tablas que contiene varan de una marca de SGBD a otra. Debido a la creciente importancia de las herramientas de bases de datos de propsito general que deben tener acceso al catlogo del sistema el estndar, SQL2 incluye la especificacin de un conjunto de vistas que ofrecen un acceso normalizado a la informacin que suele hallarse en el catlogo del sistema. Los SGBD que cumplen el estndar SQL2 incluyen estas vistas, que se denominan colectivamente INFDRMATIDN_SCHEMA (esquema de la informacin). Dado que este esquema resulta ms complejo que los autnticos catlogos del sistema utilizados por los productos comerciales de SGBD y su aceptacin crece lentamente, se describe en un apartado diferente titulado El esquema de la infonnacin de SQL2, cerca del final de este captulo.
SGBD
DB2'
Tablas
SCHEMATA TABLES REFERENCES KEYCOLUSE USER_ CATALOG USER_TABLES ALL_TABLES USER_ SYNONYMS
Columnas
COLUMNS
Usuarios
DBAUTH
Vistas
VIEWS VIEWDEP
Privilegios SCHEMAAUTH TABAUTH COLAUTH USER_TAB_ PRIVS USER_COL_ PRIVS USER_SYS PRIVS SYSTABAUTH SYSCOLAUTH
Grade
Contenido del catlogo

Cada tabla del catlogo del sistema contiene informacin sobre un solo tipo de elemento estructural de la base de datos. Aunque los detalles varan, casi todos los productos comerciales de SQL incluyen las tablas del sistema que describen cada una de estas cinco entidades: Tablas. El catlogo describe cada tabla de la base de datos. identificando su nombre de tabla, su propietario, el nmero de columnas que contiene, su tamao, etc. Columnas. El catlogo describe cada columna de la base de datos, dando el nombre de la columna, la tabla a la que pertenece, su tipo de datos, su tamao, si se permiten los valores NULL, etc. Usuarios. El catlogo describe a cada usuario autorizado de la base de datos, incluyendo el nombre de usuario, una forma codificada de la contrasea del usuario y otros datos. Vistas. El catlogo describe cada vista definida en la base de datos. incluyendo.su nombre, el nombre de su propietario, la consulta que define la vista, etc.
USER_TAB_ COLUMNS ALL_TAB_ COLUMNS
ALL_USERS
USER_VIEWS ALL_VIEWS
InformixSYSTABLES SYSCOLUMNS SYSREFER ENCES SYSSYNONYMS
SYSUSERS
SYSVIE\'IS 5YSDEPEND
Sybase SYSDATABASES SYSOBJECTS SYSKEYS
SYSCOLUMNS
SYSUSERS
SYSOBJECTS SYSCOMMENTS
SQL Server
SYSDATA5YSCOLUMNS BASES SYSOBJECTS SYSFOREIGNKEYS SYSREFERENCES
SYSUSERS SYSLOGINS SYSMEMBERS
5YSOBJECTS SYSPROTECTS SYSDEPENDS SYSCOHHENTS
Las tablas de DB2 tienen el calificador SYSCAT (por ejemplo. SYSCATTABLES).
456
457
Informacin de tablas
Cada uno de los principales productos de SQL tiene una tabla del sistema que realiza el seguimiento de las tablas de la base de datos. En DB2, por ejemplo. esta
Tabla 16.2.
Vista SYSCAT.TABLES (082) (continuacin) Tipo de datos

INTEGER VARCHAR(lB) VARCHAR (18) VARCHAR(18) SMALLINT SMALLINT SMALLINT SMALLINT SMALLINT SMALLINT SMALLINT CHAR(l) CHAR(32) SMALLINT CHAR(l) CHARll) SMALLINT VARCHAR(254)
Nombre de la columna
OVERFLOW TBSPACE INDEX_TBSPACE LONG_TBSPACE PARENTS
Informacin Nmero de registros de desbordamiento de la tabla. Espacio de tablas primario para el almacenamiemo de los datos de la tabla. Espacio de rabias para el almacenamiento de los ndices de la tabla. Espacio de tabla para el almacenamiento de objetos de ~atos de gran tamao. Nmero de tablas padre de la tabla. Nmero de tablas hijo de la tabla. Nmero de autorreferencias de la tabla. Nmero de columnas de la clave primaria de la tabla. Identificador interno para el ndice de la clave primaria. Nmero de restricciones de unicidad de la tabla. Nmero de restricciones de comprobacin de la tabla. Indica si la tabla se ha reproducido (YIN, s o no). Banderas de comprobacin de resrricciones. Identificador interno del mapa de particiones de la tabla. Modo de las tablas de la base de datos divididas en particiones. Indica si inicialmente se habilit el registro histrico para la tabla. Porcentaje de pginas que hay que reservar para datos futuros. Comentarios del usuario sobre la tabla.
infaonacin la ofrece una vista del catlogo del sistema denominada SYSCAT. TABLES. (Todas las vistas del catlogo del sistema de DB2 forman parte de un esquema denominado SYSCAT. por lo que tienen nombres de tabla o de vista cualificados de la forma SYSCAT .xu.)
La Tabla 16.2 muestra algunas de las columnas de la vista SYSCAT.TABLES. Contiene una fila por cada tabla, vista o alias definido en la base de datos. La infonnaci6n de esta vista es tpica de las ofrecidas por las vistas correspondientes
en otros productos de SGBD importantes.

Tabla 16.2. Vista SYSCAT. TABLES (082)
.
CHILDREN
TABSCHEMA TABNAME DEFINER TYPE STATUS BASE_TABSCHEMA BASE_TABNAME CREATE_TIME STATS_TIME COLCOUNT TABLEID TBSPACEID CARD NPAGES FPAGES
Tipo de datos
CHAR(B) VARCHAR (18) CHAR(B) CHAR{l) CHAR{l) CHAR{S) VARCHAR(18) TIMESTAMP TIMESTAMP SMALLINT SHALLINT SHALLINT INTEGER INTEGER INTEGER
Informacin
Esquema que contiene la tabla, vista o alias. Nombre de la tabla, vista o alias. Identificador de usuario del creador de la tabla, vista o alias.
SELFREFS KEYCOLUMNS KEYINDEXID KEYUNIQUE CHECKCOUNT DATACAPTURE CONST_CHECKED PMAP_ID PARTITION_HODE LOG_ATTRIBUTE PCTFREE REMARK5
T = tabla, V = vista, A
=alias.
Estado del objeto (para uso por el sistema). Esquema de la tabla base para el alias. Nombre de la tabla base para el alias. Momento de creacin del objeto. Momento en que se ha calculado la ltima estadstica. Nmero de columnas de la tabla. Nmero de identificacin interna de la tabla. Identificador del espacio de tablas primario de la tabla. Nmero de filas de la tabla (cardinalidad). Nmero de pginas del disco que contienen datos de la tabla. Nmero total de pginas de disco de la tabla.
(colltinla)
Las consultas pueden utilizarse como indican los ejemplos siguientes para obtener informacin sobre las tablas de las bases de datos de DB2. Pueden utilizarSe consultas parecidas. empleando nombres de tablas y de columnas diferentes, para obtener la misma informacin de otras marcas de SGBD.
458
CapItulo 16: Catlogo del sistema
459
Hacer una relacin del nombre y propietario de todas las tablas de la base de datos.
5ELECT DEFINER, TABNAME FROM SYSCAT.TABLES WHERE TYPE = T'
Tabla 16.3. Columnas seleccionadas de la tabla SYSOBJECTS (SQl Serverl
Name Id Vid
Tipo de datos
SYSNAME
Informacin Nombre del objeto. Nmero de identificador interno del objeto. Identificador de usuario del propietario del objeto. Cdigo de tipo del objeto!. Fechalhora en que se cre el objeto Identificador del procedimiento del DELETE disparador. Identificador del procedimiento del INSERT disparador.
UPDATE
INT
SMALLINT CHAR(2) DATETIME
Hacer una relacin del nombre de todas las tablas, vistas y alias de la base de datos.
SELECT TABNAME
Type
Crdate Deltrig
FROM SYSCAT.TABLES
INT INT INT
Hacer una relacin del nombre y del momento de creacin de las tablas del usuario que introduce la orden.
SELECT TABNAME. CREATE_TIME FROM SYSCAT.TABLES WHERE TYPE = T' ANO DEFINER = USER
instrig updtrig
Identificador del procedimiento del disparador.
1 S = tabla del sistema, U = tabla del usuario. V = vista. L = registro histrico. P = procedimiento almacenado. TR = disparador. etc.
USER_TABLES y ALL_TABLES llevan a cabo una labor parecida a SYSCAT. TABLES de DB2. La vista USE~TABLES contiene una fila
En las bases de datos de Gracle, un par de vistas del sistema denominadas la de la vista por cada tabla de la base de datos que posea el usuario en curso. La vista ALL_TABLES contiene una fila por cada tabla a la que tenga acceso el usuario en curso. Por tanto, la vista ALL_TABLES incluye todas las filas de USER_TABLES y otras filas que representan las tablas propiedad de otros usuarios en las que se ha concedido, como mnimo, uno de los privilegios de acceso al usuario en curso. A continuacin puede verse una consulta tpica a una de estas vistas del catlogo del sistema de Oracle: Hacer una relaci6n del nombre y propietario de todas las tablas a las que este usuario tiene acceso.
SELECT TABLE_NAME, OWNER FROM ALL_TABLES
base de datos se describen en otras tablas del sistema. A continuacin puede verse una consulta tpica a la tabla del sistema de Informix: Hacer una relacin del nombre, propietario y momento de creacin de todas las tablas de la base de datos.
SELECT TABNAME, OWNER, FROM SYSTABLES WHERE TABTYPE = 'T' CREATED
El equivalente en SQL Server de la vista de DB2 SYSCAT. TABLES es una vista del sistema denominada SYSOBJECTS, que se describ~ en la Tabla 16.3. La tabla SYSQBJECTS almacena la informacin sobre las tablas y vistas de SQL Server y sobre otros objetos de SQL Server, como los procedimientos almacenados, las reglas y los disparadores. Obsrvese tambin que la tabla SYSOBJECTS utiliza un nmero de identificador interno en lugar de un nombre para identificar al propietario de cada tabla. La tabla del sistema de Universal Server de Informix que ofrece informacin sobre las tablas se denomina SYSTABLES. Al igual que el catlogo de DB2, slo contiene informacin sobre las tablas, las vistas y los alias; los dems objetos de la
Como muestran estos ejemplos, las consultas para obtener informacin sobre las tablas tienen una estructura parecida en las diferentes marcas de SGBD. No obstante, los nombres concretos de las tablas o vistas del sistema que contienen la informacin, as como las columnas importantes, varan considerablemente de una marca a otra.
Informacin de columnas
Los principales productos de SQL tienen una tabla del sistema que realiza un seguimiento de las columnas de la base de datos. Hay una fila de esta tabla por cada columna de cada tabla o vista de la base de datos. La mayor parte de las marcas de SGBD restringen el acceso a esta tabla bsica del sistema, pero ofrecen al usuario infonnacin de las columnas mediante una vista que s610 muestra las columnas de
460
461
las tablas propiedad del usuario en curso o que le resultan accesibles. En las bases de datos de OracIe esta informacin la ofrecen dos vistas del catlogo del sistema: U5ER_TAB_COLUMNS, que incluye una fila por cada columna de cada tabla propiedad del usuario actual, y ALL_TAB_COLUMNS, que contiene una fila por cada columna de cada tabla accesible para el usuario actual. La mayor parte de la informacin de la tabla o vista de columnas del sistema almacena la definicin de las columnas -su nombre, su tipo de datos, su longitud, si puede aceptar valores NULL, ete.-, Adems, la tabla incluye a veces informacin sobre la distribucin de los valores de los datos de cada columna. Esta informacin estadstica ayuda al SGBD a decidir el modo de llevar a cabo las consultas de manera ptima. A continuacin puede verse una consulta tpica que puede utilizarse para obtener informacin sobre las columnas de una base de datos de Oracle:
Tabla 16.4.
Vista SYSCAT.COLUMNS (OB2)
TABSCHEMA TABNAME COLNAME COLNO TYPESCHEMA TYPENAME LENGTH
Tipo de datos
CHAR(B) VARCHAR (lB) VARCHAR (18) SMALLINT CHAR(B) VARCHAR(lB INTEGER SMALLINT VARCHAR(254) CHAR(l) SMALLINT CHAR(l)
Informacin
Esquema de la tabla que contiene la columna. Nombre de la tabla que contiene la columna. Nombre de la columna. Posicin de la columna en la tabla (primera columna = O). Esquema del dominio de la columna
(o SYSIBM).
Nombre del tipo de datos o del dominio de la columna. Longitud mxima de los datos para los tipos de datos de longitud variable. Escala para los tipos de datos DECIMAL. Valor predeterminado de la columna. Indica si se permiten valores NULL (Y/N. S/No). Pgina de cdigo para los tipos de caracteres ampliados. Indica si se ha activado el registro histrico (Y/N, SlNo) para las columnas de objetos de gran tamao. Indica si se han compactado las columnas de objetos de gran tamao (YIN, SlNo). Nmero de valores diferentes de los datos (cardinalidad). Segundo valor ms elevado de las columnas de la tabla. Segundo valor ms reducido de las columnas de la tabla. Longitud promedio de los datos para los tipos de datos de longitud variable. Posicin de la columna en la clave primaria (o O). Posicin de la columna dentro de la clave de particin (o O). Nmero de cuantiles en las estadsticas de las columnas. Nmero de valores frecuentes en las estadsticas de las columnas. Comentarios del usuario para la columna.
Hacer una re(acin del nombre y tipo de datos de las columnas de la tabla OFICINAS del usuario en curso.
SELECT COLUMN_NAME, DATA_TYPE FROM USER~TAB_COLUMNS WHERE TABLE_NAME = 'OFICINAS'
SCALE DEFAULT NULLS CODEPAGE LOGGED
Al igual que la informacin de las tablas del catlogo del sistema, la informacin de las columnas vara de una marca de SGBD a otra. La Tabla 16.4 muestra el contenido de la tabla del sistema SYSCAT. CQLUMNS, que contiene informacin de las columnas en el catlogo de DB2. A continuacin se ofrecen varios ejemplos de consultas que se aplican a esta marca de SGBD:
COMPACT
CHAR(l) INTEGER VARCHAR(33) VARCHAR (33 ) INTEGER SMALLINT SMALLINT SMALLINT SMALLINT VARCHAR(254)
Hallar todas las columnas de la base de datos con el tipo de datos DATE.
COLCARD SELECT TABSCHEMA, TABNAME, COLNAME FROM SYSCAT.COLUMNS WHERE TYPESCHEMA = 'SYSIBMO' ANO fYPENAME = 'DATE' HIGH2KEY LOW2KEY AVGCOLLEN KEYSEQ PARTKEYSEQ NQUANTILES NMOSTFREQ REMARKS
Hacer una relacin del propietario, nombre de la vista, nombre de la columna, tipo de datos y longitud de todas las columnas de texto de ms de diez caracteres de longitud definidas en las vistas.
SELECT FROM WHERE ANO ANO ANO ANO OEFINER, COLS.TABNAME, COLNAME, TYPENAME, LENGTH SYSCAT.COLUMNS COLS, SYSCAT.TABLES TBLS TBLS.TABSCHEMA = COLS.TABSCHEMA TBLS.TBLNAME = COLS.TBLNAME (TYPENAME = 'VARCHAR' OR TYPENAME ~ 'CHARACTER') LENGTH > 10 TYPE = 'V'
Hay una variacin considerable en el modo en que los catlogos del sistema de las diferentes marcas de SGBD ofrecen las definiciones de las columnas. Para su comparacin, la Tabla 16.5 muestra la definicin de la tabla SYSCOLUMNS de Uni-
462

SYSCOLUMNS
463
Tabla 16.5. Tabla
(In1ormixl Informacin Nombre de la columna. Identificador de tabla interno de la tabla que contiene la columna. Posicin de la columna en la tabla. Tipo de datos de la columna y si se penniten los valores NULL. Longitud de la columna. Segundo valor ms reducido de los datos de la columna. Segundo valor ms elevado de los datos de la columna. ..ongitud mnima de los datos. Longitud mxima de los datos. Identificador interno de los tipos de datos ampliados.
Informacin de vistas
Las definiciones de las vistas de una base de datos suele almacenarlas el SGBD en el catlogo del sistema. El catlogo de DB2 contiene dos tablas del sistema que
realizan un seguimiento de las vistas. La tabla SYSCAT. VIEWS. descrita en la Tabla
COLNAME
Tipo de datos
CHAR (18)
TABIO
COLNO COLTYPE CQLLENGTH COLMIN COLMAX MINLEN MAXLEN EXTENDED_ID
INTEGER SMALLINT SMALLINT 5MALLINT INTEGER
16.6, contiene la definicin de SQL en texto de cada vista. Si la definicin supera

los 3600, se almacena en varias filas, con los nmeros de secuencia 1, 2, 3, etc. La tabla SYSCAT. VIEWDEP de DB2, descrita en la Tabla 16.7, muestra el modo en que cada vista depende de las dems tablas o vistas. Hay una fila de la tabla para cada dependencia, por lo que las vistas con tres tablas fuente se representan mediante tres filas. Con estas dos tablas se pueden ver las definiciones de las vistas de la base de datos y determinar rpidamente las tablas de la base de datos que actan como tablas fuente de cada vista. Al igual que con muchos productos de SOBD implantados, la informacin sobre las vistas est estrechamente relacionada con la informacin so~ bre las tablas en el catlogo de DB2. Esto significa que suele haber ms de una manera de hallar la respuesta a las bsquedas en el catlogo. Por ejemplo, a continuacin se ofrece una consulta directa a la tabla del sistema VIEWS de DB2 para obtener el nombre y el creador de todas las vistas definidas. en la base de datos:
INTEGER INTEGER
INTEGER INTEGER
Hacer una relacin de las vistas definidas en la base de datos.

SELECT DISTINCT VIEWSCHAME. VIEWNAME. FROM SYSCAT.VIEWS DEFINER
versal Server de Informix. Algunas de las diferencias en la informacin de las co~ lumnas en las tablas son meramente cuestiones de estilo: Los nombres de las columnas de las dos tablas son completamente diferentes, aunque contienen datos parecidos. El catlogo de DB2 utiliza una combinacin del nombre del esquema y del nombre de la tabla para identificar la tabla que contiene una columna dada; el catlogo de Informix utiliza un nmero interno de identificador de la tabla, que es una clave externa de su tabla SYSTABLES.
Tabla 16.6.
Vista SYSCAT. VIEWS (082) TIpo de datos

CHAR(8) VARCHAR (18) CHAR(8) SMALLINT CHAR(l) CHAR(l) CHAR (l) VARCHAR(254)
VIEWSCHEMA VIEWNAME DEFINER SEQNO VIEWCHECK
Informacin Esquema que contiene la vista. Nombre de la vista. Identificador de usuario de la persona que cre la vista. Nmero de secuencia de la fila de texto
DB2 especifica los tipos de datos en fonua de texto (por ejemplo,
CHARAC-
TER); el catlogo de Informix utiliza cdigos enteros de tipos de datos.
de SQL.
Tipo de comprobacin de la vista. Indica si la vista es slo de lectura (YIN, s/no). Indica si la definicin de la vista es vlida (YIN, s/no). Camino para la resolucin de las llamadas a funciones de la vista.
READONLY VALID
Otras diferencias reflejan las diferentes posibilidades ofrecidas por las dos
marcas de SGBD:
DB2 permite especificar hasta 254 caracteres de comentarios sobre cada co~ lumna; Informix no ofrece esta caracterstica. El sistema de Informi~ realiza un seguimiento de la IQngitud mxima y mnima de los valores de los datos almacenados en una columna de longitud variable; esta informacin no est disponible directamente a partir del catlogo
TEXT
VARCHAR (3600) Texto de SQL de la definicin de la vista (<<SELECT... ).
del sistema de DB2.
464
465
Tabla 16.7.
Vista SYSCAT. VIEWDEP (OB2)
VIEWSCHEMA
Tipo de datos
CHAR(8) VARCHAR(18)
Informacin Esquema que contiene la vista.

Nombre de la vista.
Identificador de usuario de la persona que cre la vista.
VI EWNAME
DEFINER
BTYPE
CHAR{B)
CHAR(l)
A diferencia de los enfoques de DB2 y de Informix, que dividen el texto de SQL que define la vista en varias filas con nmeros de secuencia si es muy largo, las vistas del sistema de Orade slo contienen una fila por vista. El texto de SQL que define la vista se guarda en una columna LONG (objeto de gran tamao) y se supone que puede albergar millares de caracteres. Las columnas de gran longitud. Las columnas de gran longitud indican la longitud del texLO de SQL de la definicin de la vista. A continuacin se ofrece una consulta para obtener la informacin sobre las vistas de Oracle:
Tipo de objeto del que depende la vista (T = tabla, V = vista, A = alias, etc.).
Hacer una relacin de las vistas del usuario actual y de sus definiciones.
SELECT VIEW_NAME, TEXT_LENGTH, TEXT FROM USER_VIEWS
BSCHEMA
TABAUTH
CHAR(a)
Esquema que contiene el objeto del que depende la vista.

Banderas que indican los privilegios sobre el objeto del que depende la vista.
SMALLINT
Obsrvese que la mayor parte de los productos de SQL interactivo (incluidos los de Oracle) truncan el texto que contiene la definicin de las vistas si es demasiado largo para mostrarlo. El texto real almacenado en la base de datos est completo.
Obsrvese el empleo de DISTINCT para eliminar las filas duplicadas que apareceran para las vistas con definiciones de texto de gran longitud. Quizs una manera ms sencilla de obtener la misma informacin sea consultar directamente la tabla del sistema TABLES de DB2. seleccionando slo las filas que representan vistas, como indica el valor de TYPE:
Comentarios
Los productos de DB2 de IBM permiten asociar hasta 254 caracteres de comentarios a cada tabla, vista y columna definida en la base de datos. Los comentarios permiten almacenar una breve descripcin de las tablas o de los elementos de datos en el catlogo del sistema. Los comentarios se almacenan en las tablas del sistema 5YSCAT. TABLES y SY5CAT. COLUMNS del catlogo del sistema. A diferencia de los dems elementos de las definiciones de las tablas y de las columnas, los comentarios y las etiquetas no se especifican en la instruccin CREATE TABLE. En vez de eso, se emplea la instruccin COMMENT. SU sintaxis se puede ver en la Figura 16.2. A continuacin se ofrecen algunos ejemplos:
Hacer una relacin de las vistas definidas en la base de datos.

SELECT TABSCHEMA, TABNAME, DEFINER FROM SYSCAT.TABLES WHERE TYPE = 'v'
La mayor parte de los productos de SGBD trata las vistas de esta manera dentro de su estructura del catlogo del sistema. Universal Server de Informix. por ejemplo, tiene una tabla del sistema denominada SYSVIEWS que contiene las definiciones de las vistas. Cada una de sus filas guarda un fragmento de la instruccin SELECT de SQL que define una vista. Las definiciones de vistas que abarcan varias filas se manejan mediante nmeros de secuencia, como en DB2. La tabla SYSVIEWS de Informix slo incluye otra columna -el identificador de la tabla que vincula la tabla SYSVIEWS con la fila correspondiente de la tabla SYSTABLES-. Por tanto, Informix duplica menos informacin entre las tablas SYSTABLES y SYSVIEWS, pero el usuario debe reunir las tablas de manera explcita para las solicitudes de informacin a la vista ms frecuentes. Gracle adopta un enfoque parecido haciendo que el texto de SQL defina una vista disponible mediante las vistas del sistema. Al igual que con la informacin de tablas y columnas, hay dos vistas del sistema que resultan interesantes: USER_VIEWS, que contiene infonnacin sobre todas las vistas creadas por el usuario y que son propiedad suya, y ALL_VIEWS, que tambin incluye informacin sobre las vistas accesibles para el usuario en curso pero creadas por otros usuarios.
Definir los comentarios a la tabla
OFICINAS.
COMMENT ON TABLE OFICINAS IS 'Esta tabla almacena los datos de las oficinas de ventas'
Asociar algunos comentarios a las columnas

OFICINAS.
OBJETIVO y VENTAS
de la tabla
COMMENT ON OFICINAS (OBJETIVO 15 'ste es el objetivo anual de ventas de la oficina', VENTAS IS 'stas son las ventas de la oficina durante el ano en curso')
Como se trata de una posibilidad que se arrastra desde los primeros productos de SQL de 1BM, Oracle tambin alberga la instruccin COMMENT ON para "ad-
466
467
Tabla 16.8.
r-COMMENT O N r T A B L E
Vista SYSCAT. REFERENCES (082) Tipo de datos

VARCHAR(18) CHAR(8l VARCHAR (18) CHAR(B) VARCHAR (18) CHAR(8) VARCHAR(18) SMALLINT CHAR(l)
~
nOmbfe-COIUmna--r 15 texto-comentario
~ombre
de la columna
Informacin
CONSTNAME
COLUMN nombre-cualificado-co/umnaJ
Nombre de la restriccin descrita por la fila. Esquema que contiene la restriccin.

Tabla a la que se aplica la restriccin.
TABSCHEMA
nombre-rabia (fOmbre-eOlumna I~ texto-eomemari))
TABNAME DEFINER REFKEYNAME
Creador de la tabla a la que se aplica la restriccin. Nombre de la clave padre. Esquema que contiene la tabla padre. Nombre de la tabla padre. Nmero de columnas de la 'c1ave externa. Regla de eliminacin de la clave externa (A = sin accin, e = cascada, R = restringida, etc.). Regla de actualizacin de la restriccin de la clave externa (A = sin accin, R = restringida). Momento de creacin de la restriccin. Nombre de las columnas de la clave externa. Nombre de las columnas de la clave primaria.
f-LABEL ON
TABLE nombrecolumna
15 texto-etiqueta
REFTABSCHEMA REFTABNAME
COLUMN nomb,e-oual""BdNOlumnaJ
COLCOUNT DELETERULE
L,
Figura 16.2. Diagramas sintcticos de la instruccin
COMMENT
UPDATERULE
CHAR(ll
de D82.
CREATE_TIME FK_COLNAMES
TIMESTAMP VARCHAR(320) VARCHAR (320)
juntar comentarios a las tablas y a las columnas. Los comentarios, sin embargo, no se almacenan igual que el resto de informacin sobre tablas y columnas. Son accesibles mediante las vistas del sistema de Oracle USER_TAB_COMMENTS y USER_COL_COMMENTS. La posibilidad COMMENT de DB2 se ha ampliado a lo largo de los aos para permitir los comentarios sobre las restricciones, los procedimientos almacenados, los esquemas, los espacios de tablas, los disparadores y otros objetos de las bases de datos de DB2. Esta posibilidad no forma parte del estndar de SQL y no ha sido adoptada de manera generalizada por otros productos importantes de SGBD.
PK_COLNAMES
hijo, el nombre de la relacin y las reglas de eliminacin y de actualizacin de la relacin. Se puede consultar para obtener datos sobre las relaciones de la base de datos:
Informacin de relaciones
Con la inlroduccin de la integridad referencial en los principales productos de SGBD empresariales, a mediados de los aos noventa del siglo pasado. los catlogos se ampliaron para que describieran las claves primarias, las claves externas y las relaciones padre!hijo que crean. En DB2, que fue una de las primeras en admitir la integridad referencial, la descripcin la ofrece la tabla del catlogo del sistema SYSCAT. REFERENCES, que se describe en la Tabla 16.8. Cada relacin padre! hijo entre dos tablas de la base de datos viene representada por una sola fila de la tabla SYSCAT. REFERENCES. La fila identifica los nombres de las tablas padre e
Hacer una relaci';de todas las relaciones padre/hijo entre las tablas del usuario actual, que muestre el nombre de la relacin, el nombre de la tabla padre, el de la tabla hijo y la regla de eliminacin de cada una de ellas.
SELECT CONSTNAME, REFTABNAME, TABNAME, DELETERULE FROM SYSCAT.REFERENCES WHERE DEFINER = USER
Hacer una relacin de las tablas relacionadas con la tabla REPRESENTANTES como madres o como hijas.
SELECT REFTABNAME FROM SYSCAT.REFERENCES
468
WHERE UNION SELECT FROM WHERE

TABNAME
=
469
'REPRESENTANTES'
TABNAME SYSCAT.REFERENCES REFTABNAME = 'REPRESENTANTES'
Se puede consultar la tabla una tabla:
SYSCAT. CQLUMNS
para buscar la clave primaria de
Hacer una relacin de las columnas que forman la clave primaria de la tabla
PRODUCTS.
El nombre de las columnas de la clave externa y el de las columnas correspondientes de la clave primaria se relacionan (en forma de texto) en las columnas FK_COLNAMES y PK_COLNAMES de la tabla del sistema REFERENCES. Una segunda
tabla del sistema,
SYSCAT. KEYCOLUSE,
que puede verse en la Tabla 16.9, ofrece
una forma algo ms til de esta informacin. En esta tabla del sistema hay una tabla por cada columna de cada clave externa, de cada clave primaria o de cada restriccin de unicidad definida en la base de datos. Un nmero de secuencia define el orden de las columnas en las claves compuestas. Se puede utilizar esta tabla del sistema para averiguar el nombre de las columnas que vinculan cada tabla con su tabla padre, empleando una consulta como la siguiente:
SELECT PROM WHERE AND ORDER
COLNAME, KEYSEQ, TYPENAME, .SYSCAT.COLUMNS TABNAME = 'PRODUCTOS' KEYSEQ > o BY KEYSEQ
REMARKS
Hacer una relacin de las columnas que vinculan en la relacin denominada ESPARA.
SELECT FROM WHERE aRDER COLNAME, COLSEQ SYSCAT.KEYCOLUSE CONSTNAME = 'ESPARA' BY COLSEQ
PEDIDOS
con
PRODUCTOS
La clave primaria de cada tabla y las relaciones padre/hijo en las que participa tambin se resumen en las tablas del sistema SYSCAT. TABLES y SYSCAT. COLUMNS, que ya se han visto en las tablas 16.2 y 16.4. Si una tabla tiene clave primaria, la columna KEYCOLUMNS de su fila de la tabla del sistema SYSCAT. TABLES es distinta de cero, e indica el nmero de columnas que componen su clave primaria (uno para las claves simples, dos o ms para las claves compuestas). En la tabla del sistema SYSCAT. COLUMNS, las filas de las columnas que confonnan la clave primaria tienen un valor distinto de cero en la columna KEYSEQ. El valor de esta columna indica la posicin (1, 2, etc.) de la columna de la clave primaria dentro de la clave primaria. Tabla 16.9. Vista SYSCAT.KEYCOLUSE (D82) Nombre de la columna
CON8TNAME
Tipo de datos
VARCHAR ( 18)
Informacin Nombre de la restriccin (de unicidad, clave principal o clave externa) descrita por la fila. Esquema que contiene la restriccin. Tabla a la que se le aplica la restriccin. Nombre de la columna en la restriccin. Posicin de la columna en la restriccin.
El soporte del catlogo de DB2 de la clave primaria y de las claves externas es como el que puede hallarse en otros productos SQL importantes. La vista del sistema de Gracle USER_CONSTRAINTS, por ejemplo, ofrece la misma informacin que la tabla del sistema SYSCAT. REFERENCES de DB2. La informacin sobre las columnas concretas que conforman una clave externa O una clave primaria aparece en la vista del sistema de Gracle USER_CONS_COLUMNS, que es anloga a la tablas del sistema de DB2 SYSCAT. KEYCOLUSE. Microsoft SQL Server tiene una estructura del catlogo del sistema parecida, con la informacin sobre las claves externas dividida entre las tablas del sistema SYSFOREIGNKEYS y SYSREFERENCES. Universal Server de Informix. adopta un enfoque parecido al del catlogo de DB2, pero con el mismo tipo de diferencias mostradas anteriormente en su soporte de la informacin de tablas y de columnas. Cada restricci6n definida en la'base de datos genera una fila en la tabla del sistema SYSCONSTRAINTS de Infonnix, que define el nombre de la restricci6n y su tipo (restricci6n de comprbaci6n, clave primaria, referencial, etc.). Esta tabla del sistema asigna un 'nmero interno de identificador de la restriccin para identificar la restriccin en el catlogo. La tabla a la que se aplica la restriccin tambin se identifica mediante un identificador de tabla (que sirve de clave externa a la tabla del sistema SYSTABLES). La informacin adicional sobre las restricciones referenciales (claves externas) se encuentra en la tabla del sistema SYSREFERENCES. En esta tabla, nuevamente, la restriccin, la clave primaria y la tabla padre se identifican mediante identificadores internos que vinculan la informacin sobre la clave externa a las tablas del sistema SYSCONSTRAINTS y SYSTABLES. La tabla SYSREFERENCES contiene informacin sobre las reglas de eliminaci6n y de actualizacin que se aplican a la relacin de clave externa, y otra informacin parecida.
Informacin de usuarios
El catlogo del sistema suele contener una tabla que identifica a los usuarios que estn autorizados a tener acceso a la base de datos. El SGBD puede utilizar esta tabla del sistema para validar el nombre de usuario y la contrasea cuando los usuarios intentan conectarse por primera vez a la base de datos. La tabla puede almacenar tambin otros datos de los usuarios.
TAB8CHEMA TABNAME
CHAR (8) VARCHAR ( 18)
COLNAME
COLSEQ
VARCHAR (18 )
SMALLINT
470
471
. acin de los usuarios en la tabla SYSUSERS, .que SQL Server almacena mf~~ da fila de la tabla describe a un solo usuano o puede verse en la Tabla 16.1 . da seguridad de SQL Server. Informix adopta un e 'os del esquema . gropo d e usua,n tabla del sistema que tambin se denomlOa SYSUSERS. ~Jdo~una . '6 enf oque P d' t de Gracle se denomina ALL USERS. A contlOuaCl n pueL tabla correspon len e . dI' d:n verse dos consultas equivalentes que generan una relaclOo e os usuarios autorizados para SQL Server y para Gracle:
I
Informacin de privilegios
Adems de almacenar la informacin sobre la estructura de la base de datos, el catlogo del sistema suele almacenar la informacin que necesita el SaBD para hacer que se cumpla la seguridad de la base de datos. Como se describi en el Captulo 15, los diferentes productos de SaBD ofrecen variaciones del esquema de privilegios bsico de SQL. Estas variaciones se reflejan en la estructura de los catlogos del sistema de las diferentes marcas de SORD. DB2 tiene uno de los esquemas ms generales para los privilegios de los usuarios, que detalla hasta cada una de las columnas de las tablas. La Tabla 16.11 muestra los catlogos del sistema de DB2 que almacenan la informacin sobre los privilegios y describe brevemente el papel de cada uno. El esquema de autorizaciones utilizado por SQL Server resulta ms bsico y directo que el de DB2. Trata de manera uniforme las bases de datos, las tablas, los procedimientos almacenados, los disparadores y otras entidades como objetos a los que se les aplican los privilegios. Esta estructura directa se refleja en la tabla del sistema SYSPROTECTS, que puede verse en la Tabla 16.12, que implementa todo el esquema de privilegios de SQL Server. Cada fila de la tabla representa una nica instruccin GRA1'lT o REVQKE formulada.
Hacer una relacin de todos los identificadores de usuario conocidos para SQL Serv"
SELECT NAME FRDM SYSUSERS WHERE UID <> GIO
Hacer una relacin de todos los identificadores de usuario conocidos para OracIe.
SELECT USERNAME
FROM ALL_USERS
La tabla del catlogo del sistema de DB2 que contiene lo~ ~om~res de los usuarios tambin contiene la informacin sobre sus papeles y pn~I1eglos en la base de datos (es decir, si son administradores de la base de datos. SI pueden crear t~bl~s, si pueden crear programas que tengan acceso a la base de dat~s, etc.). A contlnua. puede verse la consulta equivalente a las consultas antenores para la recupe~~c~n de los nombres de los usuarios del catlogo de DB2:
Tabla 16.11.
Vistas del catlogo del sistema de DB2 que implementan los permisos
rabia del sistema

TABAUTH
Papel
Implementa los privilegios en el nivel de tablas indicando los usuarios que tienen permiso para el acceso a cada tabla y para cada operacin (SELECT, INSERT, OELETE, UPDATE, ALTER e
INDEX).
Hacer una relacin de todos los identificadores de usuario conocidos para

DB2.
SELECT OISTINCT GRANTEE FROM SYSCAT.OBAUTH WHERE GRANTEETYPE ; 'u' COLAUTH
Implementa los privilegios en el nivel de columnas indicando los usuarios que tienen penniso para actualizar O hacer referencia a cada columna de cada tabla. Detenruna los usuarios que tienen permiso para conectarse con la base de datos, para crear tablas y para llevar a cabo diferentes labores de administracin de la base de datos. Implementa los privilegios en el nivel del esquema indicando los usuarios que tienen permiso para crear, descartar o modificar objetos (tablas, vistas, dominios, etc.) dentro del esquema. Implementa los privilegios en el nivel de ndices indicanao los usuarios que tienen privilegios de control sobre diferentes ndices. Implementa los privilegios de acceso mediante programacin indicando los usuarios que tienen la capacidad de controlar, enlazar (crear) y ejecutar diferentes programas de acceso a la base de datos (<<paquetes).
DBAUTH
SCHEMAAUTH
Tabla 16.10.
Columnas seleccionadas de la tabla SYSUSERS (SQL Serverl
uid gid name
Tipo de datos
SMALLINT SMALLINT SYSNAME
Informacin
Nmero interno de identificador de usuario en la base de datos. Nmero interno de identificador de grupo de usuarios en la base de datos. Nombre del usuario o del grupo de usuarios.
INDEXAUTH
PACKAGEAUTH
472
473
id
uid
Tipo de datos
INT
SMALLINT
Informacin
Identificador interno de los objetos protegidos.
Identificador interno de los usuarios o grupos con privilegios.
.laDla
oel sistema
Contenido Una fila por usuario (<<Identificador de autorizacin) de la agrupacin del catlogo. Una fila por esquema de la agrupacin del catlogo. Una fLIa por dominio o columna definidos con un tipo de datos. Una fila por dominio. Una fila por restriccin de dominio. Una fila por tabla o vista. Una fila por tabla o vista. Una fila por columna de cada definicin de tabla o vista. Una fila por tabla a la que se haga referencia en cada definicin de una vista (si la vista la define una consulta a varias tablas, habr una fila por tabla). Una fila por columna a la que se haga referencia en una vista. Una fila por restriccin de tabla especificada en una definicin de tabla. Una fila por columna especificada en cada clave principal, clave externa o restriccin de unicidad (si se especifican varias columnas en la definicin de una clave o de restriccin de unicidad, habr varias filas que representen esa restriccin). Una fila por definicin de clave externa especificada en una definicin de tabla. Una fila por restriccin de comprobacin especificada en una definicin de tabla. Una fila por tabla a la que se haga referencia en cada restriccin de comprobacin, restriccin de dominio o aserto. Una fila por colUmna a la que se haga referencia en cada restriccin de comprobacin, restriccin de dominio o aserto. Una fila por aserto definido. Una fila por privilegio concedido sobre cada tabla. Una fila por privilegio concedido sobre cada columna. Una fila por conjunto de caracteres definido. Una fila por secuencia de ordenacin definida. Una fila por traduccin definida. Una fila por lenguaje (por ejemplo, COBOL, admitido por esa marca de SGBD.
USERS SCHEMATA DATA_TYPE_DESCRIPTOR DOMAINS DOMAIN_CONSTRAINTS -TABLES VIEWS COLUMNS
actino
TINYINT
TINl;"INT
Cdigo numrico del privilegio.

Cdigo numrico de concesin O retirada.
protecttype
columns
VARBINARY (32) Mapa de bits de los privilegios de actualizacin en el nivel de columnas.
El esquema de la informacin de SQL2

El estndar SQL2 no especifica de manera directa la estructura del catlogo del sistema que deben albergar las implementaciones del SOBD. En la prctica. dadas las caractersticas tan diferentes admitidas por las distintas marcas de SGBD y las grandes diferencias entre los catlogos del sistema que ya estaban utilizando los
VIEW_TABLE_USAGE
VI EW_COLUMN_USAGE TABLE_CONSTRAINTS KEY_COLUMN_USAGE
productos comerciales de SQL cuando se adopt el estndar SQL2, habra sido

imposible alcanzar un acuerdo sobre una definicin estndar de catlogo. En vez de eso, los redactores del estndar SQL2 definieron un catlogo del sistema idealizado que los fabricantes de SGBD podran disear si estuvieran creando un SGBD para albergar el estndar SQL2 desde cero. Las tablas de este catlogo idealizado del sistema (denominado esquema de definicin en el estndar) se resumen en la
Tabla 16.\3. El estndar SQL2 no exige que el SGBD admita realmente las tablas del catlogo del sistema de la Tabla 16.13, ni ningn catlogo del sistema. En vez de eso,
define una serie de vistas de esas tablas del catlogo que identifican los objetos de la base de datos "que son accesibles para el usuario actual. (Estas vistas del catlogo se denominan en el estndar esquema de la informacin.) Cualquier SGBD que proclame el nivel de cumplimiento intermedio o completo del estndar SQL2 debe admitir esas vistas. Esto da, de hecho, al usuario una manera normalizada de obtener ioformacin sobre los objetos de la base de datos que tiene disponibles utilizando SQL estndar con las vistas del catlogo. Obsrvese que el soporte de las vistas del catlogo 'no se exige para el nivel de cumplimiento inicial del estndar SQL2. En la prctica, las principales implementaciones comerciales de SQL han ido admitiendo poco a poco el esquema de la informacin de SQL2, generalmente definiendo las vistas correspondientes de las tablas de sus propios catlogos del sistema. En la mayor parte de los casos, la informacin en los propios catlogos del sistema de los SGBD es lo bastante parecida a la exigida por el estndar como para que el primer noventa por ciento de la conformidad con el estndar SQL2 resulte relativamente sencillo. El ltimo diez por ciento se ha mostrado mucho ms difcil, dadas las variaciones entre las marcas de SGBD y el. grado en que,
REFERENTIAL_CONSTRAINTS CHECK_CONSTRAINTS CHECK_TABLE_USAGE CHECK_COLUMN_USAGE ASSERTIONS TABLE_PRIVILEGES COLUMN_PRIVILEGES CHARACTER_SETS COLLATIONS TRANSLATIONS SQL_LANGUAGES
e, etc.)
_1
474
Captulo 76: Catalogo del sistema
475
incluso las vistas del catlogo de SQL2, muestran las caractersticas y posibilidades concretas del SGBD subyacente. En consecuencia, el soporte completo de las vistas del catlogo de SQL2 se ha implementado generalmente junto con ,cada nueva versin importante del producto de SOBD, acompaado por modificaciones subyacentes en el ncleo del software del SGBD. Las vistas de los catlogos exigidas por,el estndar SQL2 se resumen en la Tabla 16.14, junto con una breve descripcin de la informacin contenida
Tabla 16.14.
Vst~~
del catlogo que el estndar SQL2 hace obligatorias (con tiContenido Una fila por uso concedido por el usuario actual o que le haya sido otorgado. Una fila por .re~triccin de tabla (clave primaria, clave externa, restriCCIones de unicidad o restriccin de comp~bacin) especifica~a sobre una tabla propiedad del usuano en curso que especifica el nombre de la restricci6n ' la tabla, el tipo de restriccin y su diferibilidad. Una fila por restriccin referencial (definici6n de clave externa) para una tabla propiedad del usuario en curso que especifica el nombre de la res[ricci6n y los de las tablas madres'e hijas. Una fila por restriccin de comprobacin para una tabla propiedad del usuario en curso. Una fila por columna especificada en cada clave primaria, clave externa o restricci6n de unicidad de una tabla propiedad del usuario en curso que especifica el nombre de la columna y el de la tabla y la posicin de la columna en la clave. Una ~la por aserto propiedad del usuario en curso que espeCIfica el nombre y la diferibilidad. Una fila por definicin de conjunto de caracteres accesible para el usuario en curso. Una fila por definici6n de secuencia de ordenacin accesible para el usuario en curso. Una fila por definicin de traducci6n accesible al usuario en curso. Una fila por tabla, a la que se haga referencia en cada defini.cin de vista propiedad del usuario en curso, que espeCIfica el nombre de la tabla. Una fila por columna, a la que se haga referencia en una vista propiedad del usuario en curso, que especifica el nombre de la columna y el de la tabla que la contiene. Una fila por tabla a la que se haga referencia en cada restriccin de comprobaci6n, restriccin de unicidad definicin de clave externa o aserto propiedad del usuari actual. Una fila por columna a la que se haga referencia en cada restriccin de comprobacin, restriccin de unicidad, definicin de clave externa y aserto propiedad del usuario actual. Una fila por lenguaje (por ejemplo, COBOL, e, etc.) admitido por la marca de SGBD que especifica el nivel de conformidad con el estndar SQL2, el tipo de SQL soportado, etc.
nuaclon)
'Vista del catlogo del sistema
TABLE_CONSTRAINTS
Tabla 16.14.
Vistas del catlogo que el estndar SQL2 hace obligatorias
Vista del catlogo del sistema

INFORMATION_SCHEMA_ CATALOG_NAME
Contenido Una sola fila que especifica el nombre de la base de datos para cada usuario (<<catlogo en la terminologa del estndar de SQL2) que describe este esquema de la informacin. Una fila por esquema de la base de datos propiedad del usuario en curso que especifica el nombre del esquema, el conjunto de caracteres predeterminado, etc. Una fila por dominio accesible para el usuario en curso que especifica el nombre del dominio, el tipo de datos subyacente, el conjunto de caracteres, la longitud mxima, la escala, la precisin, etc. Una fila por restriccin de dominio que especifica el nombre de la restriccin y sus caractersticas de diferibilidad. Una fila por tabla o vista accesible para el usuario en curso que especifica el nombre y el tipo (tabla o vista). Una fila por vista accesible para el usuario en curso que especifica el nombre, la upcin de comprobacin y la posibilidad de actualizacin. Una fila por columna accesible para el usuario en curso que especifica el nombre, la tabla o vista que la contiene, el tipo de datos, la precisin, la escala, el conjunto de caracteres, etc. Una fila por privilegio sobre una tabla concedido por el usuario en curso, o que le haya sido otorgado, que especifica el tipo de tabla, el tipo de privilegio, el concedente y el concesionario, y si el usuario actual puede transmitir el privilegio. Una fila por privilegio sobre una columna concedido al usuario en curso o que le haya sido otorgado a l, que especifica 'la tabla y la columna, el tipo de privilegio, el concedente y el concesionario y si el usuario actual puede transmitir el privilegio.
(contina)
REFERENTIAL_CONSTRAINTS
CHECK_CQNSTRAINTS
SCHEMATA
DOMAINS
ASSERTIONS CHARACTER_SETS COLLATIONS TRANSLATIONS
DOMAIN_CONSTRAINTS TABLES VIEWS
COLUMNS
476
477
en cada vista. A continuacin se ofrecen algunas consultas de ejemplo que pueden utilizarse para extraer informacin sobre la estructura de la base de dalOs a partir de las vistas del catlogo del sistema definidas por SQL2:
Hacer una relacin de Jos nombres de las tablas y vistas propiedad del usuario actual.
SELECT TABLE_NAHE FROM TABLES
Otra informacin del catlogo

El catlogo del sistema es un reflejo de las posibilidades y caractersticas del SGBD que lo utiliza. Debido a las muchas ampliaciones de SQL y caractersticas adicionales ofrecidas por los productos de SGBn populares, los catlogos del sistema siempre contienen varias tablas exclusivas de cada SGBD. A continuacin se ofrecen unos cuantos ejemplos: DB2 Y Oracle incluyen alias y sinnimos (nombres alternativos de las tablas). DB2 almacena la informacin sobre los alias con otra informacin sobre las tablas en la tabla del sistema SYSCAT. TABLES. Orade deja la informacin sobre los sinnimos disponible mediante la vista del sistema
OSER_SYNONYMS.
Hacer una relacin de/nombre, posicin y tipo de datos de todas las columnas de todas las vistas.
SELECT TABLE_NAME, C.CQLUMN_NAME, QRDINAL_POSITION, DATA_TYPE FROM COLUMNS WHERE (COLUMNS.TABLE_NAME IN (SELECT TABLE_NAME FROM VIEWS))
Determinar el nmero de columnas de la tabla denominada OFICINAS.

5ELECT COUNT (*)
FRDM COLUMNS WHERE (TABLE_NAME = 'OFICINAS')
SQL Server incluye varias bases de datos con nombre. Tiene una tabla del sistema denominada SYSDATABASES que identifica las bases de datos administradas por cada servidor. Muchas marcas de SGBD incluyen ahora los procedimientos almacenados, y el catlogo contiene una o varias tablas que los describen. Sybase almacena la informacin sobre los procedimientos almacenados en la tabla del sistema SYSPROCEDURES. lngres incluye las tablas distribuidas entre varios volmenes de disco. La tabla del sistema lIMULTI_LOCATIONS realiza el seguimiento de las ubicaciones de las tablas multivolumen.
El estndar define tambin tres dominios que utilizan las vistas del catlogo y que tambin estn disponibles para los usuarios. Estos dominios se resumen en la rabIa 16.15. El Apndice E contiene un resumen completo de las principales vistas del catlogo de SQL2 y de su contenido.
Resumen
El catlogo del sistema es un conjunto de tablas del sistema que describe la estructura de las bases de datos relacionales: El SaBD mantiene los datos de las tablas del sistema, actualizndolos a medida que se modifica la estructura de la base de datos. Los usuarios pueden consultar las tablas del sistema para hallar informacin sobre las tablas, las columnas y los privilegios de la base de datos. Las herramientas de consulta de la parte visible al usuario utilizan las tablas del sistema para ayudar a los usuarios a desplazarse por la base de datos de una manera amistosa para el usuario. El nombre y la organizacin de las tablas del sistema varan ampliamente de una marca de SaBD a otra; incluso hay diferencias entre los diferentes productos de SGBD del mismo fabricante, que reflejan las diferentes estructuras internas y las diferentes posibilidades de cada producto. El estndar SQL2 no exige que el SGBD tenga realmente un conjunto de tablas del sistema, pero define un conjunto de vistas estndar del catlogo para los productos que proclaman niveles superiores de conformidad con SQL2.
Tabla 16.15.
Dominios definidos por el estndar SQL2
Dominio del sistema ,

SQL_IDENTIFIER
Valores
Dominio de todas las cadenas de caracteres de longitud variable que son identificadores legales de SQL segn el estndar SQL2. Los valores extrados de este dominio son nombres de tabla o de columna, etc. legales. Dominio de todas las cadenas de caracteres de longitud variable con una longitud entre cero y la longitud mxima admitida por el SOBD. Los valores extrados de este dominio son cadenas de caracteres legales. Dominio de todos los nmeros no negativos, de cero hasta el valor mximo representado por INTEGER para el SGBD. Los valores extrados de este dominio son cero o un nmero positivo legal.
CHARACTER_DATA
CARDINAL_NUMBER
Parte V
PROGRAMACiN CON Sal
Adems de su papel como lenguaje de acceso a datos, SQL admite el acceso a bases de datos mediante programas de aplicacin. Los captulos 17 al 19 describen las caractersticas especiales de SQL y las tcnicas que se usan para programar con SQL. El Captulo 17 describe SQL incorporado. la tcnica de programacin ms antigua, y an admitida por muchos productos. usa para SQL dinmico, una forma avanzada de SQL incorporado que construir herramientas de bases de datos de propsito general, se describe en el Captulo 18. El Captulo 19 describe una alternativa a SQL incorporado -la interfaz de llamada a funciones proporcionada por muchos productos SGBD populares, con creciente popularidad.
se
CAPTULO
17
SOL incorporado
SQL es un lenguaje dual. Es tanto un lenguaje interactivo de bases de datos utilizado para consultas y actualizaciones ad hoc como un lenguaje de programacin de bases de datos empleado por los programas de las aplicaciones para el acceso a las bases de datos. En su mayor parte, el lenguaje SQL es idntico en ambas modalidades. La naturaleza dual de SQL tiene varias ventajas: Resulta relativamente sencillo para los programadores aprender a escribir programas que tengan acceso a la base de datos. Las opciones disponibles mediante el lenguaje interactivo de consultas tambin estn disponibles de manera automtica para los programas de las aplicaciones. Las instrucciones de SQL que se van a utilizar en los programas pueden probarse primero empleando SQL interactivo, introducirlas posteriormente en el programa. Los programas pueden trabajar con tablas de datos y resultados de consultas en lugar de desplazarse por la base de datos. Este captulo resume los tipos de SQL para programacin ofrecidos por los principales productos basados en SQL, y describe luego el lenguaje SQL para p,ogramaci6n utilizado por los productos de SQL de IBM, que se denomina SQL incorporado.
",
Tcnicas de programacin en SOL
}I
.:,
SQL es un lenguaje y puede utilizarse para programacin, pero sera incorrecto llamar a SQL lenguaje de programacin. SQL carece incluso de las caractersticas ms primitivas de los verdaderos lenguajes de programacin. No tiene ningn modo de declarar las variables, ninguna instrucci6n GOTO, ninguna instruccin IF para comprobar las condiciones, ninguna instrucci6n FOR, DO ni WHILE para crear bu-
481
482
Captulo 17: SOL incorporado
483
eles, ninguna estructura de bloques, elc. SQL es un sub,lenguaje d~ bases de d~t~s que maneja tareas de gestin de bases de datos de finahdad especial. Para escnhlf programas que tengan acceso a las bases de datos, hay que comenzar con un lenguaje convencional de programacin, como COBOL, PUl, FORTRAN, Pascal o C. y luego aadir SQL al programa. . El eSlndar SQL de ANSUISO inicial se ocupaba excluSIvamente de esle empleo de SQL para la programacin. De hecho. ni siquiera inclua la io.struccin SELECT interactiva que se describe en los captulos 6 a 9. S6lo especlficaba la instruccin SELECT para programacin que se describe ms adelante en el ap~ tado Recuperacin de datos con SQL incorporado. El eSlndar SQL2, pubh-. cado en 1992, ampli su mbito para incluir el SQL mteractIvo (denommado l/amada directa a SQL en el estndar) y formas ms avanzadas del SQL para programacin (las posibilidades dinmicas de SQL que se describen en el Captulo 20). . Los fabricantes de bases de datos comerciales de SQL ofrecen dos tCnIcas bsicas para el empleo de SQL en los programas de las aplicaciones:
S~rver, Microsoft introdujo la conectividad abierta de bases de datos (O D .. . pen arabase eonneCtlVlty, ODBC) , otra API a la que se pueden realizar llamadas. DBC se b.asa, gros~o modo, en la API de SQL Server, pero con los objetivos aadidos de ser mdependlente de las bases de datos y de permitir el acceso concurrente a dos o ms marcas de SGBD mediante una API comn. Ms recientemente ha aparecido la conectividad Java para bases de datos (Java Da/abase Connectivity, JDBC) como una API importante para el acceso a bases de d~tos relacionales desde los programas escritos en Java. Con la popularidad creciente de las API a las que se puede realizar llamadas, tanto el enfoque de las llamadas como el de la incorporacin se hallan hoy en da en uso. En general. los programadores. que utilizan l~nguajes de programacin antiguos, como COBOL y ensamblador, tienden a prefenr el enfoque del SQL incorporado. Los programadores que utilizan lenguajes ms modernos, como C++ y Java, tienden a preferir el enfoque de las APl a las que se pueden realizar llamadas. La tabla siguiente resume las interfaces de programacin ofrecidas por algunos de los principales prnductos de SGBD basados en SQL:
SQL incorporado. En este enfoque las instrucciones de SQL se incorporan directamente al cdigo fuente del programa, entremezclado con las dems instrucciones del lenguaje de programacin. Se utilizan instrucciones especiales de SQL incorporado para recuperar datos para el programa. Un precompilador especial de SQL acepta el cdigo fuente combinado Y. junto con otras herramientas de programacin, lo convierte en un programa ejecutable. Interfaz para la programacin de aplicaciones. En este enfoque el pro grama se comunica con el SGBD mediante un conjunto de llamadas a funciones denominado interfaz para la programacin de aplicaciones, o API (Application Program Interface). El programa pasa las instrucciones de SQL
al SGBD mediante las llamadas de la API y uliliza esas llamadas de la API para recuperar los resultados de las consultas. Este enfoque no necesita ningn precompilador especial. Los primeros productos de SQL de IBM ulilizaban el enfoque del SQL incorporado, y la mayor parte de los productos comerciales de SQL lo ado~t~ron tambin en los aos ochenta del siglo pasado. El estndar ANSI/ISO onglOal para SQL slo especificaba un mdulo de lenguaje para el SQL para programacin muy poco prctico, pero los productos comerciales de SQL siguieron utilizando el estndar de facto de IBM. En 1989, el estndar ANSUISO se ampli para incluir una definicin del modo de incorporar las instrucciones de SQL en los lenguajes de programacin Ada, C, COBOL, FORTRAN, Pascal y PUl, siguiendo esta vez el enfoque de IBM. El estndar SQL2 continu esta especificacin. En paralelo con esta evolucin del SQL incorporado, varios fabricantes de SGBD que se centraron en los sistemas de minicomputadoras introdujeron en los aos ochenta API para las bases de datos a las que se poda realizar llamadas. Cuando se introdujo el SGBD Sybase, slo ",~ ..;ca una API al que se podan realizar llama das. SQL Server de Microsofl, que procede del SGBD Sybase, tambin utilizaba de manera exclusiva el enfoque de las APIs. Poco despus del lanzamiento de SQL
DBMS DB2
API a la que se pueden realizar llamadas
Soporte de lenguajes de SQL incorporado
ODBC, IDBC ODBC, IDBC DB Library (dblib), ODBC
APL, ensamblador, BASIC, COBOL, FORTRAN, Java, PUl

C,COBOL
Informix Microsoft SQL Server

MySQL
Orade
(propietaria), ODBC. IDBC, Perl, PHP, Te!. .. Interfaz de llamadas de Orade (Orade eaIl Interface, OC!) ODBC,
C~api
Ninguno
C, COBOL, FORTRAN, Pascal, PUl, Java
IDBC
Sybase
DB Library (dblib), ODBC, IDBC
C, COBOL
Las tcnicas bsicas de SQL incorporado, denominado SQL esttico. se describen en este captulo. Algunas caractersticas avanzadas de SQL incorporado, denominado SQL dinmico, se estudian en el Caplulo 20. Las API de SQL a las que se puede realizar llamadas, incluidas la API de SybaseJSQL Server, ODBC y IDBe, se tratan en el Captulo 21.
Procesamiento de instrucciones en el SGBD

Para comprender cualquiera de las tcnicas del SQL para programacin resulta til entender un poco mejor el modo en que el SGBD procesa las instrucciones de
484
Capitulo 17: SOL incorporado
485
SQL. Para procesar una instruccin de SQL, el SOBO recorre cinco etapas, que pueden verse en la Figura 17.1:
1.
2.
El SGBD comienza analizando la instruccin de SQL. Divide la instruccin en las palabras que la componen, se asegura de que tiene un verbo vlido. clusulas legales, etctera. Los errores de sintaxis y los de escritura pueden detectarse en esta etapa. El SGBD valida la instruccin. Compara la instruccin con el catlogo del sistema. Comprueba si existen en la base de datos todas las tablas mencio-
3.
4.
Introduccin a SOL
5.
nadas en la instruccin, si existen todas las columnas y los nombres de columna no son ambiguos, y si el usuario tiene los privilegios necesarios para ejecutar la instrucci6n. Los errores semnticos se detectan en esta etapa. El SOBD optimiza la instruccin. Explora varias maneras de ejecutar la instruccin. Comprueba si se puede utilizar algn ndice para acelerar una bsqueda, si el SOBD debe aplicar antes una condicin de bsqueda a la Tabla A y luego reunirla con la Tabla B o comenzar con la reunin y utilizar la condicin de bsqueda ms tarde, o si se puede evitar una bsqueda secuencial por una tabla o reducirla a un subconjunto de esa tabla. Tras explorar las alternativas el SOBO escoge una de ellas. El SOBO genera entonces un plan de aplicacin de la instruccin. El plan de aplicacin es una representacin binaria de los pasos necesarios para ejecutar la instruccin; es el equivalente para el SGBD del cdigo ejecutable. Finalmente, el SGBD lleva a cabo la instruccin ejecutando el plan de aplicacin.
5ELECT A,B,C FROM X,Y

WHERE A<5000
AND c::::'ABC'
t
Anlisis de la instruccin
t
Validacin de la instruccin
t
Optimizacin de la instruccin
....
t
Generacin del plan de aplicacin
Plan
t
t
Forma binaria de la instruccin de Sal
Obsrvese que las etapas de la Figura 17.1 varan en el grado de acceso a la base de datos que necesitan y en la cantidad de tiempo de CPU que emplean. El anlisis de las instrucciones de SQL no necesita el acceso a la base de datos y suele poder hacerse muy rpidamente. La optimizacin, por su parte, es un proceso muy intensivo en CPU y necesita el acceso al catlogo del sistema de la base de datos. Para consultas complejas a varias tablas puede que el optimizador explore ms de una docena de maneras diferentes de llevar a cabo la consulta. No obstante, el coste en tiempo de procesamiento de la computadora en caso de realizar la consulta de manera errnea suele ser tan alto en comparacin con el coste de realizarla de manera correcta (o, como mnimo, de una manera mejor) que el tiempo empleado en la optimizacin se recupera con creces con la mayor velocidad de ejecucin de la consulta. Cuando se escribe una instruccin de SQL para SQL interactivo, el SOBO re corre las cinco etapas mientras se espera la respuesta. El SOBO tiene pocas opcio nes en este caso -no conoce la instrucci6n que se va a escribir hasta que se escri~ be, por lo que no puede adelantar ningn fragmento del procesamiento-. En el SQL para programacin, sin embargo, la situacin es bastante diferente. Parte de las primeras etapas pueden realizarse en el momento de la compilacin, mientras el programador desarrolla el programa. Esto deja nicamente las ltimas etapas para realizarlas en el momento de la compilacin, mientras el usuario ejecuta el programa. Al utilizar SQL para programacin, todos los productos de SGBO intentan pasar todo el procesamiento posible al momento de la compilacin, ya que, una vez desarrollada la versin definitiva del programa, los usuarios pueden ejecutarla millares de veces en una aplicacin de produccin. En concreto, el objetivo es pasar la optimizacin al momento de la compilacin siempre que resulte posible.
Ejecucin del plan de aplicacin
Conceptos de SOL incorporado

La idea central del SQL incorporado es entremezclar las instrucciones de SQL en los programas escritos en lenguajes de programacin anfitriones, como C, Pascal,
Figura 17.1.
Procesamiento de una instruccin de SOL por el SGBD.
486
487
COBOL, FORTRAN, PUl o ensamblador. SQL incorporado utiliza las tcnicas siguientes para incluir las instrucciones de SQL: Las instrucciones de SQL se entremezclan con las instrucciones del lenguaje anfitrin en el programa fuente. Este programa fuente con SQL incorporado se remite a un precompilador, que procesa las instrucciones de SQL. Se puede hacer referencia a las variables del lenguaje de programacin anfitri6n en las instrucciones de SQL incrustadas, lo que permite que las instrucciones de SQL utilicen los valores calculados por el programa. Las variables del lenguaje del programa las utilizan tambin las instrucciones de SQL incorporado para recibir el resultado de las consultas de SQL. lo que permite que el programa utilice y procese los valores recuperados. Las variables especiales del programa se utilizan para asignar valores NULL a las columnas de la base de datos y para albergar la recuperacin de valores NULL de la base de datos. Varias instrucciones nuevas de SQL, que son exclusivas del SQL incorporado, se aaden a SQL interactivo, para proporcionar el procesamiento fila a fila del resultado de las consultas. La Figura 17.2 muestra un programa sencillo de SQL incorporado, escrito en C. El programa ilustra muchas de las tcnicas de SQL incorporado, pero no todas. El programa pide al usuario el nmero de una oficina. recupera la ciudad, la regin, las ventas y el objetivo de la oficina y los muestra en ]a pantalla. No hay que preocuparse si el programa parece extrao, ni si no se pueden comprender todas las instrucciones que contiene antes de leer el resto del captulo. Uno de los inconvenientes del enfoque del SQL incorporado es que el cdigo fuente de los programas se convierte en una mezcla impura de dos lenguajes diferentes, lo que hace que el programa sea difcil de comprender sin formacin tanto en SQL corno en el lenguaje de programacin. Otro inconveniente es que el lenguaje SQL incorporado utiliza estructuras de SQL que no se utilizan en el SQL interactivo, como la instruccin WHENEVER y la clusula INTO de la instruccin SELECT -que se utilizan en este programa.
main()
{
exec sql include sqlca; exec sq1 begin declare section; int numoficina; /* nmero de la oficina (obtenido del usuario) */ char nombreciudad(16]; /* nombre de la ciudad recuperado ./
char
nombreregion[~l);
/- nombre oe la regin recuperaoo
~I
float valobjetivo; /~ objetivo y ventas recuperados */ float valventas; /. objetivo y ventas recuperados ./ exec sq1 end declare section;
/* Configuracin del procesamiento de errores */ exec sq1 whenever sq1error goto query_error; exec sq1 whenever not found goto bad-number;
/* pide al usuario el nmero de oficina */ printf(-Introduzca el nmero de oficina:"); scanf("%d", &numoficina);
; ; ERROR EN ORIGINAL: ;
/* Ejecuta la consulta de SQL ./ exec sql select ciudad, region, objetivo, ventas from oficinas where oficina ~ ;numoficina into ;nombreciudad, ;nombreregion, ;valobjetivo, ;valventas:
/. Muestra el resultado ./ printf(-Ciudad: %s\n", nombreciudad); printf(-Regin: %s\n-, nombreregion): printf("Objetivo: %f\n", valobjetivo); printf("Ventas: %f\n", valventas); exit{) ; query_error: printf("Error de SQL: %ld\n", sq1ca.sq1code); exit(); bad_nwnber: printf("Nmero de oficina no vlido.\n"); exit{) ;
Desarrollo de un programa SOL incorporado

Los programas de SQL incorporado contienen una mezcla de instrucciones de SQL y del lenguaje de programacin, por lo que no pueden remitirse directamente al compilador del lenguaje de programacin. En lugar de eso, siguen un proceso de desarrollo de varias etapas, que puede verse en la Figura 17.3. Las etapas de la figura son realmente las empleadas por las bases de datos de los grandes sistemas de IBM (DB2, SQLlDS), pero todos los productos que admiten SQL incorporado utilizan un proceso parecido: 1. El programa fuente de SQL incorporado se remite al precompilador de SQL, una herramienta de programacin. El precompilador explora el prograina, busca las instrucciones de SQL incorporado y las procesa. Se ne-
Figura 17.2.
Programa tpico de SOL incorporado.
2.
cesita un precompilador diferente para cada lenguaje de programacin admitido por el SGBD. Los productos comerciales de SQL suelen ofrecer precompiladores para uno O varios lenguajes, entre ellos C, Pascal, COBOL, FORTRAN, Ada, PUl, RPG Y varios lenguajes de ensamblador. El precompilador genera como resultado dos archivos diferentes. El primer archivo es el programa fuente, despojado de las instrucciones de SQL
488
489
3.
4.
5.
incorporado. En su lugar el precompilador coloca llamadas a las rutinas privadas del SOBD que ofrecen el enlace en tiempo de ejecucin entre el programa y el SOBD. Generalmente, los nombres y las secuencias de llamada de estas rutinas slo los conoce el precompilador y el SOBD; no se trata de una interfaz pblica con el SGBD. El segundo archivo es una copia de todas las instrucciones de SQL incorporado utilizadas en el programa. Este ar.chivo se denomina a veces m6dulo de solicitudes a la base de datos o DBRM (Database Request Madu/e). El resultado para el archivo fuente del precompilador se remite al compilador estndar para el lenguaje de programacin anfitrin (el compilador de e o de COBOL). El compilador procesa el cdigo fuente y genera como resultado cdigo objeto. Obsrvese que esta etapa no tiene nada que ver con el SOBD ni con SQL. El enLazador (linker) acepta los mdulos objeto generados por el compilador, los enlaza con varias rutinas de biblioteca y genera un programa ejecutable. Entre las rutinas de biblioteca enlazadas con el programa ejecutable estn las rutinas privadas del SGBD que se describen en la Etapa 2. El mdulo de solicitudes a la base de datos generado por el precompilador se remite a un programa BIND especiaL Este programa examina las instrucciones de SQL, las analiza, las valida y optimiza, y genera un plan de aplicacin para cada instruccin. El resultado es un plan de aplicacin combinado para todo el programa, que representa una versin ejecutable por el SGBD de las instrucciones de SQL. El programa BIND almacena el plan en la base de datos, normalmente asignndole el nombre del programa de aplicacin que lo cre.
Programa fuente de SQl incorporado
--- ---- ---- --
Programa fuente despojado
..
Precompilador
1
ibliote,
Mdulo de solicitud a la base de datos
Compilador
.. ..
BIND
.. ..
Cdigo objeto
SGSD
Plan aplicad
Las etapas de desarrollo de los programas de la Figura 17.3 se correlacionan con las etapas de procesamiento de las instrucciones por el SGBD de la Figura 17.1. En concreto, el precompilador suele tratar el anlisis de las instrucciones (el primer paso) y la utilidad BIND trata la comprobacin, la optimizacin y la generacin de los planes (las etapas segunda, tercera y cuarta). Por tanto, cuando se utiliza SQL incorporado, las cuatro primeras etapas de la Figura 17.1 tienen lugar en el momento de la compilacin. Slo la quinta etapa, la ejecucin real del plan de ejecucin, sigue hacindose en el momento de la ejecucin. El proceso de desarrollo del SQL incorporado divide el programa fuente con SQL incorporado original en dos partes ejecutables: Un programa ejecutable. Almacenado en un archivo de la computadora con el mismo formato que cualquier otro programa ejecutable Un plan de aplicacin ejecutable. Almacenado en la base de datos con el formato esperado por el SOBD El ciclo de desarrollo del SQL incorporado puede parecer engorroso, y es ms incmodo que el desarrollo de programas normales de o de COBOL. En la mayor parte de: los casos, todas las etapas de la Figura 17.3 se hallan automatizadas en un solo procedimiento de comandos, de modo que cada una de las etapas resul-
..
..
Enlazador
..
'rogram 'ecutabl,
Figura 17.3.
Proceso de desarrollo del SOL incorporado.
ta invisible para el programador de la aplicacin. El proceso tiene varias ventajas importantes desde el punto de vista del SGBD, que se muestran a continuacin.
La mezcla de instrucciones de SQL y del lenguaje de programacin en el programa fuente del lenguaje SQL incorporado es una manera efectiva de
490
491
combinar los dos lenguajes. El lenguaje de programacin anfitrin proporciona el flujo de control, las variables, la estructura de bloques y las funciones de entrada y salida; SQL controla el acceso a la base de datos y no tiene que proporcionar las dems estructuras. El empleo del precompilador implica que el trabajo intensivo en clculo del anlisis y de la optimizacin puede realizarse durante el ciclo de desarrollo. El programa ejecutable resultante es muy eficiente en el empleo de los recursos de la CPU. El mdulo de solicitudes a la base de datos generado por el precompilador ofrece la portabilidad de las aplicaciones. Se pueden escribir y comprobar los programas de aplicacin en un sistema y luego pasar el programa ejecutable y el DBRM a otro sistema. Una vez que el programa BIND del sistema nuevo crea el plan de aplicacin y lo instala en la base de datos, el programa de aplicacin puede utilizarlo sin que haya que volver a compilarlo. La verdadera interfaz de tiempo de ejecucin del programa con las rutinas privadas del SGBD quedan completamente ocultas al programador de la aplicacin. El programador trabaja con SQL incorporado en el nivel del cdigo fuente y no necesita preocuparse de otras interfaces ms complejas.
S9~ in~eractivo. ~e pue~e es~ribir cualquier instruccin que se desee, pero Jos pn~lleglOs conc~ldos al Idenuficador de usuario determinan si el SGBO la ejecutara. Cuando se ejecuta un programa que utiliza SQL incorporado hay que considerar dos identificadores de usuario:
El identificador de usuario de la persona que desarroll el programa o, ms concretamente, de la persona que ejecut6 el programa BIND para crear el plan de aplicaci6n. El identificador de usuario de la persona que ejecuta el programa y el plan de aplicacin correspondiente. Puede parecer extrao que se considere el identificador de usuario de la persona que ejecut el programa BIND (o, ms en general, la persona que desarroll el programa de aplicacin o lo instal6 en el sistema informtico), pero, de hecho, DB2 y otros productos comerciales de SQL utilizan ambos identificadores de usuario en su esquema de seguridad. Para comprender el modo de funcionamiento del esquema de seguridad, sup6ngase que el usuario JOSE ejecuta el programa de mantenimiento de pedidos MANTEPEDI, que actualiza las tablas PEDIDOS, VENTAS Y OFICINAS. El plan de aplicaci6n del programa MANTEPEDI lo enlaz originalmente el identificador de usuario ADMINPP, que pertenece al administrador de procesamiento de pedidos. En el esquema de DB2 cada plan de aplicacin es un objeto de la base de datos, protegido por la seguridad de DB2. Para ejecutar un plan JOS E debe tener el privilegio EXECUTE correspondiente. Si no lo tiene, la ejecucin falla inmediatamente. Cuando se ejecuta el programa MANTEPEDI, sus instrucciones INSERT, UPDATE y DELETE incorporadas actualizan la base de datos. Los privilegios del usuario ADMINPP determinan si se permitir que el plan lleve a cabo esas actualizaciones. Obsrvese que el plan puede actualizar las tablas aunque JaSE no tenga los privilegios necesarios. No obstante, las actualizaciones que pueden llevarse a cabo slo son las que se han codificado de manera explcita en las instrucciones de SQL incorporado del programa. Por tanto, DB2 proporciona un control muy estricto de la seguridad de la base de datos. Los privilegios de los usuarios para el acceso a las tablas pueden estar muy limitados, sin que disminuya su capacidad para utilizar programas preparados. No todos los productos de SGBD ofrecen proteccin de seguridad para los planes de aplicacin. Para los que no lo hacen, Jos privilegios del usuario que ejecuta el programa de SQL incorporado determinan los privilegios del plan de aplicacin del programa. Con este esquema el usuario debe tener privilegios para llevar a cabo todas las acciones que realiza el plan, o el programa fallar. Si el usuario no debe tener esos mismos pennisos en el entorno de SQL interactivo, hay que restringir el acceso al propio programa de SQL interactivo, lo que supone un inconveniente en este enfoque.
Reenlace automtico
Ejecucin de un programa SOL incorporado

Hay que recordar de la Figura 17.3 que el proceso de desarrollo del SQL incorporado genera dos componentes ejecutables: el programa ejecutable propiamente dicho y el plan de aplicacin del programa, que se almacena en la base de datos. Cuando se ejecuta un programa de SQL incorporado, estos dos componentes se combinan para realizar la labor de la aplicacin: l. Cuando se pide al sistema informtico que ejecute el programa, la computadora carga el programa ejecutable del modo habitual y comienza a ejecutar sus instrucciones. Una de las primeras llamadas generadas por el precompilador es la dirigida a la rutina del SGBD, que busca y carga el plan de aplicacin del programa. Para cada instruccin de SQL incorporado, el programa llama a una o varias rutinas del SGBD y solicita la ejecucin de la instruccin correspondiente en el plan de aplicacin. El SGBD busca la instrucci6n, ejecuta esa parte del plan y devuelve el control al programa. La ejecuci6n contina de esta manera, con el ejecutable y el SGBD cooperando para llevar a cabo la tarea definida por el programa original de SQL incorporado.
2. 3.
4.
Seguridad en el momento de la ejecucin
Cuando se u.tiliza SQL interactivo. el SGBD hace que se cumpla la seguridad de acuerdo con el identificador de usuario que se proporciona para el programa de
Obsrvese que el plan de aplicacin est optimizado para la estructura de la base de datos tal y como es en el momento en que el programa BIND ubica el plan en la
""'-
492
493
base de datos. Si la estructura se modifica ms adelante (por ejemplo. si se descarta algn ndice o se elimina una columna de una tabla), puede que los planes de aplicacin que hagan referencia a las estructuras modificadas no sigan siendo vlidos. Para tratar esta situacin, el SOBO suele almacenar, junto con el plan de aplicacin, una copia de las instrucciones de SQL originales que lo generaron. El SGBD tambin realiza un seguimiento de todos los objetos de la base de datos de los que depende cada plan de aplicacin. Si una instruccin del LDD modifica alguno de estos objetos, el SGBD puede buscar los planes que dependen
maine }
(
de ese objeto y marcarlos de manera automtica como no vlidos. La siguiente ocasi6n en que el programa intente utilizar el plan, el SGBD puede detectar la situacin y, en la mayor parte de los casos, volver a enlazar las instrucciones de manera automtica para generar una nueva imagen enlazada. Corno el SOSD ha conservado una gran cantidad de informacin sobre el plan de aplicacin, puede hacer este nuevo enJace automtico de manera completamente transparente para el programa de aplicacin. No obstante, puede que las instrucciones de SQL tarden mucho ms en ejecutarse mientras se vuelve a enlazar el plan que cuando slo hay que ejecutarlo. Aunque el SGSD puede volver a enlazar de manera automtica un plan cuando se modifica aJguna de las estructuras de las que depende, no suele detectar de manera automtica Jas modificaciones de la base de datos que pueden hacer posible un plan mejor. Por ejemplo, supngase que un plan utiliza la exploracin secuencial de una tabJa para buscar filas concretas porque no exista ningn ndice adecuado cuando se enlaz el plan. Es posible que una instruccin CREATE INDEX posterior cree un ndice adecuado. Para aprovechar la nueva estructura hay que ejecutar de manera explcita el programa BIND con el fin de volver a enlazar el plan.
exec sql include sqlca; exec sql declare representantes lnum_empl nombre edad oficina_rep puesto fecha_contrato jefe cuota ventas
table integer not null, varchar(15) not null, integer integer, varchar(10) , date not null, integer, money, money not null);
/~ Muestra un mensaje para el usuario */ printfl"Eliminacin de representantes con cuotas bajas.\n");
/*Ejecuta la instruccin de SQL */ exec sq1 de1ete from representantes where ventas < 150000.00; Muestra otro mensaje ~/ printf("Eliminacin concluida.\n"); exit():
/~
Figura 17.4,
Programa de SOL incorporado escrito en C.
Instrucciones simples de SOL incorporado

Las instrucciones ms sencillas de SQL que se incorporan en los programas son las que se contienen a s mismas y no generan el resultado de ninguna consulta. Por ejemplo, considrese esta instruccin de SQL interactivo: Eliminar todos los representantes con ventas inferiores a 150.000 .
DELETE FROM REPRESENTANTES WHERE SALES < 150000.00
Las figuras 17.4, 17.5 Y 17.6 muestran tres programas que llevan a cabo la misma tarea que esta instruccin de SQL interactivo, empleando SQL incorporado. El programa de la Figura 17.4 est escrito en C; el de la Figura 17.5, en COBOL, y el de la Figura 17.6, en FORTRAN. Aunque los programas son extremadamente sencillos, ilustran las caractersticas ms bsicas del SQL incorporado: Las instrucciones de SQL incorporado aparecen en mitad de las instrucciones det" lenguaje de programacin anfitrin. No suele impo~ar si las instruc-
ciones de SQL estn escritas en maysculas o en minsculas; hi prctica ms habitual es seguir el estilo del lenguaje anfitrin. . Cada instruccin de SQL incorporado comienza con un introductor que la marca como instruccin de SQL. Los productos de SQL de IBM utilizan el introductor EXEC SQL para la mayor parte de los lenguajes anfitriones, y el estndar SQL de ANSIIIS02 tambin lo especifica. Algunos productos de SQL incorporado siguen adirnitiendo otros introductores en aras de -la compatibilidad con versiones anteriores. Si una instruccin de SQL incorporado se extiende por varias lneas, se utiliza la estrategia del lenguaje anfitrin para la continuacin de las instrucciones. Para los programas de COBOL, PUl YC no se necesita ningn carcter especial de continuacin. Para los programas de FORTRAN la segunda lnea de la instruccin y las posteriores deben tener un carcter de continuacin en la columna 6. Cada instruccin de SQL incorporado concluye con un terminador que seala el final de la instruccin de SQL. El terminador vara con el estilo del lenguaje anfitrin. En COBOL el terminador es la cadena de caracteres END-EXEC., que concluye con un punto, al igual que otras instruccio-
494
SOL. Manuaf de referencia
495
IDENTIFICATION DIVISION. PROGRAM-ID. EJEMPLO. ENVIRONMENT DIVISION.

DATA DIVISION. FILE SECTION.
WDRKING-5TORAGE SECTION. EXEC SQL INCLUDE SQLCA. EXEC SQL DECLARE REPRESENTANTES (NUM_EMPL NOMBRE EDAD OFICINA_REP PUESTO FECHA_CONTRATO
TABLE INTEGER NOT NULL, VARCHAR(15) NOT NULL, INTEGER, INTEGER, VARCHAR(lOl. DATE NOT NULL,
PROGRAM EJEMPLO 100 FORMAT (' ',A35) EXEC SQL INCLUDE SQLCA EXEC SQL DECLARE REPRESENTANTES C (NUM_EMPL C NOMBRE e EDAD e OFICINA_REP e PUESTO c FECHA_CONTRATO c JEFE c CUOTA c VENTAS
TABLE INTEGER NOT NULL, VARCHAR(15) NOT NULL, INTEGER, INTEGER, VARCHAR(lO) , DATE NOT NULL, INTEGER. MONEY, MONEY NOT NULL)
JEFE INTEGER.
CUOTA MONEY,
VENTAS MONEY NOT NULL) END-EXEC.

PROCEDURE DIVISION.
MUESTRA UN MENSAJE PARA EL USUARIO WRITE (6,100) 'Eliminacin de representantes con cuotas bajas .. EJECUTA LA INSTRUCCIN DE SQL EXEC SQL DELETE FROM REPRESENTANTESS WHERE CUOTA < 150000 e MUESTRA OTRO MENSAJE WRITE (6,100) 'Eliminacin concluida.' RETURN ENO
MUESTRA UN HENSAJE PARA EL USUARIO DISPLAY "Eliminacin de representantes con cuotas bajas,-, EJECUTA LA INSTRUCCIN SQL EXEC SQL DELETE FROM REPRESENTANTES WHERE CUOTA < 150000
END EXEC.
MUESTRA OTRO MENSAJE DISPLAY -Eliminacin concluida.",
Figura 17.6.
Programa de SOL incorporado escrito en FORTRAN.
Figura 17.5.
Programa de Sal incorporado escrito en COBOL.
Declaracin de tablas
En los productos SQL de IBM la instruccin incorporada DECLARE TABLE, que puede verse en la Figura 17.8, declara una tabla a la que harn referencia una o varias instrucciones de SQL incorporado del programa. Se trata de una instruccin opcional que ayuda al precompilador en su tarea de anlisis y validacin de las instrucciones de SQL incorporado. Utilizando la instruccin DECLARE TABLE el programa especifica de manera explicita sus suposiciones sobre las columnas de la tabla y el tipo y tamao de los datos. El precompilador comprueba las referencias del programa a las tablas y a las columnas para asegurarse de que se corresponden con la declaracin de la tabla. Los programas de las Figuras 17.4, 17.5 Y 17.6 utilizan la instruccin DECLARE TABLE. Es importante destacar que la instruccin slo aparece con fines de documentacin y para su empleo por el precompilador. No se trata de ninguna instruccin ejecutable y no hace falta declarar las tablas de manera explcita antes de referirse a ellas en las instrucciones de DML o de DDL incorporado. No obstante. el empleo de la instruccin DECLARE TABLE hace que los programas tengan ms
nes de COBOL. Para PUl y C el terminador es un punto y coma (;l, que tambin es el carcter de terminacin de las instrucciones de estos lenguajes. En FORTRAN las instrucciones de SQL incorporado concluyen cuando ya no se indica ninguna lnea de continuacin. La tcnica de incorporacin mostrada en las tres figuras funciona para cualquier instruccin de SQL que (al no dependa del valor de las variables del lenguaje anfitrin para su ejecucin y que (b) no recupere datos de la base de datos. Por ejemplo, el programa de e de la Figura 17.7 crea una nueva tabla REGIONES e inserta en ella dos filas, utilizando exactamente las mismas caractersticas de SQL incorporado que el programa de la Figura 17.4. Por coherencia, todos los dems ejemplos de programas de este libro utilizarn el lenguaje de programacin e, excepto cuando se ilustre una caracterstica de algn lenguaje anfitrin concreto.
496
497
maio ()
{
exec sql include sqlca;

/* Crear la nueva tabla REGIONES exec sql create table regiones (name char(15), ciudad_central char(15). jefe integer, objetivo money. ventas money,
documentacin interna y sean ms sencillos de mantener. Todos los productos de SQL desarrollados por IBM admiten la instruccin DECLARE TABLE, pero la mayor parle de los dems productos de SQL no, y sus precompiladores generarn un mensaje de error si se utiliza.
*'
Manejo de errores
Cuando se escribe una instruccin de SQL que genera un error, el programa interactivo de SQL muestra un mensaje de error, cancela la instruccin y pide al usuario que escriba otra instruccin. En SQL incorporado, el manejo de los errores pasa a ser responsabilidad del programa de aplicacin. Realmente, las instruccio~ nes de SQL incorporado pueden producir dos tipos de errores diferentes: Errores en el momento de la compilacin. Las comas mal ubicadas, las palabras clave de SQL mal escritas y errores parecidos de las instrucciones de SQL incorporado los detecta el precompilador de SQL y se los comunica al programador. El programador puede corregir estos errores y volver a compilar el programa de aplicacin. Errores en el momento de la ejecucin. Los intentos de insercin de datos no vlidos o la carencia de permiso para la actualizacin de una tabla slo puede detectarse en el momento de la ejecucin. Los errores de este tipo debe detectarlos y manejarlos el programa de aplicacin. En los programas de SQL incorporado, el SOBn comunica los errores en el momento de la ejecucin al programa de aplicacin mediante la devolucin de un cdigo de error. Si se detecta algn error, se dispone de una descripcin ms amplia del error y de otra informacin sobre la instruccin recin ejecutada mediante informacin adicional de diagnstico. Las primeras implementaciones de SQL incorporado de IBM definan un mecanismo de comunicacin de errores que fue adoptado, con variaciones, por la mayor parte de los fabricantes importantes de SGBD. La parte central de este esquema -una variable de estado del error denominada SQLCODE- tambin estaba definida en el estndar ANSIIISO original para SQL. El estndar SQL2, publicado en 1992, defini un mecanismo de comunicacin de errores paralelo, completamente nuevo, creado alrededor de una variable de estado del error denominada SQLSTATE. Estos mecanismos se describen en los dos apartados siguientes.
primary key nombre,

foreign key jefe references representantes); printf("Tabla creada.\n-);
/* Inserta dos filas; una por cada regin */ exec sql iosert into regioos values ('Este'. 'Navarra', 106. 0.00. 0.00); exec sgl iosert ioto regiones values ('Oeste', 'Len', 108, 0.00, 0.00); printf(-Tabla rellena.\n");
exit ();
Figura 17.7.
Empleo de SOL incorporado para crear tablas.
r-- DECLARE nOmbre-tabla, TABLE

Lnombreovista ~
4(lnombre.co,umna tipo-datos l
NOT NULL I
:~
WITH DEFAULT
~
I
I
-----.e
Manejo de errores con SQLCODE
----------f
Figura 17.8. Diagrama sintctico de la instruccin DECLARE TABLE.
Con este esquema, avanzado por los primeros productos de IBM, el SGBD comunica la informacin de estado al programa de SQL incorporado mediante un rea de almacenamiento del programa denominada rea de comunicaciones de SQL, o SQLCA (SQL Communications Area). SQLCA es una estructura de datos que contie'ne variables de error e indicadores de estado. Al examinar SQLCA, el programa de
498
499
aplicacin puede determinar el xito o el fallo de las instrucciones de SQL incorporado y actuar en consecuencia. Obsrvese en las figuras 17.4, 17.5, 17.6 Y 17.7 que la primera instruccin de SQL incorporado del programa es INCLUDE SQLeA. E~ta i~struccin indica al pre. . . compilador de SQL que debe incluir el rea de comUnICaCIOnes de SQL en el programa. El contenido concreto de SQLCA vara ~igera~ente d~ una ma:?a de S~BD a otra, pero SQLeA proporciona siempre el mismo tipO de mformaclOn. La FIgura 17.9 muestra la definicin de SQLeA utilizada por las bases de datos de IBM. La parte ms importante de SQLeA, la v~riable SQLC?DE, la incluyen todos los productos principales de SQL y la especIficaba el estandar SQL de ANSI/ISO l.
Cuando el SGBD ejecuta cada instruccin de SQL incorporado, define el valor de la variable SQLCODE en SQLCA para indicar el estado de realizacin de la instruccin: Un SQLCODE de cero indica el cumplimiento con xito de la instruccin, sin ningn error ni advertencia. Un valor negativo de SQLCODE indica un error grave que evit que se ejecutara la instruccin de manera correcta. Por ejemplo, un intento de actualizacin de una vista slo de lectura generara un valor negativo de SQLCODE. Se asigna un valor negativo diferente para cada error del momento de la ejecucin que pueda producirse. Un valor positivo de SQLCODE indica una condicin de advertencia. Por ejemplo, el truncado o el redondeo de un elemento de datos recuperado por el programa generara una advertencia. Se asigna un valor positivo diferente para cada advertencia del momento de la ejecucin que pueda producirse. La advertencia ms frecuente, con un valor de + 100 en la mayor parte de las implementaciones y en el estndar SQLI, es la advertencia de falta de datos que se obtiene cuando el programa intenta recuperar la siguiente fila de resultados de la consulta y no quedan ms filas que recuperar. Como cada instruccin ejecutable de SQL incorporado puede, en teora, generar un error, los programas bien escritos comprueban el valor de SQLCODE tras cada instruccin ejecutable de SQL incorporado. La Figura 17.10 muestra el fragmento de un programa de C que comprueba el valor de SQLCODE. La Figura 17.11 muestra un fragmento parecido de un programa de COBOL.
struct sqlca { unsigned char long long short unsigned char
sqlcaid[8]; /* la cadena de caracteres "SQLCA " */ sqlcabc; /* longitud de SQLCA, en bytes */ sqlcode; /* cdigo de estado de SQL */ sqlerrml; /* longitud del array de datos sqlerrmc */ sqlerrmc[70); /* nombre (s) del (los) objeto(s) que provoca el error */ unsigned char sqlerrp[8]; /* informacin de diagnstico */ long sqlerrd[6]; /* varias cuentas y cdigo de error */ unsigned char sqlwarn[8]; /* array de banderas de advertencia */ unsigned char sqlext[8]; /* ampliacin del array sqlwarn */
#define SQLCODE sqlca.sqlcode /* cdigo de estado de SQL */

/* Una
'W' en cualquiera de los campos de SQLWARN indica una condicin de advertencia; en caso contrario, cada uno de estos campos contiene un espacio en blanco */
/ ' bandera de advertencia principal ' / / ' cadena de caracteres truncada ,/
#define SQLWARNO sqlca.sqlwarn[O] #define SQLWARNl sqlca.sqlwarn[l) #define SQL!,'lARN2 sqlca.sqlwarn[2) #define SQLWARN3 sqlca.sqlwarn(3) #define SQLWARN4 sqlca.sqlwarn[4] #define SQLWARN5 sqlca.sqlwarn[5) #define SQLWARN6 sqlca.sqlwarn[6] #define SQLWARN7 sqlca.sqlwarn[7]
/' NULLs eliminados de la funcin de la columna ' / / ' demasiadas variables del anfitrin o demasiado pocas ,/ / ' preparadas UPDATE/DELETE sin WHERE ' / /' incompatibilidad de SQL/DS con DB' ' / /' fecha no vlida en una expresin aritmtica ' / /' reservada ' /
exec sql dele te from representantes where cuota < 150000; if (sqlca.sqlcode < O) gato rutina_error;
rut~na
error printf("ErrOr de SQL: %ld\n, exit ();
sqlca.sqlcode);
Figura 17.9.
El rea de comunicaciones de SOL [SOL Communications Area

"(SQLCA)] de las bases de datos de IBM.
Figura 17.10.
Fragmento de un programa de res en SQLCODE.
con comprobacin de los erro-
SOO
Captulo 17:
saL
incorporado
S01
SQLSTATE, y el cdigo de error asignado a cada error. Para cumplir el estndar SQL2, los productos de SQL deben comunicar los errores utilizando las variables de error SQLCODE y SQLSTATE. De este modo, los programas ya existentes
que utilizan
01 PRINT_MESSAGE. 02 FILLER PIe X(ii) VALUE 'Error de SQL; '.
02 PRINT-CODE Pie SZ (91 .
SQLCODE
siguen funcionando y pueden escribirse programas nuevos

SQLSTATE.
que utilicen los cdigos de error normalizados de La variable SQLSTATE consta de dos panes:
EXEC SQL DELETE FROM REPRESENTANTES WHERE CUOTA < 150000 END EXEC. IF SQLCODE NOT = ZERO GOTO ERRDR-ROUTINE.
Una clase de error de dos caracteres que identifica la clasificacin general del error (por ejemplo, error de conexin, error de datos no vlidos o advertencia). Una subclase de error que identifica el tipo concreto de error dentro de la clase general de error. Por ejemplo, dentro de la clase de datos no vlidos, la subclase de error puede identificar un error de divisin por cero, un error de valor numrico no vlido o datos de fecha no vlidos. Los errores especificados en el estndar SQL2 tienen un cdigo de clase de error que comienza con una cifra de cero a cuatro (inclusive) o una letra entre A y H (inclusive). Por ejemplo, los errores de datos se indican mediante.'Ia c1ase de error 22. La violacin de una restriccin de integridad (como la definicin de una clave externa) se indica mediante la clase de error 23. El retroceso de una transaccin se indica mediante la clase de error 40. Dentro de cada clase de error los cdigos estndar de las subclases tambin siguen las mismas restricciones de nmeros O letras iniciales. Por ejemplo, dentro de la clase de error 40 (retroceso de las transacciones), los cdigos de subclase son 001 para los fallos en la serializacin (es decir, el programa ha resultado perdedor del interbloqueo), 002 para las violaciones de las restricciones de integridad y 003 para los errores en que se desconoce el estado de cumplimiento de la instruccin de SQL (por ejemplo, cuando se interrumpe la conexin de red o un servidor falla antes de que se complete la instruccin). La Figura 17.12 muestra el mismo programa de de la Figura 17.10. pero utiliza para la comprobacin de los errores la variable SQLSTATE, en lugar de
ERROR-ROUTINE. MOVE SQLCODE TO PRINT-CODE. DISPLAY PRINT_MESSAGE.
Figura 17.'1.
Fragmento de un programa de COSOL con comprobaein de errores de SQLCODE.
Manejo de errores con SQLSTATE
Para cuando se estaba escribiendo el estndar SQL2, prcticamente todos los productos comerciales de SQL utilizaban la variable SQLCODE para comunicar las condiciones de error de los programas de SQL incorporado. No obstante, no haba ninguna normalizacin de los nmeros de error utilizados por los diferentes productos para comunicar condiciones de error idnticas o parecidas. Adems, debido a las diferencias significativas entre las implementaciones de SQL permitidas por el estndar SQLI, podan darse diferencias considerables en los errores de una implementacin a otra. Finalmente, la definicin de SQLeA variaba de manera significativa de una marca de SGBD a otra, y todas las marcas principales tenan una gran base instalada de aplicaciones que fallaran con cualquier modificaci6n en su estructura de SQLCA. En lugar de abordar la tarea imposible de lograr que todos los fabricantes de SaBD se pusieran de acuerdo para modificar sus valores de SQLCODE de acuerdo con algn estndar, los redactores del estndar SQL2 adoptaron un enfoque diferente. Incluyeron el valor de error de SQLCODE, pero lo identificaron con una caracterstica censurada, lo que significa que se consideraba obsoleta y se eliminara del estndar en algn momento posterior. Para ocupar su puesto introdujeron una nueva variab!e de error, denominada SQLSTATE. El estndar tambin especifica, con detalle, las condiciones de error que pueden comunicarse mediante la variable
SQLCODE.
El estndar reserva de manera especfica los cdigos de clase de error que comienzan con las cifras del cinco al nueve (inclusive) y con las letras entre 1 y Z (inclusive) como errores especficos de cada implementacin que no estn estandarizados. Aunque esto permite que siga habiendo diferencias entre las marcas de SGBD. todos los errores ms frecuentes provocados por las instrucciones de SQL se incluyen en los cdigos de clase de error normalizados. A medida que las implementaciones comerciales de los SGBD van dando soporte a la variable SQLSTATE, una de las incompatibilidades entre los diferentes productos de SQL.:ms problemticas se va eliminando poco a poco. El estndar SQLZ proporciona informacin adicional sobre errores y diagnstico mediante la nueva instruccin GET DIAGNOSTICS, que puede verse en la Figura 17.13. La instruccin permite que los programas de SQL incorporado recuperen uno O varios elementos de informacin sobre la instruccin de SQL recin ejecutada o sobre una condicin de error recin generada. El soporte de la instruccin GET DIAGNOSTICS es obligatorio para el cumplimiento intermedio O completo del
502
503
Para recuperar la informacin del nivel de las instrucciones

y determinar el nmero de errores de diagn6stco:
exec sql delete from representantes where cuota < 150000; if (strcmp(sqlca.sqlstate. 00000-') goto error_routine;
1- GET
DIAGNOSTICS
anl trin =
variable
1NUMBER-------1 -------,-,-..
MORE
COMMAND_FUNCTION -
DYNAMIC_FUNCTION -
ROW_COUNT
error_routine: printf("Error de SQL: %s\n",sqlca.sqlstate); exit () ;

Para recuperar la informacin sobre un error de diagnstico concreto;
GET DIAGNOSTICS EXCEPTION
nmero_error]
variable : - - CONDITION_NUHBER
RETURNED_SQLSTATE CLASS_ORIGIN ------~ SUBCLASS_ORIGIN SERVER_NAME -----1 CONNECTION_NAME CONSTRAINT_CATALOG CONSTRAINT_SCHEMA
CONSTRAINT~AME
'---.,,-
Figura 17.12.
Fragmento de un programa de
SQLSTATE.
e con comprobacin de errores de
anfitrin
estndar, pero no se exige ni se permite para el cumplimiento inicial. La Figura 17.14 muestra el fragmento de un programa de C, como el de la Figura 17.12. ampliado para incluir la instruccin GET DIAGNOSTICS.
La instruccin W1IENEVER
CATALOG~AME
SCHEMA~AME
-------1
Para los programadores se vuelve rpidamente tedioso escribir programas que comprueben de manera explcita el valor de SQLCODE tras cada instruccin de SQL incorporado. Para simplificar el manejo de los errores, SQL incorporado cuenta con la instruccin WHENEVER, que puede verse en la Figura 17.15. La instruccin WHENEVER es una directriz para el precompilador de SQL. no una instruccin ejecutable. Indica al precompilador que debe generar de manera automtica cdigo de manejo de errores a continuacin de cada instruccin ejecutable de SQL incorporado, y especifica lo que debe hacer el cdigo generado. La instruccin WHENEVER se puede utilizar para indicar al precompilador el modo de manejar tres condiciones de excepcin diferentes:
Figura 17.13.
TABLE_NAME -------..., COLUMICNAME CURSOELNAME MESSAGE_TEXT MESSAGE_LENGTH MESSAGE_OCTET_LENGTH
Diagrama sintctico de la instruccin GET DIAGNOSTICS.
WHENEVER SQLERROR
indica al precompilador que genere cdigo para manejar los errores (valores negativos de SQLCODE). WHENEVER SQLWARNING indica al precompilador que genere cdigo para manejar las advertencias (valores positivos de SQLCODE). WHENEVER NOT FOUND indica al precompilador que genere cdigo para manejar una advertencia concreta -la advertencia generada por el SGBD cuando el programa recupera resultados de consultas y ya no quedan ms. Este empleo de hi instruccin WHENEVER es privativo de las instrucciones SELECT y
FETCH que devuelven una sola fila, y se describe en el apartado Consultas sobre una sola fila.
Obsrvese que el estndar SQL2 no especifica la fonna SQLWARNING de la instruccin WHENEVER. pero la mayor parte de los productos comerciales de SQL la incluyen.
504
505
r-WHENEVER1SQLERROR3L[
CONTINUE~.
GOTa ----.---
SQLWARNING
etiqueta
ejecuta la instruccin DELETE Y comprueba si hay errores */ exec sql delete froID representantes where cuota < 150000; i i (strcmp{sqlca.sqlstate, "00000")) goto error_routine:
/* DELETE con xito; comprueba el nmero de filas eliminadas */ exec sql get diagnostics :numrows : ROW_COUNT; printf("%ld filas eliminadas\n",nurnrows);
I~
NOT FOUNO
GO TO-l
Figura 17.15.
WHENEVER.
errores de la instruccin INSERT incorporada dan lugar a una bifurcacin hacia error2. Como muestra este ejemplo. el empleo principal de la forma WHENEVER/CONTlNUE de la instruccin es cancelar el efecto de una instruccin WHENEVER anterior.
error_routine: /* Determina el nmero de errores comunicados */ exec sql get diagnostics :count ~ NUMBER; for (i=1; i<count: i++) ( exec sql get diagnostics EXCEPTION :1 :err = RETURNED_SQLSTATE, :msg = MESSAGE_TEXT; prinef("Error de SQL I %d: cade: %5 message, \s\o", i, err, msg);
}
exec sql whenever sqlerror goto error1; exec sql delete from representantes where cuota < 150000; exec sql delete from clientes where l~m~te_credito < 20000; exec sql whenever sqlerror continue; exec sql update representantes set cuota: cuota * 1.05; exec sql whenever sqlerror goto error2; exec sql insert into representantes (num_empl, nombre'f") cuott) values (116, 'Juana Hermida', IOOOOO.OO);
exit ();
Figura 17.14.
Fragmento de programa de
GET DIAGNOSTICS.
con comprobacin de errores de
Para cualquiera de estas tres condiciones se puede indicar al precompilador que genere cdigo que realice una de estas dos acciones:
WHENEVER/GOTO
indica al precompilador que genere una bifurcacin en la

errorl; printf ("Error de SQL en DELETE; tdl \n", exit l) ; error2;
printf(~Error
etiqueta especificada, que debe ser la etiqueta de-una instruccin o el nme WHENEVER/CONTlNUE
'1
ro de una instruccin del programa. indica al precompilador que permita que contine el flujo de control del programa hasta la siguiente instruccin del lenguaje anfitrin.
sqlca. sqIcodel ;'
La instruccin WHENEVER es una directriz para el precompilador, y su efecto puede anularse con otra instruccin WHENEVER que aparezca posteriormente en el texto del programa. La Figura 17.16 muestra el fragmento de un programa con tres instrucciones WHENEVER y cuatro instrucciones ejecutables de SQL. En este programa un error de cualquiera de las dos instrucciones DELETE da lugar a una bifurcacin hacia error1 debido a la primera instruccin WHENEVER. Los errores de la instruccin UPDATE incorporada fluyen directamente hacia las siguientes instrucciones del programa. Los
de SOL en INSERT; tId\n",
sqlca.sqlcodel;
exit ();
Figura 17.16.
Uso de la instruccin
WHENEVER.
506

WHENEVER
507
La instruccin
hace mucho ms sencillo el manejo de los errores del

main ()
SQL incorporado. y es ms frecuente que la utilicen los programas de aplicacin que

el que comprueben directamente SQLCQDE o SQLSTATE. Hay que recordar, no obstante, que tras la aparicin de una instruccin WHENEVER/GOTO el precompilador genera una prueba y una bifurcacin hacia la etiqueta especificada para cada in~truccin de SQL incorporado que aparece a continuacin. Hay que disponer el programa de modo
t
exec sQl include sqlca; exec sql begin declare section; float importe; exec sql end declare section; Pide al usuario el importe del incremento o disminucin de las cuotas */ printf("Aumentar o disminuir las cuotas en:-}; scanf("'f", &importe);
/*
/* Actualiza la columna CUOTA de la tabla REPRESENTANTES */ exec sql update representantes set cuota: cuota + :importe; /t Comprueba el resultado de la ejecucin de la instruccin */ if {sqlqa.sqlcode != Ol printf("Error durante la actualizacin.\n*l; else printf("Actualizacin realizada con xito.\n"};
/* importe
(obtenido del
*/
que la etiqueta especificada sea un objetivo vlido para las bifurcaciones a partir de
esas instrucciones de SQL incorporado. O utilizar otra instruccin WHENEVER para especificar un destino diferente o cancelar Jos efectos de WHENEVER/GOTD.
usuario)
Uso de variables del anfitrin

Los programas de SQL incorporado de las figuras anteriores no ofrecen ninguna interaccin real entre las instrucciones de programacin y las de SQL incorpora do. En la mayor parte de las aplicaciones se desea utilizar en las instrucciones de SQL incorporado el valor de una o varias variables del programa. Por ejemplo, supngase que se desea escribir un programa que aumente o disminuya todas las cuotas de ventas en una cantidad de euros dada. El programa debe pedir al usuario el importe y luego utilizar una instruccin UPDATE incorporada para modificar la columna CUOTA de la tabla REPRESENTANTES. El SQL incorporado admite esta posibilidad mediante el uso de variables del anfitrin. Las variables del anfitrin son variables del programa declaradas en el lenguaje anfitrin (por ejemplo, variables de COBOL o de C) a las que hacen referencia las instrucciones de SQL incorporado. Para identificar las variables del anfitrin se anteponen dos puntos (:) a su nombre cuando aparece en las instrucciones de SQL incorporado. Los dos puntos permiten al precompilador distinguir entre las variables del anfitrin y los objetos de la base de datos (como las tablas o las columnas) que puedan tener el mismo nombre. La Figura 17.17 muestra un programa en e que implementa la aplicacin de ajuste de las cuotas utilizando una variable del anfitrin. El programa pide al usua-. rio el importe del ajuste y almacena el valor introducido en la variable denominada importe. A esta variable del anfitrin se hace referencia en la instruccin UPDATE incorporada. Conceptualmente, cuando se ejecuta la instruccin UPDATE. se obtiene el valor de la vatiable importe y se sustituye ese valor por la vatiable del anfitrin en la instruccin de SQL. Por ejemplo, si se introduce el importe 500 en respuesta a la peticin, el SGBD ejecuta de hecho esta instruccin UPDATE:
exec sql update representantes set cuota = cuota + 500;
exit{) ;
Figura 17.17.
Empleo de las variables del anfitrin.
Las variables del anfitrin pueden aparecer en las condiciones de bsqueda:

exec sql delete from representantes where cuota < ;irnporte;
Las variables del anfitrin tambin pueden utilizarse en la clusula VALUES de las instrucciones INSERT:
exec sql insert into representantes (nurn_empl. nombre. cuota) values {116. 'Benito Rienda', :importeJ;
Las variables del anfitrin pueden aparecer en las instrucciones de SQL incorporado donde pueda aparecer una constante. En concreto, las variables del anfitrin pueden utilizarse en las expresiones de asignacin:
exec sql update representantes set cuota = cuota + : importe;
En cada caso, obsrvese que la variable del anfitrin es parte del aporte de datos del programa al SGBD; forma parte de la instruccin de SQL remitida al SGBD para su ejecucin. Posteriormente. en el apartado Recuperacin de datos con SQL incorporado, se ver el modo en que las variables del anfitrin se utilizan tambin para recibir resultados del SGBD; reciben los resultados de las consultas proporcionados al programa por el SGBD. Obsrvese que las variables del anfitrin no pueden utilizarse en lugar de los identificadores de SQL. Este intento de uso de la variable del anfitrin nombrecol es ilegal:
50S
509
char -nombrecol = cuota"; exec sql insert inta representantes (nurn_empl, nombre, values (116, 'Benito Rienda', O.OOl; : nombrecoll
Se trata de una declaracin vlida en C de la variable buffergrande. Sin embargo, si se intenta utilizar buffergrande como variable del anfitrin en instrucciones de SQL incorporado como la siguiente:
exec sql update representantes
set cuota = 300000
Declaracin de las variables del anfitrin
Cuando se utilizan variables del anfitrin en las instrucciones de SQL incorporado, hay que declararlas utilizando el mtodo normal de declaracin de variables del lenguaje de programacin anfitrin. Por ejemplo, en la Figura 17.17, la variable del anfitrin importe se declara utilizando la sintaxis normal del lenguaje e (float importe;). Cuando el precompilador procesa el cdigo fuente del programa LOma nota del nombre de cada variable que halla, junto con su tipo de datos y su tamao. El precompilador utiliza esta informacin para generar ms adelante el cdigo correcto cuando descubre el empleo de la variable como variable del servidor en una instruccin de SQL. Las dos instrucciones de SQL incorporado BEGIN DECLARE SECTION y END DECLARE SECTION rodean las declaraciones de las variables del anfitrin, como puede verse en la Figura 17.17. Estas dos instrucciones son exclusivas del SQL incorporado, y no son ejecutables. Son directrices para el precompilador, que le indican el momento en que debe prestar atencin a las declaraciones de las variables y el momento en que puede ignorarlas. En los programas sencillos de SQL incorporado puede que sea posible reunir todas las declaraciones de las variables del anfitrin en una sola seccin de declaraciones. Generalmente, sin embargo, hay que declarar las variables del anfitrin en varios puntos del programa, especialmente en los lenguajes estructurados en bloques como C, Pascal y PUI. En este caso, cada descripcin de una variable del anfitrin debe encerrarse entre un par de instrucciones BEGIN DECLARE SECTION/
END DECLARE SECTION.
where nombre = :buffergrande;
muchos precompiladores generarn un mensaje de error, quejndose de la declaracin ilegal de buffergrande. El problema es que algunos precompiladores no reconocen las constantes simblicas, como TALLAGRANDEBUFFER. Slo se trata de un ejemplo de las consideraciones especiales que hay que tener en cuenta al utilizar SQL incorporado y precompiladores. Por suerte, los precompiladores ofrecidos por la mayor parte de los fabricantes de SOBD se estn mejorando de manera continua, y el nmero de problemas por casos especiales como ste va disminuyendo.
Las variables del anfitrin y los tipos de datos
Las instrucciones BEGIN DECLARE SECTION y END DECLARE SECTION son relativamente recientes para el lenguaje SQL incorporado. Se especifican en el estndar SQL de ANSI/ISO, y DB2 las exige en sus implementaciones de SQL incorporado ms recientes. Sin embargo, DB2 y otras muchas marcas de SOBD no exigan histricamente las secciones de declaraciones, y algunos precompiladores de SQL no incluyen todava las instrucciones BEGIN DECLARE SECTION y END DECLARE SECTION. En ese caso, el precompilador busca y procesa todas las declaraciones de variables del programa anfitrin. Cuando se utilice variables del anfitrin puede que el precompilador limite la flexibilidad en la declaracin de las variables en el lenguaje de programacin anfitrin. Por ejemplo, considrese el siguiente cdigo fuente en lenguaje C:
'define TALLAGRANDEBUFFER 256
exec sql begin declare section; char buf~ergrande[BIGBUFSIZE+ll; exec sql end declare section;
Los tipos de datos admitidos por los SGBD basados en SQL y los admitidos por o FORTRAN suelen ser bastante diferentes. lenguajes de programacin como Estas diferencias afectan a las variables del anfitrin porque desempean un papel dual. Por un lado, las variables del anfitrin son variables del programa, que se declaran utilizando los tipos de datos del lenguaje de programacin y son manipuladas por las instrucciones del lenguaje de programacin. Por otro lado, las variables del anfitrin se utilizan en las instrucciones de SQL incorporado para contener datos de la base de dalOs. Considrense las cuatro instrucciones UPDATE incorp<;>radas de la Figu'(3. 17..,...18. En la primera instruccin UPDATE, la columna JEFE tiene el tipo de.,datos INTEGER, por lo que varanfil debe declararse como variable entera de C. En la segunda instruccin, la columna NOMBRE tiene el tipo de datos VARCHAR, por lo que varanf2 debe contener datos de cadenas de caracteres. El programa debe declarar varanfi2 como array de datos de caracteres de C, y la mayor parte de los productos de SGBD esperan que los datos del array acaben en un carcter null (O). En la tercera instruccin UPDATE la columna CUOTA tiene el tipo de datos MONEY. No hay un tipo de datos equivalente en C, y no admite ningn tipo de .datos decimal empaquetado. Para la mayor parte de las marcas de SOBD se puede declarar varanf i3 como variable de coma flotante de e, y el SGBD traduce de manera automtica el valor en coma flotante al formato MONEY del SGBD. Finalmente, en la cuarta instruccin UPDATE, la columna FECHA_CONTRATO tiene el tipo de datos DATE en la base de datos. Para la mayor parte de las marcas de SGBD, hay.que declarar varanf4 como array de datos de carcter de C y rellenar el array con un formulario de texto de la fecha aceptable para el SGBD. Como muestra la Figura 17.18, el tipo de datos de las variables del anfitrin debe escogerse con cuidado para que coincida con el uso que se les pretende dar
510
Captulo 17: Sal incorporado
511
Tabla 17.1. Tipos de datos de SOL

Tipo de
Tipo de SQL Tipo de C

exec sql begin declare seetion; 106; varanfil int "Jos Snchez ; char *varanfi2 150000.00; flaat varanfi3 Ol-JUN-1990"; char *varanfi4 exec sql end declare section;
Tipo de COBOL FORTRAN

PIe 59 (4) CQHP INTEGER*2
Tipo de PL/I
FIXED BIN(15l
.. ..
5MALLINT INTEGER
short
long
float
double
double 1
char x[ n+1]2
PIe s9 (9)COMP
INTEGER*4
FIXED SIN()1)
REAL
DOUBLE PRECISION
NUMERIC (p,S) DECIMAL (P,S)
COMP-l
COMP-2
PIe 59 (p- s)
V9 (s) COMP-3
REAL4
REAL * 8
REAL*SI
BIN FLOAT(21)
SIN FLOAT(53)
exec sql update representantes set jefe = :varanfi where num_empl = 102;
exec sql update representantes set nombre = :varanfi2 where num_empl = 102: exec sql update representantes set cuota = :varanfi3 where num_empl = 102; exec sql update representantes set fecha_contrato where num_empl = 102;
FIXED DEC(p,s)
CHAR(n)
CHAR(n) VARCHAR(n) BIT(n) BIT VARYING(n) DATE TIME TlMESTAMP :varanfi4 INTERVAL
PIe x (n)
CHARACTER"n Conv.nec.
char x( n+1]2 char x[l]3 char x(lP Conv. nec. Conv. Conv. Conv.
Conv.nec. PIC X (1) Conv. nec. Conv. Conv. Conv.
CHAR(n) VAR BIT(n) BIT(n) VAR

Conv. nec. Conv. Conv.
CHARACTER*L3 Conv. nec. Conv. nec. Conv. Conv.
, , nec. , nec. , nec.
, nec. , nec. , nec.

,
,
,
, nec.
, nec.
, , nec. , nec.
,
Conv. nec.
Conv. nec.
Conv. nec.
Figura 17.18.
Variables del anfitrin y tipos de dato.
en las instrucciones de SQL incorporado. La Tabla 17.1 muestra los tipos de datos de SQL especificados en el estndar SQL de ANSIIIS02 y los tipos de datos correspondientes empleados en cuatro de los lenguajes de programacin de SQL incorporado ms populares, tal y como se especifican en el estndar. El estndar especifica las correspondencias entre tipos de datos y las reglas de SQL incorporado para los lenguajes Ada. C. COBOL. FORTRAN. MUMPS. Pascal y PUl. Obsrvese, no obstante. que, en muchos casos, no hay una correspondencia biunvoca entre los tipos de datos. Adems, cada marca de SGBD tiene sus propias idiosincrasias en los tipos de datos y sus propias reglas para la conversin de tipos de datos al emplear las variables del anfitrin. Antes de contar con un comportamiento concreto en la conversin de datos, consltese la documentacin de la marca especfica de SGBD y lase con cuidado la descripcin de cada lenguaje de programacin que se vaya a utilizar.
NOlas: 1 El lenguaje anfitrin no admite los datos decimales empaquetados; la conversin con los datos de coma flotante pueden causar errores de truncamiento o de redondeo. 1 El estndar SQL especifica una cadena de caracteres de e con un terminador null; las implementaciones ms antiguas de los SGBD devolvan un valor diferente de longitud en la estructura de datos. J La longitud de la cadena de caracteres del anfitrin (1) es el nmero de bits (n), dividido por los bits por carcter del lenguaje anfitrin (generalmente 8), redondeado. El lenguaje anfitrin no admite las cadenas de caracteres de longitud variable; la mayor parte de las marcas de SGBD las convierten en cadenas de caracteres de longitud fija. s Los lenguajes no admiten los tipos de datos nativos de fecha y hora; exige conversin (conversin necesaria, Conv. nec.) a1desde los tipos de datos de cadenas de caracteres del lenguaje anfitrin con representaciones de texto de la fecha, la hora y los intervalos.
Las variables del anfitrin y los valores NULL
La ~ayor parte de los lenguajes de programacin no proporcionan soporte de tipo SQL para los valores desconocidos o que faltan. Las variables de COBOL, C o FORTRAN, por ejemplo, tienen siempre un valor. No existe el concepto de que el valor sea NULL o falte. Esto genera un problema cuando se desean almacenar valores NULL en la base de datos o recuperarlos de la base de datos utilizando SQL para programacin. SQL incorporado resuelve este problema permitiendo que cada variable del anfitrin tenga una variable indicadora del anfitrin acompaante. En
512
513
las instrucciones de SQL incorporado la variable del anfitrin y la variable indicadora especifican conjuntamente un solo valor de tipo SQL, de la manera siguiente: Un valor de cero del indicador significa que la variable del anfitrin contiene un valor vlido y que hay que utilizar ese valor. Un valor negativo del indicador significa que debe suponerse que la variable del anfitrin tiene un valor NULL; el valor real de la variable del anfitrin es irrelevante y no debe tenerse en cuenta. Un valor positivo del indicador indica que la variable del anfitrin contiene un valor vlido, que se puede haber redondeado o truncado. Esta situacin slo se produce cuando se recuperan datos de la base de datos, y se describe ms adelante en el apartado Recuperacin de valores NULL. Cuando se especifican variables del anfitrin en instrucciones de SQL incorporado, se puede ubicar a continuacin el nombre de la variable indicadora correspondiente. Los dos nombres de variable van precedidos por dos puntos. A continuacin se puede ver una instruccin UPDATE que utiliza la variable del anfitrin importe con la variable indicadora acompaante importe_ind:
exec sql update representantes set cuota ~ :importe :importe_ind. ventas where cuota < 20000.00; :importe2
si CUOTA Y NULL son iguales, ya que la re~puesta siempre ser NULL (desconocido). En lugar de utilizar la variable indicadora, hay que utilizar una prueba explcita 1S NULL. Este par de instrucciones de SQL incorporado lleva a trmino la tarea intentada por la instruccin ilegal anterior:
if (importe_ind < 01 { exec sql delete from representantes where cuota is nu11; } e1se exec sq1 de1ete from representantes where cuota = : importe;
Las variables indicadoras resultan especialmente tiles cuando se recuperan datos de la base de datos al programa, y puede que el valor de los datos recuperados sea NULL. Este empleo de las variables indicadoras se describe en el apartado Recuperacin de valores NULL.
Recuperacin de datos con SOL incorporado

Hasta ahora, utilizando las caractersticas del SQL incorporado, se puede incluir en los programas de aplicacin cualquier instruccin de SQL interactivo, salvo la instruccin SELECT. La recuperacin de los datos con programas de SQL incorporado exige algunas ampliaciones especiales de la instruccin SELECT. El motivo de estas ampliaciones es que hay un desajuste fundamental entre el lenguaje SQL y lenguajes de programacin como C y COBOL: las consultas de SQL generan toda una tabla de resultados de la consulta, pero la mayor parte de los lenguajes de programacin slo pueden manipular elementos de datos o registros individuales (filas) de datos. SQL incorporado debe tender un puente entre la lgica en el nivel de las tablas de la instruccin de SQL SELECT y el procesamiento fila a fila de C, COBOL y otros lenguajes de programacin anfitriones. Por este motivo, SQL incorporado divide las consultas de SQL en dos grupos: Consultas de una nica fila. Se espera que el resultado de la columna contenga una sola fila de datos. La bsqueda del lmite de crdito de un cliente o la recuperacin de las ventas y de la cuota de un representante dado son ejemplos de este tipo de consulta. Consultas de varias filas. Se espera que el resultado de la consulta pueda contener cero, una o varias filas de datos. La relacin de los pedidos coil importes superiores a 20.000 o la recuperacin del nombre de todos los representantes que han superado su cuota son ejemplos de este tipo de consulta. SQL interactivo no distingue entre estos dos tipos de consultas; la misma instruccin SELECT interactiva maneja los dos tipos. En SQL incorporado, sin embar-
UPDATE,
Si importe_ind tiene un valor no negativo cuando se ejecuta la instruccin el SGBD trata la instruccin como si fuera:
:importe2
exec sql update representantes set cuota ~ : importe, ventas where cuota < 20000.00:
DATE,
Si importe_ind tiene un valor negativo cuando se ejecuta la instruccin upel SGBD trata la instruccin como si fuera:
:importe2
exec sql update representantes set cuota = NULL, ventas where cuota < 20000.00;
El par de variables fonnado por la variable del anfitrin y la variable indicadora pueden aparecer en la clusula de asignacin de una instruccin UPDATE incrustada (como se puede ver a continuacin) o en la clusula de valores de una instruccin INSERT incorporada. No se pueden utilizar variables indicadoras en las condiciones de bsqueda, por lo que la siguiente instruccin de SQL incorporado es ilegal:
exec sql de1ete from representantes where cuota ~ :importe :importe_ind;
Esta prohibicin existe por el mismo motivo por el que no se permite la palabra clave NULL en las condiciones de bsqueda -no tiene ningn se~tido comprobar
514
515
go, los dos tipos de consultas se manejan de manera muy diferente. Las consultas de una nica fila resultan ms sencillas de manejar -se estudian en el apartado siguiente-o Las consultas de varias filas se estudian brevemente.
Consultas de una nica fila

Muchas consultas tiles de SQL devuelven una sola fila de resultados. Las consultas de una nica fila resultan especialmente frecuentes en los programas de procesamiento de transacciones, en los que el usuario introduce el nmero de un cliente o el de un pedido y el programa recupera datos importantes del cliente o del pedido. En SQL incorporado. las consultas de una nica fila las maneja la instruccin SELECT nica, que puede verse en la Figura 17.19. La instruccin SELECT nica tiene una sintaxis muy parecida a la de la instruccin SELECT interactiva. Tiene una clusula SELECT, una clusula PROM y una clusula opcional WHERE. Como la instruccin SELECT nica devuelve una sola fila de datos, no hace falta ninguna
clusula GROUP BY, HAVING ni ORDER BY. La clusula INTO especifica las variables del anfitrin que deben recibir los datos recuperados por la instruccin. La Figura 17.20 muestra un programa sencillo con una SELECT nica. El programa pide al usuario un nmero de empleado y luego recupera el nC?mbre, la cuota y las ventas del representante correspondiente. El SGBD ubica los tres elementos de datos recuperados en las variables del anfitrin nombrerep, cuotarep y ventasrep, respectivamente. Recurdese que las variables del anfitrin utilizadas en las instrucciones INSERT, DELETE y UPDATE de los ejemplos anteriores eran variables del anfitrin de entrada. Por el contrario, las variables del anfitrin especificadas en la clusula INTO de la instruccin SELECT nica son variables del anfitrin de salida. Cada
main{ I
{
exec sql begin declare section; int nurnrep; char nombrerep[16];
[L;t
INTO
efementoqu~
ar ..........- - - - - - ,
float cuotarep; float ventasrep; exec sql end declare section;
nmero de empleado (obtenido del usuario) nombre del representante. recuperado */ '* cuota, recuperada */ /* ventas, recuperadas */
'*
'*
*'
'* pide al usuario el nmero de empleado */ printf(-Introduzca el nmero del representante: scanf(-'d", &numrep);
/* Ejecuta la consulta de SQL */ exec sql select nombre, cuota, ventas from representantes where num_empl = :numrep into :nombrerep, :cuotarep, /* Muestra los datos recuperados */ if (sqlca.sqlcode == '= O) { printf("Nombre: ts\n", nombrerep); printf("Cuota: 'f\n, cuotarep); printf("Ventas: tf\n", ventasrep);
}
";
.f
Varjable-d~-anfitri6n
:ventasrep;
L....,... WHERE
condici6n-de-bsqueda
------------------+.-1
el se if (sqlca.sqlcode == == 100) printf("NO hay ningn representante con ese nmero de empleado.\n); else printf("Error de SQL: tld\n", sqlca.sqlcode); exit();
Figura 17.19. Diagrama sintctico de la instruccin SELECT. Figura 17.20. Empleo de la instruccin SELECT nica.
516
Captulo 17; SaL incorporado
517
variable del anfitrin citada en la clusula INTO recibe una sola columna de la fila de resultados de la consulta. Los elementos de la lista de seleccin y las variables del anfitrin correspondientes se emparejan en orden, tal y como aparecen en sus clusulas respectivas, y el nmero de columnas de resullados de la consulta debe ser el mismo que el de variables del anfitrin. Adems, el tipo de datos de cada variable del anfitrin debe ser compatible con el tipo de datos de la columna correspondiente de los resultados de la consulta. La mayor parle de las marcas de SGBD manejan de manera automtica las conversiones razonables entre los tipos de datos del SGBD y los tipos de dalOs admitidos por el lenguaje de programacin. Por ejemplo, la mayor parte de los productos de SGBD convierten los datos MQNEY recuperados de la base de datos en datos decimales comprimidos (COMP-3) antes de almacenarlos en una variable de COBOL, o en datos de coma flotante antes de almacenarlos en una variable de C. El precompilador utiliza su conocimiento del tipo de datos de la variable del anfitrin para manejar correctamente la conversin. Los datQs de texto de longitud variable tambin deben convertirse antes de almacenarlos en una variable del anfitrin. Generalmente, el SOBO convierte los datos VARCHAR en cadenas de caracteres con terminacin nuH para los programas de e, y en cadenas de caracteres de longitud variable (con un contador de caracteres inicial) para los programas de Pascal. Para los programas de COBOL y de FORTRAN, normalmente hay que declarar la variable del anfitrin como estructura de datos con un campo de recuento entero y un array de caracteres. El SGBD devuelve los caracteres reales de los datos en el array de caracteres, y la longitud de los datos en el campo de recuento de la estructura de datos. Si el SaBD admite datos de fecha y hora u otros tipos de datos son necesarias otras conversiones. Algunos productos de SGBO devuelven sus representaciones internas de fecha y hora a una variable entera del anfitrin. Otros convierten los datos de fecha y hora a formato de texto y los devuelven en una variable de cadena de caracteres del anfitrin. La Tabla 17.1 resume las conversiones de tipos de datos que suelen ofrecer los productos de SGBD, pero conviene consultar la documentacin del SQL incorporado para cada marca concreta de SOBO con el fin de lograr informacin ms especfica.
La condicin NO'!' FOUND
Si la consulta no genera ninguna fila de resultados de la consulta, se devuelve un valor especial de advertencia NOT FOUND en SQLCODE y SQLSTATE devuelve una clase de error NO DATA. Si la consulta genera ms de una fila de resultados de la consulta, se trata como un error y se devuelve un valor negativo de SQLCODE. El estndar SQLI especifica la condicin de advertencia NOT FOUND, pero no especifica un valor concreto que deba devolver. DB2 utiliza el valor +100, y la mayor parte de los dems productos de SQL siguen esta convencin, incluidos los dems productos de SQL de IBM, Ingres y SQLBase. Este valor se especifica tambin en el estndar de SQL2 pero, como ya se ha indicado, SQL2 recomienda encarecidamente el empleo de la nueva variable de error SQLSTATE en lugar de los valores antiguos de SQLCODE.
Recuperacin de los valores NULL
Si los datos que hay que recuperar de la base de datos pueden contener valores la instruccin SELECT nica debe proporcionar un modo de que el SGBD comunique los valores NULL al programa de aplicacin. Para manejar los valores NULL el SQL incorporado utiliza variables indicadoras en la clusula INTO, igual que se utilizan en la clusula VALUES de la instruccin INSERT y en la clusula SET de la instruccin UPDATE. Cuando se especifica una variable del anfitrin en la clusula INTO se puede hacer que la siga de manera inmediata el nombre de una variable indicadora del anfitrin acompaante. La Figura 17.21 muestra una versin revisada del programa de la Figura 17.20 que utiliza la variable indicadora cuotarep_ind con la variable del anfitrin cuotarep. Como las columnas NOMBRE y VENTAS estn declaradas como NOT NULL en la definicin de la tabla REPRESENTANTES, no pueden generar valores NULL como resultado, y no hace falta ninguna variable indicadora para esas columnas. Una vez ejecutada la instruccin SELECT, el valor de la variable indicadora indica al programa el modo en que debe interpretar los datos obtenidos:
NULL,
Al igual que todas las instrucciones de SQL incorporado, la instruccin SELECT nica define el valor de las variables SQLCODE Y SQLSTATE para indicar su estado de cumplimiento: Si se recupera con xito una nica fila de resultados de la consulta, se pone SQLCODE a cero y SQLSTATE se define como 00000; las variables del anfitrin citadas en la clusula INTO contienen los valores recuperados. Si la consulta genera un error, SQLCODE se define con un valor negativo y SQLSTATE se define con una clase de error distinta de cero (los do!) primeros caracteres de la cadena de caracteres de cinco cifras SQLSTATE); las variables del anfitrin no contienen ningn valor recuperado.
Un valor de la variable indicadora de cero significa que se ha asignado a la variable del anfitrin un valor recuperado por el SGBD. El programa de aplicacin puede utilizar el valor de la variable indicadora en su procesamiento. Un valor negativo de la variable indicadora significa que el valor recuperado era NULL. El valor de la variable del anfitrin resulta irrelevante y el programa de aplicacin no debe utilizarlo. Un valor positivo de la variable indicadora seala una condicin de advertencia de algn tipo, como los errores de redondeo o los truncamientos de cadenas de caracteres. Como no se puede predecir cundo se recuperar un valor NULL, conviene especificar siempre una variable indicadora en la clusula INTQ de cualquier columna de los resultados de la consulta que pueda contener valores NULL. Si la instruc-
518
519
main ()
1
exec sql include sqlca; exec sql begin declare section; nurorep; int
char
nombrerep[16] ;
/* nmero de empleado
(obtenido
*/ /* nombre del representante,

del usuario)
float cuotarep; float ventasrep short cuotarep_ind; exec sql end declare section;
'*
recuperado recuperado ventas, recuperado */ /* indicador de cuota nu11 */

/* cuota,
*'
*'
/* pide al usuario el nmero de empleado */ printf(-Introduzca el nmero del representante:

scanf ('d". &numrep);
-);
/* Ejecuta la consulta de SQL */ exec sql select nombre, cuota, ventas froro representantes where nUffi_empl = :numrep into :nombrerep, :cuotarep. /* Muestra los datos recuperados */ iE (sqlca.sqlcode ::: ::: O) ( printf(~Nornbre: %s\n-, nombrerep); if (cuotarep_ind < O) printf(~La cuota es NULL\n~l; el se printf("Cuota: 'f\n", cuotarep); printfVentas: 'f\n", ventasrep):
)
:cuotarep_ind.
:ventasrep;
tencia. Por ejemplo, si un desbordamiento aritmtico o una divisin por cero hace que una de las columnas de los resultados de la consulta no resulte vlida, DB2 devuelve un SQLCODE de advertencia de +802 y define la variable indicadora de la columna afectada como - 2. El programa de aplicacin puede responder a SQLCODE y examinar las variables indicadoras para determinar la columna que contiene los datos no vlidos. DB2 tambin utiliza las variables indicadoras para sealar el truncamiento de cadenas de caracteres. Si los resultados de la consulta contienen una columna de datos de caracteres que es demasiado grande para la variable del anfitrin correspondienle, DB2 copia la primera parte de la cadena de caracteres en la variable del anfitrin y define la variable indicadora correspondiente como la longitud completa de la cadena de caracteres. El programa de aplicacin puede examinar la variable indicadora y puede que desee volver a probar la instruccin SELECT con una variable del anfitrin diferente que pueda albergar una cadena de caracteres de mayor tamao. Estos usos adicionales de las variables indicadoras resultan bastante frecuentes en los productos comerciales de SQL, pero los valores concretos de los cdigos de advertencia varan de un producto a otro, No se especifican en el estndar SQL de ANSI/ISO. En lugar de eso, el eSlndar SQL2 especifica las clases y subclases estndar de los errores para indicar eslas condiciones y otras parecidas, y el programa debe utilizar la instruccin GET DIAGNQSTICS para determinar informacin ms concreta sobre la variable del anfitrin que genera el error.
Recuperacin mediante estructuras de datos

Algunos lenguajes de programacin albergan las estructuras de datos, que se denominan conjuntos de variables. Para estos lenguajes, puede que un precompilador de SQL permita al usuario tratar toda la estructura de datos como una sola variable del anfitrin compuesta en la clusula INTO. En lugar de especificar una variable del anfitrin diferente como destino de cada columna de resultados de la consulta, se puede especificar una eslructura de datos como destino de toda la fila. La Figura 17.22 muestra el programa de la Figura 17.21 modificado para utilizar una estructura de datos de C. Cuando el precompilador encuentra la referencia a una estructura de datos en la clusula INTO la sustituye por una lista de las variables incluidas en ella, en el orden en que se han declarado dentro de esa estructura. Por tanlO, el nmero de elementos de la estructura y sus tipos de datos deben coincidir con los de las columnas de los resultados de la consulta. El empleo de estructuras de datos en la clusula INTO es, de hecho, un atajo. No modifica de manera fundamental el modo en que funciona la clusula INTO. " El' soporte del empleo de las estructuras de datos como variables del anfitrin vara ampliamente entre las marcas de SOBD. Tambin se halla limitado a determinados lenguajes de programacin. DB2 admile las estructuras de C y de PUl, pero no las de COBOL ni las de ensamblador, por ejemplo.
el se if (sqlca.sqlcode ::: ::: 100) printf("NO hay ningn representante con ese nmero de empleado. \n"): else printf("ErrOr de SQL: %ld\n", sqlca.sqlcode); exitO;
Figura 11.21.
Empleo de la instruccin SELECT nica con variables indicadoras.
cin SELECT genera una columna que contiene un valor NULL y no se ha especificado ninguna variable indicadora para esa columna, el SGBD tratar la instruccin como si fuera un error y devolver un valor negativo de SQLCODE. Por tanto, hay que utilizar las variables indicadoras para recuperar con xito las filas que contienen datos NULL. Aunque el empleo principal de las variables indicadoras es el manejo de los valores NULL, "el SGBD tambin las utiliza para sealar las condiciones de adver-
520
521
main ()
(
variables del anfitrin numrep y nombrerep ilustran los dos papeles diferentes representados por las variables del anfitrin: La variable del anfitrin nurnrep es una variable del anfitrin de entrada, que se utiliza para pasar datos del programa al SGBD. El programa asigna un valor a la variable antes de ejecutar la instruccin incorporada, y ese valor pasa a ser parte de la instruccin SELECT que el SOBO va a ejecutar. El SGBO no hace nada para modificar el valor de esta variable. La variable del anfitrin nombrerep es una variable del anfitrin de salida, que se utiliza para devolver datos del SGBD al programa. El SGBD asigna un valor a esta variable cuando ejecuta la instruccin SELECT incorporada. Una vez ejecUlada la instruccin, el programa puede utilizar el valor resultante. Las variables del anfitri6n de entrada y de salida se declaran del mismo modo y se especifican utilizando la misma notacin de coma dentro de las instrucciones de SQL incorporado. No obstante, suele resultar til pensar en trminos de variables del anfitrin de entrada y de salida cuando se est llevando a cabo la codificacin del programa de SQL incorporado. Las variables del anfitrin de entrada pueden utilizarse en cualquier instruccin de SQL en la que pueda aparecer una constante. Las variables del anfitrin de salida s6lo se utilizan con la instruccin SELECT nica y con la instruccin FETCH, que se describe en el apartado siguiente de este captulo.
exec sql include sqlcd: exec sql begin declare section; /* numero de empleado (proporcionado int numrep;
por el
struct (
usuario) */
char
nombre[16) ;
float cuota; fIoat ventas; } inforep;
/* nombre del representante. recuperado */ /* cuota. recuperado */ ventas, recuperado
'*
*'
short rep_indl3l; /* array indicadora de valores nul1 */ exec sql end declare seetion;
1* pide al usuario el nmero de empleado */ printf("Introduzca el nmero del representante: scanf('%d", &numrep}; Ejecuta la consulta de SQL */ exec sql select nombre. cuota, ventas
/*
"J;
froro representantes where nurn_empl = :numrep into :inforep :rep_ind;
1* Muestra 10$ datos recuperados */ if (sqlca.sqlcode ::: ::: O) { printf("Nombre: %s\n", inforep.nombre); if (rep_ind(l) < O) printf("La cuota es NULL\n"); else printf("Cuota: 'f\n", inforep.cuota); printf("Ventas: 'f\n", inforep.Ventas);
}
else if (sqlca.sqlcode ::: ::: 100) printf("No hay ningn representante con ese nmero de empleado.\n"); else printf("Error de SQL: %ld\n", sqlca.sqlcode); exit ();
Consultas de mltiples filas

Cuando una consulta genera toda una tabla de resultados, el SQL incorporado debe proporcionar una manera de que el programa de aplicacin los procese fila a fila. SQL incorporado admite esta posibilidad mediante la definicin de un nuevo concepto de SQL, denominado cursor, y aadiendo varias instrucciones al lenguaje SQL interactivo. A continuacin se ofrece una visin general de las tcnicas de SQL incorporado para el procesamiento de consultas de mltiples filas y las instrucciones nuevas que exige:
1.
2.
Figura 17.22.
Empleo de una estructura de datos como variable del an
fitrin. 3.
Variables del anfitrin de entrada y de salida
Las variables gel anfitrin proporcionan una comunicacin en dos sentidos entre el programa y el SOBO. En el programa que puede verse en la Figura 17.21, las
La instruccin DECLARE CURSOR especifica la consulta que se va a llevar a cabo y le asocia el nombre de un cursor. La instruccin OPEN pide al SGBD que comience a ejecutar la consulta y a generar resultados. Coloca el cursor antes de la primera fila de resultados de la consulta. La instruccin FETCH desplaza el cursor hasta la primera fila de los resul tados de la consulta y recupera los datos en variables del anfitrin para su empleo por el programa de aplicacin. Las instrucciones FETCH posterio res se desplazan fila a tila por los resultados de la consulta, desplazando el cursor hasta la siguiente fila de resultados de la consulta y recuperando los datos en las variables del anfitrin.
522
4.
Captulo 17: SQL incorporado
523
La instruccin CLOSE concluye el acceso a los resultados de la consulta y rompe la asociacin entre el cursor y los resultados de la consulta.
exec sql fetch repcurs ilI into :nombrerep, ventasrep; :cuotarep, :cuotarep_ind,
La Figura 17.23 muestra un programa que utiliza el SQL incorporado para llevar a cabo una consulta sencilla de varias filas. Las llamadas numerarlas de la figura se corresponden con Jos nmeros de las etapas que se acaban de explicar. El programa recupera y muestra, en orden alfabtico, el nombre, la cuota y las ventas del ao en curso de cada representante cuyas ventas superan su cuota. La consulta de SQL interactivo que imprime esa informacin es:
5ELECT NOMBRE, CUOTA, VENTAS FROM REPRESENTANTES WHERE VENTAS > CUOTA
ORDER BY NOMBRE
/* Muestra los datos 'recuperados */ printf(*Nombre: %s\n*, nombrerep); if (cuotarep_ind < O) printf{"La cuota es NULL\n*); el se printf("Cuota: %f\n*, cuotarep); printf("Ventas: %f\n", ventasrepl;
error pr ex done:
ntf(~Error
de SQL: %ld\n*, sqlca.sqlcode);
t{);
main ()
(
exec sql include sqlca; exec sql begin declare section; char nombrerep[16]; float cuotarep; float ventasrep; short cuotarep_ind; exec sql end declare section;
/* Consulta completa; cierra el cursor */ exec sql close repcurs; .4~-------------------------------1G) exit ();
/* nombre del representante, recuperado */
/* cuota, recuperado */ /* ventas, recuperado */ /* indicador de valores null de la cuota */
Figura 17.23.
Procesamiento de consultas de varias filas. (Continuacin.)
/* Declara el cursor de la consulta */
exec sql declare select from where order
repcurs cursor for ~ nombre, cuota, ventas representantes ventas > cuota by nombre;
CI)
/* Define el procesamiento de los errores */ whenever sqlerror gota error; whenever not found gota final;
/* Abre el cursor para iniciar la consulta */ exec sql open repcurs; ,.

/* Itera el bucle para cada fila de resultados de la consulta */
for (;;)
/* Captura la siguiente fila de resultados de la consulta */
Figura 17.23.. Procesamiento de consultas de varias filas. (Contina.)
Obsrvese que esta consulta aparece, palabra por palabra, en la instruccin incorporada DECLARE CURSOR de la Figura 17.23. La instruccin tambin asocia el nombre de cursor repcurs con la consulta. Este nombre de cursor se utiliza posteriormente en la instruccin OPEN CURSOR para iniciar la consulta y colocar el cursor antes de la primera fila de resultados de la consulta. La instruccin FETCH dentro del bucle for captura la siguiente fila de resultados de la consulta cada vez que se ejecuta ese bucle. La clusula INTO de la instruccin FETCH funciona igual que la clusula INTO de la instruccin SELECT nica. Especifica las variables del anfitrin que van a recibir los elementos de datos capturados -una variable del anfitrin por cada columna de resultados de la consulta. Como en los ejemplos anteriores, se utiliza una variable indicadora del anfitrin (cuotarep_ind) cuando algn elemento de datos capturado puede contener valores NULL. Cuando no hay que capturar ms filas de resultados de la consulta, el SGBD devuelve la advertencia NOT FOUND en respuesta a la instruccin FETCH. Se trata exactamente del mismo cdigo de advertencia que se devuelve cuando la instruccin SELECT nica no puede recuperar una fila de datos. En este programa la instruccin WHENEVER NOT FOUND hace que el precompilador genere cdigo que comprueba el valor de SQLCODE despus de la instruccin FETCH. Este cdigo generado se bifurca hasta la etiqueta final cuando surge la condicin NOT FOUND, y a la etiqueta error si se produce alguno. Al final del programa, la instruccin CLOSE
524
525
concluye la consulta y finaliza el acceso del programa a los resultados de la consulta.

Cursores
r--
DECLARE nombre-cursor CURSOR FOR instrucc;n-SELECT
..
Como ilustra el programa de la Figura 17.23, los cursores de SQL incorporado se comportan de manera muy parecida a la de los nombres de archivo o los controladores de archivos en lenguajes de programacin como e o COBOL. Al igual que los programas abren los archivos para tener acceso a su contenido, abren Jos cursores para tener acceso a los resultados de las consultas. De manera parecida, los programas cierran los archivos para concluir el acceso y cierran los cursores para concluir el acceso a los resultados de las consultas. Finalmente, al igual que el controlador realiza un seguimiento de la posicin actual del programa en los archivos abiertos, los cursores realizan un seguimiento de la posicin presente del programa en los resultados de las consultas. Estos paralelismos entre la entrada y salida de los archivos y los cursores de SQL hacen el concepto de cursor relativamente sencillo de comprender para los programadores de aplicaciones. Pese a estos paralelismos entre los archivos y los cursores, hay algunas diferencias. La apertura de un cursor de SQL suele implicar mucha mayor sobrecarga que la de un archivo, ya que la apertura del cursor hace realmente que el SGBD comience a ejecutar la consulta asociada. Adems, los cursores de SQL slo admiten el movimiento secuencial por los resultados de las consultas, parecido al procesamiento secuencial de los archivos. En la mayor parte de las implementaciones actuales de SQL, no hay una analoga para los cursores del acceso aleatorio proporcionado a los registros individuales de los archivos. Los cursores proporcionan una gran flexibilidad en el procesamiento de consultas en los programas de SQL incorporado. Mediante la declaracin y apertura de varios cursores los programas pueden procesar en paralelo varios conjuntos de resultados de consultas. Por ejemplo, el programa puede recuperar varias filas de resultados de consultas, mostrarlas en la pantalla del usuario y responder a la peticin de un usuario de datos ms detallados mediante el lanzamiento de una segunda consulta, Los apartados siguientes describen con detalle las cuatro instrucciones de SQL incorporado que definen y manipulan los cursores.
La instruccin DECLARE CURS0R
Figura 17.24.
DEC.
La instruccin DECLARE CURSOR, que puede verse en la Figura 17.24, define la consulta que hay que llevar a cabo. La instruccin tambin asocia con la consulta el nombre de un cursor. El nombre del cursor debe ser un identificador vlido de SQL. Se emplea para identificar la consulta y su resultado en otras instrucciones de SQL incorporado. El nombre del cursor, en concreto, no es una variable del lenguaje anfitrin; se declara mediante la instruccin DECLARE CURSOR, no en una declaracin del lenguaje anfitrin. La instruccin SELECT de la instruccin DECLARE CURSOR define la consulta asociada con e:l cursor, La instruccin SELECT puede ser cualquier instruccin SELECT vlida de SQL interactivo, tal y como se describe en los captulos 6 a 9.
En concreto, la instruccin SELECT debe incluir una clusula FROM y puede incluir de manera opcional las clusulas WHERE, GROUP BY, HAVING Y ORDER BY. La instruccin SELECT tambin puede incluir el operador UNION, tal y como se describe en el Captulo 6. Por tanto, las consultas de SQL incorporado pueden utilizar cualquiera de las posibilidades de las consultas disponibles en el lenguaje SQL interactivo. La consulta especificada en la instruccin DECLARE CURSOR tambin puede incluir variables de entrada del anfitrin. Estas variables del anfitrin llevan a cabo exactamente la misma funcin que en las instrucciones INSERT, DELETE y UPDATE incorporadas y en la instruccin SELECT nica. Las variables de entrada del anfitrin pueden aparecer dentro de la consulta en cualquier lugar en que pueda aparecer una constante. Obsrvese que las variables de salida del anfitrin no pueden aparecer en la consulta. A diferencia de la instruccin SELECT nica, la instruccin SELECT del interior de la instruccin DECLARE CURSOR no tiene ninguna clusula INTO y no recupera ningn dato. La clusula INTO aparece como parte de la instruccin FETCH, que se describe brevemente, Como su nombre indica, la instruccin DECLARE CURSOR es una declaracin del cursor. En la mayor parte de las implementaciones de SQL, incluidos los productos de SQL de IBM, esta instruccin es una directriz para el precompilador de SQL; no se trata de una instruccin ejecutable, y el precompilador no genera ningn cdigo para ella. Al igual que todas las declaraciones, la instruccin DECLARE CURSOR debe aparecer fsicamente en el programa antes de ninguna instruccin que haga referencia al cursor que declara. La mayor parte de las implementaciones de SQL tratan los nombres de los cursores como nombres globales a los que se puede hacer referencia dentro de cualquier procedimiento, funcin O subrutina que aparezca tras la instruccin DECLARE CURSOR. Merece la pena destacar que no todas las implementaciones de SQL tratan la instruccin DECLARE CURSOR estrictamente como una instruccin declarativa, y esto puede crear problemas sutiles. Algunos precompiladores de SQL generan realmente cdigo para la instruccin DECLARE CURSOR (declaraciones del lenguaje anfitrin, llamadas al SGBD o ambas cosas), lo que le da algunas de las cualidades de las instrucciones ejecutables. Para esos precompiladores, la instruccin DECLARE CURSOR no slo debe anteceder fsicamente a las instrucciones OPEN, FETCH Y CLaSE que hacen referencia a ese cursor, sino que, a veces, tambin debe precederlas en el flujo de ejecucin o hallarse situada en el mismo bloque que las dems instrucciones. En general, se pueden evitar problemas con la instruccin DECLARE CURSOR siguiendo estas directrices:
526
527
Ubicar la instruccin DECLARE CURSOR justo antes de la instruccin QPEN del cursor. Esta ubicacin asegura la secuencia fsica correcta de las instrucciones. coloca las instrucciones DECLARE CURSOR Y OPEN en el mismo bloque y asegura que el flujo de control pase por la instruccin DECLARE CURSOR, si fuera necesario. Tambin ayuda a documentar la consulta que solicita
exactamente la instruccin OPEN. Asegurarse de que las instrucciones FETCH Y CLOSE del cursor siguen fsicamente a la instruccin OPEN, as como en el flujo de control.
La instruccin OPEN
1-- FETCH
nombre*cursor INTO - - - . tvana be-d;-anfitrinj
Figura 17.26.
Diagrama sintactico de la instruccin
FETCH.
cursor
La instruccin OPEN, que puede verse en la Figura 17.25, abre conceptualmente la tabla de los resultados de la consulta para que tenga acceso a ella el programa de aplicacin. En la prctica, la instruccin OPEN hace que el SGBD procese la consulta o, al menos, que comience a hacerlo. La instruccin OPEN, por lo tanto, hace que el SGBD lleve a cabo la misma labor que la instruccin SELECT interactiva, a falta slo de la generacin de la primera fila de resultados. El nico parmetro de la instruccin OPEN es el nombre del cursor que hay que abrir. Este cursor debe haberse declarado anteriormente mediante una instruccin DECLARE CURSOR. Si la consulta asociada con el cursor contiene un error, la instruccin OPEN genera un valor negativo de SQLCODE. La mayor parte de los errores de procesamiento de consultas, como las referencias a tablas desconocidas, los nombres ambiguos de columnas o los intentos de recuperar datos de tablas sin los permisos adecuados, se comunican como resultados de la instruccin OPEN. En la prctica, se producen muy pocos errores durante las instrucciones FETCH posteriores. Una vez abierto, los cUISores siguen en ese estado hasta que se cierran con la instruccin CLOSE. El SGBD tambin cierra de manera automtica todos los cursores abiertos al final de cada transaccin (es decir. cuando el SGBD ejecuta una instruccin COMMIT o ROLLBACK). Una vez cerrado el CUISor, puede volver a abrirse ejecutando la instruccin OPEN por segunda vez. Tngase en cuenta que el SGBD vuelve a inici~ la consulta desde el principio cada vez que ejecuta la instruccin OPEN.
La instruccin FETCH
en la instruccin FETCH especifica la fila de resultados de la que h~y que capturar. Debe identificar un cursor ya abierto anteriormente por la Instruccin OPEN. La instruccin FETCH captura la fila de elementos de datos en una lista de variables del.anfitrin, que se especifica en la clusula INTO de la instruccin. Se puede asocl~r una variable indicadora con cada variable del anfitrin para manejar la recuperacIn de datos NULL. El comportamiento de la variable indicadora y los valores qu~ p.uede adoptar SO? idnti~os a los ya descritos en el apartado Consultas de una umca fila para la lOstruccln SELECT nica. El nmero de variables del anfitrin de la lista debe ser igual que el de columnas del resultado de la consulta y los tipos de datos de las variables del anfitrin deben ser compatibles, columna ~ columna, con las columnas de resultados de la consulta. Corno puede verse en la Figura 17.27, la instruccin FETCH desplaza el cursor por los resultados de la consulta, fila a fila, de acuerdo con las reglas siguientes:
consul~a
mencion~do
La instruccin OPEN coloca el cursor antes de la primera lnea de resultados de la consulta. En ese estado, el cursor no tiene fila actual.
OP~
H PETC H+ FETeH+ FETeH
FETC
La instruccin FETCH, que puede verse en la Figura 17.26, recupera la siguiente
Resul tado de la consul ta (tres filasl

ID FAB ID PRODUCTO DESCRIPCIN
fila de resultados de la consulta para que la utilice el programa de aplicacin. El
~OPEN nombre-cursor-,----------------..,,---+-e
USING
1 1
(NOT FOUND)
I~
I~
Y CLOSE.
tVariSble-del.anfilrin
Figura 17.25',
OPEN.
Figura 17.27.
Colocacin del cursor con las instrucciones
OPEN, FETCH
I
2
528
529
La instruccin FETCH desplaza el cursor hasta la siguiente fila disponible de resultados de la consulta, si es que hay alguna. Esa fila pasa a ser la fila actual del cursor. Si una instruccin FETCH desplaza el cursor ms all de la ltima fila de resultados de la consulta, la instruccin FETCH devuelve una advertencia NQT FOUNO. En ese estado, el cursor no tiene fila actual. La instruccin CLOSE concluye el acceso al resultado de la consulta y deja el cursor en estado de cierre.
Si no hay ninguna fila de resultados de la consulta, la instruccin OPEN sigue colocando el cursor antes del resultado (vaco) de la consulta y lo devuelve con xito. El programa no puede detectar que la instruccin OPEN ha generado un conjunto vaco de resultados de la consulta. Sin embargo, la primera instrucci6n FETCH genera la advertencia NOT FOUND y coloca el cursor tras el final del resultado (vaco) de la consulta.
CLOSE
nombre-cursor
~.
Figura 17.28.
Diagrama sintctico de
la
instruccin
CLOSE.
FETC~ PRIOR
La instruccin
CLOSE
recupera la fila de resultados de la consulta que antecede inmediatamente a la fila actual del cursor. FETCH NEXT recupera la fila de resultados de la consulta que sigue inmediatamente a la fila actual del cursor. Se trata del comportamiento predeterminado si no se especifica ningn movimiento, y se corresponde con el movimiento de los cursores estndar. FETCH ABSOLUTE recupera una fila concreta a partir de su nmero de fila. FETCH RELATIVE desplaza el cursor hacia delante O hacia atrs un nmero concreto de filas respecto a su posi~in presente.
La instruccin CLOSE, que puede verse en la Figura 17.28, cierra conceptualmente la tabla de resultados de la consulta creada por la instruccin OPEN, lo que concluye el acceso a ella del programa de aplicacin. Su nico parmetro es el nombre del cursor asociado con el resultado de la consulta, que debe ser un cursor abierto anteriormente por una instruccin OPEN. La instruccin CLOSE puede ejecutarse en cualquier momento una vez abierto el cursor. En concreto, no es necesario que se haya ejecutado FETCH sobre todas las filas de la consulta antes de cerrar el cursor, amique se trate del caso ms frecuente. Todos los cursores se cierran de manera automtica al final de cada transaccin. Una vez cerrado un cursor, los resultados de su consulta dejan de estar disponibles para el programa de aplicacin.
Cursores de desplazamiento
El estndar SQLI especifica que los cursores slo pueden desplazarse hacia delante por los resultados de la consulta. Hasta hace pocos aos la mayor parte de los productos comerciales de SQL tambin disponan nicamente de esta forma de movimiento del cursor secuencial y hacia delante. Si un programa desea volver a recuperar una fila una vez que el cursor la ha superado, el programa debe ejecutar CLOSE sobre el cursor y luego volver a ejecutar OPEN sobre l (lo que hace que el SGBD vuelva a llevar a cabo la consulta); de~pus hay que ejecutar FETCH sobre las filas hasta alcanzar la fila deseada. A principios de los aos noventa, unos cuantos productos comerciales de SQL ampliaron el concepto de cursor con el de cursor de desplazamiento. A diferencia de los cursores estndar, los cursores deslizantes proporcionan un acceso aleatorio a las filas de resultados de la consulta. El programa especifica la fila que desea recuperar mediante una ampliacin de la instruccin FETCH, que puede vese en la Figura 19.28:
FETCH .FIRST FETCH LA8T
recupera la primera fila de resultados de la consulta. recupera la ltima fila de resultados de la consulta.
Los cursores de desplazamiento pueden resultar especialmente tiles en programas que permiten al usuario explorar el contenido de la base de datos. En respuesta a la solicitud del usuario de desplazamiento por los datos hacia delante o hacia atrs una fila o una pantalla, de golpe el programa puede, sencillamente, capturar las filas necesarias del resultado de la consulta. No obstante, los cursores deslizantes tambin son mucho ms difciles de implementar para el SGBD que los cursores normales unidireccionales. Para soportar un cursor de desplazamiento, el SGBD debe realizar el seguimiento del resultado de la consulta que proporcion anteriormente al programa, y del orden en que proporcion esas filas de resultados. El SGBD tambin debe asegurarse de que ninguna otra transaccin que se ejecute de manera concurrente modifique los datos que se han hecho visibles para el programa mediante el cursor de desplazamiento, ya que el programa puede utilizar la instruccin FETCH ampliada para volver a recuperar esa fila, aunque el cursor se haya desplazado ms all de esa fila. Si se utilizan cursores de desplazamiento, hay que tener en cuenta que algunas instrucciones FETCH sobre stos pueden suponer una sobrecarga muy elevada para algunas marcas de SGBD. Si la marca de SGBD ejecuta normalmente las consultas paso a paso cuando el programa ejecuta FETCH mientras avanza por los resultados de la consulta, puede que el programa espere mucho ms tiempo de lo normal si se solicita una operacin FETCH NEXT cuando el cursor se halla ubicado en la primera fila de resultados de la consulta. Es conveniente comprender las caractersticas de rendimiento de cada marca de SGBD antes de escribir programas que dependan de la funcionalidad de los cursores de desplazamiento para las aplicaciones de produccin. Debido a la utilidad de estos cursores, y dado que unos cuantos fabricantes de SGBD haban comenzado a distribuir implementaciones de los cursores de desplazamiento que eran ligeramente diferentes entre s, el estndar SQL2 se ampli para incluir el soporte de los cursores de desplazamiento. El nivel inicial del ,estndar
530
531
L
.FETCH
_-,
FROM nombre-cursorINTO
-FlRST--------1 -LAST - - - - - - - - - j -PRIOR--------j

-NEXT _ ABSOLUTE -RELATIVE
'& an",itrin ,...... L - =-.J
variabledef-
~ DELETE FROM nombre-cursor WHERE CURRENT OF nombre-cursor
.~.
Figura 17.30.
Diagrama sintctico de la instruccin DELETE posicionada.
nmero-fila-
BnmeW-fiI"-
Figura 17.29.
Instruccin
FETCH
ampliada para los cursores de desplazamiento.
SQL slo exige el cursor secuencial hacia delante del viejo estilo, pero el cumplimiento de los niveles intermedio o completo de SQL exige el soporte completo de la sintaxis de los cursores de desplazamiento que puede verse en la Figura 17.29. El estndar tambin especifica que, si se utiliza algn movimiento aparte de FETCH NEXT (el valor predeterminado) en el cursor, su instruccin DECLARE CURSOR debe identificarlo de manera explcita como cursor de desplazamiento. Empleando la sintaxis de SQL2, la declaracin de cursor de la Figura 17.22 aparecera como:
exec sql declare select from where arder repcurs scroll cursor for nombre, cuota, ventas representantes ventas > cuota by nombre;
sea incorrecta, o que el cliente desee eliminar uno de los pedidos. En esta situacin el usuario desea actualizar o eliminar ese pedido. La fila no viene identificada por la condicin de bsqueda habitual de SQL; ms bien, el programa utiliza el cursor cOll1 o puntero para indicar la fila concreta que hay que actualizar o eliminar. SQL incorporado dispone de esta posibilidad mediante versiones especiales de las instrucciones DELETE y UPDATE, denominadas, respectivamente, DELETE posi~ cionada y UPDATE posicionada. La instruccin DELETE posicionada, que puede verse en la Figura 17.30, elimina una sola fila de la tabla. La fila eliminada es la fila presente de uno de los cursores que hacen referencia a esa tabla. Para procesar la instruccin, el SGBD busca la fila de la tabla base que corresponde a la fila actual del cursor y la elimina de la tabla base. Una vez eliminada la fila, el cursor deja de tener fila actual. En vez de eso, el cursor se ubica de hecho en el espacio vaco a la izquierda de la fila eliminada, esperando a que una instruccin FETCH posterior lo desplace a la fila siguiente. La instruccin UPDATE posicionada, que puede verse en la Figura 17.31, actualiza una sola fila de la tabla. La fila actualizada es la fila presente de uno de los cursores que hacen referencia a la tabla. Para procesar la instruccin, el SGBD busca la fila de la tabla base que corresponde a la fila presente del cursor y la actualiza tal y corno se especifica en la clusula SET. Una vez actualizada la fila, sigue siendo la fila presente del cursor. La Figura 17.32 muestra un programa de exploracin de pedidos que utiliza las instrucciones UPDATE y DELETE posicionadas: l. El programa pide primero al usuario el nmero de un cliente y luego consulta la tabla PEDIDOS para buscar todos los pedidos realizados por ese cliente.
Eliminaciones y actualizaciones con cursores

Los programas de aplicacin suelen utilizar los cursores para permitir que el usuario explore las tablas de datos fila a fila. Por ejemplo, puede que el usuario pida ver todos los pedidos realizados por un cliente concreto. El programa declara un cursor para una consulta a la tabla PEDIDOS y muestra cada pedido en pantalla, posiblemente en un formulario generado por la computadora, mientras espera una seal del usuario para pasar a la fila siguiente. La exploracin contina de esta manera hasta que el usuario alcanza el final de los resultados de la consulta. El cursor sirve de puntero para la fila actual de resultados de la consulta. Si la consulta extrae los datos de una tabla y no se trata de una consulta resumen, como en este ejemplo, el cursor apunta de manera implcita a una fila de una tabla de la base de datos, ya que cada fila de resultados de la consulta se extrae de una sola fila de ,la tabla. Mientras se. exploran los datos puede que el usuario localice alguno que deba modificarse. Por ejemplo, puede que la cantidad solicitada de uno de los pedidos
1- UPDATE
nombre-tabla SET
nombre-columna
expresin
-l
WHERE CURRENT OF nombre-cursor,--------------~~.
Figura 17.31.
UPDATE
posicionada.
532
533
2.
main ()
(
exec sql include sqlca; exec sql begin declare section; nurncli; /' nmero de cliente, int proporcionado por el usuario ~I numped; / ' nmero del pedido. int recuperado */ / ' fecha del pedido. recuperado * char fechapedI12]; fabped[4]; / ' identificador del fabricante. char recuperado */ / ' identificador del producto, char productoped[6) ; recuperado */ cantped; int l' cantidad del pedido, recuperado */ float importeped; l' importe del pedido, recuperado */ exec sql end declare section; char inbuf[lOl] /* carcter proporcionado por el usuario */
/* Declara el cursor para la consulta */ exec sql declare pedcurs cursor for select num-pedido, fecha-pedido. fab. producto, cantidad, importe from pedidos where cliente = numcli arder by num_pedido for update of cantidad, importe;
/* Pide al usuario un nmero de cliente */ printf{"Introduzca nmero de cliente: "); scanf{-'d-, &numcli);
/* Configura el procesamiento de los errores */ whenever $Qlerror gato error; whenever not found gota final;
3. 4. 5.
6.
Cuando recupera cada fila de resultados de la consulta, muestra la informacin de los pedidos en la pantalla' y pregunta al usuario lo que debe hacer a continuacin. Si el usuario .escribe N, el programa no modifica el pedido presente, sino que se desplaza directamente al siguiente. Si el usuario escribe D, el programa elimina el pedido presente empleando una instruccin DELETE posicionada. Si el usuario escribe U, el programa pide al usuario una--cantidad y un importe nuevos, y luego actualiza esas dos columnas del pedido presente utilizando una instruccin UPDATE posicionada. Si el usuario escribe X, el programa detiene la consulta y concluye.
Aunque resulte primitivo en comparacin con los programas de aplicacin reales, el ejemplo de la Figura 17.32 muestra toda la lgica y las instrucciones de SQL incorporado necesarias para implementar una aplicacin de exploracin con aClUalizaciones de la base de datos basadas en cursores. El estndar SQLI especifica que las instrucciones DELETE y UPDATE posicionadas slo pueden utilizarse con cursores que cumplan estrictamente estos criterios: La consulta asociada con el cursor debe extraer los datos de una sola tabla fuente; es decir, slo debe mencionarse una tabla en la clusula FROM de la consulta especificada en la instruccin DECLARE CURSOR. La consulta no puede especificar ninguna clusula aRDER BY; el cursor no debe identificar un conjunto ordenado de resultados de la consulta. La consulta no puede especificar la palabra clave DISTINCT. La consulta no debe incluir ninguna clusula GROUP BY ni HAVING. El usuario debe tener el privilegio UPDATE o DELETE (lo que corresponda) sobre la tabla base.
(1
/* Abre el cursor para comenzar la consulta */ exec sql open pedcurs;--------------------------/*
for
Itera por cada fila de resultados de la consulta */ (;;) (

/* Captura la siguiente fila de resultados de la consulta */ exec sql fetch pedcurs , (2 into :numped. :fechaped, :fabped. :productoped, :cantidadped, :importeped;
/* Muestra los datos recuperados */ printf("NmerO del pedido: %d\n", nuroped); printf("Fecha del pedido: %s\n", fechaped); printf{-Fabricante: %s\n-, fabpedl;
Figura 17.32.
Empleo de las instrucciones
DELETE
y UPDATE posicionadas.
Las bases de datos de IBM (DB2, SQUDS) ampliaron las restricciones de SQLl un paso ms all. Exigen que el cursor se declare de manera explcita como cursor actualizable en la instruccin DECLARE CURSOR. La forma ampliada de IBM de la instruccin DECLARE CURSOR se puede ver en la Figura 17.33. Adems de declarar un cursor actualizable, la clusula FOR UPDATE puede especificar de manera opcional columnas concretas que pueden actualizarse mediante el cursor. Si la lista de columnas se especifica en las declaraciones del cursor, las instrucciones UPDATE posicionadas del cursor slo pueden actualizar esas columnas. En la prctica, todas las implementaciones comerciales de SQL que disponen de las instrucciones DELETE y UPDATE posicionadas siguen el enfoque de SQL de IBM. Supone una gran ventaja que el SGBD conozca con antelacin si el cursor se utilizar para actualizaciones o si sus datos son slo de lectura, ya que el procesamiento slo de lectura es ms sencillo. La clusula FOR UPDATE proporciona este aviso previo y puede considerarse un eslndar de tacto del lenguaje SQL incorporado. Debido a su empleo generalizado, el estndar SQL2 incluye la clusula estilo mM FOR UPDATE como opcin de la instruccin DECLARE CURSOR. No obstante, a
534
535
~ DELETE CURSOR nombre-eursor FOR intruccinSELECT---------,
FOR UPDATE
truccin COMMIT como la instruccin ROLLBACK cierran de manera automtica lodos los cursores abiertos. El SGBD proporciona entre bastidores esta garanta de consistencia bloqueando todas las filas del resultado de la consulta, lo que evita que otros usuarios las modifiquen. Si la consulta genera muchas filas de datos, puede que el curSOr bloquee una parte importante de la tabla. Adems, si el programa espera el aporte del usuario tras la captura de cada fila (por ejemplo, permitir que el usuario compruebe los datos que aparecen en la pantalla), puede que algunas partes de la base de datos queden bloqueadas durante mucho tiempo. En casos extremos el usuario puede salir a almorzar en mitad de la transaccin y bloquear a los dems usuarios durante una hora o ms. Para minimizar la cantidad de bloqueos necesaria, conviene seguir estas directrices al escribir programas interactivos de consulta: Hacer que las transacciones sean tan canas como sea posible. Generar una instruccin COMMIT inmediatamente despus de cada consulta y en cuanto sea posible una vez que el programa haya completado una actualizacin. Evitar los programas que exijan gran cantidad de interaccin con el usuario o que exploren muchas filas de datos. Si se sabe que el programa no va a volver a capturar una fila de datos despus de que el cursor la haya superado, hay que utilizar alguno de los modos de aislamiento menos restrictivos de los que se describen en el Captulo 12. Esto permite que el SGBD desbloquee una fila en cuanto se genera la siguiente instruccin FETCH. Evitar el empleo de cursores deslizantes a menos que se hayan emprendido otras acciones para eliminar o minimizar el bloqueo adicional de la base de datos que generan. Especificar de manera explcita los cursores como READ ONLY, si es posible.
Figura 17.33.
La instruccin DECLARE CURSOR con la clusula FOR UPDATE.
diferencia de Jos productos de IBM, el estndar SQL2 da por supuesto de manera automtica que los cursores se abren para actualizacin, a menos que sea un cursor deslizante o se declare de manera explcita FOR READ ONLY. La especificacin FOR READ ONLY de la instruccin SQL2 DECLARE CURSOR aparece exactamente en la misma posicin que la clusula FOR UPDATE e indica de manera explcita al SGBD que el programa no intentar ninguna operacin DELETE ni UPDATE posicionadas empleando ese cursor. Como pueden afectar de manera muy significativa a la sobrecarga y al rendimiento de la base de datos, puede. resultar muy importante comprender las suposiciones concretas que realiza cada marca concreta de SGBD sobre la posibilidad de actualizacin de los cursores y las clusulas o instrucciones que pueden utillzarse para anularlas. Adems, los programas que declaran de manera explcita si su intencin es permitir las actualizaciones mediante un cursor abierto son ms fciles de mantener.
Los cursores y el procesamiento de transacciones

La manera en que el programa maneja sus cursores puede tener un efecto importante en el rendimiento de la base de datos. Recurdese del Captulo 12 que el modelo de transacciones de SQL garantiza la consistencia de los datos durante las transacciones. En trminos de los cursores, eso significa que el programa puede declarar un cursor, abrirlo, capturar el resultado de la consulta, cerrarlo, volver a abrirlo y capturar nuevamente los resultados de la consulta -y tener la garanta de que los resultados de la consulta sern idnticos en ambas ocasiones-. El programa tambin puede capturar la misma fila mediante dos cursores diferentes y tener la garanta de que el resultado ser idntico. De hecho, se tiene la garanta de que los datos seguirn siendo consistentes hasta que el programa genere una ins~uccin COMMIT o RQLLBACK para finalizar la transaccin. Como la consistencia no est garantizada de unas transacciones a otras.. tanto la ins-
Resumen
Adems de su papel como lenguaje interactivo de bases de datos, SQL se utiliza para el acceso mediante programacin a las bases de datos relacionales: La tcnica ms frecuente para el empleo en programacin de SQL es el SQL incorporado, en el que las instrucciones de SQL se incorporan al programa de aplicacin, entremezcladas con las instrucciones de un lenguaje de programacin anfitrin como C o COBOL. Las instrucciones de SQL incorporado se procesan mediante un precompiladar especial de SQL. Comienza con un introductor especial (generalmente EXEC SQL) y concluye con un terminador, que vara de un lenguaje anfitrin a otro. Las variables del programa de aplicacin, denominadas variables del anfitrin, pueden utilizarse en las instrucciones de SQL incorporado siempre que
536
pueda aparecer una constante. Estas variables de entrada del anfitrin adoptan la instruccin de SQL incorporado a cada situacin concreta. Las variables del anfitrin se utilizan tambin para recibir el resultado de las consultas a la base de datos. El valor de estas variables de salida del anfitrin puede ser procesado por el programa de aplicacin. Las consultas que generan una sola fila de datos las maneja la instruccin SELECT nica de SQL incorporado, que especifica tanto la consulta como las variables del anfitrin que deben recibir los datos recuperados. En SQL incorporado las consultas que generan varias filas de resultados de la consulta se manejan con cursores. La instruccin DECLARE CURSOR define la consulta; la instruccin OPEN comienza el procesamiento de la consulta; la instruccin FETCH recupera filas sucesivas de resultados de la consulta, y la instruccin CLOSE finaliza el procesamiento de la consulta. Las instrucciones UPDATE y DELETE posicionadas pueden utilizarse para actualizar o eliminar la fila seleccionada en cada mon:ento por el cursor.
CAPTULO
18
SOL dinmico*
Las caractersticas de programacin de SQL incorporado descritas en el Captulo 17 se conocen en conjunto como SQL estdtico. SQL esttico resulta adecuado para escribir los programas que suelen necesitarse en las aplicaciones de proceso de datos. Por ejemplo, en la aplicacin de proceso de datos de la aplicacin de ejemplo se puede utilizar SQL esttico para escribir los programas que manejan la admisin de pedidos, las actualizaciones de los pedidos, las bsquedas de pedidos, las bsquedas de clientes, el mantenimiento de los archivos de los clientes y los programas que generan cualquier tipo de informes. En cada uno de esos programas la modalidad de acceso a la base de datos la decide el programador y la fija en el cdigo del programa como una serie de instrucciones de SQL incorporado. No obstante, hay una clase importante de aplicaciones en la que la modalidad de acceso a la base de datos no puede detenninarse con antelacin. Las herramientas de consulta grfica o los redactores de informes, por ejemplo, deben poder decidir en el momento de la ejecucin las instrucciones de SQL que van a emplear para tener acceso a la base de datos. Las hojas de clculo de las computadoras personales que admiten el acceso a las bases de datos del anfitrin tambin deben poder enviar consultas al SGBD del anfitrin para su ejecucin sobre la marcha. Estos programas y otras partes visibles de las bases de datos de finalidad general no pueden escribirse empleando tcnicas de SQL esttico. Necesitan una forma avanzada de SQL incorporado, denominada SQL dindmico, que se describe en este captulo.
Lmites de SOL esttico

Como el nombre SQL esttico indica, los programas creados empleando las caractersticas de SQL incorporado, descritas en el Captulo 17 (las variables del anfitrin, los cursores y las instrucciones DECLARE CURSOR. OPEN, FETCH Y CLOSE), tienen una modalidad fija predeterminada de acceso a la base de datos. Para cada instruccin de SQL incorporado del programa, el programador detennina con an-
537
538
Captulo 18: SOL dinmico*
539
telacin las tablas y columnas a las que esa instruccin hace referencia y las fija en el cdigo de la instruccin de SQL incorporada. Las variables de entrada del anfitrin ofrecen cierta flexibilidad en SQL esttico, pero no modifican de manera esencial su naturaleza esttica. Recurdese que las variables del anfitrin pue.den aparecer en cualquier lugar en que se permita una constante dentro de las instrucciones de SQL. Se pueden utilizar variables del anfitrin para modificar las condiciones de bsqueda:
exec sql select nombre, cuota, ventas fraro representantes where cuota> : importe_corte;
Tambin se pueden utilizar las variables del anfitrin para modificar los datos insertados o actualizados en la base de datos:
exec sql update representantes set cuota ~ cuota + :incremento where cuota >:importe_corte;
Los productos de SQL de IBM han admitido SQL dinmico desde su introduccin, igual que han hecho los productos comerciales de SGBDR basados en minicomputadoras y en UNIX. Sin embargo, el estndar SQL de ANSI/ISO 1 original no especificaba SQL dinmico; el estndar slo defina SQL esttico. La ausencia de SQL dinmico en el estndar SQLI resulta irnica, dada la idea popular de que el estndar permita crear herramientas del frontal de la base de datos que podan portarse a muchas marcas diferentes de SOBD. De hecho, esas herramientas del frontal deben crearse casi siempre empleando SQL dinmico. En ausencia de un estndar ANSI/ISO, DB2 defini el estndar de facto para SQL dinmico. Las otras bases de datos de IBM de aquel tiempo (SQLIDS y OS/2 Extended Edition) eran casi idnticas a DB2 en su soporte de SQL dinmico, y la mayor parte de los dems productos de SQL tambin siguieron el estndar de DB2. En 1992 el estndar SQL2 aadi el soporte oficial al SQL dinmico, siguiendo sobre todo el camino marcado por lBM. El estndar SQL2 no exige el soporte de SQL dinmico en el nivel ms bajo de cumplimiento (entrada), pero s lo exige para los productos que proclaman el cumplimiento de los niveles intermedio o completo del estndar SQL.
No obstante, no se pueden utilizar variables del anfitrin en lugar de los nombres de las tablas ni de las referencias a las columnas. El intento de empleo de las variables del anfitrin que_tabla y que_columna en estas instrucciones es ilegal:
exec sql update :que_tabla set :que_columna
~
Conceptos de SOL dinmico

El concepto fundamental de SQL dinmico es sencillo: no incluir las instrucciones de SQL incorporado en el cdigo fuente del programa. En lugar de eso, dejar que el programa cree el texto de la instruccin SQL en una de las reas de datos en el momento de la ejecucin. El programa pasa entonces el texto de la instruccin al SGBD para su ejecucin sobre la marcha. Aunque los detalles resulten bastante complejos, todo SQL dinmico se crea alrededor de este concepto sencillo, y resulta conveniente tenerlo presente. Para comprender SQL dinmico y sus semejanzas y diferencias con SQL esttico, resulta til considerar nuevamente el proceso que sigue el SGBD para ejecutar las instruccin de SQL, que puede verse originalmente en la Figura 17.1 Y se repite aqu en la Figura 18.1. Recurdese del Captulo 17 que las instrucciones de SQL esttico siguen los cuatro primeros pasos del proceso en el momento de la compilacin. La utilidad BIND (o la parte equivalente del sistema de tiempo de ejecucin del SGBD) analiza la instruccin de SQL, detennina la mejor manera de ejecutarla y guarda en la base de datos el plan de aplicacin de esa instruccin como parte del proceso de desarrollo del programa. Cuando la instruccin de SQL esttico se ejecuta en el momento de la ejecucin, el SOBD simplemente ejecuta el plan de aplicacin almacenado. En SQL dinmico, la situacin es bastante diferente. La instruccin de SQL que hay que ejecutar no se conoce hasta el momento de la ejecucin, por lo que el SGBD no puede prepararse con antelacin para esa instruccin. Cuando se ejecuta realmente el programa, el SGBD recibe el texto de la instruccin que hay que ejecutar de manera dinmica (denominada cadena de caracteres de la instruccin) y recorre las cinco etapas que pueden verse en la Figura 18.1 en el momento de la ejecucin.
o;
exec sql declare cursor cursor? for select from :que_tabla;
Aunque se pudieran utilizar las variables del anfitrin de esta manera (y no se puede), surgira inevitablemente otro problema. El nmero de columnas generado por la consulta de la segunda instruccin variara, en funcin de la tabla especificada por la variable del anfitrin. Para la tabla OFICINAS, el resultado de la consulta tendra seis columnas; para la tabla REPRESENTANTES, tendra nueve. Adems, los tipos de datos de las columnas seran diferentes para las dos tablas. Pero para escribir una instruccin FETCH para la consulta hace falta conocer con antelacin el nmero de columnas del resultado de la consulta y sus tipos de datos, ya que hay que especificar una variable del anfitrin que reciba cada columna:
exec sql fetch cursor? into :varl, :var2,
:var3;
Corno ilustra esta discusin, si el programa debe poder determinar en el momento de la ejecucin las instrucciones de SQL que utilizar, o las tablas y columnas a las que har referencia, SQL esttico resulta inadecuado para la tarea. SQL dinmico supra estas limitaciones.
540
Captulo 18: SOL dinmico.
541
Instruccin de Sal
5ELECT A. B, e FROM x, y WHERE A < SOOO ANO e "" 'ABe'
-----rSOL esttico PrecompiJador
SQl dinmico
~
Anlisis de la
instrucci~
!
,-Validacin de la instruccin
~
(OPtimizacin de la instruccin
Generacin del plan
~
~
,
)
de aplicacin
Plan
!1 1
"::::0
e -e -o o --
-o -
..
~ ~
, o
-e o
Instruccin
PREPARE
E ::
Instruccin EXECUTE IMMEDIATE
intermedia) y la ejecucin de la lgica de las bases de datos en otro sistema (parle oculta)- ha aadido nueva importancia a las posibilidades surgidas con SQL dinmico. En la mayor parte de estos entornos de tres capas, la lgica de las aplicaciones que se ejecuta en la capa interme,dia es bastante dinmica. Debe modificarse con frecuencia para responder a nuevas condiciones de negocio y para implementar nuevas normativas de empresa. Este entorno de cambio frecuente choca con el acoplamiento estrecho de los programas de aplicaciones y del contenido de la base de datos que implica SQL esttico. En consecuencia, la mayor parte de las arquitecturas de tres capas utilizan una API de SQL a la que pueden hacer llamadas (que se describe en el Captulo 19) para enlazar la capa intermedia con las bases de datos de la parte oculta. Estas API toman prestados de manera explcita conceptos fundamentales de SQL dinmico (por ejemplo, las etapas independientes PREPARE y EXECUTE y la posibilidad EXECUTE IMMEDI ATE) para proporcionar acceso a las bases de datos. Una buena comprensin de los conceptos de SQL dinmico es, por tanto, importante para ayudar a los programadores a comprender lo que ocurre entre bastidores de la API de SQL. En las aplicaciones sensibles al rendimiento, esta comprensin puede significar la diferencia entre un diseo de la aplicacin que ofrezca buen rendimiento y buenos tiempos de respuesta y uno que no lo haga.
Forma binaria
de la instruccin de Sal
-.---Ejecucin
Ejecucin de instrucciones dinmicas

(EXECUTE IMMEDIATE)
!
(
TIempo de ejecucin
E13
'=.t
_o
-~
L_
t ____ ~ __ J _
Instruccin
EXECUTE
La modalidad ms sencilla de SQL dinmico la ofrece la instruccin EXECUTE IMMEDIATE, que puede verse en la Figura 18.2. Esta instruccin pasa el texto de una instruccin de SQL dinmico al SGBD y le pide que la ejecute de manera inmediata. Para utilizar esta instruccin el programa recorre las etapas siguientes:
Figura 18.1.
Procesamiento de las instrucciones de SOL por el SGBD.
1.
Como cabra esperar, SQL dinmico es menos eficiente que SQL esttico. Por este motivo, SQL esttico se utiliza siempre que es posible, y muchos programadores de aplicaciones no necesitan aprender nunca nada de SQL dinmico. Sin embargo, SQL dinmico ha aumentado su importancia a medida que el acceso a las bases de datos ha ido pasando a una arquitectura cliente/servidor, frontal/dorsal durante los ltimos diez aos. El acceso a las bases de datos desde el interior de aplicaciones de las computadoras personales como las hojas de clculo y los pro~ cesadores de texto se ha incrementado espectacularmente, y ha surgido un conjunto completo de herramientas del frontal de introduccin de datos y de acceso a los datos basadas en las computadoras personales. Todas estas aplicaciones necesitan las caractersticas de SQL dinmico. Ms recie~ltemente, la aparicin de las arquitecturas de tres capas basadas ~n Internet -con la ejecucin de la lgica de las aplicaciones en u~ sistema (capa
2. 3.
El programa crea una instruccin de SQL en forma de cadena de caracteres de texto en-una de las reas de datos (generalmente denominadas bferes). La instruccin puede ser cualquier instruccin de SQL que no recupere datos. El programa pasa la instruccin de SQL al SGBD con la instruccin EXECUTE IMMEDIATE.
El SGBD ejecuta la instruccin y define el valor de SQLCODE/SQLSTATE para indicar el estado de finalizacin, exactamente igual que si la instruccin se hubiera aplicado utilizando SQL esttico.
- - - - - - - - - EXECUTE IMMEDIATE variable-del-anfitrin
_.
Figura 18.2.
EXECUTE IMMEDIATE.
542
Captulo 18: SOL dinmico"
543
La Figura ]8.3 muestra un programa sencillo en e que sigue estas etapas. El programa pide al usuario el nombre de una tabla y una condicin de bsqueda de SQL. y crea el texto de una instruccin DELETE con base en las respuesta del usua-
:io. El p.rograma utiliza luego la instruccin EXECUTE IMMEDIATE para ejecutar la instruccin DELETE. Este programa no puede utilizar una instruccin DELETE est. tica de SQL incorporado, ya que no se conocen ni el nombre de la tabla ni la condicin de bsqueda hasta que el usuario los introduce en el momento de la ejecucin. Debe utilizar SQL dinmico. Si se ejecuta el programa de la Figura 18.3 con estos parmetros:
Introduzca el nombre de una tabla: personal Introduzca una condicin de bsqueda: cuota Eliminado de personal con xito. 20000
main ()
(
<
/*
Este programa elimina filas de la tabla especificada por el usuario segn una condicin de bsqueda especificada por el usuario.
el pr.ograma pasa al SOBD este texto para la instruccin:

delete from plantilla where cuota < 20000
exec sql include sqlca; exec sql begin declare seetion; char stmtbuf(301); exec sql end declare section; char nombretbl(lOlJ; char cond_busq[lOll;
/* Texto de SQL que se va a
ejecutar .. /
Si se ejecuta el programa con estos parmetros:

Introduzca el nombre de una tabla: pedidos Introduzca una condicin de bsqueda: cliente Eliminado de pedidos con xito 2105
1* nombre de tabla introducido por el usuario 'O/ /* condicin de bsqueda
introducida por el usuario 'O/

1* Comienza a crear la instruccin DELETE en scmtbuf */
el programa pasa al SOBD este texto para la instruccin:

delete froro pedidos where cliente = 2105
strcpy(strntbuf, "delete from ");

/* Pide al usuario el nombre de una tabla;
lo aaade al texto de ");
la instruccin DELETE */ printf I ~ Introduzca el nombre de una tabla: getslnombretbl); strcat(stmtbuf, nombretbl);
/* pide al usuario la condicin de bsqueda; la aade al texto */ printf("Introduzca la condicin de bsqueda:"); gets(cond_busq); if Istrlenlcond_busq) > O) { strcat I stmtbuf, - where -); strcat(stmtbuf, cond_busq);
Por tanto, la instruccin EXECUTE IMMEDIATE concede al programa gran flexibilidad en cuanto al tipo de instruccin DELETE que puede ejecutar. La instruccin EXECUTE IMMEDIATE utiliza exactamente una variable del anfitrin -la variable que contiene toda la cadena de caracteres de la instruccin de SQL-. La cadena de caracteres de la instruccin en s misma no puede incluir referencias a las variables del anfitrin, pero no hacen falta: En lugar de utilizar una instruccin de SQL esttico con una variable del anfitrin como sta:
exec sql delete from pedidos where cliente = :num_cli;
/* Ahora pide al SGBD que ejecute la instruccin */ exec sql execute immediate :stmtbuf; if (sqlca.sqlcode < O) printf(-SQL error; tld\n", sqlca.sqlcode); else printf("Eliminado de %5 con xito.\n", tblname);
el programa de SQL dinmico consigue el mismo efecto creando toda la instruccin en un bfer y ejecutndola:
sprintf(buffer, "delete from pedidos where cliente exec sql execute immediate :buffer;
exit ();
Figura
18.3.
Empleo de la instruccin EXECUTE IHHEDIATE.
La instruccin EXECUTE IMMEDIATE es la modalidad ms sencilla de SQL dinmico, pero resulta muy verstil. Se puede utilizar para ejecutar de manera dinmica la mayor parte de las instrucciones del LMD, incluidas INSERT, DELETE, UPDATE, COMMIT y RQLLBACK. Tambin se puede utilizar EXECUTE IMMEDIATE
544
545
para ejecutar de manera dinmica la mayor parte de las instrucciones del LDD, incluidas las instrucciones CREATE, DROP, GRANT y REVOKE. No obstante, la instruccin EXECUTE IMMEDIATE tiene una limitacin significativa. No se puede utilizar para ejecutar de manera dinmica instrucciones SELECT, ya que no proporcionan ningn mecanismo para procesar el resultado de la consulta. Al igual que SQL esttico necesita los cursores y las instrucciones de finalidad especial (DECLARE CURSOR, OPEN, FETCH Y CLOSE) para las consultas mediante programacin, SQL dinmico utiliza cursores y algunas instrucciones de propsito especial nuevas para manejar las consultas. Las caractersticas de SQL dinmico que admiten consultas dinmicas se estudian ms adelante en el apartado Consultas dinmicas.
4.
dor de parmetro. Se trata de la Etapa 2 de la interaccin con el SGBD. El SGBD sustituye el valor de los parmetros, ejecuta el plan de aplicacin generado previamente y define el valor de SQLCODE/SQLSTATE para indicar su estado de finalizacin. El programa puede utilizar repetidamente la instruccin EXECUTE, proporcionando valores diferentes de los parmetros cada vez que se ejecute la instruccin dinmica. El SGBD puede repetir simplemente la Etapa 2 de la interaccin, pues el trabajo de la Etapa I ya se ha concluido, y el resultado de ese trabajo (el plan de aplicacin para la ejecucin) seguir siendo vlido.
Ejecucin dinmica en dos pasos

La instruccin EXECUTE IMMEDIATE proporciona soporte en una etapa para la ejecucin dinmica de las instrucciones. Como ya se ha descrito, el SGBn recorre las cinco etapas de la Figura 18.1 para cada instruccin ejecutada de manera dinmica. La sobrecarga de este proceso puede resultar muy significativa si el programa ejecuta muchas instrucciones dinmicas, y resulta un derroche si las instrucciones que hay que ejecutar son idnticas o muy parecidas. En la prctica, la instruccin EXECUTE IMMEDIATE slo debe utilizarse para instrucciones nicas que se ejecuten una vez por programa y no vuelvan a ejecutarse nunca. Para disminuir la gran sobrecarga que supone el enfoque de etapa nica, SQL dinmico ofrece un mtodo alternativo de dos etapas para la ejecucin dinmica de instrucciones de SQL. En la prctica, este enfoque de dos etapas, que separa la preparacin de las instrucciones de su ejecucin, se utiliza para todas las instrucciones de SQL de los programas que se ejecutan ms de una vez y, especialmente, para aquellas que se ejecutan de manera repetida, centenares o millares de veces, en respuesta a la interaccin con el usuario. A continuacin puede verse una introduccin a la tcnica de dos etapas:
1.
La.Figura 1804 muestra un programa en C que utiliza estas etapas, que estn etiquetadas en la figura mediante llamadas. Se trata de un programa de actualizacin de tablas de finalidad generaL Pide al usuario el nombre de una tabla y el nombre de dos columnas, y crea una instruccin UPDATE para la tabla, que tiene el aspecto siguiente:
update nombre-tabla set nombre-segunda-columna = ? where nombre-primera-columna = ?
main{ 1
{
/* Programa de actualizacin de propsito general.
Puede utilizarse para cualquier actualizacin en que haya que actualizar todas las filas de una columna numrica en las que una segunda columna numrica tenga un valor determinado. Por ejemplo, se puede utilizar para actualizar las cuotas de los representantes que se desee o para actualizar el lmite de crdito de los clientes seleccionados.
/0
2.
3.
El programa crea la cadena de caracteres de una instruccin de SQL en un . bfer, igual que para la instruccin EXECUTE IMMEDIATE. Los signos de interrogacin (?) pueden sustituir a las constantes en cualquier parte del texto de la instruccin para indicar que el valor de la constante se proporcionar ms adelante. El signo de interrogacin se denomina indicador de parmetro. La instruccin PREPARE pide al SGBD que analice, valide y optimice la instruccin y que genere el plan de aplicacin correspondiente. Se trata de la Etapa 1 de la interaccin con el SGBD. El SGBD define el valor de SQLCODE/ SQLSTATE para indicar los errores hallados en la instruccin y retiene el plan de aplicacin para su ejecucin posterior. Obsrvese que el SGBD 110 ejecuta el plan en respuesta a la instruccin PREPARE. Cuando el programa desea ejecutar la instruccin preparada previamente, utiliza la instruccin EXECUTE y pasa al SGBD un valor por cada marca-
exec sql include sqlca; exec sql begin declare section; char stmtbuf[301] float valor_busca; float valor_nuevo; exec sql end declare section; char nombretbl(31J; char colbusca[3l};
/0 Texto de SQL que hay que ejecutar 0/ /+ valor del parmetro para la bsqueda 0/
/' valor del parmetro para la actualizacin ,/
/* tabla que hay que actualizar */ /+ nombre de la columna de bsqueda */
Figura 18.4.
Empleo de las instrucciones PREPA.RE y EXECUTE. (Contina.)
546
547
char colactualiza[31j;
char si_llo[31];
' nombre de la columna de actualizacin ' , respuesta s/no del usuario '
pide al usuario el nombre de la tabla y el nombre de las columnas * / printf("Introduzca el nombre de la tabla que se va a actualizar: "); gets(nombretbl}; printf("Introduzca el nombre de la columna en la que hay que
I~
buscar: gets(colbusca);
");
Por tanto, los datos que introduce el usuario determinan la tabla que se va- a actualizar, la columna que hay que actualizar y la condicin de bsqueda que hay que emplear. El valor de comparacin de la bsqueda y el valor actualizado de los datos se especifican como parmetros, que se proporcionan ms tarde cuando se ejecuta realmente la instruccin UPDATE. Tras crear el texto de la instruccin UPDATE en su bfer, el programa pide al SGBD que lo compile con la instruccin PREPARE. El programa enlra entonces en un bucle, en el que pide al usuario que introduzca pares de valores de los parmetros para llevar a cabo una serie de actualizaciones de la tabla. Este dilogo con el usuario muestra el modo en que se puede utilizar el programa de la Figura 18.4 para actualizar las cuotas de los representantes escogidos:
Introduzca el nombre de la tabla que se va a actualizar: personal Introduzca el nombre de la columna en la que hay que buscar: num_empl Introduzca el nombre de la columna que hay que actualizar: cuota Introduzca el valor de bsqueda para num_emp1: 106 Introduzca el nuevo valor de cuota: 150000.00 Otra (s/n)? s Introduzca el valor de bsqueda para num_empl: 102 Introduzca el nuevo valor de cuota: 225000.00 Otra (s/n)? s Introduzca el valor de bsqueda para num_emp1: 107 Introduzca el nuevo valor de cuota: 215000.00 Otra (s/n)? n Actualizaciones completadas.
printf("Introduzca el nombre de la columna que hay que actualizar: "); gets(colactualiza) ;

/* Crea en el bfer la instruccin de SQL; pide al SGBD que la compile */ sprintf{stmtbuf, "update %5 set %5 = ? where %5 = ? , ~-------~
nombretbl, colbusqueda,
colactualiza);
exec sql prepare rnystrnt fraro : stmtbuf; .. if (sqlca. sqlcode) { printf ("Error de PREPARE: %ld\n', sqlca. sqlcode) ;
exit ();
}
/* Itera la peticin al usuario de parmetros y la realizacin de las actualizaciones */ for ( ; ; ) ( printf{'\nlntroduzca el valor de bsqueda para %s: colbusca) : scanf("%f", &valor_busca); printf("Introduzca el nuevo valor de %s: colactualiza); scanf("%f", &valor_nuevo): /* Pide al SGSD que ejecute la instruccin UPDATE */ execute mystmt using :valor_busca, :valor_nuevo; ~.l------------~ if (sqlca.sqlcode) { printf("Error de EXECUTE: %ld\n", sqlca.sq1code), exit() ;
/*Pregunta al usuario si hay ms actualizaciones */ printf ("Otra (s/n)? "); +-------------{4 gets {si_no}; if (si_no[O] == 'n') break; printf("\nActualizaciones completadas.\n}; exit ();
Este programa es un buen ejemplo de una situacin en la que resulta adecuada la ejecucin dinmica en dos etapas. El SGBD compila la instruccin dinmica UPDATE slo una vez, pero la ejecuta tres veces, una por cada conjunto de valores de los parmetros introducido por el usuario. Si el programa se hubiera escrito empleando EXECUTE IMMEDIATE, la instruccin dinmica UPDATE se habra compilado tres veces y ejecutado otras tres. Por tanto, la ejecucin dinmica en dos etapas de PREPARE y EXECUTE ayuda a eliminar parte de la desventaja en rendimiento de SQL dinmico. Como ya se ha indicado, este mismo enfoque de dos etapas 10 utilizan todas las API de SQL a las que se puede hacer llamadas se describen en el Captulo 19.
La instruccin
PREPARE
Figura 18.4.
Empleo de las instruccione::. :::-:-.BPARE y EXECUTE. (Continuacin.)
La instruccin PREPARE, que puede verse en la Figura 18.5, es exclusiva de SQL dinmico. Acepta una variable del anfitrin que contiene la cadena de caracteres de una instruccin de SQL y pasa la instruccin al SGBD. El SGBD compila el texto de la instruccin y la prepara para la ejecucin mediante la generacin del plan de aplicacin. El SGBD define las variables SQLCODEI SQLSTATE para indi-
548
Capitulo 18: SOL d;nmco.
549
I
Figura 18.5.
PREPARE nombreinstruccin FROM variable-del-anfitrin
...
f-
EXECUTE nomb,einstrucC;n U S I N G n - Variab/..
~e/.anfitrin~
PREPARE.
L==-:o:=:J
Figura 18.6. Diagrama sintctico de la instruccin EXECUTE.
car los errores detectados en el texto de la instruccin. Como ya se ha descrito, la cadena de caracteres de la instruccin puede contener un marcador de parmetro. indicado por un signo de interrogacin, en cualquier lugar en que pueda aparecer una constante. El marcador de parmetro indica al SOBD que se proporcionar ms adelante, cuando la instruccin se ejecute realmente. Como consecuencia de la instruccin PREPARE, el SOBD asigna el nombre de instruccin especificado a la instruccin preparada. El nombre de instruccin es un identificador de SQL, como el nombre de los cursores. El nombre de instruccin se especifica en las instrucciones EXECUTE posteriores cuando se desea ejecutar la instruccin. Las marcas de SGBD se diferencian en el tiempo que conservan la instruccin preparada y el nombre de instruccin asociado. Para algunas marcas, la instruccin preparada slo puede volver a ejecutarse hasta el final de la transaccin actual (es decir, hasta la siguiente instruccin COMMIT o ROLLBACK). Si se desea ejecutar la misma instruccin dinmica ms adelante durante otra transaccin, hay que volver a prepararla. Otras marcas relajan esta restriccin y conservan la instruccin preparada a lo largo de la sesin en curso con el SGBD. El estndar SQL2 de ANSInSO reconoce estas diferencias e indica de manera explcita que la validez de la instrucci6n preparada fuera de la transaccin en curso depende de la implementaci6n. La instruccin PREPARE puede utilizarse para preparar casi cualquier instruccin ejecutable del LMD O del LDD, incluida la instruccin SELECT. Las instrucciones de SQL incorporado que son realmente directivas del precompilador (corno las instrucciones WHENEVER o DECLARE CURSOR) no pueden, obviamente, prepararse, ya que no son ejecutables.
rentes, que se describen en los dos aparrados siguientes. El estndar SQL2 de ANSI! ISO incluye los dos mtodos.
EXECUTE
con variables del anfitrin
La manera ms sencilla de pasar los valores de los parmetros a la instruccin EXECUTE es especificar una lista de variables del anfitrin en la clusula USING. La instruccin EXECUTE sustituye, por orden, el valor de las variables del anfitrin por los marcadores de parmetro del texto de la instruccin preparada. Las variables del anfitri6n sirven, por tanto, como variables de entrada del anfitrin para la instruccin del anfitrin ejecutada de manera dinmica. Esta tcnica se utiliz6 en el programa que puede verse en la Figura 18.4. Est admitida por todas las marcas populares de SGBD que incorporan SQL dinmico, y se incluye en el estndar SQL2 de ANSIIISO para SQL dinmico. El nmero de variables del anfitri6n de la clusula USING debe coincidir con el nmero de marcadores de par.me~o de la instruccln dinmica, y el tipo de datos de cada variable del anfitri6n debe ser compatible con el tipo de datos necesario para el parmetro correspondiente. Cada variable del anfitrin de la lista puede tener tambin una variable del anfitrin indicadora acompaante. Si la variable indicadora contiene un valor negativo cuando se procesa la instrucci6n EXECUTE, al marcador de parmetro correspondiente se le asigna el valor NULL.
RXECUTE
La instruccin
EXECU'l'E
con
SQLDA
La instruccin EXECUTE, que puede verse en la Figura 18.6, es exclusiva de SQL dinmico. Pide al SGBD que ejecute una instruccin preparada anteriormente con la instruccin PREPARE. Se puede ejecutar cualquier instruccin que pueda prepararse. con una sola excepci6n. Al igual que la instruccin EXECUTE IMMEorATE, la instruccin EXECUTE no puede utilizarse para ejecutar las instrucciones SELECT. ya que carece de un mecanismo para manejar el resultado de la consulta. Si la lnstruccin dinmica que hay que ejecutar contiene uno o varios marcadores de par~etro, la instrucci6n EXECUTE debe proporcionar un valor para cada uno de sus parmetros. Los valores pueden proporcionarse de dos maneras dife-
La segunda manera de pasar los parmetros a la instruccin EXECUTE es mediante una estructura dinmica de datos de SQL denominada rea de datos de SQL (SQL Data Area), o SQLDA. Hay que utilizar un SQLDA para pasar los parmetros cuando no se conoce el nmero de parmetros que hay que pasar ni sus tipos de datos en el momento de escribir el programa. Por ejemplo, supngase que se desea modificar el programa de actualizacin de finalidad general de la Figura 18.4 de modo que el usuario pueda seleccionar ms de una columna para actualizarla. Se puede modificar el programa con facilidad para generar una instruccin UPOATE con un nmero variable de asignaciones, pero la lista de variables del anfitrin de Ja instru~cin EX~CUTE p]antea un problema; debe sustituirse por una lista de longitud variable. El SQLDA proporciona una manera de especificar una lista de parmetros de longitud variable de este tipo.
550
I I
551
La Figura 18.7 muestra la disposicin del SQLDA utilizada por las bases de datos de IBM, incluida DB2, que define el estndar de faclo para SQL dinmico. Casi todos los dems productos de SOBD utilizan tambin este formato de SQLDA de IBM, o uno muy parecido. El estndar SQL2 de ANSI/ISO proporciona una estructura parecida, denominada rea de descriptores de SQL. El tipo de informacin contenido en el rea de descriptores de SQL de ANSI/ISO y el SQLDA estilo DB2 son iguales, y ambas estructuras desempean el mismo papel en el procesamiento de SQL dinmico. No obstante, los detalles de empleo -el modo en el que las ubicaciones de los programas se asocian con los parmetros de las instrucciones de SQL, la manera en que la informacin se ubica y se recupera del rea de descriptores, etc.- son bastante diferentes. En la prctica, el SQLDA estilo DB2 es la ms importante, ya que el soporte de SQL dinmico apareci en la mayor parte de las principales marcas de SGBD, modeladas segn la implementacin de DB2, mucho antes de que se redactara el estndar SQL2. El SQLDA es una estructura de datos de tamao variable con dos partes diferenciadas: La parte fija se halla al comienzo del SQLDA. Sus campos identifican la estructura de datos como SQLDA y especifican el tamao de esa SQLDA concreta. La parte variable es un array de una o varias estructuras de datos SQLVAR. Cuando se utiliza un SQLDA para pasar parmetros a una instruccin EXECUTE, debe haber una estructura SQLVAR por cada parmetro.
Los campos de la estructura SQLVAR describen los datos que se pasan a la instruccin EXECUTE como valores de parmetros: El campo SQLTYPE contiene un cdigo de tipo de datos entero que especifica el tipo de datos del parmetro que se pasa. Por ejemplo, el cdigo del tipo de datos de DB2 es 500 para los enteros de dos bytes, 496 para los enteros de cuatro bytes y 448 para las cadenas de caracteres de longitud variables. El campo SQLLEN especifica la longitud de los datos que se pasan. Contiene un dos para los enteros de dos bytes y un cuatro para los enteros de cuatro bytes. Cuando se pasan cadenas de caracteres como parmetros, SQLLEN contiene el nmero de caracteres de la cadena. El campo SQLDATA es un puntero para el rea de datos desde el interior del programa que contiene el valor del parmetro. El SGBD utiliza este puntero para hallar el valor de los datos cuando ejecuta la instruccin de SQL dinmico. Los campos SQLTYPE Y SQLI:.EN indican al SGBD el tipo de datos al que se seala y su longitud. El campo SQLIND es un puntero a un entero de dos bytes que se utiliza como variable indicadora del parmetro. El SGBD comprueba la variable indicadora para determinar si se est pasando un valor NULL. Si no se utiliza ninguna variable indicadora para un parmetro concreto, el campo SQLIND debe definirse como cero. Los otros campos de las estructuras SQLVAR y SQLDA no se utilizan para pasar los valores de los parmetros a la instruccin EXECUTE. Se emplean cuando se utiliza un SQLDA para recuperar datos de la base de datos, como se describe ms adelante en el apartado Consultas dinmicas. La Figura 18.8 muestra un programa de SQL dinmico que utiliza un SQLDA para especificar los parmetros de entrada. El programa actualiza la tabla REPRESENTANTS, pero permite, al comienzo del mismo, que el usuario seleccione las columnas que hay que actualizar. Luego entra en un bucle, pide al usuario el nmero de un empleado y luego un valor nuevo para cada columna que haya que actualizar. Si el usuario escribe un asterisco (*) en respuesta a la nueva peticin de valores, el programa asigna a la columna correspondiente un valor NULL.
1
struct sqlda { unsigned char sqldaid(8); long sqldabc: short sqln; short sqld; struct sql var { short sqltype; short sqllen; unsigned char *sqldata; short *sqlind; struct_sqlname ( short length; unsigned char data(30); sqlname; sqlvar [1] ;
main( I
(
1- Este programa actualiza las columnas de la tabla
REPRESENTANTES indicadas por el usuario. Primero pide al usuario que seleccione las columnas que hay que actualizar y luego pide repetidamente el nmero de empleado de un representante y los valores nuevos de las columnas seleccionadas.
'{
Figura 18.7.
El rea de datos de SQL (SOL Data Area, SQLDA) de las bases de datos de 18M.
Figura 18.8.
Empleo de EXECUTE con un SQLDA. (Contina.)
552
553
'define COLCNT 6
/* seis columnas de la tabla
REPRESENTANTES
exec sql include sqlca: exec sql include sglda; exec sql begin declare section; char stmtbuf[2001]: exec sql end declare section;
*'
printf("Actualizar la columna %s (s/n)? -); gets(inbuf} ; i f (inbuf[O) :=:= 's') { columns[i] .selected = 's'; parmcnt +:= 1;
/*
Texto de SQL que hay que ejecutar */ /* Asigna una estructura SQLDA para pasar el valor de los parmetros */ parmda:= malloc(16:= (44 * parmcnt)) >lII strcpy(parmda -> sqldaid, "SQLDA "}; parmda->sqldabc:= (16:= (44 * parmcnt; parmda->sqln = parmcnt; /* Comienza a crear la instruccin UPDATE en el bfer de instrucciones */ strcpy(stmtbuf, "actualiza el conjunto de pedidos -J; /* Itera por las columnas, procesando las seleccionadas */ for (i := O; j := O; i++ i < COLCNT) { . 4 1 - - - - - - - - - - /* Salta las columnas no seleccionadas */ if (columns[i] .selected :== 'n') continue; /* Aftade una asignacin a la instruccin dinmica UPDATE */ if (parmcnt> O) strcat(stmtbuf," ") strcat(stmtbuf, columns[i] .nombre); strcat(stmtbuf, " = ?"); /* Asigna espacio para los datos y la variable indicadora,
y
char *malloc ()
struct { char pregunta[31];
/* pregunta sobre esta columna */ /* nombre de esta columna */ /* el cdigo de su tipo de datos */ /* longitud de su bfer *1 /* bandera "seleccionada" (sIn) */
char nombre(31); short codtipo; short longbuf; char seleccionada;
columns () '" {
Nombre~.
-NOMBRE", Oficina", OFICINA_REp, -Jefe", "JEFE", "Fecha_contrato",*FECHA_CONTRATO, Cuota", 'CUOTA-,
'Ventas',
struct sqlda *parmda;
'VENTAS',
449, 16, 497, 4, 497, 4, 449, 12, 481, 8, 8, 481,
'n , 'n' ,
CD
'n' , 'n' , 'n' ,

'n') ;
struct sqlvar *parmvar; int int int int char parmcnt; num_empl i;
j ;
,. ,.
,.
inbuf [101] ;
/* SQLDA para los valores de los parmetros SQLVAR para el valor actual de parm */ /* parmetro de recuento de ejecuciones nmero de empleado introducido por el usuario indice del array de columnas[] ndice del array sqlvar en sqlda . datos introducidos por el usuario .
.,
.,
,.
.,
.,
.,
/* rellena SQLVAR con informacin de esta columna */ parmvar := parmda -> sqlvar + j ; parrnvar -> sqltype := columns[i] .typecode; 4 parmvar -> sqllen := columns[i).buflen; 4 parmvar -> sqldata = malloc(columns[i] .longbuf); 4 parmvar -> sqlind = malloc920; 4 strcpy(parrnvar -> sqlname.data, columns(i] .prompt); j += 1;
~ ~
G)
}
/* pide al usuario que seleccione las columnas que hay que actuali.zar */ printf(-*** Programa de actualizacin de representantes ***\n\n"} ; parmcnt := 1; for (i := O; i < COLCNT i++) /* Pregunta sobre esta columna */ /* Rellena la ltima SQLVAR para el parmetro de la clusula WHERE */ strcat(stmbuf, where nurn_empl : ?"); parrnvar = parmda + parrncnt; parmvar->sqltype = 496; parmvar->sqllen := 4; parrnvar->sqldata : &empl_nurn; parmvar->sqlind : O;
Figura 18.8.
Empleo "de EXECUTE con un SQLDA. (Continuacin.)
Figura 18.8.
Empleode EXECUTE con un SQLDA. (Continuacin.)
554
555
parrnda->sqld = parrncnt><
/*
.-------------------------------(2)
break;
pide al SGSD que compile toda la instruccin UPDATE dinmica */
exec sql prepare updatestrnt fraro :stmtbuf; if {sqlca.sqlcode < Ol { printf("PREPARE error: %ld\n-, sqlca.sqlcodel; exit ( l ;
case 501: /* Convierte los datos introducidos en valores enteros de cuatro bytes */
sscanf(inbuf, -%ld", parmvar->sqldatal;
break;
/* Ahora itera, for ( ; ; ) ( /*
pidiendo los parmetros y haciendo UPDATEs */

/* Ejecuta la instruccin */ exec sql execute updatestmt using :parmda:< if (sqlca.sqlcode < O) { printf("Error de EXECUTE: %ld\n", sqlca.sqlcode); exit ():
pide al usuario el nmero de empleado del representante que hay que actualizar *1 printf{"\nlntroduzca el nmero de empleado del representante: '); scanf("%ld", &num_empl);
if (num_eropl == O) break;
.--------------(2)
/* Consigue nuevos valores para las columnas actualizadas */ for (j := O; j < (parmcnt-1); j++) { parmvar := parmda + j; printf("Introduzca el nuevo valor de %s: parmvar->sqlname.data) ; gets(inbuf):4 i f (inbuf[O] "'''' '*'} { /* si el usuario introduce hay que dar a la columna el valor NULL */ *(parmvar -> sqlind) := -1: continue;
/* Ya se ha acabado con las actualizaciones */ exec sq1 execute immediate "commit work"; if (sq1ca.sqlcode) printf("Error de COMMIT: %ld\n", sqlca.sq1code); e1se printf("\nSe han comprometido todas las actualizaciones.\n"); exit ();
else { /* En caso contrario, hay que definir el indicador para los valores que no son NULL */ *{parmvar -> sqlind) '" O: switch(parmvar -> sqItype) case 481: /* Convierte los datos introducidos a valores de coma flotante de ocho bytes */ sscanf(inbuf, "%If", parmvar -> sqldata); 8 break; case 449: /* Pasa los datos introducidos como cadenas de caracteres de longitud variable */ stccpy(parmvar -> sqldata, inbuf, str1en(inbuf)); parmvar -> sq11en := strlen(inbuf);
Figura 18.8.
Empleo de EXECUTE con un SQLDA. (Continuacin.)
Como el usuario puede seleccionar columnas diferentes cada vez que se ejecuta el programa, este programa utiliza un SQLDA para pasar el valor de los parmetros a la instruccin EXECUTE. El programa ilustra la tcnica general para el empleo de las SQLDA, indicada por las llamadas de la Fignra 18.8: 1. 2. 3. 4. 5. El programa asigna un SQLDA de tamao suficiente como para guardar la estructura SQLVAR para cada parmetro que se pasa. Define el campo SQLN para indicar el nmero de SQLVARS que pueden albergarse. Por cada parmetro que hay que pasar, el programa rellena una de las estructuras SQLVAR con informacin que describe ese parmetro. El programa determina el tipo de datos de los parmetros y ubica el cdigo correcto de tipo de datos en el campo SQLTYPE. El programa determina la longitud del parmetro y la ubica en el campo
BQLLEN.
Figura 18.8.
Empleo de EXECUTE con un SQLDA. (Continuacin.)
El programa asigna memoria para guardar el valor del parmetro y pone la direccin de la memoria asignada en el campo SQLDATA.
556
6.
557
dinmi-
7.
El programa asigna memoria para guardar el valor de una variable indicadora del parmetro y pone la direccin de esa variable indicadora en el campo SQLIND. El programa define el campo SQLO en el encabezado SQLDA para indicar el nmero de parmetros que se pasan. Esto indica al SGBD el nmero de estructuras SQLVAR dentro del SQLDA que contienen datos v-
nistra el primer conjunto de valores de los parmetros la instruccin ca pasa a ser:
UPDATE
update representantes set nombre = 'Sonia Javierre', oficina = 22, cuota = 175000.00 where num_empl = 106
8. 9.
lidos. El programa pide al usuario el valor de los datos y lo ubica en las reas de datos asignadas en las etapas 5 y 6. El programa utiliza una instruccin EXECUTE con la clusula USING DESCRIPTOR para pasar el valor de los parmetros mediante el SQLDA.
y con el segundo conjunto de valores de los parmetros se transforma en:

update representantes set nombre = 'Javier Sanchis', oficina where num_empl = 104
=
NULL, cuota = 275000.00
Obsrvese que este programa concreto copia la cadena de caracteres de peticin para cada valor del parmetro en la estructura SQLNAME. El programa slo hace esto por su propio inters; el SGBD ignora la estructura SQLNAME cuando se utiliza el SQLDA para pasar parmetros. A continuacin puede verse un ejemplo de dilogo con el programa de la Figura J8.8:
*** Programa de actualizacin de representantes
Este programa es algo complejo, pero resulta sencillo comparado con la verdadera utilidad de actualizacin de propsito general de la base de datos. Tambin ilustra todas las caractersticas de SQL dinmico necesarias para ejecutar de ma. nera dinmica las instrucciones con nmero variable de parmetros.
Consultas dinmicas
Las instrucciones EXECUTE IMMEDIATE, PREPARE Y EXECUTE, tal y como se han descrito hasta ahora, admiten la ejecucin dinmica de la mayor parte de las instrucciones de SQL. Sin embargo, no pueden admitir las consults dinmicas, ya que carecen de un mecanismo para la recuperacin del resultado de las consultas. Para admitir las consultas dinmicas, SQL combina las caractersticas de SQL di nrnico de las instrucciones PREPARE y EXECUTE con las ampliaciones de las instrucciones de procesamiento de consultas de SQL esttico, y aade una instruccin nueva. A continuacin puede verse una aproximacin a la fonna en que los programas llevan a cabo las consultas dinmicas:
1.
Actualizar Actualizar Actualizar Actualizar Actualizar Actualizar Introduzca Introduzca Introduzca Introduzca Introduzca Introduzca Introduzca Introduzca
la la la la la la el el el el el el el el
columna columna columna columna columna columna
Nombre (sIn)? 8 Oficina (sIn)? 8 Jefe (sIn)? n Fecha_contrato (sIn)? n Cuota (sIn)? s Ventas (sIn)? n
nmero de empleado del representante: 106 nuevo valor de Nombre: Sonia Javierre nuevo valor de Oficina: 22 nuevo valor de Cuota: 175000.00 nmero de empleado del representante: 10' nuevo valor de Nombre: Javier Sanchis nuevo valor de Oficina: * nuevo valor de Cuota: 275000.00
Introduzca el nmero de empleado del representante: O Se han comprometido todas las actualizaciones.
2.
De acuerdo con la respuesta del usuario a las preguntas iniciales, el programa genera esta instruccin UPDATE dinmica y la prepara: 3.
update representantes set nombre ~ ?, oficina where num_empl = ? ?, cuota = ?
4. La instruccin especifica cuatro parmetros, y el programa asigna un SQLDA de tamao suficiente para manejar cuatro estructuras SQLVAR. Cuando el usuario sumi-
Una versin dinmica de la instruccin DECLARE CURSOR declara un cur sor para la consulta. A diferencia de la instruccin esttica DECLARE CURSOR, que incluye una instruccin SELECT. la forma dinmica de la instruccin DECLARE CURSOR especifica el nombre de la instruccin asociada con la instruccin SELECT. El programa crea una instruccin SELECT vlida en un bfer, igual que si creara una instruccin UPDATE o DELETE dinmica. La instruccin SELECT puede contener marcadores de parmetro como los empleados en otras instrucciones de SQL dinmico. El programa utiliza la instruccin PREPARE para pasar la cadena de caracteres de la instruccin al SGBD. que analiza, valida y optimiza la instruccin y genera un plan de aplicacin. Esto es idntico al procesamiento de PREPARE utilizado para otras instrucciones de SQL dinmico. El programa utiliza la instruccin DESCRIBE para solicitar una descripcin del resultado de la consulta que genera la consulta. El SOBO devuelve una descripcin, columna por columna, del resultado de la consulta en
558
559
un rea de dalos de SQL (SQL Data Area, SQLDA) proporcionada por el programa, indicando al programa el nmero de columnas de resultados de la consulta que hay y el nombre. tipo de datos y longitud de cada columna. La instruccin DESCRIBE se utiliza exclusivamente para las consultas dinmicas.
consulta. Una vez completada la selecci6n del usuario. el programa ejecuta la consulta solicitada y muestra el resultado.
"/
5.
El programa utiliza las descripciones de las columnas del
SQLDA
para asignar
6.
7.
8.
un bloque de memoria con el fin de recibir cada columna de resultados de la consulta. El programa puede asignar tambin espacio para una variable indicadora de la columna. El programa ubica la direccin del rea de datos y la direccin de la variable indicadora en el SQLDA para indicar al SGBD el lugar al que debe llevar el resultado de la consulta. Una versin dinmica de la instruccin OPEN pide al SOBD que comience a ejecutar la consulta y pasa valores para los parmetros especificados en la instruccin SELECT dinmica. La instruccin QPEN coloca el cursor antes de la primera fila de los resultados de la consulta. Una versin dinmica de la instruccin FETCH desplaza el cursor hasta la primera fila de los resultados de la consulta y recupera los datos para las reas de datos y las variables indicadoras del programa. A diferencia de la instruccin FETCH esttica. que especifica una lista de variables del anfitrin para que reciban los datos. la instruccin FETCH dinmica utiliza el SQLDA para indicar al SGBD el lugar adonde debe llevar los datos. Las instrucciones FETCH posteriores transitan por los resultados de la consulta fila a fila, desplazando el cursor hasta la siguiente fila de resultados de la consulta y trasladando los datos a las reas de datos del programa. La instruccin CLOSE concluye el acceso a los resultados de la consulta y rompe la asociacin entre el cursor y los resultados de la consulta. Esta instruccin CLOSE es idntica a la instruccin CLOSE de SQL esttico; no hace falta ninguna ampliacin para las consultas dinmicas.
exec sql include sqlca; exec sql include sqlda; exec sql begin declare section; char stmtbuf[2001J; char tblconsul[32); char colconsul[32); exec sql end declare section;
/* texto de SQL que hay que ejecutar */ /* tabla especificada por el usuario */ /* columna especificada por el usuario */
/* Cursor para la consulta del catlogo del sistema que recupera los nombres de las columnas */ exec sql declare tblcurs cursor for select colname from system.syscolumns where tblname : :tblconsul and owner user; exec sql declare qrycurs cursor for querystmt;~4~------------~Q)
La programacin necesaria para llevar a cabo una consulta dinmica es ms amplia que la necesaria para cualquier otra instruccin de SQL incorporado. Sin embargo, la programacin suele resultar ms tediosa que compleja. La Figura 18.9 muestra un pequeo programa de consultas que utiliza SQL dinmico para recuperar y mostrar las columnas seleccionadas de una tabla especificada por el usuario. Las llamadas de la figura identifican las ocho etapas de la lista anterior.
/" Estructuras de datos del programa "/ cuentacol = O, /" nmero de columnas int escogidas "/ /" SQLDA asignada para la struct sqlda *qry_da; consulta "/ /" SQLVAR para la columna struct sqlvar *qry_var; actual "/ i; /" indice para el array SQLVAR int en SQLDA "/ inbuf [lOlJ; char /" datos introducidos por el usuario "/
/* Pregunta al usuario la tabla que se va a consultar */ printf("*** Programa para mini consultas ***\n\n" printf{"Introduzca el nombre de la tabla para la consulta: gets (querytbll ; /* Inicia la instrucci6n SELECT en el bfer */ strcpy(stmtbuf. select "); ..
");
main
{
{J
/* ste es un sencillo programa de consultas de finalidad general. pide al usuario el nombre de una tabla y luego le pregunta las columnas de la tabla que hay que incluir en la
/* Configura el procesamiento de los errores "/ exec sql whenever sqlerror goto handle_error; exec sql whenever not found gota no_mas_columnas;
/* Consulta el catlogo del sistema para obtener los nombres de
las columnas de la tabla */
Figura 18.9.
Recuperacin de datos con SQl dinmico. (Contina.)
Figura 18.9.
Recuperacin de datos con SQl dinmico. (Continuacin.)
560
561
exec sql apeo tblcurs;

for (;
/*
/* Itera imprimiendo los datos de cada columna de la fila *1 for (i == O; i < eolcount; i++) {
Obtiene el nombre de la siguiente columna y pregunta al usuario "/ exec sql fetch tblcurs into :colconsul; printf("Incluir columna %s (sIn)? ", colconsul); gets(inbuf); i f (inbuf{O] ='" 's') /* El usuario desea la columna; la aade a la lista de seleccin "/ iE (colcount++ > O) strcat (strntbuL ",; strcat(stmtbuf, colconsul);'"
Busca la SQLVAR de la columna; imprime la etiqueta de la columna */ qry_var = qry_da->sqlvar + i; printf(" Columna I %d (%5); i+l, qry_var->sqlname); Comprueba la variable indicadora en bsqueda de la indicacin de valores NULL */ if (*(qry_var -> sqlind) !: O) ( puts("jEs NULL!\n"); continue;
'*
'*
/* Obtenidos los datos reales; maneja cada tipo por separado */
no_mas_columnas. exec sql close tblcurs:

/* Finaliza la instruccin SELECT con una clusula FROM */
switch (qry_var -> sqltype) case 448: case 449: /* Datos VARCHAR - simplemente los muestra */ puts(qry_var -> sqldata); break; case 496: case 497: /* Datos enteros de cuatro bytes - los convierte y los muestra */ printf{-'ld", *({int *) (qry_var->sqldata); break; case 500: case 501: /* Datos enteros de dos bytes - los convierte y los muestra */ printf{"'d", *(short *) (qry_var->sqldata)); break; case 480: case 481: /* Datos de coma flotante - los convierte y los muestra */ printf("'lf", -{(double *) (qry_var->sqldat)); break:
strcat(stmtbuf, strcat(stmtbuf,
-from "); tblconsul):
/* Asigna SQLDA para la consulta dinmica */ query_da : (SQLDA *)malloc(sizeof(SQLDA) + colcount sizeof(SQLVAR)}; query_da->sqln : colcount; /- Prepara la consulta y pide al SGBD que la describa -/ exec sql prepare querystmt from :stmtbuf; : exec sql describe querystmt into qry_da; /* Itera por SQLVARs, asignando memoria para cada columna */ for (i ~ O; i < colcount; i++) ( qry_var : qry_da->sqlvar + i; qry_var->sqldat : malloc(qry_var->sqllen) 4 ~ qry_var->sqlind '" malloc{sizeof{short;
~
3 4
/* SQLDA est totalmente definida; lleva a cabo la consulta y recupera el resultado */ exec sql open qrycurs; 41 exec sql whenever not found goto no_mas_datos: for ( ) { /- Captura la fila de datos en los bferes */ exec sql fetch sqlcurs using descriptor qry_da4I printf-\n-);
(2)
no_mas_datos. printf(-\nFin de los datos.\n-);
Figura 18.9.
Recuperacin de datos con Sal dinmico. (Continuacin.)
Figura 18.9.
Recuperacin de datos con Sal dinmico. (Continuacin.)
562
Capitulo 18: SOL dinmico
563
for
/* Limpia el almacenamiento asignado */ (i =: O: i < colcount; i++) { qry_var =: qry_da->sqlvar + i;
free(qry_var->sqldata};
free (qry_var->sqlind)
}
free (qry_da); clase qrycurs; "~1-----------------------10
exit ();
cin de almacenamiento para los datos recuperados y para el SQLDA. El programa tambin debe clasificar los diferentes tipos de datos que puede devolver la consulta y manejar cada uno de ellos de manera correcta, teniendo en cuenta la posibilidad de que los datos devueltos sean NULL. Estas caractersticas del programa de ejemplo son tpicas de las aplicaciones de produccin que utilizan consultas dinmicas. Pese a su complejidad, la programacin no resulta muy difcil en lenguajes como C, C++, Pascal, PUlo Java. Los lenguajes como COBOL y FORTRAN, que carecen de la posibilidad de asignar almacenamiento de manera dinmica y de trabajar con estructuras de dalOs de longitud variable, no pueden utilizarse para el procesamiento de consultas dinmicas. Los apartados siguientes estudian la instruccin DESCRIBE y las versiones dinmicas de las instrucciones DECLARE CURSOR, OPEN Y FETCH.
Figura 18.9.
Recuperacin de datos con SQl dinmico. (Continuacin.)
La instruccin DESCRIBE
El programa de la figura comienza preguntando al usuario el nombre de la tabla y luego consulta el catlogo del sistema para descubrir el nombre de las columnas de esa tabla. Pide al usuario que seleccione las columnas que hay que recu-. perar y crea una instruccin SELECT dinmica con base en las respuestas del usuario. La construccin mecnica paso a paso de una lista de seleccin en este ejemplo es muy tpica de los programas del frontal de las bases de datos que generan SQL dinmico. En las aplicaciones reales, la lista de seleccin generada podra incluir expresiones o funciones agregadas, y pudiera haber lgica adicional del programa para generar las clusulas GRQUP BY, HAVING y ORDER BY. Tambin se utilizara una interfaz grfica de usuario en lugar de las primitivas peticiones al usuario del programa de ejemplo. No obstante, las etapas y los conceptos de programacin siguen siendo los mismos. Obsrvese que la instruccin SELECT generada es idntica a la instruccin SELECT interactiva que se utilizara para llevar a cabo la consulta solicitada. El manejo de las instrucciones PREPARE y DESCRIBE Y el mtodo de asignacin de almacenamiento para los datos recuperados en este programa son tambin tpicos de los programas de consultas dinmicas. Obsrvese el modo en que el programa utiliza las descripciones de las columnas ubicadas en el array SQLVAR para asignar un bloque de almacenamiento de datos del tamao adecuado para cada columna. Este programa asigna tambin espacio para una variable indicadora para cada columna. El programa vuelve a colocar la direccin del bloque de datos y de la variable indicadora en la estructura SQLVAR. Las instrucciones OPEN, FETCH Y CLaSE desempean el mismo papel para las consultas dinmicas que para las estticas, como ilustra este programa. Obsrvese que la instruccin FETCH especifica el SQLDA en lugar de una lista de variables del anfitrin. Como el programa ha rellenado previamente los campos SQLDATA y SQLIND del array SQLVAR, el SGBD conoce el lugar donde debe ubicar cada columna de datos recuperada. Como muestra este ejemplo, gran parte de la programacin necesaria para las consultas dinmicas est relacionada con la configuracin del SQLDA y la asignaLa instruccin DESCR-IBE, que puede verse en la Figura 18.10, es exclusiva de las consultas dinmicas. Se emplea para solicitar al SGBD una descripcin de la consulta dinmica. La instruccin DESCRIBE se utiliza una vez compilada la consulta dinmica con la instrucci6n PREPARE, pero antes de ejecutarla con la instruccin OPEN. La consulta que se va a describir se identifica mediante su nombre de instruccin. El SGBD devuelve la descripcin de la consulta en un SQLDA proporcionada por el programa. El SQLDA es una estructura de longitud variable con un array de una o varias estructuras SQLVAR. corno ya se describi en el apartado EXECUTE con SQLDA, y se ha mostrado en la Figura 18.7. Antes de pasar el SQLDA a la instruccin DESCRIBE, el programa debe rellenar el campo SQLN del encabezado del SQLDA. que indica al SGBD el tamao del array SQLVAR en esta SQLDA concreta. Como primera etapa del procesamiento de DESCRIBE, el SGBD rellena el campo SQLD del encabezado del SQLDA con el nmero de columnas del resultado dela consulta. Si el tamao del array SQLVAR (tal y como se ha especificado en el campo SQLN) es demasiado pequeo para guardar todas las descripciones de las columnas, el SGBD no rellena el resto del SQLDA. En caso contrario. el SGBD rellena una estructura SQLVAR por cada columna del resultado de la consulta, de izquierda a derecha. Los campos de cada SQLVAR describen la columna correspondiente: La estructura SQLNAME especifica el nombre de la columna (con el nombre en el campo DATA y la longitud del nombre en el campo LENGTH). Si
------DESCRIBE
nombre-instruccin
INTO
nombredescriptor------i.....
Figura 18.10.
DESCRIBE.
564
565
la columna se obtiene a partir de una expresin, no se utiliza el campo

SQLNAME.
El campo SQLTYPE especifica un cdigo de tipo de datos entero para la co lumna. Los cdigos de tipos de datos utilizados por las diferentes marcas de SGBD varan. Para los productos de SQL de IBM el cdigo de tipo de datos indica tanto el tipo de datos como si se permiten los valores NULL. como puede verse en la Tabla 18.1. El campo SQLLEN especifica la longitud de la columna. Para los tipos de datos de longitud variable (como VARCHAR), la longitud comunicada es la longitud mxima de los datos; la longitud de las columnas en cada fila del resultado de la consulta no supera esta longitud. Para DB2 (y para otros muchos productos de SQL), la longitud devuelta para el tipo de datos DECIMAL especifica tanto el tamao del nmero decimal (en su byte superior) como la escala del nmero (en su byte inferior). Los campos SQLDATA Y SQLINO no los rellena el SGBD. El programa de aplicacin rellena estos campos con las direcciones del bfer de datos y de la variable indicadora de la columna antes de utilizar el SQLDA ms adelante en una instruccin FETCH.
Umi complicacin del empleo de la instruccin DESCRIBE es que el programa n~ puede conocer con antelacin el nmero de columnas de resultados de la consulta que se producir y. por tanto, no puede saber el tamao de SQLDA que debe asignarse para recibir la descripcin. Nonnalmente se utiliza una de estas tres estrategias para asegurarse de que el SQLDA tiene espacio suficiente para las descripciones obtenidas.
Si el programa ha generado la lista de seleccin de la consulta, puede hacer un recuento de los elementos seleccionados a medida que se van generando. En este caso, el programa puede asignar un SQLDA con el nmero exacto de estructuras SQLVAR para recibir las descripciones de las columnas. Este enfoque se utiliz en el programa que puede verse en la Figura 18.9. Si no resulta conveniente que el programa cuente el nmero de elementos de la lisLa de seleccin, puede aplicar DESCRIBE al principio a la consulta dinmica en un SQLDA mnima con un array SQLVAR de un solo elemento. Cuando la instruccin DESCRIBE vuelve, el valor SQLD indica al programa el tamao que debe tener el SQLDA. El programa puede asignar entonces un SQLDA del tamao correcto y volver a ejecutar la instruccin DESCRIBE, especificando la nueva SQLDA. No hay ningn lmite en cuanto al nmero de veces que se puede describir una instruccin preparada. De manera alternativa, el programa puede asignar un SQLDA con un array SQLVAR lo bastante grande como para albergar una consulLa tpica. Una instruccin DESCRIBE que emplee esta SQLDA tendr xito la mayor parte de las veces. Si el SQLDA resulta demasiado pequea para la consulta, el valor SQLD indica al programa el tamao que debe tener el SQLDA, y puede asignar una mayor y volver a aplicar la instruccin DESCRIBE a la instruccin en esa
SQLDA.
Tabla 18.1.
Cdigos de tipos de datos I f SQLDA para DB2 NtrLL
fFipo de datos
CHAR VAR0HAR LONG VARCHAR SMALLINT INTEGER FLOAT DECIMAL DATE TIME TIMESTAMP GRAPHIC VARGRAPHIC
permitido
50'1' NtJLL
452 448 456 500 496 480 484 384 388 392 468 464
453 449 457 501 497 481 485 385 389 393 469 465
La instruccin DESCRIBE suele emplearse para las consultas dinmicas, pero puede solicitar al SGBD que aplique DESCRIBE a cualquier instruccin preparada previamente. Esta caracterstica resulta til, por ejemplo, si un programa necesita procesar una instruccin de SQL desconocida escrita por el usuario. El programa puede aplicar PREPARE y DESCRIBE a la instruccin y examinar el campo SQLO del SQLDA. Si el campo SQLD es cero, el texto de la instruccin no era una consulta y se puede utilizar la instruccin EXECUTE para ejecutarla. Si el campo SQLD es positivo, el texto de la instruccin era una consulta, y la secuencia de instrucciones OPEN!FETCH!CLOSE debe utilizarse para ejecutarla.
La instruccin
DECLARE CURSOR
La instruccin dinmica
DECLARE CURSOR, que puede verse en la Figura 18.11, es una variacin de la instruccin esttica DECLARE CURSOR. Recurdese del Captulo 17 que la instruccin esttica DECLARE CURSOR especificaba literalmente una consulta al incluir la instruccin SELECT como una de las clusulas. Por el contra-
1------- DECLARE nombre-cursor CURSOR

Figura 18.11.
FOR nombre-instruccin
11
Diagrama sintctico de la instruccin dinmica DECLARE CURSOR.
566
567
rio la instruccin dinmica DECLARE CURSOR especifica la consulta de manera indirecta, especificando el nombre de la instruccin asociada con la consulta por la instruccin PREPARE. Al igual que la instruccin esttica DECLARE CURSOR, la instruccin dinmica DECLARE CURSOR es una directiva para el precompilador de SQL, ms que una instruccin ejecutable. Debe aparecer antes de cualquier otca referencia al cursor que la declare. El nombre del cursor declar~do por esta instrucci~ se utiliza en las instrucciones DPEN, FETCH Y CLOSE posteriores para el procesamiento del resultado de la consulta dinmica.
OPEN
se puede especificar una variable indicadora para cada variable del anfitrin, si se considera necesario. La Figura 18.13 muestra el fragmento de un programa en el que la consulta dinmica tiene tres parmetros cuyos valores se especifican mediante variables del anfitrin. Si el nmero de parmetros no se conoce hasta el momento de la ejecucin, el programa debe pasar el valor de los parmetros mediante una estructura SQLDA. Esta tcnica de pase del valor de los parmetros ya se describi para la instruccin EXECUTE en el apartado EXECUTE con SQLDA. Se emplea la misma tcnica para la instruccin OPEN. La Figura 18.14 muestra el fragmento de un programa como el de la Figura 18.13, salvo que utiliza un SQLDA para pasar los parmetros. Obsrvese detenidamente que el SQLDA utilizada en la instruccin OPEN no tiene absolutamente nada que ver con el SQLDA utilizada en las instrucciones DESCRIBE Y FETCH: El SQLDA de la instruccin OPEN se utiliza para pasar el valor de los parmetros al SGBD para la ejecucin de la consulta dinmica. Los elementos de su
La instruccin dinmica OPEN, que puede verse en la Figura 18.12, es una variacin de la instruccin esttica PEN. Hace que el SGBD comience a ejecutar una consulta y coloca el cursor asociado justo antes de la primera fila de los resultados de la consulta. Cuando la instruccin OPEN se completa con xito, el cursor se halla en un estado abierto y est listo para que lo emplee la instruccin FETCH. El papel de la instruccin OPEN para las consultas dinmicas recuerda el papel de la instruccin EXECUTE para otras instrucciones de SQL dinmico. Tanto la instruccin EXECUTE como la instruccin OPEN hacen que el SGBD ejecute una instruccin compilada previamente por la instruccin PREPARE. Si el texto de la consulta dinmica incluye uno o varios marcadores de parmetro, la instruccin OPEN, al igual que la instruccin EXECUTE, debe proporcionar el valor de esos parmetros. La clusula USING se emplea para especificar el valor de los parmetros, y tiene un fonnato idntico tanto en la instruccin EXECUTE como en la instruccin OPEN. Si el nmero de parmetros que van a aparecer en la co~sulta dinmica se conoce con antelacin, el programa puede pasar el valor de los parmetros al SGBD mediante una lista d variables del anfitrin en la clusula USING de la instruccin OPEN. Como en la instruccin EXECUTE, el nmero de variables del anfitrin debe coincidir con el nmero de parmetros, el tipo de datos de cada variable del anfitrin debe ser compatible con el tipo exigido por el parmetro correspondiente, y
/* El programa ha generado y preparado previamente una instruccin
SELECT como la siguiente: SELECT A, 8, C ... FROM REPRESENTANTES WHERE VENTAS BETWEEN ? AND ?
,;
/*
con dos parmetros por especificar
pide al usuario los valores mximo y mnimo y lleva a cabo la consulta */ printf("Introduzca el valor mnimo del rango de ventas; "); scanf ( "% f", &valor_minimo); printf (~Introduzca el valor mximo del rango de ventas; "); scanf ("%f", &valor_maximo);
/* Abre el cursor para iniciar la consulta, pasando parmetros */ exec sql open qrycursor using :valor_minimo, :valor_maximo;
~ OPEN
nombre-cursor _ ,
USING ~~/-anfitrin
~_. . .
L
Figura 18.12.
=:::nombre-deSCriPtor
Figura 18.13.
Diagrama sintctico de la instruccin dinmica OPEN.
Instruccin OPEN con pase de parmetros mediante variables del anfitrin.
, ,
L
568
569
elementos de su array SQLVAR se corresponden con las columnas de los resultados de la consulta generados por la consulta dinmica.
El programa ha generado y preparado previamente una instruccin SELECT como la siguiente: SELECT A, B, e FRQM REPRESENTANTES WHERE NUM EMPL IN ( ? , ?
/*
FETCH
...?)
Con un nmero variable de parmetros por especificar. El nmero de parmetros para esta ejecucin se almacena en la variable parmcnt.
*mal1oc () char *parrnda; SQLDA SQLVAR *parmvar; long valor_param[lOl);

/* Asigna un SQLDA para pasar el valor de los parmetros */ parmda = (SQLDA *)malloc(sizeof(SQLDA) + parmcnt * sizeof(SQLVAR)); parmda->sqln = parmcnt; /*pide al usuario el valor de los parmetros */ tor (i = O; i < parmcnt; i++) { printf (" Introduzca el nmero de empleado: '}; scanf("%ld", &(valor-param[i])); parmvar = parmda -> sglvar + i; parmvar->sqltype = 496; parmvar->sqllen = 4; parmvar->sqldata = &(valor_param[i}); parmvar->sglind = O;
La instruccin dinmica FETCH, que puede verse en la Figura 18.15, es una variaci6n de la instruccin esttica FETCH. Desplaza el cursor hasta la siguiente fila disponible de resultados de la consulta y recupera el valor de sus columnas para las reas de datos del programa. Recurdese del Captulo 17 que la instruccin esttica FETCH incluye una clusula INTQ con una lista de variables del anfitrin que reciben los valores de las columnas recuperadas. En la instruccin dinmica FETCH la lista de variables del anfitrin se sustituye por un SQLDA . Antes de utilizar la instruccin dinmica FETCH, es responsabilidad del programa de aplicacin proporcionar las reas de datos para recibir los datosy la variable indicadora recuperados para cada columna. El programa de aplicacin tambin debe rellenar los campos SQLDATA, SQLIND y SQLLEN de la estructura SQLVAR para cada columna, de la manera siguiente:
El campo SQLDATA debe apuntar al rea de datos de los datos recuperados. El campo SQLLEN debe especificar la longitud del rea de datos a la que apunta el campo SQLDATA. Este valor debe especificarse correctamente para asegurarse de que el SGBD no copia los datos recuperados ms all del final del rea de datos. El campo SQLIND debe apuntar a llna variable indicadora para la columna (un entero de dos bytes). Si no se utiliza ninguna variable indicadora para una columna concreta, el campo SQLIND para la estructura SQLVAR correspondiente debe definirse como cero. Normalmente, el programa de aplicacin asigna un SQLDA, utiliza la instruccin DESCRIBE para obtener una descripcin de los resultados de la consulta, asigna almacenamiento para cada columna de resultados de la consulta y define el valor de SQLDATA y de SQLIND, todo ello antes de abrir el cursor. Esta misma SQLDA se pasa a la instruccin FETCH. No obstante, no se exige que se utilice la misma SQLDA ni que el SQLDA especifique las mismas reas de datos para cada instruccin FETCH. Resulta perfectamente aceptable que el programa de aplicacin cambie los punteros SQLDATA y SQLIND entre instrucciones FETCH, recuperando dos filas sucesivas en ubicaciones diferentes.
/* Abre el cursor para iniciar la consulta, pasando los parmetros */ exec sql apeo qrycursor using descriptor :parmda;
Figura 18.14.
Instruccin OPEN con SQLDA pase de parmetros.
array SQLVAR se corresponden con los marcadores de parmetro del texto de la instruccin dinmica. El SQLDA de las instrucciones DESCRIBE y FETCH recibe las descripciones de las columnas de los resultados de la consulta del SGBD e indica al SGBD el lugar donde deben ubicarse los resultados de la consulta recuperados. Los
!------FETCH nombre-cursorUSING DESCRIPTOR nombre-descriptor
.~.
Figura 18.15.
Diagrama sintctico de la instruccin dinmica FETCH.
570
Captulo 18: SaL dinmico.
571
La instruccin dinmica CLOSE

La forma dinmica de la instruccin CLOSE es idntica en sintaxis y funciones a la instruccin esttica CLOSE que puede verse en la Figura 17.25. En ambos casos, la instruccin CLOSE finaliza el acceso a los resultados de la consulta. Cuando un programa cierra un cursor para una consulta dinmica, el programa suele desasignar tambin los recursos asociados con la consulta dinmica, incluidos:
L~ d~scripci6n detallada de las caractersticas de SQL dinmico admitido por las pnnclpales ~arcas d.e SGBD. se halla ms all del mbito de este libro. No obstante, resulta InstructIvo exam~nar el soporte de SQL dinmico proporcionado por SQUDS y por Gracle como ejemplo del tipo de diferencias y ampliaciones de SQL dinmico que pueden hallarse en cada SGBD concreto.
SOL dinmico en Oracle
El
asignada para la consulta dinmica y utilizada en las instrucciones DESCRIBE y FETCH. Una segunda SQLDA posible, utilizada para pasar el valor de los parmetros a la instruccin PEN. Las reas de datos asignadas para recibir cada columna de resultados de la consulta recuperados por una instruccin FETCH. Las reas de datos asignadas como variables indicadoras para las columnas de resultados de las columnas.
SQLDA
Puede que no sea necesario desasignar estas reas de datos si el programa termina inmediatamente despus de la instruccin CLOSE.
El SOBD de Oracle precedi a DB2 en el mercado y bas su soporte de SQL dinmico en el prototipo de IBM SystemIR. Por este motivo, el soporte de Oracle de SQL dinmico se diferencia algo del proporcionado por el estndar SQL de IBM. Aunque Oracle y DB2 son ampliamente compatibles, se diferencian sustancialmente en los detalles. Estas diferencias incluyen el empleo por Gracle de los marcadores de parmetro, su empleo del SQLDA, el formato de su SQLDA y su soporte de la conversin entre tipos de datos. Las diferencias de Orade con DB2 son parecidas a las que pueden hallarse en otras marcas de SGBD. Por ese motivo resulta instructivo examinar brevemente el sopone de Oracle de SQL dinmico y los puntos de diferencia con DB2.
Parmetros con nombre
Dialectos de SOL dinmico

Al igual que las dems panes del lenguaje SQL, SQL dinmico vara de una marca de SGBD a otra. De hecho, las diferencias en el soporte de SQL dinmico son ms importantes que para SQL esttico, ya que SQL dinmico deja al descubierto una parte mayor de los entresijos del SGBD subyacente -los tipos de datos, los formatos de datos, etc.-. En la prctica, estas diferencias hacen imposible escribir una nica parte visible de propsito general de la base de datos que sea ponable de unas marcas de SGBD a otras empleando SQL dinmico. En lugar de eso, los programas del frontal de la base de datos deben incluir una capa de traduccin. a menudo denominada controlador. para cada marca de SGBD con que cuentan para adaptarse a las diferencias. Los primeros productos del frontal solan distribuirse con un controlador diferente para cada marca popular de SOBD. La introduccin de ODRe como capa API uniforme de SQL facilit esta tarea, ya que se poda escribir una sola vez un controlador ODBC para cada marca de SOBD, y el frontal poda escribirse para que utilizara nicamente la interfaz ODBe. En la prctica, no obstante, el enfoque de mnimo comn denominador de ODBe significaba que los programas del frontal no podan aprovechar las posibilidades exclusivas de los diferentes sistemas de SGBD admitidos, lo que limitaba el rendimiento de la aplicacin. En consecuencia, los programas y herramientas del frontal ms modernos siguen incluyendo un controlador diferente, explcito, para cada una de las marcas populares de SGBD. Se suele incl1,lir un controlador ODBe para proporcionar el acceso a las dems marcas.
Recurdese que DB2 no permite referencias a las variables del anfitrin en las instrucciones preparadas de manera dinmica. En vez de eso, los parmetros de la instruccin se identifican mediante signos de interrogacin (marcadores de parmetro) y el valor de esos parmetros se especifica en las instrucciones EXEeUTE u OPEN. Gracle permite especificar los parmetros en las instrucciones preparadas de manera dinmica empleando la sintaxis para las variables del anfitrin. Por ejemplo, esta secuencia de instrucciones de SQL incorporado es legal para Gracle:
exec sql begin declare section;
char
int
strntbuf(lOOl);
numero_empleado; exec sql end declare seetion;
"delete fram representantes where num_empl ~ :numero_rep;-); exec sql prepare delstmt from :stmtbuf; exec sql execute delstmt using : numero_empleado;
strcpy (strntbuf,
Aunque parece que numero_rep es una variable del anfitrin en la instruccin dinmica DELETE, en realidad es un parmetro con nombre. Como puede verse en el ejemplo, el parmetro con nombre se comporta exactamente. igual que los marcadores de parmetro de DB2. El valor del parmetro se obtiene de una variable real del anfitrin de la instruccin EXECUTE. Los parmetros con nombre suponen
572
573
una verdadera comodidad cuando se utilizan instrucciones dinmicas con un nmero variable de parmetros.
La instruccin DESCRIBE
struct sqlda { int N; char *"V; int short short int char short short char *L; *T; **1; F;
_"S;
/* puntero al datos */ /* puntero al /* puntero al /* puntero al
/ .. nmero de entradas de las arrays del SQLDA */ array de punteros para las reas de array de longitudes de los bferes */ array de cdigos de tipos de datos */ array de punteros para las variables
La instruccin de Orade DESCRIBE se utiliza, al igual que la instruccin DESCRIBE de DB2, para describir los resultados de la consulta de una consulta dinmica. Al igual que DB2, Gracle enva las descripciones a un SQLDA. La instruccin D;ESCRIBE de Grade tambin puede utilizarse para solicitar una descripcin de los parmetros con nombre en instrucciones preparadas de manera dinmica. Oraele tambin devuelve estas descripciones de los parmetros en un SQLDA. Esta instruccin DESCRIBE de Oracle solicita una descripcin de las columnas de resultados de la consulta a partir de consultas dinmicas preparadas previamente:
exec sql describe select list for qrystrnt into qry_sqlda;
"M;
C;
Se corresponde con la instrucci6n de DB2:

short exec sql describe qrystrnt into qry_sqlda; short
-*x;
*y;
"Z;
Esta instruccin DESCRIBE de OracJe solicita una descripcin de los parme tras con nombre de instrucciones dinmicas preparadas previamente. Las instrucciones pueden ser consultas u otras instrucciones de SQL:
exec sql describe bind list for thestmt into the_sqlda
indicadoras */ /- nmero de entradas activas en los arrays de SQLDA */ /- puntero al array de punteros para los nombres de columnas/parmetros */ /* puntero al array de longitudes de los nombres de los bferes */ /" puntero al array de longitudes actuales de los nombres */ /" puntero al array de punteros para los nombres de los parmetros -/ /" puntero al array de longitudes de los bferes de los nombres de los indicadores */ /0 puntero al array de longitudes actuales de los ~ nombres de los indicadores */
Figura 18.16.
SQLDA de Oracle.
Esta instruccin de Oracle no tiene equivalente en DB2. Con esta instruccin el programa normalmente examina la informacin del SQLDA, rellena los punteros del SQLDA para que apunten a los valores de los parmetros que el programa desea proporcionar y luego ejecuta la instruccin utilizando la forma SQLDA de las instrucciones OPEN o EXECUTE:
DESCRIBE,
El campo F del SQLDA de Oracle indica el nmero de columnas que se describen actualmente en los arrays del SQLDA. Se corresponde con el campo del SQLDA de DB2. En lugar del nico array de estructuras de SQLVAR de DB2 que contiene las descripciones de las columnas, el SQLDA de Oracle contiene punteros a una serie de arrays, cada uno de las cuales describe un aspecto de una columna: El campo T apunta a un array de enteros que especifica el tipo de datos de cada columna de resultados de la consulta o parmetro con nombre. Los enteros de este array se corresponden con el campo SQLTYPE de cada estructura SQLVAR de DB2. El campo v apunta a un array de punteros que especifica el bfer para cada columna de resultados de la consulta o cada valor de parmetro pasado. .Los punteros de este array se corresponden con el campo SQLDATA de cada estructura SQLVAR de DB2. El campo L apunta a un array de enteros que especifica la longitud de,cada bfer al que apunta el array v. Los enteros de este array se corresponden con el campo SQLLEN de cada estructura SQLVAR de DB2. El campo I apunta a un array de punteros de datos que especifica la variable indicadora para cada columna de resultados de la consulta o parmetro con
exec sql execute thestmt using descriptor the_sqlda; exec sql open qrycursor using descriptor the_sqlda;
La informacin devuelta por las dos formas de la instruccin Gracle es la misma, y se describe en el apartado siguiente.
SQLDA
DESCRIBE
de
de Oracle
El SQLDA de Oracle lleva a cabo las mismas funciones que el SQLDA de DB2, pero su formato, que puede verse en la Figura 18.16. se diferencia notablemente del de DB2. Los dos campos importantes del encabezado del SQLDA de DB2 tienen sus contrapartidas en el SQLDA de Oracle:
!I El campo
N del SQLDA de Oracle especifica el tamao de los arrays utilizados para guardar las definiciones de las columnas. Se corresponde con el campo SQLN del SQLDA de DB2.
574
Capitulo 78: SQL dinmico*
575
nombre. Los punteros de este array se corresponden con el campo SQLIND de cada estructura SQLVAR de DB2. El campo s apunta a un array de punteros de cadenas de caracteres que especifica los bferes a los que Oracle debe devolver el nombre de cada columna de resultados de la consulta o parmetro con nombre. Los bferes a los que apunta este array se corresponden con la estructura SQLNAME de cada estructura SQLVAR de DB2. El campo M apunta a un array de enteros que especifican el tamao de cada bfee al que apunta el array s. Para DB2, la estructura SQLNAME tiene un bfee de longitud fija, por lo que no hay equivalente al campo M. El campo e apunta a un array de enteros que especifican las longitudes reales de los nombres a los que apunta el array S. Cuando Gracle devuelve el nombre de las columnas o de los parmetros define los enteros de este array para que indiquen sus longitudes reales. Para DB2 la estructura SQLNAME tiene un bfer de longitud fija, por lo que no hay equivalente al campo c. El campo x apunta a un array de punteros de cadenas de caracteres que especifica los bferes en los que Gracle debe devolver el nombre de cada parmetro indicador con nombre. Estos bferes slo los utiliza la instruccin de Grac1e DESCRIBE BLIND LIST; no tienen ningn equivalente en DB2. El campo y apunta a un array de enteros que especifican el tamao de cada bfer al que apunta el array x. No hay ningn equivalente en DB2. El campo z apunta a un array de enteros que especifican las longitudes reales de los nombres de los parmetros indicadores a los que apunta el array x. Cuando Gracle devuelve el nombre de los parmetros indicadores, define los enteros de este'array para indicar sus longitudes reales. No hay ningn equivalente en DB2.
La caracterstica de conversin de tipos de datos del SOLDA de Orac1e proporciona una excelente portabilidad, tanto entre diferentes sistemas informticos como entre diferentes lenguajes de programacin. Otras marcas de SGBn poseen una caracterstica parecida, pero entre ellas no estn los productos de SQL de lBM.
SOL dinmico y el estndar SOL2

El estndar SQLl no abordaba SQL dinmico, por 10 que el estndar de facto para el SQL, tal y como se describe en los apartados anteriores, lo defini la implementacin de IBM en DB2. El estndar SQL2 inclua de manera explcita un estndar para SQL dinmico, especificado en un captulo aparte del estndar que tiene casi cincuenta pginas. En las reas ms sencillas de SQL dinmico el nuevo estndar SQL2 sigue estrechamente SQL dinmico utilizado actualmente por los productos de SGBD comerciales. Pero en otras reas, incluidas hasta las consultas dinmicas de SQL ms elementales, el nuevo estndar introduce incompatibilidades con los productos de SGBD ya existentes, 10 que exigir la reescritura de las aplicaciones. Los prximos apartados describen con detalle el estndar SQL2 para SQL dinmico, con un nfasis especial en las diferencias con SQL dinmico estilo DB2 descrito en los apartados anteriores. En la prctica, el soporte de SQL dinmico estilo SQL2 va apareciendo poco a poco entre los productos de SGBD comerciales, y la mayor parte de la programacin de SQL dinmico sigue exigiendo el empleo del antiguo SQL dinmico estilo DB2. Incluso cuando una versin nueva de un producto de SGBD admite las nuevas instrucciones de SQL2, el fabricante del SGBD proporciona siempre una opcin del precompilador que acepta la antigua estructura de SQL dinmico utilizada por ese SGBD concreto. A menudo se trata de la opcin predeterminada del precompilador, ya que, con centenares y millares de programas de SQL ya existentes, el fabricante del SGBD tiene una necesidad absoluta de que las versiones nuevas del SGBD no dejen inservibles los programas antiguos. Por tanto, la migracin a las partes de SQL2 que presentan incompatibilidades con la prctica actual ser lenta y evolutiva.
Conversiones entre tipos de datos

El formato de los tipos de datos que utiliza DB2 para recibir el valor de los parmetros y devolver los resultados de las consultas son los admitidos por los grandes sistemas de arquitectura S/370 de IBM que ejecutan DB2. Corno se dise como SGBD portable, Gracle utiliza sus propios formatos internos de tipos de datos. Gracle realiza de manera automtica la conversin entre sus formatos internos de datos y los del sistema informtico en el que se est ejecutando siempre que recibe valores de los parmetros del programa o le devuelve resultados de las consultas. El programa puede utilizar el SQLDA de Gracle para controlar la conversin de tipos de datos llevada a cabo por Grade. Por ejemplo, supngase que el programa utiliza la instruccin DESCRIBE para describir los resultados de las consultas dinmicas y descubre (a partir del cdigo de tipo de datos del SOLDA) que la primera columna contiene datos numricos. El programa puede solicitar la conversin de los datos numricos modificando el cdigo del tipo de datos en el SQLDA antes de que capture los datos. Si el programa ubica el cdigo de tipos de datos de las cadenas de caracteres en el SQLDA, por ejemplo, Oracle convierte la primera columna de resul.tados de la consulta y la devuelve al programa como una cadena de cifras.
Instrucciones bsicas de SOL2 dinmico

Las instrucciones de SQL2 que implementan la ejecucin de las instrucciones de SQL dinmico bsico (es decir, SQL que no implica a las consultas a las bases de datos) se pueden ver en la Figura 18.17. Estas instrucciones siguen estrechamente la estructura y el lenguaje de DB2. Esto incluye los mtodos de ejecucin de las instrucciones de SQL dinmico de una sola etapa y de dos etapas. La instruccin de SQL2 EXECUTE IMMEDIATE tiene una sintaxis y una operativa idnticas a las de su contrapartida de DB2. Ejecuta de manera inmediata la instruccin de SQL pasada al SGBD en forma de cadena de caracteres. Por tanto, la instruccin EXECUTE IMMEDIATE de la Figura 18.3 se ajusta al estndar SQL2.
576
577
r-
EXECUTE IHMEOIATE variable-deJ-anfitrin
f-- PREPARE nombre-instruccin FROM variable-delanfitrin
r-
EXECUTE
nombre-inst, uccin
( variable-del-
1- USING L n f i t f i n
USING SQL DESCRIPTOR nombre-descripror
f-1NTO----r
variable-delanfi,rin
mbre-descripror
so
r-OEALLOCATE PREPARE nombreinstruccin
Figura 18.17.
Instrucciones de SOL dinmico de SOL2.
Las instrucciones de SQL2 PREPARE y EXECUTE tambin operan de manera idntica a sus contrapartida de estilo DBZ. La instruccin PREPARE pasa al SGBD una cadena de caracteres de texto que contiene una instruccin de SQL y hace que el SGBD la analice, la optimice y cree un plan de aplicacin para ella. La instruccin EXECUTE hace que el SGBD ejecute realmente una instruccin preparada anteriormente. Al igual que la versin de DBZ, la instruccin de SQL2 EXECUTE acepta de manera opcional variables del anfitrin que pasan los valores concretos que hay que utilizar al ejecutar la instruccin de SQL. Las instrucciones PREPARE y EXECUTE de la Figura l8.4 (marcadas como elemento 2), por tanto, se ajustan al estndar SQLZ. DOS ampliaciones tiles de la estructura PREPARElEXECUTE forman parte de la especificacin del nivel de cumplimiento completo del estndar SQL2 (ninguna de ellas forma parte de los niveles de cumplimiento iriicial ni intennedio). La primera es una til acompaante de la instruccin PREPARE que deshace la preparacin de una instruccin de SQL dinmico compilada previamente. La instruccin DEALLOCATE PREPARE ofrece esta posibilidad. Cuando el SGBD procesa esta instruccin, puede liberar los recursos asociados con la instruccin compilada, que suelen incluir alguna representacin interna del plan de aplicacin de la instruccin. La instruccin mencionada en la instruccin DEALLOCATE PREPARE debe coincidir con el nombre especificado en alguna instruccin PREPARE ya ejecutada.
En ausencia de una posibilidad como la ofrecida por DEALLOCATE PREPARE, el SOBD no tiene manera de saber si se volver a ejecutar una instruccin preparada anteriormente y, por tanto, si debe conservar toda la informacin asociada con ella. En la prctica, algunas marcas de SOBD slo conservan la versin compilada de la instruccin hasta el final de la transaccin; en esos sistemas, hay que volver a preparar cada instruccin para cada transaccin posterior en que se vaya a utilizar. Debido a la sobrecarga implicada en este proceso. otras marcas de SGBD conservan de manera indefinida la informacin relativa a la instruccin compilada. La instruccin DEALLQCATE PREPARE puede desempear un papel ms importante en estos sistemas, en los que las sesiones de las bases de datos pueden durar varias horas. Obsrvese, no obstante, que el estndar SQLZ indica de manera explcita que el hecho de que una instruccin preparada sea vlida fuera de la transaccin en la que se prepara depende de la implementacin. La ampliacin de SQLZ a la instruccin de estilo DBZ EXECUTE puede resultar, en la prctica, todava ms importante. Pennite utilizar la instruccin EXECUTE para procesar instrucciones SELECT que devuelven una sola fila de resultados de la consulta. Al igual que la instruccin EXECUTE de DB2, la instruccin de SQL2 incluye una clusula USING que menciona las variables del anfitrin que proporcionan el valor de los parmetros de la instruccin que se est ejecutando. Pero la instruccin de SQLZ tambin permite una clusula INTO opcional que menciona las variables del anfitrin que reciben Jos valores devueltos por las consultas en una sola fila. Supngase que se ha escrito un programa que genera de manera dinmica -una instruccin de consulta que recupera el nombre y la cuota de los representantes, con el nftlero de empleado de cada representante como parmetro de entrada. Utilizando SQL dinmico del estilo DBZ, incluso esta consulta sencilla implica la utilizacin de un SQLDA, de cursores, de un bucle con la instruccin FETCH, etc. Empleando SQL dinmico de SQLZ, la instruccin puede ejecutarse empleando esta secuencia sencilla de dos instrucciones:
PREPARE qrystmt FROM :bufer_instruccion; EXECUTE qrys tmt USING : numempl INTO : nombre
:
cuota:
Al igual que con cualquier instruccin preparada, esta consulta en una sola.fila puede ejecutarse de manera repetida despus de haberla preparado una vez. Sigue adoleciendo de la restriccin de que el nmero de columnas devueltas, y sus tipos de datos, deben conocerse al escribir el programa, ya que deben coincidir exactamente con el nmero y los tipos de datos de las variables del anfitrin de la clusula INTO. Esta restriccin se elimina permitiendo el empleo de un rea de descriptores estilo SQLDA en lugar de una lista de variables del anfitrin, tal y como se describe en el apartado siguiente.
SQL2 y SQLDA
Aunque su soporte del procesamiento de PREPARE/EXECUTE sigue muy de cerca al de SQL dinmico de OBZ, el estndar SQL2 diverge sustancialmente del estilo
578
579
DB2 en el rea del procesamiento de las consultas dinmicas. En concreto, el estndar SQL2 incluye cambios importantes en el rea de datos de SQL de DB2 (SQL Data Area, SQLDA), que se halla en el corazn de las consultas dinmicas en varias filas. Recurdese que el rea de datos de SQL (SQL Data Area, SQLDA) proporciona dos funciones importantes: Una manera flexible de pasar los parmetros que se van a utilizar en la ejecucin de las instrucciones de SQL dinmico (pasando los datos del programa anfitrin al SOBD), como ya se ha descrito en el apartado EXECUTE con
SQLDA.
Parte fija
COUNT
nmero de elementos descritos
Parte variable -una aparicin por elemento (parametro o columna de resultados de la consulta):
TYPE LENGTH OCTET_LENGTH RETURNEO_LENGTH RETURNED_OCTET_LENGTH
PRECISION SCALE DATETIME_INTERVAL_CODE OATETIME_INTERVAL_PRECISION NULLABLE INDICATOR DATA NAME UNNAMED tipo de datos del elemento longitud del elemento longitud del elemento (en octetos de ocho bits) longitud del elemento de datos devuelto longitud de los datos devueltos (en octetos de ocho bits) precisin del elemento de datos escala del elemento de datos tipo de datos del intervalo de fecha/hora precisin de los datos del intervalo de fecha/hora indica si el elemento puede ser NULL indica si el elemento de datos es NULL (valor del indicador) el propio elemento de datos nombre del elemento de datos indica si el elemento de datos carece de nombre
La manera de que el resultado de la consulta se pase al programa en la ejecucin de una consulta de SQL dinmico (enviando los datos del SOBD al programa anfitrin), como ya se ha descrito en el apartado La instruccin
FETCH.
El SQLDA estilo DB2 maneja estas funciones con flexibilidad, pero tiene algunos inconvenientes graves. Se trata de una estructura de nivel muy bajo, que tiende a ser especfica de cada lenguaje de programacin. Por ejemplo, la estructura de longitud variable de las SQLDA estilo DB2 la hace muy difcil de representar en el lenguaje FORTRAN. La estructura SQLDA tambin hace suposiciones de manera implcita sobre la memoria del sistema informtico en el que se est ejecutando el programa de SQL dinmico, el modo en que los elementos de datos de una estructura se alinean en ese sistema, etc. Para los redactores del estndar SQL2, estas dependencias de bajo nivel eran barreras inaceptables para la portabilidad. Por tanto, sustituyeron la estructura SQLDA de DB2 por un conjunto de instrucciones para la manipulacin de una estructura ms abstracta denominada descriptor de SQL dinmico. La estructura de los descriptores de SQL2 se puede ver en la Figura 18.18. Conceptualmente, los descriptores de SQL2 son paralelos al SQLDA de DB2, que se muestra en la Figura 18.7, y desempean exactamente el mismo papel. La parte fija de los descriptores de SQL2 especifica un recuento del nmero de elementos de la parte variable de cada descriptor. Cada elemento de la parte variable contiene informacin sobre un nico parmetro que se pasa, como su tipo de datos, su longitud, un indicador que indica si se pasa un valor NULL, etc. Pero, a diferencia de las SQLDA de DB2, los descriptores de SQL2 no son una estructura real de datos dentro del programa anfitrin. En vez de eso, son un conjunto de elementos de datos propiedad del software del SOBD. El programa anfitrin manipula los descriptores de SQL2 ---crendolos, destruyndolos, ubicando elementos de datos en su interior, extrayendo datos de ellos- mediante un conjunto nuevo de instrucciones de SQL dinmico diseado especialmente para esa finalidad. La Figura 18.19 resume estas instrucciones de gestin de descriptores de SQL2. Para comprender el modo en que funcionan las instrucciones de gestin de los descriptores, resulta instructivo volver a examinar el programa de actualizaciones de SQL, dinmico de la Figura 18.8. Este programa ilustra el empleo de las SQLDA de estilo DB2 en las instrucciones EXECUTE. El flujo del programa sigue
Figura 18.18.
Estructura del descriptor de SQL2.
r---ALLOCATE DESCRIPTOR
nombre.descriPtor-L
WITH MAX
J
nmercrdeelementos
r---DEALLOCATE DESCRIPTOR
n o m b r e d e s c r i p t o r - - - - - - - - - - - - - - - - 1 ,...
r---SET DESCRIPTOR - - , - - - - - - - - - - - - - - - - - - . - - - -....

COUNT ..
VALUE
variabledel-anfitrin'--------.[ nombre- .. varja~Ie..delelemento anfltrlon

I
nmero.elemento
~ GET
DESCRIPTOR-
variable-del-anfitrin .. COUN'I'.
LVALUE numero-elemento
L:n
vafla~le. del .. nombre ~_--l

elemento
I
Figura 18.19.
Instrucciones de gestin de los descriptores de SQL2.
580

Tabla 18.2.
581
siendo idntico si se utiliza un descriplOr de SQL2 en su lugar, pero Jos detalles cambian bastante. Antes de utilizar el descriptor, el programa debe crearlo, utilizando la instruccin:
ALLOCATE DESCRIPTOR parmdesc WITH MAX :parrncnt;
Cdigos de tipos de datos de SQL2
il'ipo de datos Cdigos de tipos de datos (TYPE)

INTEGER SMALLINT
Cdigo
S 2
3
Esta instruccin sustituye la asignacin de almacenamiento para la estructura de datos parmda en la llamada 1 de la Figura 18.8. El descriptor (denominado parrndesc) llevar a cabo las mismas funciones que parrnda. Obsrvese que el programa de la Figura 18.8 tena que calcular la cantidad de almacenamiento que sera necesaria para la estructura parmda antes de asignarla. Con los descriptores de SQL2 ese clculo se elimina, y el programa anfitrin se limita a indicar al SGBD el nmero de elementos que debe poder guardar la parle variable del descriptor. La siguiente etapa del programa es la definicin del descriptor orientada a indicar los parmetros que hay que pasar -sus tipos de datos, sus longitudes. etc.-. El bucle de la llamada 2 del programa permanece intacto. pero, nuevamente, los detalles del modo en que se inicializa el descriptor difieren de los del SQLDA. En las llamadas 3 y 4, el tipo de datos y la longitud del parmetro se especifican con una modalidad de la instruccin SET DESCRIPTOR, con este fragmento de cdigo:
typecode = columnsliJ .typecode; length = columnsli].buflen; SET DESCRIPTOR parmdesc VALUE (:i + 1) TYPE = :typecode SET DESCRIPTOR parmdesc VALUE (:i + 1) LENGTH = ,length;
NUMERIC DECIHAL FLOAT REAL DOUBLE PRECISION CHARACTER CHARACTER VARYING BIT BIT VARYING DATE/TIME/TIMESTAMP INTERVAL
7
8
12
14
tS
9
10
Subcdigos de fecha/hora (In terval_Code)

DATE
t
2 4
Las diferencias con la Figura 18.8 son reveladoras. Como el SGBD mantiene el descriptor, hay que pasar al SGBD el tipo de datos y la longitud mediante la instruccin SET DESCRIPTOR, empleando variables del anfitrin. En este ejemplo concreto, se utilizan las variables sencillas typecode y length. Adems, los cdigos de tipos de datos de la Figura 18.8 eran privativos de DB2. El hecho de que cada fabricante de SGBD utilice cdigos diferentes para representar los diferentes tipos de datos de SQL fue una causa importante de problemas de portabilidad en SQL dinmico. El estndar SQL2 especifica los cdigos enteros de los tipos de datos para todos los tipos de datos especificados en el estndar, lo que elimina este problema. Los cdigos de tipos de datos de SQL2 se resumen en la Tabla 18.2. Por tanto, adems de las otras modificaciones. habra que modificar los cdigos de tipos de datos de la estructura de columnas de la Figura 18.8 para utilizar estos cdigos de tipos de datos del estndar SQL2. Las instrucciones de las llamadas 5 y 6 de la Figura 18.8 se utilizaron para enlazar la estructura SQLDA con los bferes del programa utilizados para contener los datos de los parmetros y de las variables indicadoras correspondientes. Efec~ tivamente, ponen punteros a esos bferes del programa dentro del SQLDA para que los emplee el SGBD. Con los descriptores de SQL2 este tipo de enlace no es posible. En su lugar, se pasa de manera especfica el valor de los datos y del indicador como variables del anfitrin, ms adelante en el programa. Por tanto, habra que eliminar las "instrucciones de las llamadas 5 y 6 durante la conversin a SQL2.
TIME TIME WITH TIME ZONE TIMESTAMP TIMESTAMP WITH TIME ZONE
3 S
Subcdigos de fecha/hora (Interval_precision)

YEAR MONTH OAY HOUR MINUTE SECaNO YEAR - MONTH OAY - HOUR OAY - MINUTE OAY - SECONO
3
4
5
6
8
9 10
582
Capitulo 18: SOL dinmico
583
La instruccin de la llamada 7 de la Figura 18.8 define el SQLDA para que indi que el nmero de valores de los parmetros que se pasan realmente al SGBD. De manera parecida, hay que definir los descriptores de SQL2 para que indiquen el nmero de parmetros que se pasan. Esto se hace con una modalidad de la instruccin SET DESCRIPTOR:
SET DESCRIPTOR parrndesc COUNT : :parmcnt;
De manera estricta, esta instruccin SET DESCRIPTOR debera, probablemente, colocarse antes en el programa y ejecutarse antes de las de los elementos indivi duales. El estndar SQL2 especifica un conjunto completo de reglas que describen el modo en que la definicin de los valores en algunas partes del descriptor hace que haya que volver a definir los valores de otras partes del descriptor. En su mayor parte, estas reglas simplemente especifican la jerarqua natural de la informacin. Por ejemplo, si se define el tipo de datos de un elemento concreto para que indique un entero, el estndar indica que se volver a definir la informacin correspondiente del descriptor que indica la longitud del mismo elemento como algn valor dependiente de la implementacin. Normalmente esto no afecta a la programacin, pero significa que no se puede dar por supuesto que, porque se haya definido anteriormente algn valor dentro del descriptor, conservar ese mismo valor. Es mejor rellenar el descriptor de manera jerrquica, comenzando con la informacin de nivel superior (por ejemplo, el nmero de elementos y sus tipos de datos) y pasando luego a la informacin de nivel inferior (longitudes de los tipos de datos. subtipos. si se permiten los valores NULL, etc.). El flujo del programa en la Figura 18.8 puede continuar ahora sin modificaciones. La instruccin PREPARE compila la instruccin dinmica UPDATE y su modalidad no cambia para SQL2. El programa entra ahora en el bucle for, pidiendo los parmetros al usuario. Una vez ms, los conceptos son los mismos, pero los detalles de la manipulacin de la estructura SQLDA y del descriptor de SQL2 difieren. Si el usuario indica que hay que asignar un valor NULL (escribiendo un asterisco en respuesta a la peticin), el programa de la Figura 18.8 define de manera adecuada el bfer de los indicadores de parmetro con la instruccin:
* (parmvar->sQ1ind) ;
-1;
Obsrvese otra vez el empleo de la variable de control del bucle para especificar el elemento del descriptor que se est definiendo y el pase directo de datos (en este caso, constantes) en lugar del empleo de punteros a bferes en la estructura del SQLDA. Finalmente, el programa de la Figura 18.8 pasa al SGBD el valor real del parmetro escrito por el usuario, mediante el SQLDA. Las instrucciones de la llamada 8 realizan esto para datos de diferentes tipos, convirtiendo primero los caracteres escritos en representaciones binarias de los datos y ubicando los datos binarios en los bferes de datos a los que apunta el SQLDA. Una vez ms, la conversin a SQL2 implica la sustitucin de estos punteros y la manipulacin directa del SQLDA con una instruccin SET DESCRIPTOR. Por ejemplo, estas instrucciones pasan los datos y la longitud de una cadena de caracteres de longitud variable:
length = strlen(inbuf); SET DESCRIPTOR parmdesc VALUE (:j + 1) DATA = :inbuf; SET DESCRIPTOR parrndesc VALUE (:j + 1) LENGTH = :length;
Para los elementos de datos que no necesitan una especificacin de longitud, el pase de los datos es incluso ms sencillo, ya que slo es necesaria la forma DATA de la instruccin SET DESCRIPTOR. Tambin resulta til darse cuenta de que SQL2 especifica las conversiones implcitas de tipos de datos entre las variables del anfitrin (como inbuf) y los tipos de datos de SQL. De acuerdo con el estndar SQL sera necesario que el programa de la Figura 18.8 llevara a cabo todas las conversiones de tipos de datos en las funciones sscanf (). En vez de eso, se pueden pasar los datos al SGBD corno datos de caracteres. para su conversin automtica y la deteccin de errores. Con el SQLDA definida finalmente corno es necesario, el programa de la Figura 18.8 ejecuta la instruccin dinmica UPDATE con los parmetros pasados en la llamada 9, empleando una instruccin EXECUTE que especifica un SQLDA. La conversin de esta instruccin en un descriptor de SQL2 es directa; se transforma en:
EXECUTE updatestmt USING SQL DESCRIPTOR parrndesc;
y si el valor no es NULL, el programa vuelve a definir el bfer de los indicadores con la instruccin:
* (parmvar->sQlind) :
Las palabras clave de la instruccin EXECUTE cambian ligeramente y se especifica el nombre del descriptor, en lugar del nombre del SQLDA. Finalmente, el programa de la Figura 18.8 debe; modificarse como se indica a continuacin para indicar al SGBD que debe desasignar el descriptor de SQL2. La instruccin que lo lleva a cabo es:
DEALLOCATE DESCRIPTOR parrndesc;
o;
En prooramas sencillos corno ste, la instruccin DEALLOCATE no resulta muy necesaria, ~ero en los programas ms complejos del da a da, con varios descrip~ tares, resulta muy conveniente desasignarlos cuando el programa deja de necesi~ tarlos.
Para los descriptores de SQL2 estas instrucciones se volveran a convertir en un par de instrucciones SET DESCRIPTOR:
SET DESCRIPTOR parmdesc VALUE(:j + 1) INDICATOR = -1; SET DESCRIPTOR parmdesc VALUE (:j + 1) INDICATOR = O;
584
585
SOL2 y consultas de SOL dinmico

En las instrucciones de SQL dinmico de los apartados anteriores los descriptores de SQL2, al igual que las SQLDA a las que sustituyen, se utilizan para pasar informacin de los parmetros desde el programa anfitrin al SGBD, para su empleo en la ejecucin de instrucciones dinmicas. El estndar SQL2 tambin utiliza los descriptores de SQL en las instrucciones para consultas dinmicas, donde, dado que las SQLDA las sustituyen, controlan el pase de los resultados de las consultas desde el SGBD al programa anfitrin. La Figura 18.9 muestra el listado de un programa de consultas de SQL dinmico del estilo DB2. Resulta til examinar el modo en que el programa de la Figura 18.9 cambiara para adaptarse al estndar SQL2. Una vez ms, el flujo del programa permanece idntico bajo SQL2, pero los detalles cambian mucho. Las modalidades de las instrucciones de procesamiento de consultas de SQL dinmico ~e pueden ver en la Figura 18.20.
La declaracin del cursor para la consulta dinmica, en la llamada 1 de la Figura 18.9. sigue igual bajo SQL2. La construccin de la instruccin dinmica SE~ LECT en la llamada 2 tambin sigue sin cambios. igual que la instruccin PREPARE de la llamada 3. Las modificaciones del programa comienzan en la llamada 4, en la que el programa utiliza la instruccin DESCRIBE para obtener una descripcin de los resultados de la consulta, que se devuelve en un SQLDA denominaaa qry_da. Para SQL2 esta instruccin DESCRIBE debe modificarse para hacer referencia a un descriptor de SQL2. que se ha debido asignar anteriormente. Suponiendo que el descriptor se denomine qrydesc. las instrucciones seran:
ALLOCATE DESCRIPTOR qrydesc WITH MAX :colcount; DESCRIBE querystrnt USING SQL DESCRIPTOR qrydesc;
r-r-r--
DESCRIBE
T;T
OUT"'"
IN"'"
nombre-instruccin USING SQL DESCRIPTOR nombredescriptor----...
DECLARE
nombre-cursor [
INSENSITlVE
~ CURSOR FOR
nombrtt-jnstrucx:in---+e
La modalidad de SQL2 de la instruccin DESCRIBE tiene un efecto paralelo a la que sustituye. Se devuelven las descripciones de las columnas de resultados de la consulta, columna por columna, en el descriptor de SQL2, en lugar de hacerlo en el SQLDA. Como el descriptor es una estructura del SGBD, en vez de una estructura de datos real del programa, el programa anfitrin debe recuperar la informacin del descriptor, fragmento a fragmento, cuando la necesita. La instruccin GET DESCRIPTOR lleva a cabo esta funcin, igual que la funcin SET DESCRIPTOR desempea la funcin opuesta de poner la informacin en el descriptor de SQL2. En el programa de la Figura 18.9 las instrucciones de la llamada 5, que obtienen del SQLDA la longitud de una columna concreta de resultados de la consulta~ se sustituiran por la instruccin:
GET DESCRIPTOR qrydesc VALUE (:i + 1) qry_var -> sqldat z malloc{length); :length LENGTH;
J L
~ ALLQCATE nombre-eursor
T
L
INSESITIVE
rr=T
SCROLL
SCROLL
CURSOR FOR
nombre-instruccin - . .
OPEN
nombrecursor
1- USING L..:nfi;i~
L USlNG SQL DESCRIPTOR
variab/e.de/-
nombre-descriptor
r--
FETCH
nombre-cursor
&
~ mro ~nr;ri~
variable""lie/LUSING SQL DESCRIPTOR
I
!
nombredescriptor
La instruccin de la llamada 5 que asigna los bferes para cada elemento de resultados de la consulta sigue siendo necesaria, pero el mtodo para indicar al SGBD el lugar en que debe colocar los resultados cambia para SQL2. En lugar de ubicar la direccin de destino del programa para cada elemento en el SQLDA, el programa debe ubicar estas direcciones en el descriptor de SQL2, empleando la instruccin SET DESCRIPTOR. Los bferes de las variables indicadoras no son necesarios con el descriptor de SQL2. En su lugar, la informacin sobre si las columnas contienen valores NULL puede obtenerse del descriptor para cada fila a medida que las captura, como puede verse ms adelante en el programa de ejemplQ. En este ejemplo concreto, el nmero de columnas de los resultados de la consulta 10 calcula el programa a medida que crea la consulta. El programa tambin podra obtener el nmero de columnas del descriptor de SQL2 con esta modalidad , I de la instruccin GET DESCRIPTOR:
GET DESCRIPTOR qrydesc :colcount = COUNT;
r--
CLaSE
nomrlH:ursor
Figura 18.2'0.
Instrucciones de procesamiento de consultas de SQL2 dinmico.
Habiendo obtenido la descripcin de los resultados de la consulta, el programa la lleva a cabo abriendo el cursor de la llamada 6_ La fonna sencilla de la instruccin QPEN, sin ningn parmetro de entrada, se ajusta al estndar SQL2. Si la consulta
586
587
dinmica especificaba algn parmetro, puede pasarse al SGBD como una serie de variables del anfitrin o mediante un descriptor de SQL2. La instruccin OPEN de SQL2
que utiliza variables del anfitrin es idntica a la del estilo DB2, que puede verse en el programa de la Figura 18.13. La instruccin OPEN de SQL2 que utiliza descriptores es paralela a la instruccin de SQL2 EXECUTE que utiliza descriptores, y se diferencia de
especifica en la estructura del descriptor. El programa debe seguir utilizando el descriptor para determinar la informacin sobre cada columna de resultados devueltos, como su longitud o si contiene valores
NULL.
Por ejemplo, para determi-
nar la longitud devuelta de una columna de datos de caracteres, el programa puede utilizar la instruccin:
GET DESCRIPTOR qrydesc VALUE(:i + 1) :1ength = RETURNED_LENGTH;
NULL,
la de estilo DB2. Por ejemplo, la instruccin
OPEN
de la Figura 18.14:
OPEN qrycursor USING DESCRIPTOR :parmda;
se transforma para SQL2 en esta instruccin
OPEN:
Para determinar si el valor de la columna era la instruccin:

GET DESCRIPTOR qrydesc VALUE{:i
+
el programa puede utilizar
QPEN qrycursor USING SQL DESCRIPTOR parmdesc;
1)
;indbuf = INDICATOR;
La tcnica para pasar los parmetros de entrada a la instruccin OPEN mediante los descriptores de SQL2 es exactamente la misma que ya se describi anteriormente para la instruccin EXECUTE. Al igual que la implementacin de Gracle de SQL dinmico, el estndar SQL2 ofrece una manera de que el programa anfitrin obtenga una descripcin de los parmetros de la consulta dinmica, as como una descripcin de los resultados de la consulta. Para el fragmento de programa de la Figura 18.14, la siguiente instruccin DESCRIBE:
DESCRIBE INPUT querystmt USING SQL DESCRIPTOR parmdesc;
y, de manera parecida, para determinar el tipo de datos de la columna, el programa puede utilizar la instruccin:
GET DESCRIPTOR qrydesc VALUE{:i + 1) :type = TYPE;
devolver, en el descriptor de SQL2 denominado parmdesc, una descripcin de cada uno de los parmetros que aparecen en la consulta dinmica. El nmero de parmetros puede obtenerse con la instruccin GET DESCRI PTOR, recuperando el elemento COUNT del descriptor. Al igual que con la implementacin de Oracle, el estndar SQL2 puede tener dos descriptores asociados con cada consulta dinmica. El descriptor de entrada, obtenido con la instruccin DESCRIBE INPUT, contiene descripciones de los parmetros. El descriptor de salida contiene descripciones de las columnas de resultados de la consulta. El estndar permite pedir, de manera explcita, la descripcin del resultado:
DESCRIBE OUTPUT querystmt USING SQL DESCRIPTOR qrydesc;
Como puede verse, los detalles del procesamiento fila por fila de las consultas dentro del bucle for del programa se diferencian espectacularmente de los de la Figura 18.9. Tras procesar todas las filas de resultados de la consulta, el programa cierra el cursor en la llamada 8. La instruccin CLOSE sigue sin cambios bajo SQL2. Despus del cierre del cursor resulta conveniente desasignar los descriptores de SQL2 que se hubieran asignado al comienzo del programa. Las modificaciones necesarias de los programas de SQL dinmico de las Figuras 18.8, 18.9 Y 18.14 para hacer que se ajusten al estndar SQL2 ilustran, con detalle, las nuevas caractersticas especificadas por el estndar y el grado en el que se diferencian del uso normal de SQL dinmico de hoy en da. En resumen, las modificaciones respecto de SQL dinmico estilo DB2 son: La estructura SQLDA se sustituye por un descriptor con nombre de SQL2. Se utilizan las instrucciones ALLOCATE DESCRIPTOR y DEALLOCATE DESCRIPTOR para crear y destruir los descriptores, sustituyendo a la asignacin y desasignacin de las estructuras de datos SQLDA del programa anfitrin. En lugar de manipular directamente los elementos del SQLDA, el programa especifica los valores y la informacin de los parmetros mediante la instruccin SET DESCRIPTOR. En lugar de manipular directamente los elementos del SQLDA, el programa obtiene la informacin sobre los resultados de la consulta, y los propios resultados de la consulta mediante la instruccin GET DESCRIPTOR. La instruccin DESCRIBE se utiliza tanto para obtener las descripciones de los resultados de la consulta (DESCRIBE OUTPUT) como para obtener las descripciones de los parmetros (DESCRIBE INPUT). Las instrucciones EXECUTE, OPEN y FETCH estn ligeramente modificadas para especificar el descriptor de SQL2 por su nombre, en lugar del SQLDA.
pero la modalidad DESCRIBE OUTPUT de la instruccin es la predeterminada, y lo ms habitual es omitir la palabra clave OUTPUT. Volviendo al ejemplo de consulta dinmica de la Figura 18.9, el cursor se ha abierto en la llamada 7, y ya es hora de capturar las filas de resultados de la consulta en la llamada 8. Una vez ms, la modalidad de SQL2 de la instruccin FETCH est ligeramente modificada para utilizar el descriptor de estilo SQL2:
FETCH sq1curs USING SQL DESCRIPTOR qrydesc;
La inslrU.cci6n FETCH desplaza el cursor hasta la siguiente fila de resultados de la consulta y lleva los valores de esa fila a los bferes del programa, tal y como se
588
Capftulo 78: SOL dinmico.
589
Resumen
Este captulo describe SQL dinmico, una forma avanzada de SQL incorporado. SQL dinmico se necesita pocas veces para escribir aplicaciones sencillas de procesamiento de datos, pero resulta crucial para la creacin de partes visibles de finalidad general de las bases de datos. SQL esttico y SQL dinmico presentan un equilibrio clsico entre la eficiencia y la flexibilidad, que puede resumirse de la manera siguiente: Sencillez. SQL esttico resulta relativamente sencillo; incluso su caracterstica ms compleja, los cursores, puede comprenderse fcilmente en trminos de los conceptos familiares de entrada y salida de archivos. SQL dinmico es complejo, exige la generacin dinmica de instrucciones, estructuras de datos de longitud variable y la gestin de la memoria, con asignacin y desasignacin de la memoria, alineacin de tipos de datos, gestin de punteros y los problemas asociados. Rendimiento. SQL esttico se compila dentro de un plan de aplicacin en el momento de la compilacin; SQL dinmico debe compilarse en el momento de la ejecucin. En consecuencia, el rendimiento de SQL esttico suele ser mucho mejor que el de SQL dinmico. El rendimiento de SQL dinmico se ve enormemente afectado por la calidad del diseo de las aplicaciones; un diseo que minimice la cantidad de sobrecarga de compilacin puede aproximarse al rendimiento de SQL esttico. Flexibilidad. SQL dinmico permite que los programas decidan en el momento de la ejecucin las instrucciones concretas de SQL que van a ejecutar. SQL esttico exige que todas las instrucciones de SQL se codifiquen con antelacin, al escribir los programas, 10 que limita la flexibilidad de los programas. SQL dinmico utiliza un conjunto de instrucciones de SQL incorporado ampliadas para soportar sus caractersticas dinmicas: La instruccin EXECUTE IMMEDIATE pasa al SGBD el texto de una instruccin de SQL dinmico, que lo ejecuta de manera inmediata. La instruccin PREPARE pasa al SGBD el texto de una instruccin de SQL dinmico, que la compila en un plan de aplicacin, pero no la ejecuta. La instruccin dinmica puede incluir marcadores de parmetro cuyos valores se especifican al ejecutar la instruccin. La instruccin EXECUTE pide al SGBD que ejecute una instruccin dinmica compilada previamente por una instruccin PREPARE. Tambin proporciona el valor de los parmetros para la instruccin que se va a ejecutar. La instruccin DESCRIBE devuelve una descripcin de una instruccin dinmica preparada previamente dentro de un SQLDA. Si la instruccin dinmica es una consulta, la descripcin incluye una descripcin de cada columna de resultados de la consulta.
La instruccin DECLARE CURSOR para consultas dinmicas especifica la consulta mediante el nombre de instruccin que se le asign cuando la compil la instruccin PREPARE. La instruccin OPEN para consultas dinmicas pasa el valor de los parmetros para la instruccin dinmica SELECT y solicita la ejecucin de la consulta. La instruccin FETCH para consultas dinmicas captura una fila de resultados de la consulta en reas de datos del programa especificadas por la estructura SQLDA. La instruccin CLOSE para consultas dinmicas concluye el acceso a los resultados de la consulta.
CAPTULO
19
Las API de SOL
I
1
La tcnica de SQL incorporado para el acceso mediante programacin a las bases de datos basadas en SQL fue desarrollada por los primeros prototipos de bases de datos relacionales de IBM y la adoptaron los principales productos de SQL. No obstante, varios productos de SGBD importantes, liderados por la primera implementacin de SQL Server de Sybase, adoptaron un enfoque diferente. En lugar de intentar mezclar SQL con otro lenguaje de programacin. esos productos proporcionan una biblioteca de llamadas a funciones en forma de interfaz de programacin de aplicaciones (Application Programming Interface, APl) para el SGBD. Para pasar las instrucciones de SQL al SGBD, los programas de aplicacin llaman a las funciones de la API, que llama a otras funciones para recuperar del SGBn los resultados de la consulta y la informacin de estado. Para muchos programadores, las API de SQL son una manera muy sencilla de utilizar SQL. La mayor parte de los programadores tienen cierta experiencia en el empleo de bibliotecas de funciones para otras finalidades, como la manipulacin de cadenas de caracteres, las funciones matemticas, la entrada y salida de archivos y la gestin de formularios en pantalla. Los sistemas operativos modernos, como UNIX y Windows. realizan un empleo extensivo de los conjuntos de las API para ampliar las posibilidades bsicas proporcionadas por el propio sistema operativo. La API de SQL, por tanto, no es ms que otra biblioteca que debe conocer el programador. En los ltimos aos, las API de SQL se han hecho muy populares, igualando o, incluso, superando, la popularidad del enfoque de SQL incorporado para el desarrollo de nuevas aplicaciones. Este captulo describe los conceptos generales utilizados por todas las interfaces API de SQL. Tambin describe caractersticas propias de algunas de las API propietarias empleadas por sistemas de SGBD populares basados en SQL, as como el estndar ANSIIISO de la interfaz del nivel de llamadas de SQL (SQL CallLevel Interface, CU) y el estndar de conectividad abierta de bases de datos (Open Database Connectivity, ODBe) de Microsoft en el que se basa. Finalmente, describe JDBe, que es el estndar de API para el acceso de SQL desde los programas escritos en Java. y lo utilizan todos los servidores de aplicaciones de Internet populares.
591
592
Captulo 79: Las API de SOL
593
Conceptos de las API

Cuando un SOBO alberga una interfaz de llamadas a funciones, los programas de aplicacin se comunican con el SGBO exclusivamente mediante un conjunto de llamadas que se conoce colectivamente como interfaz de programacin de aplicaciones (Application Programming interface) o API. La operacin bsica de las API tpicas de los SGBD se ilustra en la Figura 19.1. El programa comienza el acceso a la base de datos con una o varias llamadas a la API que conectan al programa con el SGBD y. a menudo, a una base de datos concreta.
Para enviar una instruccin de SQL al SGBD, el programa crea la instruccin en forma de cadena de caracteres de texto en un bfer y luego hace una llamada a la API para pasar el contenido de ese bfer al SGBD. El programa hace llamadas a la API para comprobar el estado de su solicitud al SGBD y para manejar los errores. Si la solicitud es una consulta, el programa utiliza llamadas a la API para recuperar el resultado de la consulta en el bfer del programa. Generalmente las llamadas recuperan los datos fila a fila o columna a columna. El programa concluye el acceso a la base de datos con una llamada a la API que lo desconecta del SGBD. La API de SQL suele utilizarse cuando el programa de aplicacin y la base de datos se hallan en dos sistemas diferentes en una arquitectura cliente/servidor, como puede verse en la Figura 19.2. En esta configuracin, el cdigo para las funciones API se halla en el sistema cliente, donde se ejecuta el programa de aplicacin. El software del SOBD se halla en el sistema servidor, donde reside la base de datos. Las llamadas desde el programa de aplicacin a la API tienen lugar de manera local dentro del sistema cliente, y el cdigo API traduce esas llamadas en mensajes que intercambia con el SOBO por la red. La API de SQL ofrece ventajas especiales para la arquitectura cliente/servidor, ya que puede minimizar la cantidad de trfico de red entre la API y el SGBD. Las primeras API ofrecidas por diferentes productos de SGBD eran bastante diferentes unas de otras. Al igual que muchas partes del lenguaje SQL, as APl propietarias de SQL proliferaron mucho antes de que hubiera un intento de nonna lizadas. Adems, las API de SQL tienden a dejar a la vista las posibilidades subya centes del SGBD ms que el enfoque de SQL incorporado, lo que produce todava ms diferencias. No obstante, todas las APl de SQL disponibles en los productos
llamadas a fa API
CONNECT
usuario, pedidos set ... ")
contrasei\.. ,
SEND (" upda te
EXECUTE () STATUS_CHECK ()
) OK
S&LECT
("select * from oficinas ... )
EXECUTE ()
SGBD
GETROW ()
Cliente
Cliente
(101, Navarra, ... )

GETROW ()
I
API
~
- _.
API
~
Servidor
Ba~datos
(12, Castelln,... )

DISCONNECT ()
1 Programa I
1 Programa 1
SGBD
/
Figura 19.1. Empleo de un API de SQL para el acceso al SGBD. Figura 19.2. La API de SQl en una arquitectura cliente/servidor.
594
595
comerciales de SQL se basan en los mismos conceptos fundamentales que se ilustran en las figuras 19.1 y 19.2. Estos conceptos tambin se aplican a la API de ODBC y a los estndares ANSI/ISO ms recientes que se basan en ella.
Tabla 19.1,
Funciones bsicas de la API dblib {continuacin}
Funcin
Tratamiento de errores
Descripcin
La API dblib (SaL Server)

El primer producto de SGBD importante que destac su API lIamable fue SQL Server, tanto en las versiones de Sybase como en las de Microsoft. Durante muchos aos, la API llamable de SQL Server fue la nica interfaz ofrecida por estos productos. Tanto Microsoft como Sybase ofrecen ahora posibilidades de SQL incorporado y han aadido API a las que se puede hacer llamadas ms nuevas o de nivel superior, pero la API original de SQL Server sigue siendo una manera popular de tener acceso a esas marcas de SGBD. La API de SQL Server tambin proporcion el modelo para gran parte de la API para ODBC de Microsoft. SQL Server y su API tambin son un ejemplo excelente de SGBD diseado desde el comienzo alrededor de una arquitectura cliente/servidor. Por todos estos motivos, resulta til comenzar la exploracin de las API de SQL examinando la API bsica de SQL Server. La API original de SQL Server, que se denomina biblioteca de la base de datos (database library) o dblib, dispone de alrededor de cien funciones para los programas de aplicacin. La API es muy completa, pero los programas habituales s6lo utilizan una media docena de las llamadas a las funciones, que se resumen en la Tabla 19.1. Las dems llamadas proporcionan caractersticas avanzadas, mtodos alternativos de interaccin con el SGBD o versiones de llamada nica de caractersticas que, de otro modo, necesitaran varias llamadas.
Tabla 19.1. Funciones bsicas de la API dblib
dbmsghandle () dberrhandle()
Establece un procedimiento de manejo de mensajes escrito por el usuario. Establece un procedimiento de un manejo de errores escrito por el usuario.
Procesamiento del resultado de las COllsultas

Dbbind( ) dbnextrow ( ) dbnumcols () dbcolname ( ) dbcol t.ype () dbcollen() Dbdata( l dbdatlen( ) dbcanquery ( )
Enlaza una columna de resultados de la consulta con una variable del programa. Captura la siguiente fila de resultados de la consulta. Obtiene el nmero de columnas de resultados de la consulta. Obtiene el nombre de una columna de resultados de la consuha. Obtiene el tipo de datos de una columna de resultados de la consulta. Obtiene la longitud mxima de una columna de resultados de la consulta. Obtiene un puntero a un valor de datos recuperado. Obtiene la longitud real de un valor de datos recuperado. Cancela una consulta antes de que se capturen todas las filas.
Funcin
Descripcin
Tcnicas bsicas de SaL Server

Un programa sencillo de SQL Server que actualice una base de datos puede utilizar un conjunto muy pequeo de llamadas a dblib para realizar su trabajo. El programa de la Figura 19.3 implementa una aplicacin sencilla para la actualizacin de cuotas de la tabla REPRESENTANTES de la base de datos de ejemplo. Resulta idntico al programa de la Figura 17.17, pero utiliza la API de SQL Server API en lugar de SQL incorporado. La figura ilustra la interaccin bsica entre los programas y SQL Server: l. 2. 3.
(contina)
Conexi6n y desconexi6n de la base de datos

dblogin () Dbopen () dbuse( ) Dbexit()
Proporciona una estructura de datos para la informacin de inicio de sesin. Abre una conexin con SQL Server. Establece la base de datos predeterminada. Cierra la conexin con SQL Server.
Procesamiento bdsico de instrucciones

dbcmd() dbsqlexec ( ) dbresults() dbcancel ()
Pasa el texto de la instruccin de SQL a dblib. Solicita la ejecucin de un lote de instrucciones. Obtiene el resultado de la siguiente instruccin de SQL del lote. Cancela el resto del lote de instrucciones.
El programa prepara un registro de inicios de sesin, rellenando el nombre de usuario, la contrasea y cualquier otra infonnacin necesaria para conectarse con el SOBD. El programa llama a dbopen () para establecer conexin con el SOBD. Debe haber una conexin para que el programa pueda enviar instrucciones de SQL a SQL Server. El programa crea una instruccin de SQL en un bfer y llama a dbcmd () para que pase el texto de SQL a dblib. Las sucesivas llamadas a dbcmd ()
596
Capitulo 79: Las API de SOL
597
main (l
{
LQGINREC
"'loginrec;
/" estructura de datos para
,.
4. 5.
informacin de inicio de sesin "/ OBPROCESS *dbproc;

/" estructura de datos para la conexin */
char
amount_str[31]:
int
status;
/" importe introducido por el usuario (en forma de cadena de caracteres) "/ /" estado de devolucin de l . llamada a dblib */
6.
se suman al texto pasado anteriormente; no se exige que se enve una instruccin completa de SQL en cada llamada a dbcmd ( ) . El programa llama a dbsqlexec (), que da instrucciones a SQL Server para que ejecute la instruccin pasada anteriormente con dbcrod ( ) . El programa llama a dbresul ts () para determinar el xito o el fracaso de la instruccin. El programa llama a dbexi t () para cerrar la conexin con SQL Server.
Resulta instructivo comparar los programas de la Figura 19.3 y de-Ia Figura 17.17 para ver las diferencias entre el enfoque de SQL incorporado y el de dblib:
El programa de SQL o bien se conecta de manera implcita con la nica base

/* Obtiene una estructura de inicio de sesin y define un nombre de usuario y una contrasea */
lo.inree dblo.in{), DBSETLUSER{loginrec. "santi"); DBSETLPWD (1oginrec. *tigre");
(!)
/* Se conecta con SQL Server */ dbproc '" dbopen(loginrec. "-); ~
pide al usuario el importe del aumento o la disminucin de la cuota */ printf("Aumentar o disminuir en: -J; gets{amount_str);
/*
/* Pasa la instruccin de SQL a dblib */ dbcmd(dbproc, update representantes set cuota = cuota + ~ dbcmd(dbproc. amount_str); .44------------------------------'
/* pide a SQL Server que ejecute la instruccin */ dbsqlexec (dbprocJ; ~
de datos disponible (como en DB2), o incluye una instruccin de SQL incorporado para la conexin (como la instruccin CONNECT especificada por el estndar SQL2). El programa dblib se conecta con un servidor concreto de SQL Server con la llamada dbopen ( ) . La instruccin de SQL UPDATE que procesa realmente el SGBD es idntica en los dos programas. Con SQL incorporado, la instruccin forma parte del cdigo fuente del programa. Con dblib, la instruccin se pasa a la API en forma de secuencia de una o varias cadenas de caracteres. De hecho, el enfoque de dblib recuerda ms a la instruccin de SQL dinmico EXECUTE IMMEDIATE que a SQL esttico. En el programa de SQL incorporado, las variables del anfitrin proporcionan el vnculo entre las instrucciones de SQL y el valor de las variables del programa. Con d.bl ib, el programa pasa el valor de las variables al SGBD del mismo modo que pasa el texto del programa -como parte de las instrucciones de cadenas de caracteres de SQL. Con SQL incorporado, los errores se devuelven en los campos SQLCODE o SQLSTATE de la estructura SQLCA. Con dblib,la llamada dbresults () recupera el estado de cada instruccin de SQL. En general, el programa de SQL incorporado de la Figura 17.17 es ms corto y, probablemente, ms sencillo de leer. No obstante, el programa ni es e puro ni SQL puro, y hay que formar a los programadores en el empleo de SQL incorporado para que lo comprendan. El empleo de variables del anfitrin implica que las modalidades interactiva e incorporada de las instrucciones de SQL son diferentes. Adems, el programa de SQL incorporado deben procesarlo tanto el precompiladar de SQL corno el compilador de C, lo que prolonga el ciclo de compilacin. Por el contrario, el programa de SQL Server es un mero programa de e puro, aceptable directamente por el compilador de e, y no necesita tcnicas especiales de codificacin.
0
~
/* Obtiene el resultado de la ejecucin de la instruccin */ status", dbresultsldbproc); 4 if (status ! '" SUCCEED) printf(*Error durante la actualizacin.\n-); else printf("Actualizacin concluida con xito.\n");
/* Interrumpe la conexin con SQL Server */ dbexit (dbprocl; ~ exit () ;
Lotes de instrucciones
Figura 19.3:
Programa sencillo que utiliza dblib.
El programa de la Figura 19.3 en'la a SQL Server una sola instruccin y comprueba su estado. Si un programa de aplicacin debe ejecutar varias instrucciones de
598
Capitulo 79: Las AP/ de SOL
599
SQL, puede repetir el ciclo dbcmd() I dbsqlexec () I dbresults () para cada instruccin. De manera alternativa. el programa puede enviar varias instrucciones como un solo lote de instrucciones que debe ejecutar SQL Server. La Figura 19.4 muestra un programa que utiliza un lote de tres instrucciones de SQL. Al igual que en la Figura 19.3, el programa llama a dbcrnd () para pasar el texto de SQL a dbl ib. La API simplemente encadena el texto de cada llamada.
main ()
(
LOGINREC
~loginrec:
/* estructura de datos para la

/*
DBPROCESS *dbproc;
informacin de inicio de sesin */ estructura de datos para la conexin
Obsrvese que es responsabilidad del programa incluir los espacios o los signos de puntuacin necesarios en el texto transmitido. SQL Server no comienza a ejecutar las instruccioll;es hasta que el programa llama a dbsqlexec ( ) . En este ejemplo se han enviado a SQL Server tres instrucciones, por lo que el programa llama a dbresul ts ( l tres veces, una despus de otra. Cada llamada a dbresul ts () desplaza la API hasta el resultado de la siguiente instruccin del lote e indica al programa si la instruccin ha tenido xito o ha fallado. En el programa que puede verse en la Figura 19.4 el programador conoce con antelacin que hay tres instrucciones en el lote. y puede codificar las tres llamadas correspondientes a dbresul ts (). Si el nmero de instrucciones del lote no se conoce con antelacin. el programa puede llamar a dbresul ts () repetidamente hasta que reciba el cdigo de error NO_MORE_RESULTS. El fragmento de programa de la Figura 19.5 ilustra esta tcnica.
Manejo de errores
*'
/* Elimina los representantes con pocas ventas */ dbcmd{dbproc, -delete from representantes where ventas 10000.00") ;
<
El valor devuelto por la funcin dbresul ts () indica al programa si la instruccin correspondiente del lote tuvo xito o fall. Para obtener una informacin ms detallada sobre Jos fallos, el programa debe proporcionar su propia funcin de manejo de mensajes. El software de dbl ib llama de manera automtica a la funcin de manejo de mensajes cuando SQL Server encuentra un error al ejecutar instruccio-
/* Incrementa la cuota de los representantes con ventas moderadas */ dbcrnd(dbproc, update representantes set cuota cuota + 10000.00") ; dbcmd(dbproc, "where ventas <= 150000.00");
,
I 1'1
,'~
1 1:
/* Incrementa la cuota de los representantes con muchas ventas */ dbcmd(dbproc, "update representantes set cuota cuota + 20000.00"}; dbcrnd(dbproc, "where ventas> 150000.00};
/* Ejecuta instrucciones anteriormente con llamadas a dbcmd-() dbsqlexec(dbproc};
*/
/* pide a SQL Server que ejecute el lote de instrucciones */ dbsqlexec(dbproc) ;
/* Itera para comprobar el resultado de cada instruccin del lote */ while (status: dbresu1ts(dbproc) != NO_MORE_RESULTS { if (status == FAIL) goto handle_error; else printf("Instruccin ejecutada con xito.\n");
/* Comprueba el resultado de cada una de las tres
instrucciones */ if (dbresults(dbproc) if (dbresults(dbproc) if (dbresults{dbproc)
!: SUCCEED)
!= !=
goto do_error; SUCCEEO gota do_error; SUCCEED gota do_error;
/* Acabado el bucle; lote completado con xito */ printf ( "Lote completado. \n) ; exit (1;
Figura 19.4.
Empleo de un lote de instrucciones de dblib.
Figura 19.5.
Procesamiento del resultado de un lote de dblib.
600
Captulo 19: Las API de SaL
601
nes de SQL. Obsrvese que dbl ib llama a la funcin de manejo de mensajes durante el procesamiento de las llamadas a las funciones dbsqlexec () o dbresults (). antes de volver al programa (es decir, se trata de una funcin de retrollamada, a la que llama el software de SQL Server). Esto permite a la funcin de manejo de errores realizar su propio procesamiento de los errores. La Figura 19.6 muestra un fragmento de un programa de SQL Server que incluye una funcin de manejo de mensajes denominada msg_rtn (). Cuando comienza el programa, activa la funcin de manejo de mensajes llamando a rnsghandIe (). Supngase que posteriormente se produce un error, mientras SQL Server est procesando la instruccin DELETE. Cuando el programa llama a dbsqlexec ( l o a dbresults () y dblib recibe el mensaje de error de SQL Server, llama a la rutina msg_rtn () del programa y le pasa cinco parmetros:
dbproc. La conexin en la que se produjo el error. msgno. El nmero de error de SQL Server que identifica el error. msgstate. Un parmetro que proporciona informacin sobre el contexto del
/* Variables externas para guardar la informacin sobre los errores */ int errcode; /* cdigo de error guardado */ char errmsg(256]; /* mensaje de error guardado */ /* Define nuestra propia funcin de manejo de mensajes */ int mSQ_rtn(dbproc, msgno, msgstate, severity, msgtext} DBPROCESS *dbproc DBINT msgno; int msgstate; int severity; char *msgtext; extern int errcode; extern char *errmsg;
/* Imprime el nmero y el mensaje de error */ printf("*** Error: %d Message: %s\n", msgno, msgtext)
error.
severity. Un nmero que indica la gravedad del error. msgtext. Un mensaje de error correspondiente a msgno.
La funcin msg_rtn () de este programa maneja el mensaje imprimindolo y guardando el nmero de error en una variable del programa para utilizarlo ms adelante en el programa. Cuando la funcin de manejo de mensajes vuelve a dblib (que la llam), dblib completa su propio procesamiento y luego vuelve al programa con el estado FAlL. El programa puede detectar este valor de retorno y llevar a cabo ms procesamiento de errores, si lo considera adecuado. El fragmento de programa de la figura representa realmente una vista simplificada del manejo de errores de SQL Server. Adems de los errores de las instrucciones de SQL detectados por SQL Server, tambin pueden producirse errores dentro de la propia API de dblib. Por ejemplo, si se pierde la conexin de red con el servidor de SQL Server, puede que caduquen las llamadas de dbl ib mientras esperan la respuesta de SQL Server, lo que dar lugar a un error. La API maneja estos errores llamando a una funcin de manejo de errores diferente. que opera de manera muy parecida a la funcin de manejo de errores que se ha descrito aqu. Una comparacin de la Figura 19.6 con las figuras 17.10 y 17.13 ilustra las diferencias entre las tcnicas de manejo de errores de dbl ib Y de SQL incorporado: En SQL incorporado se utiliza la estructura SQLCA para marcar los errores y las advertencias al programa. SQL Server comunica los errores y las advertencias llamando a funciones especiales del programa de aplicacin y devolviendo un estado de fallo de la funcin de la API que encontr el error. En SQL incorporado el procesamiento de errores es sincrnico. La instruccin de SQL incorporado falla, el control vuelve al programa y se comprueba el valor de SQLCODE o de SQLSTATE. El procesamiento de errores de SQL Server es asncrono. Cuando una llamada a la API falla, SQL Server llama a
/* Guarda la informacin del error para el programa de aplicacin */ errcode :: msgno; strcpy(errmsg, msgtextl;
/* Vuelve a dlib para completar la llamada a la API */ return(O) ;

)
main()
(
DBPROCESS *dbproc
/* Estructura de datos para la conexin */
/* Instala nuestra propia funcin de manejo de errores */ dberrhandle(rnsg_rtn)
/* Ejecuta una instruccin DELETE */ dbcmd(dbproc, "delete from representantes where cuota <
100000.00");
dbsqlexec(dbproc); dbresults(dbprocl;
Figura 19.&.
Manejo de los errores en un programa de dblib.
602
603
la funcin de manejo de errores o de mensajes del programa de aplicacin durante la llamada a la API. Vuelve ms adelante al programa de aplicacin con un estado de error. SQL incorporado slo tiene un tipo de error y un mecanismo para comunicarlo. El esquema de SQL Server tiene dos tipos de errores y dos mecanismos paralelos. En resumen, el manejo de los errores en SQL incorporado es sencillo y claro, pero el programa de aplicacin slo puede dar un nmero limitado de respuestas cuando se produce un error. Los programas de SQL Server tienen ms flexibilidad para el manejo de los errores. No obstante, el esquema de llamadas utilizado por dblib es ms sofisticado, y aunque resulta familiar para los programadores de sistemas, puede que no lo sea para los programadores de aplicaciones.
main (J
(
LOGINREC
*loginrec;
OBPROCESS *dbproc;
char
repname(16] ;
short
repquota: repsales;
float
/, estructura de datos para la informacin de inicio de sesin */ /, estructura de datos para la conexin */ / ' ciudad para la oficina, recuperado */ /' nmero de empleado del jefe, recuperado */ / ' ventas de la oficina, recuperado */
/* Abre una conexin con SQL Server */ loginrec = dblogin():

DBSETLUSER (loginrec, santi -, ;
Consultas de SOL Server

La tcnica de SQL Server para manejar las consultas mediante programacin es muy parecida a su tcnica para manejar otras instrucciones de SQL. Para llevar a cabo las consultas. los programas envan a SQL Server una instruccin SELECT y utilizan dblib para recuperar el resultado de la consulta fila a fila. El programa de la Figura 19.7 ilustra la tcnica de procesamiento de consultas de SQL Server. 1. 2. El programa utiliza las llamadas dbcmd () y dbsqlexec () para pasar a SQL Server una instruccin SELECT y solicitar su ejecucin. Cuando el programa llama a dbresults () para la instruccin SELECT, dbl ib devuelve el estado de finalizacin de la consulta y tambin hace que el resultado de la consulta est disponible para su procesamiento. El programa llama a dbbind () una vez por cada columna de los resulta-
(loginrec. tigre-) ; dbproc = dbopen(loginrec, );

DBSETLPWD
/* Pasa la consulta a dblib y pide a SQL Server que la ejecute */ dbcmd{dbproc. select nombre, cuota. ventas fram representantes "J; dbcmd(dbproc, where ventas> cuota arder by nombre dbsqlexec{dbproc); 4
"'---0
/* Obtiene la primera instruccin del lote */ dbresults(dbproc); ~
3.
dos de la consulta, para indicar a dblib dnde debe llevar los datos de
cada columna. Los argumentos de dbbind () indican el nmero de columna, el bfer que va a recibir sus datos, el tamao del bfer y el tipo de datos esperado. El programa itera, llamando repetidamente a dbnextrow () para obtener las filas de los resultados de la consulta. La API ubica los datos obtenidos en las reas de datos indicadas en las llamadas anteriores a dbbind ( 1.
/* Enlaza cada dbbind(dbproc, dbbind(dbproc, dbbind(dbproc,
columna con una variable de este programa */ 1, NTBSTRINGBIND, 16, &nOmbrerep);~ 2, FLT4BIND, 0, &cuotarep); ~ 3, FLT4BIND, 0, &ventasrep);
o
G)
/* Itera para recuperar las filas de resultados de la consulta */ while (status = dbnextrow(dbproc) SUCCEED) {~
/* Imprime los printf("NOmbre: printf("Cuota: printf{"Venta5:
4.
5.
Cuando no quedan disponibles ms filas de resultados, la llamada a dbdevuelve el valor NO_MORE_ROWS. Si hubiera ms instrllccio nes en el lote a continuacin de la instruccin SELECT, el programa podra llamar a dbresul ts () para desplazarse a la siguiente instruccin.
nextrow ()
datos de este representante */ %5\n", nombrerepl; %f\n\n", cuotarepl; %f\n", ventasrepl;
1* Busca errores y cierra la conexin */ if (status == FAIL) (
.4t---------~@
Dos de las llamadas a dblib de la Figura 19.7. dbbind () y dbnextrow(). admiten el procesamiento de los resultados de la consulta de SQL Server. La llamada a dbbind () configura una correspondencia biunvoca entre cada columna de resultados de la consulta y la variable del programa que debe recibir los datos recuperado's. Este proceso se denomina enlace de la columna. En la figura, la pri-
printf(-Error de SQL.\n"); dbexit (dbproc); exit ();
Figura 19.7.
Recuperacin del resultado de la consulta empleando dblib.
604
605
mera columna (NOMBRE) est enlazada con un array de caracteres de 16 bytes y se devuelve en forma de cadena de caracteres terminada en un carcter NULL. La segunda y la tercera columnas, CUOTA y VENTAS, estn enlazadas con nmeros de coma flotante. Es responsabilidad del programador asegurarse de que el tipo de datos de cada col9mna de resultados de la consulta sea compatible con el tipo de datos de la variable del programa con la que est enlazada. Una vez ms, resulta til comparar el procesamiento de las consultas de SQL Server de la Figura 19.7 con las consultas de SQL incorporado de las Figuras 17.20
y 17.23:
peTara un valor cero en la variable quota_value. Obsrvese que el programa -o puede deducir de los datos recuperados si la columna CUOTA de la fila tiene realmente un valor cero, ni si es NULL. En algunas aplicaciones, el empleo de los valores de sustitucin resulta aceptable, pero en otras resulta importante poder detectar los valores NULL. Estas ltimas aplicaciones deben utilizar un esquema alternativo para la recuperacin del resultado de las consultas, que se describe en el apartado siguiente.
Recuperacin mediante punteros
SQL incorporado tiene dos tcnicas diferentes para el procesamiento de consultas -una para las consultas en una sola fila (SELECT nica) y otra para las consultas en varias filas (cursores)-. La API de dblib utiliza una sola tcnica. independientemente del nmero de filas del resultado de la consulta. Para especificar la consulta, SQL incorporado sustituye la instruccin SELECT por la instruccin SELECT nica o por la instruccin DECLARE CURSOR. Con SQL Server, la instruccin SELECT enviada por el programa es idntica a la instruccin SELECT interactiva de la consulta. Con SQL incorporado. as variables del anfitrin qne reciben el resultado de la consulta se mencionan en la clusula INTO de las instrucciones SELECT nica o FETCH. Con SQL Server, las variables que deben recibir el resultado de la consulta se especifican en las llamadas a dbbind ( ) . Con SQL incorporado, el acceso fila a fila al resultado de la..consulta lo proporcionan las instrucciones de finalidad especial de SQL incorporado (OPEN, FETCH Y CLOSE). Con SQL Server, el acceso al resultado de la consulta se realiza mediante llamadas a la funcin dblib (dbresults () y dbnextrow(), que conservan el propio lenguaje SQL ms racionalizado. Debido a su relativa simplicidad y a su parecido con la interfaz de SQL interactivo, muchos programadores encuentran la interfaz de SQL Server ms sencilla de utilizar para el procesamiento de las consultas que la interfaz de SQL incorporado.
Recuperacin de valores NULL
Con la tcnica bsica de recuperacin de datos de SQL Server. la llamada dbnextrow () copia el valor de los datos de cada columna en una de las variables del programa. Si hay muchas filas de resultados de la consulta o columnas muy largas de datos de texto, la copia de los datos en las reas de datos del programa puede crear una sobrecarga significativa. Adems, la llamada dbnextrow () careceoe un mecanismo para la entrega de los valores NULL al programa. Para resolver estos dos problemas, dbl ib ofrece un mtodo alternativo de recuperacin del resultado de las consultas. La Figura 19.8 muestra el fragmento del programa de la Figura 19.7, que se ha vuelto a escribir para que utilice este mtodo alternativo:
main( )
(
LOGINREC
*loginrec;
OBPROCESS -dbproc; char int float float "namep; citylen; *quotap; "salesp;
/ ' estructura de datos para la informacin de inicio de sesin -1 / ' estructura de datos para la conexin ' / / ' puntero a la columna de datos NOMBRE "1 / ' longitud de la columna de datos NOMBRE *1 /' puntero para la columna de datos CUOTA ,/ / ' puntero a la columna de datos VENTAS ' /
Las llamadas dbnextrow() y"dbbind() que pueden verse en la Figura 19.7 proporcionan una manera sencilla de recuperar el resultado de la consulta, pero no incorporan los valores NULL. Cuando una fila recuperada por dbnextrow () incluye una columna con un valor NULL, SQL Server sustituye el valor NULL por un valor de sustitucin de los valores NULL. De manera predeterminada, SQL Server utiliza cero corno valor de sustitucin de los tipos de datos numricos, una cadena de caracteres de espacios en blanco para las cadenas de caracteres de longitud fija y una cadena de caracteres vaca para las cadenas de caracteres de longitud variable. El programa de aplicacin puede modificar el valor predeterminado para cualquier tipo de datos mediante una llamada a la funcin dbsetnull () de la API. En el programa que puede verse en la Figura 19.7, si una de las oficinas tuviera un valor NULL en su columna CUOTA, la llamada dbnextrow () de esa oficina recu-
1" Abre una conexi6n con SQL Sexver "/ loginrec = dblogin(); OBSETLUSER (loginrec, santi) ; OBSETLPWO (loginrec, "tigre"); dbproc = dbopen(loginrec, .0);
/" Pasa la consulta a dblib y pide a SQL Server para que la ejecute */
Figura 19.8.
Recuperacin mediante la funcin dbdata{). (Contina.)
606
607
4.
dbcmd(dbproc, "select nombre, cuota, ventas fraro representantes "); dbcmd(dbproc, where ventas> cuota arder by nombre "j; dbsqlexec(dbproc);
/* Llega a la primera instruccin del lote */
5.
'4~--------------~
dbresults(dbproc); /* Recupera la nica fila de resultados de la consulta */ while (status = dbnextrow(dbproc) SUCCEED) ('4~----------~~
Si una columna contiene datos de longitud variable, como los elementos de datos VARCHAR, el programa llama a dbdatlen () para averiguar la Ion. gitud de ese elemento de datos. Si una columna tiene un valor NULL, la funcin dbdata () devuelve un puntero para valores null (O), y dbdatlen () devuelve O como longitud del elemento. Estos valores de devolucin proporcionan al programa una manera de detectar y responder a los valores NULL en los resultados de las consultas.
==
/* consigue fila * I nombrep cuotap ventasp lonnombre
la direccin de cada elemento de datos de esta
dbdata(dbproc, 1); dbdata{dbproc, 2); _ dbdata{dbproc. 3); dbdatlen{dbproc, 1); 4
:~========::==========~
__(2)
~
El programa de la Figura 19.8 es ms enrevesado que el de la Figura 19.7. En general, resulta ms sencillo utilizar la funcin dbbind () que el enfoque dbdata ( ) a menos que el programa necesite manejar valores NULL o un gran volumen de resultados de la consulta.
Recuperacin aleatoria de filas
/* Copia el valor de NOMBRE en nuestro propio bfer y 10 termina con un valor nu11 */ strncpy{bufnombre, nombrep, lonnombre); *(bufnombre + lonnombre) = (char) O;
/* Imprime los datos de este representante */ printf("Nombre; 's\n~, bufnombre); i f (cuotap == O) .. printf(~La cuota es NULL_\n~); else printf("Cuota; 'f\n-, *cuotap); printf-Ventas; 'f\n-, *ventasp);
/* Comprueba la terminacin con xito */ if (status ~= FAIL) printf("ErrOr de SQL.\n"); dbexit(dbproc) ; exitO;
Figura 19.8.
Recuperacin mediante la funcin dbdata ). (Continuacin.)
1.
2. 3.
El programa enva la consulta a SQL Server y utiliza dbresul ts () para tener acceso al resultado, como hace para cualquier instruccin de SQL. No obstante, el programa no llama a dbbind () para enlazar las columnas de resultados de consulta con las variables del programa. El programa llama a dbnextrow () para desplazarse, fila a fila, por los resultados de la consulta. Por cada columna de cada fila, el programa llama a dbdata () para obtener .un puntero hacia el valor de los datos de la columna. El puntero seala a una ubicacin de los bferes internos de dbl ib.
Los programas procesan generalmente los resultados de las consultas de SQL Server desplazndose por ellos secuencialmente mediante la llamada a dbnextrow ( ) . Para la exploracin de aplicaciones. dbl ib tambin proporciona un acceso aleatorio limitado a las filas de resultados de la consulta. Los programas deben permitir de manera explcita el acceso aleatorio a las filas de resultados de las consultas activando una opcin de dblib. La llamada a dbgetrow () puede utilizarse entonces para recuperar una fila a partir de su nmero de fila. Para incorporar la recuperacin aleatoria de filas, dbl ib almacena las filas de resultados de las consultas en un bfer interno. Si los resultados de la consulta caben totalmente dentro del bfer de dblib, dbgetrow () admite la recuperacin aleatoria de cualquier fila. Si los resultados de la consulta superan el tamao del bfer, slo se almacenan las filas iniciales de los resultados de la consulta. El programa puede recuperar de manera aleatoria esas filas, pero una llamada a dbnextrow () que intente recuperar una fila ms all del final del bfer devolver la condicin especial de error BUF_FULL. El programa debe descartar entonces;algunas de las filas guardadas del bfer. empleando la llamada a dbclrbuf (), para hacer sitio para la fila nueva. Una vez que se ha descartado una fila, no puede volver a recuperare con la funcin dbgetrow (). Por tanto, dblib admite la recuperacin aleatoria de resultados de la consulta dentro de una ventana limitada, dictada por el tamao del bfer de filas, como puede verse en la Figura 19.9. El programa puede especificar el tamao del bfer de filas de dblib llamando a la rutina dbsetopt () de dblib. El acceso aleatorio proporcionado por dbgetrow() es parecido a,los cursores de desplazamiento incorporados por varios productos de SGBD y especificados por el estndar de SQL2. En ambos casos se admite la recuperacin aleatoria mediante el nmero de fila. No obstante, los cursores de desplazamiento son punteros autnticos dentro del conjunto completo de resultados de la consulta; puede abarcar desde la primera a la ltima fila, aunque el resultado de la consulta contenga millares de filas. Por el contrario, la funcin dbgetrow () slo proporciona el acceso aleatorio dentro de una ventana limitada. Esto resulta adecuado para las apli-
60S
Captulo 79: Las API de SaL.
609
Resultados
de la consulta
Ya procesados
Bfer de fijas dblib_---
>El el bfer
dbgetrow (
dbnextrow
)
I(
I

I
,,
dbnextrow ( ) ~
dbgetrow ( ) dbnextrow I( )
,/ ,/
Desplazados por dbnextrow ()
aplicaba a los resultados de la consulta dentro de la API de dbl ib, no a las filas de las tablas reales de las bases de datos. Las versiones posteriores de SQL Server (y de Sybase) aadieron el soporte completo de los cursores estndar de SQL, con sus instrucciones de SQL asociadas DECLARE/OPEN/FETCH/CLOSE. Los cursores operan realmente dentro de los procedimientos almacenados de Transact-SQL, y la accin de la instruccin FETCH es capturar los datos de la base de datos en los procedimientos almacenados para su procesamiento, no recuperarlos realmente en el programa de aplicacin que ha llamado al procedimiento almacenado. Los procedimientos almacenados y su operativa en los diferentes productos populares de SGBD de SQL se estudian en el Captulo 20.
Todava fuera del bfer
Consultas dinmicas
En los ejemplos de programas que hemos visto hasta ahora en este captulo, las consultas que haba que realizar se conocan con antelacin. Las columnas de resultados de la consulta podan enlazarse con variables del programa mediante llamadas explcitas a dbbind () incluidas en el programa. La mayor parte de los programas que utilizan SQL Server pueden escribirse empleando esta tcnica. (Este enlace esttico con las columnas se corresponde con la lista fija de variables del anfitrin empleada en la instruccin FETCH de SQL esttico de SQL incorporado estndar, que se describe en el Captulo 17.) Si la consulta que debe ejecutar el programa no se conoce en el momento en que se escribe el programa, el programa no puede incluir en su texto las llamadas a dbbind (). En su lugar, el programa debe pedir a dblib una descripcin de cada columna de resultados de la consulta, empleando funciones especiales de ]a API. As, el programa puede enlazar sobre la marcha las columnas con las reas de datos que asigna en el momento de la ejecucin. (Este enlace dinmico de las columnas se corresponde con el uso de la instruccin DBNUMCOLS ( ) de SQL dinmico y de SQLDA, de SQL dinmico incorporado, tal y como se describe en el Captulo 18). La Figura 19.10 muestra un programa interactivo de consultas que ilustra la tcnica de dblib para el manejo de las consultas dinmicas. El programa acepta un nombre de tbla introducido por el usuario y luego pide al usuario que escoja las columnas que se van a recuperar de esa tabla. Cuando el usuario selecciona las columnas, el programa crea una instruccin SELECT y luego utiliza estas etapas para ejecutar la instruccin SELECT y mostrar los datos de las columnas seleccionadas: 1. El programa pasa la instruccin SELECT generada a SQL Server mediante la llamada a dbcmd (), solicita su ejecucin con la llamada a dbsqlexec () y llama a dbresults () para que desplace la API hasta los resultados de la consulta, como hace para todas las consultas. El programa llama a dbnumcols () para averiguar el nmero de columnas de los resultados de la consulta generadas por la instrucci6n SELECT.
dbnexcrow ( ) I
Figura 19.9.
Recuperacin aleatoria de filas con dblib.
.'
caciones limitadas de exploracin, pero no puede ampliarse fcilmente a las consultas de gran tamao.
Actualizaciones posicionadas
En los programas de SQL incorporado. los cursores proporcionan un enlace directo, ntimo, entre el programa y el procesamiento de consultas de SGBD. El programa se comunica con el SaBD fila a fila cuando utiliza la instruccin FETCH para recuperar el resultado de la consulta. Si la consulta es una consulta sencilla sobre una sola tabla, el SGBn puede mantener una correspondencia directa eotre la fila en curso de los resultados de la consulta y la fila correspondiente de la base de datos. Mediante esta correspondencia el programa puede utilizar las instrucciones para actualizaciones posicionadas (UPDATE . . . WHERE CURRENT OF y DELETE . . . WHERE CURRENT OF) con el fin de modificar o eliminar la fila en curso de los resultados de la consulta. El procesamiento de consultas de SQL Server utiliza una conexi6n asncrona mucho ms independiente entre el programa y el SGBD. En respuesta a los lotes de instrucciones que contienen una o ms instrucciones SELECT SQL Server enva el resultado de la consulta al software de dblib, que las maneja. La recuperacin fila a fila la manejan las llamadas a la API de dblib, no las instrucciones del lenguaje SQL. En consecuencia, las primeras versiones de SQL Server no podan albergar las actualizaciones posicionadas, ya que su concepto de fila en curso se
2.
610
611
main( )
(
/* Se trata de un programa sencillo de consultas de propsito general. pide al usuario el nombre de una tabla y luego le pregunta las columnas de la tabla que hay que incluir en la consulta. Una vez completas las selecciones del usuario, el programa ejecuta la consulta solicitada y muestra el result.ado.
/* Pregunta al usuario la tabla que hay que consultar */ printf("*** Programa para miniconsultas ***\n"); printf("Introduzca el nombre de la tabla para la consulta: gets (querytbl) ;
"J;
/* Inicia la instruccin SELECT en el bfer */ strcpy(stmbuf, select -);
"'
LOGINREC
*loginreci
'"
'" '"
DBPROCESS *dbproc; char char char

int int int stmbuf(2001];
querytbl[32):
querycol [32] ;
status; f~rst col
O,
colcount;
int char
i; inbuf[lOl];
*tem_name[lOOl:
char
'" '" '" '" '" '" '" '"
char
*item_data[lOO) ;
'"
'"
'"
int
item _type[lOO];
char int
*address; length;
'"
estructura de datos para la informacin del inicio de sesin */ estructura de datos para la conexin "" texto de SQL que hay que ejecutar */ tabla especificada por el usuario */ columna especificada por el usuario */ estado de devolucin de dblib */ es sta la primera columna escogida? * / nmero de columnas de los resultados de la consulta */ ndice de las columnas */ datos introducidos por el usuario */ array para realizar el seguimiento de los nombres de columna */ array para realizar el seguimiento de los bferes de columnas */ array para realizar el seguimiento de los tipos de datos de las columnas */ direccin del bfer de la columna actual */ longitud del bfer de la columna actual */
/* consulta el catlogo del sistema de SQL Server para obtener el nombre de las columnas */ ~ dbcmd(dbproc, select name from syscolumns "); dbcmd(dbproc, "where id == (select id from sysobjects "); dbcmd(dbproc, "where type == 'U' and name == "l; dbcmd(dbproc, querytbl}; dbcmd(dbproc, --); dbsqlexec(dbproc);
/* Procesa el resultado de la consulta */ dbresults(dbproc); dbbind(dbproc, querycol); while (status == dbnextrow(dbproc) SUCCEED) ( printf("Se incluye la columna %s (s/n)? ", querycol); gets(inbuf); if (inbuf[O] ==== 'y') { /* El usuario quiere la columna; hay que aadirla a la lista de seleccin */ if (first_col++ > O) strcat(stmbuf, -); strcat(stmbuf, querycol};
/* Concluye la instruccin SELECT con una clusula FRDM */ strcat(stmbuf, -from -; strcat(stmbuf, querytb1);
/- Ejecuta la consulta y se desplaza al resultado de la consulta */ dbcmd (dbproc, s dbsqlexec (dbproc); dbresults(dbproc);
tmbuf:i'=~4~~~=~~~==~==~;;;;;~;==_ _0
/* Abre una conexin con SQL Server */ loginrec == dblogin(); DBSETLUSER{loginrec, santi-); DBSETLPWD (loginrec, -tigre"); dbproc '" dbopen(loginrec, "-;
/- pide a dblib que describa cada columna, le asigne memoria y la enlace */ colcount == dbnumcols(dbproc); 4 ~
Figura 19.10.
Empleo de dblib para consultas dinmicas. (Contina.)
Figura 19.10.
Empleo de dblib para consultas dinmicas. (Continuacin.)
612
613
for
(i '" o; i < colcount; i++) ( item_nameli] '" dbcolname(dbproc.
i);
..
CV
type '" dbcoltype(dbproc. swi tch (type I (
i);
case NTBSTRINGBIND: /" Datos de texto -- simplemente los muestra *1 puts(item_data[i)) ; break;
case SQLCHAR:
case SQLTEXT: case SQLDATETIHE: length '" dbcollen(dbproc. il + 1;

item_data!i] '" address '" malloc(lengeh);
icern_type[il = NTBSTRINGBIND; dbind(dbproc, i, NTBSTRINGBIND, length,

break;
addreSS};~
-0
case INTBIND: /" Datos enteros de cuatro bytes -- los convierte y los muestra "/ printf(-Uf-, "double *) (iteIn.-data[illl); break;
case SQLINTl;
case SQLINT2: case SQLINT4: item_data!i]
case FLT8BIND: /* Datos de coma flotante -- los convierte y los muestra "/ printf(-Uf", *({double *l (item_data[ij))); break;
address = rnalloc(sizeof(long)):
sizeof(longl, address); printf("\nFinal de los datos.\n"l;
z
itern_type[i] break; case SQLFLT8: case SQLMONEY:
INTBrNo; dbbind(dbproc, i, INTBrND,
address = malloc(sizeof(double)); FLT8BIND; dbbind(dbproc. i, FLT8BIND, sizeof(double), address); break; item_data[i]
itern_type[i}
/* Limpia el almacenamiento asignado "/

for
}
(i = O; i < colcount; free(iteIn.-data(i]);
i++)
dbexi t (dbproc) ; exit (); Captura y muestra las filas de los resultados de la consulta */ while (status: dbnextrow(dbproc) SUCCEED) ( 4
/*
==
Figura 19.10.
Empleo de dblib para consultas dinmicas. (Continuacin.)
/* Itera para imprimir los datos de cada columna de la fila */ printf(-\n-); for (i = O; i < colcount; i++) (
3.
Halla SQLVAR de esta columna; imprime la etiqueta de la columna */ printf("Columna nmero 'ld (%s): ", i+l, item_name(i);
/*
4.
5.
/* Maneja cada tipo de datos por separado */
cada columna el programa llama a dbcolname () para averiguar el nombre de la columna, a dbeol type () para averiguar su tipo de datos, y a dbcollen () para averiguar su longitud mxima. El programa asigna un bfer para que reciba cada columna de resultados de la consulta y llama a dbbind () para que enlace cada columna con su bfer. Cuando se han enlazado todas las columnas, el programa llama a dbnextrow () repetidamente para recuperar cada fila de resultados de la consulta.
~ara
switch(item_type[ij)
Figura 19.10.
Empleo de dblib para consultas dinmicas. (Continuacin,)
El programa basado en dblib de la Figura 19.10 desempea exactamente la misma funcin que el programa de SQL dinmico incorporado de la Figura 18.9. Resulta instructivo comparar los dos programas y las tcnicas que utilizan:
614
615
Tanto para SQL incorporado como para dblib el programa crea una instruccin SELECT en sus bferes y la remite al SGBD para su procesamiento. Con SQL dinmico, la instruccin especial PREPARE maneja esta tarea; con la API de SQL Server se utilizan las funciones estndar dbcmd () y dbsqlexec ().
Para as dos interfaces el programa debe solicitar al SGBD una descripcin de las columnas de resultados de la consulta. Con SQL dinmico esta tarea la maneja la instruccin especial DBNUMCOLS ( ) y la descripcin se devuelve en una estructura de datos de SQLDA. Con dblib la descripcin se obtiene llamando a las funciones de la API. Obsrvese que el programa de la Figura 19.10 conserva sus propios arrays para realizar el seguimiento de la informacin de las columnas. Para las dos interfaces el programa debe recibir el resultado de la consulta y enlazar cada columna con esas ubicaciones del bfer. Con SQL dinmico, el programa enlaza las columnas ubicando las direcciones del bfer en las estructuras SQLVAR de SQLDA. Con SQL Server, el programa utiliza la funcin dbbind () para enlazar las columnas. Para las dos interfaces los resultados de la consulta se devuelven fila a fila en los bferes del programa. Con SQL dinmico, el programa recupera las filas de los resultados de la consulta mediante una versin especial de la instruccin FETCH que especifica la SQLDA. Con SQL Server, el programa llama a dbnextrow () para recuperar las filas.
En general, la estrategia empleada para manejar las consultas dinmicas es muy parecida para las dos interfaces. La tcnica de SQL dinmico utiliza instrucciones especiales y estructuras de datos que son privativas de SQL dinmico; son bastante diferentes 'de las tcnicas empleadas para las consultas de SQL esttico. Por el contrario, las tcnicas de dblib para las consultas dinmicas son bsicamente las mismas que las empleadas para las dems consultas. Las nicas caractersticas aadidas son las funciones dblib que devuelven la informacin sobre las columnas de los resultados de las consultas. Esto tiende a hacer el enfoque de la API llamable ms sencillo de comprender por los programadores de SQL menos experimentados.
m:1s se ejecutaran con varias marcas de SGBD, tenan que proporcionar un mdulo de interfaz de la base de datos (generalmente denominado controlador) diferente escrito especialmente para cada una. Cada programa de aplicacin que quisier~ ofrecer acceso a varias bases de datos tena que proporcionar un conjunto de controladores. La solucin de Microsoft .a este problema fue la creacin de ODBC como interfaz de acceso a las bases de datos uniforme y estandarizada e incorporarla en el sistema operativo Windows. Para los desarrolladores de aplicaciones, ODBC elimin la necesidad de escribir controladores personalizados para las bases de datos. Para los fabricantes de bases de datos, ODBC ofreci una manera de conseguir soporte de un rango ms amplio de programas de aplicacin.
La estandarizacin de la interfaz en el nivel de llamadas (CLI)

ODBC ya hubiera sido importante slo como estndar de Microsoft. Sin embargo, Microsoft trabaj para hacerla tambin un estndar independiente del fabricante. Una asociacin de fabricantes de bases de datos denominada Grupo de Acceso a SQL (SQL Access Group) trabajaba en la normalizacin de los protocolos cliente/servidor para el acceso remoto a las bases de datos aproximadamente en la misma poca que el desarrollo original de ODBC por Microsoft. Microsoft persuadi al grupo de acceso a SQL para que ampliara sus objetivos y adoptara ODBC como estndar para el acceso a las bases de datos independiente de los fabricantes. La direccin del grupo de acceso a SQL acab transfirindose al consorcio europeo X/Open, otra organizacin de normalizacin, como parte de sus estndares globales para un entorno comn de aplicaciones (Common Application Environment, CAE). Con la creciente popularidad de las API en el nivel de llamadas para el acceso a las bases de datos, los grupos oficiales de normas de SQL acabaron centrando su atencin en la normalizacin de este aspecto de SQL. El estndar XlOpen (basado en los primeros trabajos en ODBC de Microsoft) se torn como punto de partida y se modific ligeramente para crear un estndar oficial ANSI/ISO. El estndar de la interfaz en el nivel de llamadas para SQL (SQUCall-Level Interface, SQUCL!) resultante se public en 1995 como ANSI/ISO/IEC 9075-3-1995. Con unas pocas modificaciones, SQUCL! se transform en la Parte 3 del estndar SQL:1999. Microsoft ha modificado ODBC para que se adapte al estndar oficial SQU CL!. El estndar CL! forma, ms o menos, el nivel central de la revisin ODBC 3 de Microsoft. Otras posibilidades de nivel superior de ODBC 3 superan la especificacin de CL! para ofrecer ms funcionalidad API y tratar con los problemas especficos de la gestin de ODBC corno parte del sistema operativo Windows. En la prctica, las posibilidades del nivel central de DBC y la especificacin SQU CL! forman el estndar real de las API lIamables. Debido a sus importantes ventajas tanto para los desarrolladores de aplicaciones como para los fabricantes de bases de datos, DBC/CLI se ha convertido en un estndar muy incorporado. Prcticamente todos los sistemas de bases de datos
ODBC y el estndar SQL/CLI

La conectividad abierta de bases de datos (Open Database Connectivity, ODBC) es una familia de varias API llamables, independiente de las bases de datos, que fue desarrollada originalmente por Microsoft. Aunque Microsoft desempea un papel importante como' fabricante de. software de bases de datos, su desarrollo de ODBC vino motivado por su papel como' uno de los principales desarrolladores de sistemas operativos. Microsoft deseaba hacer ms fcil para los desarrolladores de aplicaciones para Windows la incorporacin del acceso a las bases de datos. Pero las grandes diferencias entre los diferentes sistemas de bases de datos y sus API lo hacan muy"difciL Si Jos desarrolladores de aplicaciones deseaban que los progra-
616
Captulo 19: Las AP/ de SOL
617
basados en SQL ofrecen una interfaz ODBe/eLI entre las interfaces que incorporan. Algunas marcas de SGBD han adoptado incluso DBe/eLI como API estndar de la base de datos. Millares de programas de aplicacin incorporan ODBCI eLI, incluidos todos los principales paquetes de herramientas de programacin, herramientas de procesamiento de consultas y de formularios y redactores de informes. as como el software de productividad popular, como las hojas de clculo y los programas de grficos. El estndar SQL/CLI incluye alrededor de cuarenta llamadas diferentes a la API, que se resumen en la Tabla 19.2. Las llamadas ofrecen una facilidad global para el establecimiento de conexiones con los servidores de bases de datos, la ejecucin de instrucciones de SQL, la recuperacin y el procesamiento del resultado de las consultas y el manejo de los errores en el procesamiento de la base de datos. Ofrecen lodas las posibilidades disponibles mediante la interfaz de SQL incorporado del estndar, incluidas las posibilidades de SQL esttico y de SQL dinmico.
Tabla 19.2.
Fvnciones de la API SQljCLI (continuacin)
Funcin Gestin de transacciones SQLEndTran ( ) SQLCancel () Manejo de parmetros SQLBindParam () SQLPararnData () SQLPutData ()
Descripcin
Concluye una transaccin de SQL. Cancela la ejecucin de una instruccin de SQL.
Enlaza la ubicacin del programa con el valor de un parmetro. Procesa valores diferidos de parmetros. Proporciona valores diferidos de parmetros o una parte del valor de una cadena de caracteres.
Procesamiento del resultado de las consultas Tabla 19.2.

Funciones de la API SQl/CL1
SQLSetCursorName() SQLGetCursorName() SQLFetch () SQLFetchScroll () SQLCloseCursor() SQLGetData()
Define el nombre de un cursor. Obtiene el nombre de un cursor. Captura una fila de resultados de la consulta. Captura una fila de resultados de la consulta con desplazamiento. Cierra un cursor abierto. Obtiene el valor de una columna de resultados de la consulta.
Funcin
Descripcin
Gestin de recursos y de conexiones SQLAllocHandle () SQLFreeHandle() SQLAllocEnv( ) SQLFree::nv ( ) SQLAllocConnect() SQLFreeConnect () SQLAllocStmt () SQLFreeStmt () SQLConnect () SQLDisconnect () Asigna los recursos para el entorno, la conexin, los descriptores o la instruccin. Libera los recursos asignados previamente. Asigna recursos para un entorno de SQL. Libera los recursos para un entorno SQL. Asigna recursos para una conexin a la base de datos. Libera los recursos para una conexin a la base de datos. Asigna recursos para una instruccin de SQL. Libera los recursos p'ara una instruccin de SQL. Establece una conexin con la base de datos. Concluye una conexin con la base de datos ya establecida.
Descripcin del resultado de la consulta SQLNumResultCols() sQLDescribeCol() SQLColAttribute() SQLGetDescField() SQLSetDescField() SQLGetDescRec ( ) sQLSetDescRec() Determina el nmero de columnas del resultado de la consulta.
D~scribe una sola columna de resultados de la consulta.
Obtiene los atributos de una columna de resultados de la consulta. Obtiene el valor de un campo descriptor. Define el valor de un campo descriptor. Obtiene valores de un registro descriptor. Define los valores de un registro descriptor.. Copia los valores del rea descriptora.
Ejecucin de instrucciones SQLExeCDirect () SQLPrepare ( ) SQLExecute () SQLRowCount () Ejecuta directamente una instruccin de SQL. Prepara una instruccin de SQL para su ejecucin posterior. Ejecuta'una instruccin de SQL preparada anteriormente. Consigue el nmero de filas afectadas por la ltima instruccin de SQL. (contina)
SQLcopyDesc() Manejo de errores SQLError () SQLGetDiagField() SQLGetDiagRec ()
Obtiene la informacin sobre los errores. Obtiene el valor de un campo de registros de diagnstico. Obtiene el valor del registro de diagnstico. (contina)
618
619
Tabla 19.2.
Funciones de la API SOl/eU (continuacin)
Funcin
Gesti6n de atributos
SQLSetEnvAtt.r( )
Descripcin
char char
"nombre_usuario "contra_usuario
"jase" ; xyz" ;
' nombre de usuario para la

conexin "1
Define el valor de los atributos de un entorno de SQL.

Recupera el valor de los atributos de un entorno de SQL.
char char
cadena_importe[31); buf_instruc[128) ;
sQLGetEnvAttr ()
SQLSetStrntAttr() SQLGetStrntAttr()
Define el rea descriptora que hay que utilizar para una instruccin de SQL.
Obtiene el rea descriptora para una instruccin de SQL.
- contrasea del usuario para la conexin "1 ' importe introducido por el usuario '*1 - bfer para la instruccin
SQL *1
1" Asigna controladores para el entorno SQL, la conexin y la

instruccin *1 SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env_hdl); SQLAllocHandle{SQL_HANDLE_DBC, env_hdl, &conn_hdll; SQLAllocHandle{SQL_HANDLE_STMT, conn_hdl, &stmt_hdll;
Gesti6n de controladores
SQLDataSources() sQLGetFunctions{)
SQLGetlnfo()
Obtiene una lista de los servidores de SQL disponibles. Obtiene la informacin sobre las caractersticas incorporadas por la implementacin de SQL.
Obtiene informacin sobre las caractersticas incorporadas por la implementacin de SQL.
1'* Conecta con la base de datos, pasando el nombre del servidor, el usuario y la contrasea '*1 1'* SQL_NTS indica una cadena de caracteres terminada en un
carcter NULL en lugar de pasar su longitud "1 SQLConnect(conn_hdl, nombre_serv, SQL_NTS, Nombre_usuario. SQL_NTS, Contra_usuario, SQL_NTS);
1* Pregunta al usuario el importe del incremento o la disminucin
El sencillo programa de eL! de la Figura 19.11 repite el programa de as Figuras 19.3 y 17.14, pero utiliza las funciones CL!. Sigue la secuencia de etapas utilizada por la mayor parte de las aplicaciones basadas en CLI: 1. El programa se conecta con la eL! y le asigna estructuras de datos para que las utilice.
de la cuota "1 printf("En cunto se aumenta o disminuye la cuota?: gets(cadena_importe);
");
' Programa para aumentar las cuotas en un importe especificado por el usuario , ' archivo de cabecera con linclude <sqlcli.h>
las definiciones de la CLl , main ()
[
1'* Monta la instruccin UPDATE y pide al SGBD que la ejecute '*1 strcpy(buf_instruc, "update representantes set cuota cuota + O); strcat(buf_inst~uc, cadena_importe); status = SQLExecDirect{strnt_hdl, stmt_buf, SQL_NTS) i f (status) printf("Error durante la actualizacin\n~); else printf(~Actualizacin concluida con xito.\n"); 1'* Compromete las actualizaciones y se desconecta del servidor de bases de datos '*1
SQLEndTran(SQL_HANDLE_ENV, SQLDisconnect(conn_hdl); env_hdl. SQL_COMMIT);
SQLHENV SQLHD8C SQLHSTMT SQLRETURN char
env_hdl; conn_hdl; stmt_hdl; status; "nombre serv "demo" ;
' controlador del entorno SQL , ' controlador de la conexin , , controlador de instrucciones ' , estado de retorno de la rutina CLl , , nombre del servidor '
1'* Desasigna los controladores y sale '*1

SQLFreeHandle(SQL_HANDLE_STMT, stmt_hdl); SQLFreeHandle(SQL_HANDLE_DBC, conn_hdl); SQLFreeHandle(SQL_HANDLE_ENV, env_hdl); exit () ;
Figura 19.11.
Programa sencillo que emplea SOljClI. (Contin_a.)
Figura 19.11.
Programa sencillo que emplea SOLJCLI. (Continuacin.)
620
2. 3. 4. 5.
6.
Captulo 19: Las AP/ de SOL
621
Se conecta con un servidor de bases de datos concreto. El programa crea las instrucciones de SQL en sus bferes de memoria. Realiza las llamadas a eL! para solicitar la ejecucin de l,!s instrucciones y comprobar su estado. Tras su finalizacin con xito hace una llamada a eL! para comprometer la transaccin de la base de datos. Se desconecta de la base de datos y libera sus estructuras de datos.
Todas las rutinas de eLI devuelven un cdigo de estado que indica la finalizacin con xilo de la rutina, o algn tipo de error o de advertencia sobre su ejecucin. El valor de los cdigos de estado de devolucin de eLI se resumen en la Tabla 19.3. Algunos de los ejemplos de programas de este Libro omiten la comprobacin de los cdigos de estado de devolucin para abreviar el ejemplo y centrarse en las caractersticas concretas que se ilustran. No obstante, los programas de pro~ duccin que llaman a las funciones CLI deben comprobar siempre el valor de devolucin para asegurarse de que la funcin se complet con xito. Los nombres de las constantes simblicas de los cdigos de estado de devolucin y otros muchos valores, como los cdigos de tipos de datos y los cdigos de identificacin de las instrucciones, suelen definirse en archivos de encabezado que se incluyen al comienzo de los programas que utilizan la CL!.
con el entorno SQL para realizar un seguimiento de los diferentes programas de aplicacin que lo utilizan. Conexin con SQL. Conexin lgica con un servidor de bases de datos Concreto. Conceptualmente, la CLI permite que se conecte un solo programa de aplicacin con varios servidores de bases de datos diferentes de manera simultnea. Cada conexin tiene su propia estructura de datos, que la CLl utiliza para realizar un seguimiento del estado de conexin. Instruccin SQL. Instruccin de SQL que el servidor de bases de datos debe procesar. La instruccin puede desplazarse por varias etapas de procesamiento, mientras el SGBD la prepara (la compila), la ejecuta, procesa los errores y, en el caso de las consultas, devuelve el resultado al programa de aplicacin. Conceptualmente, el programa de aplicacin puede tener varias instrucciones de SQL que se desplacen en paralelo por estas etapas de procesamiento. Cada instruccin tiene su propia estructura de datos, que la CLI utiliza para seguir su progreso. La CLI utiliza una tcnica utilizada frecuentemente por los sistemas operativos modernos y los paquetes de bibliotecas para gestionar estas entidades conceptuales. Se asocia un puntero simblico, denominado controlador. con el entorno global SQL, con una conexin de SQL con un servidor de bases de datos concreto y con la ejecucin de una instruccin de SQL. El controlador identifica un rea de almacenamieolo gestionada por la propia CL!. En cada llamada CL! se pasa algn tipo de controlador como uno de los parmetros. Las rutinas CLI que gestionan los controladores se muestran en la Figura 19.12. Los controladores se crean (asignan) empleando la rutina CLI SQLAllocHandIe (l. Uno de los parmetros de la rutina indica a la CLI el tipo de controlador que hay que asignar. Otro parmetro devuelve el valor del parmetro al programa de aplicacin. Una vez asignado, se pasa el controlador a las rutinas CLI posteriores para.mantener un contexto para las llamadas a la eLI. De este modo, las diferentes hebras de ejecucin dentro del programa o los diferentes programas que se ejecutan de manera simultnea (los procesos) pueden establecer sus propias conexiones con la eLI y mantener sus propios contextos, independientes entre s. Los controladores tambin permiten que un solo programa tenga varias conexiones CLI con servidores de bases de datos diferentes, y que se procese en paralelo ms de una instruccin de SQL. Cuando ya no se necesita un controlador, la aplicacin llama a SQLFreeHandle (> para indicrselo a la CL!. Adems de las rutinas de gestin de controladores de propsito general, SQLA110cHandle () y SQLFreeHandle (), la especificacin CLI incluye rutinas diferentes para crear y liberar controladores de entornos, conexiones o instrucciones. Estas rutinas (SQLAllocEnv(), SQLAllocStmt (>, etc.) formaban parte de la API original de DBC y siguen incluyndose en las implementaciones actuales de DBC en aras de la compatibilidad con versiones anteriores. No obstante, Microsoft ha indicado que las rutinas generales para gestin de controladores son ahora las funciones ODBC preferidas, y puede que las rutinas especficas se descarten en futuras versiones de DBC. De cara a una portabilidad mxima entre plataformas es mejor utilizar las rutinas de propsito generaL
Estructuras
eL/
La CL! gestiona las interacciones entre los programas de aplicacin y las bases de datos incorporadas mediante una jerarqua de conceptos, que se refleja en una jerarqua de estructuras de datos de CLL Entorno de SQL. Entorno de mximo nivel dentro del que tiene lugar el acceso a las bases de datos. La CL! emplea la estructura de datos asociada
Tabla 19.3. Cdigos de estado de devolucin de CL!
Valor de devolucin de. eLI
Significado
o
1
Instruccin completada con xito. Finalizacin con xito, pero con advertencias. No se han hallado datos (al recuperar el resultado de la consulta). Hacen falta datos (falta un parmetro dinmico necesario). Error durante la ejecucin de la instruccin de SQL. Error -se ha proporcionado un controlador no vlido en la llamada.
100
99
-1
-2
622
Captulo 19: Las AP/ de SaL
623
Entorno SOL
/* Asigna un controlador para emplearlo en llamadas posteriores a eL! */
la
short SQLAllocHandle
short HdI Type. long inHdl,
long "rtnHl)
/* IN: cdigo de tipo entero de controlador .. / 1* IN: controlador de entorno o de conexin */ 1* OUT: controlador devuelto */
/* Libera un controlador asignado anteriormente por
El entorno de SQL es el contexto de nivel superior utilizado por los programas de aplicacin en sus llamadas a la CL!. En las aplicaciones de una sola hebra suele haber un entorno de SQL para todo el programa. En las aplicaciones con varias hebras, puede haber un entorno de SQL por hebra o un entorno global de SQL, segn la arquitectura del programa. La CL! permite, en teora, varias conexiones, incluso con diferentes servidores de bases de datos, desde un mismo entorno de SQL. Puede que la implementacin concreta de la CL! para un SGBD concreto no albergue realmente las conexiones mll.iples.
Conexiones de SOL
SQLAllocHandle() */ short SQLFreeHandle ( short HdI Type,

long inHdl)
'*
IN: cdigo de tipo entero de controlador */ /* IN: controlador que hay que liberar */
1* Asigna un controlador para un nuevo entorno SQL */ short SQLAllocEnv ( long *envHdl) /* OUT: controlador de entorno devuelto */
/* Libera un controlador de entorno asignado previamente por SQLAllocEnv (l */
short SQLFreeEnv long envHdl J
/* IN: controlador de entorno */
1* Asigna un controlador para una nueva conexin SQL */ short SQLAllocConnect long envHdl, /* IN: controlador de entorno */ long "connHdl) /* OUT: controlador devuelto */
/* Libera un controlador de conexiones asignado previamente */ short SQLFreeConnect long connHd1) /* IN: controlador de conexiones */
short SQLAllocStmt ( long envHdl, /* IN: controlador de entorno "/ long "strntHdll /* OUT: controlador de instrucciones */
/* Libera un controlador de entorno asignado previamente */ short SQLFreeStmt long stmtHdl, /* IN: controlador de instrucciones "/ long optionl /* IN: opciones de cursores y de desenlace */
Figura 19.12. -
Rutinas de gestin de controladores de SOl/elL
Un programa de aplicacin puede establecer dentro de un entorno SQL una o ms conexiones SQL. Las conexiones de SQL son el enlace entre el programa y los servidores de SQL (servidores de bases de datos) en los que se procesan las instrucciones de SQL. En la prctica, las conexiones de SQL suelen ser realmente conexiones de red virtuales con los servidores de bases de datos ubicados en otros sistemas informticos. No obstante, las conexiones de SQL pueden ser tambin conexiones lgicas entre el programa y un SGBD ubicado en el mismo sistema informtico. La Figura 19.13 muestra las rutinas de CLI que se utilizan para gestionar las conexiones de SQL. Para establecer una conexin, el programa de aplicacin asigna antes un controlador de conexiones llamando a SQLAllocHandle () con el tipo de controlador adecuado. Luego intenta conectar con el servidor de SQL deseado mediante una llamada SQLConnect (). Las instrucciones de SQL pueden procesarse posteriormente empleando la conexin. El controlador de conexiones se pasa como parmetro a todas las llamadas de procesamiento de instrucciones para indicar la conexin que se est utilizando. Cuando ya no se necesita la conexin, una llamada a SQLDisconnect () la termina, y otra llamada a SQLFreeHandle () libera al controlador de conexiones asociado en la CL!. Normalmente, los programas de aplicacin conocen el nombre del servidor de bases de datos concreto (en trminos del estndar, el servidor de SQL) al que desean tener acceso. En algunas aplicaciones (como las consultas de propsito general o las herramientas de introduccin de datos), puede que resulte deseable permitir que el usuario escoja el servidor de bases de datos que se va a utilizar. La llamada eL! SQLDataSources () devuelve el nombre de los servidores de SQL que conoce la CLI -es decir, los orgenes de datos que pueden especificarse legalmente corno nombres de servidor en las llamadas SQLConnect ()-. Para obtener la lista de nombres de los servidores, la aplicacin llama repetidamente a SQLDataSources (). Cada llamada devuelve la descripcin de un solo servidor, hasta que devuelve un mensaje de error que indica que no quedan ms datos. Se puede utilizar de manera opcional un parmetro de la llamada para modificar esta recuperacin secuencial de nombres de servidores.
624
625
/* Inicia una conexin con un servidor de SOL */ short SQLConnect( /* IN: controlador de la conexin */ long connHdl. /* IN: nombre del servidor de SQL ehar "'svrName. deseado */ short svrnarnlen, /* IN: longitud del nombre del servidor de SOL */ ,. IN: nombre de usuario para la char userName, conexin */ short usrnamlen, /* IN: longitud del nombre de usuario */ /. IN: contrasea de la conexin */ char *passwd, short pswlenJ /* IN: longitud de la conexin */
/* Ejecuta directamente una instruccin de SQL */ short SQLExecDirect ( long stmtHdl, /* IN: controlador de instrucciones ~/ char *stmttext, /* IN: texto de la instruccin de SQL */ /* IN: longitud del texto de la short textlen) instruccin */ /* Prepara una instruccin de SQL ~/ short SQLPrepare ( long stmtHdl, /* IN: controlador de instrucciones */ /* IN: texto de la instruccin de SQL */ char *stmttext, /* IN: longitud del texto de la short textlen) instruccin ~/ /* Ejecuta una instruccin de SQL preparada con anterioridad */ short SQLExecute ( long stmtHdl) /* IN: controlador de instrucciones */ /* Enlaza el parmetro de una instruccin de SQL con el rea de datos del programa */ short SQLBindParam ( long stmtHdl, /* IN: controlador de instrucciones */ short parmnr, /* IN: nmero del parmetro (1,2,3 ... l */ short val type, /* IN: tipo de datos del valor proporcionado */ /- IN: tipo de datos del parmetro */ parmtype, short /* IN: tamao de la columna */ short colsize, /* IN: nmero de cifras decimales */ short decdigits, /* IN: puntero al bfer de valores de los void *value, parmetros */ /* IN: puntero al bfer de longitudes o long *lenind) indicadores */ /* Obtiene la etiqueta del parmetro para el siguiente parmetro dinmico necesario */ short SQLParamData ( ./* IN: controlador de instrucciones con long stmtHdl, parmetros dinmicos */ /* OUT: valor devuelto de la etiqueta del void *prmtag) parmetro */ /* Obtiene informacin detallada sobre un elemento descrito por un descriptor de la eLI */ short SQLPutData ( /* IN: controlador de instrucciones con long stmtHdl, parmetros dinmicos */ /* IN: bfer con datos para los void *prmdata, parmetros */ /* IN: longitud del parmetro o indicador short prmlenind) de valores NULL */
/* Se desconecta del servidor de SOL ./ short SQLDisconnect( long connHdl) /* IN: controlador de la conexin
*'
/* Obtiene el nombre de los servidores de SQL con los que es posible conectarse */
short SQLDataSources
long envHdl,
short direction, char *svrname , short buflen, short *namlen, char *descrip, short buf21en, short *dsclen)
" IN: controlador del entorno " " IN: indica la primera solicitud o
la siguiente */
" OUT: bfer para el nombre del servidor " " IN: longitud del bfer para el nombre del servidor " " OUT: longitud real del nombre del servidor " " OUT: bfer para la descripcin */ " IN: longitud del bfer de la descripcin " " OUT: longitud real de la descripcin "
Figura 19.13.
Rutinas de gestin de conexiones de SOL/CL!.
Procesamiento de instrucciones eLI

La eLI procesa las instrucciones de SQL empleando una tcnica muy parecida a la
descrita para SQL dinmico incorporado en el Captulo 18. Las instrucciones de SQL se pasan a la eL! en forma de texto, como cadena de caracteres. Pueden ejecutarse en procesos de una o de dos etapas. La Figura 19.14 muestra las llamadas bsicas de procesamiento de instrucciones de SQL. Los programas de aplicacin deben llamar primero a SQLAllocHandle ( ) para obtener un controlador de instrucciones, que identifica la instruccin ante el programa y la eLI. Todas las llamadas posteriores a SQLExecDirect ( ), SQLPrepare ( )
Figura 19.14.
Rutinas de procesamiento de instrucciones de CLI.
626
627
y SQLExecute () hacen referencia a este controlador de instrucciones. Cuando el controlador ya no se necesita, se libera con una llamada a SQLFreeHandle (). Para la ejecucin en un solo paso, el programa de aplicacin llama a SQLExecDirect () de SQL y le pasa a la llamada el texto de la instruccin de SQL como uno de los parmetros. El SGBD procesa la instruccin como consecuencia de la llamada y devuelve el estado de finalizacin de la instruccin. Este proceso de una sola etapa se utilizaba en el programa sencillo de ejemplo de la Figura 19.11. Se corresponde con la instruccin de una etapa EXECUTE IMMEDIATE de SQL dinmico incorporado, que se describe en el Captulo 18. Para la ejecucin en dos etapas, el programa de aplicacin llama a SQLPrepare () y le pasa el texto de la instruccin de SQL a la llamada como uno de los parmetros. El SGBD analiza la instruccin, determina la manera de ejecutarla y conserva esa informacin. No ejecuta la instruccin de manera inmediata. En vez de eso, las llamadas posteriores a la rutina SQLExecu te () hacen que la instruccin se ejecute realmente. Este proceso de dos etapas se corresponde exactamente con las instrucciones PREPARE y EXECUTE de SQL dinmico incorporado, descritos en el Captulo 18. Conviene utilizarlo siempre para cualquier operacin de SQL que haya que ejecutar de manera repetida, ya que hace que el SGBD slo pase una vez por la sobrec~ga del anlisis de las instrucciones y la optimizacin, en respuesta a la llamada SQLPrepare ( ). Se pueden pasar los parmetros mediante la CLI para personalizar la operacin de las llamadas a SQLExecu te () que siguen.
la longitud de la cadena de caracteres pueden obtenerla las rutinas de la eLI de los propios datos. De manera parecida, se utiliza un cdigo negativo para indicar un valor NULL de los parmetros de entrada. Si en la instruccin hay tres marcadores de parmetro de entrada, habr tres llamadas a SQLBindPararn ( ), una por cada parmetro. Una vez establecida la relacin entre las variables del programa de aplicacin (ms exactamente, ubicaciones de almacenamiento del programa) y los parmetros de la instruccin, se puede ejecutar la instruccin real con una llamada a SQLExecute ( ). Para modificar los valores de los parmetros para instrucciones posteriores slo hace falta colocar valores nuevos en las reas de bferes del programa de aplicacin antes de la siguiente llamada a SQLExecu te ( ). De manera alternativa, se pueden volver a enlazar los parmetros con diferentes reas de datos del programa de aplicacin mediante llamadas posteriores a SQLBindParam( l. La Figura 19.15 muestra un programa que incluye una instruccin de SQL con dos parmetros de entrada. El programa pide repetidamente al usuario un nmero de cliente y un nuevo lmite de crdito para ese cliente. Los valores proporcionados por el usuario se transforman en los parmetros de entrada de una instruccin UPDATE de la tabla CLIENTES.
Ejecucin de instrucciones con parmetros

En muchos casos la instruccin de SQL debe ejecutarse de manera repetida slo con cambios en algunos de los valores que especifica. Por ejemplo, la instruccin INSERT que aade un pedido a la base de datos de ejemplo es idntica para cada pedido, salvo por la informacin especfica sobre el nmero de cliente, el producto y el fabricante y la cantidad encargada. Como se describi en el Captulo 18, para SQL dinmico incorporado esas instrucciones pueden procesarse de manera eficiente especificando las partes variables de la instruccin como parmetros de entrada. El texto de la instruccin pasado a la llamada a SQLPrepare () tiene un marcador de parmetro -un signo de interrogacin (?)- en el texto en cada posicin en la que hay que insertar el valor de un parmetro. Cuando la instruccin se ejecute ms adelante, habr que proporcionar valores para cada uno de los parmetros de entrada. La manera ms sencilla de proporcionar los valores de los parmetros de entrada es utilizar la llamada a SQLBindPararn (). Cada llamada a SQLBindPararn () establece un enlace entre uno de los marcadores de parmetro de la instruccin de SQL (identificado por su nmero) y una variable del programa de aplicacin (identificada por su direccin de memoria). Adems, se establece opcionalmente una asociacin con una segunda variable del programa de aplicacin (un entero) que proporciona la longitud de los parmetros de longitud variable. Si el parmetro es una cadena de caracteres terminada en un valor NULL, como las empleadas ~n los programas d.e C, se puede pasar un valor negativo especial del cdigo, definido en el archivo de encabezados como la constante simblica SQL_NTS, para indicar que
/* Programa para elevar el lmite de crdito de los clientes especificados por el usuario */ /* archivo de encabezados iinclude <sqlcli.h> con definiciones de CLI */ main( )
(
SQLHENV SQLHDBC
env_hdl; conn_hdl; stmt._hdl; status; *nornbre_servidor = "derno" ; *nombre_usuario "jose"; *contra_usuario buf_importe[3l) ; amt_ind
=
SQL~TS;
"xyz~;
jO JO jo JO jO jO jo jO jO
SQLHSTMT
SQLRETURN char char char char int
l'
char
buf_cli [31];
jo
controlador del entorno de SQL * / controlador de la conexin */ controlador de instrucciones */ estado de devolucin de la rutina CLI */ nombre del servidor */ nombre de usuario para la conexin */ contras efta del usuario para la conexin */ importe introducido por el usuario */ indicador del importe (cadena de caracteres acabada en NULL) */ nmero de cliente introducido por el usuario * /
Figura 19.15.
Programa de eL! que utiliza parmetros de entrada. (Contina.)
628
629
iot
cust
~nd
SQL_NTS;
1\
char buf_instru(128J:
indicador de cliente (cadena de caracteres acabada en NULL) */ /* bfer para la instruccin de SQL */
I~
I * Ejecuta la instruccin con los parmetros */ status = SQLExecute(strnt_hdll; if (status) printf("Error durante la actualizacin\n"); else printf("Modificaci6n del lmite de crdito concluida con xito.\n"):
/*
Asigna controladores para el entorno de SQL, la conexin y la instruccin */ SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env_hdl}; SQLAllocHandle(SQL_HANDLE_DBC, env_hdl, &conn_hdl); SQLAllocHandle(SQL_HANDLE_STMT, cono_hdl. &strnt_hdl);
/* Compromete la actualizacin */
SQLEndTran(SQL_HANDLE_ENV,
env_hdl,
SQL_COMMIT);
Conecta con la base de datos, pasando el nombre del servidor, el usuario y la contrasefia */ /* SQL_NTS says NULL-terminated string instead of passing length */ SQLConnect{conn_hdl, nombre_servidor, SQL_NTS, nombre_usuario, SQL_NTS, contra_usuario, SQL_NTS};
/*
/ * Desconecta, desasigna los controladores y SQLDisconnect{conn_hdl); SQLFreeHandle{SQL_HANDLE_STMT, stmt_hdl); SQLFreeHandle(SQL_HANDLE_DBC, conn_hdl); SQLFreeHandle(SQL_HANOLE_ENV, env_hdl); exit();
sale */
'r 1
/* Prepara una instruccin UPOATE con marcadores de parmetro */ strcpy(buf_instru, update clientes set limite_credito :: ? -); strcat (buf_instru, "where num_cli :: ?-l; SQLPrepare{stmt_hdl, stmt_buf, SQL_NTSl;
Figura 19.15.
Program~
de eL! que utiliza parmetros de entrada. (Continuacin.)
1,
/ * Enlaza los parmetros con los bferes del programa */ SQLBindParamlstmt_hdl,1,SQL_C_CHAR.SQL_DEClMAL.9.2.&buf_importe. &amt_ind);
I
I
SQLBindParam(strnt_hdl,2.SQL_C_CHAR,SQL_INTEGER,O.O,&buf_cli, &cust_indl; 1'1
* Itera para procesar cada modificacin del lmite de crdito */ for ( ; ) ( /
1,1
1"
!I
/* Pide al usuario el cliente y el nuevo limite de crdito */ printf (" Introduzca el nmero de cliente; -); gets (buf_clil ; if (strlen(buf_cli) ::~ O) break; printf{"Introduzca el nuevo lmite de crdito; -); gets(buf_importe);
1,
Figura 19.15.
Programa de eL! que utiliza parmetros de entrada. (Continuacin)
Las llamadas a SQLParamData () ya SQLPutData () de la Figura 19.15 proporcionan un mtodo alternativo para pasar parmetros en el momento de la ejecucin, denominado paso diferido de parmetros. La seleccin de esta tcnica para un parmetro concreto de la instruccin se indica en la llamada correspondiente a SQLBindParam (). En lugar de proporcionar realmente una ubicacin de datos del programa a la que est ligado el parmetro, la llamada a SQLBindParam () indica que se utilizar el paso diferido de parmetros y proporciona un valor que se utilizar ms tarde para identificar al parmetro concreto que se procesa de esta manera. Una vez solicitada la ejecucin de la instruccin (mediante una llamada a SQLExecute () O a SQLExecDirect (, el programa llama a SQLParamOata () para determinar si la instruccin necesita datos de parmetros diferidos. En caso afIrmativo, la eLI devuelve un cdigo de estado (SQL_NEED_DATA) junto con un indicador del parmetro que necesita valores. El programa llama entonces a SQLPutData () para proporcionar realmente el valor del parmetro. Generalmente, el programa llama entonces nuevamente a SQLParamDa ta () para determinar si algn otro parmetro necesita datos dinmicos. El ciclo se repite hasta que se hayan proporcionado todos los datos dinmicos necesarios. y la ejecucin de la instruccin de SQL contina entonces normalmente. Este mtodo alternativo de paso de parmetros es considerablemente ms complejo que el sencillo proceso de enlace de los parmetros con las ubicaciones del programa de aplicacin. Tiene dos ventajas. La primera es que el paso real de Jos valores de los datos (y la asignacin de almacenamiento para contenerlos) puede
l'
630
631
retrasarse hasta el ltimo momento, cuando los datos se necesiten realmente. La segunda ventaja es que la tcnica puede utilizarse para pasar valores de parmetros muy largos trozo a trozo. Para los tipos de datos largos escogidos la eLI permite llamadas repetidas a SQLPutData (l para el mismo parmetro, donde cada llamada pasa la siguiente parte de los datos. Por ejemplo, el texto de un documento que se proporcione como parmetro para la clusula VALUES de una instruccin INSERT puede pasarse en trozos de mil caracteres mediante llamadas repetidas a SQLPutOata () hasta que se haya pasado todo el documento. Esto evita la necesidad de asignar un nico bfer de memoria de tamao muy grande dentro del programa de aplicacin para guardar todo el valor del parmetro.
-el apartado anterior. Si el programa determina que debe cancelar la ejecucin de la instruccin en lugar de proporcionar un valor para el parmetro diferido, puede llamar a SQLCancel () para lograr ese resultado. La llamada a SQLCancel () tambin puede utilizarse en aplicaciones multihebra para cancelar el efecto de una llamada a SQLExecu te () Oa SQLExecDirect ( ) que no se haya completado todava. En esta situacin, la hebra que realiza la llamada original para la ejecuci6n seguir esperando que se complete la' llamada, pero las dems hebras que se ejecuten de manera simultnea pueden llamar a SQLCancel () empleando el mismo controlador de instrucciones. Los detalles de esta tcnica y el grado de interrupcin de las llamadas CLI suelen depender mucho de la implementacin.
Gestin de transacciones con CL/

Las funciones COMMIT y ROLLBACK para el procesamiento de las transacciones de SQL se aplican tambin a la operativa de SQL mediante la CL!. No obstante, como la propia CLl debe tener conocimiento de que se est completando una transaccin, las instrucciones CDMMIT y RDLLBACK de SQL se sustituyen por la llamada eLl a SQLEndTran (l, como puede verse en la Figura 19.16. Esta llamada se emplea para comprometer las transacciones en los ejemplos de programas de las figu ras 19.11 y 19.15. Se utiliza la misma rutina eLl para ejecutar las operaciones COMMIT y RDLLBACK; la operacin concreta que se va a Bevar a cabo se especifica mediante el parmetro de tipo de finalizacin de la llamada. La llamada CL! a SQLCancel (l. que tambin puede verse en la Figura 19.16 no proporciona realmente una funcin de gestin de transacciones, pero, en la prctica, se utiliza casi siempre junto con las operaciones ROLLBACK. Se emplea para cancelar la ejecucin de una instruccin de SQL que inici anteriormente una llamada a SQLExecDirect () o a SQLExecute (). Esto resulta adecuado en programas que utilizan el procesamiento diferido de parmetros, como se ha descrito en
Procesamiento de resultados de consultas con CL/

Las rutinas CLl descritas hasta ahora pueden utilizarse para procesar instrucciones de definicin de datos de SQL o instrucciones de manipulacin de datos de SQL que no sean consultas (es decir, instrucciones UPDATE, DELETE e INSERT). Para el procesamiento de consultas, se necesitan algunas llamadas CLl, como indica la Figura 19.17. La fonna ms sencilla de procesar los resultados de las consultas es utilizar las llamadas a SQLBindCol () ya SQLFetch (). Para realizar una consulta empleando estas llamadas el programa de aplicacin recorre las etapas siguientes (suponiendo que ya se ha establecido conexin):
1.
2. 3.
El programa asigna un controlador de instrucciones empleando SQLAllocHandle (). El programa llma a SQLPrepare () y le pasa el texto de la instruccin SELECT de SQL para la consulta. El programa llama a SQLExecute () para que realice la consulta.
/- Compromete (COMMIT) o hace retroceder (ROLLBACK) una transaccin de SQL -/ short SQLEndTran ( /~ IN: tipo de controlador -/ short hdltype, /. IN: controlador de entorno, de long txnHdl, conexiones o de instrucciones ./ /. IN: tipo de transaccin (COMMIT/ short compltype) ROLLBACK) ./
/- cancela una instruccin de SQL que se est ejecutando -/ short SQLCancel ( short stmtHdll 1- IN: controlador de instrucciones -/
/. Enlaza una columna de resultados de la consulta con un rea de datos del programa . / short SQLBindCol ( long s tmtHdl /- IN: controlador de instrucciones ./ short colnr, /. IN: nmero de columna que se va a enlazar ~/ short tgttype, /. IN: tipo de datos del rea del programa ./ void value, /. IN: puntero al rea de datos del programa -/ long buflen. /- IN: longitud del bfer del programa -/ long lenind) /- IN: puntero al bfer de longitudes e indicadores -/
Figura 19.17. Figura 19.16. Rutinas de gestin de transacciones de CLI.
Rutinas de procesamiento de los resultados de las consulta de CLI. (ConUna.)
632
633
4.
/* Desplaza el cursor hasta la siguiente fila de resultados de la consulta */
short SQLFetch ( long stmtHdl)
S.
/*
IN: controlador de instrucciones */
/* Desplaza el cursor hacia arriba o hacia abajo por el resultado de
la consulta "" short SQLFetchScroll long strntHdl.
6. 7.
short
long
fetchdir,
offset}
/* IN: controlador de instrucciones */ /* IN: direccin (primera/siguientel anterior) .. I / .. IN: resul cado (nmero de filas) .. I
El programa llama a SQLBindCol () una vez por cada columna de resultados de la consulta que se vaya a devolver. Cada llamada asocia un rea de bferes del programa con una columna de datos devuelta. El programa llama a SQLFetch () para que capture una fila de resultados de la consulta. El valor de los datos de cada columna de la fila recin capturada se coloca en el bfer del programa correspondiente, como se indica en las llamadas anteriores a SQLBindCol (). Si la consulta produce varias filas, el programa repite la Etapa 5 hasta que la llamada a SQLFetch () devuelva un valor que indique que no quedan ms filas. Cuando se han procesado todos los resultados de la consulta, el programa llama a SQLCloseCursor () para concluir el acceso al resultado de la consulta.
/* Obtiene los datos de una sola columna de resultados de la consulta */ short SQLGetData ( long s tmtHdl, /* IN: controlador de instrucciones */ /* IN: nmero de la columna que hay que short color, recuperar */ /* IN: tipo de datos que hay que devolver short tgttype, al programa */
El fragmento de programa de la Figura 19.18 muestra una consulta sencilla ejecutada empleando esta tcnica. El programa es idntico en funcionalidad al ejemplo de programa basado en dblib de la Figura 19.7. Resulta instructivo comparar los dos programas. Los detalles de las llamadas y de sus parmetros son- bastante diferentes, pero el flujo de los programas y la secuencia 16gica de las llamadas que realizan son idnticos.
void
value. buflen,
*lenind)
long
long
/* IN: puntero al bfer de datos de la columna */ /* IN: longitud del bfer del programa */ /* OUT: longitud real o indicador de valores NULL * /
/* Cierra un cursor para concluir e~ acceso a los resultados de la consulta */ short SQLCloseCursor long stmtHdl) /* IN: controlador de instrucciones */
/* Programa para mostrar un informe de los representantes Que han superado su cuota */ iinclude <sqlcli.h> /~ archivo de encabezados con las definiciones CLI ~/ main ()
(
SQLHENV SQLHDBC
env_hdl: conn_hdl; stmt_hdl; status; *nombre_servidor : "demo"; *nombre_usuario : "jose-; *contra_usuario nombrerep[16) ; -xyz";
/* Establece un nombre de cursor para un cursor abierto */ short SQLSetCursorName 1
SQLHSTMT SQLRETURN char char
long char short
stmtHdl, cursname, namelen)
/* IN: controlador de instrucciones */ /* IN: nombre del cursor */ /* IN: longitud del nombre del cursor *1
/* Recupera el nombre de un cursor abierto */ short SQLGetCursorName ( long stmtHdl, /* IN: controlador de instrucciones */ char cursname, /* OUT: bfer para el nombre devuelto */ short huflen, /* IN: longitud del bfer */ short *namlen) /* OUT: longitud real del nombre devuelto */
char char
float float
cuotarep; ventasrep;
1- controlador del entorno SQL *1 1- controlador de conexiones */ 1- controlador de instrucciones *1 1- estado de devolucin de la rutina CLI */ 1* nombre del servidor */ /* nombre de usuario para la conexin */ 1* contraseBa del usuario para la conexin *1 1* nombre del representante, recuperado *1 1* cuota, recuperado */ /* ventas, recuperado */
Figura 19.17.
Rutinas de procesamiento de los resultados de las consulta de ell. (Continuacin.)
Figura 19.18.
Recuperacin de los resultados de la consulta con
ell. (Contina.)
634
635
short char
repquota_ind; buf_instrul128l;
, indicador de valor NULL en la cuota , ' bfer para la instruccin de SQL '
~I
l. Asigna controladores y se conecta con la base de datos SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env_hdl); SQLAllocHandle(SQL_HANDLE_DBC, env_hdl, &conn_hdl); SQLAllocHandle(SQL_HANDLE_STMT, conn_hdl, &stmt_hdl); SQLConnect(conn_hdl, nombre_servidor, SQL_NTS, nombre_usuario, SQL_NTS, contra_usuario, SQL_NTSl;
I~ Solicita la ejecucin de la consulta ~I strcpy(buf_instru, "select nombre, cuota. ventas froro representantes O); strcat(buf instru, "where ventas> cuota arder by nombre"); SQLEy.ecDir;ct(stmt_hdl, buf_instru, SQL_NTSl;
1 ~ Enlaza las columnas recuperadas con los bferes del programa 1 SQLBindCol (stmt_hdl,l,SQL_C_CHAR,nombrerep, lS.NULL); SQLBindCol (stmt_hdl.2,SQL_C_FLOAT,&cuotarep, O,&quota_i nd); SQLBindCol(stmt_hdl,3, SQL_C_FLOAT, &ventasrep,O,NULL) i
I * Itera por las filas de resultados de la consulta *1 for ( , ) { 1* Captura la siguiente fila de resultados de la consulta (SQLFetch (s trnt_hdl) ! = SQL_SUCCESS l break;
~I
if
1* Muestra los datos recuperados *1 printf("Nombre: \s\n~. norobrerep); if (repquotA_ind < O) printf(~La cuota es NULL\n~); else printf(~Cuota: \f\n", cuotarep); printf(-Ventas: \f\n", ventasrep);
I * Desconecta, desasigna los controladores y sale '"/ SQLDisconnect(conn_hdl); SQLFreeHandle(SQL_HANDLE_STMT, stmt_hdl); SQLFreeHandle(SQL_HANDLE_DBC. conn_hdl); SQLFreeHandlelSQL_HANDLE_ENV, env_hdl); exit () ;
.,
Cada llamada a SQLBindCol () establece una asociacin entre una columna de resultados de la consulta (identificada por su nmero de columna) y un bfer del programa de aplicacin (identificado por su direccin). Con cada llamada a SQLFetch () la eLI utiliza este enlace para copiar el valor de los datos correspondiente a la columna en el rea de bferes del programa. En el momento adecuado se especifica una segunda rea de datos del programa como bfer para la variable indicadora de la columna. Cada llamada a SQLFetch () define esta variable del programa para que indique la longitud real de los valores devueltos de los datos (para los datos de longitud variable) y para que indique la devolucin de valores NULL. Cuando el programa ha terminado de procesar todos los resultados de la consulta, llama a SQLCloseCursor ( ) . Las rutinas CLI de la Figura 19.17 tambin pueden utilizarse para implementar un mtodo alternativo de procesamiento de los resultados de la consulta. En esta tcnica las columnas de resultados de la consulta no se enlazan de antemano con ubicaciones del programa de aplicacin. En vez de eso, cada llamada a SQLFetch () slo desplaza el cursor hasta la siguiente fila de resultados de la consulta. No hace realmente que se recuperen datos en las reas de datos del programa anfitrin. En su lugar se realiza una llamada a SQLGetData () para que recupere realmente los datos. Uno de los parmetros de SQLGetData () especifica la columna de resultados de la consulta que hay que recuperar. Los dems parmetros especifican el tipo de datos que hay que recuperar y la ubicacin del bfer que debe recibir los datos y el valor de la variable indicadora asociada. En el nivel bsico la llamada a SQLGetData () es simplemente una alternativa al enfoque de enlace de las variables del anfitrin proporcionado por SQLBindCol (), pero SQLGetData () proporciona una ventaja importante al procesar elementos de datos de tamao muy grande. Algunas bases de datos soportan columnas binarias largas O columnas de caracteres que pueden contener millares o millones de bytes de datos. No suele resultar prctico asignar un bfer del programa para que albergue todos los datos de esas columnas. Con el empleo de SQLGetData () el programa puede asignar un bfer de tamao razonable y procesar los datos en grupos de unos cuantos miles de bytes cada vez. Resulta posible entremezclar los estilos de SQLBindCol () y de SQLGetData () para procesar el resultado de la consulta de una sola instruccin. En este caso, la llamada a SQLFetch () recupera realmente los valores de los datos de las columnas enlazadas (para las que se ha realizado una llamada a SQLBindCol ()), pero el programa debe llamar de manera explcita a SQLGetDa ta () para procesar las dems columnas. Esta tcnica puede resultar especialmente adecuada si una consulta recupera varias columnas de datos tpicos de SQL (nombres, fechas, cantidades de dinero) y una o dos columnas de datos largos, como el texto de un contrato. Obsrvese que algunas implementaciones de CL! restringen mucho la posibilidad de entremezclar los dos estilos de procesamiento. En concreto, algunas implementaciones exigen que todas las columnas enlazadas aparezcan primero en el orden de derecha a izquierda de los resultados de la consulta, antes que las columnas recuperadas mediante SQLGetData ().
Figura 19.18.
Recuperacin de los resultados de la consulta con
eLl. (Continuacin.)
636
.637
Cursores de desplazamiento
El estndar SQL/CLI especifica el soporte de eLI para los cursores de desplazamiento, que es muy parecido al soporte de los cursores de desplazamiento incluido originalmente en el estndar SQLZ para SQL incorporado. La llamada a SQLFetchScroll (l. que puede verse en la Figura 19.17, proporciona las fun-
Procesamiento de consultas dinmicas con CL!

Si las columnas que tiene que recuperar la consulta de SQL no se conocen con antelacin cuando se desarrolla el programa, ste puede utilizar las llamadas de procesamiento de consultas de la Figura 19.19 para determinar las caractersticas de los resultados de la consulta en el mamen lO de la ejecucin. Estas llamadas implementan el mismo tipo de posibilidad de procesamiento de consultas de SQL dinmico incorporado del Captulo 18. A continuacin pueden verse las etapas para el procesamiento dinmico de las consultas empleando CL!: l. El programa asigna un controlador de instrucciones empleando SQLAllocHandle ().
ciones ampliadas FETCH necesarias para la recuperacin hacia delante y hacia atrs y aleatoria de los resultados de las consultas. Uno de sus parmetros especifica el controlador de instrucciones de la consulta, igual que para la llamada SQLFetch () sencilla. Los otros dos parmetros especifican la direccin del movimiento de FETCH (PREVIDUS, NEXT, etctera) y el resultado de los movimientos de FETCH que 10 necesitan (recuperacin de las filas aleatoria absoluta y relativa). La operativa de SQLBindCol () y de SQLGetData () para el procesamiento de los valores devueltos es idntica a la descrita para la llamada a
SQLFet.ch ().
Cursores con nombre

Obsrvese que la CL] no incluye una llamada explcita a la declaracin del cursor para igualar la instruccin DECLARE CURSOR de SQL incorporado. En lugar de eso, el texto de las consultas de SQL (es decir, una instruccin SELECT) se pasa a la eL! para su ejecucin del mismo modo que cualquier otra instruccin de SQL, empleando una llamada a SQLExecDirect () o a la secuencia SQLPrepare () I SQLExecute (). Los resultados de la consulta se identifican mediante el controlador de instrucciones de las llamadas SQLFetch ( ) , SQLBindCol () posteriores y de instrucciones parecidas. Para esto el controlador de instrucciones ocupa el lugar del nombre del cursor empleado en SQL incorporado. Con este esquema surge un problema en el caso de las actualizaciones posicionadas (basadas en los cursores) y las eliminaciones posicionadas. Como se describi en el Captulo 17, se puede utilizar una instruccin UPDATE posicionada o una instruccin DELETE (UPDATE ... WHERE CURRENT OF o DELETE ... WHERE CURRENT OF) para modificar o eliminar la fila en curso (es decir, recin capturada) de los resultados de la consulta. Estas instrucciones de SQL incorporado utilizan el nombre del cursor para identificar la fila concreta que hay que procesar, ya que el programa de aplicacin puede tener abierto ms de un cursor a la vez para procesar ms de un conjunto de resultados de la consulta. .. Para incorporar las actualizaciones posicionadas, la eL] proporciona la llamada a SQLSetCursorName () que puede verse en la Figura 19.17. La llamada se utiliza para asignar un nombre de cursor, especificado como uno de sus parmetros, a un conjunto de resultados de la consulta, identificado por el controlador de instrucciones que.lo gener. Una vez realizada la llamada, el nombre del cursor puede utilizarse en instrucciones posicionadas UPDATE o DELETE posteriores, que pueden pasarse para su ejecucin a la eLl. Se puede utilizar una llamada adjunta, SQLGetCursorName (l, para obtener un nombre de cursor ya asignado, dado su controlador de instrucciones.
/* Determina el nmero de columnas de resultados de la columna -/ short SQLNumResultCols ( long stmtHdl, 1* IN: controlador de instrucciones */ short *colcount) 1* OUT: nmero de columnas devuelto */ /* Determina las caractersticas de una columna de resultados de la consulta */ short SQLDescribeCol long stmtHdl, 1* IN: controlador de instrucciones *1 short. numcol, /* IN: nmero de la columna que hay que describir *1 char *nombrecol, 1* OUT: nombre de la columna de resultados de la consulta */ short lonbuf, /* IN: longitud del bfer del nombre de la columna */ short *lonnoro, 1* OUT: longitud real del nombre de la columna */ short *tipocol, /* OUT: cdigo de tipo de datos de la columna devuelta */ short *tamacol, /* OUT: longitud de los datos de la columna devuelta *1 short *cifrasdec, /* OUT: nmero devuelto de cifras de la columna */ short *nullable) /* OUT: indica si la columna puede tener valores NULL */ /* Obtiene informacin detallada sobre una columna de resultados de la columna *1 short SQLColAttribute long stmtHdl, /* IN: controlador de instrucciones */ short numcol, /* IN: nmero de la columna que hay que describir *1 short codiatri, /* IN: cdigo del atributo que hay que recuperar *1
Figura 19.19.
Llamadas eLl para el procesamiento dinmico de consultas. (Contina.)
638
639
char
~infoatri.
short
lonbu f,
short *lonreal,
iot *atrinum)
bfer para la informacin de los atributos de la cadena de caracteres ... / /* IN: longitud del bfer de atributos de la columna */ /* OUT: longitud real de la informacin de los atributos */ /* OUT: informacin entera devuelta de los atributos */
/* OUT:
short void short short
escala, *bufdatos, lonbuf, ""bufind)
/* IN: escala del elemento, si es numrico '"/ /* IN: direccin del bfer de datos del elemento */ /'" IN: longitud del bfer de datos *( /'" IN: direccin del bfer de indicadores del elemento '"/
/* Recupera la informacin utilizada frecuentemente de un descriptor eL! ,o/ short SQLGetDescRec long descHdl, controlador de descriptores ' / / ' IN: short numreg. nmero del registro del / ' IN: descriptor ,/ char ,. nombre. / ' OUT: nombre del elemento que se est describiendo ' / short lonbuf, longitud del bfer de /' IN: nombres -/ short *lonnom, /- OUT: longitud real del nombre devuelto ' / short *tipodatos, /- OUT: cdigo del tipo de datos del elemento -/ short *subtipo, /' OUT: subcdigo del tipo de datos del elemento ' / short *longitud, /- OUT: longitud del elemento -/ /- OUT: precisin del elemento, si es short *precis, numrico -/ short ""escala, /- OUT: escala del elemento, si es numrico - short ""nullablel /- OUT: indica si el elemento puede tener valores NULL -/
/* Obtiene informacin detallada sobre un elemento descrito por un descriptor CLI */ short SQLGetDescField long descHdl. /'" IN: controlador de descriptores ""/ short numreg, /* IN: nmero del registro del descriptor ""/ short codiatri, /'" IN: cdigo del atributo que hay que describir ""/ void ""infoatri, /* IN: bfer para la informacin sobre los atributos */ short lonbuf, /* IN: longitud de la informacin sobre los atributos */ short ""lonreal) /* OUT: longitud real de la informacin devuelta '"/
/* Define la informacin utilizada frecuentemente en un descriptor
CLI ""/
short SQLSetDescRec long descHdl, short numreg, short short short short tipodatos, subtipo, longitud, precis,
/- IN: controlador de descriptores -/ /- IN: descriptor del nmero de .c~ registro -/ /- IN: cdigo del tipo de datos del elemento -/ /- IN: subc6digo del tipo de datos del elemento -/ /- IN: longitud del elemento -/ /- IN: precisin del elemento, si es numrico ' /
/* Define el valor de un elemento descrito por un descriptor CL! */ short SQLSetDescField long descHdl. controlador de /' IN: descriptores -/ short numreg, /- IN: nmero del registro del descriptor -/ short codiatri, /- IN: cdigo del atributo que se va a describir ' / void ""infoatri, /- IN: bfer con el valor del atributo -/ short lonbuf) /- IN: longitud de informacin sobre los atributos ' /
,.
/"" Copia el contenido de un descriptor eLI en otro descriptor * / short SQLCopyDesc ( long indscHdl, IN: controlador del descriptor de / origen -/ long /- IN: controlador del descriptor de outdscHdl) destino -/
Figura 19.1~.
Llamadas CL! para el procesamiento dinmico de consultas. (Continuacin.)
Figura 19.19.
Llamadas CLI para el procesamiento dinmico de consultas. (Continuacin.)
640
2.
3. 4.
5.
641
6.
7.
8.
9.
El programa llama a Prepare () para que pase el texto de la instruccin SELECT de la consulta. El programa llama a SQLExecute () para que ejecute la consulta. El programa llama a SQLNurnResultCols () para que determine el nmero de columnas del resultado de la consulta. El programa llama a SQLDescribeCol (l una vez por cada columna de resultados de la consulta para determinar su tipo de datos, su tamao, si puede contener valores NULL, etc. El programa asigna memoria para que reciba los resultados de la consulta y enlaza esas ubicaciones de memoria con las columnas llamando a SQLBindCol (J una vez por cada columna. . El programa llama a sQLFetch () para capturar una fila de resultados de la consulta. La llamada a SQLFetch () desplaza el cursor hasta la siguiente fila de resultados de la consulta y devuelve cada columna de resultados al rea correspondiente del programa de aplicacin, tal y como se especifica en las llamadas a SQLBindCol (). Si la consulta genera varias filas, el programa repite la etapa 7 hasta que la llamada SQLFetch (J devuelva un valor que indique que ya no quedan ms filas. Cuando se han procesado todos los resultados de la consulta, el programa llama a SQLCloseCursor (l para finalizar el acceso a los resultados de la consulta.
main ()
(
/* Se trata de un programa sencillo de consultas de propsito
general. Pide al usuario el nombre de una tabla y luego le pregunta las columnas de la tabla que se van a incluir en la consulta. Una vez completadas las selecciones del usuario, el programa ejecuta la consulta solicitada y muestra el resultado.
"f
SQLHENV SQLHDEC SQLHSTMT env_hdl; conn_hdl; stmtl_hdl; controlador del entorno SQL */ controlador de conexiones ./ controlador de instrucciones para la consulta principal */ controlador de instrucciones para la consulta del nombre de la columna */ estado de devolucin de la rutina eL! */ nombre del servidor */ nombre de usuario para la conexin */ contraseBa del usuario para la conexin */ texto de la consulta principal de SQL que se va a ejecutar *1 texto de SQL para la consulta del nombre de la columna */ tabla especificada por el usuario para la consulta */ columna especificada por el usuario */ consulta si se trata de la primera columna escogida */ nmero de columnas del resultado de la consulta */ direccin para que eL! devuelva el nombre de la columna */
/*
/*
/*
SQLHSTMT
stmt2_hdl;
/*
SQLRETURN char char char char
status; nombre_servidor = "demo" ; nombre_usuario = "jose"; *contra_usuario = "xyz" ; bufinstru(2001];
f" f" f" f" f" f" f" f" f" f" f"
La Figura 19.20 muestra un programa que utiliza estas tcnicas para procesar una consulta dinmica. El programa es idntico en su concepto y propsito al programa de consultas de SQL dinmico incorporado de la Figura 18.9 y al programa de consultas de SQL dinmico basado en dblib de la Figura 19.10. Una vez ms, resulta instructivo comparar los ejemplos de programas para mejorar la comprensin del procesamiento dinmico de las consultas. Las llamadas a las API tienen nombres bastante diferentes, pero las secuencias de llamadas a funciones para el programa de dblib (Figura 19.10) y para el programa eL! (Figura 19.20) son casi idnticas. La secuencia de llamadas a dbcmd () I dbsqlexec () I dbresults (l se sustituye por SQLExecDirect (). (En este caso, la consulta slo se ejecutar una vez, por lo que no supone ninguna ventaja el empleo de SQLPrepare (l Yde SQLExecute () por separado.) La llamada a dbnumcols () se transfonna en SQLNumResultCols (l. Las llamadas para obtener infonnaci6n sobre las columnas (dbc'lname ( l, dbco 1 type ( 1, dbcoll en ( ) se transforman en una sola llamada a SQLDescribeCol (l. La llamada a dbnextrow (l se transforma en SQLFetch (l. Todas las dems modificaciones en el programa se realizan para incorporar estos cambios a las funciones API. Si se compara el programa de la Figura 19.20 con el programa correspondiente de SQL dinmico incorporado de la Figura 18.9, una de las principales diferencias es el empleo por SQL incorporado del rea especial de datos de SQL (SQL .Data Area, SQLDA) para el enlace y la descripcin de las columnas. La CLI divide estas funciones entre las funciones SQLNumResul tCols (), SQLDescribeCol (l Y SQLBindCol (), y la mayor parte de los programadores encuentran la estructura de la
char
hufinstru2[2001];
char
tablacon(32);
char int
columcon[32] ; pri_col = O;
short
cuentacol;
char
*punnombre;
Figura 19.20.
Empleo de
eL! para consultas dinamicas. (Contina.)
642
643
short
lonnombre;
" " "
short
tipo;
short short
tama; cifras;
"
" " " " "
short short char char
nullable;
i, bufen(lOl] ;
-nombre_elemllOO];
char
*datos_elem{lOO};
ioe short
indi_elem[lOOl; tipo_elemllOOl;
"
"
char
"'pundatos;
"
longitud del nombre de la columna devuelto por eL! " cdigo eL! para el tipo de datos de la columna " tamao de la columna devuelto por eL! " nmero de cifras de la columna devuelto por eL! " posibilidad de valores NULL devuelta por eL! " ndice de las columnas " datos introducidos por el usuario " array para seguir los nombres de las columnas " array para seguir los bferes de las columnas " array de variables indicadoras " array para seguir los tipos de datos de las columnas " direccin del bfer para la columna actual "
strcpy(bufinstru,
"select
"J;
/* Consulta al esquema de la informacin para obtener el nombre de las columnas */ strcpy (bufinstru2, "select column name from co1urnns where table_name: O); strcat (strnt2buf, tablacon); SQLExecDirect(strnt2_hdl, strnt2buf, SQL_NTS);
/* Procesa el resultado de la consulta */ SQLBindco1 (strnt2_hdl. 1, SQL_C_CHAR, colurncon, 31, (int *) O); while (status: SQLFetch{stmt2_hd1) : : SQL_SUCCESS) { printf{"Incluir la columna ts (s/n)? ., colurocon); gets (bufen); if (bufen[O] : : 's') { /* El usuario desea incluir la columna; hay que aadirla a la lista de seleccin */ if (first_col++ > O) strcat (bufinstru, ", "); strcat(bufinstru, colurncon);
/* Concluye la instruccin SELECT con una clusula FROM */ strcat(bufinstru, "froro "}; strcat (bufinstru, tablaconJ;
'" Abre una conexin con la base de datos de demostracin mediante eLI */ SQLAllocHandle{SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env_hdl); SQLAllocHandle(SQL_HANDLE_DBC, env_hdl, &conn_hdl); SQLAllocHandle(SQL_HANDLE_STMT, conn_hdl, &stmtl_hdl); SQLAllOcHandle(SQL_HANDLE_STMT, cono_hdl, &stmt2_hdl); SQLConnect{conn_hdl, nombre_servidor, SQL_NTS, nombre_usuario, SQL_NTS, contra_usuario, SQL_NTS};
/. Ejecuta la consulta y se prepara para capturar el resultado de la consulta ./ SQLExecDirect (strntl_hdl, bufinstru, SQL_NTS);
/* pide a la eLI que describa cada columna, la asigne y la enlace */ SQLNuroResultCo1s (strnt1_hdl, &cuentacol); for (i :0; i < cuentacol; i++) { nombre_elern[i] ~ punnombre = malloc(32); indptr ~ &indi_elern[iJ; SQLDescribeCol(stmtl_hdl, i, punnombre, 32, &lonnombre, &tipo, &tama, &cifras, &nullable); swi tch (tipo)
/* Pregunta al usuario la tabla que hay que consultar * / printf("*"* Miniprograma para consultas ***\n"); printf (" Introduzca el nombre de la tabla para la consul ta: gets(tablacon);
");
/" Inicia la instruccin SELECT en el bfer */
case SQL_CHAR: case SQL_VARCHAR: /* Asigna el bfer para la cadena de caracteres y le enlaza la columna ./ datos_elern(il : pundatos ~ malloc(size+l);
Figura 19.20.
. Empleo de eL! para consultas dinmicas. (Continuacin.)
Figura 19.20.
Empleo de eLl para consultas dinamicas. (Continuacin.)
644
645
tipo_elem{i] : SQL_C_CHAR; SQLBindCol(strntl_hdl. i, SQL_e_CHAR, indptr}; break;
pundatosr,
tama~o+l.
SQLBindCol(stmtl_hdl, indptr) ; break;
i,
SQL_C_DOUBLE,
pundatos,
sizeof(double),
case SQL_TYPE_DATE:
case case case case case case case case case case case case case case case case
SQL_TVPE_TIHE: SQL_TYPE_TIME_WITH_TIMEZONE: SQL_TYPE_TIMESTAMP: SQL_TYPE TIMESTAMP_WITH_TIMEZONE:
SQL_INTERVAL~DAY:
default: /* En aras de la caracteres de printf("No puede (integer) exit ();
sencillez, no se manejan cadenas de bits, etc. */ manejarse este tipo de datos 'd\n", type):
case SQL_INTERVAL_DAY_TO_HOUR:
SQL_INTERVAL_DAY_TO_MINUTE: SQL_INTERVAL_DAY_TO_SECQND: SQL_INTERVAL_HOUR: SQL_INTERVAL_HOUR_TO_MINUTE: SQL_INTERVAL_HOUR_TO_SECOND: SQL_INTERVAL_MINUTE: SQL_INTERVAL_MINUTE_TO_SECOND: SQL_INTERVAL_MONTH: SQL_INTERVAL_SECONO: SQL_INTERVAL_YEAR: SQL_INTERVAL_YEAR_TO_MONTH: /* Solicita la conversin ODBC/CLI de estos tipos a cadenas de caracteres de C */ datos_elem[iJ : pundatos : malloc(31); tipo_elem[i] = SQL_C_CHAR; SQLBindCol(stmtl_hdl, i, SQL_C_CHAR, pundatos, 31, indptr); break;
/* Captura y muestra las filas de resultados de la consulta "/ while (status SQLFetch(stmtl_hdl) SQL_SUCCESS)
==
,
/* Itera para imprimir los datos de cada columna de la fila / printf(-\n-): for(i = O: i < cuentacol; i++)
/* Imprime la etiqueta de la columna *1 printf(Columna nmero %d ('s): ", i+1, nombre_elem[iJ);
1" Comprueba en la variable indicadora la indicaci6n de

if valores NULL "/ (item_ind{iJ SQL_NULL_DATA){ puts(*es NULL!\n"}; continue;
==
case SQL_INTEGER: case SQL_SMALLINT: /* Convierte estos tipos a enteros largos de C */ datos_elem[i] = pundatos = malloc(sizeof(integer); tipo_elem(i) = SQL_C_SLONG; SQLBindCol(strnt1_hdl, i, SQL_C_SLONG, pundatos, sizeoflinteger), indptr) ; break; case SQL_NUMERIC: case SQL_DECIMAL: case SQL_FLOAT: case SQL_REAL:
1* Maneja cada tipo de datos devuelto (acaso convertido) por

separado I switch(item_type[i]l case SQL_C_CHAR: /* Devuelto como datos de texto - s610 se muestra */ puts(datos_elem(iJl; break:
case SQL_DOUBLE: /* A modo de ejemplo, convierte estos tipos en tipos de coma flotante de doble precisin de C */ datos_elem[i] = pundatos = malloc(sizeof(long)); tipo_elern(i] : SQL_C_DOUBLE;
case SQL_C_SLONG: /* Datos enteros de cuatro bytes - se convierten y se muestran */ printf ("Ud", * ((int o.) (datos_elem[i])}); break;
Figura 19.20:
Empleo de
eL!
para consultas dinmicas. (Continuacin.)
Figura 19.20.
Empleo de
eL!
para consultas dinmicas. (Continuacin.)
646
647
case SQL_C_DOUBLE: /~ Datos de coma flotante - se convierten y se muestran */

printf("Uf-, break; *(double )(datos_elem[i)));
printf("\nFinal de los datos.\n");
for
/* Limpia el almacenamiento asignado */ (i '" O; i < cuentacol; i++ I {
free(datos_elem[i)); free(nombre_elem[iJ) ;
)
SQLDisconnect(conn_hdl) ; SQLFreeHandle(SQL_HANDLE_STMT. SQLFreeHandle(SQL_HANDLE_DBC. SQLFreeHandle(SQL_HANDLE_ENV,
stmtl_hdl); conn_hdl); env_hdll;
SQLFreeHandle(SQL_HANDLE~STMT. stmt2_hdll;
ran atributos de esa instruccin y se asocian con un controlador de instrucciones concreto. El programa puede recuperar y definir el valor del controlador de descriptores mediante las rutinas de gestin de atributos, que se describen ms adelante en el apartado Atributos de Cll. Se utilizan dos llamadas para recuperar la informacin de los descriptores, dado su controlador. La llamada a SQLGetDescField (l recupera un campo concreto del descriptor, que se identifica mediante un valor del cdigo. Suele emplearse para obtener el tipo o la longitud de los datos de una columna de resultados de la consulta, por ejemplo. La llamada a SQLGetDescRec () recupera muchos fragmentos de informacin en una sola llamada, incluidos el nombre de la columna o del parmetro, el tipo y el subtipo de datos, su longitud, su precisin y su escala, y si pueden contener valores NULL. Se utiliza el conjunto de llamadas correspondiente para colocar la informacin en un descriptor. La llamada a SQLSetDescField () define el valor de un solo fragmento de informacin del descriptor. La llamada a SQLSetDescRec () define varios valores en una sola llamada, incluidos el tipo y el subtipo de los datos, su longitud, su precisin y su escala, y la posibilidad de que alberguen valores NULL. Por conveniencia, la eLI proporciona una llamada a SQLCopyDesc () que copia todos los valores de un descriptor en otro.
Errores e informacin de diagnstico en eL/

exit () ;
Figura 19.20.
Empleo de
eL! para consultas dinmicas. (Continuacin.)
eLI ms sencilla de utilizar y de comprender. No obstante, la eLI proporciona un mtodo alternativo de nivel inferior que ofrece posibilidades como las proporcionadas por la SQLDA incorporada. El mtodo eLI alternativo para el procesamiento dinmico de las consultas implica a los descriptores CL!. Los descriptores CLI contienen informacin de bajo nivel sobre los parmetros de una instruccin (los descriptores de los parmetros) o las columnas de resultados de las consultas (los descriptores de las filas): La informacin del descriptor es igual que la contenida en el rea de variables de la SQLDA -el nombre del parmetro o de la columna, el tipo y subtipo de los datos, su longitud, la ubicacin del bfer de datos, la ubicacin del indicador de valores NULL, etc. Los descriptores de los parmetros y de las filas se corresponden, por tanto, con las SOLDA de entrada y de salida proporcionadas por algunas marcas de SGBD en sus implementaciones de SQL dinmico incorporado. Los descriptores eLI se identifican mediante los controladores de descriptores. La CLI proporciona un conjunto predeterminado de descriptores para parmetros y para columnas de resultados de las consultas cuando se preparan las instrucciones. De manera alternativa, el programa puede asignar sus propios descriptores y utilizarlos. Los controladores de los descriptores de una instruccin se conside-
Cada funcin CLI devuelve el valor de un entero corto que indica su estado de finalizacin. Si el estado de finalizacin indica un error, se pueden utilizar las llamadas eLI de manejo de errores, mostradas en la Figura 19.21, para obtener ms informacin sobre el error y diagnosticarlo. La llamada de manejo de errores ms bsica es SQLError ( ) . El programa de aplicacin pasa Jos controladores de entorno, de conexin y de instrucciones y se devuelve en cdigo de resultado de SQL2 SQLSTATE, el cdigo de error nativo del subsistema que produce el error, y un mensaje en forma de texto.
/* Recupera la informacin de errores asociada con una llamada CL! previa */ short SQLError ( long envHdl, " IN: controlador de entorno " long connHdl, " IN: controlador de conexiones " long stmtHdl, " IN: controlador de instrucciones " char *estadosql, " OUT: valor SQLSTATE de cinco caracteres " long *errornativo, " OUT: cdigo de error nativo devuelto " " OUT: bfer para el texto del mensaje char *bufmensa. de error "
Figura 19.21.
Rutinas
eu de manejo de errores.
(Contina.)
648
649
short lonbuf,
short lonmensal
IN: longitud del bfer del texto del mensaje de error */ /* OUT: longitud real del mensaje devuelto */
/*
Determina el nmero de filas afectadas por la instruccin SQL anterior */ short SQLRowCount ( /* IN: controlador de long stmtHdl. instrucciones */ 1* OUT: nmero de filas long cuentafila)
/*
*'
1* Recupera la informacin de uno de los registros de diagnstico de

errores de la eL! short SQLGetDiagRec ( short hdltype,
long ioRdl,
*'
short
numreg.
" "
char long char

short
*estadosql, *errornativo, *bufmensa,

lonbuf.
"
" " " " "
short *lonmensa}
cdigo del t.ipo de IN: cont.rolador */ controlador eLI " IN: nmero de registro del error IN: solicit.ado " OUT: cdigo SQLSTATE devuelto de cinco caracteres " OUT: cdigo de error nat.ivo devuelt.o */ OUT: bfer para el t.ext.o del mensaje de error " longitud del bfer del texto del IN: mensaje de error " OUT: longitud real del mensaje devuelto */
La rutina SQLError () recupera realmente informacin concreta utilizada frecuentemente del rea de diagnstico de la CLl. Las otras rutinas de manejo de errores proporcionan informacin ms completa mediante el acceso directo a los registros de diagnstico creados y mantenidos por la CL!. En general, las llamadas CLI pueden producir varios errores, que dan lugar a varios registros de diagnstico. La llamada SQLGetDiagRec () recupera un solo registro de diagnostico a partir de su nmero de registro. Mediante llamadas repetidas el programa de aplicacin puede recuperar la informacin completa sobre lodos los registros de error producidos por una llamada CL!. Se puede incluso obtener informacin ms completa interrogando los campos de diagnstico del registro. Esta posibilidad la proporciona la llamada SQLGeCDiagField (). Aunque no estrictamente una funcin de procesamiento de errores, se llama a la funcin SQLRowCount (), como a las funciones de manejo de errores, despus de una llamada CLI anterior a SQLExecute (). Se utiliza para determinar el im~ pacto de la instruccin previa cuando ha tenido xito. El valor devuelto indica el nmero de filas de datos afectadas por la instruccin ejecutada previamente. (Por ejemplo, se devuelve el valor 4 para una instruccin UPDATE de bsqueda que ac tualice cuatro filas).
Atributos de
eL/
'*
Recupera un campo de uno de los registros de diagnstico de errores de la eL! */ short SQLGetDiagField /* IN: cdigo del tipo de short hdl type. controlador */ /* IN: controlador eLI * / long ioRdl, /* IN: nmero de registro del error short nurnreg I solicitado */ /* IN: Identificador del campo de short iddiag, diagnstico */ /* OUT: informacin de diagnstico void *infodiag, devuelta */ /* IN: longitud del bfer de short lonbuf, informacin de diagnstico */ /* OUT: longitud real de la informacin short *lonreall devuelta */
.,
Figura 19.21.'
Rutinas eL! de manejo de errores. (Continuacin.)
La CLI proporciona varias opciones que controlan algunos detalles del procesamiento. Algunas de ellas controlan detalles relativamente menores pero crticos, como si la eLI debiera dar por supuesto de manera automtica que los parmetros pasados como valores de cadenas de caracteres terminan en valores NULL. Otras controlan aspectos ms amplios de la operativa de la CLI, como la posibilidad de desplazamiento de los cursores. La CLI concede a los programas de aplicacin la posibilidad de controlar estas opciones de procesamiento mediante un conjunto de atributos CL!. Los atributos se estructuran en una jerarqua, igual que la jerarqua entorno/conexin! instrucciones de la estructura de controladores de la eL!. Los atributos de entorno controlan las opciones operativas globales. Las opciones de conexin se aplican a cada conexin concreta creada por la llamada SQLConnect {>, pero pueden variar de una conexin a otra. Los atributos de instrucciones se aplican al procesamiento de cada instruccin, identificada mediante un controlador CLI de instrucciones. Los programas de aplicacin utilizan un conjunto de llamadas a la CLI, que pueden verse en la Figura 19.22, para controlar los atributos. Las llamadas get (SQLGetEnvAttr (), SQLGetConnectAttr () y SQLGetStrntAttr ( obtienen los valores en curso de los atributos. Las llamadas set (SQLSetEnvAttr (l, SQLSetConnectAttr () y SQLSetStrntAttr () modifican los valores en curso de los atributos. En todas las llamadas, el atributo concreto que se est procesando viene indicado por el valor de un cdigo. Aunque el estndar eLI proporciona esta compleja estructura de atributos, realmente especifica relativamente pocos atributos. El nico atributo de entorno espe-
650
651
/* Obtiene el valor de un atributo del entorno SQL short SQLGetEnvAttr{
*'
long
envHdl.
long
void long
codiatri,
*valdevu. lonbuf.
/* /* /* /*
IN:
controlador del entorno "/
IN: cdigo entero del atributo */ OUT: valor devuelto */

IN: longitud del bfer de
long
"'oocade)
valdevu */ loO OUT: longitud de los datos reales "/
1* Define el valor de un atributo del short SQLSetEnvAttr( /* IN: long envHdl, /* IN; long codiatri, /* IN: void "valatri, /* IN: long "1oocade)
entorno SQL */ controlador del entorno */ cdigo entero del atributo "'/ nuevo valor del atributo "'/ longitud de los datos "'/
1* Obtiene el valor del atributo de una conexin SQL */ short SQLGetConneccAttr( controlador de conexiones */ /* IN: long connHdl. cdigo entero del atributo */ /* IN: long codiatri, /* OUT: valor devuelto */ void valdevu, longitud del bfer valdevu "'/ 1* IN: long lonbuf, 1* OUT: longitud de los datos reales */ long *loocade)
cificado es NULL TERMINATION; controla las cadenas de caracteres terminadas en valores nul!. El nico atributo de conexin especificado controla si la eLI llena automticamente los descriptores de parmetros cuando se prepara o ejecuta la instruccin correspondiente. Los atributos del nivel de las instrucciones controlan la posibilidad de desplazamiento y la sensibilidad de los cursores. Quizs los ms importantes de los atributos especificados por la eLI sean los controladores de los cuatro descriptores eLI que pueden asociarse con instrucciones (dos descriptores de parmetros y dos de filas). Las llamadas de la Figura 19.22 se utilizan para obtener y definir estos controladores de descriptores al utilizar el procesamiento de instrucciones basado en descriptores. La APl de ODBC, en la que se bas originalmente el estndar SQUCL!, incluye muchos ms atributos. Por ejemplo, los atributos de conexin de ODBC pueden utilizarse para especificar conexiones slo de lectura, para activar el procesamiento asncrono de instrucciones, para especificar el tiempo lmite para las soliciludes de conexin, etc. Los atributos de entorno de OnBC controlan la traduccin automtica de las llamadas ODBC de versiones anteriores del estndar DBC. Los atributos de las instrucciones de DBC controlan los niveles de aislamiento de las transacciones, especifican si los cursores son con desplazamiento y limitan el nmero de filas de resultados de las consultas que pueden generar las consultas.
L/amadas de informacin a CL/

La eLI incluye tres llamadas especficas que pueden utilizarse para obtener informacin sobre la implementacin eL!. En general, estas llamadas no las utilizan los programas de aplicacin escritos para una finalidad concreta. Son necesarias para los programas de finalidad general (como los programas de consultas o de elaboracin de informes) que necesitan determinar las caractersticas concretas de la CL! que estn utilizando. Las llamadas pueden verse en la Figura 19.23. La llamada a SQLGetFunctions () se utiliza para determinar si una implementacin dada admite las llamadas a una funcin eLI concreta. Se llama con el valor del cdigo de funcin correspondiente a una de las funciones eLI y devuelve un parmetro que indica si se admite la funcin. La llamada a SQLGetlnfo () se utiliza para obtener informacin mucho ms detallada sobre la implementacin eLI, como las longitudes mximas de los nombres de las tablas y de los usuarios, si el SGBD admite las reuniones externas o las transacciones y si los identificadores de SQL distinguen entre maysculas y minsculas. La llamada a sQLGetTypelnfo () se utiliza para obtener informacin sobre un tipo de datos admitido concreto o sobre todos los tipos de datos admitidos mediante la interfaz CLI. La llamada se comporta realmente como si fuera una consulta de un catlogo del sistema de informacin de tipos de datos. Genera un conjunto de filas de resultados de la consulta en el que cada fila contiene informacin sobre un tipo de datos admitido concreto. La informacin proporcionada indica el nombre del tipo de datos, su tamao, si admite valores nuU, si se puede buscar, etc.
/* Define el valor del atributo short SQLSetConnectAttrl /* long connHdl. /'" long codiatri. /* void "'valatri. /* long *loncade}
de una conexin de SQL */ IN: IN: IN: IN: controlador de conexiones */ cdigo entero del atributo */ nuevo valor del atributo */ longitud de los datos */
/* Obtiene el valor del atributo de una instruccin de SQL */ short SQLGetStmtAttr ( controlador de instrucciones IN: long stmtHdl. cdigo entero del atributo IN: long codiatri. OUT: valor devuelto void *valdevu. longitud del bfer de IN: long lonbuf. valdevu OUT: longitud de lo, datos reales long *loncade)
'" '" '" '" '"
"'
"'
"' "'-' "'
/* Define el valor del atributo de una instruccin de SQL */ short SQLSetStmtAttr( controlador de instrucciones */ /* IN: long stmtHdl. cdigo entero del atributo "'/ /* IN: long codiatri. nuevo valor del atributo "'/ /* IN: void *va1atri, longitud de los datos */ /* IN: long *loncarle)
Figura 19.22.
Rutinas eLl de gestin de atributos.
652
653
/* Recupera informacin detallada sobre las posibilidades de la implementacin de la eLI .. / short SQLGetlnfo ( /* IN: controlador de conexiones */ long connHdl, /* IN: tipo de informacin solicitada */ short tipoinfo, 1* OUT: bfer para la informacin vod "valinfo, recuperada */ /* IN: longitud del bfer de short lonbuf, informacin */ /'* OUT: longitud real de la informacin short *10ninfo) devuelta .,
ODBe. Tambin deseaba ofrecer una estructura en la que los fabricantes de bases de datos pudieran admitir ODBe sin abandonar sus API propietarias, y en la que el software que proporciona el soporte para una marca concreta de SOBD pudiera distribuirlo el fabricante de la base de datos e instalarse en los sistemas clientes basados en Windows como fuera necesario. La estructura en capas de ODBe y las llamadas especiales de gestin de ODBC ofrecen estas posibilidades.
La estructura de ODBC
La estructura de ODBC, tal y como se proporciona en los sistemas operativos basados en Windows o en otros sistemas operativos, puede verse en la Figura 19.24. Hay tres capas bsicas en el software ODRe software: La API llamable. En la capa superior, ODBC proporciona una sola API llamable de acceso a las bases de datos que pueden utilizar todos los programas
/* Determina el nmero de filas afectadas por la instruccin anterior de SQL */ short SQLGetFunctions /* IN: controlador de conexiones */ long connHdl, /* IN: cdigo de identificacin de la short idfunci . funcin ,o/ /* OUT: indica si se admite la short "admitida) funcin */
,. Determina la informacin sobre los tipos de datos admitidos short SQLGetTypeInfo ( ,. IN: controlador de instrucciones ., long strntHdl, ,. IN: TODOS LOS TIPOS o el tipo short tipodatosl solicitado .,
*'
Programa interactivo de consultas
Programa de anlisis de datos
J.
Programa de hoja de clculo
Programa escrito por el usuario
I elaboracin I de informes I
Programa de
API OOBC lIamable Gestor de controladores OBOC
I
Controlador
Figura 19.23.
Rutinas
eL!
de informacin sobre la implementacin.

Controlador Controlador Controlador
OBOe
OBoe
(incluidas las capas de SOL y de consultas)
OBoe
Cliente SGBD
OBoe
La API de ODBC
Microsoft desarroll originalmente la API conectividad abierta de bases de datos (Open Database Connectivity, ODBC) con el fin de proporcionar una API para bases de datos indepe~diente de las marcas para el acceso a las bases de datos en los sistemlis operativos Windows. La primera API OOBC pas a ser la base del estndar SQUCLI, que es ahora el estndar oficial ANSl/lSO para la interfaz del nivel de llamadas de SQL. La API de OOBC origina! se ampli y modific durante el proceso de normalizacin para crear la especificacin SQUCLI. Con la introduccin de la versin 3.0 de OOBC, Microsoft adapt OOBC a! cumplimiento del estndar SQUCLI. Con esta revisin, ODBe se transform en un superconjunto de la especificacin SQUCLI. OOBC va ms all de las posibilidades de SQLlCLI en varias reas, en parte porque el objetivo de Microsoft para ODBe era ms amplio que la mera creacin de una API normalizada para el acceso a las bases de datos. Microsoft tambin quera permitir, que un solo programa de aplicacin de Windows pudiera tener acceso de manera simultnea a varias bases de datos diferentes empleando la API
1
SGBO
r
Archivos locales
IOC:J
'=
l'
1
Servidor
SGBO
Servidor SGBO
Base de datos local
Base de datos del servidor
. l'
Base de datos del servidor
Figura 19.24.
Arquitectura de ODBe.
654
655
de aplicacin. La API se empaqueta en forma de biblioteca de vnculos dinmicos (dynamk/inked library, DLL), que forma parte integral de Jos diversos sistemas operativos Windows. Controladores ODBC. En la capa inferior de la estructura ODBe hay un conjunto de controladores ODBe. Hay un controlador diferente para cada una de las marcas de SOBD. La finalidad del controlador es traducir las llamadas ODBC normalizadas a las llamadas correspondientes al SOBO concreto que admite. Cada controlador puede instalarse de manera independiente en un sistema informtico concreto. Esto permite a los fabricantes de SGBD proporcionar un controlador ODBe para su marca concreta de SGBD y distribuir ese controlador de manera independiente del software del sistema operativo Windows. Si la base de datos reside en el mismo sistema que el controlador ODBC, se suele enlazar el controlador directamente con el cdigo API nativo de la base de datos. Si hay que tener acceso a la base de datos mediante una red, el controlador puede llamar a un cliente SGBD nativo para que maneje la conexin cliente/servidor, o manejar la conexin de red por s mismo. Gestor de controladores. En la capa intermedia de la estructura ODBC se halla el gestor de controladores de ODBC. Su papel es cargar y descargar los diversos controladores ODBC, a peticin de los programas de aplicacin. El gestor de controladores tambin es responsable del enrutamiento de las llamadas a la API realizadas por los programas de aplicacin al controlador correspondiente para su ejecucin. Cuando un programa de aplicacin desea tener acceso a una base de datos mediante ODBC, sigue la misma secuencia de inicio especificada por el estndar SQUCLI. El programa asigna un controlador de entorno, luego un controlador de conexiones y luego llama a SQLConnect (), especificando el origen de datos concreto al que desea tener acceso, Cuando recibe. la llamada a SQLConnect (), el gestor de controladores ODBC examina la informacin sobre la conexin proporcionada y determina el controlador ODBC necesario. El gestor de controladorescarga el controlador en la memoria si no lo est utilizando todava otro programa de aplicacin. Las llamadas posteriores del programa de aplicacin por esa conexin CLIJ ODBC concreta se encaminan a ese controlador. El programa de aplicacin puede, si es conveniente, realizar ms llamadas a SQLConnect () para otros ogenes de datos que harn que el gestor de controladores cargue de manera simultnea otros controladores para otras marcas de SGBD. El programa de aplicacin puede utilizar ODBC para comunicarse con dos o ms bases de datos diferentes, de marcas diferentes, empleando una API uniforme.
dedores para el acceso a las bases de datos, pero resulta imposible pro . porclOnar un acceso comp Ietamente transparente. Los controladores ODBC para I d . d b . . os lversos . sistemas e ases de datos pueden enmascarar fcIlmente diferencias . mas sust COsm tlcas , 1 de SQL y conjuntos A PI ,pero Id' . as herenCIas '1 en sus dla ectos f' . ancla es. son d1 lCt1 es o tropOSIbl es d O ' e enmascarar. DBC proporCIOna una solucin 1 . . . parcJa bl ema proporcIOnan do vanos OIve Ies dferentes d e capacidad ODBC a est~ pro 1 haCiendo que cada controlador ODBC se describa a s mismo mediante las llam ~ d~s ODBC/~Ll que dev~elven informacin,sobre la funcionalidad general, las fU~ ClOnes a?mUdas y los tipOS de d~tos admiudos. No obstante, la existencia de diferentes OIveles y perfiles de capacldad vuelve a llevar de hecho las diferencias entr SaBn a los programas de aplicacin, que deben tratar con esta falta de uniformi~ dad de los :on~rloladlores O~BC. En la prctica,. la inmensa mayora de los progral mas de aphcaclOn solo conflan en el nucleo bSICO central de funcionalidad ODBC y no se preocupan de caractersticas o perfiles ms avanzados. '
Funciones del catlogo de OOBC

Una de las reas en las que ODBC ofrece posibilidades que superan el estndar SQUCLI es la recuperacin de informacin del catlogo del sistema sobre la estructura de las bases de, datos, Como parte del estndar SQL DE ANSI/ISO, la CLI da or supuesto que esta mformact6n (sobre las tablas. las columnas, los Privilegios efc) est disponible mediante el esquema de la informacin de SQL2 (SQL2 lnfon:zatio~ Schema), tal y como se describe en l Captulo 16, ODBC no da por supuesta la presencIa de un esquema de la mformacln. En vez de eso, proporciona un conjunto de funciones especializadas, que pueden verse en la Tabla 19.4, que aportan la informacin sobre la estructura de los ogenes de datos. Llamando a esas funciones y procesando sus resultados, los programas de aplicacin pueden determinar en el momento de la ejecucin, la informacin sobre las tablas, las columnas los ~rivile gios, las claves primarias, las claves externas y los procedimientos alma~enados que forman la estructura de los ogenes de datos.
Tabla 19.4. Funciones de catlogo de DDBC
iValor devuelto por la eLI
Significado Instruccin completada con xito. Finalizacin con xito y con advertencia. No se han encontrado datos (al recuperar el resultado de la consulta). Hacen falta datos (falta un parmetro dinmico necesario). Error durante la ejecucin de una instruccin de SQL. Error -proporcionado controlador no vlido durante la llamada.
o
I
100
99
OOBC y la independencia del SGBO

Al proporcionar una API uniforme y su arquitectura del gestor de controladores, ODBC avanza mucho en el camino para ofrecer una API independiente de los ven-
-1
-2
656

Tabla 19.5. Funcin SQLBrowseConnect() Otras funciones ODSe
Captulo 19: las API de Sal
657
Las funciones de catlogo ODBC no suelen ser necesarias para los programas de aplicacin que se escriben para un propsito concreto. Sin embargo, resultan fundamentales para los programas de propsito general, como los programas de consulta, los generadores de informes o las herramientas de anlisis de datos. Se puede llamar a las funciones de catlogo en cualquier momento una vez establecida la conexin con el origen de datos. Por ejemplo, los programas generadores de informes pueden llamar a $QLConnect () y llamar inmediatamente despus a SQLTables () para determinar las tablas que estn disponibles en el origen de datos objetivo. Entonces se pueden presentar las tablas en una lista en la pantalla, lo que permite al usuano seleccionar las tablas que deben utilizarse para generar cada informe. Todas las funciones de catlogo devuelven su informacin como si fuera un conjunto de resultados de llna consulta. El programa de aplicacin utiliza las tc nicas ya descritas para el procesamiento de los resultados de las consultas CLI, con el fin de enlazar las columnas de informacin devuelta con las reas de las variables del programa. El programa llama luego a SQLFetch () para que trabaje con la informacin devuelta. Por ejemplo, en los resultados devueltos por la llamada a SQLTables (), cada llamada a SQLFetch () recupera informacin sobre una tabla del origen de datos.
Descripcin Proporciona informacin sobre los orgenes de datos ODBC disponibles y los atributos necesarios para conectar con cada uno de ellos. Devuelve una lista de los controladores disponibles y de los nombres de los atributos de los controladores. Funciona como una forma ampliada de la llamada SQLConnect () para el paso de informacin adicional sobre las conexiones. Devuelve el nmero de parmetros de una instruccin de SQL preparada anteriormente. Proporciona funcionalidad ampliada respecto de la llamada SQUCLI SQLBindParam ( ) . Devuelve informacin sobre un parmetro. Realiza operaciones masivas de insercin y de marcadores. Determina si hay disponibles ms resultados para una instruccin. Define la posicin del cursor dentro de un conjunto recuperado de resultados de la consulta para operaciones posicionadas. Devuelve la traduccin a SQL nativo del texto de una instruccin proporcionada de SQL que cumple ODBC.
SQLDrivers() SQLDriverConnect()
SQLNumParams () SQLBindParameter() SQLDescribeParam() SQLBulkOperations{l SQLMoreResults(l
I
I
Capacidades ampliadas de OD8C

ODBe proporciona un conjunto de capacidades ampliadas respecto a las especificadas en el estndar SQUCLI. Muchas de estas capacidades estn diseadas para mejorar el rendimiento de las aplicaciones basadas en ODBC minimizan.do el nmero de llamadasa funciones de ODRe que deben hacer los programas de aplicacin o la cantidad de trfico generada por las llamadas ODRC. Otras capacidades proporcionan caractersticas tiles para el mantenimiento de la independencia respecto de las bases de datos o ayudan a los programas de aplicacin en el proceso de conexin con las bases de datos. Algunas de las capacidades se proporcionan mediante el conjunto adicional de llamadas a funciones ODRe que puede verse en la Tabla 19.5. Otras se proporcionan mediante los atributos de las instrucciones o de las conexiones. Muchas de estas capacidades adicionales se introdujeron en la revisin 3.0 de ODRC y no las incluyen todava la mayor parte de los controladores ODRe ni las aplicaciones basadas en ODRC.
SQLSetPos()
SQLNativeSQL()
I!
mero a la funcin con informacin bsica sobre el origen de datos de destino y la funcin devuelve ms atributos de conexin necesarios (corno el nombre de usuario o la contrasea). Los programas de aplicacin pueden obtener esta informacin (por ejemplo, pidindosela al usuario) y luego volver a llamar a SQLBrowseConnect () con la informacin adicional. El ciclo contina hasta que la aplicacin baya determinado toda la informacin necesaria para una llamada con xito
a SQLConnect (l.
Capacidades de conexin extendidas

Dos de las caractersticas extendidas de ODRC se centran en el proceso de conexin.. La exploracin de conexiones est diseada para simplificar el proceso de conexin con los orgenes de datos y hacerlo ms independiente de las bases de datos. SQI:-BrowseConnect () incluye un estilo de conexin iterativo para el acceso a los orgenes de datos ODRC. Los programas de aplicacin llaman pri-
I
I
La capacidad de agrupacin de conexiones est diseada para mejorar la eficiencia del proceso de conexin y desconexin de ODBC en entornos cliente/servidor. Cuando se activa la agrupacin de conexiones, ODBC no termina realmente las conexiones de red al recibir la llamada a SQLDisconnect (l. En vez de eso, las conexiones se mantienen abiertas en un estado de inactividad durante algn tiempo y se vuelven a utilizar si se realiza alguna llamada a SQLConnect (l para el mismo origen de datos. Esta reutilizacin de las conexiones puede reducir notablemente la sobrecarga de la red y de los inicios y finales de sesin en las aplicaciones cliente/servidor que implican cortas transacciones y elevadas tasas de transacciones.
658
659
Traduccin de los dialectos de SOL

ODBe no slo especifica un conjunto de llamadas a la API, sino tambin un dialecto estndar del lenguaje SQL que es un subconjunto del estndar SQL2. Es responsabilidad de los controladores DDBC la traduccin del dialecto ODBe a instrucciones adecuadas para el origen de datos de destino (por ejemplo, modificando las expresiones de fecha y hora, los convenios sobre comillas, las palabras clave, etc.). La llamada a SQLNativeSQL () permite a los programas de aplicacin ver el efecto de esta traduccin. ODBe admite tambin las secuencias de escape que permiten que los programas de aplicacin dirijan de manera ms explcita la traduccin de las caractersticas de SQL que tienden a ser menos consistentes de unos dialectos SQL a otros, como las reuniones externas y los criterios de bsqueda de estructuras.
Ejecucin asncrona
Los controladores ODBC pueden admitir la ejecucin asncrona de las funciones ODBe. Cuando un programa de aplicacin realiza una llamada ODBe en modo asncrono, ODBC inicia el procesamiento necesario (generalmente, la preparacin o la ejecucin de la instruccin) y luego, inmediatamente, devuelve el control al programa de aplicacin. El programa de aplicacin puede seguir adelante con otro trabajo y volver a sincronizarse ms adelante con la funcin ODBC para determinar su estado de finalizacin. La ejecucin asncrona puede solicitarse conexin por conexin o instruccin por instruccin. En algunos casos, la ejecucin asncrona de funciones puede terminarse con una llamada a sQLCancel ( ), lo que concede al programa de aplicacin un mtodo para la interrupcin de las operaciones ODBC de larga duracin.
Eficiencia en el procesamiento de instrucciones
Cada llamada a ODBC para que ejecute una instruccin SQL puede implicar un'! cantidad significativa de sobrecarga, especialmente si el origen de datos implica una conexin de red cliente/servidor. Para reducir esta sobrecarga,. los controladores ODBC pueden albergar los lotes de instrucciones. Con esta capacidad los programas de aplicacin pueden pasar una secuencia de dos o ms instrucciones de SQL como si fueran un lote, para que Se ejecuten en una sola llamada a SQLExecDirect (loa SQLExecute (). Por ejemplo. una serie de una docena de instrucciones INSERT o UPOATE pueden ejecutarse de esta manera como un lote. Puede reducir de manera significativa el trfico de red en un entorno cliente/servidor, pero complica la deteccin y la recuperacin de los errores, que tienden a volverse especficos de los controladores cuando se emplean lotes de instrucciones. Muchos productos de SGBD abordan la eficiencia de las transacciones con varias inslrucciones de una manera diferente. Albergan los procedimientos almacenados dentro de la propia base de datos, que pueden reunir una secuencia de operaciones de SQL, junto con la lgica asociada de control del flujo, y permiten que se invoquen las instrucciones con una sola llamada al procedimiento. ODBC
proporciona un conjunto de posibilidades que permiten que los programas de aplicacin llamen directamente a los procedimientos almacenados en el origen de datos de destino. Para las bases de datos que permiten que se pasen por el nombre los parmetros de los procedimientos, ODBC pennite que los parmetros se enlacen por el nombre en lugar de por la posicin. Para los orgenes de datos que proporcionan informacin de metadatos sobre los parmetros de los procedimientos almacenados,la llamada a SQLDescribeParam () permite que los programas de aplicacin determinen, en el momento de la ejecucin, el tipo de datos del parmetro exigido. Los parmelros de salida de los procedimientos almacenados se admiten mediante SQLBindParam () (en cuyo caso se modifica el bfer de datos del programa de aplicacin al volver de la llamada a SQLExecute (loa SQLExecDirect ()) o mediante SQLGetData (), lo que permite la recuperacin de los datos devueltos de gran longitud. Otras dos capacidades extendidas de ODBC proporcionan eficiencia cuando hay que ejecutar de manera repetida una sola instruccin de SQL (como las instrucciones INSERT o UPDATE). Las dos abordan el enlace de parmetros para esta situacin. Con la caracterstica de compensacin de enlaces, una vez que se ha enlazado un parmetro de la instruccin y se ha ejecutado la instruccin, ODBC permite que el programa de aplicacin modifique su enlace para la siguiente ejecucin de la instruccin especificando una nueva ubicacin de memoria como compensacin de la ubicacin original. Se trata de una manera efectiva de enlazar los parmetros con elementos individuales de un array para la ejecucin repetida de instrucciones. En general, la modificacin de los valores compensados es mucho ms eficiente que volver a enlazar el parmetro con llamadas repetidas a SQLBindParam( l. Las arrays de parmetros de ODBC proporcionan un mecanismo alternativo para que los programas de aplicacin pasen varios conjuntos de valores de los parmetros en una sola llamada. Por ejemplo, si un programa de aplicacin necesita insertar varias filas en una tabla, puede solicitar la ejecucin de una instruccin INSERT parametrizada y enlazar los parmetros con arrays de valores de datos. El resultado final es como si se hubieran llevado a cabo varias instrucciones INSERT -una por cada conjunto de valores de los parmetros-o ODBC admite tanto las arrays de parmetros por filas (cada elemento del array guarda un conjuto de valores de los parmetros) como los arrays de parmetros por columnas (cada valor de los parmetros se enlaza con su pro~io array individual, que guarda sus valores).
Eficiencia en el procesamiento de consultas
En los entornos cliente/servidor la sobrecarga de la red implicada en la captura de muchas filas de resultados de las consultas puede ser muy importante. Para reducirla, los controladores ODBC pueden admitir las capturas de varias filas mediante la capacidad de cursores de bloques de ODBC. Con los cursores de bloques, cada llamada a SQLFetch () o a SQLFetchScroll (l recupera varias filas (denominadas conju1lfo actual de filas del cursor) del origen de datos. La aplicacin debe enlazar las columnas devueltas con arrays para guardar las filas de datos capturados. Se admite el enlace de filas o de columnas de los datos del conjunto de filas
660
661
utilizando las mismas tcnicas que se emplean para las arrays de parmetros. Adems, se puede utilizar la funcin SQLSetPos () para establecer una de las filas del conjunto de filas como fila en curso para las operaciones de actualizacin o de eliminacin posicionadas. Los marcadores de OnBC proporcionan un impulso diferente de eficiencia para los programas de aplicacin que necesitan operar sobre filas de datos recuperadas. Las marcadores de DBC son identificadores de filas nicos. independientes de las bases de datos para las operaciones de SQL. (Los controladores pueden utilizar realmente las claves primarias o identificadores de filas propios del SGBD u otros mtodos para soportar los marcadores, pero es transparente para el programa de aplicacin). Cuando se activan los marcadores, se devuelve un marcador (identificador de fila) por cada fila de resultados de la consulta. Los marcadores pueden utilizarse con los cursores de desplazamiento para volver a una fila concreta. Adems, pueden utilizarse para llevar a cabo actualizaciones o eliminaciones posicionadas con base en un marcador. Los marcadores tambin pueden utilizarse para determinar si una fila concreta recuperada por dos consultas diferentes es, de hecho, la misma fila o dos filas diferentes con los mismos valores de los datos. Los marcadores pueden hacer mucho ms eficientes algunas operaciones (por ejemplo, la realizacin de actualizaciones posicionadas mediante un marcador en lugar de volver a especificar un criterio de bsqueda complejo para identificar la fila). No obstante, puede haber una sobrecarga importante para algunas marcas de SGBD y algunos controladores ODBC con el mantenimiento de la informacin de los marcadores, por lo que hay que considerar detenidamente este equilibrio. Los marcadores de ODBC forman la base de las operaciones masivas de ODBC, otra caracterstica relacionada con la eficiencia. La llamada a SQLBulkOperations () permite que los programas de aplicacin actualicen, inserten, eliminen o vuelvan a capturar varias filas de manera eficiente en funcin de sus marcadores. Opera junto con los cursores de bloques y trabaja sobre las filas del conjunto de filas actual. Los programas de aplicacin colocan los marcadores de las filas que se van a ver afectadas en un aITay y en otros arrays los valores que se van a insertar o a eliminar. Luego llama a SQLBulkOperations () con un cdigo de funci6n que indica si las filas identificadas se van a actualizar, eliminar o volver a capturar, o si hay que aadir un conjunto de filas nuevas. Esta llamada elude por completo la sintaxis normal de las instrucciones de SQL para estas operacion"es y, como puede operar sobre varias filas en una sola llamada, puede ser un mecanismo muy eficiente para la insercin, la eliminaci6n o la actualizaci6n masivas de datos.
introduccin de OracleS, OCI sufri una importante revisin, y muchas de las llamadas OCI originales se sustituyeron por versiones nuevas mejoradas. Junto con Oracle9 y versiones posteriores esta nueva OCI (la versin de OracleS) es de hecho la interfaz de llamadas de Oracle para los nuevos programas. La antigua OCl (de Oracle7 y versiones anteriores) slo es importante por los programas heredados que se desarrollaron originalmente emplendola. Para referencia, las rutina,s de la antigua OC! se resumen en la Tabla 19.6, de modo
Tabla 19.6.
Funciones antiguas de la interfaz de llamadas de Oracle (Oracle7 y anteriores)
Funcin
Descripcin Inicia la sesin en una base de datos de Oraele. Abre un cursor (conexin) para el procesamiento de inslrucciones de SQL. Cierra un cursor abierto (conexin). Cierra la sesin en una base de datos de Graele. Prepara (compila) una cadena de caracteres de SQL. Ejecuta una instruccin ya compilada. Se ejecuta con un array de variables de enlace. Aborta la funcin actual de la interfaz de llamadas de Orade. Obtiene el texto del mensaje de error. Enlaza un parmetro con una variable del programa (por su nombre). Enlaza un parmetro con una variable del programa (por su nmero). Compromete la transaccin actual. Retrocede la transaccin actuaL Activa el modo de compromiso automtico. Desactiva el modo de compromiso automtico. Obtiene una descripcin de una columna de resultados de la consulta. Obtiene el nombre de una columna de resultados de la consulta. Enlaza una columna de resultados de la consulta con una variable del programa. Captura la siguiente fila de resultados de la consulta. Captura varias filas de resultados de la consulta en un array. "'Cancela una consulta antes de capturar todas las filas.
Conexin y desconexin de bases de datos
olon (l oopen () ocIase () oIogof ()

osq13 ()
Procesamiento bsico de instrucciones
oexee () oexn( ) obreak () oermsg ()

obndrv () obndrn ()
Parmetros de las instrucciones
Procesamiento de transacciorles
ocom() oroI () ocon () oeof () odse ( ) oname ( ) odefin () ofeteh () ofen () ocan ( )
Procesamiento de resultados de las consultas
La interfaz de llamadas de Oraele (OCI)

La ntenaz de programacin ms popular de Orade es SQL incorporado. No obstante, Oracle proporciona tambin una API alternativa llamable, conocida como interfaz de llamadas de Oraele (Oraele Call Interface) u OC!. OC! lleva muchos aos disponible y ha permanecido bastante estable a travs de varios ciclos importantes de actualizacin de Orade, incluidas todas las versiones de OracIe7. Con la
662
663
que se puedan reconocer los programas que puedan estar utilizando esta versin antigua. Conceptualmente, la rutinas son muy parecidas a la interfaz de SQL dinmico ncaporado. que se describen en el Captulo 18. La nueva OCI utiliza muchos de los conceptos del estndar SQUCLI y de ODBC, incluido el empleo de controladores para identificar los objetos de la interfaz. En la API hay definidos varios centenares de rutinas, y su descripcin completa queda fuera del objetivo de este libro. Los apartados siguientes identifican las principales rutinas que emplea la mayor parte de los programas de aplicacin y sus funciones.
Tabla 19.7. Rutina
Rutinas OCI de gestin de controladores Funci6n
OCIHandleAlloc() OCIHandleFree() OCIAttrGet () OCIAttrSet(}
Asigna un controlador para su empleo. Libera un controlador asignado previamente. Recupera un atributo concreto del controlador. Define el valor de un atributo concreto del controlador.
Controladores OCI
La nueva OCI utiliza una jerarqua de controladores para gestionar la interaccin con las bases de dalas de Orade, al igual que la jerarqua de controladores de SQUCLl ya descrita en el apartado Estructuras CLl. Los controladores son: Controlador de entorno. El controlador de nivel superior asociado con las interacciones OCI. Controlador de contexto del servicio. Identifica una conexin del servidor de conexiones de Orade para el procesamiento de instrucciones. Controlador de servidores. Identifica un servidor de bases de datos de Oracle (para aplicaciones multisesin). Controlador de sesiones. Identifica una sesin activa de usuario (para aplicaciones multisesin). Controlador de instrucciones. Identifica una instruccin de Oracle-SQL que se est procesando. Controlador de enlaces. Identifica UD parmetro de entrada de una instruccin de Orade. Controlador de definiciones. Identifica una columna de resultados de una consulta de Orade. Controlador de transacciones. Identifica una transaccin de SQL en evolucin. Controlador de objetos completos. Recupera los datos de un objeto de Orade. Controlador de errores. Informa y procesa los errores OCI. Los programas de aplicacin gestionan los controladores OCI empleando las rutinas que pueden verse en la Tabla 19.7. Las rutinas de asignacin y las rutinas libres funcionan como sus equivalentes SQUCLL Las funciones de atributos get y set operan como las rutinas SQUCLI de nombre parecido que consiguen y definen los atributos de entorno, de conexin y de instrucciones. Los controladores de errores se utilizan para devolver informacin de OCI a la aplicacin. Los controladores de errores que hay que utilizar para la comunicacin de errores suelen pasarse como parmetros para las llamadas OCL Si el estado de devolucin indi.ca un error, se puede recuperar del controlador de errores la informacin sobre el error empleando OCIErrorGet ( ).
Conexin a un servidor de Oraele

La secuencia de inicializacin y de conexin para OCI es igual que las ya ilustradas para CLUODBC y para dbl ib. Las rutinas OCI asociadas con la gestin de conexiones se pueden ver en la Tabla 19.8. Los programas de aplicacin llaman primero a OCllni tialize () para inicializar la interfaz de llamadas de Drade. Esta llamada tambin indica si se va a utilizar OCI en modo multihebra, si el programa de aplicacin va a utilizar las funciones del modo de objetos de OCI y otras opciones. Tras la inicializacin los programas de aplicacin llaman a OCIEnvIni t () para inicializar los controladores de entorno. Al igual que con CLUDDBC. todas las interacciones OCI tienen lugar en el contexto del entorno definido por estos controladores.
Tabla 19.8. Rutinas DCI de inicializacin y de gestin de conexiones

Rutina
OCIInitialize() OCIEnvlnit () OC lLagan () oCILagoff () oCIServerAttach() OCIServerDetach() OCIServerVersian() OCISessionBegin() OCIPasswordChange() OCISessionEnd()
Funcin Inicializa la interfaz de llamadas de Draele para utilizarla. Establece un controlador de entorno para la interaccin con la OC!. Se conecta con un servidor de bases de datos de Drade para una sesin OCL Termina una conexin previa de inicio de sesin. Se conecta a un servidor de Graele para operaciones multisesin. Se desconecta de un servidor de Oraele. Devuelve la informacin sobre la versin del servidor. Comienza una sesin de usuario en un servidor conectado previamente. Cambia la contrasea de un usuario en el servidor. Finaliza una sesin de usuario iniciada previamente.
664
665
Tras estos pasos iniciales la mayor parte de las aplicaciones llaman a OCILogon () para establecer una sesin con un servidor de bases de datos de Orade. Las llamadas OCI posteriores tienen lugar en el contexto de esa sesin y utilizan la identificador de usuario proporcionada para determinar sus privilegios dentro de la base de datos de Oracle. Las llamadas a OCILogoff () terminan la sesin. Las otras llamadas proporcionan una gestin de la sesin ms avanzada para las aplicaciones multihebra y multiconexin. Las llamadas a OCIServerVersion () pue~ den utilizarse para determinar la versin del software del servidor de Oracle. Las llamadas a oCIChangePassword () se pueden utilizar para modificar las contraseas caducadas.
Ejecucin de instrucciones
Las funciones OCI que pueden verse en la Tabla 19.9 implementan la ejecucin de instrucciones de SQL. OCIStmtPrepare () y OCIStmtExecute () admiten el pro-
Tabla 19.9.
Rutinas OCI de procesamiento de instrucciones y de manejo de parmetros
ceso de dos etapas de preparacin y ejecucin. La funcin OCIStmtExecute () tambin puede utilizarse para describir los resultados de las consultas (de manera parecida a la instruccin de SQL incorporado DESCRIBE), sin ejecutar realmente la consulta, pasando una bandera especfica. OCl proporciona de manera automtica una descripcin de los resultados de la consulta cuando se llama a OCIStmtExecute () en el modo de ejecucin normal de las instrucciones. La descripcin est disponible como atributo del controlador de instrucciones de la consulta ejecutada. . Las funciones OCIBindbyPos () y ocrBindbyName () se utilizan para enlazar las ubicaciones de los programas de aplicacin con los parmetros de las instrucciones, bien sea empleando las posiciones de los parmetros, bien los nombres de los parmetros. Estas llamadas asignan de manera automtica controladores de enlaces para Jos parmetros cuando se los llama, o pueden llamarse con controladores de enlaces asignados de manera explcita. Las otras llamadas implementan tcnicas de enlace ms avanzadas, incluidos el enlace de varios valores de los parmetros (arrays) y el enlace de tipos de datos de objetos complejos. Tambin proporcionan el procesamiento de los parmetros (y de los resultados de las consultas) en el momento de la ejecucin, lo que se corresponde con el modo de parmetros diferidos soportado por CLIIODBC y ya descrito en el apartado Procesamiento de instrucciones CLl. Las llamadas de infonnaci6n sobre fragmentos admiten este modo de informacin.
Rutina
Funcin
OCIStmtPrepare(} OCIStmtExecute() OCIBreak () OCIBindbyPos () OCIBindbyName () OCIStmtGetBindInfo() OCIBindArrayOfStruct() OCIBindDynarnic () OCIBindObject() OCIStmtGetPiecelnfo{)
OCIStrntSetPiecelnfo()
Prepara una instruccin para ejecutarla. Ejecuta una instruccin ya preparada. Aborta la operacin OCI en curso en el servidor. Enlaza un parmetro con base en su posicin. Enlaza un parmetro con base en su nombre. Obtiene el nombre de las variables de enlace e indicadoras. Configura el enlace de arrays para el paso de varios valores de parmetros. Registra una rutina de rellamada para un parmetro ya enlazado que va a utilizar el enlace en el momento de la ejecucin. Proporciona informacin adicional de un parmetro ya enlazado con un tipo de datos de objeto complejo. Obtiene informacin sobre el valor de un parmetro dinmico fragmentario necesario en el momento de la ejecucin para la OCI (o una columna de resultados fragmentarios de la consulta en proceso de devolucin). Define la informacin (bfer, valor, indicador, etc.) del valor de un parmelfo dinmico fragmentario que se le proporciona a la OCI en el momento de la ejecucin (o una columna de resultados fragmentarios de la consulta que se acepta en el momento de la ejecucin).
Procesamiento de los resultados de una consulta

Las funciones OCl que pueden verse en la Tabla 19.10 se utilizan para procesar resultados de las consultas. La funcin OCIDefineBypos () se utiliza para enlazar una columna de resultados de la co~sulta (identificada por su nmero de columna)
Tabla 19.10.
Rutinas OCI de procesamiento de resultados de consultas
Rutina
Funcin
OCIStrntFetch() OCIDefineByPos() OCIDefineArrayofStruct() OCIDefineDynamic()
OCIDefineObject()
Captura una o varias filas de resultados de la consulta. Enlaza con una columna de resultados de la consulta. Configura el enlace de arrays para la recuperacin de varias filas de resultados. Registra una rutina de retrollamada para el procesamiento dinmico de una columna de resultados de la consulta. Proporciona informacin adicional de una columna de resultados de la consulta ya enlazada con un tipo de datos de objeto complejo.
666

Tabla 19.12.
667
con una ubicacin de almacenamiento del programa. (La terminologa OCI se refiere a esto como proceso de definicin; el trmino enlace queda reservado para
los parmetros de entrada.) Las otras llamadas de definicin admiten enlaces dinmicos (en el momento de la ejecucin). enlaces de arrays (para operaciones de capLUea multifila) y el enlace de tipos de datos de objetos complejos. La llamada a OCIStrntFetch () recupera una fila de resultados de la consulta y proporciona funcionalidad a la instruccin de SQL FETCH.
Rutinas OCI de gestin de transacciones
Rutina
OCITransComrnit() OCITransRollback() OCITransStart() OCITransPrepare()
Function
Compromete una transaccin. Hace retroceder una transaccin. Inicia o reconecta una transaccin especial. Se prepara para 90mprometer una transaccin distribuida. Olvida una transaccin preparada anteriormenle. Desconecta una transaccin distribuida.
Manejo de descriptores
OCI utiliza los descriptores para proporcionar informacin sobre los parmetros,
los objetos de las bases de datos de Oracle (tablas, vistas, procedimientos almacenados, etc.), los objetos de gran tamao, los identificadores de las filas y otros
OCITransForget() OCITransDetach()
Manejo de errores
objetos OCI. Los descriptores proporcionan informacin al programa de aplicacin y se utilizan en algunos casos para gestionar los detalles del procesamiento de esos objetos. Las rutinas que pueden verse en la Tabla ]9.J 1 se utilizan para gestionar los descriptores. Asignan y liberan los descriptores y recuperan y definen los valores de cada dato de los descriptores.
Gestin de transacciones
Los programas de aplicacin utilizan las funciones que pueden verse en la Tabla 19.12 para implementar la gestin de transacciones de SQL. Las llamadas a OCITransConuni t () y a OCITransRollback () ofrecen la posibilidad bsica de comprometer y de hacer retroceder las transacciones, y se corresponden con las instrucciones normales de SQL COMMIT y ROLLBACK. Las dems funciones proporcionan un esquema de transacciones muy rico y complejo, incluida la especificacin :Je transacciones s610 de lectura, serializables y acopladas de manera laxa o fuerte, y el control sobre las transacciones distribuidas. Las rutinas de gestion de transacciones llevan un controlador de contexto de servicios que identifica una conexin en activo como parmetro de entrada,
Las funciones OCI devuelven un cdigo de estado que indica si se han completado con xito. Adems, la mayor parte de las funciones OCI aceptan los controladores de errores como parmetros de entrada. Si se produce un error durante el procesamiento, la informacin del error se asocia con el controlador. A la vuelta de la funcin, el programa de aplicacin puede llamar a OC;IErrorGet () para el controlador de errores con el fin de obtener ms informacin sobre el error, incluido el nmero y el mensaje de error.
Informacin del catlogo
La llamada a OCIDescribeAAY () proporciona acceso a la informacin del catlogo del sistema de Orade. Los programas de aplicacin llaman a esta rutina con el nombre de una tabla, vista, sinnimo, procedimiento almacenado, tipo de datos u otro objeto del esquema de Orade. La rutina rellena un descriptor (identificado mediante un controlador de descriptores) con informacin sobre los atributos del objeto. Las llamadas posteriores a OCIAttrGet () para el controlador del descriptor pueden utilizarse para obtener los datos completos del objeto en el momento de la ejecucin.
Manipulacin de objetos de gran tamao
Tabla 19.11.
Rutinas OCI de gestin de descriptores
Rutina
OCIDescriptorAlloc() OCIDescriptorFree() OCIParamGet () OCIParamSet (l
Funcin
Asigna un descriptor o un localizador LOB. Libera un descriptor asignado anteriormente. Consigue un descriptor para un parmetro. Define un descriptor de parmetros en un controlador complejo de recuperacin de objetos.
OCI inc;luye un gran grupo de rutinas, que pueden verse en la Tabla 19.13, para el procesamiento de los tipos de datos para objetos de gran tamao de OracIe (Large Object, LOB) y los objetos de gran tamao almacenados en archivos a los que hacen referencia las columnas de Orade. Como los objetos de gran tamao pueden tener longitudes de decenas de millares o millones de bytes. no se suelen poder enlazar directamente con los bferes de los programas de aplicacin en su totalidad. En lugar de eso, OC! utiliza los ioealizadores de LOB, que funcionan como los controladores para los elementos de datos LOB. Los Iocalizadores se devuelven para los datos LOB en los resultados de las consultas y se utilizan como parmetros de entrada para los datos LOB que se insertan o actualizan. Las rutinas de manejo
668
SOL. Manual de referenc;a

Rutinas OCI para el procesamiento de objetos de gran tamao
669
Tabla 19.13.
Rutina
OCILobRead ()
Funcin
Lee un fragmento de un LOB para el rea de datos del programa de aplicacin. Escribe los datos del rea de datos del programa de aplicacin en un LOB.
Aade datos al final de un LOB.
de Java. En consecuencia, todos los productos de los principales SGBD ofrecen soporte de Java mediante JDBC; no hay ninguna API competidora de importancia.
Historia y versiones de JDBC

La API JDBe ha sufrido varias revisiones importantes desde su primera versin. IDBC 1.0 proporcionaba el ncleo bsico de la funcionalidad de acceso a datos, incluido un gestor de controladores para arbitrar las conexiones con varios SGBD, la gestin de las conexiones para el acceso a cada base de datos, la gestin de las instrucciones para el envo de comandos de SQL al SGBD y la gestin de conjuntos de resultados para proporcionar el acceso Java a los resultados de las consultas. La API JDBC 2.0 y sus modificaciones sucesivas ampliaron JDBC 1.0 y dividieron la funcionalidad entre una API central y varias extensiones de la API. La versin 2.0 aadi: Operaciones por lotes. Los programas Java pueden pasar muchas filas de datos para insertarlas o actualizarlas mediante una sola llamada a la API, lo que mejora el rendimiento y la eficiencia de las operaciones masivas. Conjuntos de resultados con desplazamiento. Al igual que los cursores de desplazamiento proporcionados en otras API, esta posibilidad nueva permita el movimiento hacia delante y hacia atrs por los resultados de las consultas. Conjuntos de resultados actualiza;les. Los programas de Java pueden actualizar la base de datos mediante la actualizacin de una fila concreta de resultados de la consulta o la insercin en el resultado de una nueva fila. Agrupacin de conexiones. Las conexiones con las bases de datos pueden compartirse entre los programas de Java, lo que reduce la sobrecarga de las conexiones y desconexiones frecuentes. Transacciones distribuidas. La API proporciona la posibilidad de sincronizar las actualizaciones de varias bases de datos, con transacciones a todo o nada que amplan los lmites de las bases de datos. Orgenes de datos. Un nuevo tipo de objeto encapsula los detalles de las conexiones de las bases de datos, lo que reduce la necesidad de que los programadores de aplicaciones comprendan los detalles de las conexiones. Conjuntos de filas. Abstraccin de los resultados de las consultas, los conjuntos de filas permiten tanto el procesamiento de los resultados de las consultas, aunque el programa est desconectado de la base de datos de origen, como su posterior resincronizacin. Soporte de la interfaz Java de nombres y directorios (Java Naming & Directory Interface, JNDI). Las bases de datos y los controladores se pueden denominar y catalogar en un directorio de red y se puede tener acceso a ellos mediante esas entradas del directorio. La API JDBC 3.0 es una versin relativamente nueva de JDBC. Sun la finaliz y la anunci formalmente en febrero de 2002, y se distribuye como parte de Java2
OCILobWrite()
OCILobAppend ()
OCILohErase (l
OCILobTrim ()
Borra
dato~
de un LOB.
Trunca los datos del final de un LOB.
OCILobGetLength() OCILobLocatorIslnit()
OCILobCopy ()
Obtiene la longitud de un LOB.
Comprueba si es vlido el localizador de un Copia los datos de un

LOS
LOS.
a otro.
LOS
OCILobAssign () OCILobIsEqual () OCILobFileOpen ()
Asigna el localizador de un
a otro.
LOB.
Compara dos localizadores de Cierra un archivo

LOS
LOS.
Abre un archivo que contiene datos Cierra todos los archivos

LOE
OCILobFileClose()
abierto anteriormente. abiertos anteriormente.

LOE. LOS,
OCILobFileCloseAll()
OCILobFileIsOpen() OCILobFileGetName() OCILobFileSetName()
Comprueba si est abierto un archivo Obtiene el nombre de un archivo localizador LOB. Define el nombre de un archivo
LOE.
dado un
LOS
en un localizador
OCILobFileExists()
OCILobLoadFromFile()
Comprueba si existe un archivo Carga un

LOE
LOB.
de un archivo
LOB.
LOS admiten el procesamiento fragmentario de los datos LOS, lo que permite que se transfieran entre las bases de datos de OracIe y los programas de aplicacin. Las rutinas aceptan uno o varios IDealizadores LOS como parmetros.
Conectividad con bases de datos Java (JDBC

JDBC es una API llamable de SQL para el lenguaje de programacin Java. JDBC es, a la vez, el estndar oficial y el estndar de facto para el acceso a las bases de datos de SQL desde Java. Para el lenguaje de programacin C, los fabricantes de SGBD desarrollaron sus propias API propietarias mucho antes del desarrollo de ODBC O de la API SQL-CLI. Para Java Sun Microsystems desarroll la API JDBC como parte de una familia de varias API de Java, incluidas en diversas ediciones
670
671
Standard Edition (J2SE) 1.4. Entre las nuevas posibilidades introducidas en la versin 3.0, figuran:
Extensiones SQL para objetos relacionales. La API aade el soporte para

los tipos de datos abstractos y las posibilidades asociadas que se agregaron en el estndar SQL:1999. Puntos de revisin. La API permite el retroceso parcial a un punto de revisin marcado de manera especfica a mitad de cada transaccin.
Programa
de aplicacin Java
Java
Java
~
J,.
J,.
J,.
API JDBC
Conservacin de los cursores. Las opciones de la API permiten que los cursores permanezcan abiertos de unas transacciones a otras.
Metadatos de las instrucciones preparadas. Los programas pueden determinar la informacin sobre las instrucciones preparadas, como el nmero y tipo de datos de los parmetros y de las columnas de los resultados de las consultas.
Controlador JDBC 1
Gestor de controladores JDBC
Controlador
JDBC 2
Implementaciones de JDBC y tipos de controladores

JDBC da por supuesta una arquitectura de controladores como la proporcionada por el estndar DBC. en la que se basa principalmente. La Figura 19.25 muestra los principales elementos de esta arquitectura. Los programas de Java se conectan con el gestor de controladores JDBC mediante la API JDBC. El software del sistema IDBC es responsable de la carga de uno O varios controladores JDBC, generalmente a peticin de los programas de Java que los solicitan. Conceptualmente, cada controlador proporciona acceso a una marca concreta de SGBD, realizando las llamadas a la API propias de cada marca y enviando las instrucciones de SQL necesarias para llevar a cabo la solicitud JDBC. El software de IDBC se entrega en forma de paquete de Java, que se importa a los programas de Java que desean utilizar JDBC. La especificacin JDBC no entra en los detalles concretos del modo en_ que se implementa cada controlador IDBC. No obstante, desde la introduccin de JDBC, los desarrolladores han tendido a caracterizar los controladores JDBC en cuatro tipos. Las descripciones de los tipos dan por supuesta una conexin cliente/servidor entre la API JDBC (en el sistema cliente) y un servidor de bases de datos. Aunque se trata de una arquitectura de implantacin empresarial frecuente, merece la pena observar que JDBC se utiliza para tener acceso a las bases de datos locales en sistemas tan pequeos como los dispositivos de mano; en ese contexto, los tipos de controladores tienen menos significado. Los tipos de controladores se diferencian en el modo en que traducen las llamadas JDBC (invocaciones de mtodo) en acciones concretas contra el SGBD. Los controladores de tipo 1 se denominan tambin puentes JDBC/ODBC, y pueden verse en la Figura 19.26. El controlador traduce las llamadas a JDBC a una API neutral respecto a los fabricantes, que en la prctica siempre es OnBC. La solicitud pasa a un controlador ODBC especfico para el SGBD objetivo. (De manera opcional, se puede eliminar el controlador ODBC, ya que la API ODBC para el gestor de controladores es la misma que la API para el propio controlador.) Fi-
J
SGSD
local I
1
SGSD
del servidor
..
Figura 19.25.
Componentes de la arquitectura JD8C.
nalmente, el controlador ODBC llama a la API propietaria del SGBD. Si la base de datos se halla en un sistema local, el SGBD lleva a cabo la solicitud. Si se halla en un sistema remoto (servidor), el cdigo del SGBD para el cliente es un resguardo del acceso remoto, que traduce la solicitud a un mensaje de red (propietario para el SGBD) y lo enva al servidor de SGBD. Los controladores de tipo 1 tienen una ventaja significativa. Como casi todos los productos de SGBn populares soportan ODBC, un solo controlador de tipo 1 puede proporcionar acceso a docenas de marcas de SGBD diferentes. Los controladores de tipo l son fciles de encontrar, incluido uno distribuido por Sun. Los controladores de tipo 1 tambin tienen varios inconvenientes. Cada solicitud de IDBC pasa por muchas capas en su camino de ida y vuelta al SGBD. por lo que los controladores de tipo 1 suelen acumular mucha sobrecarga y, en consecuencia, su rendimiento se resiente. El empleo de ODBe como etapa intennedia puede limitar tambin la funcionalidad proporcionada por los controladores -puede que median-
672
673
Programa
de aplicacin Java
I
!
..
API JD8C
Gestor de controladores JOBC Controlador JDBe (Tipo 1)

~
T
APIOOSe Gestor de controladores Controlador DDBe para
Los controladores de lipo 2 tambin se denominan controladores API nativos. Los controladores traducen las solicitudes JDBe directamente a la API nativa del SGBD, como puede verse en la Figura 19.27. A diferencia de los controladores de tipo 1, no est implicada ODBC ni ninguna otra capa neutral respecto a los fabricantes. Si la base de datos se ubica en el mismo sistema que el programa de Java, las llamadas del controlador de tipo 2 a la API nativa van directamente al SGBD. En las redes cliente/servidor el cdigo SGBD del cliente vuelve a ser un resguardo de acceso a la red y las solicitudes fluyen por la red en un protocolo propietario del SGBD, como en los controladores de tipo l. Los controladores de tipo 2 presentan un conjunto diferente de equilibrios que los del tipo 1. Los controladores de tipo 2 tienen menos capas, por 10 que el rendimiento suele ser mayor. Siguen presentando el inconveniente de necesitar la instalacin de cdigo binario en el sistema cliente, por lo que los controladores de tipo 2
oose
Programa de aplicacin Java
I
SGBD xYZ
/"'APIXVZ
SGBD local XVZ
+
API JDBC
API XVZ
Ciente SGBD
Gestor de controladores JDB Controlador JOBC (npo 2)
I I
XVZ
~
"'API XYZ Servidor SGBO local XVZ API XYZ Cliente SGBO XVZ
SGSO
XVZ
.1
..
-l
Servidor SGBO XVZ
Figura 19.26.
Controlador JOBC de tipo 1.
-l
te ODBC no sean accesibles caractesticas del SGBD subyacente que podan ofrecerse directamente mediante la interfaz JDBe. Finalmente, los controladores DBC exigidos por los controladores de tipo 1 se ofrecen en forma binaria, no como ejecutables Java. Por tanto, los controladores de tipo 1 son especficos del hardware y del sistema operativo de cada computadora cliente y carecen de la portabilidad de Java.
Figura 19.27.
Controlador JDBC de tipo 2.
674
675
siguen siendo especficos de la arquitectura del hardware y del sistema operativo. A diferencia de los controladores de tipo 1, los controladores de tipo 2 tambin son especficos de la marca del SGBD. Si se desea establecer comunicacin con varios SOBD, harn falta varios controladores. Finalmente, merece la pena observar que la distincin entre tipo 1 y tipo 2 da por supuesto que la API nativa del SGBD no es DBC. Si el SGBD presenta una interfaz DBC nativa, el empleo de ODBC no supone una capa adicional y su controlador de tipo 2 utilizar, de hecho. OOBe para tener acceso al SOBD. Los controladores de lipo 3 son controladores neutrales ante la red. Los controladores traducen las solicitudes IDBe a mensajes de red en un formato neutral respecto a los fabricantes y los enva por la red hasta el servidor, como puede verse en la Figura 19.28. En el servidor una capa intermedia recibe las solicitudes de red
Pmg"m, do ,plk,d6n I!
Java
API JDSC Gestor de controladores JDBC Controlador JDBC ITipo3)
Protocofo de red neutral respecto a los fabricantes
Agente de acceso a la base de datos
1
API XYZ Servidor SGSD
XVZ
..L
..
Figura 19.28.
Controlador JD8C de tipo 3.
y las traduce en llamadas a la API nativa del SGBD. Los resultados de las consultas se vuelven a pasar por la red, nuevamente en un formato respecto a los fabricantes. L05 controladores de tipo 3 vuelven a presentar un conjunto diferente de equilibrios. Una ventaja importante anunciada para la arquitectura de tipo 3 es que el cdigo del lado del cliente puede escribirse en Java, empleando las interfaces de red proporcionadas por otras API de Java. Obsrvese tambin que el cdigo del lado del cliente es neutral respecto al SGBD; realiza la misma funcin independientemente del SGBD de destino en el servidor. Esto significa que el cdigo del lado del cliente es muy portable y puede ejecutarse en cualquier sistema que incorpore una mquina virtual de Java (Java Virtual Machine. JVM) y las API de red de Java. Los controladores de tipo 3 comparten un inconveniente con los del tipo 1: el empleo de una capa neutral respecto a los fabricantes, al igual que el de una capa ODBC neutral respecto a los fabricantes, implica que algunas de las posibilidades del SGBD subyacente puedan quedar inaccesibles a travs de la capa intermedia. La arquitectura de tipo 3 tambin implica una traduccin doble de cada solicitud JDBC, igual que en el tipo 1; no obstante, una de las traducciones tiene lugar en el sistema servidor, lo que minimiza su impacto en el lado del cliente. Los controladores de tipo 4 son controladores propietarios de red. Los controladores traducen las solicitudes JDBC en mensajes de red, pero esta vez en un formato propietario de cada SGBD, como puede verse en la Figura 19.29. Los controladores se escriben en Java e implementan un cliente de red para el software de red de cada SGBD, corno SQL*Net de Oracle. En el servidor no hay necesidad de ninguna capa intermedia, ya que el servidor del SGBD ya proporciona soporte para la red cliente/servidor propia del fabricante del SOBD. Los resultados de las consultas vuelven por la red nuevamente en formato propietario de cada fabricante y se devuelven al programa solicitante. Los controladores de tipo 4 conservan una de las ventajas importantes de los del tipo 3. Pueden implementarse en Java puro, por lo que, como los del tipo 3, son portables de un hardware informtico a otro y de unos sistemas operativos a otros. Sin embargo, a diferencia de los controladores del tipo 3, son especficos de cada SGBD, por lo que se necesita diferente cdigo del lado del cliente para cada marca de SOBD a la que se desee tener acceso. La arquitectura de tipo 4 implica menos sobrecarga en el sistema servidor y puede, ppr tanto, ofrecer un rendimiento algo mejor. En la prctica, la sobrecarga de la mensajera de red casi siempre anula esta ventaja, excepto en aplicaciones con tasas de lransacciones muy elevadas. La Figura 19.30 resume los cuatro tipos de controladores JDBe y muestra el modo en que se relacionan entre s. Las dos columnas dividen los tipos de controladores de acuerdo con su empleo de una capa intermedia neutrl respecto a los fabricantes (columna izquierda) o de la traduccin directa de la API JDBC a una interfaz propietaria del SGBD. Las dos filas dividen los tipos de controlador segn la traduccin a una API concreta del SGBD, ocurra en el lado del cliente (fil.a superior) o en el lado del servidor. Como muestra la figura, cada una de estas dos decisiones crea equilibrios, y dan lugar a cuatro (2x2) tipos de controladores.
676
677
-----.----....~ ...--... Acceso a la base de datos -.----..---....-------I
Java
Mediante API neutral respecto Directo a la API propietario al fabricante (ODSC) del fabricante
.L
API JOBC
lD
lO
Gestor de controladores JDBC

Controlador JDBC
(Tipo 4)
(f)
"O
O;
"O
~
o
O;
"O
Controlador de tipo 1
;:
"C
~
<:
"O
!!!
<;
"O
-~
1
APIXYZ Cliente XVZ
o .
:; :>
"" O; ~
~
"O "O
~ Pro'o
red
prop'
yz
Figura 19.30.
Tipos de controladores JDBC y compromisos.
SelVidor SGBD
XYZ
I ...
Objetos conjunto de resultados. Representan los resultados de las consultas de SQL. Objetos metadatos. Representan metadatos sobre bases de datos, resultados de consultas e instrucciones. Objetos excepcin. Representan errores en la ejecucin de las sentencias de SQL. Estos objetos tienen la relacin lgica que puede verse en la Figura 19.31, basada en los objetos que proporcionan mtodos para crear otros objetos. Los apartados siguientes describen cada uno de estos objetos y el modo en que se emplean sus mtodos para conectar con las bases de datos, ejecutar instrucciones de SQL y procesar los resultados de las consultas. La explicacin completa de la API IDBe excede el objetivo de este libro, pero los conceptos descritos deben permitir que ellector realice un empleo efectivo de IDBe y que comprenda la documentacin que se entrega con el paquete. El objeto DriverManager es la interfaz principal con el paquete IDBe. Algunos de los mtodos ms importantes que proporciona se muestran en la Tabla 19.14. Tras cargar la clase de controladores IDBe que se desea utilizar (generalmente empleando el mtodo Class. forName ()), el programa pide al objeto DriverManager que conecte con el controlador y la base de datos concretas con el mtodo getConnection ( ) :
II Crea una conexi6n con el controlador JDBC de Oracle
Figura 19.29.
Controlador JOBC de tipo 4.
La API de JDBC
Java es un lenguaje orientado a objetos. por lo que no es probable que sea una sorpresa que IDBe organice sus funciones API en torno a un conjunto de objetos relacionados con las bases de datos y los mtodos que proporcionan:
Objeto gestor de controladores. El punto de entrada a IDEC.
Objetos conexin. Representan conexiones activas con las bases de datos de destino. Objetos instruccin. Representan instrucciones de SQL que hay que ejecutar.
String url : - .. varia en funcin del SO, etc," String usuario: "Santi"; String contra: "Tigre-; Connection dbconn ~ DriverManager.getConnection(url, usuario, contra);
678
679
.Objeto conexin
Objeto meladalos de la base de dalos
El mtodo getConnection () devuelve un objeto, el objeto Connection, que e'lcarna la conexin que se acaba de crear y la base de daro~del otro lado de esa conexin. Otros mtodos DriverManager proporcionan control mediante programacin de los tiempos lmites de conexin, activan el registro histrico de llamadas de JDBC para la depuracin y otras funciones de utilidad. Si halla un error mientras intenta establecer la conexin, el objeto DriverManager genera una excepcin. El manejo de errores se describe ms adelante en este captulo en el apar tado Manejo de errores en IDBC.
createStatement() prepareStatement()
Procesamiento bsico de instrucciones en JDBC

Las principales funciones del objeto de IDBC Connection son la gestin de la conexin con la base de datos, la creacin de instrucciones de SQL para su procesamiento por esa base de datos y la gestin de las transacciones a travs de la conexin. La tabla 19.15 muestra los mtodos del objeto Connection que proporcionan esas funciones. En los programas de IDBC ms sencillos, el paso siguiente al establecimiento de una conexin es llamar al mtodo createStatement (l del objeto Connection para crear un objeto Statement. La principal funcin de los objetos Statement es ejecutar realmente las instrucciones de SQL. La Tabla 19.16 muestra los mtodos d! objeto Statement. que se utilizan para controlar la ejecucin de las instrucciones. Hay varios mtodos execute () diferentes, en funcin del tipo concreto de instruccin de SQL. Las instrucciones sencillas que no generan resultados de consultas (por ejemplo, UPDATE, DELETE, INSERT. CREATE TABLE) pueden utilizar el mtodo execu teUpTabla 19.15. Mtodos JDBC del objeto Connection
Mtodo Descripcin
preparecall ()
/-
~--'''---" /-~'---"
Objeto instruccin lIamable
Objeto instruccin
getParameterMetaData()
Objeto conjunto de resultados
Objeto meladatos de parmetros
Objeto roeladalos
del conjunto de
resultados
Objeto excepcin
Figura 19.31.
Objetos principales empleados por la API JDBC.
Close () createStatement() prepareStaternent()
Cierra la conexin con el origen de datos. Crea un objeto Statement para la conexin. Prepara para su ejecucin una instruccin de SQL parametrizada en un objeto PreparedStatement. Prepara para su ejecucin una llamada parametrizada a un procedimiento almacenado o a una funcin en un objeto callableStatement. Compromete la transaccin en curso en la conexin. Hace retroceder la transaccin en curso en la conexin. Define y reinicia el modo de compromiso automtico de la conexin. Recupera advertencias de SQL asociadas con una conexin. Devuelve un objeto DatabaseMetadata con informacin sobre la base de datos.
Tabla 19,14.
Mtodos del objeto DriverManager
prepareCall() Mtodo
getConnection ()
Descripcin
Crea y devuelve un objeto de conexin de la base de datos, dado un URL para el origen de datos y. opcionalmente, un nombre de
commit () rollback( ) setAutoCommit() getWarnings (J GetMetaData
usuario y una contrasea, y las propiedades de la conexin.

registerDriver() setLoginTimeout() getLoginTimeout()
setLogWriter ()
Registra un controlador ante el gestor de controladores JDBC. Define el tiempo lmite para el inicio de sesin de cada conexin. Obtiene el valor del tiempo lmite para el inicio de sesin. Activa el seguimiento de las llamadas JDBC.
I
1\
680
681
Tabla 19.16.
Mtodos JDBC del objeto Statement
Mtodo
Descripcin
bsica.~
Connection dbconn; 11 La conexin de la base de datos String strl = UPDATE OFICINAS SET OBJETIVO = O"; String str2 = "DELETE FROM REPRESENTANTES WHERE NUM_EMPL = 106";
<el cdigo que crea la conexin >
Ejecucin de instrucciones
executeUpdate() executeQuery () execute ()
Ejecuta una instruccin de SQL que no es una consulta y devuelve el nmero de filas afectadas. Ejecuta una sola consulta de SQL y devuelve un conjunto de resultados. Ejecucin de propsito general de una o varias instrucciones de SQL.
/1 Crea un objeto statement para ejecutar SQL Statement stmt = dbconn.createStatement();
Ejecucin de instrucciones por lotes

addBatch ()
11 Actualiza la tabla OFICINAS con el objeto instruccin stmt.executeUpdate{strl);
Almacena los valores de los parmetros proporcionados anteriormente como parte de un lote de valores para su ejecucin.
Ejecuta una secuencia de instrucciones de SQL; devuelve un arfay de enteros que indican el nmero de filas afectado por cada una de eUas.
// Actualiza la tabla REPRESENTANTES con el objeto instruccin stmt.executeUpdate(str2);
executeBatch (1
1/ Compromete las modificaciones de la base de datos dbconn.commit():
Limitacin de los resultados de la consulta

setMaxRows () getMaxRows () setMaxFieldSize() getMaxFieldSize{) setQueryTimeout() getQueryTimeout()
Limita el nmero de filas recuperadas por una consulta. Recupera el

va~or
actual del lmite mximo de filas.
1/ Actualiza la tabla REPRESENTANTES empleando el mismo objeto instruccin strnt.executeUpdate(str2);
Limita el tamao mximo de cualquier columna recuperada. Recupera el lmite actual del tamao mximo del campo. Limita el tiempo mximo de ejecucin de las consultas. Recupera el lmite actual del tiempo mximo para las consultas.
1/ Finalmente, cierra la conexin dbconn. close () ;
Manejo de errores
getWarnings ()
Recupera las advertencias de SQL asociadas con la ejecucin de las instrucciones.
Las consultas utilizan el mtodo executeQuery (l, ya que proporciona un mecanismo para devolver los resultados. Otros mtodos execute incorporan las instrucciones preparadas de SQL, los parmetros de las instrucciones y los procedimientos almacenados. Para ilustrar el empleo bsico de los objetos Connection y Staternent, se ofrece a continuacin el fragmento de un programa de Java sencillo que crea una conexin con una base de datos. lleva a cabo dos actualizaciones de la base d datos, compromete los cambios y cierra la conexin.
date.
1/ El objeto de conexin y las cadenas de caracteres que se emplearn
Corno muestra el ejemplo. las operaciones de procesamiento de transacciones de SQL (comprometer y hacer retroceder) se manejan mediante llamadas de los mtodos al objeto Connection, en lugar de mediante la ejecucin de instrucciones COMMIT y ROLLBACK. Esto permite al controlador JDBC conocer el estado de las transacciones que est procesando sin necesidad de examinar el cdigo de SQL concreto que se est ejecutando. IDBC tambin incorpora un modo de compromiso automtico, en el que cada instruccin se trata corno si fuera una transaccin. Un mtodo del objeto Connection tambin controla esta opcin. Obsrvese que los mtodos Connection y Stat.ement a los que se llama en este fragmento de programa pueden provocar errores, y el fragmento no muestra ningn cdigo para el manejo de errores. Si se produce algn error, el controlador JDBC generar una excepcin sQLException. Normalmente. los fragmentos como el anterior (o partes de ellos) aparecen dentro de estructuras try I catch para manejar las posibles excepciones. En aras de la sencillez se suprime la estructura try I ca tch que lo e~cierra en este ejemplo y en los siguientes. Las tcnicas de manejo de errores se describen ms adelante en este captulo en el apartado Manejo de errores en JDBe .
.-L-
682
683
Procesamiento de consultas sencillas

Al igual que con las dems APl de SQL y con SQL incorporado, el procesamiento de consultas necesita un mecanismo adicional aparte de los utilizados para las actualizaciones de las bases de datos para manejar Jos resultados de la consulta devueltos. En IDBe el objeto ResultSet proporciona ese mecanismo adicional. Para ejecutar una consulta sencilla, los programas de Java invocan al mtodo execut.eQuery () de algn objeto Statement, pasando el texto de la consulta en la llamada al mtodo. El mtodo executeQuery () devuelve un objeto ResultSet que contiene los resultados de la consulta. El programa de Java invoca luego los mtodos de este obj~to ResultSet para tener acceso a los resultados de la consulta, fila a fila y columna por columna.
La Tabla 19.17 muestra los mtodos proporcionados por el objeto ResultSet. A continuacin se ofrece el fragmento de un programa de Java muy sencillo que muestra el modo en que los objetos y los mtodos que se han visto hasta ahora se combinan para llevar a cabo el procesamiento de una consulta sencilla. Recupera e imprime el nmero de la oficina, la ciudad y la regin de cada oficina de la tabla OFICINAS: // El objeto conexin, las cadenas de caracteres y las variables Connection dbconn; // la conexin de la base de datos Int num; // nmero de oficina devuelto String ciudad; // ciudad devuelta String reg; // regin devuelta String strl = SELECT OFICINA, CIUDAD, REGION FROM OFICINAS;
<el cdigo que crea la conexin
>
Tabla 19.17.
Mtodos JDBC del objeto ResultSet
Mtodo
Descripcin
Desplazamiento de los cursores

next ( ) clase () Desplaza el cursor a la siguiente fila de resultados de la consulta. Finaliza el procesamiento de la consulta; cierra el cursor.
Recuperacin bsica de valores de las columnas

getlnt () getShort () getLong ( ) getFloat () getDouble () getString() getBaolean () getDate () getTime () getTimestamp () getByte () Recupera un valor entero de la columna especificada. Recupera un valor entero corto de la columna especificada. Recupera un valor entero largo de la columna especificada. Recupera un valor numrico de coma flotante de la columna especificada. Recupera un valor de coma flolante de doble precisin de la columna especificada. Recupera el valor de una cadena de caracteres de la columna especificada. Recupera un valor verdadero/falso de la columna especificada. Recupera un valor de fecha de la columna especificada. Recupera un valor de tiempo de la columna especificada. Recupera un valor de marca temporal de la columna especificada. Recupera un valor de bYle de la columna especificada. Recupera datos BINARY de longitud fija o variable de la columna especificada. Recupera cualquier tipo de datos de la columna especificada.
// Crea un objeto instruccin para ejecutar la consulta Statement stmt = dbconn.createSta~ement{); // Lleva a cabo la consulta - el mtodo devuelve un objeto Result$et ResultSet answer = stmt.executeQuerylstrl); // Itera por ResultSet fila por fila whi le (answer. next () ( // Recupera cada columna de datos num answer.getlnt(~OFICINA"); ciudad answer.getString("CIUDAD"); reg answer.getString(3); // Imprime la fila de resultados System.out.printlnlciudad + + num
getBytes () getObj ect ()
Recuperaci6n de objetos de gran tamao

getAsciiStream() Obtiene un objeto de corriente de entrada para el procesamiento de una columna de objetos de carcter de gran tamao (Character Large Object. CLOB). Obtiene un objeto de corriente de entrada para el procesamiento de una columna de objetos binarios de gran tamao (Binary Large Object, BLOB).
GetBinaryStream()
+
~
reg);
arras funciones
getMetaData() // Cierra de manera explicita el cursor y la conexin answer. clase () ; dbconn.close() ; getWarnings() Devuelve un objeto ResultSetMetaData con metadatos para una consulta. Recupera advertencias de SQL asociadas con ResultSet.
684
685
Los mtodos aqu empleados son sencillos y se asemejan a las etapas de procesamiento de las consultas que ya se vieron para SQL incorporado y las API de C/C++. El objeto Resul tSet conserva un cursor para recordar su posicin en curso en los resultados de la consulta. Su mtodo next desplaza el cursor hacia delante, fila a fila, por los resultados. Hay una llamada explcita al mtodo IDBC get para recuperar cada columna de datos de cada fila. Los estrictos esquemas de escritura y de proteccin de la memoria de Java hacen imprescindible este enfoque, pero supone una sobrecarga significativamente ms elevada que el enfoque de C1C++ del enlace de las variables del programa y de hacer que la API de la base de datos llene esas variables de manera automtica cuando se captura la fila siguiente. Finalmente, la llamada al mtodo close concluye el procesamiento de la consulta. El ejemplo tambin muestra los dos mtodos alternativos para la especificacin del valor que debe recuperar de una columna cada llamada al mtodo get. Se puede especificar el nombre de la columna que hay que recuperar (que se emplea para las columnas OFICINAS y CIUDAD) o su posicin ordinal entre las columnas de resultados (que se utiliza para la columna REGlON). JDBC ofrece esta posibilidad sobrecargando cada mtodo get -una versin toma un argumento de cadena de caracteres (el nombre de la columna); la otra toma un argumento entero (el nmero de la columna).
Empleo de instrucciones preparadas en JDBC
Los mtodos executeQuery () y executeUpdate () del objeto Staternent proporcionan una posibilidad de SQL dinmico. Remedan la llamada a SQLExecDirect () del estndar CL!. La base de datos del otro extremo de la conexin JDBC no conoce con antelacin el texto de SQL que aparecer cuando se llame al mtodo execute. Debe analizar la instruccin sobre la marcha y determinar el modo de ejecutarla. El enfoque de SQL dinmico hace esta parte de la interfaz de JDBC bastante sencilla de utilizar, pero crea la elevada sobrecarga para el SGBD subyacente que suele asociarse con SQL. Para aplicaciones con elevadas tasas de transacciones en las que el rendimiento sea importante, resulta ms adecuada una interfaz alternativa de instrucciones preparadas. El enfoque de las instrucciones preparadas utiliza los mismos conceptos que las instrucciones PREPARE I EXECUTE de SQL dinmico incorporado y las llamadas SQLPrepare () y SQLExecute () del estndar CL!. La instruccin de SQL que hay que ejecutar de manera repetida (como puede ser una instruccin UPDATE que se vaya a utilizar en muchas filas o una consulta que se vaya a ejecutar centenares de veces en un programa) se prepara antes pasndola al SGBD para su anlisis. Luego se puede ejecutar la instruccin de manera repetida con muy poca sobrecarga. Se pueden variar los valores concretos empleados por la instruccin durante cada ejecucin pasndole valores de parmetros para su ejecucin. Por ejemplo, se pueden modificar los valores que hay que utilizar para cada operacin UPDATE o modificar el valor que debe coincidir en la clusula WHERE de una consulta empleando parmetros. Para utilizar instrucciones preparadas con JDBe, los programas invocan el mtodo prepa'reStatement () para una conexin, en lugar del mtodo create-
Staternent (). A diferencia de createStatement (), el mtodo prepareStaternent () toma un argumento -una cadena de caracteres que contiene la instruc-
cin de SQL que hay que preparar-o En la cadena de caracteres de la instruccin se indican los parmetros que hay que proporcionar mediante un signo de interrogacin (?), que sirve como marcador de par6metro. Los parmetros pueden utilizarse en la instruccin en cualquier lugar en que pueda aparecer legalmente una constante. El mtodo prepareStatement (') devuelve un objeto preparedStatement, que incluye algunos mtodos adicionales adems de los proporcionados por los objetos Statement. La Tabla 19.18 muestra algunos de esos mtodos adicionales, casi todos los cuales son para el procesamiento de parmetros. Los mtodos set () adicionales del objeto preparedStatement necesitan dos parmetros. Uno indica el nmero del parmetro para el que se proporciona el valor. El otro proporciona el propio valor del parmetro. Con estos mtodos la
Tabla 19.18. Mtodos adicionales del objeto JDBC PreparedStatement

Mtodo
setInt () setShort () setLong () setFloat () setDouble () setString () setBoolean () setDate () setTime () setTimeStamp (l setByte (l setBytes () setBigDecimal() setNull () setObject () ClearParameters getParameterMetaData()
Descripcin Define el valor de un parmetro entero. Define el valor de un parmetro entero corto. Define el valor de un parmetro entero largo. Define el valor de un parmetro de coma flotante. Define el valor de un parmetro de coma flotante de doble precisin. Define el valor de un parmetro de cadena de caracteres. Define el valor de un parmetro BOOLEAN. Define el valor de un parmetro DATE. Define el valor de un parmetro TIME. Define el valor de un parmetro TIMESTAMP. Define el valor de un parmetro BYTE. Define el valor de un parmetro BINARY o
VARBINARY.
Define el valor de un parmetro DECIMAL o

NUMERIC.
Define un valor NULL para un parmetro. Define el valor de un parmetro arbittario. Borra el valor de todos los parmetros. Devuelve el objeto ParameterMetaOata para una instruccin preparada (slo JDBe 3.0).
686

pstrntl.executeUpdate(); dbconn.commit{) 1
CapItulo 19: Las API de SOL
687
secuencia tpica para el procesamiento de instrucciones preparadas de lDBe puede resumirse como sigue: 1. 2.
3.
4.
5.
El programa de Java establece una conexi6n con el SGBD de la manera habitual. El programa llama al mtodo prepareStaternent () con el texto de la instruccin que hay que preparar, incluidos los marcadores de parmetro. El SGBD analiza la instruccin y crea una representacin interna optimizada de la instruccin que se va a ejecutar. Ms adelante, cuando llega el momento de ejecutar la instruccin con parmetros, el programa llama a uno de los mtodos set de la Figura 19.18 para cada parmetro, para proporcionar un valor para los parmetros. Cuando se han proporcionado todos los valores de los parmetros, el programa llama a executeQuery o a executeUpdate para que ejecuten la instruccin. El programa repite las etapas 3 y 4 una y otra vez (generalmente, docenas o centenares de veces, o ms), variando el valor de los parmetros. Si el valor de un parmetro concreto no se modifica de una ejecucin a la siguiente, no hace falta volver a llamar al mtodo seto
// Define un parmetro de la consulta y la ejecuta pstrnt2.setString{l, "Central"); ResultSet answer : pstmt2.executeQuery();
/1 Itera por ResultSet fila a fila whi le (answer. next ( )) { 11 Recupera cada columna de datos ciudad: answer.getString(l);
// Imprime la fila de resultados System.out.println(-La ciudad de la central es "

l answer.close() ;
ciudad);
// Define un parmetro diferente para la consulta y la ejecuta pstmt2.setString(l, "Este"); ResultSet answer : pstmt2.executeQuery();
A continuacin se ofrece el fragmento de un programa que ilustra esta tcnica:

// El objeto conexin, las cadenas de caracteres y las variables Connection dbconn; // La conexin de la base de datos String ciudad; // ciudad devuelta String strl : -UPDATE OFICINAS SET REGION : ? WHERE JEF : ?-; String str2 // Itera por el conjunto de resultados fila a fila while (answer. next () ( // Recupera cada columna de dacas ciudad: answer.getString{l);
"SELECT CIUDAD FROM OFICINAS WHERE REGION

}
1/ Imprime la fila de resultados
system.out.println("La ciudad del este es " + ciudad); answer. close () ;
>
1/ Prepara la instruccin UPDATE PreparedStatement pstmtl : dbconn.prepareStatement(strl);
// Acabado - cierra la conexin dbconn.close();
// Prepara la consulta PreparedStatement pstmt2
Empleo de instrucciones l/amables en JD8C

dbconn.prepareStatement(str2);
// Define los parmetros para la instruccin UPDATE y la ejecuta pstmtl.setString{l,-Central"); pstmtl.setInt(2,108) ; pstmtl.executeUpdate();
Reinicia uno de los parmetros y vuelve a ejecutar la instrucc~n. y luego compromete la transaccin pstmtl.setlnt(2,104);
/1
Los ltimos apartados describan el modo en que JDBC admite la ejecucin de instrucciones de SQL dinmico (mediante el objeto Statement. creado por el mtodo createStatement () y las instrucciones preparadas de SQL (mediante el objeto PreparedStatement. creado por el mtodo prepareStaternent (). JDBC tambin admite la ejecucin de procedimientos almacenados y funciones almacenadas mediante un tercer tipo de objeto de instruccin, el objeto CallableStatement, creado por el mtodo prepareCall (). A continuacin puede verse el modo en que los programas de Java invocan las funciones almacenadas o los procedimientos almacenados empleando JDBC:
688
1.
689
2. 3.
4.
5.
6.
El programa de Java invoca al mtodo prepareCall (), pasndole una instruccin de SQL que invoca la rutina almacenada. Los parmetros de la llamada se indican mediante marcadores de parmetro en la cadena de caracteres de la instruccin, igual que para las instrucciones preparadas. El mtodo devuelve un objeto CallableStatement. El programa de Java utiliza los mtodos set (l del objeto CallableStatement para especificar el valor de los parmetros de la llamada al procedimiento o a la funcin. El programa de Java utiliza otro mtodo del objeto CallableStatement para especificar los tipos de datos de los valores devueltos por el procedimiento almacenado o la funcin. El programa de Java invoca uno de los mtodos execute () del objeto CallableStatement para realizar realmente la llamada al procedimiento almacenado. Finalmente, el programa de Java invoca uno O varios de los mtodos get () del objeto CallableStatement para recuperar los valores devueltos por el procedimiento almacenado (si es que hay alguno) o el valor devuelto de la funcin almacenada.
Tabla 19.19.
Otros mtodos del objeto CallableStatement (continuacin)
Funcin
getBoolean () getDate () getTime () getTiroestamp () getByte () getBytes () getBigDecimal () getObject ()
Descripcin
Recupera un valor verdadero/falso de la columna especificada. Recupera un solo valor de datos de la columna especificada. Recupera un solo valor de hora de la columna especificada. Recupera un solo valor de marca temporal de la columna especificada. Recupera un solo valor de byte de la columna especificada. Recupera datos BINARY de longitud fija o variable. Recupera datos DECIMAL o NUMERIC. Recupera cualquier tipo de datos.
El objelO CallableStatement proporclona todos los mtodos del objeto PreparedStatement, que pueden verse en las Tablas 19.16 y 19.18. Los mtodos adicionales que proporciona para el registro de los tipos de datos de los parmetros de salida o de entrada y salida y para recibir los valores devueltos de los parmetros tras la llamada se muestran en la Tabla 19.19. Un ejemplo breve es la mejor manera de ilustrar la tcnica de llamada a procedimientos almacenados y funciones almacenadas. Supngase que la base de datos de ejemplo contiene un procedimiento almacenado definido de esta manera:
CREATE (IN OUT IN PROCEDURE CAMBIAR_REGION OFICINA INTEGER. REG_VIEJA VARCHAR(lO). REG_NUEVA VARCHAR{lO))
Tabla 19.19.
Otros mtodos del objeto CallableStatement
Funcin
registerOutPararneter() getInt () getShort (1 getLong( ) getFloat () getDouble () getString ()
Descripcin
Registra el tipo de datos del parmetro de salida (o de enlfada y salida). Recupera un valor entero devuelto. Recupera un valor entero corto de la columna especificada. Recupera un valor enlero largo de la columna especificada. Recupera un valor numrico de coma flotante de la columna especificada. Recupera un valor de coma flotante de doble -precisin de la columna especificada. Recupera un valor de cadena de caracteres de la columna especificada.
(contina)
que cambia la regin de una oficina, de la manera solicitada por los dos parmetros de entrada, y devuelve la regin antigua como parmetro de salida y una funcin almacenada, definida de esta manera:
CREATE FUNCTION OBTENER_REGION {IN OFICINA INTEGER) RETURNS VARCHAR(lO
que devuelve la regin de la oficina dado su nmero de oficina. Este fragmento de un programa de Java muestra el modo de invocar el procedimiento almacenado y la funcin almacenada mediante JDBC:
11 El objeto conexin. las cadenas de caracteres y las variables Connection dbconn; 1/ la conexin de la base de datos String strl :: "{CALL CAMBIAR_REGION(?, ? ?)}-; String str2 :: "(? :: CALL OBTENER_REGlON(?))"; string regvieja; // regin antigua devuelta String regnueva; // regin actual devuelta
'-'--
690

>
691
JI Prepara las dos instrucciones CallableStatement cstmtl dbconn prepareCall(strl); CallableStatement cstmt2 : dbconn prepareCall(str2);
JI Especifica los valores de los parmetros y el tipo de datos de
los datos devueltos para la llamada al procedimiento almacenado cstrntl.setlnt(1.12); 11 llama con el nmero de oficina 12 (Castelln) cstmtl.setString(3,"Centra1"); 11 y nueva regin de la central cstmtl.registerOutParameter(2,Types.VARCHAR); 11 devuelve un parmetro varchar
Para las funciones almacenadas slo hay parmetros de entrada y se vuelven a utilizar una vez ms los mtodos set ( ) . El valor devuelto de la funcin se especifica con un marcador de parmetro en la cadena de caracteres de la instruccin preparada. Se registra su tipo de datos y se recupera su valor, igual que si fuera un parmetro normal de salida.
Manejo de errores en JDBC
11 Sigue adelante y ejecuta la llamada al procedimiento almacenado cstmtl.executeUpdate(}; regvieja = cstmt.getString(2); 11 el (segundo) parmetro devuelto es una cadena de caracteres
11 Especifica el valor de los parmetros y el tipo de los datos

devueltos para la llamada a la funcin almacenada cstmt2.setlnt(1,12}; 11 llama con el nmero de oficina 12 (Castel1n) cstmt2. registerOutParameter (1, Types. VARCHAR); 11 la funcin devuelve un varchar
Cuando se produce un error durante una operacin de JDBC, la interfaz de JDBC genera una excepcin de Java. La mayor parte de los errores de ejecucin de SQL generan una SQLException. El error puede manejarse mediante el mecanismo estndar de Java try I catch. Cuando se produce un error SQLException, se llama al mtodo catch () con un objeto SQLException, parte de cuyos mtodos se resumen en la Tabla 19.20. Los mtodos SQLException permiten recuperar el mensaje de error, el cdigo de error SQLSTATE y el cdigo de error especfico del SGBD asociado con el error. Es posible que una operacin de JDBe cree ms de un error. En este caso, los errores se ponen a disposicin del programa en orden. La llamada a getNextException () en el primer error comunicado devuelve una SQLException para la segunda excepcin, y as hasta que no haya ms excepciones que manejar. .
Cursores con desplazamiento y actualizables en JDBC
11 Sigue adelante y ejecuta la llamada a la funcin almacenada cstmt2.executeUpdate() ; ansreg == cstmt. getString (1); 11 el valor devuelto (primer parmetro) es una cadena de caracteres 11 Acabado - cierra la conexin dbconn. clase () ;
Igual que se han aadido los cursores con desplazamiento al estndar SQL de ANSI! ISO, los cursores con desplazamiento se han aadido a los conjuntos de resultados de JDBC en versiones posteriores de la especificacin. Se indica al mtodo executeQuery que se desea que una consulta genere resultados con posibilidad de desplazamiento mediante un parmetro. Si se especifica desplazamiento, el ResultSet devuelto por la llamada a executeQuery ofrece algunos mtodos adicionales para el control de los cursores. Los mtodos importantes se relacionan en la Tabla 19.21. Adems de los conjuntos de resultados con desplazamiento, las versiones posteriores de la especificacin JDBC aadieron soporte para los conjuntos de resultados
Obsrvese que las invocaciones a las llamadas del procedimiento almacenado o de la funcin almacenada en las cadenas de caracteres de las instrucciones van encerradas entre llaves. Los parmetros de entrada pasados a un procedimiento almacenado o a una funcin almacenada se manejan exactamente igual que los parmetros para las instrucciones preparadas. Los parmetros de salida de los pro'cedimientos almacenados necesitan algn artilugio nuevo: la llamada al mtodo registerOutParameter (J para especificar los tipos de datos y las llamadas a los mtodos get (J para recuperar su valor tras concluir la llamada. Se resumen en la Tabla 19.19. Los parmetros de entrada y salida para los procedimientos almacenados necesitan tanto que los valores se pasen en la llamada al procedimiento, empleando los mtodos set (J, como que el tipo de datos de la salida se especifiquen con registerOutParameter (), y que los datos devueltos se recuperen con los mtodos get ( ) .
Tabla 19.20.
Mtodos JDBC de SQLException
Mtodo
getMessage() getSQLState() getErrorCode{J getNextException()
Descripcin
Recupera el mensaje de error que describe la excepcin. Recupera el valor de SQLSTATE (cadena de caracteres de cinco caracteres, como se describe en el Captulo 17). Recupera un cdigo de error especfico del controlador o del
SGBD.
Se desplaza a
la siguiente excepcin
de SQL de
una
serie.
692

Mtodos JOSe de cursor ampliados del objeto ResultSet Tabla 19.21. Funcin
693
Tabla 19.21.
Mtodos JDBC de cursor ampliados del objeto ResultSet (continuacin)
Funcin
Descripcin
Descripcin
updateTime() updateTimeStamp{)
updateByte (1 upda teBytes ( )
DespLazamiento de Jos cursores de desplazamiento
previous ()
beforeFirst () first ()
Desplaza el cursor a la fila anterior de resultados de la consulta.

Desplaza el cursor antes del inicio de los resultados. Desplaza el cursor a la primera fila de resullados de la consulta.
Actualiza el valor de una columna de horas. Actualiza el valor de una columna de marcas temporales. Actualiza el valor de una columna de bytes. Actualiza el valor de una columna de longitud fija o variable. Actualiza el valor de una columna DECIMAL o NUMERIC. Actualiza una columna con un valor NULL. Actualiza un valor arbilrario de una columna.
updateBigDecimal()
last() afterLast()
Desplaza el cursor a la ltima fila de resultados de la
cansulla.
Desplaza el cursor ms all del final de los resultados. Desplaza el cursor al nmero de fila absoluto indicado. Desplaza el cursor al nmero de fila relativo indicado. absol u te ( ) relative () isFirst() isLast () isBeforeFirst{) isAfterLast () moveToInsertRow() moveToCurrentRowl)
updateNull () updateObject ()
ldencificacin de la posicin de los cursores
Determina si la fila en curso es la primera fila del conjunto de resultados. Determina si la fila en curso es la ltima fila del conjunto de resultados. Determina si el cursor se ubica antes del comienzo del conjunto de resullados. Determina si el cursor se ubica ms all del final del conjunto de resultados. Desplaza el cursor a una fila vaca para la insercin de datos nuevos. Vuelve a desplazar el cursor a la fila en curso antes de una insercin. .
actualizables. Esta posibilidad se corresponde con la posibilidad UPDATE...WHERE CURRENT QF de SQL incorporado. Permite la actualizacin de columnas concretas de "a fila, que viene indicada por la posicin actual del cursor. Los conjuntos de resultados actualizables permiten tambin que se inserten nuevas filas de datos en la tabla mediante un conjunto de resultados. Recuperacin de metadatos con JDBC La interfaz de JDBC proporciona objetos y mtodos para la recuperacin de metadatos sobre las bases de datos, los resultados de una consulta y las instrucciones parametrizadas. El objeto JDBC Connection proporciona el acceso a los metadatos sobre la base de datos que representa. Al acogerse a su mtodo getMetaData (), devuelve un objeto DatabaseMetaData, que se describe en la Tabla 19.22. Cada mtodo relacionado en la tabla devuelve un conjunto de resultados, que contiene informacin sobre un tipo de entidad de la base de datos: tablas, columnas, claves primarias, etc. El conjunto de resultados puede procesarse mediante las rutinas JDBC habituales de procesamiento de los resultados de la consulta. Otros mtodos de acceso a los metadatos proporcionan informacin sobre el nombre del producto de base de datos incorporado en esa conexin, su nmero de versin y otra informacin parecida. La informacin de los metadatos sobre los resultados de las consultas puede resultar tambin muy til. Los objetos ResultSet proporcionan un mtodo getMetaData que puede invocarse para obtener una descripcin de los resultados de -sus consultas. El mtodo devuelve un objeto ResultSetMetaData, que se describe en la Tabla 19.23. Los mtodos permiten determinar el nmero de columnas que hay en los resultados de las columnas y el nombre y el tipo de datos de cada columna, identificada por su posicin ordinal en los resultados de la consulta. Finalmente, la informacin de los metadatos sobre los parmetros utilizados en las instrucciones de SQL preparadas, o las llamadas preparadas a procedimientos almacenados, tambin puede resultar til. Los objetos PreparedStatement y
Actualizacin de columnas de lafila actual (mediante cursores)
updateInt () updateShort(1 updateLong () updateFloat () updateDouble {l updateString 11 updateBoolean (1 updateDate()
Actualiza el valor de una columna entera. Actualiza el valor de una columna entera corta. Actualiza el valor de una columna entera larga. Actualiza el valor de una columna de coma flotante. Actualiza el valor de una columna de coma flotante de doble precisin. Actualiza el valor de una columna de cadenas de caracteres. Actualiza el valor de una columna verdadera/falsa.. Actualiza el valor de una columna de fechas.
(contina)
694
Captulo 19: Las A?I de SOL
695
Tabla 19.22. Mtodos de DatabaseMetaData para la recuperacin de informacin de la base de datos
Tabla 19.24.
Mtodos JDBC de ParameterMetaData
Funcin
getTables() getColumns ()
Descripcin
Funcin
getParameterClassName()
Descripcin
Devuelve el nombre de la clase (tipo de datos) del parmetro especificado. Devuelve el nmero de parmetros de la instruccin. Devuelve el modo (IN, OUT, INOUT) del parmetro. Devuelve el tipo de datos de SQL del parmetro especificado. Devuelve el tipo de datos del SGBD del parmetro especificado. Devuelve la precisin del parmetro especificado. Devuel ve la escala del parmetro especificado. Determina si el parmetro especificado puede tener valores oull. Determina si el parmetro especificado es un nmero con signo.
Devuelve el conjumo de resultados de la informacin de las tablas de la base de dalos.
Devuelve el conjunto de resullados de la informacin

del nombre y tipo de las columnas, dado el nombre de la labia.
getParameterCount() getParameterMode() getParameterType() getParameterTypeName() getPrecision() getScale () iSNullable () isSigned ()
getPrimaryKeys{) getProcedures(I getProcedureColumns()
Devuelve el conjunto de resultados de la informacin de clave primaria, dado el nombre de la tabla.
Devuelve el conjunto de resultados de la informacin sobre los procedimientos almacenados. Devuelve el conjunto de resultados de la informacin sobre los parmetros de un procedimienlo almacenado concreto.
eallableStatement proporcionan un mtodo getParameterMetaData () que recupera esa informacin. El mtodo devuelve un objeto ParameterMetaData,
que se describe en la Tabla 19.24. Acogerse a los mtodos de este objeto proporciona infonnacin sobre el nmero de parmetros empleados en la instruccin, sus tipos de datos, si cada parmetro es un parmetro de entrada, de salida o de entrada y salida, y otra infonnacin parecida.
Posibilidades avanzadas de JDBC
JDBC 2.0 y JDBC 3.0 introdujeron varias posibilidades que ampliaban la funcionalidad bsica de acceso a las bases de datos de JDBC. Los orgenes de datos de JDBC, introducidos por primera vez en JDBC 2.0, proporcionan un mtodo de nivel superior para la bsqueda de controladores y bases de datos disponibles y la conexin con ellas. Enmascaran los detalles del establecimiento de conexiones del programador de aplicaciones de Java. Bsicamente, los orgenes de datos se iden-
Tabla 19.23.
Funcin
Mtodos de ResultSetMetaData
Descripcin
Devuelve el nmero de columnas de los resultados de la columna. Recupera el nombre de la columna de resultados especificada. Recupera el tipo de datos de la columna de resultados especificada.
getColumnCount() getColumnName() getColumnType()
lifican con algn directorio o catlogo externo que es capaz de traducir los nombres lgicos de las entidades a detalles especficos. Empleando orgenes de datos los programadores de aplicaciones pueden especificar las bases de datos de destino mediante nombres abstractos y hacer que el directorio maneje junto con el controlador de software de JDBC los detalles de las conexiones. Los conjuntos de filas de JDBC son otro concepto avanzado mejorado y ampliado en las revisiones de JDBe. Los conjuntos de filas amplan el concepto de conjunto de resultados de JDBC, que, como se recordar, representa a un conjunto de resultados de una consulta. Aparte de los propios resultados de las consultas, los conjuntos de filas "encapsulan informacin sobre la base de datos de origen subyacente, la conexin con la base de datos, su nombre de usuario y contrasea, etc. Los conjuntos de filas conservan su identidad independiente de las conexiones activas con las bases de datos. Por tanto, puede haber conjuntos de filas en estado de desconexin y pueden emplearse para reestablecer una conexin con la base de datos. Cuando los conjuntos de filas estn conectados con las bases de datos, pued~n contener resultados de consultas como los conjuntos de resultados. Los conjuntos de filas tienen otras caractersticas y posibilidades. Los conjuntos de filas cumplen los requisitos para los componentes JavaBeans y, cuando estn conectados con bases de datos, proporcionan un modo de hacer que los conjuntos de resultados parezcan una Enterprise Java Bean (EJB). Los conjuntos de filas guardan resultados de consultas tabulares de filas y columnas, y se pueden recuperar esos resultados, desplazarse por ellos e incluso actualizarlos, est el conjunto de filas conectado con la base de datos o no. Si se llevan a cabo actualizaciones en desconexin, queda implcita la resincronizacin cuando se
696
saL
697
vuelva a conectar el conjunto de filas con la base de datos de origen. Finalmente, el concepto de conjunto de filas no se halla vinculado necesariamente con SQL y' las bases de datos relacionales. Los datos de los conjuntos de filas pueden venir, tericamente, de cualquier origen de datos tabular, como las hojas de clculo de las computadoras personales 0, incluso, de una tabla de un documento de un procesador de texLOS. El estudio completo de los conjuntos de filas de JDBC excede las inlencion~s de este libro; vase la documentacin sobre JDBC en hllp:/ /www.java.sun.com/products/jdbc/paraobtenerms infonnaci6n sobre sta y otras posibilidades de JDBC.
En general, los fabricantes de SOBD hacen un trabajo considerable de ajuste del rendimiento en sus API propietarias, y tienden a ofrecer soporte de ODBC o de SQUCLI como caracterstica aadida. Por tanto, las aplicaciones con mayores necesidades de rendimiento tienden a utilizar las API propietarias, y quedan encerradas en una marca concreta de SGBD cuando lo hacen.
Resumen
Muchos productos de SGBD basados en SQL proporcionan una API Ilamable para el acceso a las bases de datos mediante programacin: En funcin de la marca concreta de SGBD y de su historial, puede que la API lIamable sea una alternativa al enfoque de SQL incorporado, o que sea el mtodo principal mediante el cual los programas de aplicacin tienen acceso a las bases de datos. La interfaz llamable pone en la interfaz de llamadas el procesamiento de consultas, el paso de parmetros, la compilacin de instrucclones, la ejecucin de instrucciones y otras tareas parecidas, conservando el lenguaje SQL de programacin idntico a SQL interactivo. Con SQL incorporado, estas tareas estn a cargo de instrucciones especiales de SQL (OPEN, FETCH, CLOSE, PREPARE, EXECUTE, etc.), que son exclusivas de SQL de programacin. La ODBC de Microsoft es una API llamable, ampliamente admitida, que proporciona una manera efectiva para que los programas de aplicacin consigan la independencia de los SGBD concretos. Sin embargo, las diferencias entre las marcas de SGBD se reflejan en el soporte variable de las funciones y posibilidades de ODBC. El estndar de la interfaz del nivel de llamadas de SQL (SQUCall-Level interface, SQUCLI) se basa en ODBC y es compatible con ena en su nivel central. SQUCLI proporciona una API Ilamable para complementar la interfaz de SQL incorporado especificado en SQL2. Muchos fabricantes de SOBD ya incorporan SQUCLI debido a su soporte bistrico de ODBC. Para los programas de Java, la interfaz IDBe es la API llamable estndar industrial de facto, admitida por todos los principales productos de SGBD y definida como la API de gestin de bases de datos en el estndar Edicin para empresas de Java2 (Java2 Enterprise Edition, J2EE), implementado por todos los principales productos de servidores de aplicaciones. Las API llamables propietarias de las diferentes marcas de SGBD sigue!) siendo importantes en el mercado (especialmente la OCI de Oracle). Todas ellas ofrecen las mismas caractersticas bsicas, pero 'varan espectacularmente en cuanto a las caractersticas ampliadas que ofrecen y a los detalles de las llamadas y las estructuras de datos que emplean.
i
j
Parte VI
I
1
Sal HOY Y MANANA
,
,I
La influencia de SQL contina en aumento dado que nuevas capacidades y desarrollos afrontan nuevos tipos de requisitos para gestin de datos. Los captulos 20 al 25 describen varias de estas nuevas reas. El Captulo 20 describe los procedimientos almacenados, que proporcionan una capacidad de procesamiento en el propio SGBD para implementar reglas de negocio y para crear interacciones bien definidas con la base de datos. El Captulo 21 examina el papel de SQL en el aulisis de datos y la tendencia a crear almacenes de datos basados en SQL. El Captulo 22 describe el papel de SQL en la creacin de sitios web interactivos, y especialmente su relacin con la tecnologa de servidores de aplicaciones. El Captulo 23 estudia cmo se usa SQL para crear bases de datos distribuidas que explotan la potencia de las redes informticas. El Captulo 24 estudia una de las reas ms importantes de la evolucin de SQL: la interaccin entre SQL y las tecnologas orientadas a objetos y la nueva generacin de bases de datos relacionales orientadas a objetos. El Captulo 25 se enfoca en la relacin entre SQL y una de las ms importantes de estas tecnologas, XML, y la arquitectura emergente de servicios web en Internet basada en XML. Finalmente, el Captulo 26 resalta las tendencias clave que dirigirn la evolucin de SQL a lo largo de esta dcada.
CAPTULO
26
Procesamiento de bases de datos y procedimientos almacenados

La tendencia a largo plazo en el mercado de bases de datos es a que las bases de datos adopten progresivamente una mayor importancia en la arquitectura global del procesamiento de datos. Los sistemas de bases de datos prerrelacionales bsicamente s6lo gestionaban el almacenamiento de los datos y la recuperacin; las aplicaciones eran responsables de la navegacin por la base de datos, la ordenacin y seleccin de los datos y la gestin de todo el procesamiento de datos. Con la llegada de las bases de datos relacionales y SQL, el SGBD tom mayores responsabilidades. La bsqueda y ordenacin de la base de datos se integraba en las clusulas del lenguaje SQL y era proporcionado por el SGBD, junto con la capacidad de resumir los datos. La navegacin explcita por la base de datos se convirti en innecesaria. Posteriores mejoras de SQL, tales como las claves principales y externas y las restricciones de comprobacin, continuaron la tendencia, tomando la responsabilidad de las funciones de comprobacin de los datos y su integridad, que eran responsabilidad de las aplicaciones en implementaciones SQL anteriores. En cada paso, el SaBD adopt ms responsabilidad proporcionada por el control centralizado y se redujo la posibilidad de la corrupcin de los datos debido a errores en la programacin de la aplicacin. En muchos departamentos de tecnologas de la informacin (IT, lnformation Technology) en grandes compaas y organizaciones, esta tendencia del SGBD sigui una tendencia organizativa. La base de datos corporativa y los datos que contena tenan que ser vistos como un bien corporativo principal, y en muchos departamentos IT emergi un grupo de administracin de bases de datos dedicado (DBA, Dedicated Database Administration), con la responsabilidad de gestionar la base de datos, definiendo y actualizando los datos contenidos y proporcionando estructuras de acceso. Otros grupos en el departamento IT. o en cualquier parte de la compaa, podran desarrollar aplicaciones, informes, consultas u otra lgica para acceder a la base de datos. Sin embargo, la seguridad de la base de datos, las fonnas permitidas de acceso y, en general, todo lo del dominio de la base de datos lleg a ser responsabilidad del DBA. Dos caractersticas importantes de las bases de datos relacionales a escala empresarial moderna (los procedimientos almacenados y los disparadores) han repre-
701
702
Captulo 20: Procesamiento de bases de datos y procedimientos...
703
sentado una parte de esta tendencia. Los procedimientos almacenados proporcionan la capacidad de ejecutar el procesamiento de aplicaciones de bases de datos dentro de la base de datos misma. Por ejemplo, un procedimiento almacenado puede implementar la lgica de la aplicacin para que acepte el pedido de un cliente o transferir dinero de una cuenta bancaria a mea. Los disparadores se utilizan para invocar automticamente el procesamiento de un procedimiento almacenado basado en condiciones que se dan lugar en la base de datos. Por ejemplo, un disparador puede transferir automticamente fondos de una cuenta de ahorro a una cuenta corriente si sta est en nmeros rojos. Este captulo describe los conceptos principales de los procedimientos almacenados y disparadores, y su implememacin en varias marcas de SOBD populares. La capacidad de los procedimientos almacenados y disparadores de los productos SGBD ha aumentado significativamente en sus revisiones principales durante los ltimos aos noventa y en la presente dcada. Un tratamiento completo de la programacin de los procedimientos almacenados y disparadores excede el alcance de este libro, pero los conceptos y comparaciones proporcionarn una comprensin de las capacidades principales y un fundamenlO para comenzar el uso de capacidades especficas del software SGBD. Los procedimientos almacenados y disparadores bsicamente extienden SQL a un lenguaje de programacin completo, por lo que en este captulo se considera que se est familiarizado con los conceptos de programacin bsicos.
Bucles. Un bucle WHILE o FOR o estructura similar permite una secuencia de operaciones SQL a ejecutar repetidamente, hasta que se cumple una condicin de terminacin. Algunas implementaciones proporcionan una estructura especial de bucles basada en cursores para procesar cada fila de resultados de la consulta. Estructura en bloque. Una secuencia de instrucciones SQL se puede agrupar en uri nico bloque y utilizar en otras construcciones de control de flujo como si el bloque de la instruccin fuera una nica instruccin. Variables con nombre. Un procedimiento SQL puede almacenar un valor que se ha calculado, recuperado de una base de datos o derivado de alguna forma en una variable del programa,. y despus recuperar el valor almacenado para usarlo en clculos posteriores. Procedimientos con nombre. Una secuencia de instrucciones SQL se puede agrupar, dndole un nombre y asignando parmetros formales de entrada y salida, como una subrutina o funcin en un lenguaje de programacin convencionaL Una vez definido el procedimiento de esta forma, se puede llamar por su nombre, pasando los valores apropiados en los parmetros de entrada. Si el procedimiento es una funcin que devuelve un valor, se puede utilizar en expresiones de SQL. Colectivamente, las estructuras que implementan estas capacidades forman un lenguaje de procedimientos almacenado (SPL, SlOred Procedure Language). Los procedimientos almacenados se introdujeron inicialmente por Sybase en el producto original SQL Servc::r de Sybase. Gran parte del entusiasmo original con los procedimientos almacenados se debi a su impacto en el rendimiento en una arquitectura de base de datos-cliente/servidor. Sin los procedimientos almacenados, cada operacin SQL requerida por una aplicacin (ejecutndose en el sistema de la computadora cliente) deba enviarse por la red al servidor de la base de datos, y haba que esperar el mensaje de respuesta a travs de la red. Si una transaccin lgica requera seis operaciones SQL, deban realizarse seis viajes por la red. Con los procedimientos almacenados se poda programar la secuencia de seis operaciones SQL en un procedimiento y almacenarlo en la base de datos. 'La aplicacin solicita simplement~ la ejecucin del procedimiento almacenado Y espera el resultado. De esta forma los seis viajes de ida y vuelta se convierten en un nico viaje (la solicitud y la respuesta de la ejecucin del procedimiento almacenado). Los procedimientos almacenados se han mostrado como un engarce natural del modelo cliente/servidor, y Sybase los utiliz para establecer una primera tendencia con esta arquitectura. Rpidamente sigui una respuesta competitiva por muchos otros fabricantes de SGBD. En la actualidad la mayor parte de los productos empresariales SGBD proporcionan procedimientos almacenados, y los beneficios ~e los procedimientos almacenados en las bases de datos corporativas se ha expandIdo considerablemente ms all del objetivo inicial en el rendimiento de la red. Los procedimientos almacenados son menos relevantes para otros tipos de sistemas SGBD especializados, tales como los sistemas de almacenes de datos o en bases de datos residentes en memoria. Algunos productos SGBD han modelado sus es
Conceptos de los procedimientos almacenados

En su forma inicial, SQL no se consideraba un lenguaje de programacin completo. Se dise e implement corno un lenguaje para expresar las operaciones de bases de datos .....:.....creacin de estructuras de bases de datos. introduccin de datos en la base de datos, actualizacin de la base de datos- y, especialmente, para ex.p~esar consultas de la base de datos y recuperar las respuestas. SQL se poda uuhzar de forma interactiva introduciendo las instrucciones SQL en un teclado una a una. En este caso, la secuencia de operaciones de la base de datos era determinada por el usuario humano. SQL tambin se poda incorporar en otro lenguaje de programacin, corno COBOL o C. En este caso, la secuencia de operaciones en la base de datos estaba determinada por el flujo de control del programa de COBOL o C. Con los procedimientos almacenados, algunas capacidades normalmente asociadas con los lenguajes de programacin estn incorporadas en el lenguaje SQL. Las secuencias de ~ns~rucciones SQL extendidas se agrupan para formar programas SQL o procedImientos. La forma especfica vara de una implementacin a otra, pero generalmente se proporcionan las siguientes capacidades:
E~ecucin condicional. Una estructura IF...THEN_.ELSE permite un procedimIento. SQL para comprobar una condicin y llevar a cabo distintas operaciones dependiendo del resultado.
n
704
Capitulo 20: Procesamiento de bases de datos y procedimientos...
705
lrucluras del SPL en construcciones de lenguaje e o Pascal. Otros han imentado ajustar el estilo del lenguaje de manipulacin de datos (LMD) y del lenguaje de definicin de datos (LDD). Como resultado, mientras que los conceptos del procedimiento almacenado son muy similares entre dialectos SQL, la sintaxis especfica vara considerablemente.
Un ejemplo bsico
Es ms fcil entender los procedimientos almacenados mediante un ejemplo. Consideremos el proceso de agregar un cliente a la base de datos ejemplo. Veamos los pasos que pueden darse:
1.
2. 3. 4.
5.
Obtener el nmero de cliente, nombre, lmite de crdito y el objetivo de ventas para el cliente, as como el representante asignado y la oficina. Agregar una fila a la tabla cliente que contenga los datos del cliente. Actualizar la fila del representante asignado, elevando el objetivo de cuota en la cantidad especificada. Actualizar la fila de la oficina, elevando el objetivo de ventas en la cantidad especificada. Realizar los cambios en la base de datos, si todo estuviera correcto.
' Procedimiento para agregar un cliente , create procedure agregar_cliente , nombre del cliente, nombre_c in varchar{201. entrada , , nmero del cliente, num_c in integer. entrada *1 , lmite de crdito. lim_cred in number(16,2}, entrada ' obj_ven in number{16,21, ' objetivo de ventas. entrada rep_c in integer. ' nmero de empleado del representante, entrada , , ciudad de la oficina. ofic_c in varchar(15)) entrada , as begin I~ Insertar una fila nueva en la tabla CLIENTES ~I insert into clientes (num_cli. empresa, rep_cli, limite_credito) values (nu~c. nombre_c, rep_c, lim_cred);
I~ Actualizar la fila de la tabla REPRESENTANTES *1 update representantes set cuota = cuota + cuota + obj_ven where num_empl = rep_c;
Sin la posibilidad de usar procedimientos almacenados, sta es la secuencia de instrucciones SQL que realiza este trabajo para Empresa XYZ, nuevo nmero de cliente 2137, con un lmite de crdito de 30.000 Y unos objetivos del primer ao de 50.000 a asignar por Pablo Cruz (empleado nmero 103), de la oficina de Castelln:
INSERT INTO VALUES UPDATE SET WHERE UPDATE SET WHERE COMMIT; CLIENTES (NUM_CLI, EMPRESA, REP_CLI. LIMITE_CREDITOI (2137, 'Empresa XYZ', 1q3. 30000.00); REPRESENTANTES CUOTA = CUOTA + 50000.00 NUM_EMPL = 103; OFICINAS OBJETIVO OBJETIVO + 50000.00 CIUDAD 'Castelln';
1* Actualizar la fila de la tabla OFICINAS 1 update oficinas set objetivo = objetivo + obj_ven where ciudad = afic_c;
l Comprometer la transaccin y terminar 1 commit; end;
Figura 20.1.
Procedimiento almacenado bsico en PLJSQL.
Una vez que se ha creado este procedimiento en la base de datos, una instruc, cin como la siguiente:
AGREGAR_CLIENTE('Empresa XYZ'. . Castel16n' ) 2137, 30000.00, 50000.00, 103,
Con un procedimiento almacenado, todo este trabajo se puede incorporar en una nica rutina SQL definida. La Figura 20.1 muestra un procedimiento almacenado para esta tarea, expresada en el dialecto de los procedimientos almacenados PL/SQL de Gracle. El procedimiento se denomina AGREGAR_CLIENTE, y acepta seis parmetros (nombre del cliente, nmero, lmite de crdito y objetivo de ventas, nmero de empleado del representante asignado y ciudad donde est ubicada la oficina de" ventas).
llama al procedimiento almacenado y pasa los seis valores especificados como parmetros. El SGBD ejecuta el procedimiento almacenado, llevando a cabo cada instruccin SQL en la definicin del procedimiento, una a una. Si el.procedimiente AGREGAR_CLIENTE completa su ejecucin satisfactoriamente, se ha realizado una transaccin asistida por el SOBD. Si no, el cdigo de error y el mensaje devueltos indican lo que fue mal.
706
707
Uso de los procedimientos almacenados

El procedimiento definido en la Figura 20.1 ilustra varias estructuras comunes bsicas a todos los dialectos SPL. Casi todos los dialectos utilizan una instruccin CREATE PROCEDURE para definir inicialmente un procedimiento almacenado. La instruccin DROP PROCEDURE correspondiente se utiliza para descartar procedi-
mientos que no son necesarios. L{t instruccin guiente:
CREATE PROCEDURE
define lo si-
El nombre del procedimiento almacenado. El nombre y tipos de datos de sus parmetros. Los nombres y tipos de datos de cualquier variable local utilizada por el-procedimiento. La secuencia de instrucciones ejecutada cuando se llama al procedimiento. Las siguientes secciones, describen estos elementos y las instrucciones SQL especiales que se utilizan para controlar el flujo de ejecucin en el cuerpo del procedimiento almacenado.
Adems de los parmetros de entrada, algunos dialectos SPL incorporan parmetros de salida (output en ingls). Permiten devolver a un procedimiento almacena~ do valores que calcula durante su ejecucin. Los parmetros de salida no son tiles para los procedimientos almacenados invocados desde SQL interactivo, pero proporcionan una capacidad importante para devolver informacin de un procedimiento almacenado a otro procedimiento almacenado que 10 llama. Algunos dialectos SPL albergan parmetros que operan tanto como parmetros de entrada como de salida. En este caso los parmetros pasan un valor al procedimiento almacenado, y cualquier cambio en el valor durante la ejecucin del procedimiento se refleja en el procedimiento que lo llama. La Figura 20.2 muestr.a la definicin del mismo procedimiento AGREGAR_ CLIENTE expresado en el dialecto Transact-SQL de Sybase {SQL Server de Mi-
Creacin de un procedimiento almacenado

En muchos dialectos comunes SPL se utiliza la instruccin CREATE PROCEDURE para crear un procedimiento almacenado y especificar cmo opera. La instruccin CREATE PROCEDURE asigna un nombre al procedimiento recin definido, que se utiliza para llamarlo. El nombre debe seguir las reglas de los identificadores SQL. (El procedimiento de la Figura 20.1 se denomina AGREGAR_CLIENTE.) Un procedimiento almacenado acepta ninguno o ms parmetros como argumentos. (ste tiene seis parmetros: C_NOMBRE, NUM_C, LIM_CREDI, OBJ_VEN, REP _C y OFIe_c.) En todos los dialectos SPL comunes, los valores de los parmetros aparecen en una lista separada por comas, encerradas entre parntesis; seguidamente, el nombre del procedimiento cuando se llama al procedimiento. La cabecera de la definicin del procedimiento almacenado especifica los nombres de los parmetros y sus tipos de datos. Los tipos de datos SQL admitidos por el SGBD para las columnas de la base de datos se pueden utilizar corno tipos de datos de los parmetros. En la Figura 20.1 todos los parmetros son parmetros de entrada (input en ingls, identificado por la palabra clave IN en la cabecera del procedimiento en el dialecto PL/SQL de Oracle). Cuando se llama al procedimiento se asignan a los parmetros los valores especificados en la llamada al procedimiento y se comienzan a ejecutar las instrucciones en el cuerpo del procedimiento. Los nombres de los parmetros pueden aparecer en el cuerpo del procedimiento (y particularmente en las instrucciones SQL estndar en el cuerpo del procedimiento) en cualquier lugar en que pueda aprecer una constante. Cuando aparece el nombre de un parmetro, el SGBD utiliza su valor en curso. En la Figura 20.1 se utilizan los parmetros en la instruccin IN5ERT y en la instruccin UPDATE, ambos como valores de datos a utilizar en los clculos de columna y condiciones de bsqueda.
/Y Procedimiento para agregar un cliente */ crea te proc agregar_cliente /y nombre del cliente, @nombre_c varchar(20}, entrada */ /* nmero del cliente, @num_c integer, entrada */ /* lmite de crdito, @lim_cred money, entrada */ /* objetivo de ventas, @obj_ven money, entrada */ /* nmero de empleado del representante, entrada */ /* ciudad de la oficina, @ofic_c varchar(l5} entrada */
as begin
/* Insertar una fila nueva en la tabla CLIENTES */
insert into clientes (num~cli, empresa, rep_cli, limite_credito) values (@num_c, @nombre_c, @rep_c, @lim_cred)
/* Actualizar la fila de la tabla REPRESENTANTES */ update representantes set cuota ~ cuota + cuota + @obj_ven where num_empl = @rep_c
/* Actualizar la fila de la tabla OFICINAS */ update oficinas set objetivo = objetivo + @obj_ven where ciudad = @ofic_c
/* Comprometer la transaccin y finalizar */ commit trans end
Figura 20.2.
Procedimiento AGREGAR_CLIENTE en PL/SQL.
70S
709
erosaft tambin utiliza el dialeclO Transacl-SQL; sus fundamentos han cambiado mucho desde la versin original SQL Server de Sybase, en la cual se basaron las lneas de producto Microsoft y Sybase). Obsrvese las diferencias con el dialecto de Oraele:
La palabra clave PROCEDURE se puede abreviar por PROC. No hay una lista enlre parntesis de parmetros que sigue al nombre del pro~ cedimiento. En su lugar las declaraciones de los parmetros siguen inmediatamente al nombre del procedimiento almacenado. Todos los nombres de los parmetros comienzan con un signo @, cuando se declaran al comienzo del procedimiento y cuando aparecen en las instrucciones SQL en el cuerpo del procedimiento. No hay. un marcador formal del final del cuerpo del procedimiento. En su lugar el cuerpo del procedimiento es una nica instruccin Transact-SQL. Si se necesita ms de una instruccin, se utiliza la estructura de bloques de Transact-SQL para agrupar las instrucciones.
/~ Procedimiento para agregar un cliente */ crea te procedure agregar_cliente nombre_c varchar(20), /~ nombre del cliente, entrada */ num_c integer, /* nmero del cliente, entrada */ lim_cred money(16,2}, /* lmite de crdito, entrada */ obj_ven money(16,2), /* objetivo de ventas, entrada */ rep_c integer, /* nmero de empleado del representante, entrada *1 1* ciudad de la oficina, of~c_c varchar(lS)} entrada */
/* Insertar una fila nueva en la tabla CLIENTES
~I
insert into clientes (num_cli, empresa, rep_cli, values (nUID_c, nombre_c, rep_c, lim_cred);
/* Actualizar fila de la tabla REPRESENTANTES update representantes set cuota ~ cuota + cuota + obj_ven where num_empl : rep_c;
/* Actualizar fila en la tabla OFICINAS */ update oficinas set objetiva : objetivo + obj_ven where ciudad : ofic_c;
~/
limite_creditol
La Figura 20.3 muestra el procedimiento AGREGAR_CLIENTE de nuevo, esta vez expresado en el dialecto de procedimientos almacenado de Informix. La declaracin de la cabecera del procedimiento y los parmetros son muy parecidos al dialecto de Oracle. Al contrario que en el ejemplo de Transact-SQL. las variables locales y los parmetros utilizan normalmente identificadores SQL como sus nom~ bres, sin ningn smbolo especial de identificacin. La definicin del procedimiento se finaliza formalmente con una clusula END PROCEDURE, que hace que la sintaxis sea menos susceptible de errores. En todos los dialectos en que se utiliza la instruccin CREATE PROCEDURE el procedimiento se puede eliminar, cuando ya no sea necesario, mediante una instruccin DROP PROCEDURE:
DROP PROCEDURE AGREGAR_CLIENTE
/* Comprometer la transacci6n y finalizar */ commit transaction; end procedure;
Figura 20.3.
Procedimiento AGREGAFLCLIENTE en SPL de Informix.
Llamada a un procedimiento almacenado

Una vez definido el procedimiento almacenado mediante una instruccin CREATE PROCEDURE se puede utilizar. Una aplicacin puede solicitar la ejecucin del procedimiento almacenado utilizando la instruccin SQL adecuada. Otro procedimiento almacenado puede llamarlo para que ejecute una funcin especfica. El procedimiento almacenado tambin se puede invocar mediante una interfaz SQL interactiva. Los distintos dialectos SQL difieren en la sintaxis especfica utilizada para llamar a un procedimiento almacenado. A continuacin se muestra una llamada a un procedimiento AGREGAR_CLIENTE en el dialecto PUSQL:
EXECUTE AGREGAR_CLIENTE('Empresa XYZ', 2137, . 103, 'Castel16n') 30000.00, 50000.00,
Se especifican los valores a utilizar por los parmetros del procedimiento, por orden, en una lista que se encierra entre parntesis. Cuando se llama desde otro procedimiento O disparador, se puede omitir la instruccin EXECUTE, y la llamada se convierte simplemente:
AGREGAR_CLIENTE('Empresa XYZ', 'Castel16n ') 2137, 30000.00, SOOOO.OO, 103.
En el dialecto Transact-SQL la llamada al procedimiento almacenado se convierte en:

EXECUTE AGREGAR_CLIENTE 'Empresa XYZ', 103. 'Castelln' 2137, 30000.00. 50000.00,
710
I
,
'Empresa XYZ',
711
No se necesitan los parntesis, y los valores a utilizar en los parmetros forman de nuevo una lista separada por comas. La palabra clave EXECUTE se puede abreviar a EXEC, y los nombres de los parmetros se pueden especificar explcitamente en la llamada, permitiendo especificar los valores del parmetro en el orden deseado. A continuacin se muestra una llamada alternativa equivalente en Transacl-SQL del procedimiento almacenado AGREGAR_CLIENTE:
EXEC AGREGAR_CLIENTE @C_NOMBRE @NUM_C
/. Comprobar el pedido total de un cliente ./ create proc comprobar_total @num_c integer /* un parmetro de entrada ./ as
/* Declarar dos variables locales */ declare @tot_pedido money. @texto_mensaje varchar(30)
2137,
@LIM_CRED @OFIC_C
@REP_C
@OBJ_VEN
30000.00,
'Castelln' . 103.
50000.00
EXECUTE
begin /. Calcular los pedidos totales de un cliente */ se1ect @tot-pedido : sum(importeJ from pedidos where cliente = @num_c
La fonna en SPL de Informix de la misma instruccin
es:
EXECUTE PROCEDURE AGREGAR_CLIENTE('Empresa XYZ', 2137, 30000.00, 50000.00, 103, 'Castelln' J
/. Cargar el mensaje apropiado. basado en el total */ if tot-pedido > 30000.00 se1ect @texto_mensaje -total de los pedidos alto" el se se1ect @texto_mensaje "total de los pedidos bajo"
/* Ms procesamiento para el texto del mensaje ./
De nuevo, los parmetros estn encerrados en una lista entre parntesis, separados por comas. Esta forma de la instruccin EXECUTE se puede utilizar en cualquier contexto. Por eje~pl.o, puede ser utilizada por una aplicaci?n.SQL incorporada para invo- , car un procedimiento almacenado. Dentro del procedImiento almacenado mismo se! puede llamar a otro procedimiento almacenado utilizando la instruccin equivalente:
CALL AGREGAR_CLIENTE ( 'Empresa XYZ', . Castelln' l 2137, 30000.00, 50000.00.103
end
Figura 20.4.
Uso de variables locales en Transact-SQL.
Variables de los procedimientos almacenados

Adems de los parmetros pasados a un procedimiento almacenado, suele ser conveniente o necesario definir otras variables que alberguen valores intermedios durante la ejecucin de los procedimientos. Todos los dialectos de procedimientos almacenados proporcionan esta capacidad. Normalmente las variables se declaran al comienzo del cuerpo del procedimiento, justo despus de la cabecera del procedimiento y antes de la lista de instrucciones SQL. Los tipos de datos de las variables pueden ser cualquiera de los tipos de datos SQL admitidos como tipos de datos de las columnas. La Figura 20.4 muestra el fragmento de un procedimiento almacenado Transact-SQL sencillo que calcula importe total de pedidos pendientes para un nmero de cliente especfico y establece un mensaje u otro dependiendo de si la cantidaD del pedido total est por encima o por debajo de 30.000 . Ntese que los nombres de las variables locales de Transact-SQL, al igual que los nombres de los parmetros, comienzan con un signo arroba (@). La instruccin DECLARE declara las variables locales para este procedimiento. En este caso, hay dos variables: una con el tipo de datos MONEY y otra con VARCHAR.
En Transact-SQL la instruccin SELECT asume la funcin adicional de asignar valores a las variables. Una forma sencilla de este uso de SELECT es la asignacin del mensaje de texto:
SELECT @TEXTO_MENSAJE : "total de los pedidos alto"
Un ejemplo ms complejo es la asignacin de la cantidad total del pedido al comienzo del cuerpo del procedimiento, donde SELECT se utiliza para asignar un valor y como introductor de la consulta que genera el valor a ~signar. .' La Figura 20.5 muestra la versin SPL de Informix del ffilsmo procedllruento almacenado. Hay varias diferencias con la versin Transact-SQL: Las variables locales de declaran mediante la instruccin DEFINE. Este ejemplo muestra solamente un subconjunto muy limitado de las opciones que estn disponibles. Los nombres de las variables son identificadores SQL normales; no hay un . ' primer carcter especial. Se utiliza en SPL una instruccin SELECT INTO especial para aSIgnar el resultado nico de una instruccin SELECT a una variable local.
712
713
/* Comprobar el total de los pedidos de un cliente */ crea te procedure chk_tot (num_c integerl
/* Declarar dos variables locales -/ define tot-pedido money{16,2); define texto_mensaje varchar(30);
1* Calcular los pedidos totales para el cliente solicitado */ select sum(importe) into tot._pedido fram pedidos where cliente ~ nuro_e;
/* Comprobar el total de los pedidos de un cliente */ create procedure chk_tot (num_c in integer) as declare /* Declarar dos variables locales */ tot_pedido number{l6,2); texto_mensaje varchar(30);
begin
/* Calcular los pedidos totales para el cliente solicitado */ select sum(importe) into tot_pedido froro pedidos where cliente = num_c;
/* Cargar el mensaje apropiado, basado en el total */ if tot-pedido > 30000.00 texto_mensaje ;= 'total de los pedidos alto'; else texto_mens~je ;= 'total de los pedidos bajo';
" Cargar el mensaje apropiado, segn el total " i f tot._pedido > 30000.00 let texto_mensaje == "total de los pedidos alto"
else
let texto_mensaje = "total de los pedidos bajo'
/* Realizar otro procesamiento para el texto del mensaje */
end procedure;
Figura 20.5.
Uso de variables locales en SPL de Informix.
/*
Realizar otro procesamiento para el texto del mensaje */
end;
Figura 20.6. La instruccin variables.

LET
Uso de variables locales en Pl/SGL de Oracle.
proporciona asignaciones sencillas de los valores de las
Bloques de instrucciones
La Figura 20.6 muestra la versin PLlSQL de Oraele del mismo procedimiento almacenado. De nuevo, hay varias diferencias entre los ejemplos Transact-SQL y SPL de Infonnix: Las declaraciones de las variables locales aparecen en una seccin DECLARE separada. Esta seccin es realmente una parte integral de la estructura de bloque BEGIN ... END; declara las variables locales para su uso en el bloque. La instruccin SELECT INTO tiene la misma forma que el procedimiento In- t formix; se utiliza para seleccionar los valores de una consulta de una fila directamente en variables locales. Las instrucciones de asignacin utilizan la notacin de Pascal (: =) en lugar de una instruccin LET. Las variables locales en un procedimiento almacenado se pueden utilizar como origen de los datos en expresiones SQL en cualquier lugar donde puede aparecer una constante. El valor actual de la variable se utiliza en la ejecucin de la instruccin. Adems, las variables locales pueden ser destino para los datos derivados de expresiones o consultas SQL, como se muestra en los ejemplos anteri"ores.
Es normalmente necesario en los procedimientos almacenados, excepto en los ms sencillos, agrupar una secuencia de instrucciones SQL de forma se traten como si fuera una nica instruccin. Por ejemplo, en la estructura IF ... THEN ... ELSE, utilizada normalmente para controlar el flujo de la ejecucin de un procedimiento al~ macenado, la mayor parte de dialectos de procedimientos almacenados esperan una nica instruccin seguida de la palabra clave THEN. Si tn procedimiento requiere ejecutar una secuencia de varias instrucciones SQL cuando la condicin de comprobacin es verdadera, se deben agrupar las instrucciones como un bloque de instruccin, y este bloque aparecer despus de THEN. En Transact-SQL, un bloque de instrucciones' tiene esta sencilla estructura:
/* Bloque de instrucciones Transact-SQL ./ begin /* Secuencia de instrucciones SQL */
end
La nica funcin del par BEGIN ... END es crear un bloque de instrucciones; no influyen en el mbito de las variables locales u otros objetos de la base de datos.
714
715
La definicin del procedimiento Transact-SQL, las construcciones de ejecucin condicional, bucles y otras se designan para operar con instrucciones SQL nicas, de fonna que Jos bloques se utilizan frecuentemente en cada uno de estos contextos para agrupar instrucciones en una nica unidad. En SPL de Inforrnix, un bloque de instrucciones no solamente incluye una secuencia de instrucciones, sino que puede opcionalmente declarar variables locales' para su uso en el bloque y controladores de excepciones para gestionar errores que pueden ocurrir en el bloque. A continuacin se muestra la estructura de un bloque de instrucciones Informix SQL:
Bloque de instrucciones SPL de Informix I~ Declaracin de variables locales */ define . . .
I~ ~I
Las tres secciones del bloque son opcionales. Normalmente se utiliza la estructura con solamente la secuencia BEGIN ... END para definir una secuencia de instrucciones, o con una secuencia DECLARE .. BEGIN ... END para declarar variables y una secuencia de instrucciones. Como en Informix, las estructuras Oracle que especifican la ejecucin condicional y los bucles tienen sus propios marcadores de fin de instruccin autodefinidos, por lo que las secuencias de instrucciones en estas estructuras no necesitan una estructura de bloques BEGIN ... END explcita.
Devolucin de un valor
Adems de los procedimientos almacenados, la mayor parte de los dialectos SPL incorporan las funciones almacenadas. La diferencia es que una funcin almacenada devuelve un valor, mientras que un procedimiento almacenado no. Veamos un sencillo ejemplo de funcin almacenada. Consideremos que se desea definir un procedimiento almacenado que, dado un nmero de cliente, calcule la cantidad total del pedido en curso para dicho cliente. Si se define el procedimiento como funcin, se puede devolver la cantidad total. La Figura 20.7 muestra una funcin almacenada en Gracle que calcula la cantidad total de pedidos en curso para un cliente, dado un nmero de cliente. N6tese la clusula RETURNS en la definicin del procedimiento, la cual dice el tipo de datos del SOBD del valor a devolver. En la mayora de los productos SOBD, si se introduce una llamada de funci6n mediante SQL interactivo, se muestra el valor de la funcin como respuesta. En un procedimiento almacenado, se puede llamar a una funcin almacenada y utilizar su valor devuelto en los clculos o almacenarlo en una variable.
/* Declaracin de la gestin de excepciones */ on exception
/* Definir la secuencia de instrucciones SQL */ begin.
end
La seccin de declaracin de variables es opcional; ya hemos visto un ejemplo ) de ello en el cuerpo del procedimiento almacenado lnformix, en la Figura 20.5. La seccin de gestin de excepciones tambin es opcional; su funci6n se describe posteriormente en la seccin Manejo de condiciones de error. La secuencia BEGIN .. END realiza la misma funci6n en Transact-SQt. Informix tambin permite que aparezcan instrucciones nicas en esta posici6n, si el bloque consiste en solamente los otros dos componentes y una inslrucci6n SQL o SPL sencilla. La estructura del lenguaje Informix SQL no requiere el uso de los bloques de instruccin tan frecuentemente como las otras estructuras Transact-SQt. En el dialecto Informix, las instrucciones de ejecuci6n condicional de bucles incluyen una / terminaci6n explcita (IF ... E~D 1F, WHILE ... END WHILE, FOR ... END FOR). En la estructura puede aparecer una nica instruccin SQL o una secuencia de instrucciones (cada una terminada en un punto y coma). Como resultado no siempre se necesita una estructura de bloques explicita para agrupar una secuencia de instrucciones SQL. La estructura de bloques PUSQL tiene las mismas capacidades que la estructura Informix. Ofrece la capacidad de declarar variables y condiciones de excepcin mediante el siguiente formato:
/* Bloque de instrucciones PL/SQL de Oracle */ /* Declaracin de variables locales */
/* Devolver el importe total de los pedidos de un cliente */ create function obtener_tot_pedidos(num_c in integer} return number(lG,2) as
/* Declarar una variable para albergar el total */ declare tot-pedido number(lG,2);
begin
/* Consulta sencilla de una nica fila para obtener el total */ select sum{importe) into tot_pedide frem pedidos where cliente = num_c;
/* devuelve el valor recuperado como valor de la funcin */ return tot_pedido; end;
declare
/* Secuencia de instrucciones */ begin .
/* Declaracin de la gestin de excepciones */ exception
end;
Figura 20.7.
Funcin almacenada de Pl/SQL de Oracle.
716
Captulo" 20: Procesamiento de bases de datos y procedimientos...
717
Muchos dialectos SPL tambin permiten utilizar una funcin almacenada como una funcin definida por el usuario en expresiones de valor SQL. Esto es cieno para el dialecto PUSQL de Oracle, por 10 que este uso de la funcin definida en la Figura 20.? en una condicin de bsqueda es legal.
SELECT FROM WHERE AND EMPRESA, NOMBRE CLIENTES, REPRESENTANTES REP_CLI : NUM_EMPL OBTENER_TOT_PEDIDOS(NUM_CLII
valor negativo devuelto indica diversos tipos de errores. Los procedimientos almacenados definidos por el sistema en Adaptive Server de Sybase y SQL Server de Microsoft todos utilizan este convenio de valor de estado. El estado de retorno de un procedimiento se puede almacenar en una variable local usando esta forma de asignacin de la instruccin EXECUTE:
declare sts_val int execute sts_val agregar_cliente 'Empresa XYZ'. 50000.00, 103, 'CasteIln'
2137.
>
10000.00
30000.00.
Puesto que el SGBD evala la condicin de bsqueda para cada fila de los resultados preliminares de la consulta, utiliza el nmero de cliente de la fila candidata actual como argumento para la funcin OBTENER_TOT_PEDIDOS y se comprueba si excede el umbral de 10.000 . Esta misma consulta se podra expresar como una consulta agrupada. con la tabla PEDIDOS tambin incluida en la clusula FROM y los resultados agrupados por cliente y representante. En muchas implementaciones. el SOBD realiza la consulta agrupada ms eficientemente que la pre~ cedente, lo cual probablemente fuerza al SGBD a procesar la tabla de pedidos una vez cada para cada cliente. La Figura 20.8 muestra la definicin SPL de Informix para la misma funcin almacenada mostrada en la Figura 20.7. Excepto por variaciones de estilo, difiere ) muy poco de la versin de Oracle. Transact-SQL no tiene funciones almacenadas como las ilustradas en las figu- . ras 20.7 y 20.8. Los procedimientos almacenados Transact-SQL pueden devolver explcitamente un cdigo de estado y utilizan una instruccin RETURN para este propsito. Sin embargo, el valor devuelto siempre es un valor de estado entero. Un valor cero indica la terminacin satisfactoria del procedimiento almacenado; un
Devolucin de valores por parmetros

La capacidad de funcin almacenada proporciona solamente la posibilidad de devolver un nico valor de una rutina almacenada. Varios dialectos de procedimientos almacenados proporcionan un mtodo para devolver ms de un valor, lo que permite enviar los valores a la rutina que la llama mediante parmelros de salida. Los parmetros de salida se listan en la lista de parmetros del procedimiento almacenado, al igual que los parmetros de entrada vistos en los ejemplos anterio~ res. Sin embargo, en lugar de ser utilizados para pasar valores de datos al procedimiento almacenado cuando se llama, los parmetros de salida se utilizan para devolver los datos del procedimiento almacenado al procedimiento que lo llama. La Figura 20.9 muestra un procedimiento almacenado PUSQL para recuperar el nombre de un cliente, su representante y la oficina de ventas a la que el cliente est asignado. dado un nmero de cliente. El procedimiento tiene cuatro parmetros. El primero, NUM_C. es un parmetro de entrada y proporciona el nmero de cliente solicitado. Los otros tres parmetros son parmetros de salida. utilizados para pasar los datos al procedimiento que 10 llama. En este sencillo ejemplo, la forma
/* Devolver el importe total de los pedidos de un cliente */ create function obtener_tot_pedidos{num_c in integer) returning money(16,2)
/* Declara una variable local para albergar el total */ define tot-pedido money{16,2);
begin
/* Sencilla consulta de una nica fila para obtener el total */ select sum(importe) into tot_pedido from pedidos where cliente: num_c;
/* Devuelve el valor recuperado como valor de la funcin */ return tot-pedido; end function;
/* Obtiene el nombre del cliente, representante y oficina */ create procedure obtener_info_cliente(num_c in integer, nombre_c out varchar(20), nombre_r out varchar(15) , ofic_c out varchar(ls)) as begin /* consulta de una nica fila para obtener informacin *{ select empresa, nombre, ciudad into nombre_c, nombre_r, ofic_c from clientes, representantes. oficinas where num_cli : num_c and num_empl : rep_cli and oficina : oficina_rep; end;
Figura 20.8:
Una funcin almacenada SPL de lnformix.
Figura 20.9.
Procedimiento almacenado Pl/SQL con parmetros de salida.
718
719
SEL"ECT INTO de la consulta ubIca las variables devueltas directamente en los parmetros de salida. En un procedimiento almacenado ms complejo, los valores devueltos pueden ser calculados y ubicados en los parmetros de salida con una instruccin de asignacin PUSQL. Cuando se llama a un procedimiento almacenado con parmetros de salida, el valor pasado para cada parmetro de salida debe ser un objetivo aceptable que pueda recibir un valor devuelto. El objetivo puede ser una variable local, por ejemplo, o un parmetro de un procedimiento de un nivel superior que llama a un procedimiento de nivel inferior para que realice alguna tarea. A continuacin se muestra un fragmento de un procedimiento PUSQL de Oracle que realiz.a la llamada apropiada al procedimiento OBTENER_INFO_CLIENTE de la Figura 20.9: /. Obtiene la informacin de cliente para el cliente 2111 ./ declare el_nombre varchar(20), el_rep varchar(15), la_ciudad varchar(15); execute obtener_info_cliente(2111, el_nombre, el_rep, la_ciudad);
/* Obtiene el nombre del cliente, representante y oficina ./ create procedure obtener_info_cliente{num_c in integer, nombre_c out varchar(20) , nombre_r out varchar(l5), ofic_c out varchar(15)
as
begin /- Sencilla consulta de una fi1a para obtener informacin ./ select empresa, nombre, ciudad into nombre_c, nombre_r, ofic_c from clientes, representantes, oficinas where num_cli ~ num_c and num_empl : rep_cli and oficina ; oficina_rep; end;
Por supuesto, no sera usual llamar a este procedimiento con un nmero de cliente literal, pero es perfectamente legal, puesto que hay un parmetro de entrada. Los tres parmetros restantes tienen objetivos de asignacin de datos aceptables (en este caso son variables PUSQL) pasados de forma que puedan recibir los valores devueltos. sta es una llamada ilegal al mismo procedimiento:
/. Obtiene la informacin de cliente para el cliente 2111 ./ execute obtener_info_cliente(211l, ~Emp XYZ", el_rep, la_ciudad)
Figura 20.10.
Procedimiento almacenado TransactSQL con parmetros de salida.
La Figura 20.11 muestra la versin SPL de Informix del mismo ejemplo de procedimiento almacenado. Informix adopta un enfoque diferente para gestionar varios valores de salida. En lugar de parmetros de salida, Informix extiende la definicin de una funcin almacenada y permite varios valores devueltos. Por ello, el procedimiento OBTENER_INFO_CLIENTE se convierte en una funcin en el dia-" JI
/. Obtiene el nombre de cliente, representante y oficina ./ create function obtener_info_clientelnum_c integer) returning varchar(20) , varchar(15) , varchar(15) define nombre_c varchar(20); define nombre_r varchar(15); define ofic_c varchar(15); /. Sencilla consulta de una fila para obtener informacin */ select empresa. nombre, ciudad into nombre_c, nombre_r, ofic_c from clientes, representantes, oficinas where num_cli ; num_c and num_empl ; rep_cli and oficina ; oficina_rep; /. Devuelve los tres valores ./ returo nombre_c, nombre_r, ofie_c; end procedure;
debido a que el segundo parmetro es un parmetro de salida y no puede recibir un valor literaL Adems de los parmetros de entrada y salida, Oraele permite especificar parmetros del procedimienlo que sean ambos parmetros de entrada y salida (INOUT). Deben obedecer a las mismas restricciones previamente citadas para los parmetros de salida, pero adems, sus valores son utilizados por el procedimiento corno entradas. La Figura 20.10 muestra una versin del procedimiento OBTENER_INFO_CLIENTE definida en el dialecto Transacl-SQL. La fonna en que son identificados los parmetros de salida en la cabecera del procedimiento difiere ligeramente de la versin Oraele, y la instruccin de una nica fila SELECT tiene una forma distinta. Por otra parte, la estructura del procedimiento y su operacin es idntica a la del ejemplo de Omele. Cuando un procedimiento Transact-SQL llama a ste, el hecho de que el se gundo, tercer y cuarto parmetros sean parmetros de salida se "debe indicar en la llamada al procedimiento, as como en su definicin. A continuacin se muestra la sintaxis Transact-SQL para la llamada al procedimiento en la Figura 20.10:
/. Obtiene la informacin del cliente para el cliente 2111 ./ declare el_nombre varchar(20); declare el_rep varchar{lS); declare la_ciudad varcharllS); exec obtener_info_cliente @num_c ~ 2111, @nombre_c ~ el_nombre output, @nombre_r : el_rep output, @ofic_c = la_ciudad output
Figura 20.11.
Funcin almacenada Informix con varios valores devueltos.
720
721
leeto Informix. Los diversos valores devueltos se especifican en la clusula RETURNING de la cabecera del procedimiento y entonces se devuelven realmente mediante la instruccin RETURN. La instruccin de Informix CALL que invoca a la funcin almacenada utiliza una clusula especial RETURNING para recibir los valores devueltos:
/* Obtiene la informacin de cliente para el cliente 2111 */ define el_nombre varchar(20); define el_rep varchar(15); define la_ciudad varchar(15);
ofl.c_c
in varchar{15))
It ciudad de la oficina, entrada tI
as begin It Inserta nueva fila en la tabla CLIENTES tI insert into clientes (num_cli, empresa, rep_cli, 1imite_credito) values (num_c, nombre_c, rep_c, 1iffi-credl:
if obj_ven <: 20000.00 then It Actualiza la fila de la tabla REPRESENTANTES *1 update representantes set cuota : cuota + cuota + obj_ven where num_empl : rep_c; else 1* Actualiza la fila de la tabla REPRESENTANTES *1 update representantes set cuota = cuota + cuota + 20000.00 where num_empl : rep_c: end if
eall obtener_iofo_cliente
(211l)
returning el_nombre, el_rep,
la_ciudad;
Como en el dialecto Transact-SQL, lnformix tambin permite una versin de la instruccin CALL que pasa los parmetros por nombre:
call obtener_info_cliente (num_c : 2111) returning el_nombre, e1_rep, la_ciudad:
'1
Ejecucin condicional
Una de las caractersticas ms bsicas de los procedimientos almacenados es la ) construccin IF ... THEN ... ELSE para la toma de decisiones en el procedimiento.. Veamos de nuevo el procedimiento AGREGAR_CLIENTE definido en la Figura 20.1 para agregar un nuevo cliente. Supongamos que las reglas para agregar nuevos clientes se modifican de fonna que hay un lmite en el importe segn el cual la cuota del representante se tiene que incrementar por cada nuevo cliente. Si los pedidos anticipados por el cliente son 20.000 o menos, se tiene que agregar esa cantidad a la cuota, pero si hay ms de 20.000 , la cuota se tiene que incrementar solamente en 20.000 . La Figura 20.12 muestra un procedimiento modificado que
It Actualiza la fila de la tabla OFICINAS *1 update oficinas set objetivo : objetivo + obj_ven where ciudad ofic_c:
1* Compromete la transaccin *1 cornmit; end
Figura 20.12.
Lgica condicional en un procedimiento almacenado. (Continuacin.)
ir
1;
/ ' Procedimiento para agregar un cliente ' / create procedure agregar_cliente nombre_c in varchar{20), / ' nombre del cliente, entrada tI num_c in integer. / ' nmero del cliente, entrada ' / lim_cred in number(16,2), / ' lmite de crdito, entrada ' / obj_ven in number(16,2), /' objetivo de ventas, entrada ' / rep_c in integer. It nmero de empleado del representante, entrada ' /
implementa esta nueva directriz. La lgica IF ... THEN ... ELSE opera exactamente como lo hace en cualquier lenguaje de programacin convencional. Todos los dialectos de procedimientos almacenados permiten instrucciones IF anidadas para una toma de decisiones ms compleja. Algunos proporcionan lgica condicional extendida para permitir la bifurcacin mltiple. Por ejemplo, supongamos que se desean realizar tres cosas distintas en el procedimiento almacenado AGREGAR_ CLIENTE, dependiendo de si los pedidos anticipados del cliente para el primer ao estn por debajo de 20.000 , entre 20.000 Y50.000 o por encima de 50.000 . En PUSQL de Oraele se puede expresar esta decisin triple de la siguiente fonna:
/* Procesa los objetivos de ventas por rango *1 if obj_ven < 20000.00 then 1* Aqu se gestionan los clientes con objetivo bajo */
Figura 20.12.
Lgica condicional en un procedimiento almacenado. (Contina.)
722

if (num_elem = elem_especial) then exit for; end for;
723
elsif obj_ven < 50000.00 then /* Aqu se gestionan los clientes con objetivo medio */
else
/* Aqu se gestionan los clientes con objetivo alto */
end if;
En el dialecto lnforrnix se permite la misma estructura de bifurcacin mltiple. La palabra clave ELSIF se convierte en ELIF, pero el resto permanece iguaL
La otra forma comn de bucle se da cuando una secuencia de instrucciones se ejecuta repetidamente mientras existen ciertas condiciones o hasta que exista alguna condicin especificada. A continuacin se muestra una construccin de bucle PUSQL de Oracle que repite indefinidamente. Este bucle debe, por supuesto, proporcionar una comprobacin en el cuerpo del bucle que detecte la condicin de terminacin del bucle (en este caso, una coincidencia entre dos variables) y salga explcitamente de ste:
/* Procesa repetidamente algunos datos */ loop /* Realiza un cierto procesamiento cada vez */
Ejecucin repetida
Otra caracterstica comn a casi todos los dialectos de procedimientos almacenados es
una construccin para la ejecucin repetida de un grupo de instrucciones (bucles). Dependiendo del dialecto puede haber soporte para los bucles FOR estilo Basic (donde se incrementa o decrementa un valor entero para el control del bucle) o bucles WHILE estilo e con una condicin de comprobacin ejecutada al comienzo o fin del bucle. En el ejemplo de la base de datos es difcil encontrar un ejemplo no rebuscado con bucles. Consideremos que se desea procesar un grupo de instrucciones repetida-) mente mientras el valor de la variable de control del bucle, llamada NUM_ELEM, vale entre l a 10. A continuacin se muestra un bucle PUSQL de Drade que gestiona esta situacin:
/* Procesa cada uno de los 10 elementos */ for num_elem in l .. 10 loop /* Procesa este elemento particular */
/* Comprueba si salir del bucle anticipadamente */ exit when (valor_test = valor_salida): end loop;
Una construccin de bucle ms comn es una que incorpora el test en la estructura misma del bucle. El bucle se ejecuta repetidamente siempre que la condicin es cierta. Por ejemplo, supongamos que se desean reducir los objetivos de las oficinas en la base de datos ejemplo hasta que el total de objetivos sea menor de 2.400.000 . El objetivo de cada oficina se va a reducir en la misma cantidad, que tiene que ser un mltiplo de 10.000 . A continuacin se muestra un bucle en un procedimiento almacenado Transact-SQL (no muy eficiente) que reduce gradualmente los objetivos de la oficina hasta que el total est por debajo del umbral:
/* Decrementa los objetivos hasta que el total sea menor que
/* Comprueba si finalizar el bucle */ exit when (oum_elem = elem_especia1); end loop;
Las instrucciones en el cuerpo del bucle se ejecutan normalmente diez veces, cada vez con un valor entero mayor en la variable NUM_ELEM. La instruccin EXIT proporciona la capacidad de salir de un bucle PUSQL de Dracle de forma antici- ' pada. Puede ser incondicional o se puede utilizar con una condicin de comprobacin incorporada, como en este ejemplo. A continuacin se muestra la misma estructura de bucle expresada en SPL de Informix, mostrando algunas de estas capacidades adicionales y las diferencias del dialecto con PUSQL:
/* Procesa cada uno de los 10 elementos */ for num_elero = 1 to 10 step 1 /* Procesa este elemento particular */
2.400.000 */ while lselect sum{objetivo) froro oficinas) < 2400000.00 begin update oficinas set objetivo objetivo - 10000.00
end
El bloque BEGIN ... END en el bucle WHILE no es estrictamente necesario, pero la mayora de los bucles Transact-SQL WHILE incluyen uno. Transact-SQL repite la nica instruccin SQL que sigue a la condicin de comprobacin, como el cuerpo del bucle WHILE. Si el cuerpo del bucle consiste en ms de una instruccin, se debe utilizar un bloque BEGIN ... END para agrupar las instrucciones_ A continuacin se muestra la versin PUSQL de Oracle del mismo bucle:
/* Decrementa los objetivos hasta que el total sea menor que 2.400.000 */
/* Comprueba si finaliza el bucle */
select sum(objetivol into total_obj while (total_obj < 2400000.00)
trom oficinas;
724
725
loop update oficinas

set objetivo = objetivo ~ 10000.00; select sum(objetivo) inta total_obj froro oficinas:
end loop;
La versin con subconsulla de la instruccin SELECT de Transacl-SQL se ha reemplazado por la forma SELECT INTO de PUSQL de la instruccin, con una variable local utilizada para albergar el total de los objetivos de las oficinas. Cada vez que se ejecuta el bucle, se actualiza la tabla OFICINAS y se recalcula el total de los objetivos. A continuacin se muestra el mismo bucle una vez ms, expresado utilizando la instruccin WHILE de SPL de Informix:
1- Decrementa los objetivos hasta que el total sea menor que 2.400.000 -,
Con etiquetas para las instrucciones y para la instruccin GOTO se proporciona control adicional del flujo de ejecucin en los procedimientos almacenados. En la mayora de los dialectos, la etiqueta de la instruccin es un identificador seguido de dos puntos. La instruccin GOTO llama a la etiqueta a la cual se debera transferir el control. Normalmente se da la limitacin de que no se puede transferir el control de un bucle o una instruccin de comprobacin condicional, y siempre existe una prohibicin de transferir el control en el medio de dicha instruccin. Como en los lenguajes de programacin estructurados, el uso de las instrucciones GOTO est desaconsejado, puesto que hace que el cdigo del procedimiento almacenado sea ms complicado de comprender y depurar.
Repeticin con cursores

select sum(objetivo) inta total_obj fraro oficinas; while (total_obj < 2400000.00) update oficinas set objetivo z objetivo - 10000.00; select sum(objetivoJ into total_obj froro oficinas;
end while;
En diversos dialectos se proporcionan otras variantes de estas construcciones de procesamiento de bucles, pero las capacidades y sintaxis son similares a estos ejemplos.
Otras constructoras de flujo de control

Algunos dialectos de procedimientos almacenados proporcionan instrucciones para controlar el flujo y alterar el flujo de control. En Inforrnix, por ejemplo, la instruccin EXIT interrumpe el flujo normal en un bucle y provoca que la ejecucin contine con la siguiente instruccin que sigue al bucle. La instruccin CONTINUE interrumpe el flujo normal en el bucle, pero hace que la ejecucin contine en la siguiente iteracin del bucle. Ambas instrucciones tienen tres formas, dependiendo del tipo de bucle interrumpido:
exit for; continue for; exit while; continue while; exit foreach; continue foreach;
Una necesidad comn de la repeticin de instrucciones en un procedimiento almacenado se produce cuando el procedimiento ejecuta una consulta y necesita procesar los resultados de la misma, fila a fila. La mayora de los dialectos proporcionan una estructura para este tipo de procesamiento. Conceptualmente, las estructuras reflejan las instrucciones DECLARE CURSOR, OPEN CURSOR, FETCH YCLaSE CURSOR en SQL incorporado o las Uamadas correspondientes de la API de SQL. Sin embargo, en lugar de buscar los resultados de la consulta en la aplicacin, en este caso se buscan en el procedimiento almacenado, el cual se ejecuta en el SORD. En lugar de recuperar los resultados de la consulta en las variables de la aplicacin (variables anfitrionas), el procedimiento almacenado las recupera en variables locales del procedimiento almacenado. Para ilustrar esta capacidad, consideremos que se desea rellenar dos tablas con los datos de la tabla PEDIDOS. Una tabla, denominada PEDIDOSGRANDES, debera contener el nombre del cliente y el tamao del pedido para cualquier pedido superior a 10.000 . La otra, PEDIDOSPEQUEOS, debera contener el nombre del representante y el tamao de pedido para cualquier pedido por debajo de 1.000 . La mejor y ms eficiente forma de realizar esto sera mediante dos instrucciones SQL INSERT separadas con subconsultas, pero, dado el propsito didctico, en su lugar consideraremos este mtodo:
1.
2.
3. 4. 5.
Ejecutar una consulta para recuperar el importe del pedido, nombre del cliente y nombre del representante p~a cada pedido. Para cada fila de los resultados de la consulta hay que comprobar la cantidad del pedido, con el fin de ver si cae en el rango adecuado e inc1uirlo en la tabla PEDIDOSGRANDES o PEDIDOS PEQUEOS. Dependiendo de la cantidad, INSERT la fila apropiada en la tabla PEDIDOSGRANDES o PEDIDOS PEQUEOS.
En Transact-SQL, la nica instruccin BREAK proporciona el equivalente de las variantes de la instruccin lnformix EXIT, y tambin hay un nica forma-de la instruccin CONTINUE. En Oracle, la instruccin EXIT ejecuta la misma funcin que para lnformix, y no hay una instruccin CONTINUE.
Repetir los pasos 2 y 3 hasta que se acaben todos los resultados de la consulta. Realizar las actualizaciones en la base de datos.
La Figura 20.13 muestra un procedimiento almacenado Orac1e que desarrolla este mtodo. El cursor que define la consulta est descrito en la seccin de decla-
726
727
crea te procedure sort_PEDlDOS() declare /* Cursor para la consulta */ cursor cursor-p is select importe, empresa, nombre from pedidos, clientes, representantes where cliente = num_cli and rep = nUffi_empl;
/* Variable fila que recibe los resultados de la consulta */
create procedure sort_pedidos() /* Variables locales para albergar consulta * / define cant_ped money(16,2); define nombre_c varchar(20); define nombre_r varchar(l5l;
los resultados de la
/* importe del pedido */ /* nombre del cliente */
/. nombre del representante */
fila_curs cursor-p%rowtype;
begin
/* Bucle por cada fila de los resultados de la consulta */ for fila_curs in cursor_p loop
/* Comprueba los pedidos pequeBos y los gestiona */ iE (fila_curs.importe < 1000.00l then insert into pedidospequeftos values (fila_curs.nombre, fila_curs.importel;
/~ Ejecuta la consulta y procesa cada fila del resultado */ foreach select importe, empresa, nombre iota cant_ped, nombre_c, nombre_r froID pedidos, clientes. representantes where cliente : num_cli and rep : nUID_empl; begin
/* comprueba los pedidos pequeffos y los gestiona */ if (cant_ped < 1000.00) then insert into pedidospequeftos values (nombre_r, cant_ped);
/* Comprueba los pedidos grandes y los gestiona */ elsif {fila_curs.importe > 10000.00l then insert into pedidos grandes values (fila_curs.empresa, fila_curs.importe); end if; end loop;
/* Comprueba los elif (cant_ped > then insert inta values end if; end; end foreach; end procedure;
pedidos grandes y los gestiona */ 10000.00) pedidosgrandes (nombre_c, cant_ped);
Figura 20.14. Figura 20.13.

Bucle FOR basado en cursores para PIJSQL.
Bucle FOREACH basado en cursores en SPL de Informix.
raciones del procedimiento y asignado al nombre CURSOR_P. La variable FILA_CURS, descrita en la misma seccin. se define como un tipo fila de Oracle. Esta variable es una variable fila de Gracle estructurada con componentes individuales (como una estructura del lenguaje e). Al declararla como si tuviese el mismo tipo fila que el cursor, los componentes individuales de FIL~CURS tienen los mismos tipos de datos y nombres que las columnas de resultados del cursor. La consulta descrita por el cursor se realiza realmente con el bucle FOR del cursor. Bsicamente dice al SGBD que realice la consulta descrita por el cursor (equivalente a la instruccin OPEN en SQL incorporado) antes de iniciar el procesamiento del bucle. El SGBD ejecuta entonces el bucle FOR repetidamente, buscando una fila de los resultados de la consulta en la parte superior del bucle, situando los valores de la columna en la variable FILA_CURS, y despus ejecutando las instrucciones en el cuerpo del bucle. Cuando no hay ms filas de los resultados de la consulta, se cierra el cursor y el procesamiento contina despus del bucle. La Figura 20.14 muestra un procedimiento almacenado equivalente con la estructura FOR delSPL de Informix. En este caso, los resultados de la consulta se recuperan
en variables locales ordinarias; no se utiliza un tipo de datos especial. La instruccin FOREACH incorpora varias funciones distintas. Define la consulta a realizar ~ediante la expresin SELECT que contiene. Marca el comienzo del bucle que se va a ejecutar para cada fila de los resultados de la consulta (el fin del bucle se marca con la instruccin END FOREACH). Cuando se ejecuta la instruccin FOREACH. se lleva a cabo la consulta, y entonces busca las filas de los resultados de la consulta repeti?amente, p~niendo. los valores de la columna en las variables locales, como se especifica en la mstruccln. Despus de que se encuentra cada fila, se ejecuta el cuerpo del bucle. Cuando no hay ms filas en los resultados de la consulta, se cierra automticamente el cursor y la ejecuci6n contina con la siguiente instruccin que sigue a FOREACH. Ntese que en este ejemplo ni siquiera se asigna un nombre al cursor, p~e.sto .que t~o el procesamiento con el cursor est especificado estrechamente en la uOlca mstruccl~n .FOREACH. El dialecto Transact-SQL no tiene una estructura de bucle FOR especIalIzada para el procesamiento de resultados de consulta basados en cursore~. En su luga.:, las instrucciones DECLARE CURSOR, OPEN, FETCH Y CLOSE de SQL lOcorporado tIenen contrapartidas directas en el lenguaje Transact-SQL. La Figura 20.15 muestra una versin Transact-SQL del procedimiento ordenar-pedidos.
728
729
create proc ordenar-pedidos{)
SQLSTATE. Recibe un valor cero cuando liene xito una bsqueda, y un valor distinto de cero cuando no hay ms filas que buscar.
as
/* Variables locales para albergar los resultados de la consulta */ declare @cant-ped money(16,2); /* importe del pedido */ declare @nombre_c varchar(20); /* nombre del cliente */ declare 9nombre_r varchar(151: /* nombre del representante */
Gestin de condiciones de error

Cuando una aplicacin utiliza SQL incorporado o la API de SQL para el procesamiento de bases de datos, la aplicacin es responsable de la gestin de los errores que se dan lugar. Los cdigos de estado de error se devuelven a la aplicacin y normalmente est disponible ms informacin mediante llamadas API adicionales o acceso a un rea de diagnstico extendida. Cuando tiene lugar el procesamiento de bases de datos en un procedimiento almacenado, el procedimiento mismo debe gestionar los errores. TransactSQL proporciona gestin de errores mediante un conjunto de variables globales del sistema. Las variables especficas de gestin de errores son solamente unas pocas de ms de 100 variables de sistema que proporcionan informacin sobre el estado del servidor, el estado de la transaccin, conexiones abiertas y otra informacin sobre la configuracin y el estado de la base de datos. Las dos variables globales ms tiles para la gestin de errores son:
@.@@ERROR.
/* Declara el cursor para la consulta */ declare curs_p cursor tor select importe, empresa, nombre froro pedidos, clientes. representantes where cliente = num_cli
and rep = num_empl

begin
/* Abre el cursor y busca la primera fila de resultados */
apeo curs_p fetch curs_p into @cant_ped,
9nombre_c,
@nombre_r
/* si no hay filas, termina inmediatamente */ i f (@@sqlstatus :: 2) begin clase curs-I)
returo
end
1* Bucle por cada fila de los resultados de la consulta */ while (@@sqlstatus = O)
Contiene el estado de error del lote de instrucciones ms recientemente ejecutado. @.@@.SQLSTATOS. Contiene el estado de la ltima operacin de bsqueda.
begin
/* comprueba los pedidos pequeos y los gestiona */ (@cant~ped < 1000.00)
if
insert into pedidospequeftos values (@nombre_r, @cant-ped)

/* comprueba los pedidos grandes y los gestiona */ el se if (fila_curs.importe > 10000.00) insert into pedidos grandes values (@nombre_c, @cant-ped)
end
/* Terminado con los resultados, clase curs-p
cierra el cursor y finaliza */
end
Figura 20.15.
Bucle WHILE basado en cursores en TransactSQL
Ntense las instrucciones separadas DECLARE, OPEN, FETCH Y CLOSE para el cursor. El control del bucle es proporcionado mediante la comprobacin de la variable del s"istema @@SQLSTATUS, que es el equivalente Transact-SQL del cdigo
Los valores de terminacin normal para ambas variables son cero; otros valores indican varios errores y avisos. Las variables globales se pueden utilizar de la misma forma como variables locales en un procedimiento Transact-SQL. En concreto, sus valores se pueden comprobar para el control de las bifurcaciones y bucles. PUSQL de Gracle proporciona un estilo distinto para la gestin de errores. El SGBD Gracle proporciona un conjunto de excepciones definidas por el sistema, que son errores o condiciones de aviso que pueden darse durante el procesamiento de instrucciones SQL. En un procedimiento almacenado Gracle (realmente, cualquier bloque de instrucciones Gracle) la seccin EXCEPTION dice al SGBD cmo debe gestionar cualquier condicin de excepcin que ocurra durante la ejecucin del procedimiento. Hay alrededor de una docena de condiciones de excepcin predefinidas detectadas por Dracle. Adems, se pueden definir condiciones de excepcin propias. La mayoa de los ejemplos anteriores en este captulo no proporcionan ninguna capacidad real de gestin de errores. La Figura 20.16 muestra una versin revisada de la funcin almacenada de Gracle de la Figura 20.7. La versin mejorada detecta la situacin especfica en que el nmero de cliente proporcionado no tiene ningn pedido asociado (esto es, aquella en que la consulta para calcular los pedidos totales devuelve una excepcin NO_DATA_FDUND). Responde a esta situacin informando a la aplicacin de un error en un nivel de aplicacin y un mensaje asociado. Cualquier otra condicin de excepcin que se da lugar es capturada mediante el gestor de excepciones WHEN OTHERS.
730
731
"/* Devuelve la cantidad de pedidos totales de un cliente */
create function obtener_tot_pedidos(num_c in integer} returo number(16.2)
/* Devuelve la cantidad total de pedidos de un cliente */ create function obtener_tot_pedidos(num_c in integerl returning rooney(16,2)
as
/* Declara una variable local
para albergar el total */
/* Declara una variable local para albergar el total */ define tot-pedido money(16,2);
declare toc_pedido number(16.2); begin

/* Sencilla consulta de una fila para obtener el total */ select sum(IMPORTE) into tot-pedido fram pedidos where cliente = num_e;
/* Devuelve el valor recuperado como valor de la funcin */ returo tot-pedido;
/* Define el gestor de excepciones para los nmero de error -123 y 121 */ on exception in (-121, -123) /* Se realiza lo que sea apropiado */ end exception; on exception /* Aqu se gestiona cualquier otra excepcin */
exception Gestiona la 51tuac10n donde no se encuentran pedidos */ when no_data_found then raise_application~error (-20123. Nmero de cliente incorrecto') ;
'*
end exception; begin /* sencilla consulta de una fila para obtener el total */ select sum(IMPORTE) into tot-pedido froro PEDIDOS where CLIENTE = num_c;
/* Devuelve el valor recuperado como valor de la funcin */ return tot_pedido; end function;
/* Gestiona cualquier otra excepcin! when others then raise_application_error (-20199. 'Error desconocido'); end;
,
,I
Figura 20.16. Funcin almacenada PUSQL con gestin de errores. Figura 20.17. Funcin almacenada SPL de Informix con gestin de condiciones.
El SPL de Informix adopta un enfoque similar para la gestin de excepciones. La Figura 20.17 muestra la versin Informix de la funcin almacenada, con gestin de excepciones estilo Informix. La instruccin ON EXCEPTION es una instruccin declarativa, y especifica la secuencia de instrucciones SQL que ha de ejecutarse cuando ocurre la excepcin. Se puede especificar una lista de nmeros de excepcin separada por comas.
Ventajas de los procedimientos almacenados

",
Los procedimientos almacenados presentan diversas ventajas para los usuarios de bases de datos y administradores: Rendimiento en tiempo de ejecucin. Muchas marcas de SGBD compilan procedimientos almacenados (automticamente o por solicitud del usuario) en una representacin interna que se puede ejecutar muy eficientemente en el SGBD en tiempo de ejecucin. La ejecucin de un procedimiento alm.ace-
nado precompilado puede ser mucho ms rpida que la ejecucin de las instrucciones SQL equivalentes mediante el proceso PREPARE/EXECUTE. Reutilizacin. Una vez que se ha definido un procedimiento almacenado para una funcin especfica, a dicho procedimiento se puede ll~ar desde muchas aplicaciones distintas que necesitan ejecutar dIcha funCIn, lo que permite una reutilizacin muy sencilla de la lgica de la aplicacin y reduce el riesgo de error del programador de la aplicacin. . Trfico de red reducido. En una configuracin cliente/servidor, al enviar una llamada a un procedimiento almacenado a travs de la red y recibi~ los resultados en un mensaje de respuesta, se genera mucho menos trfico de red que en el caso de un viaje a travs de la red para cada in_stI~uccin SQL individual. Esto puede mejorar considerablemente el rendImIento glob~l del sistema en una red con un gran trfico o que tiene conexiones de baja velocidad. Seguridad. En la mayora de las marcas de SGBD, el procedimi~nto almacenado se trata como una entidad fiable en la base de datos y se ejecuta con
1:
732
733
'''1
j;1
,, ,
,
11
I "
sus propios privilegios. El usuario que ejecuta el procedimiento almacenado solamente necesita tener permiso para ejecutarlo; no hace falta permiso sobre las tablas subyacentes que el procedimiento almacenado puede modificar o a las que puede acceder. Por ello, el procedimiento almacenado permite al administrador de la base de datos mantener una seguridad ms fuerte sobre los datos subyacentes, mientras que an proporciona a los usuarios individuales la actualizacin de datos especficos o la capacidad de acceso a datos que requiere. Encapsulacin. Los procedimientos almacenados son una forma de lograr uno de los objetivos principales de la programacin orientada a objetos (la encapsulacin de los datos, estructuras y acceso en un conjunto de interfaces externas muy limitadas y bien definidas). En la terminologa de los objetos los procedimientos almacenados pueden ser los mtodos mediante los cuales se manipulan exclusivamente-los objetos en SGBDR subyacente. Para conseguir completamente el enfoque orientado a objetos, todo acceso directo a los datos subyacentes mediante SQL debe estar prohibido mediante el siste., ma de seguridad SGBDR, dejando slo a los procedimientos almacena'!,9d acceder a la base de datos. En la prctica, pocas bases de datos relacionales de produccin operan de esta forma restringida. Simplicidad de acceso. En una gran base de datos corporativa, una coleccin de procedimientos almacenados puede ser la forma principal con la que las aplicaciones acceden a la base de datos. Los procedimientos almacenados forman un conjunto bien definido de transacciones y consultas que pueden ser ejecutadas por las aplicaciones sobre la base de datos. Para la mayora de los programadores es ms sencillo comprender una llamada a una funcin predefinida sencilla que comprueba el saldo de una cuenta dado un nmero de cliente, o una que agrega un pedido, dado un nmero de cliente, cantidad, identificador del producto, que las instrucciones SQL correspondientes. Aplicacin de las reglas de negocio. Las capacidades de procesamiento condicional de los procedimientos almacenados se utilizan frecuentemente para ubicar reglas de negocio en la base de datos. Por ejemplo, un procedimiento almacenado utilizado para agregar un pedido a la base de datos podra contener lgica para comprobar el crdito del cliente que formula el pedido y si hay suficiente stock para cumplimentar el pedido, y rechazarlo si estas condiciones no se pueden cumplir. Una gran compaa podra tener fcilmente distntas formas de anotar los pedidos e introducirlos en la base de datos corporativa: un programa para el uso del representante, uno para las personas del departamento de televenta, otro que acepte pedidos mediante World Wide Web, etc. Cada uno de stos podra tener su propia aplicacin de aceptacin de pedidos, normalmente escrito por distintos programadores en momentos diferentes. Pero si todos los programas estn forzados a utilizar el mismo procedimiento almacenado para agregar un pedido, la compaa puede asegurar que las reglas del negocio en dicho proc~dimiento se cumplen de forma uniforme, sin importar dnde se origin el pedido.
Rendimiento de los procedimientos almacenados

Las distintas marcas de SOBD vaan en la forma en la que realmente implementan los procedimientos almacenados. En varias marcas, el texto del procedimiento almacenado se introduce en la base de datos y se interpreta cuando se ejecuta el procedimiento. Esto tiene la ventaja de crear un lenguaje de procedimientos almacenados muy flexible, pero crea una sobrecarga significativa en el tiempo de ejecucin para procedimientos almacenados complejos. El SGBD debe leer las instrucciones que forman el procedimiento almacenado en tiempo de ejecucin, analizarlas y determinar al vuelo lo que se debe hacer. Debido a la sobrecarga en el enfoque interpretado, algunas marcas de SOBD compilan los procedimientos almacenados en una forma intermedia que es mucho ms fcil de interpretar. La compilacin puede ser automtica cuando se crea el procedimiento almacenado, o el SGBD puede proporcionar al usuario la posibilidad de solicitar la compilacin del procedimiento almacenado. La desventajas de los procedimientos almacenados compilados es que la tcnica exacta utilizada para el procedimiento almacenado se fija cuando se compila el procedimiento. Supongamos, por ejemplo, que un procedimiento almacenado se crea y compila muy poco despus de que se haya creado la base de datos y despus se construyen algunos ndices tiles sobre los datos. Las consultas compiladas en el procedimiento almacenado no se aprovecharn de estos ndices y, como consecuencia, se podrn ejecutar mucho ms lentamente que si fueran recompiladas_ Para tratar con estos procedimientos compilados desde hace tiempo algunas marcas de SGBD anotan automticamente que cualquier procedimiento compilado que puede estar afectado por posteriores cambios de la base de datos necesita una recompilacin. La siguiente vez que se llame al procedimiento, el SGBD descubrir la marca y recompilar el procedimiento antes de ejecutarlo. Normalmente este enfoque proporciona lo mejor de ambos mundos (beneficia el rendimiento de la recompilacin mientras que mantiene actualizado el procedimiento almacenado). Su desventaja es que puede dar lugar a tiempos de ejecucin del procedimiento almacenado impredecibles. Cuando no es necesaria la recompilacin, el procedimiento almacenado se puede ejecutar rpidamente; cuando se activa la recompilacin, se puede producir un retraso significativo, y en la mayora de los casos, el retraso de la recompilacin es mucho mayor que la desventaja de usar la antigua versin compilada. Para determinar las capacidades de compilacin del procedimiento almacenado de un SGBD particular, se pueden examinar las opciones de instruccin CREATE PROCEDURE Y EXECUTE PROCEDURE, o buscar otras instrucciones de gestin de procedimientos, tal corno ALTER PROCEDURE.
Procedimientos almacenados definidos por el sistema

Las marcas de SGBD que admiten los procedimientos almacenados proporcionan algunas veces procedimientos almacenados incorporados, definidos por el sistema para automatizar el procesamiento de la base de datos o las funciones de gestin.
e-.....
734
1
SOL. Manual de referencia Captulo 20: Procesamiento de bases de datos y procedimientos...
735
SQL Server de Sybase inici este uso de procedimientos almacenados de sistema. Actualmente, cientos de procedimientos almacenados Transact-SQL del sistema proporcionan funciones tales como la gestin de usuarios, funciones de base de datos, ejecucin de trabajos, servidores distribuidos, rplicas. etc. La mayora de los procedimientos del sistema en Transact-SQL siguen este convenio de nombres:
SP_ADD_algo. Agrega un nu~vo objeLO (usuario, servidor, rplica, etc.).
SP_DROP _algo. SP_HELP_algo.
Elimina un objeto existente. Obtiene informacin sobre un objeto u objetos.
Por ejemplo. el procedimiento SP_HELPUSER devuelve informacin sobre los usuarios vlidos de la base de datos actual.
enlace dinmico (DLL, DynamicLinked Library) y llamarla desde los procedimientos almacenados SQL Server. lnformix proporciona acceso bsico a las capacidades subyacentes dei sistema operativo con una instruccin SYSTEM especial. Adems, admite procedimientos externos definidos por el usuario mediante su instruccin CREATE PROCEDURE. En el lugar en que pueda aparecer el bloque de instrucciones que contiene el cuerpo de un procedimiento SPL de Informix, un clusula EXTERNAL especificar el nombre, ubicacin y lenguaje del procedimiento escrito externamente. Con el procedimiento definido de esta forma, se puede llamar de igual modo que en los procedimientos SPL de Informix nativos. Las nuevas versiones de OracJe (Oracle8 y posteriores) proporcionan la misma capacidad, tambin mediante la instruccin CREATE PROCEDURE. La familia de bases de datos DBZ de IBM proporciona el mismo conjunto de capacidades.
Procedimientos almacenados externos

Aunque los procedimientos almacenados escritos en los dialectos SQL extendIdos de las marcas principales de SGBD pueden ser bastante potentes, tienen sus limitaciones. Una limitacin principal es que no proporcionan acceso a caractersticas externas al SGBD, tales como las caractersticas del sistema operativo u otras aplicaciones que se ejecutan en el mismo sistema informtico. Los dialectos SQL extendidos tambin tienden a ser lenguajes de alto nivel, con capacidad limitada para la programacin en bajo nivel, realizada en C o C++. Para evitar estas limitaciones, algunas marcas de SGBD acceden a procedimientos almacenados externos. Un procedimiento almacenado externo es un procedimiento escrito en un lenguaje de programacin convencional (tal como C o Pascal) y compilado fuera del SGBD. Se da al SGBD una definici.6n del nombre y parmetros del procedimiento, junto con otra informacin esencial tal como los convenios de llamada uti~iza~ dos por el lenguaje de programacin en el cual est escrito el procedimiento almacenado. Una vez definido para el SOBO, el procedimiento almacenado externo se puede llamar como si fuera un procedimiento almacenado SQL. El SGBD gestiona la llamada, cede el control al procedimiento externo y recibe cualquier valor y parmetro que devuelva. SQL Server de Microsoft proporciona un conjunto de procedimientos almacenados externos, definidos por el sistema, que proporcionan acceso a capacidades seleccionadas del sistema operativo. El procedimiento XP_SENDMAIL se puede utilizar para enviar correos electrnicos a usuarios, segn las condiciones en el SOBD:
XP_SENDHAIL liRECIPIENTS = 'Juan'. 'Sarnuel'. iMESSAGE = 'Tabla de clientes casi llena';
Disparadores
Como se describe al comienzo de este captulo, un disparador es un conjunto especial de cdigo de procedimiento almacenado cuya activaci~ est causada p~r modificaciones en el contenido de la base de datos. Al contrano que los procedImientos almacenados creados con una instruccin CREATE PROCEDURE, un disparador no es activado por una instruccin CALL o EXECUTE. En su lugar, el disparador se asocia con una tabla de la base de datos. Cuando se cambian los datos en la tabla (mediante una instruccin INSERT, DELETE, o UPDATE), el disparador se activa, lo que significa que el SGBD ejecuta las instrucciones SQL que forman el cuerpo del disparador. Los disparadores tambin se pueden utilizar para producir actualizaciones automticas en una base de datos. Por ejemplo, supongamos que se desea actualizar la base de datos de ejemplo de forma que, siempre que se inserte un representante en la tabla REPRESENTANTES, el objetivo de ventas para la oficina donde el representante trabaja aumente segn la cuota del representante. A continuacin se muestra un disparador PUSQL de Grac1e que ejecuta este objetivo:
create trigger act_obj /~ Inserta el disparador para REPRESENTANTES */ before insert on representantes for each row when (new.cuota is not null) begin update oficinas set objetivo = objetivo + new.cuota;
end; La instruccin CREATE TRIGGER se usa en la mayora de marcas de SOBD que incorporan los disparadores para definir un nuevo disparador en la base de datos. Asigna un nombre al disparador (ACT_OBJ para ste) e identifica la tabla a la cual el disparador est asociado (REPRESENTANTES) y la accin o acciones de actuali-
De forma similar, al procedimiento externo XP_CM05HELL se le llama para pasar comandos al sistema operativo subyacente sobre el cual est operando SQL Server. Adems de estos procedimientos externos predefinidos, SQL Server permite almacenar un procedimiento externo escrito por el usuario en una biblioteca de
736
737
zacin sobre la tabla que producirn que se active el disparador (INSERT en este caso). El cuerpo de este disparador dice al SGBD que para cada nueva fila insertada en la tabla, se debera ejecutar la instruccin especificada UPDATE para la tabla OFICINAS. El valor CUOTA de la fila que se acaba de insertar en REPRESENTANTES se denomina NEW. CUOTA en el cuerpo del disparador.
Disparadores en TransactSQL
Transact-SQL proporciona disparadores mediante la instruccin CREATE TRIGGER en los dialectos SQL Server de Microsoft y Adaptive Server de Sybase. A continuaci6n se muestra la definicin de un disparador Transact-SQL para la base de datos ejemplo. que implementa la misma funcin de disparador que el ejemplo PU SQL, de Orac!e, precedente:
create trigger act_obj /. Inserta disparador para REPRESENTANTES */ on representantes for insert as if (QQrowcount ~ 1) begin update oficinas set objetivo ~ objetivo + inserted.cuota from oficinas, inserted where oficinas.oficina ~ inserted.oficina_rep;
end
Ventajas e inconvenientes de los disparadores

Los disparadores pueden ser extremadamente tiles como parle integral de la
definicin de una base de datos, y entre sus funciones podemos destacar las siguientes:
.1
Auditora de cambios. Un disparador puede detectar y prohibir actualizaciones especficas y cambios que no deberan estar permitidos en la base de datos. . Operaciones en cascada. Un disparador puede detectar una operaci6n enJIa base de datos (como el borrado de un cliente o representante) y automtfca~ mente desencadenar el impacto en la base de datos (como ajustar los balances contables o los objetivos de ventas). Aplicar relaciones. Un disparador puede aplicar relaciones ms complejas entre los datos en la base de datos que los que se pueden expresar co,n res~ tricciones sencillas de integridad o restricciones de comprobacin, como las que requiere una secuencia de instrucciones SQL o con IF...THEN...ELSE. Invocacin a procedimientos almacenados. Un disparador puede llamar a uno O ms procedimientos almacenados o incluso invocar acciones fuera del SGBD mediante llamadas a procedimientos externos en respuesta a actualizaciones de la base de datos.
En cada uno de estos casos, un disparador incorpora un conjunto de reglas de negocio que gobierna los datos en la base de datos y las modificaciones de dichos datos. Las reglas se insertan en una ubicacin sencilla en la base de datos (la definicin del disparador). Como consecuencia, se fuerzan uniformemente en todas las aplicaciones que acceden a la base de datos. Cuando se necesitan cambiar, s~ procede a ello tras asegurarse de que el cambio se aplicar unifor~ memente. La principal desventaja de los disparadores es su potencial impacto en el rendimiento. Si se establece un disparador sobre una tabla particular, entonces toda operacin de base de datos que intente actualizar la tabla hace que el SGBD ejecute el procedimiento disparador. Para una base de datos que requiera una inserci6n importante de datos o grandes factores de actualizaci6n, la sobrecarga de este procesamiento puede ser considerable. Esto es especialmente cierto para operaciones de carga masiva, donde los datos se pueden ya haber precomprobado en su integridad. Para tratar este inconveniente, algunas marcas de SGBD permiten habilitar y deshabilitar selectivamente los disparadores, segn sea apropiado. .
else raiserror 23456
1,
La primera clusula da nombre al disparador (ACT_OBJ). Se requiere la segunda clusula, que identifica la tabla a la cual se aplica el disparador. La tercera clusula tambin es necesaria y dice qu operaciones de la base de datos hacen que se active el disparador. En este caso solamente la instruccin INSERT da lugar a esta activacin. Tambin se pueden especificar las operaciones UPDATE o DELETE, o una combinacin de dos o tres de estas operaciones en una lista separada por comas. Transact-SQL restringe los disparadores de forma que slo se puede definir un disparador sobre una tabla determinada para cada una de las tres operaciones de modificacin. Al cuerpo del disparador le sigue la palabra clave AS. Para comprender el cuerpo del disparador, se necesita entender cmo Transact-SQL trata las filas en la tabla objetivo durante las operaciones de modificacin de la base de datos. Para la operacin del disparador, Transact-SQL define dos tablas lgicas cuya estructura de columnas es idntica a la tabla objetivo sobre la cual se define el disparador. Una de estas tablas 16gicas se denomina DELETED y la otra se denomina INSERTED. Estas tablas lgicas se rellenan con filas de la tabla objetivo, depen~ diendo de la instruccin de modificacin de los datos que hace que se active el disparador:
DELETE. Cada LETE se ubica INSERT. Cada
SERT
fila de la tabla objetivo que se elimina con la instruccin DEen .la tabla DELETED. La tabla INSERTED permanece vaca. fila de la tabla objetivo que se agrega con la instruccin INtambin se ubica en la tabla INSERTED. La tabla DELETED permanece Por cada fila de la tabla objetivo que se cambia con la instruccin se ubica una copia de la fila antes de las modificaciones en la tabla
vaca.
UPDATE. UPDATE,
738

DELETED.
739
Una copia de la fila se ubica en la tabla INSERTED despus de todas las modificaciones.
Disparadores en SPL de Informix

GGER. Como en TRIGGER define
Se puede hacer referencia a estas dos tablas lgicas en el cuerpo del disparador. y los datos se pueden combinar con los datos de otras tablas durante la ,operacin del disparador. En este disparador de Transact-SQL, el cuerpo del dIsparador confirma en primer lugar que solamente se ha insertado una nica fila en la tabla REPRESENTANTES, mediante la comprobacin de la variable del sistema @@ROWCOUNT. Si esto es cierto, se agrega en la columna CUOTA de la tabla lgica INSERTED la fila apropiada de la tabla OFICINAS. La fila apropiada se determina combinando la tabla lgica a la tabla OFICINAS segn los nmeros de oficina coincidentes. A conlinuacin se muestra un disparador dislinlO que detecta un tipo distinto de problema de integridad de datos. En este caso comprueba un intento de borrar un cliente que todava tiene pedidos pendientes en la base de datos. Si se detecta esta situacin, el disparador deshace automticamente toda la transaccin, inclu) yendo la instruccin DELETE que activ dicho disparador:
crea te trigger comp_eli_cliente (* Borra el disparador para CLIENTES *J on clientes for delete as J* Detecta cualquier pedido para el nmero de cliente eliminado *J if (select count(*) from pedidos, deleted where pedidos. cliente deleted.num_cli) > O begin rollback transaction print ~No se puede eliminar, an tiene pedidos raiserror 31234 end
Informix tambin incorpora los disparadores mediante la instruccin CREATE TRIel dialecto Transact-SQL, el comienzo de la instruccin CREATE el nombre del disparador, la tabla sobre la cual se define el disparador y las acciones de la activacin. A continuacin se muestran fragmentos de una instruccin que ilustran la sintaxis:
crea te trigger nuevo_rep insert on representantes create trigger comp_eli_cliente delete on clientes crea te trigger act_ped update on pedidos . create trigger act_rep update of cuota, ventas on representantes
El ltimo ejemplo es un disparador que se activa solamente cuando se actualizan dos columnas especficas de la tabla REPRESENTANTES. Informix permite especificar que un disparador debera operar tres veces distintas durante el procesamiento de un cambio activado en una tabla objetivo:
BEFORE.
El disparador se activa antes de que tenga lugar cualquier cambio. Todava no se ha modificado ninguna fila de la tabla objetivo. AFTER. El disparador se activa despus de que tengan lugar todos los cambios. Se han modificado las filas afectadas de la tabla objetivo. FOR EACH RON. El disparador se activa repetidamente, una vez en cada ocasin que una fila es afectada por un cambio. Los valores antiguos y nuevos de ia fila estn disponibles para el disparador.
Se puede especificar que los disparadores Transact-SQL se activen por cada UPDATE de la tabla objetivo, o solamente en las actualizaciones de las columnas seleccionadas. El siguiente disparador se activa con las inserciones o actualizaciones de la tabla REPRESENTANTES y realiza un procesamiento distinto dependiendo de si se ha actualizado la columna CUOTA o VENTAS:
crea te trigger upd_reps J* Actualiza el disparador para REPRESENTANTES */ on representantes for insert, update if update(cuota) /* Gestiona las actualizaciones de la columna cuota *J if update (ventas) /~ Gestiona las actualizaciones de la columna ventas */
La definicin de un disparador individual puede especificar acciones que han de adoptarse en uno o ms de estos pasos. Por ejemplo, un disparador podra ejecutar un procedimiento almacenado para calcular la suma de todos los pedidos antes de (BEFDRE) una actualizacin, supervisar las actualizaciones de de cada fila de PEDIDOS cada vez que ocurren con una segunda accin y despus calcular el total de pedidos revisado despus de (AFTER) la actualizacin con una ~larnada a otro procedimiento almacenado. A continuacin se muestra la definicin de un disparador que realiza todo esto:
create trigger act_ped update of importe on pedidos referencing old as pre new as post
/~ Calcula el total de los pedidos antes de los cambios before (execute procedure agregar_pedidos() into total_anterior;) ~/
740
741
/* Captura aumentos Y disminuciones en el pedido for each row when (post. importe < pre.importe) 1* Escribe las disminuciones en la tabla */ (iosert into ped_dis values (pre.cliente. pre.fecha_pedido,
*'
En la prctica, la ltima opcin proporciona algo de flexibilidad. El procedimiento llamado puede ejecutar casi cualquier procesamiento que pudiera realizarse en el cuerpo del disparador.
when
pre. importe. post. importe) ;) (post. importe > pre.importel
Disparadores en PL/SQL de Oraele

Oracle proporciona una capacidad de disparadores ms compleja que lnformix o Transact-SQL, descritas en las secciones anteriores. Utiliza la instruccin CREATE TRIGGER para especificar las acciones disparadas. Como en Informix, se puede especificar un disparador para activarlo en ciertas ocasiones durante operaciones de actualizacin especficas: Disparador para instrucciones. Un disparador para instrucciones se activa una vez por cada instruccin de modificacin de datos. Se puede especificar para activarse antes de que se ejecute la instruccin o despus de que la instruccin haya completado su accin. Disparador para filas. Un disparador para filas se activa una vez para por cada fila que es modificada por una instruccin. En la estructura Oracle este tipo de disparador tambin se activa antes de que se modifique la fila o despus de modificarse. Disparador en lugar de. Un disparador en lugar de toma el lugar de una instruccin de un intento de modificacin de datos. Proporciona una forma de detectar el intento de una operacin UPDATE, INSERT o DELETE mediante un usuario o procedimiento y la sustituye por otro procesamiento. Se puede especificar que un disparador se tiene que ejecutar en lugar de una instruccin, o que se debera ejecutar en lugar de cada modificacin intentada de una fila.
crea te trigger antes_act-ped befare update on pedidos begin /* Calcula el total de los pedidos antes de los cambios */ total_anterior: agregar-pedidos(); end; create trigger despues_act-ped after update on pedidos begin /* Calcula el total de los pedidos despus de los cambios */ nuevo_total: agregar_pedidos{); end; crea te trigger dur_act-ped befare update of importe on pedidos referencing old as pre new as post
/* Captura los aumentos y disminuciones de los pedidos */ fer each rew when (post.importe !: pre.importel begin
/* Escribe los aumentos en la tabla */
{iosert into ped_aum values (pre.cliente, pre.fecha_pedido, pre. importe, post. importe);)
/* Despus de los cambios, recalcula el total */ after (execute procedure agregar-pedidos() into nuevo_total;)
La clusula
BEFORE
en este disparador especifica que se va a

AGREGAR_PEDIDOS
procedimiento almacenado denominado
antes de que ocurra
Ilama~ un
cualquier procesamiento de la instruccin UPDATE. Presumiblemente, este procedimiento calcula los pedidos totales y devuelve el valor total en la variable local TOTAL_ANTERIOR. De igual forma, la clusula AFTER especifica que se va a llamar a un procedimiento almacenado (en este caso, el mismo) despus de que se complete el procesamiento de la instruccin UPDATE. Esta vez, la cantidad total de pedidos se ubica en una variable local distinta, NUEVO_TOTAL. La clusula FOR EACH ROW especifica la accin a adoptar cada vez que se actualiza cada fila. En este caso la accin solicitada es un INSERT en una de las dos tablas de seguimiento de pedidos, segn aumente o disminuya la cantidad del pedido. Estas tablas de seguimiento contienen el nmero de cliente, la fecha y los importes antiguo y nuevo del pedido. Para obtener los valores requeridos, el disparador debe poder referirse a los valores anterior (antes del cambio) y nuevo (despus del cambio) de cada fila. La clusula REFERENCING proporciona nombres mediante los cuales se pueden usar estos dos estados de la fila actualizada de la tabla PEDIDOS. En este ejemplo, los valores anteriores al cambio de las columnas estn disponibles mediante el calificador del nombre de columna PRE, y los valores posteriores al cambio, mediante el calificador del nombre de columna POST. No son nombres especiales; se puede utilizar cualquier nombre. Informix est ms limitado que algunas otras marcas de SGBD en las acciones que se pueden especificar en la definicin del disparador. Estn disponibles las siguientes acciones: Una instruccin Una instruccin Un~ instruccin Una instruccin
INSERT. DELETE. UPDATE. EXECUTE PROCEDURE.
'-
742

pre.importel
743
if (post. importe
then
<
1* Escribe los datos que disminuyen en la tabla */ insert into ped_dis values (pre.cliente, pre.fecha-pedido, pre.imporce,
post. importe) ;
elsif (post. importe > pre.importe)

then
/* escribe los datos que aumentan en la tabla */
si se permite el procesamiento de disparadores en cascada. Finalmente, algunos proporcionan un lmite en el nmero de niveles de disparadores anidados que se pueden activar. Un tema adicional asociado con los disparadores es la carga que puede resultar durante un uso muy grande de la base de datos, como cuando se cargan datos de forma masiva en una base de datos. Algunas marcas de SGBD proporcionan la capacidad de habilitar y deshabilitar selectivamente el procesamiento de disparadores para gestionar esta situacin. Oracle, por ejemplo, proporciona esta forma de la instruccin ALTER TRIGGER:
ALTER TRIGGER ANTES_ACT_PED DISABLE;
insert into ped_aum

values (pre.cliente, pre.fecha_pedido, pre.importe,
post. importe);
end if;
'1
Se proporciona una capacidad similar con la instruccin Informix.
CREATE TRIGGER
de
end;
Estas estructuras de disparador y sus opciones proporcionan 14 tipos vlidos) de disparadores Orade (12 resultantes de la eleccin de disparadores INSERT/ DELETE/UPDATE para BEFORE o AFTER para filas o instrucciones (3x2x2) y dos ms para los disparadores en lugar de para las instrucciones o filas. En la prctica, las bases de datos relacionales que utilizan Oracle no tienden a utilizar los disparadores en lugar de; se introdujeron en Oracle8 para incorporar algunas nuevas caractersticas orientadas a objetos. El cdigo que se acaba de mostrar es una definicin de disparador PUSQL que implementa el mismo procesamiento que en el complejo ejemplo Informix de la seccin anterior. Se ha dividido en tres instrucciones CREATE TRIGGER Orade separadas; una por cada disparador en el nivel de instrucciones BEFQRE y AFTER, Y un disparador que se ejecuta por cada actualizacin de fila.
Procedimientos almacenados, disparadores y el estndar SOL

El desarrollo de los procedimientos almacenados y los disparadores en los SGBD ha sido dirigido fundamentalmente por fabricantes de SGBD y por la competitiva dinmica de la industria de bases de datos. La introduccin inicial de Sybase de los procedimientos almacenados y disparadores en SQL Server produjo una respuesta competitiva y, a mediados de los aos noventa, muchos de los sistemas empresariales haban agregado sus propias extensiones procedimentales propias a SQL. Los procedimientos almacenados no eran centro de atencin del estndar SQL2, pero formaron parte de la agenda de estandarizacin despus de la publicacin en 1992 del estndar SQL2. El trabajo sobre estndares de procedimientos almacenados se deriv de las extensiones orientadas a objetos que fueron propuestas por SQL3, y se centr en un conjunto de extensiones procedimentales al lenguaje SQL2, El resultado fue una nueva parte del estndar SQL, publicado en 1996 como el estndar internacional ISO/lEC 9075-4, denominado SQUPersistent Stored Modules (SQUPSM). La forma real de la especificacin del estndar es una coleccin de aadidos, ediciones, nuevos prrafos y reemplazo de prrafos del estndar SQL2 de 1992 (ISO/lEC 9075:1992). Adems de ser una modificacin del estndar SQL2, SQUPSM fue tambin un boceto de una parte del estndar futuro planificado, que se llam SQL3 durante el desarrollo de su boceto. El desarrollo del estndar supuso ms tiempo de lo esperado, pero SQLIPSM finalmente sali como Parte 4 del estndar SQL3, oficialmente conocido como SQL: 1999. El estndar SQL Call-Levellnteiface (CLI), descrito en el Captulo 19, se trat de la misma forma; ahora es la Parte 3 del estndar SQL: 1999. Cuando se public el estndar SQL:1999, se trasladaron partes seleccionadas de SQUPSM al ncleo de SQUFoundation specification (Part 1), puesto que tambin es usado por otras partes del estndar. El estndar SQUPSM publicado en 1996 solamente describa procedimientos almacenados; no proporcion explcitamente una especificacin de los disparado-
Otras consideraciones sobre los disparadores

Los disparadores plantean algunos de los mismos aspectos del procesamiento en los SGBD que presentan las reglas UPDATE y DELETE. Por ejemplo, los disparadores pueden producir una serie de acciones en cascada. El intento de un usuario de actualizar una tabla puede producir que se active un disparador. En el cuerpo del disparador hay una instruccin UPDATE para otra tabla. Un disparador en esta tabla produce UPDATE de otra tabla, y as sucesivamente. La situacin es incluso peor si uno de los disparadores activado intenta actualizar la tabla objetivo inicial que produjo la activacin de la secuencia del disparador en primer lugar! En este caso se podra producir un bucle infinito de disparadores activados. Algunos sistemas SGBD tratan de resolver este tema de distintas formas. Algunos imponen restricciones sobre las acciones que se pueden adoptar durante la ejecucin de un disparador. Otros proporcionan funciones incorporadas que permiten al c~erpo del disparador detectar el nivel de anidamiento en el que est operando el disparador. Algunos proporcionan un parmetro del s~stema que controla
744
745
res para el estndar SQL de ISO. Se consider la estandarizacin de disparadores durante el desarrollo de los estndares SQL2 y SQLlPSM, pero los grupos de estndares determinaron que los disparadores estaban demasiado vinculados a otras extensiones orientadas a objetivos propuestas por SQL3. El estndar SQL: 1999 que result del trabajo SQL3 proporcion finalmente una capacidad ANSIIISO estndar para los disparadores. La publicacin de los estndares SQUPSM y SQL: 1999 retrasaron en muchos aos la primera implementacin comercial de los procedimientos almacenados y disparadores. Cuando se adopt el estndar, la mayora de los fabricantes de SOBO haban respondido al entusiasmo de los usuarios y a la presin competitiva introduciendo los procedimientos almacenados y los disparadores en sus productos. A diferencia de algunas extensiones de SQL en las que la implementacin DB2 de IBM impuso el estndar de facto, la mayora de fabricantes de SGBD implement procedimientos almacenados y disparadores de distintas formas y, en algunos casos, compitieron entre s en trminos de las caractersticas nicas de sus implementaciones. Como consecuencia, la estandarizacin ANSIJISO de los procedimientos) almacenados y disparadores ha tenido hasta ahora poco impacto en el mercado de los SGBD. Es razonable esperar que las implementaciones ANSI/ISO encontrarn, con el tiempo, su camino en la mayora de los productos SGBD, pero como complemento a las implementaciones propietarias, ms que como remplazo de stas.
aceptan parmetros pasados mediante la instruccin CALL. Los procedimient6s al. macenados SQUPSM tambin pueden devolver datos mediante los parmetros de salida, de nuevo como en los lenguajes de procedimientos almacenados propietarios. SQUPSM tambin alberga parmetros combinados de entrada/salida, como algunos de los lenguajes propietarios. Una funcin SQL devuelve un valor. Se llama de igual forma que una funcin SQL incorporada en una expresin:
SELECT EMPRESA PROM CLIENTES WHERE OBTENER_TOT_PEDIDOS(NUM_CLI)
> 10000.00
SQUPSM restringe las funciones SQL de forma que solamente devuelven un nico valor por el mecanismo de llamada a la funcin. En las funciones SQL no se permiten los parmetros de salida y de entrada/salida. Las rutinas SQL son objetos en la estructura de la base de datos SQL-92 O SQL-99. SQLlPSM pennite la creacin de rutinas en un esquema SQL-92 o SQL99 (una rutina en un nivel de esquema), donde existe junto con tablas, vistas, aser tos y otros objetos en el esquema. Tambin permite la creacin de rutinas en un mdulo SQL2, que es el modelo de procedimientos de SQL que se desarroll a partir del estndar SQLI.
Creacin de una rutina SOL
El estndar de los procedimientos almacenados SQL/PSM

Las capacidades especificadas en el estndar SQL/PSM reflejan las caractersticas principales de las capacidades de los procedimientos almacenados propietarios de los sistemas SGBD actuales. Incluyen construcciones del lenguaje SQL para:
'1
I
,1
Definir y dar nombre a procedimientos y funciones escritos en el lenguaje SQL extendido. . Invocar (llamar) un procedimiento o funcin previamente definido. Pasar parmetros a un procedimiento o funcin invocada y obtener los resultados de su ejecucin. Declarar y utilizar variables locales en el procedimiento o funcin. Agrupar un bloque de instrucciones SQL para su ejecucin. Ejecutar condicionalmente instrucciones SQL (IF ... THEN ... ELSE). Ejecutar repetidamente un grupo de instrucciones SQL (bucles). El estndar SQUPSM especifica dostipos de rutinas SQL. Un procedimiento SQL es una rutina que no devuelve un valor. Se llama con una instruccin CALL:
CALL AGREGAR_CLIENTE{'Empresa XY"Z' , 'Cast.elln' I 2137, 30000.00, 50000.00, 103,
Siguiendo la prctica de la mayora de marcas de SGBD, el estndar SQUPSM utiliza las instrucciones CREATE PROCEDURE y CREATE FUNCTION para especificar las definiciones de procedimientos almacenados y funciones. La Figura 20.18 muestra la sintaxis simplificada para cada una de estas instrucciones. Adems de las capacidades mostradas en la figura, el estndar proporciona la capacidad de defi'nir procedimientos almacenados externos, especificando el lenguaje en el que estn escritos, si pueden o no leer o modificar los datos en la base de datos, los convenios de llamada y otras caractersticas.
Instrucciones de control de flujo
Como .con los lenguajes de procedimientos almacenados ilustrados en los ejemplos anteriores en todo este captulo, los procedimientos almacenados SQL!PSM
El estndar SQUPSM especifica las estructuras de programacin comunes que se encuentran en la mayora de los dialectos de procedimientos almacenados para controlar el flujo de la ejecucin. La Figura 20.19 muestra la sintaxis de la bifurcacin condicional y los bucles. Ntese que las listas de instrucciones SQL especificadas para cada estructura consisten en una secuencia de instrucciones SQL, cada una de las cuales acaba en un punto y coma. Por ello, no se requieren estructuras de bloques explcitas para las secuencias sencillas de varias instrucciones que apa recen en una instruccin IF ... THEN ... ELSE o una instruccin LOOP. Las estructuras de bucle proporcionan mucha flexibilidad para el procesamiento de bucles. Hay formas que ubican la comprobacin al comienzo del bucle, y otras al final del bucle, as como una forma que proporciona un bucle infinito y requiere una codi
'-
746
Captulo 20: Procesamiento de bases de datos y procedmiemos...
747
1-- CREATE
-,-
PROCEDURE
nomb'Cp'0c
FUNCTION
Ejecucin condicional:
1-- IF condicinde-bsqueda T H E N T
instruccin;
ELSEIF condicinde-bsqueda THEN
instruccin;
ELSEIF
RETIJRNS
instruccin;
tipo-datos-devuelto
SPECIFIC nombre-especfico
)
END IF
I
1
' - - - instrucc;n-SQL-o-instruccin-compuesta -----------_~

Iteracin:
Figura 20.18.
CREATE PROCEDURE
de SQlIPSM.
fr
LOOP
LetiQUera . ..J
L ;n","~;n;-.
_
..J
END LOOP
-r.
L etIqueta:
J----+
L etiqueta:J
ficaci6n explcita de un test para salir de la ejecucin del bucle. Cada una de las estructuras de control del programa termina explcitamente en un indicador-ENO que se corresponde con el tipo de estructura. haciendo ms sencilla la depuracin del programa.
te. J
etIqueta:
WHITE condicin-de bsqueda DO instruccin;
END WRITE'-------::+_
Operaciones con cursores

El estndar SQL/PSM extiende las capacidades de manipulacin de cursores especificado en el estndar SQL2 con rutinas SQL incorporadas en rutinas SQL. Las instrucciones DECLARE CURSOR. OPEN, FETCH Y CLQSE conservan sus funciones. En lugar de utilizar las variables del anfitrin de la aplicacin para proporcionar valores de los parmetros y recibir los datos recuperados, se pueden utilizar los parmetros y variables de la rutina SQL para estas funciones. El estndar SQLlPSM introduce una nueva estructura de bucle controlada por cursor, la cual se muestra en la Figura 20.20. Al igual que las estructuras similares de los dialectos Oracle e Informix descritas en la seccin Repeticin con cursores de este captulo, combina la definicin del cursor y las instrucciones OPEN, FETCH Y CLOSE en una nica definicin de bucle que tambin especifica ~l procesamiento a ejecutar por cada fila de los resultados recuperados de la consulta.
~[.
REPEAT
instruccin
;y
UNTIL condicin-de-bsqueda
EN[)
REPEAT [ .
etlquete :
etIqueta:
Figura 20.19.
Diagrama sintctico de las instrucciones de control de flujo SQl/PSM.
Estructura de los bloques
La Figura 20.21 muestra la estructura de los bloques especificada por el estndar SQUPSM. Es una estructura bastante fcil de entender que proporciona las siguientes capacidades: Etiqueta el bloque de instrucciones con una etiqueta de instruccin. Declara variables locales para su uso en el bloque. Declara condiciones locales de error definidas por el usuario_
748
749
L.
I1r,queta:
FOR "'a,iabllHf~l-bucle AS
~
J
especificacin-de-
BEGIN
L l
NOT
ATOMIC..J
nombrcdel-
cursor
L
INSENSITlVE
yCURSOR FOR
~o'"",
d"""'60d',,,;,.,, declarllCin-dft<Ondicin _
;
;
=J
-.J
-.J
declaracin-de-eursor _ _ ;
00
;nsrrvcr:in;
END FOR
-L.
et,queta:
.~
declaracin-de-eontrolador-;
Figura 20.20.
Diagrama sintctico de flujo controlado por cursor SQl/PSM.
instruccin
END
;~
etiqueta:
Declara cursores para la ejecucin de consultas en el bloque. Declara controladores para procesar las condiciones de error que tienen lugar. Define la secuencia de instrucciones SQL que se han de ejecutar. Estas capacidades recuerdan algunas de las descritas anteriormente en la seccin Bloques de instrucciones de este captulo para los dialectos de los procedimientos almacenados de Inforrnix y Grade. Las variables locales en los procedimientos y funciones SQUPSM (realmente en bloques de instrucciones) se declaran mediante el uso de la instruccin DECLARE. Los valores se asignan mediante el uso de la instruccin SET. Las funciones devuelven un valor mediante el uso de la instruccin RETURN. A continuacin se muestra un bloque de instrucciones que puede aparecer en una funcin almacenada, con ejemplos de estas instrucciones:
try_again: begin 1- Declara algunas variables locales +1 declare texto_mensaje varchar(40); declare imp_tot decimal(lG.2):
/* Obtiene el total de los pedidos */
J
valor LOEFAULT predeterminado
Declaracin de variable:
- - - - DECLARE .......---
nombre-de. variable ---r-tIPo-de-datos-r
L.- , ~
Declaracin de condicin:
DECLARE nombre-de-condicin CONDITION ~L
:r-
,I
I
JPOR SQLSTATE va/or-sq/sfate
Figura 20.21.
Diagrama sintctico del bloque de instrucciones SOl/PSM.
11
Gestin de errores
La estructura de bloques especificada por el estndar SQL/PSM proporciona un soporte bastante fcil de entender para la gestin de errores. El estndar especifica condiciones predefinidas que se pueden detectar y gestionar:
SQLWARNING.
set imp_tot obtener_tot-pedidos(l: if (imp_tot > O) then return (imp_tot): el se return (O.OOl: end if end try_again
Una de las condiciones de aviso especificada en el estndar
SQL2.
NOT FaUNO.
Condicin que normalmente sucede cuando se alcanza el final de un conjunto de una consulta con una instruccin FETCH.
750

begin ,. Se arregla el desastre ., end;
751
Valores SQLSTATE. Un test para cdigos de error especficos SQLSTATE. Condiciones definidas por el usuario. Una condicin nombrada por el procedimiento almacenado. Las condiciones se definen normalmente en trminos de valores SQLSTATE. En lugar de utilizar cdigos SQLSTATE numricos se puede asignar un nombre simblico a la condicin. Se puede tambin especificar una condicin definida por el usuario:
declare err_mal condition for sqlstate '12345', declare mi_err eondition;
La gestin de errores puede llegar a ser bastante compleja, y es posible que ocurran errores durante la ejecucin de la propia rutina del controlador. Para evitar la repeticin infinita en los errores, no se aplica la seal normal de errores durante la ejecucin de un controlador de condiciones. El estndar permite omitir esta restriccin con la instruccin RE5IGNAL. Opera de igual forma que la instruccin SIGNAL, pero se utiliza exclusivamente con rutinas de controladores de condiciones.
Una vez que se ha definido la condicin, se puede forzar que ocurra la condi cin mediante la ejecucin de una rutina SQL con la instruccin SIGNAL:
signal err_mal;
Sobrecarga de rutinas
El estndar SQUPSM permite la sobrecarga de nombres de procedimientos y funciones almacenadas. La sobrecarga es un atributo comn en sistemas orientados a objetos y es una forma de hacer que las rutinas almacenadas sean ms flexibles para gestionar una amplia variedad de tipos de datos y situaciones. Mediante el uso de la sobrecarga se puede dar el mismo nombre a rutinas diferentes. Las diferentes rutinas definidas con el mismo nombre se deben diferenciar en el nmero de parmetros que aceptan o en los tipos de datos de los parmetros. Por ejemplo, se pueden definir estas tres funciones almacenadas:
crea te function combo la, a integer; b integer; returns integer; as return (a+b) bl
signal sqlstate '12345';
Para gestionar las condiciones de error que pueden ocurrir, SQUPSM permite declarar un controlador de condiciones. La declaracin especifica la lista de condiciones que se van a gestionar y la accin que se ha de adoptar. Tambin especifica el tipo de gestin de la condicin. Los tipos se diferencian en lo que sucede al flujo de control despus de que el gestor termine con su t~rea: Tipo CONTrNUE. Despus de que el controlador de condiciones finalice su trabajo, se devuelve el control a la siguiente instruccin que sigue a la que ha provocado la condicin. Esto es, la ejecucin contina con la siguiente instruccin. Tipo ExrT. Despus de que el controlador de condiciones finalice su trabajo, se devuelve el control al final del bloque de instrucciones que contiene la instruccin que ha provocado la condicin. Esto es, la ejecucin finaliza el bloque. Tipo ONDO. Despus de que el controlador de condiciones finalice su trabajo, se deshacen todas las modificaciones de los datos en la base de datos provocadas por las instrucciones en el mismo bloque de instrucciones que la instruccin que provoc el error. El efecto es el mismo que si la transaccin se hubiera iniciado al comienzo del bloque de instrucciones y se hubiera retrocedido'A continuacin se muestran algunos ejemplos que ilustran la definicin de la estructura del gestor:
,. Gestiona los avisos SQL y despus contina ., declare continue handler for sqlwarning call mi_rutina_avisol); , . Gestiona errores severos deshaciendo los efectos . , declare undo handler for user_disaster
crea te function combo(a, b, a integer; b integer; c integer; returns integer; as return (a+b+c) create procedure combo{a, a varchar(255}; b varchar(255}; returns varchar(255}; as return la 1I bl bl
el
La primera funcin COMBO combina dos enteros y devuelve la suma. La segunda funcin COMBO combina tres enteros de la misma forma. La tercera funcin COMBO combina dos cadenas de caracteres y las concatena. El estndar permite definir estas funciones COMBO al mismo tiempo en la base de datos. Cuando el SGBD encuentra una referencia a la funcin COMBO, examina el nmero de argumentos en la referencia y sus tipos de datos, y determina a qu versin de la funcin COMBO llamar. La capacidad de sobrecarga permite a un programador SQL
752
753
crear una familia de rutinas que ejecutan la misma funcin lgica y tienen el mismo nombre, incluso si se especifica su uso para distintos tipos de datos. En trminos del lenguaje orientado a objetos, la sobrecarga se denomina algunas veces polimorfismo. Jo que significa literalmente que la misma funcin puede adoptar muchas formas distintas. Para simplificar la gestin de una familia de rutinas que comparten un nombre sobrecargado, el estndar SQUPSM tiene el concepto de un nombre especfico: un segundo nombre que se asigna a la rutina que es nico en el esquema de la base de datos o mdulo. Identifica de forma nica una rutina especfica. El nombre especfico se utiliza para borrar ]a rutina y se refleja en las vistas del esquema de la informacin que describen las rutinas almacenadas. El nombre especfico no se utiliza para llamar a la rutina; esto evitara el propsito principal del nombre de la rutina sobrecargada. Incorporar nombres especficos o algn mecanismo similar es un requisito prctico para cualquier sistema que permite la sobrecarga o el polimorfismo para los objetos y proporciona la capacidad de gestionarlos mediante la eliminacin o el cambio de sus definiciones, puesto que el sistema debe poder determinar qu objeto especfico se va a modificar. )
Procedimientos almacenados externos
La mayor parte del estndar SQUPSM se refiere a las extensiones al lenguaje SQL que se utilizan para definir procedimientos SQL y funciones SQL. Ntese, sin embargo, que el mtodo utilizado para invocar a un procedimiento SQL (la instruccin CALL) o una funcin SQL (una referencia a la funcin mediante el nombre en una instruccin SQL) no son especficos de los procedimientos definidos en el lenguaje SQL. En realidad, el estndar SQUPSM proporciona procedimientos almacenados externos y funciones, escritos en algn otro lenguaje de programacin, como e o PascaL Para los procedimientos externos las instrucciones CREATE PROCEDURE y CREATE FUNCTION todava se utilizan para definir el procedimiento en el SGBD, especificando su nombre y parmetros que acepta o devuelve. Una clusula especial de la instruccin CREATE especifica el lenguaje en el que est escrito el procedimiento almacenado o funcin, de forma que el SOBn puede ejecutar la conversin apropiada de los tipos de datos y llamar a la rutina de forma apropiada.
Otras capacidades de los procedimientos almacenados
Debido a que las rutinas almacenadas definidas por SQUPSM se describen con los esquemas SQL2, muchas rutinas se pueden definir en muchos esquemas distintos en toda la base de datos. Cuando se llama a una rutina almacenada, el nombre de la rutina se puede calificar completamente para definir de forma nica la rutina en la base de datos. El estndar SQL/PSM proporciona un mtodo alternativo de bsqueda de la definicin de nombres de rutinas sin calificar mediante un nuevo concepto PATH. PATH es la secuencia de nombres de esquema que se deberan buscar para resolver una referencia a una rutina. Un PATH predeterminado se puede especificar como parLe de la cabecera del esquema en la instruccin CREATE SCHEMA. PATH tambin se puede modificar dinmicamente durante una sesin SQL mediante la instruccin SET PATH. El estndar SQUPSM tambin permite al autor de un procedimiento o funcin almacenada dar al SOBO algunos consejos sobre su operacin con el fin de mejorar la eficiencia de su ejecucin. Un ejemplo es la posibilidad de definir una rutina almacenada como DETERMINISTIC o NOT DETERMINISTIC. Una rutina DETERMINISTIC, siempre devolver los mismos resultados cuando se acoja a los mismos valores de parmetros. Si el SOBD observa que se llama repetidamente a una rutina DETERMINISTIC, puede elegir guardar una copia de los resultados que devuelve. Posteriormente, cuando se llame de nuevo a la rutina del SOBO no tiene que ejecutar realmente la rutina, sino simplemente devolver los mismos resultados que los devueltos la ltima vez. Otra forma de indicacin dice al SOBD si un procedimiento o funcin almacenada externa lee los contenidos de la base de datos y si modifica los contenidos de la misma. Esto no solamente permite al SOBD optimizar el acceso a la base de datos, sino que tambin puede imponer una restriccin de seguridad sobre rutinas externas de otros orgenes. Otras indicaciones determinan si se debe llamar a una funcin SQL si uno de sus parmetros tiene un valor NULL, y controlan cmo el SOBD selecciona una funcin o procedimiento especfico a ejecutar cuando se utiliza la sobrecarga.
Estndares de disparadores en SQL:1999

Los disparadores se tuvieron en cuenta para su estandarizacin como parte de SQL3, que dio lugar a l final publicacin del estndar ANSIIISO SQL:1999. Por esas fechas, muchos productos comerciales de SGBD ya haban implementado los disparadores y el estndar sintetiz las capacidades especficas que se haban mostrado tiles en la prctica. Al igual que los productos comerciales, los disparadores estndar ANSIflSO se definen para una nica tabla especfica. El estndar permite definiciones de disparadores solamente sobre tablas, no sobre las vistas. Los mecanismos propietarios de disparadores de SQL Server, Oracle e 1nformix mostrados en los ejemplos de este captulo proporcionan un contexto para examinar el mecanismo estndar ANSIIISO. El estndar no proporciona una separacin radical de las capacidades ya descritas para los diversos pro-
El estndar SQUPSM trata los procedimientos SQL y las funciones SQL como objetos gestionados en la base de datos, utilizando extensiones a las instrucciones SQL utilizadas para gestionar otros objetos. Se utiliza una variante de la instruccin DROP para borrar rutinas que no son necesarias, y una variante de la instruccin ALTER para cambiar la definicin de una funcin o procedimiento. El mecanismo de permisos SQL2 se extiende de forma similar con privilegios adicionales. El privilegio EXECUTE proporciona a un usuario la posibilidad de ejecutar un procedimiento almacenado o funcin. Se gestiona mediante las ,instrucciones GRANT y REVOKE de la misma forma que otros privilegios de la base de datos.
""'--
754
Captulo 20: Procesamiento de bases de datos y procedimentos...
755
ductos de SGRD. A continuacin se muestra cmo se relaciona el estndar con ellos: Nombres. El estndar trata a los disparadores como objetos con nombre en la base de dalos. Tipos. El estndar proporciona los disparadores INSERT, DELETE y UPDATE; los disparadores UPDATE se pueden asociar con la actualizacin de una columna o grupos de columnas especficas. Temporizacin. El estndar proporciona los disparadores que operan ames o despus de una instruccin de actualizacin de la base de datos. Operacin en el nivel de las filas o de las instrucciones. El estndar proporciona disparadores en el nivel de las instrucciones (se ejecutan una vez por cada instruccin de actualizacin de la base de datos) y disparadores en el nivel de las filas (se ejecutan repetidamente para cada fila de la tabla que se modifica). Alias. Se proporciona acceso a los valores antes y despus en una fila o tabla modificada mediante un mecanismo de alias, como los alias de tbla utilizados en la clusula FROM. / Para definir un disparador se utiliza la instruccin CREATE TRIGGER de SQL:1999, mostrada en la Figura 20.22. Las clusulas de la instruccin resultan familiares a partir de los ejemplos de disparadores de las primeras secciones de este captulo. Una extensin muy til, proporcionada por el estndar, es la clusula WHEN que se puede especificar como parte de una accin disparada. La clusula WHEN es opcional y opera como una clusula WHERE para determinar si se llevar a cabo una accin disparada_ Cuando el SGBD ejecuta un tipo particular de instruccin especificada en la definicin del disparador, evala la condicin de bsqueda especificada en la clusula WHEN. La forma de la condicin de bsqueda es exactamente igual a la condicin de bsqueda en la clusula WHERE y producir un resultado TRUE o FALSE. La accin disparada se lleva a cabo solamente si el resultado es TRUE. Para proporcionar seguridad a los disparadores, el estndar SQL:1999 establece un nuevo privilegio TRIGGER que se puede conceder en tablas especficas a usuarios especficos. Con este privilegio un usuario puede establecer un disparador en la tabla. El propietario de la tabla siempre tiene el permiso de establecer disparadores en la tabla.
I
r- CREATE TRIGGER
nombre-dedisparador
AFTER DELETE BEFORE1INSERT':======3C-l UPDATE nombre-deUPDATE OF

~u~n8
ONnombre-de-tab/s - - - - - - - - - - - - - - - - - - - - - - - -
REFERENCING
1
OLD
NE\'
OLD TABLE
NEW TABLE
LAS-.l LAS-.l
alias-de-tabla-antes-de-cambios aliasde-tabJadespu8s-de-cambios alias-detabJa-antas-de-cambios
L J L
AS
LAS-.l L ROW-.l
alias-de-tabla-despus-de-csmbios
ROW
FOR EAeH
,-----..,.-,----------;r------.j
WHEN ( condicin-debusqueda J
inslrucci6nSOL-------------------,,----+
BEGIN
ATOMIC ~ccn-SOL
END-.Jo
Figura 20.22.
CREATE TRIGGER
de 1999.
I
I
1 1
Resumen
Los procedimientos almacenados y los disparadores son dos capacidades muy tiles para las bases de datos SQL utilizadas en aplicaciones de procesamiento de transacciones.
Los procedimientos almacenados permiten predefinir operaciones comunes de la base de datos y los invocan simplemente llamando al procedimiento almacenado, para una mejor eficiencia y menor posibilidad de errores. Las extensiones al lenguaje SQL bsico proporcionan a los procedimientos almacenados las caractersticas normalmente encontradas en los lenguajes de programacin. Estas caractersticas incluyen variables locales, procesamiento condicional, bifurcacin e instrucciones especiales para el procesamiento de los resultados de la consulta fila a fila. Las funciones almacenarlas son una forma especial de procedimiento almacenado que devuelven un valor. Los disparadores son procedimientos cuya ejecucin se inicia automticamente en funcin de los intentos de modificacin de una tabla. Un disparador se puede activar mediante una instruccin INSERT, DELETE o UPDATE.
756
Hay una gran variedad en los dialectos SQL especficos utilizados por la mayora de marcas de SaBD para incorporar procedimientos almacenados y disparadores. Actualmente hay un estndar internacional para los procedimientos almacenados (aunque no para los disparadores); al ser uno de los ltimos estndares, todava no ha tenido un gran impacto sobre las implementaciones reales de los principales fabricantes de SGBD.
CAPTULO
21
SOL Y los almacenes de datos
,[
.
'1
Una de las aplicaciones actuales ms importantes de SQL y la tecnologa de bases de datos relacionales es el rea rpidamente creciente de los almacenes de datos y la informacin de empresa. El punto clave del almacn de datos es utilizar datos acumulados para proporcionar informacin e intuiciones para la toma de decisiones. Con el aumento de popularidad de World Wide Web y la interaccin directa con los clientes que proporciona, la cantidad de datos disponibles sobre el comportamiento de los clientes (reflejado en sus viajes dic a dic por las pginas web) ha explotado literalmente. El almacn de datos fomenta que estos datos sean tratados como un conjunto valioso y que se traduzcan, mediante su anlisis, en una ventaja competitiva. El proceso complementario de minera de datos supone un anlisis profundo de la historia y de la tendencia de los datos para encontrar intuiciones valiosas sobre el comportamiento de los clientes y las dependencias cruzadas. Las bases de datos relacionales basadas en SQL son la tecnologa clave subyacente para aplicaciones de almacn de datos. Las aplicaciones de informacin de empresa han aumentado considerablemente en popularidad en la ltima dcada. Los estudios de Corporate IS muestran que la mayora de las grandes corporaciones tienen algn tipo de anlisis de la empresa o proyectos de almacn de datos. En muchas formas, el almacn de datos representa que las bases de datos relacionales vuelven a sus races. Cuando las bases de datos relacionales aparecieron por primera vez en escena, las bases de datos establecidas (corno la base de datos lMS jerrquica de lB M) se centraron en las aplicaciones de procesamiento de transacciones de empresa. La tecnologa relacional gan popularidad cuando se centr en las .aplicaciones de ayuda a la toma de decisiones y en sus consultas ad hoc. Debido a que la popularidad de estas aplicaciones creci, la mayora de los fabricantes de bases de datos relacionales cambiaron su centro de inters para competir por nuevas aplicaciones de procesamiento de transacciones. Con el almacn de datos, la atencin ha vuelto a lo que formalmente se llama ayuda a la toma de decisiones, aunque con nueva terminologa y herramientas mucho ms potentes que las existentes hace 15 aos.
757
758
SOL. Manual de referenda
Captulo 21: SOL y los almacenes de datos
759
Conceptos de los almacenes de datos

Uno de los fundamentos de los almacenes de datos es la nocin de que las bases de datos para el procesamiento de transacciones y las bases de datos para el anlisis de los negocios sirven para necesidades muy diferentes. El foco principal de una base de datos de procesamiento interactivo de transacciones (OLTP, Online Transaclion Processillg) es admitir las funciones bsicas diarias de una organizacin. En una
Leer una fila de la tabla de inventario para comprobar que el producto est disponible. Insertar una nueva fila en una tabla de pedidos y en una tabla de elementos de pedidos para grabar el pedido del cliente. Actualizar la fila de la tabla del inventario para reflejar la disminucin de la cantidad disponible. La carga de trabajo presenta un gran volumen de solicitudes pequeas y sencillas a la base de datos que normalmente leen, escriben o actualizan filas individuales cuando se realiza una transaccin. El mismo tipo de carga de trabajo se presenta en la mayora de los tipos frecuentes de transacciones, tales como: Conocer el precio de un producto. Comprobar la cantidad de producto disponible. Borrar un pedido. Actualizar la direccin de un cliente. Aumentar el lmite de crdito de un cliente.
compaa manufacturera, las bases de datos LTP admiten los pedidos de los clientes, las listas de pedidos de materiales, la gestin del inventario, la facturacin a clientes y funciones similares. Los usuarios principales son las aplicaciones utilizadas por oficinistas que procesan los pedidos, trabajadores de produccin, plantilla de los almacenes, etc. En cambio, el ncleo central de la informacin de empresa (BI. business incelligence) es ayudar a la toma de decisiones en la empresa mediante el anlisis de los datos. Sus usuarios principales son normalmente los gestores del producto, los planificadores de la produccin y los profesionales del marketing. La Tabla 21.1 muestra las diferencias ms significativas entre los perfiles de las aplicaciones OLTP y la informacin de empresa, y las cargas de trabajo ep la base de datos que producen. El procesamiento tpico de una transaccin OL}:p del pedido de un cliente puede comprender los siguientes accesos a bases de datos:
Leer una fila de la tabla de clientes para comprobar el nmero del cliente. Comprobar el lmite de crdito para dicho cliente.
En cambio. una transaccin tpica de anlisis del negocio (que genera un informe de anlisis del pedido) puede comprender los siguientes accesos a bases de datos: Reunir informacin de las tablas de pedidos, elementos de pedidos, productos y clientes. Resumir los detalles de la tabla de pedidos por producto en una consulta resumida. Calcular las cantidades totales de pedidos por cada producto. Ordenar la informacin resultante por cliente. Esta carga de trabajo presenta una nica consulta que emplea mucho tiempo y realiza muchas lecturas. Procesa muchas filas de la base de datos (en este caso, todo elemento de cada pedido) y comprende el clculo de totales y promedios y el resumen de los datos. Estas caractersticas son tpicas de casi todas las consultas de anlisis de la empresa tales como: Qu regiones tuvieron el mejor rendimiento el pasado cuatrimestre? Cmo han sido las ventas por producto el ltimo cuatrimestre en relacin con el ao pasado? Cul es la tendencia para las ventas de un producto? Qu clientes compran los productos de mayor crecimiento? Qu caractersticas comparten dichos clientes? La diferencia de las cargas de trabajo entre la informacin de empresa y OLTP es sustancial y hace difcil o imposible a un nico SGBD servir a ambos tipos de aplicaciones.
Tabla 21.1.
Atributos de las bases de datos OLTP y de los almacenes de datos
Caracterstica de la base de datos
Base de datos OLTP
Base de ,datos de un almacn de datos Datos histricos. Tablas organizadas para ser fciles de comprender y consultar. Millones de filas. Ad hoc, dependiendo de la decisin particular a realizar. De miles a millones.
I
I
Contenidos de los datos Datos acmales. Estructura de los datos Tablas organizadas para adecuarse a la estructura de la transaccin. Tamao de tabla nonual Miles de filas. Patrones de acceso Predeterminados para cada tipo de transaccin a procesar. Decenas. Filas a las que se ha accedido por. solicitud Tratamiento de filas por acceso Tasa de acceso Tipo de acceso Rendimiento Filas individuales. Muchas transacciones de empresa por segundo o minuto. Leer, insertar y actualizar. Productividad de las transacciones.
Grupos (consultas resumen). Muchos minutos u horas por consulta. Casi el 100 por ciento, leer. Tiempo de ejecucin de las consultas.
760
Captufo 21; SaL y fos almacenes de datos
.761
Componentes de un almacn de datos

La Figura 21.1 muestra la arquitectura del entorno de un almacn de datos. Hay tres componentes principales:
Herramientas de carga del almacn de datos. Normalmente, un conjunto
"
1:
de programas que extraen datos de los sistemas de procesamiento de transacciones corporativos (bases de datos relacionales, archivos de grandes sistemas informticos [mainframes] y minicomputadoras, bases de datos heredadas), procesan los datos y los cargan en el almacn de datos. Este proceso comprende. normalmente, una limpieza sustancial de los datos de la transaccin, filtrndolos, dndoles nuevo formato y cargndolos de forma masiva en el almacn de datos. Una base de datos del almacn de datos. Normalmente, una base de datos relacional optimizada para almacenar grandes cantidades de datos, carga de datos masiva a altas velocidades y soporte de complejas consultas de anlisis ) del n e g o c i o . Herramientas de anlisis del negocio. Normalmente, un conjunto.-de pro gramas para ejecutar anlisis estadstico y de series temporales, que realizan anlisis de tipo qu ocurrira si y presentan los resultados de forma grfica.
Los vendedores en el mercado de almacenes de datos han tendido a concentrarse en una de estas reas. Varios vendedores desarrollan conjuntos de productos enfocados a los procesos de carga del almacn de datos. Un grupo distinto de vendedores se ha centrado en el anlisis de los datos. Ha habido una cierta consolidacin de vendedores en cada una de estas reas, pero quedan compaas de software independientes, incluidas aquellas cuyos beneficios rondan los 100 millones de dlares. Las bases de datos de los almacenes de datos especializados tambin fueron el objetivo de varias compaas que se iniciaron en los albores del mercado de los almacenes de datos. Con elliempo, las grandes empresas de SGBD tambin se han movido sobre esta rea. Algunos desarrollaron sus propias bases de datos especializadas en almacenes de datos; otras agregaron bases de datos para almacenes de datos a su lnea de productos y adquirieron compaas ms pequeas. En la actua lidad el componente base de datos de la figura es casi siempre un SGBD basado en SQL especializado en almacn de datos proporcionado por alguno de los fabricantes principales de bases de datos.
La evolucin de los almacenes de datos

El objetivo inicial del almacn de datos fue la creacin de enormes colecciones en el mbito completo de la empresa de todos los datos acumulados de la empresa. Mediante la creacin de dicho almacn de datos se podra generar casi cualquier posible pregunta sobre las prcticas del negocio en el pasado. Muchas compaas iniciaron el camino creando almacenes de datos con este enfoque, pero las tasas.de logros fueron pequeas. Los grandes almacenes de datos en el mbito completo de la empresa eran, generalmente, demasiado complicados de crear, demasiado grandes y tambin poco cmodos de usar en la prctica. Los objetivos finalmente se cambiaron a almacenes de datos ms pequeos enfocados en reas especficas que se podan beneficiar de un anlisis profundo de los datos. Se acu el trmino puesto de datos (data mart) para describir estos almacenes de datos ms pequeos (pero an grandes). Con la llegada de mltiples puestos de datos en las empresas, un rea reciente de inters ha sido la gestin de los puestos de datos distribuidos. En particular hay un gran potencial para la duplicacin del esfuerzo de la limpieza de datos y del proceso de refonnato cuando varios puestos de datos se alimentan de las mismas bases de datos de produccin. La respuesta que surge parece ser un enfoque coordinado a la transformacin de datos para mercados distribuidos, en lugar de volver a usar enormes almacenes de datos. Los almacenes de datos y ms recientemente los puestos de datos, han crecido notablemente en muchas industrias distintas. Se utilizan ms ampliamente (y ram bin ms agresivamente) en industrias donde mejor se puede utilizar la informacin sobre las tendencias del negocio para tomar decisiones que ahorren o generen grandes cantidades de dinero. Por ejemplo: Alto volumen de fabricacin. Los anlisis de las tendencias de compra de lC!s clientes, estacionalidad, etc. pueden ayudar a planificar la produccin de una empresa y disminuir sus niveles de inventario, ahorrando dinero.
Operaciones del negocio
,.---A-
__
Anlisis del negocio _ _A-,
....
r
Almacn de datos
SGBD
Herramientas
d.
i
'1
,1
I
Aplicaciones 11 del negocio ,
extraccin de datos, nuevo formato y carga
Herramientas
d.
anlisis de datos e informes
,.
I
Figura 21.1. Componentes de un almacn de datos.
762
763
Bienes empaquetados. Los anlisis de promociones (cupones, campaas de publicidad, correo directo, etc.) y la respuestas de los clientes con demografas diferentes pueden ayudar a determinar la forma ms efectiva de alcanzar clientes, ahorrando millones de euros en publicidad y costes de promocin. Telecomunicacin. Los anlisis de patrones de llamada de clientes pueden ayudar a crear planes de precios y promociones ms atractivas, quizs atrayendo a nuevos clientes de un competidor. Lneas areas. Los anlisis de los patrones de viaje de los clientes son crticos para la gestin de campo, el proceso de determinar los pasajes y las restricciones asociadas sobre los asientos disponibles en las lneas areas para maximizar el beneficio. Servicios financieros. Los anlisis de los factores de crdito de los clientes y su comparacin con los perfiles de cliente histricos pueden ayudar a tomar mejores decisiones sobre los clientes a quienes puede confiarse un crdito.
Zapatos Accesorios Mantelerias Ropa

ENE FES MAR ASR MAY JUN
50.475 55.607 61.977 55.403 62.673 65.973

Este
67.463 65.345 64.730 63.400 62.478 61.995

Oeste
89.475 93.143 94.006 97.105 97.847 98.567

Central
Arquitectura de las bases de datos para los almacenes de datos
)
Figura 21.2.
Representacin tridimensional de los datos de ventas.
La estructura (esquema) de una base de datos de un almacn de datos se disea normalmente para hacer que la informacin sea sencilla de analizar, pl:lesto que ste es el objetivo principal de su uso. La estructura debe hacer sencillo recortar los datos por la distintas dimensiones. Por ejemplo, un analista del negocio puede desear observar las ventas por categora del producto y por regin para comparar el rendimiento de diferentes productos en distintas reas del pas. El siguiente da algn analista puede desear ver las tendencias de ventas en el tiempo por regin, para ver las regiones que han crecido y las que no. La estructura de la base de datos debe proporcionar por s misma este tipo de anlisis en varias dimensiones distintas.
Cubos de hechos
.,1,
:1 '
, I
En la mayora de los casos los datos almacenados en un almacn de datos se pueden modelar adecuadamente como un cubo N dimensional (N-cubo) de hechos del negocio histricos. Un cubo sencillo tridimensional de los datos de ventas se muestra en la Figura 21.2 para ilustrar la estructura. El hecho en cada celda del cubo es un importe de ventas en euros. A lo largo de un borde del cubo, una de las dimensiones es el mes durante el que tuvieron lugar las ventas. Otra dimensin es la regin donde se realizaron las ventas. La tercera dimensin es el tipo de producto que se vendi. Cada celda en el cubo representa las ventas segn la combinacin de estas tres dimensiones. La cantidad de 50.475 en la celda frontal superior izquierda representa las ventas para enero, en ropa, en la regin Este. La Figura 21.2 muestra un sencillo cubo tridimensional, pero en muchas aplicaciones' de almacenes de datos habr una docena de dimensiones o ms. Aunque
un cubo de doce dimensiones es complicado de visualizar, los principios son los mismos que para el ejemplo del cubo tridimensional. Cada combinacin de valores dimensionales tiene un valor de hecho asociado, que es normalmente el resultado histrico del negocio obtenido para esa coleccin de valores dimensionales. Para ilustrar las estructuras de base de datos empleadas normalmente en aplicaciones de bases de datos utilizaremos un almacn de datos que se podra encontrar en una compaa de distribucin. La compaa distribuye diferentes tipos de productos, hechos por diversos proveedores, a varios cientos de clientes ubicados en diversas regiones del pas, mediante los esfuerzos de su plantilla de ventas. La . compaa desea analizar los datos de ventas histricas en estas dimensiones para descubrir tendencias y obtener intuiciones que ayuden a comprender mejor el negocio. El modelo subyacente para este anlisis ser un cubo de hechos de cinco dimensiones: Categora. Categora del producto vendido, con valores tales como ropa, manteleras, accesorios y calzado. El almacn de datos tiene alrededor de dos docenas de categoras de productos. Proveedor. Proveedor que fabrica el producto. La compaa puede distribuir productos de 50 proveedores distintos. Cliente. Cliente que adquiri los produclOs. La compaa tiene varios cientos de clientes. Algunos de los mayores clientes adquieren productos en la central, y un nico representante los sirve; otros adquieren los productos de forma local y son servidos por representantes locales.
764
765
Regin. Regin del pas donde se vendieron los productos. Algunos de los clientes de la compaa operan solamente en una regin del pas; otros operan en dos o ms regiones. Mes. Mes en el que se vendieron lt;>s productos. Por motivos de comparacin, la compaa ha decidido mantener 36 meses (tres aos) de datos histricos de ventas en el almacn de datos. Con estas caractersticas cada una de las cinco dimensiones es relativamente independiente de las otras. Las ventas a un cliente particular se pueden concentrar en una nica regin O en varias regiones. Una categora especfica de producto puede ser proporcionada por uno o muchos proveedores distintos. El hecho en cada celda del cubo de cinco dimensiones es la cantidad de ventas para esa combinacin particular de valores de la dimensin. Con los atributos que se acaban de describir, el cubo de hechos contiene 35 millones de celdas (24 categoras x 50 proveedores x 300 clientes x 3 regiones x 36 meses).
Tabla CATEGORAS
Tabla PROVEEDORES
X X X X
r
Ropa Manteleras X X X
XX XX XX
Acme XYZ S A.
X X X X
XX XX XX XX
X X X X
X X X X
.!!
~
<
Acceso;r-ios Zapatos
"-
.
Acme XYZ S A.
XX
;;
o w
KRTY S.A. DIMES S.L.
.
"-
Tabla CLIENTES
Tabla VENTAS (hechos) . .

X X
X
r
X X X X
XX XX XX XX
X X X X
50.475 64.370 93.143 61.090 57.443 61.090
X X X X
X X X X X X X X
X X X X X X X X
X X X X
X X X X X X X X
I"
Esquemas en estrella
It
En la mayora de los almacenes de datos, la forma ms efectiva de modelar el cubo de hechos N dimensional es con un esquema en estrella. Un esquema en estrella para el almacn de datos del distribuidor del ejemplo anterior ~e muestra en la Figura 21.3. Cada dimensin del cubo est representada por una tabla dimensional. Hay cinco de ellas en la figura, denominadas CATEGORAS, PROVEEDORES, CLIENTES. REGIONES Y MESES. Hay una fila en cada tabla dimensional para cada posible valor de esa dimensin. La tabla MESES tiene 36 filas. una por cada mes almacenado. Tres regiones producen la tabla de tres filas REGIONES.
"
~
KRTY S.A.
<
DIMES S.L.
x
X
93.500 61. 056
o o
o
=:
It
Tabla MESES
Las tablas dimensionales en un esquema en estrella contienen frecuentemente columnas con informacin descriptiva u otros atributos asociados con dicha dimensin (como el nombre del comprador para un cliente o la direccin del cliente y nmero de telfono, o los trminos de venta para un cliente). Estas columnas se pueden mostrar en informes generados a partir de la base de datos. Una tabla dimensional siempre tiene una clave principal que contiene el valor de la dimensin. Si los valores de una dimensin son nmeros (como el tamao de la prenda de vestir) o cadenas de texto cortas (como el nombre de la ciudad) la clave principal puede ser este valor de dimensin. Es ms comn expresar los valores de la dimensin en algn tipo de cdigo. Los cdigos de tres letras para los aeropuertos y los nmeros de cliente son ejemplos tpicos. En el almacn de datos de ejemplo de la Figura 21.3, se considera que los valores reales se utilizan como claves principales para REGIONES (Este, Oeste, etc.), CATEGORAS (ropa, calzado, etc.) y MESES. Las otras dos dimensiones utilizan valores codificados (CDIGO_CLIENTE para CLIENTES, CDIGO_PROVEEDOR para PROVEEDORES). La tabla mayor de la base de datos es la tabla de hechos en el centro del esquema, Esta tabla se denomina VENTAS en la Figura 21.3. La tabla de hechos contiene una columna con los valores de los datos que aparec;:en en las celdas del
X X X X
XX XX XX XX
ENE
1999 1999 1999 1999
" ill
.
"-
FEa
MAR
~
Tabla REGIONES
ASR
~{
ESTE OESTE CENTRAL
X X X
XX XX XX
X X X
X X X
Figura 21.3.
Esquema en estrella para el almacn de datos del distribuidor.
N-cubo de la Figura 21.2. Adems, la tabla de hechos contiene una columna (o columnas) que forma una clave externa para cada una de las labias dimensionales. En este ejemplo hay cinco columnas con dichas claves externas. Con esta estructura cada fila representa los datos para una celda del N-cubo. Las claves
766
767
externas vinculan la fila a las filas de las tablas dimensionales correspondientes para su posicin en el cubo. La tabla de hechos contiene normalmente slo unas pocas columnas. pero muchas filas (cientos de miles o incluso millones de filas no es inusual en un almacn de datos de produccin). La columna de hechos casi siempre contiene valores numricos, tales como valores monetarios. unidades enviadas o recibidas, o kilogramos procesados. Virtualmente lodos los informes del almacn de datos involucran datos resumidos (totales, promedios, valores mayores o menores, porcentajes) basados en clculos aritmticos sobre estos valores numricos. La estructura en esquema de la Figura 21.3 se llama esquema en estrella, por razones obvias. La tabla de hechos est en el centro de la estrella de las relaciones de datos. Las tablas dimensionales forma las puntas de la estrella. Las relaciones creadas por las claves externas en la tabla de hechos conectan el centro con las puntas. Con la estructura en estrella la mayora de las preguntas de anlisis del negocio se convierten en consultas que combinan la tabla central de hechos con una o ms tablas de dimensiones. Veamos algunos ejemplos.
Los datos de ventas se pueden acumular en productos individuales ordenados, y los productos se pueden asociar con un proveedor particular. Las dimensiones multinivel como stas complican el esquema en estrella bsico, y, en la prctica, hay varias maneras de tratar con ellas: Datos adicionales en las tablas dimensionales. La tabla dimensional geogrfica puede contener informacin sobre las oficinas individuales, pero tambin puede incluir columnas que indiquen el distrito y regin a la cual pertenece la oficina. Los datos agregados para estos niveles mayores de dimensin geogrfica se pueden obtener resumiendo las consultas que combinan la tabla de hechos con la tabla dimensional s'e1eccionada segn las columnas de distrito o regin. Este enfoque es conceptualmente sencillo, pero significa que todos los datos agregados (resmenes) se deben calcular consulta a consulta. Esto, probablemente, produce un rendimiento inaceptablemente bajo. Varios niveles en las tablas dimensionales. Se puede ampliar la tabla di~ mensional geogrfica para incluir filas para oficinas, distritos y regiones. Las filas que contienen los datos resumidos (total) para estas dimensiones de ms alto nivel se agregan a la tabla de hechos cuando se actualiza. Esto resuelve el problema de rendimiento de la consulta en tiempo de ejecucin mediante un clculo previo de los datos agregados (resumidos). Sin embargo, complica las consultas considerablemente. Debido a que cada venta se incluye aho~ ra en tres filas de la tabla de hechos separadas (una por cada oficina, distrito y regin). cualquier total se tiene que calcular de una fonna muy cuidadosa. En concreto, la tabla de hechos debe contener normalmente una columna de nivel para indicar el nivel de resumen proporcionado por cada fila, y cada consulta que calcula los totales u otras estadsticas debe incluir una condicin de bsqueda que la limita a filas de solamente un nivel especfico. Resmenes precalculados en las tablas dimensionales. En lugar de complicar la tabla de hechos, los datos resumidos se pueden precalcular y almacenar en las tablas dimensionales (por ejemplo, vemas resumidas para un distrito almacenado en la fila distrito de la tabla dimensional geogrfica). Esto resuelve el problema de hechos duplicados de la solucin anterior, pero funciona solamente para cantidades precalculadas muy sencillas. Los totales precalculados no ayudan con consultas sobre productos por distritos o sobre resultados de distrito por meses, por ejemplo, sin complicar ms las tablas dimensionales. Varias tablas de hechos en niveles distintos. En lugar de complicar la tabla de hechos, este enfoque crea varias tablas de hechos para diversos niveles de datos resumidos. Para admitir consultas de dimensiones cruzadas (por ejemplo, distrito - resultados - por mes) se necesitan tablas de hechos especializadas que resuman los datos segn esta base. El patrn resultante de tablas dimensionales y tablas de hechos tiende a tener muchas interrelaciones, por lo que recuerda a un copo de nieve; por ello este tipo de esquema frecuentemente se denomina esquema en copo de nieve. Este enfoque soluciona el problema del rendimiento en tiempo de ejecucin y elimina la posibilidad de
Mostrar las ventas totales para ropa en enero, por regin.

SELECT FROM WHERE AND AND ORDER IMPORTE_VENTAS, REGION VENTAS, REGIONES MONTH = 01/1999 PROD_TYPE = -RopaVENTAS.REGION = REGIONES.REGION BY REGION
Mostrar el promedio de ventas para cada cliente, por proveedor, para cada mes.
SELECT FROM WHERE AND GROUP ORDER AVG(IMPORTE_VENTAS), NOMBRE_CLIENTE, NOMBRE_PROVEEDOR, MES VENTAS, CLIENTES, PROVEEDORES VENTAS. CDIGO_CLIENTE = CLIENTES. CDIGO_CLIENTE VENTAS. CDIGO_PROVEEDOR = PROVEEDORES. CDIGO_PROVEEDOR BY NOMBRE_CLIENTE, NOMBRE_PROVEEDOR BY NOMBRE_CLIENTE, NOMBRE_PROVEEDOR, MES
Dimensiones multinivel
,I
En la estructura del esquema en estrella de la Figura 21.3, cada una de las dimensiones tiene solamente un nivel. En la prctica son bastante comunes las dimensiones multinivel. Por ejemplo: Los datos de ventas se pueden acumular para cada oficina de ventas. Cada oficina es una parte del distrito de ventas; cada distrito es parte de una regin de ventas. Los datos de ventas se acumulan en meses, pero tambin puede ser til mirar los resultados de forma cuatrimestral. Cada mes es parte de un cuatrimestre determinado.
768
769
datos errneos de una nica tabla de hechos, si bien puede agregar una complejidad significativa al diseo de la base de datos del almacn de datos. hacindolo ms difcil de entender. En la prctica es complicado encontrar el esquema y la arquitectura correcta para un almacn de datos particular, que est guiada por las particularidades de los hechos y dimensiones, los tipos de consultas normalmente ejecutados y otros tipos de consideraciones. Muchas compaas utilizan consultores especializados para ayudar a disear los almacenes de datos y tratar estos temas.
Para tratar con estos temas los productos SOBO para almacenes de datos han tendido a extender el ncleo del lenguaje SQL. Por ejemplo, SGBD de Red Brick, uno de los pioneros del almacn de datos y ahora parte de la lnea de productos Informix (que ha sido adquirida por IBM), disfruta de estas aportaciones como parte de su lenguaje Red Brick lntelligem SQL (RISQL): Clasificacin (Ranking). Admite consultas que piden los diez valores ms altos y solicitudes similares. Traslado de totales y promedios. Admite consultas que suavizan los datos para el anlisis de series temporales. Totales y promedios por periodos. Permite las respuestas a consultas que muestran los resultados individuales de meses ms totales actuales, y solici tudes similares. Proporciones. Permite consultas que expresan muy sencillamente las proporciones de valores individuales con respecto a un total o subtotal. sin el uso de subconsultas complejas. Decodificacin. Simplifica la traduccin de cdigos de valores dimensionales (como el identificador del proveedor en el ejemplo del almacn de datos) en nombres comprensibles. Subtotales. Permite la generacin de resultados de consulta que combinan valores detallados y resumidos en varios niveles de resumen. Otros fabricantes de almacenes de datos proporcionan extensiones similares a sus implementaciones SQL, o proporcionan las mismas capacidades en sus produc tos de anlisis de datos. Como con las extensiones en otras reas del lenguaje SQL, aunque las capacidades conceptuales proporcionadas por diferentes marcas SGBD pueden ser similares, las implementaciones especficas difieren sustancialmente.
I'[
Extensiones de SaL para los almacenes de datos

Con una estructura de esquema en estrella, una base de datos relacional proporciona conceptualmente un buen fundamento para la gestin de datos para el anlisis del negocio. La capacidad para relacionar libremente informacin de la base de datos basndose nicamente en los valores de los datos es positiva para las consultas ad hoc y no estructuradas de las aplicaciones normales de informaci6~de negocios. Sin embargo, hay algunos desajustes serios entre las consultas normales sobre informacin de negocios y las capacidades del ncleo dellenguaj SQL. Por ejemplo: Ordenacin de los datos. Muchas consultas sobre informacin de negocios tratan con ordenacin de datos explcita o implcitamente (se realizan preguntas como cul es ellO por ciento superior?, cules son los diez mejores? o cul es el peor rendimiento?. Como lenguaje orientado a conjuntos, SQL manipula conjuntos desordenados de filas. El nico soporte para ordenar los datos en el estndar SQL es la clusula ORDER BY en la instruccin SELECT, que se aplica solamente al final del procesamiento orientado a conjuntos. Series temporales. Muchas consultas sobre informacin de negocios comparan valores basados en el tiempo (contrastando los resultados de este ao con los del ao pasado o los resultados de este mes con los del mismo mes del ao pasado, o calculando los factores de crecimiento ao a ao, por ejemplo). Es muy complicado, y algunas veces imposible, obtener comparaciones de datos uno a uno de distintos periodos de tiempo en una nica fila de resultados de consulta de SQL estndar; esto depender de la estructura de . la base de datos subyacente. Comparacin con valores agregados. Muchas consultas sobre informacin de negocios comparan valores de entidades individuales (por ejemplo, resultados de ventas por oficina) con un total global o con subtotales (como los resultados regionales). Estas comparaciones son difciles de expresar en SQL estndar. Es imposible generar directamente un formato de informe que muestre los detalles de artculos, subtotales y totales desde SQL, puesto que todas las filas de resultados deben tener la misma estructura de columna.
',1
l"
t
1 '
Rendimiento de los almacenes de datos

El rendimiento de un almacn de datos es una de las claves de su utilidad. Si las consultas sobre el anlisis del negocio tardan mucho tiempo se tiende a no utilizar el almacn de datos para tomar decisiones. Si se tarda mucho tiempo en cargar los datos en el almacn de dalas, la organizacin del IS corporativo probablemente se resistir a actualizaciones frecuentes, y los datos antiguos pueden hacer que el almacn de datos sea menos til. Lograr un buen equilibrio entre el rendimiento de la carga y el rendimiento en el tiempo de ejecucin es una de las claves para una implantacin satisfactoria de un almacn de datos.
I )
"
Rendimiento de la carga
El proceso de cargar un almacn de datos puede ser muy costoso en tiempo. Es comn que las cargas de datos de un almacn de datos tarden horas o incluso das
' I
770
Captulo 21: SaL y Jos almacenes de datos
771
para almacenes de datos muy grandes. El procesamiento de carga normalmente comprende estas operaciones: Extraccin de datos. Los datos a cargar en la base de datos del almacn de datos vienen normalmente de varios orgenes de datos operacionales diferentes. Algunos pueden ser bases de datos relacionales que admiten aplicaciones OLTP. Limpieza de datos. Los datos operacionales tienden a ser sucios, en el sentido de que contienen errores significativos. Por ejemplo, los sistemas de procesamientos de transacciones antiguos pueden no tener comprobaciones de integridad, permitiendo la entrada de nmeros de clientes O n-" meros de productos incorrectos. El proceso de carga del almacn de datos incluye normalmente integridad de datos y comprobaciones de la sanidad de los datos. Verificacin cruzada de los datos. En muchas compaas se han desarrollado sistemas de procesamiento de datos que admiten varias operaciones del negocio en pocas diferentes y no estn integradas. Los cambios proce.sados por un sistema (por ejemplo, agregar nuevos nmeros de productQs/a una aplicacin de procesamiento antigua) pueden no estar reflejados auto.mticamente en otros sistemas (por ejemplo, el sistema de control de inventario) o puede haber retrasos en la propagacin de los cambios. Cuando los 'datos de estos sistemas no integrados llegan al almacn de datos, se debe comprobar su consistencia interna. Reformato de los datos. Los formatos de datos en los almacenes de datos operacionales pueden diferir considerablemente de la base de datos del almacn de datos. Los datos de caracteres pueden necesitar la transformacin de una codificacin EBCDIC del gran sistema (mainframe) a ASCII. Los datos decimales por zonas o empaquetados pueden necesitar un cambio de formato. Los formatos de fechas y horas son otra fuente de diferencias. Adems de estas sencillas diferencias en el formato de los datos, los datos de un origen de datos OLTP pueden tener que ser divididos en varias tablas de almacenes de datos, mientras que los datos de varias tablas o archivos OLTP pueden tener que ser combinados para crear una tabla de almacn de datos. Insercin/actualizacin de datos. Despus del preprocesamiento, la carga de datos masiva real en una base de datos de un almacn de datos tiende a ser una operacin especializada. Los cargadores de datos de grandes volmenes operan normalmente en un modo orientado a lotes, sin una lgica de transaccin y con una recuperacin especializada. Se puede necesitar la carga de filas o factores de actualizacin de cientos de megabytes por hora. Creacin/actualizacin de ndices. Se deben modificar los ndices especializados utilizados por el almacn de datos para reflejar los contenidos revisados del almacn de datos. Al igual que en la insercin y actualizacin real de datos, normalmente se aplica un control especial. En algunos casos es ms eficaz volver a crear rpidamente un ndice entero que modificarlo incrementalmente cuando las filas de datos se insertan o actualizan. Otras estructuras de ndices penniten ms actualizaciones incrementales.
Estas tareas son ejecutadas normalmente por programas de construccin de almacenes de datos especializados basados en procesamiento por lotes. El acceso a consultas ad hoc al almacn de datos est desactivado durante el procesamiento ~e actua.lizaciones. permitiendo que se ejecuten a la mxima velocidad sin compeUr por CIclos del SGBD. A pesar de estas optimizaciones, los tiempos de carga del almacn de datos tienden a crecer con la cantidad de datos acumulados, por lo que el compromiso entre el tiempo de carga y el rendimiento en tiempo de ejecucin se debe hacer de forma progresiva. Los almacenes de datos con muchos ndices o valores resumidos precalculados pueden ofrecer un rendimiento mucho mejor en tiempo de ejecucin, pero a expensas de tiempos de carga inaceptablemente largos. Las estructuras ms sencillas con menos trabajo de carga pueden incrementar el tiempo requerido para consultas ad hoc por encima de un nivel aceptable. En la prctica, el administrador del almacn de datos debe encontrar un buen equilibrio entre la carga y el rendimiento de la consulta en tiempo de ejecucin.
Rendimiento de las consultas

Los fabricantes de bases de datos centrados en los almacenes de datos han invertido una energa considerable en optimizar sus productos SGBD para maximizar el rendimiento de las consultas. Como consecuencia, el rendimiento de los almace nes de datos ha aumentado dramticamente en los ltimos aos. El crecimiento en tamao y complejidad de los almacenes de datos ha evitado que parte de esta ganancia en el rendimiento se haya trasladado en un beneficio perceptible al usuario final. Se han desarrollado varias tcnicas diferentes para maximizar el rendimiento de las consultas del anlisis del negocio en un almacn de datos: Esquemas de ndices especializados. Las consultas de anlisis del negocio normales comprenden un subconjunto de datos en el almacn de datos, seleccionados segn los valores dimensionales. Por ejemplo, una comparacin entre los resultados de este mes y el mes anterior comprende solamente dos de los 36 meses de datos en el ejemplo del almacn de datos. Los esquemas de ndices especializados se han desarrollado para permitir una seleccin muy rpida de las filas adecuadas de la tabla de hechos y combinarlos en tablas dimensionales. Varias comprenden tcnicas de mapas de bits, donde cada valor individual posible para una dimensin (o una combinacin de dimensiones) se asigna a un nico bit en un valor del ndice. Las filas que cumplen un criterio de seleccin se pueden identificar muy rpidamente mediante operaciones lgicas de bits, las cuales se pueden calcular ms rpidamente que las comparaciones por valores. Tcnicas de procesamiento en paralelo. Las consultas de anlisis del negocio se pueden dividir frecuentemente en partes que se pueden realizar en paralelo para reducir el tiempo completo requerido para producir los resultados finales. En una consulta que rena cuatro tablas de un almacn de datos, por ejemplo, el SGBD puede aprovecharse de un sistema de dos procesado-
i'
772
773
res mediame la reunin de dos tablas en un proceso y otras dos en otro. Los resultados de estas reuniones intermedias se combinan despus. De forma alternativa, la carga de trabajo del procesamiento de una nica tabla en la consulta se podra dividir y llevar a cabo en paralelo (por ejemplo, asignando filas para rangos mensuales especficos para procesos especficos). El uso de sistemas multiprocesadores en estos casos es bastante distinto que para bases de datos LTP. Para OLTP el foco de las operaciones multiprocesador es incrementar la productividad general. Para almacenes de datos el foco es normalmente la mejora del tiempo global de ejecucin en respuesta a una nica consulta compleja. Optimizaciones especializadas. Cuando aparece una consulta de base de datos compleja que comprende criterios de seleccin y reuniones, el SOBO tiene muchas secuencias diferentes para llevar a cabo la consulta. El optimizador para una base de datos OLTP tiende a beneficiarse de la suposicin de que las relaciones entres claves externas y claves principales se deberan realizar al principio de su procesamiento, puesto que tiende a disminuir drsticamente el nmero de filas en resultados intermedios. El optimizador1para una base de datos del almacn de datos puede poner en prctica una declsin bastante diferente, basada en la informacin acumulada durante el p;oceso de carga sobre la distribucin de valores de datos en la base de datos" Como con el rendimiento del tiempo de carga, la maximizacin del rendimiento en tiempo de ejecucin de un almacn de datos es una tarea diaria para el administrador de la base de datos. Nuevas revisiones del software SOBD proporcionan frecuentemente beneficios en el rendimiento, al igual que lo hacen procesadores de mayor rendimiento o ms procesadores_
tendencias, ordenaciones segn clasificaciones y comparaciones basadas en fechas. Se requiere un diseo cuidadoso de un gran almacn de datos para proporcionar el correcto equilibrio entre el rendimiento de carga y el rendimiento en tiempo de ejecucin.
Resumen
.!I
El almacn de datos es un apartado rpidamente creciente del mercado para bases de datos relacionales basadas en SQL y presenta un conjunto de requisitos especializados: Las bases de datos para almacenes de datos se optimizan para la carga de trabajo de consultas de anlisis del negocio tpicas, que son bastante diferentes a las cargas de trabajo de OLTP. Los programas de utilidades especializados proporcionan una carga de alto rendimiento para el almacn de datos y las herramientas de anlisis para aprovechar los datos almacenados. Las estructuras del esquema de la base de datos especializada, tales como el esquema en estrella, se utilizan normalmente en aplicaciones de almacn de datos para admitir consultas de anlisis del negocio tpicas y para optimizar el rendimiento. L~s extensiones de SQL se utilizan frecuentemente para admitir consultas de anlisis del negocio tpicas que comprenden series temporales y anlisis de
l' fl
i-
CAPTULO
22
SOL Y los servidores de aplicaciones
I~ ,
Los servidores de aplicaciones son una de las nuevas tecnologas principales originadas por el crecimiento de Internet. Los servidores de aplicaciones forman una capa clave en la mayora de las arquitecturas de los sitios Web comerciales. Como el nombre indica, los servidores de aplicaciones proporcionan una plataforma para ejecutar la lgica de la aplicacin que dirige la interaccin del usuario en un sitio Web. Adems, Jos servidores de aplicaciones realizan otra funcin importante: actan como mediadores entre los componentes de la zona Internet en un sitio Web (los servidores Web y las herramientas de gestin de contenidos) y los componentes IT, tales como las aplicaciones corporativas heredadas y las bases de datos. En esta funcin los servidores de aplicaciones deben trabajar codo con codo con el software SGBD, y SQL es el lenguaje para esa comunicacin. Este captulo explora la funcin de SQL en una arquitectura de sitio Web multicapa construida utilizando servidores de aplicaciones.
SOL Y lo sitios Web: las primeras implementaciones

Los servidores de aplicaciones no siempre tuvieron una funcin prominente en las arquitecturas de los sitios Web. Los primeros sitios Web estaban focal izados casi exclusivamente en repartir contenido a sus usuarios, en la forma de pginas Web estticas. El contenido del sitio Web se estructuraba como una serie de pginas Web predefinidas almacenadas en archivos. Un servidor Web aceptaba solicitudes de los exploradores de usuario (en la forma de mensajes HTTP), localizaba ]a pgina o pginas solicitadas y las enviaba al explorador para su visualizacin, de nuevo utilizando HTTP. Los contenidos de la pgina Web se expresaban en HTML, el lenguaje de marcas de hipertexto. El cdigo HTML para una pgina dada contena texto y grficos a mostrar en la pgina, as como los vnculos que albergaban la navegacin desde esta pgina a otras. No se tard mucho para que las demandas de informacin a repartir mediante World Wide Web sobrepasaran las capacidades estticas de las pginas Web prede775
I I
776
Captulo 22: SOL y Jos servidores de aplicaciones
777
Internet
Solicitud
HTIP
Resultados HTML
r--'~---..JI---,
de comandos para el procesamiento de sitios Web. La mayora de los lenguajes de secuencias de comandos son interpretados y la ejecucin de una secuencia de comandos compleja puede consumir una gran cantidad de ciclos de CPU. Las .secuencias se ejecutaban como procesos separados en servidores basados en UNIX o Windows (una gran sobrecarga si se deben ejecutar cada segundo docenas o cientos de secuencias de comandos). stas y otras limitaciones de las secuencias de comandos establecieron la necesidad de un enfoque alternativo y el surgimiento de los servidores de aplicaciones como parte de la arquitectura de los sitios Web.
Resultados HTML Secuencia
Los servidores de aplicaciones y las arquitecturas de tres capas de los sitios Web
Ide comandos
Perl
Figura 22.1.
Sirviendo contenido Web dinmico sin un servidor de aplig..atones.
:1
finidas. Las compaas comenzaron a utilizar sitios Web para comunicarse con sus clientes y tenan que admilir capacidades bsicas tales como bsquedas de productos especficos o aceptar el pedido de un cliente. El primer paso para proporcionar la capacidad de procesamiento actual en conjuncin con mostrar una pgina Web fue proporcionado por los mismos servidores Web, como se muestra en la Figura 22.1. En lugar de aceptar solamente solicitudes de pginas Web estticas, los servidores Web tambin aceptaron solicitudes para ejecutar secuencias de comandos, una serie de instrucciones que determinaban qu informacin mostrar. Las secuencias de comandos para servidores Web se escriban frecuentemente en lenguajes de secuencias de comandos especializados, tales como Perl. En su forma ms simple, una secuencia de comandos podra realizar un clculo muy sencillo (tal como recuperar la fecha y hora actual del sistema operativo) y mostrar el resultado como parte de una pgina Web. En un formulario ligeramente ms complejo, la secuencia de comandos podra aceptar entradas introducidas por un usuario en una pgina Web orientada a formularios, ejecutar una consulta en la base de datos basada en la entrada y mostrar los resultados. Debido a que la salida de la secuencia de comandos poda variar de una ejecucin a la siguiente, la pgina Web resultante se convirti en dinmica: sus contenidos podran cambiar de una vista a la siguiente, dependiendo de los resultados de la ejecucin de la secuencia de comandos. Los lenguajes de secuencias de comandos proporcionaron los primeros vnculos entre los sitios Web y las bases de datos SQL. Una secuencia de comandos poda, por ejemplo, enviar una consulta SQL al SGBn mediante una variacin sobre la interfaz interactiva SQL y aceptar los resultados de la consulta para mostrarlos en la pgina Web. Sin embargo, hubo muchos problemas con las secuencias
La evolucin lgica de las secuencias de comandos de los servidores Web fue la definicin de una funcin separada para un servidor de aplicaciones, de lo que result una arquitectura en tres capas, segn se muestra en la Figura 22.2. El servidor Web mantiene su responsabilidad principal de ubicar y servir pginas Web estticas y trozos estticos de pginas Web desde sus archivos. Cuando se requiere el procesamiento de una aplicacin para determinar qu informacin visualizar o para procesar informacin proporcionada por el usuario, el servidor Web llama a un servidor de aplicaciones separado para ejecutar el procesamiento. En un sitio Web pequeo y de poco volumen el servidor d~ aplicaciones se puede ejecutar como un proceso separado en el mismo sistema fsico que el servidor Web. En un caso ms general, utilizado por sitios Web grandes, el servidor Web y el servidor de aplicaciones se ejecutarn sobre dos computadoras distintas, 'normalmente conectadas mediante una red de rea local de alta velocidad. En cualquiefa de las configuraciones, el servidor Web pasa solicitudes en forma de mensajes al servidor de aplicaciones y recibe la respuesta en forma de contenido HTML a mostrar en la pgina. En los primeros das de los servidores de aplicaciones hubo una amplia gama de productos servidores de aplicaciones distintos. Algunos 'servidores requeran que las aplicaciones se escribieran en C o C++. Otros requeran el uso de Java. La interfaz entre el servidor de aplicaciones y el servidor Web fue definida por las API de dos de los principales vendedores de servidores Web, Netscape y Microsoft. Pero el resto de aspectos, desde el lenguaje de programacin a los servicios admitidos, proporcionados por el servidor de aplicaciones a la API para acceso a bases de datos, no estaban estandarizados. La introduccin por Sun Microsystem de E11terprise Java Beans (EJE) y Java2 E11terprise Edition (J2EE) inici la estandarizacin de los servidores de aplicaciones. EJB se construy sobre la creciente popularidad de Java como lenguaje de programacin. La especificacin vino desde Sun, uno de los vendedores principales de servidores y una compaa ampliamente reconocida por su liderazgo en las tecnologas Internet. Las especificaciones tambin contenan una API estandarizada para el acceso a bases de datos, una de las funciones ms importantes proporcionadas por un servidor de aplicaciones, en la forma de Java Database C011l1eCtivity (JDBC).
778
Captulo 22: SaL y los servidores de aplicaciones
779
Explorador Web
Solicitud
HITP
i 1tI
1
Internet
Resultados
HTML
Capa 1 -
Servidor{es) Web Servidor{es) Web
(contenido esttico)
Sol icitud
Ap pSvr Capa 2 - Servidorles) de aplicaciones (contenido dinmico y lgica)
Resultados HTML
uno de los vendedores pioneros de servidores de aplicaciones J2EE. BEA Systems, un fabricante lder de software middleware para el procesamiento de transacciones, adquiri WebLogic, otro pionero de los servidores de aplicaciones. Netscape, que proporcion uno de los servidores Web lderes, rellen su lnea de productos adquiriendo Kiva, otro lder inicial de mercado de servidores de aplicaciones. Posteriomente, cuando AOL adquiri Netscape y form una alianza con Sun, ambos productos de servidores de aplicaciones J2EE tuvieron una gestin comn en Sun, combinndose finalmente en el servidor de aplicaciones Sun iPlanet (cambiando posteriormente la marca del servidor de aplicaciones SunONE). HewlettPackard sigui con su propia adquisicin de Bluestone, otro vendedor de servidores de aplicaciones. IBM se apart de esta lnea de adquisiciones construyendo su propio servidor de aplicaciones, con el nombre en el mercado de WebSphere. Oraele tambin introdujo su propio producto desarrollado internamente, Oracle Application Server, aunque gran parte de su software fue reemplazado por componentes adquiridos a terceros al luchar por su posicin. Tras varios aos de competencia agresiva, la especificacin J2EE continu evolucionando, e incorpor caractersticas expandidas para acceso a bases de datos en servidores de aplicaciones. WebLogic, de BEA, y WebSphere, de IBM, surgieron como productos dominantes, con aproximadamente la misma cuota de mercado. Los productos de Sun, Gracle y una docena de vendedores menores se dividieron el resto del mercado. Todo producto servidor de aplicaciones significativo cumpla con la especificacin J2EE y proporcionaba capacidades basadas en JDBC para el acceso a bases de datos.
Servidor(es) de aplicaciones
Acceso a bases de datos desde los servidores de aplicaciones

Sal
La convergencia del mercado de servidores de aplicaciones alrededor de la especificacin J2EE estandariz la interfaz externa entre el servidor de aplicaciones y SGBn alrededor de JDBC. Conceptualmente, un servidor de aplicaciones puede acceder automticamente a cualquier producto de bases de datos que ofrezca una API compatible con JDBe, y con ello logra independencia de SOBD. En la prctica existen sutiles diferencias entre los sistemas SGBD en reas como dialectos SQL y nombres de bases de datos que todava requieren algn ajuste y test, y manifiestan sutiles diferencias con el cdigo implantado en el servidor de aplicaciones. Sin embargo, estas diferencias tienden a ser menores y su ajuste es relativamente sencillo. El enfoque de la gestin de datos para el cdigo de la aplicacin que se ejecuta en el servidor de aplicaciones es una tarea ligeramente ms complicada. Aunque el servidor de aplicaciones proporciona servicios uniformes para la gestin de datos, lo hace en varias arquitecturas diferentes, utilizando distintos tipos de EJB en la especificacin J2EE. El diseador de aplicaciones debe elegir entre estos enfoques, y en algunos casos los mezclar y ajustar para lograr los requisitos de la aplicacin. Veamos algunas de las decisiones que hay que adoptar:
Sol icitud
Resultados
Sal
Capa 3 - Servidor(es) de bases de datos (gestin de datos)
1, I
,1
'1
Servidor(es) de bases de datos
i':! I
,1
Figura 22.2.
Arquitectura en tres capas mediante el uso de un servidor de aplicaciones.
En poco tiempo los servidores de aplicaciones basados en la especificacin J2EE coparon el mercado. Los vendedores que adoptaron un enfoque alternativo aumentaron sus productos con capacidad Java y finalmente abandonaron sus productos por: una estrategia basada en J2EE. Poco tiempo despus, el mercado de servidores de aplicaciones comenz a consolidarse. Sun adquiri NetDynamics,
780
Captulo 22: SOL y los servidores de aplicaciones
781
i:
Realizar la lgica de la aplicacin un acceso directo a la base de datos desde una sessioll bean, o se representarn los contenidos de la base de datos como entidades heao, con la lgica del acceso a la base de datos
encapsulada? Si se utiliza un acceso directo desde sesiones beao, puede la sesin beao permanecer sin estado (lo que simplifica el cdigo de la heao y su gestin
a bases de datos (mediante JDBC). El contenedor tambin proporciona servicios de persistencia, preservando el estado de las bean entre diferentes activaciones. Las EJB vienen en dos tipos principales que son de inters desde una perspectiva de gestin de datos. Los tipos de EJB se ilustran grficamente en el la Figura 22.3. Los dos tipos de bean principales son: Sesiones beao. Estas bean representan sesiones de usuario individuales con el servidor de aplicaciones. Conceptualmente hay una asociacin uno a uno entre cada sesin bean y el usuario en curso. En la Figura, los usuarios Mara, Juan y Samuel vienen representados cada uno por su propia sesin bean. Si hay variables de ejemplares internas a la beao, los valores de las variables representan el estado actual asociado con el usuario durante esta sesin particular. Entidades bean. Estas hean.representan objetos del negocio y lgicamente se corresponden con filas individuales de una tabla de una base de datos. Por ejemplo, para entidades beao que representan oficinas de ventas hay una correspondencia biunvoca entre cada entidad bean y una oficina particular, que tambin es representada en nuestra base de datos ejemplo por una nica fila en la tabla OFICINAS. Si hay variables de ejemplares internas a la bean, los valores de las variables representan el estado actual asociado con la oficina, que tambin est representada por los valores de columna en esta fila
,1
por el servidor de aplicaciones), o requiere la lgica de acceso a la base de datos para que guarde el estado preservando el contexto de una invocaci6n a otra? Si las entidades beao se utilizan para representar los contenidos de la base de datos. puede la aplicacin apoyarse en la persistencia de los contenedores proporcionada por el servidor de aplicaciones, para gestionar la interaccin de la base de datos, o la lgica de la aplicacin requiere que la entidad bean proporcione su propia lgica de acceso a la base de datos mediante la persistencia gestionada por la bean? Si las entidades bean se utilizan para modelar los contenidos de los datos, hay una correspondencia biunvoca entre las bean y las tablas de la base de datos subyacente (modelado de grano fino), o es ms apropiado que las bean presenten una vista de mayor nivel, orientado a objetos, de los datos~bn los datos de cada bean extrados de mltiples tablas de la base de datos (modelado de grano grueso)? Los compromisos representados por estas incertidumbres en el diseo proporcionan una perspectiva excelente sobre el reto de ajUstar SQL y la tecnologa de bases de datos relacionales a las demandas de World Wide Web y su arquitectura ausente de estado, y las demandas de los servidores de aplicaciones y la programacin orientada a objetos. En las siguientes secciones se describen los fundamentos de EJB y los compromisos entre las diferentes arquitecturas de acceso a datos que pueden admitir.
r
"
Internet Sesiones de usuario
Tipos EJB
En un servidor de aplicaciones compatible con J2EE, el cdigo de las aplicaciones Java.desarrolladas por el usuario que implementan la lgica especfica del negocio se empaquetan y ejecIah como una coleccin de Effi. Un EJB es un conjunto bien definido de interfaces externas (mtodos) que se deben proporcionar, y se escribe con un conjunto explcito de mtodos pblicos especficos de la clase que definen la interfaz externa a la bean. El trabajo realizado en la bean y cualquier variable de datos privada que se mantiene para uso propio se puede encapsular y ocultar 'a otras bean y a desarrolladores que no tienen que conocer estos detalles internos y no tienen que escribir cdigo que dependa de ellas. Las EJB se ejecutan en el servidor de aplicaciones en un contenedor, que proporciona un entorno en tiempo de ejecucin para las bean y los servicios para ellos. stos van de servicios generales, como gestin de memoria para las bean y programacin de su ejecucin, a servicios especficos, como acceso a red y acceso
't '1
,'.,1 1
Sesiones
bean Entidades bean
00
Servidor de aplicaciones __ Tabla de la base de datos
:I
I
l
'1.,
[1
'1
Figura 22.3.
Tipos de EJB,
782
783
de la tabla OFICINAS. Este estado es independiente de cualquier sesin de usuario panicular.

Cada tipo de bean puede acceder a una base de datos, pero normalmente 10 harn de forma bastante diferente.
piar los valores de las variables del ejemplar para almacenar (en un archivo de disco o base de datos) cuando se hace pasiva la bean y restaurar posteriormente dichos valores cuando se reactiva la bean. Por ello, las sesiones bean con estado pueden disminuir significativamente el rendimiento de un servidor de aplicaciones en un sitio atareado. Son preferibles por motivos de rendimiento las bean sin estado, pero muchas aplicaciones son difciles o imposibles de implementar sin el uso de las bean con estado.
Acceso a bases de datos con sesiones bean

Normalmente, una sesin bean acceder a una base de datos en una serie de una o ms llamadas JDBC en nombre de un usuario representado por la bean. Un servidor de aplicaciones clasifica las sesiones bean en dos categoras, dependiendo de cmo gestiona la bean el estado:
Uso de JDBC desde una sesin bean sin estado

La Figura 22.4 muestra un ejemplo sencillo de aplicacin que se puede gestionar fcilmente con el acceso a una base de datos mediante una sesin bean sin estado. Una pgina en un sitio Web muestra el precio en curso de los productos de una compaa cuando se muestra la pgina. La pgina no puede ser esttica, puesto que los precios mostrados cambian minuto a minuto. Por ello cuando el explorador del usuario solicita la pgina, el servidor Web enva la solicitud a un servidor de aplicaciones, el cual finalmente invoca un mtodo de una sesin bean. La sesin bean puede utilizar JDBC para enviar una instruccin SELECT de SQL a una base de datos con los precios actuales de los productos, y devuelve la respuesta como una lnea de resultados de consulta. La sesin bean vuelve a dar formato a la cuota de productos como un fragmento de una pgina Web y los devuelve al servidor Web para que los muestre al usuario. Las sesiones bean sin estado tambin pueden ejecutar funciones ms complejas. Supongamos que la misma compaa tiene una pgina en su sitio Web donde un usuario puede solicitar un catlogo de productos rellenando los contenidos de un pequeo formulario. Cuando se rellena el formulario y el usuario pulsa el botn Enviar, el explorador enva los datos desde el formulario al servidor Web, el cual de nuevo enva la solicitud a un servidor de aplicaciones. Esta vez, se invoca un mtodo diferente de la sesin bean y recibe los datos del formulario como parmetros. La sesin bean puede utilizar JDBC para enviar una instruccin SQL INSERT a la tabla de una base de datos que albergue las solicitudes de catlogo pendientes. . En cada uno de estos ejemplos, la informacin que la sesin bean necesita para realizar su tarea se pasa con la invocacin al mtodo. Cuando la bean ha completado su tarea, dicha informacin no se necesita ms. La siguiente invocacin recibe de nuevo toda la informacin necesaria, por lo que no es preciso conservar informacin de estado. Incluso, ms importante, la actividad de la base de datos en cada invocacin es completamente independiente del resto de invocaciones. Ninguna transaccin de la base de datos implica mltiples llamadas a mtodos.
Sesin bean sin estado. Este tipo de bean no mantiene ninguna informacin del estado entre diferentes llamadas a los mtodos. Lleva a cabo sus acciones en nombre de un usuario cada vez y una solicitud cada vez. Cada solicitud a la bean es independiente de la anterior. Con esta restriccin, cada invocacin a la bean debe contener (en forma de parmetros pasadosJcon la invocacin) toda la informacin necesaria para llevar a cabo la sorkitud. Sesin bean con estado. Este tipo de bean mantiene la informacin del estado entre diferentes llamadas a los mtodos. La bean necesita recordar la informacin de invocaciones previas (su estado) para llevar a cabo las tareas solicitadas por invocaciones posteriores. Utiliza variables de ejemplares privadas para albergar la informacin.
Las siguientes dos sesiones muestran ejemplos de tareas que se implementan muy fcilmente con cada uno de los tipos de sesin bean. Se especifica si una sesin bean est sin o con estado en el descriptor de implantacin de la bean, que contiene informacin proporcionada al servidor de aplicaciones sobre el cual se despliega la bean. Un servidor de aplicaciones en un sitio Web atareado puede fcilmente tener ms sesiones bean y otros EJB en uso que los que la memoria puede almacenar. En esta situacin el servidor de aplicaciones mantendr un nmero limitado de ejemplares de sesiones bean activas en su memoria principal. Si un usuario asociado con una sesin bean inactiva se vuelve activo (esto es, se debe procesar una de las pulsaciones en el sitio Web), el servidor de aplicaciones elige otro ejemplar de la misma clase de bean y la hace pasiva (esto es, guarda los valores de cualquier variable de ejemplar definida para la bean y entonces reutiliza la bean para servir a la sesin de usuario que necesita la activacin). Que una sesin bean est con o sin estado tiene un impacto significativo en hacerla pasiva o activarla. Puesto que una sesin sin estado no necesita preservar su estado a travs de llamadas a los mtodos, el servidor de aplicaciones no necesita guardar los valores de variable del ejemplar cuando hace pasiva la bean, y no necesita restaurar los valores de variable del ejemplar cuando reactiva la bean. Sin embargo, para una sesin bean con estado el servidor de aplicaciones necesita co-
l.'
I
I
,1 '1
Uso de JDBC desde una sesin bean con estado

Muchas interacciones Web no pueden funcionar con las limitaciones impuestas por las sesiones bean sin estado. Consideremos un formulario Web ms complejo que abarque cuatro pginas. Cuando el usuario rellena cada pgina y la enva al
784
f
'1
Capitulo 22: SOL y los servidores de aplicaciones
785
. _..._.Pantalla
ABe Carpo Explorador Web
Precio: 1 15,75
1-i
Internet
Otro ejemplo en el cual una sesin bean con estado es adecuada es un sitio Web comercial donde un usuario compra en lnea y acumula una lista de elementos a adquirir en una lista de compras en lnea. Despus de 40 o 50 chcs por el sitio Web el usuario puede haber acumulado cinco o seis elementos en la lista de compras. Si el usuario entonces pulsa un botn solicitando mostrar los contenidos actuales de la lista de compra, los contenidos probablemente se mantienen ms fcilmente como una sesin bean con estado. En ambos ejemplos la sesin bean requiere la continuidad del acceso a la base de datos para realizar sus tareas. En la Figura 22.5 se muestra el patrn y las dife-
id
Solicitud
HITP
"
Servidor Web
Solicitud AppSvr Servidor
Resultados HTML
1i
Pantalla . ... ..
~ ~ ~
ResultadoS HTMl
Carta de compra Elementos Pantalones Camisas Zapatos
...
Explorador Web
.r
ti
Internet
de aplicaciones
Sesin
+'1
besn
Cdigo
Se agregan varias llamadas a la carta de compra ___
Servidor Web
I I I '"
Java
:1
1
Solicitud
Sal
Resultados Sal
Servidor de aplicaciones
_1 ..
_1
.Variables de ejemplares (conrenidos de fa carta de compra)
Servidor(es)
de bases de
datos
Sesin bean con estado Cdigo Java Solicitud Resultados
Figura 22.4.
Llamadas a la base de datos desde una sesin bean sin estado.
Sal
Sal
Servidor(es) de bases de datos
I I ,
sitio Web, la sesin beao debe acumular la informacin y retenerla durante las cuatro pginas hasta que todos los datos estn listos para ser enviados a la base de datos. Si es necesario retener infonnaci6n entre llamadas a mtodos, entonces es preciso usar una sesin beao con estado.
Figura 22.5.
Llamadas a la base de datos desde una sesin bean con estado.
~'
786
787
rencias con el patrn de interacciones de la Figura 22.4. Incluso si la beao se puede implementar sin variables de ejemplar (por ejemplo, almacenando toda su informacin de estado en una base de datos dorsal) necesita una sesin de base de datos continua paca llevar a cabo su acceso a la base de datos. La API en el lado del cliente para SGBD mantiene esta sesin, y la API misma necesitar mantener la informacin del estado de la sesin entre llamadas a mtodos de la sesin beao.
Hay una fuerte correspondencia entre las acciones llevadas a cabo en entidades bean y las acciones de la base de datos, segn se muestra en la Tabla 22.1. La especificacin J2EE proporciona dos maneras alternativas de gestionar esta Coordinacin. Persistencia gestionada por la bean. La entidad bean es la responsable de mantener la sincronizacin con la base de datos. El programador de la aplicacin que desarrolla la entidad bean escribe sus mtodos de implementacin para que utilicen JDBC para leer y escribir datos en la base de datos cuando sea necesario. El contenedor del servidor de aplicaciones notifica a la bean cuando realiza acciones que requieren la interaccin con la base de
Acceso a entidades con sesiones bean

Es posible implementar aplicaciones para sitios Web completas y sofistic.:adas utilizando sesiones beao implantadas en un servidor de aplicaciones J2EE. Sin embargo la programacin de una aplicacin utilizando sesiones bean tiende a producir ms cdigo procedimental y menos orientado a objetos. La filosofa orientada a objetos es tener clases de objetos (en este caso, clases EJB) que representen entidades del mundo real, tales como clientes u oficinas y ejemplares de objetos que representen clientes u oficinas individuales. Sin embargo, las sesiones bean no representan ninguna de dichas entidades; representan sesiones de usuario actualmente activas. Cuando la interaccin de la base de datos se gestiona directament~or las sesiones bean, la representacin de las entidades del mundo real se deja. bsicamente en la base de datos; no tiene una contrapartida de objeto. Las entidades bean proporcionan la contrapartida en trminos de objetos de las entidades del mundo real y las filas en una base de datos que las representan. Las clases de entidades bean incorporan los clientes y las oficinas; las ejemplares de las entidades bean individuales representan clientes individuales y oficinas individuales. Otros objetos (tales como sesiones bean) en el servidor de aplicaciones pueden interaccionar con los clientes y oficinas utilizando tcnicas orientadas a objetos, invocando los mtodos de las entidades bean que los representan. Para mantener este modelo orientado a objetos debe haber una cooperacin muy fuerte entre las representaciones de entidades bean de las entidades y sus representaciones de base de datos. Si una sesin bean invoca un mtodo de la entidad bean que cambia el lmite de crdito de un cliente, dicho cambio se debe reflejar en la base de datos, de forma que una aplicacin de procesamiento de pedidos que utilice la base de datos utilizar el nuevo lmite. De forma similar, si una aplicacin de gestin del inventario agrega el stock de un producto particular a la base de datos, se debe actualizar la entidad bean de dicho producto en el servidor de aplicaciones. De igual forma que un servidor de aplicaciones har pasiva y reactivar las sesiones bean segn sea necesario, har pasivas y reactivar entidades bean repetidamente en respuesta a una fuerte carga de trabajo. Antes de que el servidor de aplicaciones haga pasiva una entidad bean, se debe guardar el estado de la bean de una forma persistente, actualizando la base de datos. De forma similar, cuando el servidor de aplicaciones reactive una entidad bean, sus variables de ejemplar se deben establecer a los valores que tenan antes de que se hiciera pasiva, volviendo a cargar dichos valores de la base de datos. La clase de la entidad bean define los mtodos d,e retrollamada que llna entidad bean debe proporcionar para implementar esta sincronizacin.
datos .
Persistencia gestionada por el contenedor. El contenedor EJB proporcionado por el servidor de aplicaciones es responsable de mantener la sincronizacin con la base de datos. El contenedor supervisa la interaccin con la entidad bean y automticamente utiliza JDBC para leer y escribir datos en la base de datos y actualizar las variables de ejemplar en la bean cuando sea necesario. El programador de la aplicacin que desarrolla la entidad bean y codifica sus mtodos de implementacin se puede centrar en la lgica de negocio de la bean y asume que sus variables de ejemplar representarn de forma precisa el estado de los datos en la base de datos.
Tabla 22.1. Actividades de la base de datos y EJB
Instruccin de la base de datos

INSERT
Mtodo EJB
ejbCreate (), ejbPostCreate ()
Accin EJBlbase de datos Crea un nuevo ejemplar de entidad bean; el estado inicial de la bean se especifica mediante parmetros en la llamada a crea te (). Se debe insertar una nueva fila con estos valores en la base de datos. Carga los valores de variables de ejemplar, leyndolos de los datos persistentes en la base de datos. Almacena los valores de variable de ejemplar, guardndolos de fonna persistente en la base de dalas. Elimina un ejemplar de una entidad bean; se debe borrar la fila correspondiente en la base de datos.
SELECT
ejbLoad ()
'!
I
UPDATE
EjbStore ()
l'
DELETE
ejbRemove ()
11
788
789
Ntese que las entidades bean siempre son con estado (la distincin entre estos dos lipos de bean no es la diferencia entre bean con y sin estado, sino ms bien la diferencia entre quin es responsable de mantener el estado adecuado. En las siguientes dos secciones de discutirn temas prcticos asociados con cada tipo de entidad bean y los compromisos entre ellas.
Uso de la persistencia gestionada por el contenedor

El descriptor de implantacin de una entidad bean especifica que una entidad bean requiere una persistencia gestionada por el contenedor. El descriptor de implantacin tambin especifica la correspondencia entre las variables de ejemplar de la bean y las columnas en la base de datos subyacente. El descriptor de implantacin tambin identifica la clave principal, que identifica, a su vez, de forma nica a la bean y la fila de la base de datos correspondiente. El valor de la clave principal se utiliza en operaciones de base de datos que almacenan y recuperan valores de variables de la base de datos. Con la persistencia gestionada por el contenedor, el contenedor EJB es r,esponsable de mantener la sincronizacin entre la entidad bean y la fila de la b;ase de datos. El contenedor llama a JDBC para almacenar los valores de la variable del ejemplar en la base de datos, para restaurar dichos valores, para insertar u'na nueva fila en la base de datos y para borrar una fila (como se requieren por las acciones sobre la bean). El contenedor llamar al mtodo ejbStore () de la bean antes de almacenar los valores en la base de datos, para notificar a la bean que debe obtener sus valores de variable en un estado consistente. De forma similar, el contenedor llamar al mtodo ejbLoad () de la bean despus de cargar los valores de la base de datos, para permitir que la bean realice un postprocesamiento (por ejemplo, calcular un valor que no es persistente, basado en valores que s lo son). De la misma forma, se llamar al mtodo ejbRernove () de la bean antes de que el contenedor borre la fila de la base de datos y se llame a ejbCreate () yejbPostCreate () cuando se inserta una nueva fila. Para muchas entidades beao, los mtodos de retrollamada estarn vacos, puesto que el contenedor gestiona las operaciones reales de la base de datos.
Uso de la persistencia gestionada por la bean
La carga de la bean se gestiona de forma similar mediante una llamada del contenedor a ej bLoad () y almacenndola mediante una llamada del contenedor a ejbStore (). El contenedor notifica a la bean mediante retrollamadas al hacerla pasiva O activarla. Por supuesto, nada limila la interaccin de la base de datos de la entidad bean a es(Os mtodos ,de retrollamada. Si la bean necesita acceder a la base de datos durante la ejecucin de uno de sus mtodos, la hean puede hacer lo que necesite la llamada JDBe. Las llamadas JDBe en los mtodos de retrollamada se cenlran estrictamente en la gestin de la persistencia de la bean.
Diferencias entre la gestin por el contenedor y por la bean
Nos podramos naturalmente preguntar por qu se puede desear utilizar la persistencia gestionada por la bean cuando la persislencia geslionada por el contenedor elimina la necesidad de preocupamos sobre la sincronizacin con la base de datos. La respuesta es que la persistencia geslionada por el contenedor liene algunas limitaciones: Mltiples bases de datos. Para la mayora de los servidores de aplicaciones, las entidades bean se deben corresponder con un nico servidor de bases de datos. Si los datos de la entidad bean vienen de varias bases de datos, entonces la persistencia gestionada por la beao puede ser la nica forma de gestionar la sincronizacin con la base de datos. Mltiples tablas por bean. La persistencia gestionada por el contenedor funciona bien cuando (Odas las variables de ejemplar para una entidad bean vienen de una nica fila de una nica tabla (esto es, cuando hay una correspondencia uno a uno entre los ejemplos bean y las filas de la tabla). Si una entidad bean necesita modelar un objeto ms complejo, como una cabecera de pedido y elemenlos individuales de un pedido que viene de dos tablas dislintas relacionadas, se requiere usualmente la persistencia gestionada por la bean, puesto que el propio cdigo de la bean debe proporcionar la inteligencia para la correspondencia con la base de datos. Optimizaciones en el rendimiento. Con la persistencia gestionada por el contenedor, un contenedor debe realizar una suposicin todo o nada sobre las variables de ejemplar persistentes. Cada vez que las variables se deben almacenar O cargar, se han de gestionar todas las variables. En muchas aplicaciones, la entidad bean debe poder delenninar que, dependiendo de su estado particular, se necesitan procesar solamente unas pocas variables. Si la entidad bean alberga una gran cantidad de datos, la diferencia en el rendimiento puede ser significativa. Optimizaciones de la base de datos. Si los mtodos de una entidad bean que implementan la lgica del negocio determinan mucho acceso a la base de datos (consultas y actualizaciones), algunas de las operaciones de la base de datos que el contenedor llevar a cabo en un esquema de persistencia gestionada por el conlenerlor pueden ser redundantes. Si se utiliza en su lugar la persistencia gestionada por la bean, entonces la bean puede determinar exactamente cundo se requieren las operaciones de la base de datos y cundo la base de datos est ya actualizada.
,11' '1
'::
Si el descriptor de implantacin de una entidad hean especifica la persistencia gestionada por la bean, el contenedor asume que la entidad bean gestionar su propia interaccin con la base de datos. Cuando se crea por primera vez una nueva entidad bean, el conlenedor llama a los mtodos ejbCreate () y ejbPostCreate () de la bean. La bean es responsable del procesamiento de la instruccin INSERT correspondieme de la base de datos. De forma similar, cuando se va a eliminar una entidad bean, el contenedor llama al mtodo ejbRernove () de la heao. La bean es responsable de procesar la instruccin DELETE correspondiente de la base de datos, y cuando la bean vuelve del mtodo ejbRernove(), el contenedor es libre de eliminar re'almente la bean y reutilizar su uso.
,1
:-..
790
791
En la prctica, esLas limitaciones evitan frecuentemente el uso de la persistencia gestionada por el contenedor en implantaciones actuales. Las mejoras en las nuevas versiones de la especificacin EJB se disean para solventar muchos de estos inconvenientes. Sin embargo, la persistencia gestionada por la beao sigue siendo una tcnica muy importante en los servidores de aplicaciones actualmente disponibles.
Mejoras de EJB 2.0

EJB 2.0 representa una revisin importante de la especificacin EJB. Muchas de las mejoras en EJB 2.0 eran incompatibles con las capacidades correspondientes en EJB l.x. Para evitar la ruptura de compatibilidad en las beao EJB"l.x, EJE 2.0 proporciona capacidades complementarias en estas reas, permitiendo coexistencia enlre EJB 1.x y EJB 2.0. Una descripcin completa de las diferencias entre EJB l.x y EJB 2.0 excede el objeto de este libro. Sin embargo, varias de las diferencias estuvieron molivadas por dificullades en el uso de la persistencia gestionada por el contenedor bajo la especificacin EJB 1.x, y dichos cambios afectan directamente al procesamiento de la base de datos en EJB. Ya se ha mencionado una dificuhad con EJB ].x (la dificuhad de modelarbjetos complejos que obtienen sus datos desde mltiples tablas de la base de da9s o que contienen estructuras no relacionales tales como arrays y datos jerrquicos. Con EJB 1.x se poda modelar un objeto complejo como una familia de entidades bean interrelacionadas, cada una obteniendo datos de una tabla. Ente enfoque permiti el uso de la persistencia gestionada por el contenedor, pero las relaciones entre las partes del objeto se tenan que implementar en el cdigo de aplicacin dentro de la beao. Ideal mente, estos detalles internos en el objeto complejo deberan estar ocultos del cdigo de las aplicaciones. De forma alternativa, con EJB 1.x se poda modelar un objeto complejo como una nica entidad bean, con datos en las variables de ejemplar de las bean obtenidas desde varias tablas relacionadas. Esto permite la transparencia deseada del cdigo de la aplicacin, pero la persistencia gestionada por el contenedor se puede utilizar cuando una entidad bean obtiene sus datos desde varias tablas. EJB 2.0 soluciona este tema mediante el uso de mtodos de acceso abstractos, que se utilizan para establecer y recuperar toda variable de ejemplar persistente en una entidad bean. El contenedor mantiene realmente el almacenamiento de las variables y los valores de las variables. La bean llama explcitamente a un mtodo de acceso get () para recuperar el valor de una variable de ejemplar, y a un mtodo de acceso set () para establecer su valor. De forma similar, hay mtodos de acceso abstractos get () y set () para toda relacin que vincula las filas en la base de datos que proporcionan datos a la entidad bean. Las relaciones muchos a muchos se gestionan sencillamente hacindolas corresponder con variables de coleccin Java. Con estas nuevas caractersticas el contenedor tiene un conocimiento completo de todas las variables de ejemplar utilizadas por una bean, y cada acceso en la bean corresponde a variables de ejemplar. La entidad bean puede representar un objeto complejo que obtiene datos de varias tablas de la base de datos, ocultando los detalles del cdigo de las aplicaciones. Sin embargo, ahora.se puede utilizar la
persistencia gestionada por el contenedor, puesto que el contenedor conoce todo sobre las diversas partes del objeto y las relaciones entre las partes. Otro problema con la especificacin EJB l.x es que mientras que las interacciones de la base de datos estaban estandarizadas, no lo estaban los mtodos del buscador que se utilizaban para buscar las entidades bean activas. Los mtodos del buscador implementan capacidades tales como la bsqueda de una entidad bean mediante la clave principal o la bsqueda del conjunto de beao que coinciden con un criterio particular. Sin esta estandarizacin, la portabilidad a travs los servidores de aplicaciones estaba comprometida y las bsquedas de entidades bean requeran frecuentemente la bsqueda en la base de datos subyacente. EJB 2.0 soluciona las limitaciones de bsqueda mediante el uso de mtodos de seleccin abstractos que buscan las entidades bean. Los mtodos de seleccin utilizan el nuevo lenguaje de consultas EJB 2.0 Query Language (EJBQL). Aunque el lenguaje de consulta se basa en SQL-92, incluye construcciones tales como expresiones de ruta de acceso que son decididamente no relacionales. Finalmente; EJB 2.0 se dise para adecuarse al estndar SQL:1999 y sus tipos de datos abstractos. Admitir estos tipos simplifica en cierta forma la interaccin entre las entidades bean y las bases de datos para productos SGBD que admiten los tipos abstractos. En este momento, pocos productos SGBD los incorporan.
Cach de los servidores de aplicaciones

En un sitio Web de gran volumen, el acceso a la base de datos se puede convertir en un cuello de botella para el rendimiento global del sitio Web. Debido a la estructura EJB, el acceso a la base de datos requerido por la lgica de negocio de la aplicacin es aumentado (quizs sustancialmente) por el acceso a la base de datos requerido para mantener la sincronizacin entre la entidad bean y la base de datos. Si el sitio Web implementa una fuerte personalizacin de su interaccin con el usuario (esto es, un alto porcentaje de sus pginas se generan dinmicamente segn el perfil del usuario particular que las est viendo), entonces la carga en el acceso a la base de datos puede ser incluso mayor. En el extremo, todo clic en un sito Web altamente personalizado podra requerir la recuperacin de los datos de perfil del usuario de una base de datos para dirigir la generacin de la pgina. Finalmente, la interaccin de usuario con un sitio Web sucede en tiempo real y est afectada por la actividad de picos de carga. El factor promedio del procesamiento de clics es menos importante que la actividad de los picos de carga en la determinacin de si los usuarios perciben el sitio como rpido o lento. World Wide Web ya ha mostrado una arquitectura efectiva para tratar con este tipo de demandas de volumen de carga de picos en Internet (mediante la cach de las pginas Web y la ampliacin horizontal). Con la cach, las copias a l,as que se accede mucho se extraen en la red y se reproducen. Como consecuenCia, se au menta la capacidad total de la red para servir pginas Web y se reduce la cantidad de trfico de red asociado con dichas pginas. Con la escala horizontal, el contenido del sitio Web se replica en dos o ms servidores Web (hasta docenas o incluso cientos de servidores) cuya capacidad para servir pginas es mucho mayor que en solamente un nico servidor.
I!
792
Captulo 22: SQL y los servidores de aplicaciones
793
Se utilizan arquitecturas similares de cach y escala horizontal para aumentar la capacidad de los servidores de aplicaciones. La mayora de los servidores de aplicaciones comerciales actuales implementan la cach bean, donde las copias de las enti~ dades beao utilizadas frecuentemente se mantienen en la memoria del servidor de aplicaciones. Adems, los servidores de aplicaciones se implantan normalmente en bancos o agrupaciones, con cada servidor de aplicaciones proporcionando idmica lgica del negocio y capacidad de procesamiento de aplicaciones. En realidad muchos servidores de aplicaciones comerciales utilizan una escala horizontal con un nico servidor para aprovechar las configuraciones de multiprocesamiento simtrico (SMP, Symmetric Multiprocessing). Es tpico para un servidor de aplicaciones de ocho procesadores estar ejecutando hasta ocho copias independientes del software del servidor d_e aplicaciones operando en paralelo. La Figura 22.6 muestra una configuracin del servidor de aplicaciones tpica con tres servidores con cuatro procesadores cada uno.
LAN con conexin a Internet
-)
Servidor C
Servidor A
Servidor B
Desafortunadamente, el escalado horizontal y la cach tienden a funcionar enfrentndose entre s cuando tratan con datos con estado, como los almacenados en una entidad bean o base de datos. Sin una lgica de sincronizacin de cach especial, las actualizaciones realizadas en una bean almacenada en la cach de un ejemplar del servidor no aparecer automticamente en las otras cachs, lo que supone una causa potencial de resultados incorrectos. Consideremos, por ejemplo, lo que le sucede al stock si tres o cuatro cachs contienen copias de una entidad bean de un nico producto y la lgica del negocio del servidor de aplicaciones actualiza dichos valores. Las cachs contendrn muy rpidamente valores distintos para la cantidad, ninguna de las cuales es buena. La lgica de sincronizacin de las cachs requerida para detectar y evitar dicha situacin supone desafortunadamente una gran cantidad de sobrecarga. Una sincronizacin absoluta requiere un protocolo de compromiso completo de dos fases (descrito en el Captulo 23) entre las cachs. Las cachs de la base de datos pueden solventar problemas de varias cachs bean en un nico servidor SMP, como se muestra en la Figura 22.7. Mediante la cach en un nivel de base de datos en lugar del nivel de la bean, una cach de la base de datos proporciona consistencia en todas las ejemplares del servidor de aplicaciones en un nico servidor. Si el factor de lecturas de la base de datos respecto a las actualizaciones de la base de datos es alta (como, por ejemplo, en un sitio Web altamente personalizado), la sobrecarga de la sincronizacin de la cach permanecer relativamente baja y los beneficios de la escala horizontal pueden ser significativos. Oracle ha utilizado la cach de base de datos en su propio servidor de aplicaciones y ha intentado aplicarla como una ventaja competitiva. IBM est preparada para ofrecer cach de base de datos integrado para su SGBD DB2, pero no ha introducido dicha capacidad en el momento de escribir este libro. Varios productos de terceros se han introducido como cachs de bases de datos para servidores de aplicaciones, incluyendo productos para varios de los vendedores de bases de datos orientadas a objetos y de fabricantes de bases- de datos residentes en memoria. Todava permanece abierta la pregunta de si la cach de bases de datos impactar sustancialmente al mercado de servidores de aplicaciones.
,
I
Resumen
1I 1I El
Rplica de cach Servidorlesl de bases de datos
El
En este captulo se han descrito los servidores de aplicaciones y el papel que desempean en el vnculo de World Wide Web con sistemas empresariales dorsales, incluyendo bases de datos empresariales: Los servidores de aplicaciones populares implementan la especificacin 12EE, que estandariza el acceso a las bases de datos mediante un IDBC API. La lgica del negocio en un servidor de aplicaciones se implementa mediante EJB, que pueden ser sesiones bean o entidades bean. Las sesiones bean incorporan las sesiones de usuario. Pueden acceder a las bases de datos directamente mediante llamadas JDBC. Las sesiones bean sin estado admiten acceso a datos muy sencillo: una transaccin por invocacin.
Figura 22.6.
Servidores de aplicaciones y cach EJS.
lL
794
Servidor de bases de datos Servidor de aplicaciones Base de datos residente en memoria Internet Perfiles de usuario
A
/L -"
CAPTULO
23
"
o
Intranet
..
SGSD
Redes SOL Y bases de datos distribuidas
'"
L,.
<:

Intern el
Aplicacin Internet
A
~
<
=>
~
Base de datos dorsal
, L,.
'"
-
Datos calientes) en cach Base de datos residente ~ memoria

Servidores reproducidos
<1
Figura 22.7.
V Servidor
Web
Servidores de aplicaciones y cach de bases de datos.
Las sesiones bean con estado admiten transacciones que conllevan invocaciones, pero su lgica debe gestionar la persistencia del estado entre la bean pasiva y la activa. Las entidades bean representan objetos del mundo real y se corresponden con filas en las tablas de la base de datos. Siempre son con estado. Las entidades bean pueden utilizar la persistencia gestionada por el contenedor, donde el servidor de aplicaciones gestiona automticamente la sincronizaci6n entre la entidad bean y la base de datos. De forma alternativa, las entidades bean pueden adoptar la responsabilidad para ~u propia sincronizaci6n de la base de datos, bajo el esquema de persistencia gestionada por la bean.
En las dos ltimas dcadas, las redes informticas han transformado radicalmente el paisaje de la informtica corporativa. En la mayora de las compaas, toda computadora personal est conectada a una red de rea local CLAN, local area network). Potentes servidores de grupos de trabajo conectados a las LAN cumplen las necesidades informticas de los departamentos individuales. Las redes corporativas interconectan las LAN en un edificio o campus y las conectan a centros de datos de divisiones o corporativos. Enlaces adicionales interconectan ubicaciones corporativas por todo el mundo. Internet proporciona una red de redes, vinculando compaas entre s y a clientes individuales. Las aplicaciones se ejecutan en las computadoras en todos los niveles y en todas las ubicaciones de este entOrno de red. En este nuevo entorno tan profusamente conectado, los datos no residen en un nico sistema bajo control de un nico SGBD, sino que estn esparcidos por muchos sistemas diferentes, cada uno con su propio gestor de bases de datos. Frecuentemente, los diversos sistemas informticos y los sistemas de gestin de bases de datos provienen de diversos fabricantes. Al intentar las compaas interconectar sus sistemas de procesamiento de datos mediante Internet, el reto se hace incluso ms grande. Incluso si una compaa se las ha arreglado para estandarizar un nico SGBD en toda la compaa y sobre estructuras de bases de datos, dichos estndares no se aplicarn a proveedores o clientes cuando se intenten generar vnculos externos para dirigir el negocio de fonna electr6nica. Estas tendencias han generado un fuerte inters en la industria de computadoras y en la comunidad de gestin de datos sobre los problemas de gestin de bases de datos en un entorno de red. Este captulo analiza los retos de la gesti6n de los datos distribuidos, la variedad de enfoques de arquitectura y algunos de los productos que los fabricantes de SGBD han ofrecido para solventar dichos retos.
El desafio de la gestin de datos distribuidos

Cuando se establecieron en la dcada de los setenta los fundamentos de )a gestin de bases de datos relacionales y el lenguaje SQL, casi todo el procesamiento de
795
796
Captulo 23: Redes SOL V bases de datos distribuidas
797
datos comerciales se daba en grandes sistemas informticos centralizados. Los programas de negocio que procesaban las transacciones y generaban los informes se ejecutaban en el sistema central y accedan a los datos. Gran parte de la carga de trabajo del sistema central era procesamiento por lotes. Los usuarios en lnea accedan al sistema central mediante terminales de computadoras tontos que no tenan por s mismos capacidad de procesamiento. El sistema central daba formato a la informacin a mostrar al usuario en lnea y aceptaba los datos introducidos por el usuario para su procesamiento. En este entorno, las funciones del sistema de base de datos relacional y su lenguaje SQL estaba claro. El SGBD tena la responsabilidad de aceptar, almacenar y recuperar los datos basados en solicitudes expresadas en el lenguaje SQL. La lgica para el procesamiento del negocio resida fuera de la base de datos y era responsabilidad de los programas de negocio desarrollados y mantenidos por la plantilla de los sistemas de informacin. Los programas y el software SGBD se ejecutaban en el mismo sistema centralizado en que los datos se almacenaban, por 10 que el rendimiento del sistema no estaba afectado por factores externos, como el trfico de red o fallos externos al sistema. \ El procesamiento comercial de dalas en una corporacin moderna ha eyolucionado mucho desde el entorno centralizado de los aos setenta. La Figura 23.1 muestra una parte de una red de computadoras que se puede encontrar en una compaa de fabricacin, una empresa de servicios financieros o una compaa de distribucin actual. Los datos se almacenan en una serie de sistemas informticos en la red: Grandes sistemas (mailJframes). Las aplicaciones de procesamiento de datos principales de la compaa, como la contabilidad y las nminas, se ejecutan en un gran sistema mM. Las aplicaciones ms antiguas, desarrolladas y mantenidas durante los ltimos veinte o treinta aos, todava almacenan sus datos en bases de datos IMS jerrquicas. La empresa mantiene una estrategia consistente en migrar estas aplicaciones a DB2 con el tiempo, y todas las nuevas aplicaciones de los grandes sistemas desarrolladas utilizan DB2 como gestor de bases de datos. Estaciones de trabajo y servidores basados en UNIX. La organizacin de ingeniera del sistema utiliza estaciones de trabajo y servidores basados en UNIX (de Sun Microsystems) para el diseo de ingeniera, tests y soporte. Los resultados de los tests de la ingeniera y las especificaciones se almacenan en una base de datos Gracle. La compaa tambin utiliza bases de datos Gracle que se ejecutan sobre servidores basados en UNIX, de Hewlett-Packard, ubicados en seis centros de distribucin para gestionar el inventario y procesar los pedidos. Servidores LAN. Todos los departamentos de la compaa tienen LAN de PC para compartir impresoras y archivos. Algunos de los departamentos tambin tienen bases de datos locales para albergar su trabajo. Por ejemplo, el departamento de personal ha adquirido un paquete de software para la gestin de los recursos humanos y utiliza SQL Server sobre Windows NT para almacenar sus datos. En el departamento de planificacin financiera el per-
Gran sistema corporativo -IMS - DB2
Ingenieria
'5~1. Om,"
5~1 .SOL S'~"
- MS Access - qBases de datos" Excel
Planificacin
15~i .I,'ocm;,
5~1 Voo'"
Distribucin Internet Internet
~.
:"
~- Sybase
'e:- e:./
Clientes
Equipo de ventas
Figura 23.1.
/
/
Uso de un SGBD en una red corporativa tpica.
sonal de procesamiento de datos ha desarrollado una aplicacin de planificacin corporativa personalizada que utiliza Universal Server de Informix. Computadoras personales de escritorio. Todos los trabajadores de la oficina de la compaa utilizan computadoras personales. Muchos de los asis~ lentes administrativos y algunos de los gestores mantienen bases de datos personales que utilizan hojas de clculo Excel. Microsoft Access o alguno de los productos SGBD ligeros, tales como Gracle Light. En algunos casos las bases de datos se comparten con otros usuarios, mediante el uso de versiones LAN de estos productos. pe porttiles, La compaa ha adquirido recientemente un paquete de software para la automatizacin del equipo de ventas y ha equipado a los vendedores con un PC porttil. El porttil ejecuta presentaciones de ventas, enva y recibe correos electrnicos y tambin alberga una base de datos ligera local (SQL Anywhere de Sybase) con los precios de los productos y disponibilidad de datos. La base de datos tambin captura pedidos introducidos por el
798
Captulo 23: Redes SOL y bases de datos distribuidas
799
vendedor. De noche, el pe porttil se conecta a una red corporativa mediante una conexin telefnica, transmite los pedidos y recibe informacin actualizada para su copia local de la base de datos de productos. Dispositivos manuales. El equipo de gestin de la compaa ha adoptado ampliamente los asistentes digitales personales manuales (PDA). Adems de las funciones de calendario personal y libreta de direcciones, las aplicaciones que se ejecutan en el PDA pueden utilizar conexiones a red inalmbricas para verificar Jos precios e introducir pedidos de clientes. La red inalmbrica tambin se puede utilizar para alertar a los usuarios, mediante sus PDA, de cambios importantes en la base de datos, tales como actualizaciones de pre_ cios o escasez de productos. Conexiones de internet. La compaa tiene un sitio Web de Internet donde los clientes, repartidores y distribuidores pueden encontrar la ltima informacin sobre sus productos y servicios. En primer lugar, esto solamente fue un sitio Web de slo informacin, pero los competidores han comenzado recientemente a aceptar pedidos de clientes directamente a travs de Internet. Una de las prioridades ms altas del departamente IS es responder al reto competitivo mediante el soporte de transacciones de comer;!9 electr' nico en el sitio Web de la compaa. Con los datos esparcidos por muchos sistemas diferentes, es fc de imaginar solicitudes que se extiendan ms all de una base de datos y la posibilidad de conflictos de datos entre las bases de datos: Un ingeniero necesita combinar resultados de las pruebas de laboratorio (o una estacin de trabajo de ingeniera) con las previsiones de produccin (en los grandes sistemas) para elegir entre tres tecnologas alternativas. Un planificador financiero necesita vincular las previsiones financieras (en una base de datos Informix) a los datos financieros histricos (en el gran sistema). Un gestor de productos necesita saber cunto inventario de un producto particular hay en cada centro de distribucin (datos almacenados en seis servidores UNIX) para planificar la obsolescencia de los productos. Los datos de los precios en curso se necesitan descargar diariamente del gran sistema a los servidores del centro de distribucin y tambin a todas las computadoras porttiles del equipo de ventas. Los pedidos se tienen que actualizar diariamente de los sistemas porttiles y parcelarse en los centros de distribucin; los datos de pedidos agregados de los centros de distribucin se deben actualizar al gran sistema de forma que se pueda ajustar el plan de fabricacin. Los vendedores pueden aceptar pedidos de clientes y realizar estimaciones de las fechas de envo para productos populares segn sus bases de datos locales, sin conocer que otros vendedores tienen acuerdos similares. Los ped.idos se deben reconciliar y priori zar, y deben revisarse las estimaciones de envo proporcionadas a los clientes.
Los cambios de ingeniera realizados en las bases de datos de la estacin de trabajo pueden afectar a los costes de produccin y a los precios. Estos cambios se deben propagar por los grandes sistemas, al sitio Web, los centros de distribucin y las computadoras porttiles de los vendedores. Los gestores de la compaa desean consultar las diversas bases de datos compartidas mediante sus PC de mesa. Como sugieren estos ejemplos, se han convertido en decisivos los medios efectivos de distribuir los datos, gestionar los datos distribuidos y proporcionar acceso a los datos distribuidos, debido a que el procesamiento de los datos se ha cambiado por un modelo de computacin distribuida. Los fabricantes de SGBD lderes estn comprometidos en repartir la gestin distribuida de la base de dalOs, y actualmente ofrecen una serie de produclOs que solucionan algunos de los problemas de datos distribuidos ilustrados en estos ejemplos. La gestin de los datos distribuidos tambin ha sido el foco de la investigacin en la universidad y de la investigacin corporativa, y se han publicado muchos artculos tcnicos sobre la teora de la gestin de los datos distribuidos y los compromisos implicados. Hay un acuerdo general entre los investigadores sobre las caractersticas ideales que se deberan proporcionar mediante un esquema para gestionar las bases de datos distribuidas: Transparencia de la ubicacin. El usuario no se debera tener que preocupar sobre dnde estn fsicamente ubicados los datos. El SGBD debera presentar todos los datos como si fueran locales y ser responsable de mantener dicha ilusin. Sistemas heterogneos. El SGBD debera admitir los datos almacenados en diferentes sistemas. con distintas arquitecturas y niveles de rendimiento, con PC, estaciones de trabajo, servidores LAN. minicompUladoras y grandes sistemas. Transparencia de la red. Excepto por diferencias en el rendimiento, el SGBD debera funcionar de la misma forma sobre diferentes redes, desde LAN de alta velocidad a vnculos telefnicos de baja velocidad. Consultas distribuidas. El usuario debera poder reunir los datos de cualquier tabla de la base de datos (distribuida), incluso si las tablas estn ubicadas en sistemas diferentes. Actualizaciones distribuidas. El usuario debe poder actualizar los datos en cualquier tabla en la cual el usuario tenga los privilegios necesarios, tanto si la tabla est en el sistema distribuido como en un sistema remoto. Transacciones distribuidas. El SGBD debera admitir transacciones distribuidas (mediante el uso de COMMIT y ROLLBACK) a travs de las fronteras del sistema, manteniendo la integridad de la base de datos (distribuida) incluso en el caso de fallos de red y fallos en los sistemas individuales. Seguridad. El SGBD debe proporcionar un esquema de seguridad adecuado para proteger toda la base de datos (distribuida) de formas de acceso no autorizadas. Acceso universal. El SGBD debera proporcionar acceso universal y uniforme a todos los datos de la organizacin.
SOO
Captulo 23: Redes SQL y bases de datos distribuidas
S01
Ninguno de los productos SOBD distribuidos actuales se acerca a cumplir este ideal, y es poco probable que ningn producto lo haga alguna vez. En la prctica existen grandes obstculos que hacen complicado proporcionar incluso formas sencillas de gestin distribuida de la base de datos. Estos obstculos incluyen:
Rendimiento. En una base de datos centralizada, la ruta de acceso de SGBD a los datos tiene una velocidad de acceso de unos pocos milisegundos. y la velocidad de transferencia, de dalos de millones de caracteres por segundo. Incluso en una red de rea local rpida, las velocidades de acceso se alargan a centsimas o dcimas de segundo y los factores de lransferncia pueden caer hasta 100.000 caracteres por segundo o menos. En un enlace de mdem, el acceso a los datos puede tardar segundos o minutos y el mximo efectivo puede ser unos pocos miles de caracteres por segundo. Esta gran diferencia de velocidades puede ralentizar drsticamente el rendimiento del acceso a los datos remoto. Integridad. Las transacciones distribuidas requieren la cooperacin activa entre dos o ms copias independientes del software SGBD ejecutndose en diferentes sistemas informticos si las transacciones admiten propoJiciones todo o nada. Se deben utilizar protocolos especiales de transaccionti de compromiso en dos fases. Estos protocolos generan una gran cantidad de trfico de red y bloquean partes de las bases de datos que participan en la transaccin distribuida durante largos periodos de tiempo. SQL esttico. Una instruccin SQL embebida esttica se complica y almacena en la base de datos como un plan de la aplicacin. Cuando una consulta combina los datos de dos o ms bases de datos, dnde se debera almacenar el plan de la aplicacin? Debe haber dos o ms planes de cooperacin? Si hay un cambio en la estructura de una base de datos cmo se notifican los planes de aplicacin a las otras bases de datos? Mediante el uso de SQL dinmico para solucionar estos problemas en un entorno de bases de datos en red casi siempre nos lleva a un rendimiento de la aplicacin inaceptablemente lento, debido a las sobrecargas y retrasos de la red. Optimizacin. Cuando se accede a los datos a travs de la red no se aplican las reglas normales de optimizacin para SQL. Por ejemplo, puede ser ms eficiente explorar de forma secuencial una tabla local entera que utilizar una bsqueda indexada en una tabla remota. El software de optimizacin debe conocer las redes y sus velocidades. De fonna general, la optimizacin se vuelve ms crtica y ms difcil. Compatibilidad en los datos. Distintos sistemas infonnticos admiten diferentes tipos de datos e incluso cuando dos sistemas ofrecen los mismos tipos de datos, frecuentemente utilizan diferentes formatos. Por ejemplo, un pe Windows y un Macintosh almacenan enteros de 16 bits de forma diferente. Los grandes sistemas IBM almacenan cdigos de caracteres EBCDIC mientras que los servidores basados en UNIX y los PC utilizan ASCII. Uo SGBD distribuido debe enmascarar estas diferencias. Catlogos del sistema. Cuando un SGBD lleva a cabo sus tareas, realiza accesos muy frecuentes a sus catlogos del sistema. Dnde se debe tener el
catlogo en un sistema distribuido? Si est centralizado en un sistema, el acceso remoto ser lento, y colapsar el SGBD. Si est distribuido en muchos sistemas diferentes, los cambios se deben propagar por la red y estar sincronizados. Entorno mixto de fabricantes. Es muy improbable que todos los datos en una organizacin estn gestionados por una nica marca de SGBD. por lo que el acceso distribuido de la base de datos cruzar fronteras de la marca SGBD. Esto requiere una cooperacin activa entre los productos SGBD de vendedores muy competitivos (algo poco probable). Corno los fabricantes de SGBD intentan ampliar las capacidades de sus productos con nuevas caractersticas y tipos de datos, la capacidad de mantener un estndar entre vendedores es incluso menos probable. Interbloqueos distribuidos. Cuando las transacciones entre dos sistemas diferentes intentan entre s acceder a datos bloqueados en el otro sistema puede producirse un bloqueo en la base de datos distribuida, incluso si el interbloqueo no es visible en ninguno de los dos sistemas. El SGBD debe proporcionar una deteccin global de interbloqueos para una base de datos distribuida. De nuevo, esto requiere la coordinacin del procesamiento a travs de una red. y lo ms probable es que lleve a un rendimiento de la aplicacin inaceptablememe bajo. Recuperacin. Si uno de los sistemas que ejecuta un sistema SGBD distribuido falla, el operador de ese sistema debe poder ejecutar sus procedimientos de recuperacin independientemente del resto de sistemas en la red, y el estado de recuperacin de la base de datos debe ser coherente con el de los otros sistemas.
Distribucin de datos: enfoques prcticos

Debido a los formidables obstculos en la realizacin de la base distribuida ideal, los fabricantes de SGBD han adoptado un enfoque paso a paso a las bases de datos .y redes. Se han centrado en formas especficas de acceso a la base de datos en red, distribucin de datos y gestin distribuida de datos que son apropiadas para escenarios de aplicaciones particulares. Por ejemplo, un fabricante de SGBD puede, en primer lugar, proporcionar herramientas para extraer de forma rpida un subconjunto de datos de una base de datos 'principal y enviarlo a travs de una red para su carga en una base de datos esclava. Posteriormente, el vendedor puede mejorar la herramienta para mantener las actualizaciones en la base de datos maestra desde la ltima extraccin, y para extraer y transmitir solamente los cambios a la base de datos maestra. Una versin posterior de la herramienta puede automatizar el proceso completo, proporcionando una interfaz de usuario grfica para especificar los datos a extraer y las secuencias de comandos para automatizar los procesos peridicos de extraccin. De forma similar, un SGBD puede proporcionar soporte inicial a consultas distribuidas permitiendo a un usuario en un sistema consultar una base de datos ubicada en otro sistema. En versiones posteriores, el SGBD puede permitir
a;
"
1i
!l'
802
Capitulo 23: Redes SOL y bases de datos distribuidas
803
la consulta remota como una subconsulta en una consulta que accede a las tablas de la base de datos local. Despus, el SGBD puede permitir las consultas distribuidas que mezclan ms libremente los datos de las bases de bases de datos locales y remotas.
Acceso a bases de datos remotas

Uno de los enfoques ms sencillos para gestionar Jos datos almacenados en varias ubicaciones es el acceso a datos remotos. Con esta capacidad, se da'" a un usuario de una base de datos la opcin de extenderse a travs de una red y recuperar la informacin de una base de datos diferente. En su forma ms sencilla, esto puede implicar la realizacin de una consulta sencilla en la base de datos remota, como se muestra en la Figura 23.2. Tambin puede suponer la ejecucin de una instruccin INSERT. UPDATE o DELETE para modificar los contenidos de la base de datos remota. Este tipo de requisito se da frecuentemente cuando la base de datos local es una base de datos satlite (como una base de datos en una oficina de ventas local o en un centro de distribucin) y la base de datos remota es una ba~ae datos central y corporativa. ' Adems de la solicitud de acceso a datos remotos, la Figura 23.2 tamhin muestra una solicitud cliente/servidor a la base de datos remota desde un usuario PC (diferente). Obsrvese que, desde el punto de vista de la base de datos remota, hay
muy poca diferencia entre el procesamiento de la solicitud desde el PC cliente y el procesamiento de la solicitud de acceso a la base de datos remota. En ambos casos una solicitud SQL llega a travs de la red y la base de datos remota determina qu~ el usuario que hace la solicitud tenga privilegios apropiados, y entonces la lleva a cabo. En ambos casos, se informa sobre el estado del procesamiento SQL a travs de la red. Sin embargo, la base de datos local en la Figura 23.2 debe realizar algn traba~ jo diferente que el del proceso utilizado normalmente para gestionar las solicitudes de la base de datos local. Hay varias complicaciones para el SGBD local: Debe determinar a qu base de datos remota desea acceder el usuario y cmo se puede acceder sobre la red. Se debe establecer una conexin a la base de datos remota para llevar a cabo las solicitudes remotas. Se debe determinar cmo se corresponden la autenticacin del usuario local y el esquema de privilegios con la base de datos remota. Esto es, simplemente pasa el nombre/contrasea del usuario proporcionada por el acceso de la base de datos local a la base de datos remota, o es un nombre/contrasea de usuario remoto diferente, o se debera realizar alguna clase de correspondencia automtica? En efecto, el SGBD local se convierte en un agente para el usuario que realiza la solicitud de acceso remoto. Se convierte en un cliente en una conexin clientel servidor para el SGBD remoto. Varios de los principales fabricantes de SGBD ofrecen la capacidad de acceso a bases de datos remotas mostrada en la Figura 23.2. Se diferencian en la forma especfica en la que se presenta al usuario y al administrador de la base de datos. En algunos casos conllevan extensiones al lenguaje SQL aceptados por el SGBD. En otros, los mecanismos extra para establecer el acceso remoto son mayoritariamente externos al lenguaje SQL Sybase ofrece una sencilla capacidad de acceso a bases de datos remoto en el nivel de entrada. Mientras est conectado a una instalacin Sybase local, el usuario puede enviar una instruccin SQL CONNECT TO, llamando a un servidor remoto que es conocido por el servidor local. Por ejemplo, si un servidor remoto denominado SISTEMACENTRAL contiene una copia de la base de datos de ejemplo, entonces la instruccin ser:
CONNECT TO SI5TEMACENTRAL
Servidor local
Servidor remoto
"
;;:' :;-;:=::;"~ ~l:----:--I

~
lPcI l!-0ca:J
Consult, []GBD
SOL
I----.~
~
[]GBD
Solicitud cliente!
1----...
s."'idO"~ Lpc ~
--o
Resultados
Base de datos local
Base de datos remota
Hace del servidor remoto el servidor actual para la sesin. El servidor local introduce un modo de paso a travs, enviando todas las instrucciones SQL al servidor remoto. Ahora se puede procesar la base de datos remota directamente sobre la conexin, con consultas estndar sin modificar e instrucciones de manipulacin de datos:
Figura 23.2.
Solicitud de acceso a un servidor remoto de bases de datos.
Obtener los nombres y ventas de IOdos los vendedores que ya estn por encima de la cuota.
S04
Captulo 23: Redes SaL y bases de datos distribuidas
S05
SELECT NOMBRE, CUOTA, VENTAS FROM REPRESENTANTES WHERE VENTAS > CUOTA
to con un vnculo de la base de datos denominado SISTEMACENTRAL. Esta instruccin SQL recupera informacin de la tabla REPRESENTANTES remota:
Cuando se completa el acceso remoto, una instruccin SQL acompaante:

DISCONNECT
Obteller los nombres y ventas de todos los vendedores que ya hall superado la cuota.
SELECT NOMBRE, CUOTA, VENTAS FROM REPRESENTANTES@$ISTEMACENTRAL WHERE VENTAS > CUOTA
,I
finaliza el modo de paso a travs y el servidor local se convierte de nuevo en el servidor actual. Ex.cepto por el par CONNECT/DISCONNECT, el mecanismo para la gestin del acceso remoto es externa al lenguaje SQL. El administrador de la ba~ se de datos indica a la base de datos local sobre la existencia, ubicaciones y nombres de los servidores remotos mediante los procedimientos almaceI).ados del sistema spaddserver () y spdropserver (). El nombre y contrasea del usuario local actual se utilizan de forma predeterminada para el acceso al servidor remoto. De forma alternativa, el administrador de la' base de datos puede especificar un nombre/contrasea de usuario proxy que se utiliza para el acceso a servidores remotos, de f1uevo mediante los procedimientos almacenados de sistema. Syb~se ofrece otras capacidades para bases de datos distribuidas ms complejas, pero1a capacidad bsica tiene la ventaja de la mxima simplicidad. .' Oracle adopta un enfoque ligeramente diferente al de acceso a las bases de datos remotas, pero es similar a las capacidades proporcionadas por otras marcas SGBD. Requiere que el software de red SQL*Net de Oracle est instalado junto con Oracle SGBD en los sistemas local y remoto. El administrador de la base de datos es responsable de establecer uno o ms vnculos con la base de datos con nombre de la base de datos local o bases de datos remotas. Cada vnculo con la base de datos especifica: La ubicacin de la red del sistema informtico remoto objetivo. Protocolo de comunicaciones a utilizar. Nombre de la base de datos Oracle en el servidor remoto. Nombre y contrasea de usuario para la base de datos remota.
Oracle incorpora casi todas las capacidades de consulta que estn disponibles para la base de datos en bases de datos remotas. La nica restriccin es que toda entidad de la base de datos remota (tabla, vista, etc.) debe estar con el sufijo del vnculo de-la base de datos. Veamos una reunin de dos tablas ejecutada en la base de datos Gracle remota:
Obtener los nombres y ciudades de las oficinas de rodas los Ilelldedores que ya han superado la cuota.
SELECT FROM WHERE AND NOMBRE, CIUDAD, CUOTA, VENTAS REPRESENTANTES@$ISTEMACENTRAL, VENTAS > CUOTA OFICINA_REP : OFICINA OFICINAS@SISTEMACENTRAL
Oracle tambin incorpora la definicin de datos y las operaciones de actualizacin llevadas a cabo en la base de datos remota. Veamos un ejemplo:
Crear una nueva tabla remota con informacin sobre el mayor lmite de crdi ro en la base de daros y rellenarla con los datos de la tabla CLIENTES.
CREATE TABLE MEJORCLIENTE@SISTEMACENTRAL (NUM_CLI INTEGER NOT NULL, EMPRESA VARCHAR(20) NOT NULL, REP~NOMBRE VARCHAR(15)l INSERT INTO SELECT FROM WHERE AND MEJORCLIENTE@SISTEMACENTRAL NUM_CLI, EMPRESA, NOMBRE CLIENTES@SISTEMACENTRAL, REPRESENTANTES@SISTEMACENTRAL LIMITE_CREDITO > 50000.00 REP_CLI : NUM_EMPL
Todos los accesos a la base de datos remota se producen a travs del vnculo con la base de datos y estn gobernados por los privilegios del nombre de usuario proporcionado en el sistema remoto. El vnculo a la base de datos incorpora por ello las respuestas a qu base de datos, cmo comunicarse y qu privilegios que surgieron previamente en esta seccin. El administrador de la base de datos asigna un nombre al vnculo de la base de datos. Los vnculos pueden ser privados (creados para el uso de un usuario especfico del sistema local) o pblicos (disponibles para varios usuarios del sistema local). Para acceder a una base de datos remota con un vnculo, el usuario del sistema local utiliza instrucciones SQL estndar. El nombre del vnculo de la base de datos est agregado a las tablas remotas y los nombres de las vistas, seguidas de un signo (@). Por ejemplo, consideremos que estamos en un sistema informtico 10c~1 que est conectado a una copia de la base de datos de ejemplo en un sistema remo-
Universal Server de Informix proporciona capacidades que son similares a las ofrecidas por Oracle, pero utiliza un mecanismo diferente para identificar las bases de datos remotas y una extensin de sintaxis SQL diferente. La arquitectura Informix diferencia entre un servidor de bases de datos remoto y una base de daros remota que est gestionada por el servidor remoto, puesto que tiende a proporcionar un rico soporte para mltiples bases de datos con nombre por servidor. Supongamos una copia Informix de la base de datos de ejemplo que se denomina EJEMPLO y que reside en un servidor de base de datos remoto denominado SISTE-
806
807
MACENTRAL. Entonces esta consulta es equivalente a los ejemplos anteriores de Ocaele y Sybase:
Con este sinnimo, el nombre de columna calificado anterior se vuelve muy sencillo:
REPS_REMOTOS.NOMBRE
Obtener los nombres y ventas de todos los vendedores que ya Izan superado la cuota.
SELECT NOMBRE, CUOTA, VENTAS FROM EJEMPLO@SISTEMACENTRAL;REPRESENTANTES WHERE VENTAS > CUOTA
El nombre de la base de datos aparece al comienzo del nombre de la base de datos (as como un calificativo adicional antes del punto). Si la base de datos es remota, entonces el nombre del servidor aparece siguiendo al signo (@) despus del nombre de la base de datos.
Transparencia de los datos remotos
Con cualquiera de los convenios de nombres de bases de datos remotas que extienden los nombres de las tablas y vistas SQL usuales, los calificadores adicionales se pueden convertir rpidamente en molestos o confusos. Por ejemplo, si dos tablas de la base de datos remota tienen columnas con los mismos nombres, cualquier consulta que afecta a ambas tablas debe utilizar nombres de columnas calificados (y los calificadores de los nombres de tablas tienen ahora tambin una calificacin de la base de datos). A continuacin se muestra el nombre de tabla calificado en Informix para la columna NOMBRE de la tabla REPRESENTANTES remota del usuario JUAN en una base de datos remota denominada EJEMPLO en el servidor remoto Infonnix SISTEMACENTRAL:
EJEMPLO@SISTEMACENTRAL.JUAN.REPRESENTANTES.NOMBRE
Cualquier consulta que haga referencia a la tabla REPS_REMOTOS y a sus columnas es realmente una consulta a una base de datos remota, pero ese hecho es transparente al usuario. En la prctica la mayora de las instalaciones de bases de datos accedern frecuentemente a tablas remotas que tendrn un conjunto de sinnimos definidos. La mayora de las marcas SGBD incorporan sinnimos pblicos (disponibles a todos los usuarios) y sinnimos privados que se crean para un usuario especfico o grupo de usuarios. Con esta estructura, los sinnimos se pueden convertir en una parte adicional del mecanismo de seguridad de acceso remoto, limitado a aquellos usuarios con una necesidad real de acceso remoto. Varias marcas de SGBD adoptan los sinnimos para el acceso a bases de datos transparentes un paso ms all y permiten las vistas en la base de datos local que estn definidas en funcin de las tablas de la base de datos remota. Veamos una definicin de vista Gracle que crea una vista denominada REPS_ESTE en la base de datos local. La vista es un subconjunto de informacin de la base de datos remota de ejemplo: Crear una vista local definida en funcin de dos tablas remotas.
CREATE VIEW SELECT FROM WHERE AND REPS_ESTE AS NUM_EMPL, NOMBRE, EDAD, CIUDAD REPRESENTANTES@SISTEMACENTRAL, OFICINAS@SISTEMACENTRAL OFICINA_REP = OFICINA OFICINA_REP BETWEEN 11 AND 19
Una nica referencia a una columna ha crecido a media lnea de texto SQL! Por esta razn se utilizan frecuentemente los alias a tabla en las instrucciones SQL que conllevan un acceso a bases de datos remotas. Los sinnimos y los alias (descritos en el Captulo 16) tambin son muy tiles para proporcionar acceso ms transparente a las bases de datos remotas. Veamos una definicin de sinnimo Informix que se podra establecer por un usuario o administrador de una base de datos:
CREATE SYNONYM REPS_REMOTOS FOR EJEMPLO@SISTEMACENTRAL.JUAN.REPRESENTANTES
La definicin equivalente de sinnimo Oracle es:

CREATE SYNONYM REPS_REMOTOS FOR JUAN.REPRESENTANTES@SISTEMACENTRAL
Despus de que se haya definido esta vista, un usuario puede plantear consultas en funcin de la vista REPS_ESTE, sin preocuparse por los vnculos con la base de datos o los nombres de las tablas remotas. La vista no solamente proporciona acceso remoto transparente, sino que tambin oculta al usuario la operacin de reunin remota entre las tablas OFICINAS y REPRESENTANTES. El acceso transparente a los datos remotos, proporcionado por las vistas y los sinnimos, se considera usualmente una caracterstica muy deseable. Tiene un inconveniente, no obstante. Debido a que el aspecto remoto de acceso a la base de datos est ahora oculto, la sobrecarga de la red creada por el acceso tambin est oculta. Por consiguiente, aumenta la posibilidad de que un usuario O programador cree inadvertidamente una gran cantidad de trfico de red debido a consultas muy grandes. El administrador de la base de datos debe plantearse esta posibilidad cuando decida si permitir o no los sinnimos y las vistas transparentes remotas. El acceso remoto transparente tambin genera inevitablemente una pregunta adicional: puesto que las tablas remotas ahora aparecen como si fueran locales, puede el usuario plantear consultas que afecten a tablas remotas y locales? Esto es, puede una reunin cruzar las fronteras del servidor de bases de datos y relacionar informacin de la base de datos remota y la base de datos local? Se plantean
808
809
preguntas incluso ms serias cuando se considera el esquema de las transacciones SQL. Si una base de datos permite el acceso transparente a una base de datos remota, tiene permiso un usuario de actualizar una fila en la base de datos local e insertar una fila en la base de datos remota, y entonces decidir deshacer la transaccin? Puesto que los recursos remotos se han formado para que aparezcan como si fueran locales parece que la respuesta debera ser: Por supuesto, las bases de datos local y remota deberan aparecer como si fueran solamente una base de datos local e inlegrada. En realidad, admitir tales consultas y transacciones distribuidas agrega un nuevo e importante grado de complejidad (y potencialmente una enorme sQbrecarga de transmisin de datos a travs de la red) al acceso remoto. Debido a esto, aunque varios SOBD comerciales admiten las consultas y transacciones distribuidas, no se usan masivamente en la prctica. Estas capacidades y sus implicaciones se analizan en detalle en la seccin Acceso a bases de datos distribuidas. La siguiente seccin plantea una alternativa prctica -duplicacin de datos o rplica de la base de datosque se utiliza mucho ms frecuentemente.
Servidor central
SGBD
Extractos de tablas
EJ B~
GBD
Base de datos esclava
Base de datos
maestra
o'
Y ""
Insercin! actualizacin! consulta
Se",do,
satlite
~;I_EJI
OD
esclavall
'f'~_"":::::"
El acceso remoto a la base de datos es muy conveniente para consultas remotas pequeas y un acceso ocasional a la base de datos remota. Si una aplicacin requiere un acceso masivo y frecuente a una base de datos remota, la sobrecarga de comunicaciones del acceso remoto a la base de datos puede llegar a ser grande. Una vez que el acceso remoto crece por encima de un cierto punto. es frecuentemente ms eficiente mantener una copia local de los datos remotos en la base de datos local. Muchos de los fabricantes de SGBD proporcionan herramientas para simplificar el proceso de la extraccin y distribucin de datos. En su forma ms simple, el proceso extrae el contenido de una tabla en una base de datos principal, lo enva a travs de una red a otro sistema y lo carga en una tabla rplica corres~ pondiente en una base de datos esclava, como se muestra en la Figura 23.3. En la prctica, el extracto se ejecuta peridicamente y durante periodos de baja actividad en la base de datos. Este enfoque es muy apropiado cuando los datos de la tabla reproducida cambian lentamente o cuando los cambios en la tabla ocurren de foona natural en un procesamiento por lotes. Por ejemplo, supongamos que algunas tablas de la base de datos de ejemplo, ubicada en un sistema de computadora central remota, se van a reproducir en una base de datos local. Los contenidos de la tabla OFICINAS rara vez cambian. Sera un excelente candidato para la rplica en un centro de distribucin o bases de datos para la automatizacin del equipo de ventas. Una vez que" las tablas reproducidas (locales) iniciales se establecen y rellenan, podra necesitarse actualizarlas solamente una vez por mes, o cuando se abre una nueva oficina de ventas. La tabla PRODUCTOS tambin es un buen candidato para la rplica. Los cambios en los precios de los productos se dan ms frecuentemente que los cambios de oficinas, pero en la mayora de las compaas suceden en lotes, quizs una
~
Slo lectura
---="11; Base de datos Tablas
Slo lectura
Figura 23.3.
Arquitectura bsica replicada maestro/esclavo.
vez a la semana o una vez al da. Con este ciclo de procesamiento natural, podra ser muy efectivo extraer una tabla con los datos del precio de los productos justo despus de cada lote de actualizaciones y enviarlo a las bases de datos del centro de distribucin y la base de datos central de automatizacin del equipo de ventas. Los datos de los precios en estas bases de datos no tienen que estar vinculados estrechamente a la base de datos del gran sistema para asegurar que son frescos. Un ciclo semanal o diario para la extraccin/actualizacin har que los datos estn como los actuales, con un procesamiento de carga de trabajo menos sustancial. Es posible implementar este tipo de estrategia de tablas reproducidas sin ningn soporte de SGBD. Se podra escribir una aplicacin que utilizara SQL en el gran sistema para extraer los datos de los precios de los productos en un archivo. Un programa de transferencia de archivos podra transmitir el archivo a los centros de distribucin, donde otra aplicacin podra leer sus contenidos y generar las instrucciones apropiadas DROP TABLE, CREATE TABLE e INSERT para rellenar la tabla reproducida.
810
811
El primer paso hacia la automatizacin de esta estrategia fue el desarrollo de programas de extraccin de datos y de carga de datos. Estos programas de utilidades, ofrecidos por los fabricantes de SGBD, utilizan normalmente tcnicas de acceso a las bases de datos propietarias, de bajo nivel, para extraer y cargar los datos mucho ms rpidamente que mediante las instrucciones de SQL SELECT e INSERT. Ms recientemente, las compaas de software han encontrado esta rea como una oportunidad para paquetes de software autnomos, independientes de los fabricantes de SGBD. Esta categora de software, denominada software para la integracin de aplicaciones de la empresa (Enterprise Applicalion /ntegralion, EAI), se centra en la vinculacin de sistemas informticos dispares, paquetes de software, sistemas de bases de datos y formatos de archivos. La vinculacin de diferentes SOSD es una pequea parte de la solucin total ofrecida por estos sistemas, que se personalizan de forma extensiva para cumplir las necesidades individuales de una compaa cuando se instalan. Los sistemas EAI ofrecen normalmente una interfaz de usuario grfica para especificar la extraccin de datos, una serie de herramientas para volver a dar formato a los datos entre los sistemas origen y destino, una capacidad de mensajes para transmitir los datos, quizs una capacidad de almacenamiento y envo de los datos extrados por parles antes y despus de la transmisin, y utilidades para gestionar y sup~rvjsar el proceso completo.
de datos Gracle establece estos vnculos en la base de datos remota como parte de las capacidades Oracle distribuidas que se requieren para utilizar la instantnea. Finalmente, la instruccin CREATE SNAPSHOT har que la tabla de instantneas local PRECIOPROD se rellene con los datos de la tabla remota PRODUCTOS. Con este tipo de instantnea de slo lectura, no se permite a los usuarios cambiar la tabla de instantneas con las instrucciones INSERT, UPDATE O DELETE. Todas las actualizaciones de la base de datos se producen en la tabla principal (remota) y se propagan a la tabla reproducida (instantnea) mediante Grade. El administrador de la base de datos puede actualizar de forma manual la tabla instantnea cuando lo desee. La instruccin CREATE SNAPSHOT tambin incluye capacidades muy completas para especificar las actualizaciones automticas. Veamos algunos ejemplos:
Crear una rplica local de los precios desde la labla remola PRODUCTOS. Actualizar los datos una vez a la semana, con una recarga completa de los datos.
CREATE SNAPSHOT PRECIOPROD REFRESH COMPLETE START WITH SYSDATE NEXT SYSDATE+7 AS SELECT ID_FAS, ID_PRODUCTO, PRECIO FROM PRODUCTOS@VINCULO_REMOTO
Rplica de tablas
Varios fabricantes de SGBD han avanzado ms all de sus programas de extraccin y carga para ofrecer soporte para la extraccin de tablas en el propio SGBD. Drade, por ejemplo, ofrece una utilidad de instantneas para crear de forma automtica una copia local de una tabla remota. En su forma ms sencilla, la tabla local es una rplica de slo lectura de la tabla remota principal, la cual se actualiza automticamente y de forma peridica por el SGBD de Oracle. Veamos una instruccin Oracle SQL para crear una copia local de los precios de los productos, partiendo de que la base de datos remota principal incluye una tabla PRODUCTOS como la de Ja base de datos de ejemplo:
Crea una rplica local de los precios desde la tabla remota PRODUCTOS. Actualizar los datos una vez al da, enviando solamente los cambios desde la tabla principal.
CREATE SNAPSHOT PRECIOPROD REFRESH FAST START WITH SYSDATE NEXT SYSDATE+l AS SELECT ID_FAS, ID_PRODUCTO, PRECIO FROM PRODUCTOS@VINCULO_REMOTO
Crear una rplica local de la informaci6n de precios de la tabla

CREATE SNAPSHOT PRECIOPRQD AS SELECT ID_FAS, ID_PRODUCTO, PRECIO FROM PRODUCTOS@VINCULO_REMOTO
PRODUCTOS.
Esta instruccin crea de forma efectiva una tabla local Oracle denominada PREContiene tres columnas, especificadas por la instruccin SELECT de la base de datos remola (principal). El signo arroba y el nombre VINCULO_REMOTO en la instruccin indican a Orade que la tabla PRODUCTOS, de la cual se van a reproducir los datos es una tabla remota, est accesible mediante el vnculo a la base de datos Oracle denominada VINCULO_REMOTO. El administrador de la base
CIOPROD.
En el ejemplo anterior, la instantnea se actualiza transmitiendo solamente los cambios de la tabla remota PRODUCTOS. Orac1e implementa esta capacidad manteniendo un registro histrico de los cambios (un registro histrico instantnea) en el sistema remoto y actualizando el registro histrico cada vez que la actualizacin de la tabla PRODUCTOS afecte a la rplica instantnea. Cuando llega la hora de una actualizacin, se utiliza la informacin del registro histrico instantnea. Para aplicaciones como sta, en que los cambios en los precios de los productos probablemente afeclan slo a un pequeo porcentaje de la tabla global, esta estrategia es efectiva. La sobrecarga adicional del mantenimiento del registro histrico para la tabla principal est ms que compensada por el trfico reducido de la red por la transmisin de nicamente los datos cambiados. En otras aplicaciones, donde se modificarn entre actualizaciones un gran porcentaje de las filas en la tabla principal, puede ser ms eficaz realizar simplemente una actualizacin completa y eliminar la sobrecarga derivada de mantener el registro histrico de instantneas. De forma predeterminada, Gracle identifica las filas (para detenninar si han cambiado) basndose en sus claves principales. Si la clave principal no fonna parte de los datos reproducidos, se puede producir confusin en cuanto a qu filas se han actualizado; en este caso Gracle utiliza un nmero de identificacin de columnas
812
813
interno con el fin de identificar las filas modificadas para su actualizacin en la instantnea. La instruccin SELECT que define la tabla instantnea ofrece una capacidad muy general para la extraccin de datos. Puede incluir una clusula SELECT para extraer solamente las filas de la tabla principal:
sultas da a da sobre los datos de las instantneas se llevan a cabo localmente y no generan trfico de red. Para situaciones en que la carga de trabajo de la consulta sea mucho mayor que los costes de mantenimiento de la instantnea, sta puede ser una forma efectiva de mejorar el rendimiento global de la base de datos.
Crear una rplica local de los precios de los productos de alto precio a partir de la tabla remora PRODUCTOS. Actualizar los datos una vez al dia, enviando solamente los cambios de la tabla principal.
CREATE SNAPSHOT PRECIOPROD REFRESH FAST START WITH SYSDATE NEXT SYSDATE+l AS SELECT ID_FAS, ID_PRODUCTO, PRECIO FROM PRODUCTOS@VINCULO_REMOTO WHERE PRECIO> 1000.00
Rplicas actualizables
En las implementaciones ms sencillas, una tabla y sus rplicas tienen una relacin maestro/esclavo estricta, como se muestra en la Figura 23.3. La copia maestra central contiene los datos reales. Siempre est actualizada y todas las actualizaciones de la tabla deben ocurrir en esta copia de la tabla. Las otras copias esclavas se rellenan mediante actualizaciones peridicas, gestionadas por SOBD. Entre las actualizaciones, pueden estar ligeramente desfasadas, pero si la base de datos se configura de esta fonna, es un precio aceptable por la ventaja de tener una copia local de los datos. Las actualizaciones de las copias esclavas no estn permitidas. Si se intenta, el SOBD devuelve un error. De forma predeterminada, la instruccin de Oracle CREATE SNAPSHOT crea este tipo de rplica esclava de una tabla. La relacin maestro/esclavo est implcita en la estructura Microsoft SQL Server para la rplica. La arquitectura del servidor SQL define el maestro como el publicador de los datos, y los esclavos como los suscriptores de los datos. En la configuracin predeterminada hay un nico publicador (actualizable), y puede haber varios suscriptores (de slo lectura). La arquitectura SQL Server lleva esta analoga un paso ms all, incorporando la nocin de actualizaciones de insercin (el publicador enva de forma activa los datos actualizados a los suscriptores) y actualizaciones de extraccin (donde los suscriptores tienen la responsabilidad principal de obtener actualizaciones del publicador). Hay algunas aplicaciones para las cuales la rplica de tablas es una tcnica excelente, pero en las que no se aplica la relacin maestro/esclavo. Por ejemplo, las aplicaciones que demandan una alta disponibilidad utilizan tablas replicadas para mantener copias idnticas de los datos en diferentes sistemas informticos. Si un sistema falla, los otros contienen los datos en curso y pueden continuar el procesamiento. Una aplicacin para Internet puede demandar velocidades de acceso a la base de datos muy altas, y logra esta escalabilidad reproduciendo una tabla muchas veces en diferentes sistemas informticos y dividiendo la carga de trabajo entre los sistemas. Una aplicacin de automatizacin del equipo de ventas contendr probablemente una tabla central CLIENTE y cientos de rplicas en los sistemas informticos porttiles, y los vendedores deberan poder introducir nuevos clientes o cambiar la informacin de contacto de un cliente en las rplicas de la computadora porttil. En estas configuraciones (yen otras) el uso ms eficiente de los recursos de la computadora se logra si todas las rplicas pueden aceptar actualizaciones a la tabla, como se muestra en la Figura 23.4. Una tabla reproducida en la que varias copias pueden aceptar actualizaciones crea un nuevo conjunto de temas sobre la integridad de los datos. Qu sucede si se actualiza la misma fila de una tabla en una o ms rplicas? Cuando el SOBD intenta sincronizar las rplicas, cul de las de las 40s actualizaciones de las rpli-
Obsrvese que esto hace que el mantenimiento del registro histrico de instantneas sea ms complejo. Oracle no necesita agregar al registro histrico todas las actualizaciones de la tabla PRODUCTOS; solamente aquellos que modifican la! filas que cumplen el criterio de bsqueda. La instantnea tambin se puede crear como una tabla de reunin, extrayendo sus datos de dos o ms tablas principaes en la base de datos remota:
Crear una rplica local de los datos de un vendedor, actualizada semanalmente.

CREATE SNAPSHOT EQUIPOVENTAS REFRESH FAST START WITH SYSDATE NEXT SYSDATE+7 AS SELECT NOMBRE, CUOTA, VENTAS. CIUDAD PROM REPRESENTANTES@REMOTO, OFICINAS@REMOTO WHERE OFICINA_REP : OFICINA
Aadiendo algo de complejidad, la instantnea se puede definir con una consulta de agrupacin:
Crear un resumen local del volumen de pedidos de los clientes, actualizado diariamente.
CREATE SNAPSHOT PEDCLIENTES REFRESH FAST START WITH SYSDATE NEXT SYSDATE+l AS SELECT EMPRESA, SUM(IMPORTE) FROM CLIENTES@REMOTO, PEDIDOS@REMOTO WHERE CLIENTE = NUM_CLI
Por supuesto, con cada grado adicional de complejidad, la sobrecarga en la gestin de la instantnea y el proceso de rplica aumenta. Sin considerar lo sencilla o compleja que sea la definicin de la instantnea, los principios generales son los mismos. En lugar de tener consultas sobre los datos reproducidos viajando a travs de la red hacia la base de datos remota, los datos remotos se toman de la instantnea. Las actualizaciones sobre la instantnea todava generan trfico de red, pero las con-
l.
814
815
Servidor central
SGBD
Base de datos
central
~~l;;~~F:::J actualizacin! Insercin}

=consulta
Base de datos
en un porttil
o
)
Insercinl actualizacinl
consulta
CLIENTES
Rplica
C "jo.,r"L.:.IENT=.:.E':"?1.L . Insercinl
-1:::;;=::::;;;;;
bidireccional
L----"'rr~ actualizacin! consulta
Figura 23.4.
Rplicas con varios sitios actualizados.
cas se debera aplicar?, no se debera aplicar ninguna, o deberan aplicarse ambas? Qu sucede si una fila se borra en una copia de la tabla, pero se actualiza en otra copia de la tabla? En los SGBD que admiten rplicas actualizables, estos temas se solucionan creando un conjunto de reglas de resolucin de conflictos que se aplican en el sistema de rplicas. Por ejemplo, cuando la rplica se establece entre una tabla central CLIENTE y versiones porttiles de la tabla, la regla de rplica puede decir que los cambios en la base de datos de clientes central siempre ganan sobre los cambios introducidos en un sistema porttiL De forma alternativa, la regla de la rplica podra decir que las actualizaciones ms recientes siempre ganan. Adems de las reglas incorporadas proporcionadas por SGBD, la definicin de la rplica puede incluir la capacidad de pasar conflictos a un procedimiento escrito por el usuario (como un procedimiento almacenado en la base de datos) para la seleccin del vencedor y el perdedor de las rplicas.
Compromisos de las rplicas

Las estrategias prcticas de las rplicas siempre conllevan un compromiso entre el deseo de mantener los datos lo ms actualizados posible y el de mantener el trfico de red bajo desde el punto de vista prctico y proporcionar as un rendimiento ade~
cuado. Este compromiso normalmente conlleva no slo consideraciones tcnicas, sino tambin prcticas, as como directrices del negocio. Por ejemplo, consideremos una aplicacin de procesamiento de pedidos que utiliza la base de datos de ejemplo y partamos de que el procesamiento de pedidos se distribuye entre cinco centros de llamada diferentes que estn geogrficamente repartidos alrededor del mundo. Cada centro de llamada tiene su propio sistema informtico y sus bases de datos. Los pedidos entrantes se comprueban con la tabla PRODUCTOS para asegurar que el inventario permite formular el pedido. La tabla PRODUCTOS sigue el stock de los productos para todos los establecimientos de la compaa, en todo el mundo. Supongamos que la directiva de la compaa es que el oficinista que procesa el pedido debe poder garantizar de forma absoluta a un cliente que los productos se pueden enviar en 24 horas despus de que se acepte el pedido. En este caso, la tabla PRODUCTOS debe contener de forma absoluta los datos actualizados al minuto, reflejando el impacto en el inventario de los pedidos tomados solamente segundos antes. Hay solamente dos posibles diseos para la base de datos en este caso. Podra haber una nica copia central de la tabla PRODUCTOS, compartida por todos los usuarios en las cinco ubicaciones de procesamiento de pedidos. De forma al~ ternativa, podra haber una copia imagen completa de la tabla PRODUCTOS en cada uno de Jos cinco sitios. La solucin de la imagen completa es, casi seguro, poco prctica, puesto que la actualizacin de la tabla PRODUCTOS cada vez que se toma un pedido provocar un trfico de red excesivo para mantener las cinco copias de la tabla con una sincronizacin perfecta. Por otra parte supongamos que la compaa cree que puede mantener una satisfaccin adecuada del cliente con una poltica un poco menos estricta (por ejemplo, promete notificar a cualquier cliente en 24 horas si el pedido no se puede rellenar inmediatamente y darle la posibilidad de cancelar el pedido. En este caso, una tabla reproducida PRODUCTOS es una solucin excelente. Una vez al da se puede actualizar la tabla PRODUCTOS descargando una copia en cada uno de los cinco sitios. Durante el da, los pedidos se verifican en la copia local de la tabla PRODUCTOS, pero solamente se actualiza la tabla PRODUCTOS local. Esto evita que la compaa tome un pedido para el cual no hay un stock adecuado al comienzo de la maana, pero no evita que se anoten pedidos en dos o tres sitios distintos que excedan del stock disponible. La siguiente noche, cuando los costes de comunicacin de datos son menores que durante el da, los pedidos de cada sitio se transmiten a un sitio central que los procesa utilizando una copia de la tabla PRODUCTOS. Los pedidos que no se pueden completar debido al inventario se marcan y se genera un informe. Cuando el procesamiento est completo, la tabla actualizada PRODUCTOS, junto con el informe de los pedidos problemticos, se transmite a cada uno de los cinco sitios para preparar el procesamiento del siguiente da. Cul es la arquitectura correcta para asumir la operacin de este negocio global? Como el ejemplo muestra, no es tanto una cuestin de la arquitectura de la base de datos como una cuestin de la poltica del negocio. La interdependencia de las arquitecturas de los sistemas informticos y las operaciones del negocio es una de las razones de que las decisiones sobre la reproduccin y la distribucin de datos hagan que unos tipos de operaciones del negocio sean ms sencillos y otros ms complicados.
816
817
Arquitecturas normales de rplica

En muchos casos es posible estructurar una aplicacin que implique a los datos reproducidos de forma que los conflictos entre las actualizaciones de la rplica se eviten o se minimicen en gran medida. Las reglas de resolucin de conflictos en el SOBO se aplican entonces como ltimo intento. cuando el conflicto se da 'Iugar a pesar del diseo de la aplicacin. Las siguientes secciones describen algunos esce narios de tablas reproducidas normales y la estructura de aplicacir que se utiliza frecuentemente en cada escenario con el fin de minimizar los conflictos de rplicas.
/'
Subconjuntos de tablas horizontales

Una forma eficiente de reproducir partes de una tabla a travs de una red es dividir la tabla de forma horizontal, ubicando diferentes filas de la tabla en sistemas diferentes. La Figura 23.5 muestra un ejemplo sencillo que indica la utilidad de la divisin horizontal de una tabla. En esta aplicacin una compaa opera en tres centros de distribucin, cada uno con su propio sistema informtico y SGBD para gestionar una base de datos inventario y el procesamiento de pedidos. Tambin se mantiene una base de datos central orientada a la planificacin de la produccin.
Para asumir este entorno, la tabla PRODUCTOS se divide de forma horizontal en tres partes y se expande para ubicar una columna UBICACION que dice dnde est situado el inventario. La copia central de la tabla contiene todas las filas. Las filas de la tabla que describen el inventario en cada centro de distribucin se reproducen en la base de datos local gestionada por el SGBD del centro. En este caso, la mayora de las actualizaciones de la tabla PRODUCTOS tienen lugar en el mismo centro de distribucin, puesto que, procesa los pedidos. Debi do a que las rplicas del centro de distribucin son mutuamente excluyentes (esto es, una fila de la tabla PRODUCTOS aparece en slo una rplica del centro de distribucin), se evitan los conflictos de actualizacin. Las rplicas en el centro de distribucin pueden transmitir actualizaciones de forma peridica a la base de datos central para mantenerla actualizada.
Subconjuntos de tablas verticales

Otra fonna eficaz de gestionar la rplica de la tabla es dividir la tabla verticalmente y reproducir diferentes columnas de la tabla en diferentes sistemas. La Figura 23.6 muestra un ejemplo sencillo de una divisin vertical de la tabla. La tabla REPRESENTANTES se ha expandido para incluir nuevas columnas de infannacin personal (nmero de tel-
Castefln
Fl3
111111111111
'.
Tabla PRODUCTOS
I I I I
-1:11I11I 11I11I
-r-
Navarra
-,
---.-111I11I 11I11I
Sistema personal
Sistema de procesamiento de pedidos

I
-1-
11I11I 11I11I
Daimiel
=E
111111111111
Figura 23.5.
Reproduccin de trozos horizontales de una tabla.
Figura 23.6.
Rplica de trozos verticales de una tabla.
818
819
fono, estado civil, etc.) y su informacin es necesaria en dos bases de datos (una en el departamento de procesamiento de pedidos y la otra en el departamento de personal). La mayor parte de la actividad en cada departamento se centra en una o dos columnas de la tabla, pero muchas consultas e informes utilizan las columnas relacionadas con la informacin personal y las columnas relacionadas con los pedidos. Para acomodar esta aplicacin se reproduce la tabla REPRESENTANTES en ambos sistemas, pero conceptualmente se divide verticalmente en dos trozos. Las columnas de la tabla que almacenan datos personales (NOMBRE, EDAD, FECHA_CONTRATO, TELEFONO, CASAOO) pertenecen al sistema de personal, que gana en cualquier conflicto relacionado con las actualizaciones en estas columnas. El resto de colu~S (NUM~EMPL, CUOTA, VENTAS, OFICINA_REP) pertenecen al sistema de procesamiento de pedidos, que gana en los conflictos de actualizacin relacionados con estas columnas. Debido a que toda la tabla est reproducida en ambos sistemas, se puede utilizar cualquier sistema para generar informes y gestionar consultas sobre la marcha, y todas se pueden procesar de forma local. Solamente las actualizaciones vinculadas al mecanismo de rplica generan trfico de red y potencialmente requieren una resolucin de conflictos.
Tablas con espejo
-Sistema A
Copias
11I11I 11I11I ~~
de la tabla X
-Sistema B
11I11I 111111
Cuando se utiliza la reproduccin de tablas para lograr una alta disponibilidad (esto es, resistencia al fallo de la computadora o de la base de datos), toda la tabla est normalmente con espejo, como se muestra en la Figura 23.7. La forma ms sencilla de implementar esta .configuracin es que un sistema sea el sistema activo, y el otro, una espera en calIente. En este esquema todo el acceso a la base de datos fluye normalmente al sistema activo (sistema A), que reproduce cualquier actualizacin al sistema en espera (sistema B). Solamente en el caso de un error del sistema el. acceso a la base de datos se cambia al sistema en espera,_ que tiene datos actualIzados. La desventaja de este esquema es que malgasta el sistema informtico en espera baj? operacin normal. Es necesario pagar y mantener el sistema, pero no agrega runguna capacidad de procesamiento. Por esta razn, los sistemas de alta disponibilidad se disean frecuentemente para que tambin proporcionen equilibrio de carga, como se muestra en la Figura 23.8. En esta configuracin, algn software frontal intercepta las solicitudes de a~ceso al ~GBD y las distribuye equitativamente entre los dos (o ms) sistemas mformtIcos. En una operacin normal. ambos (todos) sistemas contribuye? a la capacid~d de procesamiento de los dat?s; no se malgasta ninguno. Ade. mas, es ms fcIl conce~tualmente hacer crecer la capacidad de procesamiento de los datos agregando Simplemente ms sistemas informticos con una copia de la tabla reproducida. Este tipo de enfoque de tablas con espejo puede ser muy efectivo si el factor de las consultas en la bas~ de datos es muy alto (por ejemplo, 95 por ciento de acces.os d.e lectura I 5 por ciento de accesos de actualizacin). Si el porcentaje de actuah~ac~on~s es may~r~ el potencial d~. conflictos y sobrecargas para la rplica puede dls~~ulr la efectividad y escalabilIdad de la configuracin global. La eficiencia tamblen decr~ce con cada aumento en el nmero de sistemas reproducidos, puesto que aumenta la sobrecarga para la rplica.
Tabla X
Figura 23.7.
Rplica de tabla con espejo.
"
Una forma comn de obtener mayor eficiencia de una configuracin de tabla con espejo corno la de la Figura 23.8 es dividir las actualizaciones de la base de datos segn alguna regla. Por ejemplo, si la tabla con espejo es una tabla de clientes, la clave principal puede ser el nombre del cliente. Se puede escribir software para el equilibrio de carga de forma que las actualizaciones de nombres de clientes que comiencen con una letra entre A y M se enven a un sistema y las actualizaciones de los nombres de cliente que comienzan entre N y Z se enven al otro sistema. Esto elimina la posibilidad de conflictos entre actualizaciones. Debido a que la tabla permanece completamente reproducida bajo este escenario, las solicitudes de acceso de lectura se pueden todava distribuir de forma aleatoria entre los dos sistemas para equilibrar la carga de trabajo. Este tipo de enfoque puede ser bastante efectivo para lograr un rendimiento de la base de datos escalable con las tablas reproducidas. Puede ser bastante sencillo extender el esquema de dos caminos a un esquema de N caminos, donde las actualizaciones se dividen entre tres o ms servidores de bases de datos.
Acceso a bases de datos distribuidas

En los ltimos aos, la investigacin de acceso a bases de datos completamente distribuidas ha encontrado de forma lenta, pero segura, su camino en los produc-
820

Tabla 23.1.
821
Enfoque de cuatro estados de IBM para acceso a bases de datos distribuidas
Solicitudes de insercin/actualizacin! consulta
,..,
Estado Solicilud remola
Descripcin
Cada instruccin SQL accede a una nica base de datos remota; cada instruccin es una transaccin. Cada instruccin SQL accede a una nica base de datos remota; se admiten transacciones de mltiples instrucciones para una nica base de datos. Cada instruccin SQL accede a una nica base de dalos remola; se admiten las transacciones de mltiples instrucciones p<lTa varias bases de datos. Cada instruccin SQL puede acceder a varias bases de datos; se admiten las transacciones de mltiples instrucciones para varias bases de datos.
Servidor
frontal
Software
de distribucin de carga
Transaccin remota
~~
, I
Transaccin distribuida
I \
SGBD
A
AV
~
,,~
Solicitud distribuida
SGBD
A
c.....:::::!
'7
~
Rplica de N vas ..
:r'7
I
Tabla reproducida
reproducida
Tabla
Figura 23.8.
Rplica para el equilibrio de carga.
El esquema de IBM proporciona un modelo sencillo para definir el problema del acceso a los datos distribuidos: el usuario de un sistema informtico necesita acceder a los datos almacenados en uno o ms sistemas informticos. La sofisticacin de los accesos distribuidos aumenta en funcin del estado alcanzado. Por ello, las capacidades proporcionadas por un SOBD dado se pueden describir en funcin del estado que ha alcanzado. Adems, en cada estado, se puede realizar una distinci6n entre acceso de slo lectura (con la instruccin SELECT) y acceso de actualizaci6n (con las instrucciones IN8ERT, DELETE Y UPDATE). Un producto SOBD puede ofrecer capacidad de s6lo lectura para un estado dado antes de proporcionar una capacidad de actualizaci6n completa.
tos comerciales. En la actualidad muchos de los productos de bases de datos empresariales principales ofrecen al menos algn nivel transparente de acceso a bases de datos distribuidas. Como se observ anteriormente en la seccin Transparencia de los datos remotos, las implicaciones en el rendimiento del acceso y actualizaciones a bases de dalos distribuidas pueden ser muy sustanciales. Dos consultas que parecen muy similares pueden crear volmenes muy diferentes de trfico de red. Una nica consulta realizada con un mtodo de fuerza bruta o mediante un mtodo optimizado puede crear las mismas diferencias, dependiendo de la calidad de la optimizacin realizada por el SOBD. Debido a estos retos, todos los vendedores han adoptado un enfoque paso a paso para repartir el acceso a bases de datos distribuidas. Cuando IBM anunci por primera vez su anteproyecto para la gestin de datos distribuidos en sus productos SQL, defini un enfoque en cuatro estados. Los cuatro estados de lBM, mostrados en la Tabla 23.1, proporcionan un marco excelente para la comprensin de las capacidades de gestin de los datos distribuidos y sus implica. ciones. .
Solicitudes remotas
El primer estado de acceso a los datos distribuidos, segn defini 1BM, es una solicitud remota, segn se mu-estra en la Figura 23.9. En este estado, un usuario de PC puede enviar una instrucci6n SQL que consulte o actualice los datos en una nica base de datos remota. Cada instruccin SQL individual opera como su propia transaccin, de forma similar al modo de aUlOcompromiso proporcionado por muchos programas SQL interactivos. El usuario puede enviar una secuencia de instrucciones SQL a varias bases de datos, pero el SGBD no admite transacciones de mltiples instrucciones. Las solicitudes remotas son muy tiles cuando un usuario de pe necesita consultar datos corporativos. Normalmente, los datos requeridos estn ubicados en una nica base de datos, como una base de datos con datos para el procesamiento de pedidos o datos para la fabricacin. Mediante el uso de una solicitud remota, un programa pe puede recuperar los datos remotos para su procesamiento en una hoja de clculo, programa grfico o paquete de edicin.
'---
822
1
Sistema remoto Sistema local
823
Sistema local
Sistema remoto
Transaccin
Transaccin
Transaccin
Transaccin
{ { { {
Instruccin Transaccin
{
{
Instruccin Instruccin Instruccin Instruccin
SGSD
iI
I
1,
Instruccin
Transaccin
Sistema remoto
Instruccin
Sistema remoto
~~
::a.
SGSD
I l'
1:
Instruccin
II
Figura 23.10.
Acceso a datos distribuidos: transacciones remotas.
Figura 23.9.
Acceso a los datos distribuidos: solicitudes remotas.
La capacidad de solicitud remota no es lo suficientemente potente para la mayora de las aplicaciones de procesamiento de transacciones. Por ejemplo, consideremos una aplicacin de entrada de pedidos basada en pe. Para procesar un nuevo pedido, el programa pe debe comprobar los niveles de inventario, agregar el pedido a la base de datos, disminuir los totales en el inventario y ajustar los clientes y las ventas totales, lo que implica quizs media docena de instrucciones SQL diferentes. Como se explic en el Captulo 11, la integridad de la base de datos puede estar corrompida si estas instrucciones no se ejecutan como una nica transaccin. Sin embargo, el estado de solicitud remota no admite transacciones de mltiples instrucciones, por lo que no puede admitir esta aplicacin.
Transacciones remotas
El segundo estado del acceso a los datos distribuidos, segn defini IBM, es una transaccin remota (denominada por IBM unidad remota de trabajo), mostrada en la Figura 23.10. Las transacciones remotas extienden el estado de solicitud remota para incluir soporte para transacciones de mltiples instrucciones. Un usuario de pe puede enviar una serie de instrucciones SQL que consulten o actualicen datos en una base de datos remota, y entonces realizar o deshacer toda la serie de instrucciones corno una nica transaccin. El SGBD garantiza que toda la transaccin ser satisfactoria O fallar como una unidad, corno lo hacen las transacciones
en una base de datos local. Sin embargo, todas las instrucciones SQL que realizan la instruccin deben hacer referencia a una nica base de datos remota. Las transacciones remotas abren la puerta a las aplicaciones de procesamiento de transacciones distribuidas. Por ejemplo, en una aplicacin de procesamiento de pedidos, un programa de entrada de pedidos basado en PC puede ahora realizar una secuencia de consultas, actualizaciones e inserciones en la base de datos de inventario para procesar un nuevo pedido. El programa finaliza la secuencia de instrucciones con COMMIT o ROLLBACK para la transaccin. Las transacciones remotas requieren normalmente un SGBD (o, al menos, l gica de procesamiento de transacciones) en el PC~ as como en el sistema donde la base de datos est ubicada. La lgica de transaCClOnes de SGBD se debe exten~er por la red para asegurar que los sistemas locales .y rem.otos siempre tengan la ~I~ ma opinin sobre si se ha realizado una transaCCIn. Sm embargo, la responsabilIdad real para mantener la integridad de la base de datos permanece con el SGBD remoto. Las transaccio~es remotas tienen frecuentemente el nivel mayor de acceso a la base de datos distribuida proporcionado por las pasarelas de la base de. datos que vinculan el SGBD de un vendedor con otras marcas de SGBD. Por ejemplo, la mayora de los vendedores de bases de datos empresariales independientes (Sybase, Grade, Informix) proporcionan pasarelas de sus SGBD basados en UNIX a implementaciones DB2 de grandes sistemas de IBM. Algunos produc~~s de pasarelas van ms all de las fronteras de las transacciones remotas, permitiendo a un usuario reunir, en una nica consulta, tablas de una base de datos local con tabl~s de una base de datos remota gestionada por una marca diferente de SGBD. SIO
824
825
embargo, estas pasarelas no proporcionan (y no pueden, sin soporte del SGBD remoto) la lgica de la transaccin subyacente requerida para albergar los estados mayores de acceso distribuido segn defini IBM. La pasarela puede asegurar la integridad de las bases de datos locales y remotas de forma individual, p.eio-no pueden garantizar que una transaccin no se comprometa en una y se deshaga en otra.
Transacciones distribuidas
El tercer estado de acceso a datos distribuidos, como defini IBM, es una transaccin distribuida (en lenguaje de lB M, una unidad distribuida de trabajo), mostrada en la Figura 23.1 L En este estado, cada instruccin SQL individual todava consulLa o actualiza una nica base de datos en un nico sistema informtico remoto. Sin embargo, la secuencia de instruccin SQL en una transaccin puede acceder a dos o ms bases de datos ubicadas en sistemas diferentes. Cuando la transaccin se realiza o se deshace, el SOBD garantiza que ladas las partes de la transaccin en todos los sistemas involucrados en la transaccin se realicen o se deshagan. El SOBD garantiza especficamente que no haya una transaccin parcial, en que la transaccin se realiza en un sistema y se deshace en otro. Las transacciones distribuidas admiten el desarrollo de aplicaciones de procesamiento de transacciones muy sofisticadas. Por ejemplo, en la red corporativa de la Figura 23.1, una aplicacin de procesamiento de pedidos basada en pe puede consultar las bases de datos inventario en dos o tres servidores de centros de distri-
bucin diferentes para comprobar el inventario de un producto escaso y entonces actualizar las bases de datos para comprometer el inventario de varias ubicaciones a un pedido de un cliente. El SOBD asegura que otros pedidos simultneos no interfieran con el acceso remoto de la primera transaccin. Las transacciones distribuidas son mucho ms difciles de proporcionar que los primeros dos estados del acceso a datos distribuidos. Es imposible proporcionar transacciones distribuidas sin la cooperacin activa de los SGBD individuales involucrados en la transaccin. Por esta razn las marcas de SOBD que admiten las transacciones distribuidas casi siempre lo hacen solamente en una red homog nea de bases de datos, todas gestionadas por la misma marca de SGBD (esto es, en una red todo Oracle o todo Sybase). Un protocolo especial de transacciones, denominado protocolo de compromiso en dos fases, se utiliza para implementar transacciones distribuidas y asegurar que proporcionan el requisito todo o nada de una transaccin SQL. Los detalles de este protocolo se describen posteriormente en la seccin El protocolo de compromiso de dos fases.
Solicitudes distribuidas
El estado final del acceso a datos distribuido en el modelo IBM es una solicitud distribuida, mostrada en la Figura 23.12. En este estado, una nica instruccin SQL puede hacer referencia a tablas de dos O ms bases de datos ubicadas en diferentes sistemas informticos. El SGBD es responsable de resolver la instruccin automticamente a travs de la red. Una secuencia de instrucciones de solicitud
Sistema local
Sistema remoto
1
I
Sistema local
Sistema remoto
Transaccin
Transaccin
{ {
Instruccin Instruccin Instruccin Instruccin
{' I InSUucd6n
Transaccin Instruccin
{ In","",6n
~!,
','
Sistema remoto
:
~
Transaccin
InstruccIn
Figura 23.11.
Acceso a datos distribuidos: transacciones distribuidas.
Figura 23.12.
Acceso a los datos distribuidos: solicitudes distribuidas.
'':,
826
827
distribuida se puede agrupar como una transaccin. Como en el estado anterior de transaccin distribuida, el SGBD debe garantizar la integridad de la transaccin distribuida en todos los sistemas involucrados. El estado de solicitud distribuida no realiza ninguna nueva demanda sobre la lgica de procesamienlO de transacciones del SOBO, puesto que el SOBD" ya tuvo que admitir las transacciones por las fronteras del sistema en el estado de transaccin distribuida anterior. Sin embargo, las solicitudes distribuidas poseen nuevos reros para la lgica de optimizacin del SOBD. El optimizador debe ahora considerar la velocidad de la red cuando evala mtodos alternativos para realizar una instruccin SQL. Si el SOBD local debe acceder repetidamente a parte de una tabla remota (por ejemplo, cuando realiza una reunin), puede ser ms rpido copiar parte de la tabla a travs de la red en una gran transferencia masiva, en lugar de recuperar de fonna repetida filas individuales a travs de la red. Los tamaos relativos de las tablas en el sistema local y remoto tambin son factores de optimizacin relevantes, as como la selectividad de cualquier condicin de bsqueda en la clusula SELECT. Para algunas consultas las condiciones de bsqueda pueden seleccionar solamente una o unas pocas filas en el sistema local y cientos de filas en el sistema remoto, por lo que, en primer lugar, se deberan aplicar localmente. Para otras consultas que afectan a las mismas tablas, la selectividad relativa puede ser a la inversa y se debera aplicar la condicin de bsqueda remota. Para otras consultas, la condicin de reunin puede limitar las filas que participan en los sistemas local y remoto y puede ser ms eficaz aplicarla en primer lugar. En cada caso, el coste de la consulta no es solamente el coste del acceso a la base de datos, sino tambin el coste derivado de enviar los resultados intermedios de los pasos de la ejecucin de la consulta a travs de la red. El optimizador tambin debe decidir qu copia de SGBD debera gestionar la ejecucin de las instrucciones. Si la mayora de las tablas estn en un sistema remoto, puede ser una buena idea que el SGBD remoto en ese sistema ejecute la instruccin. Sin embargo, puede ser una mala eleccin si el sistema tiene una gran carga. Por ello la tarea del optimizador es ms compleja y mucho ms importante en una solicitud distribuida. Por ltimo, el objetivo del estado de solicitud distribuida es hacer que toda la base de datos distribuida le parezca al usuario una gran base de datos. Idealmente, el usuario tendra acceso completo a cualquier tabla en la base de datos distribuida y podra utilizar transacciones SQL sin conocer nada sobre la ubicacin fsica de los datos. Desafortunadamente, se probara rpidamente que este escenario es poco prctico en redes reales. En una red de cualquier tamao, el nmero de tablas en la base de datos distribuida se hara rpidamente muy grande y a los usuarios les resultara imposible encontrar los datos de inters. Se tendran que coordinar todos los identificadores de usuario de todas las bases de datos en la organizacin para asegurar que un identificador de usuario dado identifica de forma nica a un usua rio en todas las bases de datos. La administracin de la base de datos tambin sera muy complicada. En la prctica, por tanto, las solicitudes distribuidas se deben implementar de forma selectiva. Los administradores de bases de datos deben decidir qu tablas remotas se van a hacer visibles para los usuarios locales y cules se mantendrn
ocultas. Las copias de SGBD cooperantes deben lraducir los identificadores de usuarios de un sistema a otro, permitiendo que cada base de datos se administre de forma autnoma mientras se proporciona seguridad para el acceso a los datos remotos. Las solicitudes distribuidas que consuman demasiados recursos del SGBD o de red se deben detectar y prohibir antes de que afecten al rendimiento global del SGBD. Debido a su complejidad, en la actualidad las solicitudes distribuidas no son admitidas completamente por ningn SGBD comercial basado en SQL y pasar un cierto tiempo antes de que est disponible una buena parte de sus caractersticas. Un paso importante hacia el procesamiento distribuido a travs de las marcas de base de datos ha sido la estandarizacin de un protocolo de transacciones distribuido. El protocolo XA, originalmente desarrollado para coordinar varios supervisores de la transaccin, tambin se est aplicando de forma activa a transacciones de bases de datos distribuidas. Una versin Java de la misma capacidad, denominada Java Transaclion ProLOcol (JTP), proporciona una interfaz de transaccin distribuida para aplicaciones basadas en Java y servidores de aplicaciones. En la actualidad, la mayora de los productos SGBD comerciales se han diseado para ser utilizados en un soporte en red de las interfaces XA y JTA.
El protocolo de compromiso de dos fases
Un SGBD distribuido debe preservar la cualidad todo o nada de una transaccin SQL si va a proporcionar transacciones distribuidas. El usuario de un SGBD distribuido espera que una transaccin estar realizada en todos los sistemas en que los datos residan y tambin que una transaccin deshecha estar deshecha en todos los sistemas. Adems, los fallos en una conexin de red o en uno de los siste mas debera provocar que una transaccin se aborte y se deshaga, en lugar de dejar la transaccin en un estado de realizacin parcial. Todos los SOBD comerciales que admiten las transacciones distribuidas utilizan una tcnica denominada compromiso de dos fases para proporcionar dicho soporte. No se tiene que comprender el esquema de compromiso de dos fases para utilizar las transacciones distribuidas. En realidad, el ncleo central del esquema es albergar las transacciones distribuidas sin saberlo. Sin embargo, la comprensin de los mecanismos de un compromiso de dos fases puede ayudar a planificar de forma eficiente el acceso a la base de datos. Para comprender por qu es necesario un protocolo especial de compromiso de dos fases, consideremos la base de datos de la Figura 23.13. El usuario, ubicado en el sistema A, ha actualizado una tabla en el sistema B y una tabla en el sistema e, y ahora desea realizar la transaccin. Supongamos que el software SOBD en el sistema A intent completar la transaccin enviando simplemente un mensaje COMMIT al sistema B y al sistema e y despus esperando sus contestaciones afirmativas. Esta estrategia funciona siempre que los sistemas B y e realicen satisfactoriamente su parte de la transaccin. Pero qu sucede si un problema como un fallo en un disco o una condicin de interbloqueo evita que.el sistema e realice la transaccin como se le ha solicitado?
828
saL.
829
Sistema B
Sistema A
INSERT
Sistema
C---'
Sistema B
Sistema A
INSERT
Sist,
INSERT
INSERT
UPDATE GET READY
S
UPDATE COMMIT
UPDATE COMMIT
UPDATE GET READY

COMMIT
OK
OK
(comprometida)
1)
COMfHT
s
COMMIT
1)
1)
GET READY
COMMIT OK COMlUT
INSERT

INSERT
COMMIT
OK
(comprometida)

INSERT UPDATE ... GET READY COMMIT GET READY NO
UPDATE
UPDATE
COMMIT
..
Figura 23.13.
(
.....
OK
COMMIT
Vaya!
NO
IN5ERT
UPDATE
GET REAOY
NO ROLLBACK
~ ROLLBACK
ROLLBACK
OK
Vaya! (retrocedida)
ROLLBACK OK
lI
) ROLLBACK
Error: la transaccin se ha comprometido

en el sistema B pero se ha retrocedido en el
Figura 23.14.
El protocolo de compromiso de dos fases.
Problemas en un esquema de compromiso difundido.
3. El sistema B realizar su parte de la transaccin y enviar su notificacin. El sistema e deshar su parte de la transaccin debido al error y enviar un mensaje de error, y el usuario finalizar con una transaccin parcialmente realizada, parcialmente deshecha. Ntese que el sistema A no puede cambiar de opinin en este punto y pedir al sistema B que deshaga la transaccin. La transaccin en el sistema B se ha realizado y otros usuarios pueden ya haber modificado los datos en el sistema B basndose en los cambios realizados por la transaccin. El protocolo de compromiso de dos fases elimina los problemas de la estrategia sencilla mostrados en la Figura 23.13. La Figura 23.14 ilustra los pasos que conlleva un compromiso de dos fases:
1.
4.
2.
El programa en el sistema A enva un COMMIT para la transaccin en curso (distribuida), la cual ha actualizado las tablas en el sistema B y en el sistema C. El sistema A actuar como el coordinador del proceso de compromiso, coordinando las actividades del software SGBD en los sistemas B y C. El si~tema A enva un mensaje GET READY a los sistemas B y C y anota el mensaje en su propio registro de transacciones.
S.
Cuando el SGBD en el sistema B o C reciba el mensaje GET READY, debe prepararse para realizar o deshacer la transaccin en curso. Si el SGBD puede alcanzar este estado preparado para el compromiso responde s al sistema A y anota ese hecho en su registro histrico de transacciones local; si no se puede obtener este estado, responde NO. El sistema A espera la respuesta a su mensaje GET READY. Si todas las respuestas son s, el sistema A enva un mensaje COMMIT a ambos sistemas B y C y anota la decisin en su registro histrico de transacciones. Si cualquiera de las respuestas es NO, o si no se reciben todas las respuestas dentro de un cierto periodo de tiempo, el sistema A enva un mensaje RQLLBACK a ambos sistemas y anota esa decisin en su registro histrico de transacciones. Cuando el SOBD en el sistema B o recibe el mensaje COMMIT o ROLLBACK, debe hacer lo que se le ha dicho. El SGBD cede la capacidad de decidir el destino de la transaccin de forma autnoma cuando se res~ ponde S al mensaje GET READY en el paso 3. El SGBD realiza o deshace su parte de la transaccin segn se solicita, escribe el mensaje COMMIT o
...-.J
830

ROLLBACK en su registro histrico de transacciones y devuelve un men-
831
Aplicaciones de redes y arquitectura de bases de datos

Las innovaciones en las redes informticas han estado fuertemente vinculadas a muchas de las innovaciones en las arquitecturas de bases de datos relacionales y SQL Potentes minicomputadoras con conexiones de red a grandes sistemas (como la familia VAX de Digital) formaron las primeras plataformas populares para ba~ ses de datos basadas en SQL. Ofrecan una plataforma para soporte en la decisin, basada en datos descargados desde grandes sistemas. Tambin admitan aplicaciones de procesamiento de datos locales, captura de datos del negocio y su carga en aplicaciones de grandes sistemas corporativos. Los servidores basados en UNIX y las redes de rea local potentes (como los productos para servidores de Sun) trajeron otra ola en el crecimiento e innovacin de los SOBD. Esta era de bases de datos y redes dio lugar a la arquitectura cliente! servidor que domin el procesamiento de datos empresariales en la dcada de los noventa. Posteriormente, la formacin de redes y aplicaciones empresariales (como Enterprise Resource Planning) cre la necesidad de un nuevo nivel para la escalabilidad de bases de datos y capacidad de bases de datos distribuida. En la actualidad, la explosiva popularidad de Internet nos est llevando a otra ola de innovacin, porque las tasas de transacciones con altos picos de carga y la interaccin personalizada con los usuarios guan las tecnologas de las cachs de bases de datos y las bases de datos residentes en memoria.
6.
saje OK al sistema A. "Cuando el sistema A haya recibido lOdos los mensajes OR, sabraque la transaccin se habr realizado o deshecho y devolver el valor SQLCODE adecuado al programa.
Este protocolo protege la transaccin distribuida de cualquier fallo en el sistema B, el sistema e o en la red de comunicaciones. Estos dos ejemplos ilustran cmo el protocolo permite la recuperacin de los fallos: Supongamos que ocurre un fallo en el sistema e antes de enviar un mensaje s en el Paso 3. El sistema A no recibir una respuesta s y difundir un mensaje ROLLBACK, haciendo que el sistema B deshaga la transaccin. El programa de recuperacin en el sistema e no encontrar el mensaje s o un mensaje COMMIT en el registro histrico de transacciones local y deshar la transaccin en el sistema e como parte del proceso de recuperacin. Todas las partes de la transaccin se habrn deshecho en este punto. Supongamos que ocurre un fallo en el sistema e antes de que enve un mensaje s en el paso 3. El sistema A decidir si realizar o deshacer la transaccin distribuida basndose en la respuesta del sistema B. El programa de recuperacin en el sistema C encontrar un mensaje s en el registro histrico de transacciones local, pero no encontrar un mensaje COMMIT o ROLLBACK para marcar el final de la transaccin. El programa de recuperacin pregunta entonces al coordinador (sistema A) cul fue la disposicin final de la transaccin y acta en consecuencia. Ntese que el sistema A debe mantener un registro de su decisin para realizar o deshacer la transaccin hasta que reciba el OK final de todos los participantes, de forma que puede responder al programa de recuperacin en caso de fallo.
Aplicaciones cliente/servidor y arquitectura de bases de datos

Cuando las bases de datos basadas en SQL se implantaron por primera vez en sistemas de minicomputadoras, la arquitectura de las bases de datos y de las aplicaciones era muy sencilla -todo el procesamiento, desde la visualizacin en pantalla (presentacin), los clculos y el procesamiento de datos (lgica del negocio), hasta el acceso a la base de datos ocurra en la CPU de la minicornputadora-. Con. la llegada de las computadoras personales potentes y las plataformas de servidores se produjo un cambio grande en la arquitectura, por varias razones. La interfaz grfica de usuario (GUI, Graphical User lnteiface) del software de automatizacin de oficinas PC populares (hojas de clculo, procesadores de texto, etc.) estableci un nuevo estndar de facilidad de uso, y las compaas demandaban el mismo estilo de interfaz para las aplicaciones corporativas. Admitir una GUI requiere mucha carga en el procesador y tambin un camino con un gran ancho de banda desde el procesador para mostrar las memoria que alberga la imagen de la pantalla. Mientras algunos protocolos emergieron para ejecutar una GUI a travs de LAN (el protocolo X-windows), la mejor ubicacin para ejecutar un cdigo de capa de presentacin de una aplicacin de produccin era claramente el mismo Pe. La economa fue tambin un factor. Los sistemas informticos personales eran mucho ms baratos, en tnninos del coste por potencia de procesamiento, que las minicomputadoras o los servidores basados en UNIX. Si buena parte del procesa-
El protocolo de compromiso de dos fases garantiza la integridad de las transacciones distribuidas, pero genera una gran cantidad de trfico de red. Si hay n sistemas implicados en la transaccin, el coordinador debe enviar un total de 4 * n mensajes para realizar satisfactoriamente la transaccin. Ntese que estos mensajes se agregan a los mensajes que ya llevan las instrucciones SQL y los resultados de la consulta entre los sistemas. Sin embargo, no hay ninguna forma de evitar el trfico de mensajes si una transaccin distribuida va a proporcionar integridad de la base de datos en el caso de fanos del sistema. Debido a la gran carga de trfico de red, las transacciones distribuidas pueden tener un efecto seriamente negativo en el rendimiento de la base de datos. Por esta razn se deben disear cuidadosamente las bases de datos distribuidas de forma que los datos a los que se accede frecuentemente (o al menos que se actualizan frecuentemente) estn en un sistema local o en un nico sistema remoto. Si es posible, deberan ser relativamente raras las transacciones que actualicen dos o ms sistemas remotos.
832
833
miemo de una aplicacin del negocio poda tener lugar en pe de bajo coste, ~el coste total del hardware para implantar una aplicacin se reducira. Esto fue un argumento para cambiar, no solamente la capa de presentacin, sino gran parte de la capa de la lgica del negocio al pe. Conducidos por estos y otros factores emergieron las primeras arquitecturas cliente/servidor, mostradas en la Figura 23.15. Muchas aplicaciones basadas en pe se estn implantando actualmente utilizando esta arquitectura. SQL desempea una funcin clave como lenguaje cliente/servidor. Las solicitudes se envan desde la lgica de la aplicacin (en el pe) al SOBD (en el servidor) expresadas en instrucciones SQL Las respuestas vuelven a travs de la red en forma de cqigos de estado de terminacin de SQL (para las actualizaciones de la base de datos. o resultados de la consulta SQL (para solicitudes de informacin).
capacidad de transmisin de dalos (ancho de banda) y en retrasos en los mensajes de ida y vuelLa (Ialencia). Con la arquitectura mostrada en la Figura 23.15, cada acceso a la base de datos (esto es, cada instruccin SQL) genera al menos un viaje de ida y vuelta a travs de la red. En una aplicacin OLTP. las transacciones normales pueden requerir hasta ms de una docena de inSlrucciones SQL individuales. Por ejemplo. para anotar un pedido de cliente de un nico producto en la sencilla estructura de la base de datos de ejemplo, la aplicacin de procesamiento de pedidos puede: Ree;.uperar el nmero de cliente segn el nombre del cliente (SELECT de una nica fila). Recuperar el lmite de crdito del cliente para comprobar su capacidad de crdito (SELECT de una nica fila). Recuperar la informacin de producto. como el precio y la cantidad disponible (SELECT de una nica fila). Agregar una fila a la tabla PEDIDOS para el nuevo pedido (INSERT). Actualizar la informacin del producto para reflejar una menor cantidad disponible (UPDATE). Actualizar el lmite de crdito del cliente, reduciendo el crdito disponible
(UPDATE).
Aplicaciones cliente/servidor con procedimientos almacenados

Siempre que una aplicacin se divide entre dos o ms sistemas informticos en red. como en la Figura 23.15, uno de los problemas principales es la interfaz entre las dos mitades de la aplicacin dividida. Cada interaccin a travs de esta interfaz genera trfico de red y ]a red siempre es la parte ms lenta del sistema global. en su
Llevar a cabo toda la transaccin

'1i,:!-
(COMMIT).
Computadora personal
SGBD
Instrucciones Sal (1 solicitud/instruccinl
Resultados

Base de datos
Figura 23.15.
Arquitectura de las aplicaciones cliente/servidor.
con un':iotal de siete viajes de ida y vuelta entre la aplicacin y la base de datos. En una aplicacin real el nmero de accesos a la base de datos puede ser dos o tres veces esta cantidad. Al crecer el volumen de transacciones, la cantidad de trfico de red puede ser muy significativa. Los procedimientos almacenados de la base de datos proporcionan una arquitectura alternativa que puede reducir radicalmente la cantidad de trfico de red, como se muestra en la Figura 23.16. Un procedimiento almacenado en la base de datos incorpora la secuencia de pasos y la lgica para toma de decisiones requerida para llevar a cabo todas las operaciones de la base de datos asociadas con la transaccin. Bsicamente, parte de la lgica del negocio que anteriormente resida en la aplicacin misma se ha movido a travs de la red al servidor de bases de datos. En lugar de enviar instrucciones SQL individuales a SGBD, la aplicacin llama al procedimiento almacenado, pasando el nombre del cliente. producto requerido y la cantidad deseada. Si todo va bien, el procedimiento almacenado termina satisfactoriamente. Si se genera un problema (como una falta de producto disponible O un problema con el crdito del cliente), se devuelve un cdigo de error y un mensaje que lo describe. Mediante el uso del procedimiento almacenado se reduce el trfico de red a una nica interaccin cliente/servidor. Hay otras ventajas de utilizar los procedimientos almacenados, pero la reduccin en el trfico de red es una de las principales. Supuso una ventaja principal para la venta de SQL Server de Sybase cuando se introdujo por primera vez y ayud a posicionar a Sybase como un especialista SGBD para aplicaciones OLTP de aIto rendimiento. Con la popularidad de los procedimientos almacenados toda empresa SGBD de propsito general ofrece ahora esta capacidad.
834
835
Computadora personal Entrada de usuario

~ ~
Servidor de aplicaciones Solicitudes de bases de datos Aplicacin empresarial

~
Computadora personal
SGSD
Aplicacin Windows o explorador '--I

~
Mostrar datos
Resultados
~-..
B
-HV
Base de datos
Base de datos
\,--_--,_--,1 y-
\'--_yr---JI Capa intermedia
\~_....,
y-
_ _~J
Figura 23.16.
Arquitectura cliente/servidor con procedimientos almacenados.
Frontal
Dorsal
Aplicaciones empresariales y cach de datos

En la actualidad la mayora de las aplicaciones de fabricantes de grandes paquetes de software empresarial se basan en SQL y bases de datos relacionales. Ejemplos de esto son Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Human Resources Management (HRM), Customer Relationship Managernent (CRM), gesti6n financiera y otros paquetes de vendedores tales como SAP,
BAAN, PeopleSoft, Vanlive, Clarify, Siebel Systems. i2 Technologies, Manugis tics y otros. Estas aplicaciones de gran escala se ejecutan normalmente en grandes sistemas de servidores basados en UNIX y tienen una gran carga de trabajo en el SGBD que lo incorpora. Para aislar las apli~aciones y el procesamiento SOBD y aplicar ms potencia de procesamiento total a la aplicacin, se utiliza frecuentemente una arquitectura de tres capas mostrada en-ia Figura 23.17. Incluso con el uso de procedimientos almacenados para minimizar el trfico de red, la red y las demandas de acceso a la base de datos de la mayora de estas aplicaciones intensivas en datos pueden superar el ancho de banda disponible de la red y las tasas de transacciones del SGBD. Por ejemplo, consideremos una aplicacin de planificacin de una cadena proveedora que ayuda a una compaa de fabricacin a determinar las piezas que debe pedir a los proveedores. Para generar un plan completo, la aplicacin debe examinar todo pedido abierto y aplicar la lista de materiales del producto. Un producto complejo puede suponer cientos de piezas, algunas de las cuales son subcomponentes, consistentes en docenas o cientos de piezas.
Figura 23.17.
Arquitectura de tres capas de una importante aplicacin em~ presarial.
Si se escribe milizando tcnicas de programacin sencillas, la aplicacin para la planificacin debe ejecutar una consulta a la base de datos para determinar el total de partes de todos los productos, y despus todos los subcomponentes, para todos los pedidos, y acumular la informacin necesaria total en la base d~ d~tos de planificacin para cada una de estas piez~s. Mediante. el uso de .esta tecfilca, la aplicacin tardar horas en procesar los CIentos de mIles de pedIdos que puede haber actualmente en los libros. En realidad la aplicacin tardar probablemente tanto que no podr completar su trabajo durante la ventana de tiempo con bajo volumen de procesamiento por lotes nocturno durante el cual, normalmente, la compaa ejecuta dichas aplicaciones. . . . Para conseguir un rendimiento aceptable, todas las aplicaCIOnes empresanal~s con datos intensivos emplean tcnicas de cach, enviando los datos fuera del serv dor de la base de datos, ms cerca de la aplicacin. En la mayora de los casos, ~a aplicacin utiliza tcnicas de cach relativamente primitivas. Por ejempl?, ~~a leer la lista de materiales una vez y cargarla en tablas de datos en la memona pnnclpal en la aplicacin. Eliminando las consultas ,de la estruct~ra de los product.os.repetidas intensivamente, el programa puede mejorar dramticamente su rendImiento. Recientemente los fabricantes de aplicaciones empresariales han comenzado a utilizar tcnicas de cach ms complejas. Pueden reproducir los datos a los cuales
836
Captulo 23: Redes SOL V bases de datos distribuidas
837
se accede ms frecuentemente (los datos calientes) en una tabla duplicada de la base de datos, en el mismo sistema que la aplicacin. Las bases de datos residentes en memoria ofrecen una alternativa con un rendimiento incluso mayor y ya se han utilizado donde hay una cantidad relativamente pequea de datos calientes (decenas o cien LOS de megabytes). Con la llegada de arquitecturas de sistemas op~rali vos de 64 bits y con las continuas bajadas de precios de las memorias se dt haciendo accesible almacenar en cach cantidades de datos mayores (varios gigabyles a decenas de gigabytes). La cach y la rplica avanzadas sern ms importantes en respuesta a requisitos de negocio emergentes. Las compaas de fabricacin lderes desean una planificacin en tiempo real, donde los pedidos entrantes de los clientes y los cambios impacten inmediatamente en los planes de produccin. Desean ofrecer productos ms personalizados. con ms configuraciones, con el fin de cumplir ms especficamente los deseos de los clientes. Estas tendencias continuarn aumentando el volumen y la complejidad del acceso a las bases de datos.
principal, que se utiliza para personalizar experiencias de los usuarios cuando interaccionan con el sitio Web. Como se muestra en la Figura 23. J 8, los mtodos para manipular la gestin de datos de alto rendimiento estn comenzando a seguir a los ya establecidos para la gestin de pginas Web de alto rendimiento. Los temas para las bases de datos son ms complicados debido a factores de integridad de la base de datos, pero las tcnicas emergentes son similares (rplica, acceso de lectura de gran volumen. bases de datos residentes en memoria y arquitecturas altamente tolerantes a fallos. Estas demandas crecern solamente si el trfico en Internet y la personalizacin continan aumentando, llevndonos a arquitecturas de bases de datos en red ms avanzadas.
Servidor de bases de datos Servidor de aplicaciones
Gestin de grandes volmenes de datos en Internet

Las aplicaciones de Internet con grandes volmenes de datos tambin estn dirigiendo la tendencia a cach de base de datos y rplica en arquitecturas de base de datos en red. Por ejemplo, las empresas de servicios financieros estn compitiendo por atraer a clientes por Internet ofreciendo informes de stock en tiempo real y capacidades de anlisis cada vez ms avanzadas. La gestin de datos para albergar esta aplicacin exige la alimentacin de datos en tiempo real (para asegurar que la informacin sobre los precios y el volumen en la base de datos es actual) y solicitudes a la base de datos con picos de carga de cientos de miles de transacciones por segundo. Demandas de volmenes similares se encuentran en aplicaciones para gestionar y supervisar los sitios de Internet de gran volumen. La tendencia a personalizar los sitios Web (determinando en tiempo real los anuncios a mostrar. los productos a ofertar y cosas asO y a medir la efectividad de dicha personalizaci6n es otra tendencia que genera picos de carga de acceso a datos y altos niveles de captura de datos. La Web tambin se ha mostrado como una arquitectura efectiva para tratar con estos tipos de demandas de volumen de carga en Internet (mediante cach del sitio Web). Las copias de las pginas Web a las que se accede frecuentemente se envan a la red y se reproducen. Como resultado, la capacidad total de la red para servir pginas Web se ve aumentada y la cantidad de trfico de red asociado con estas pginas se reduce. Estn comenzando a emerger arquitecturas similares para la gestin de bases de datos Internet de gran volumen, como la mostrada en la Figura 23.18. En este caso, una aplicacin de servicios de informacin Internet almacena en cach los datos calientes. como las noticias ms recientes y la informacin financiera, en una base de datos residente en memoria principal de alto rendimiento de un fabricante como TimesTen Performance Software. Tambin almacena infoonacin resumida del perfil de usuario en una base de datos residente memoria
BD residente "en memoria principal Perilles de usuario

A
<::...-..>1
SGSD
Internet
o
Intranet
:Exptorado~
Web
~-....-..
l(
V
-,---0
<'-~
Aplicacin Internet
<:
::>
Base de datos dorsal
1r
I~ Internet
\2atos llcalientesl encach BO residente en
LI ~ ~
memoria principal

Servidores reproducidos
Web
Figura 23.18.
Reparto de datos para la gestin de datos de alto rendimiento.
838
Resumen
\
)
En este captulo se han descrito las capacidades en la gestin de datos distribuidos ofrecidas por varios productos SOBO y los compromisos adaptados para proporcionar el acceso a datos remotos: Una base de datos distribuida est implementada en una red de sistemas informticos, cada uno ejecutando su propia copia de software SGBD y operando de forma autnoma para el acceso a los datos locales. Las copias de SGBD cooperan para proporcionar acceso a Jos datos remotos cuando se requiera. . La base de datos distribuida ideal es aquella en la cual el usuario no conoce y no le importa que los datos estn distribuidos; para el usuario todos los datos relevantes aparecen como si estuvieran en el sistema local. Debido a que este SOBD distribuido ideal es muy complicado de proporcionar y conlleva demasiados compromisos de rendimiento, los productos SOBD comerciales proporcionan capacidad de bases de datos distribuida en fases. El acceso a bases de datos remotas puede ser til en situaciones en que el acceso remoto es una pequea parte de la actividad total de la base de datos; en este caso es ms prctico dejar los datos en la ubicacin remota y generar una carga en la red para cada acceso a la base de datos. La rplica de la base de datos es muy til en situaciones donde el acceso a los datos en varias ubicaciones es relativamente grande; lleva los datos ms cerca del punto de acceso, pero con el coste de carga de la red para la sincronizacin de la rplica y sabiendo que Jos datos no estn actualizados al cien por cien. Los compromisos particulares del acceso a los datos remotos y las estrategias de rplica tienen implicaciones ms all de las decisiones tecnolgicas; tambin deberan reflejar los compromisos subyacentes en las prioridades del negocio. Las aplicaciones distribuidas empresariales, las aplicaciones basadas en Internet, los almacenes de datos y otras tendencias estn aumentando la complejidad del entorno de gestin de datos distribuidos. Las arquitecturas en N capas que utilizan requerirn una cach de datos inteligente y estrategias de rplica para conseguir un rendimiento adecuado.
CAPTULO
24
SOL Y los objetos
El nico reto imponante para el domioio de SQL y la gestin de as bases de datos relacionales en los ltimos aos ha venido de la irrupcin de una tendencia igualmente significativa: la creciente popularidad de las tecnologas orientadas a objetos. Los lenguajes de programacin orientados a objetos (tales como C++ y Java), las herramientas de desarrollo orientadas a objetos y las redes orientadas a objetos (incluidos los agentes de solicitud de objetos y, ms recientemente, los servicios Web) han emergido como tecnologas fundamentales para el desarrollo de software moderno. Las tecnologas de objetos ganaron gran parte de su popularidad inicial por la construccin de aplicaciones en computadoras personales con interfaces grficas de usuario. Pero su impacto ha crecido y se estn utilizando actualmente para construir (y, ms importante an, para vincular entre s) aplicaciones basadas en red empresariales para grandes corporaciones. Al comienzo de los aos noventa surgi un grupo de empresas de bases de datos orientadas a objetos que se embarcaron en la aventura de aplicar los principios orientados a objetos a la gestin de bases de datos. Estas compaas creyeron que sus bases de datos orientadas a objetos suplantaran a las anticuadas bases de datos relacionales de igual forma que el modelo relacional haba suplantado anteriormente a los modelos de datos. Sin embargo, se encontraron con un limitado xito en el mercado frente a las consolidadas tecnologas relacionales y SQL. En respuesta al reto de los objetos, muchos fabricantes de bases de datos se cambiaron agresivamente a tecnologas de objetos incrustadas en sus sistemas relacionales, creando modelos hbridos relacionales orientados a objetos. Este captulo describe el reto de las bases de datos orientadas a objetos para SQL y las caractersticas resultantes relacionales orientadas a objetos proporcionadas por algunos de los principales fabricantes de SOBD.
Bases de datos orientadas a objetos

Buena parte de la investigacin acadmica en la tecnologa de bases de datos durante la ltima dcada se ha enfocado en nuevos modelos de datos post-relaciona-
839
840
Captulo 24: SOL y los objetos
841
les. As como el modelo relacional proporcion claras ventajas sobre los anteriores modelos jerrquicos y de red, el objetivo de la investigacin fue el de desarrollar nuevos modelos de dales que superaran algunas de las desventajas del modelo relacional. Gran parte de esta investigacin se centr en cmo combinar los principios de la programacin orientada a objetos y el diseo con caractersticas tradicionales de la base de datos, como es el caso del almacenamiento persistente y la gestin de transacciones. Adems de la investigacin acadmica, al comienzo y a mediados de los aos noventa algunas grandes inversiones de capital dieron como resultado la creacin de empresas de software cuyos objetivos comenzaron con las estructuras de datos de los objetos utilizadas por un programa orientado a objetos para gesti6nar sus datos en la memoria, y las extendieron para un almacenamiento basado en disco y acceso a varios usuarios. Los entusiastas de estas bases de datos orientadas a objetos (BDOO) crean firmemente que se producira un cambio serio en el modelo relacional y se convertira en la arquitectura dominante de las bases de datos, pero los fabricantes de bases de datos orientadas a objetos han tenido un impacto significativo en sus rivales relacionales.
Caractersticas de las bases de datos orentadas a objetos

Al contrario del caso del modelo de datos relacional, en que el artculo de Codd de 1970 proporcion una definicin matemtica clara de una base de datos relacional, no hay una nica definicin de una base de datos orientada a objetos. Sin embargo. los principios principales de la mayora de las bases de datos orientadas a objetos hacen referencia a los siguientes aspectos:
este atributo, por son subclases de VEHICULOS. La clase COCHES podra tambin tener el atributo nmero de puertas y la clase DESCAPOTABLES heredara este atributo. Sin embargo, la clase BARCOS no heredara este atributo. Atributos. Las caractersticas que un objeto posee se modelan con sus atributos. Ejemplos de esto son el color de un objeto o el nmero uC puerta que tiene y su nombre en lenguaje natural. L~s atributos se relacionan con el objeto que describen de una forma parecida a como las columnas de una tabla se relacionan con sus filas. Mensajes y mtodos. Los objetos se comunican entre s enviando y recibiendo mensajes. Cuando un objeto recibe un mensaje, responde ejecutando un mtodo, un programa almacenado en el objeto que determina cmo se procesa el mensaje. Por ello, un objeto incluye un conjunto de comportamientos descritos por sus mtodos. Normalmente, un objeto comparte muchos mtodos con otros objetos en clases de un nivel ms alto. Encapsulacin, La estructura interna y los datos de los objetos se ocultan del mundo exterior (encapsulado) detrs de un conjunto limitado de interfaces bien definidas. La nica forma de averiguar algo sobre un objeto, o de actuar sobre l, es mediante sus mtodos, cuyas funciones y comportamientos se especifican claramente. Esto hace al objeto ms predecible y limita las posibilidades de una corrupcin accidental de los datos. Identidad del objeto. Los objetos se pueden distinguir entre s mediante un identificador de objeto nico, normalmente implementado como un puntero abstracto conocido como controlador. Los controladores se utilizan frecuentemente para representar relaciones entre objetos; un objeto apunta a un objeto relacionado almacenando el controlador del objeto como uno de sus elementos de datos (atributos).
Objetos. En una base de datos orientada a objetos, todo es un objeto y se manipula como un objeto. La organizacin tabular de filas y columnas de una base de datos relacional se reemplaza por la nocin de colecciones de objetos. Generalmente, una coleccin de objetos es en s misma un objeto y se puede manipular de la misma forma que se manipulan los objetos. Clases. Las bases de datos orientadas a objetos reemplazan la nocin relacional de los tipos de datos atmicos por una nocin jerrquica de las clases y subclases. Por ejemplo, VEHICULOS podra ser una clase de objeto, y los miembros individuales (instancias) podran incluir coche, bicicleta, tren o barco. La clase VEHICULOS podra incluir subclases llamadas COCHES y BARCOS, representando una forma ms especializada de vehculo. De forma similar, la clase COCHES podra incluir una subclase denominada DE8CAPOTABLES, etc. Herencia, Los objetos heredan las caractersticas de sus clases y de todas las clases de nivel superior a la que pertenecen. Por ejemplo, una de las caractersticas de un vehculo podra ser nmero de pasajeros. Todos los miembros de las clases COCHES, BARCOS Y DESCAPOTABLES tambin tienen
Estos principios y tcnicas hacen que las bases de datos orientadas a objetos sean muy adecuadas para aplicaciones que conllevan tipos de datos complejos, como el diseo asistido por computadora o documentos compuestos que combinan texto, grficos y hojas de clculo. La base de datos proporciona una forma natural de representar las jerarquas que se dan en los datos complejos. Por ejemplo, un documento completo se puede representar como un nico objeto, compuesto de objetos menores (secciones), compuestos de objetos todava menores (prrafos, grficos, etc.). La jerarqua de clase permite a la base de datos seguir el tipo de cada objeto en el documento (prrafos, grficos, ilustraciones, ttulos, pies de pgina, etc.). Finalmente, el mecanismo del mensaje ofrece un soporte natural para una interfaz grfica de usuario. La aplicacin puede enviar un mensaje dibjate a ti mismo a cada parte del documento, pidindole que se dibuje a s mismo en la pantalla. Si el usuario cambia la forma de la ventana que muestra el documento, la aplicacin puede responder enviando un mensaje cambia de tamao por ti mismo a cada parte del documento, etc. Cada objeto en el documento cuenta con la responsabilidad de su propia visualizacin, por lo que se pueden agregar fcilmente nuevos objetos a la arquitectura del documento.
.-l-
842
Captulo 24: SQL y los objetos
843
Pros y contras de las bases de datos orientadas a objetos

Las bases de datos orientadas a objetos han producido una tormenta de controversias en la comunidad de bases de datos. Los que estn a favor dicen que las bases de datos orientadas a objetos son esenciales para crear una coincidencia adecuada entre los modelos de los datos de la programacin y de las bases de datos. Piensan que la rgida y fija estructura de filas y columnas de las tablas relacionales es una herencia de la era del procesamiento de datos, a base de las tarjetas perforadas, con sus campos de datos fijos y su orientacin a registros. Segn stos, para responder de forma efectiva a ~ituaciones reales, .es .esencial un modelo ms) flexible, por el cual las clases de objetos puedan ser simIlares (esto es, compartan ciertos atributos), pero tambin diferentes entre s. Otra reivindicacin es que las reuniones multitabla, que son una parte integral del modelo de datos relacional, crean una sobrecarga en la base de datos y hace que la tecnologa relacional no sea til para las demandas de rendimiento crecientes de las aplicaciones actuales. Finalmente, puesto que los objetos estn bien establecidos como el modelo de datos residente en memoria principal para los programas modernos, los que estn a favor sostienen que el nico modelo de datos natural ser uno que extienda de forma transparente el modelo residente en memoria principal hacia el almacenamiento permanente, compartido, bas.ado en disco y multiusuario. Los oponentes a las bases de datos orientadas a objetos son tan inflex.ibles en sus planteamientos que las bases de datos orientadas a objetos son innecesarias y no ofrecen ventajas reales y sustantivas sobre el modelo relacional. Consideran que los controladores de las bases de datos orientadas a objetos no son ms que los pu~teros de las bases de datos embebidos de bases de datos prerrelacionales jerrqUicas y de red. Apuntan que, al igual que estas primeras tecnologas de bases de datos, las bases de datos orientadas a objetos carecen de la fuerte teora matemtica que forma la base de las bases de datos relacionales. La falta de estndares de bases de datos orientadas a objetos y la ausencia de un lenguaje de consultas estndar, como SQL, son reflejo de esta deficiencia, y han impedido el desarrollo de herramientas independientes de los fabricantes y aplicaciones que han sido esenciales en el desarrollo de la industria de las bases de dalOs. En respuesta a las afirmaciones de un rendimiento menor, apuntan al uso de la tecnologa relacional en algunas de las aplicaciones empresariales con ms demanda en el rendimiento. Tambin son cuidadosos en establecer una distincin entre el modelo relacional externo de los datos y la implementacin subyacente, que puede contener punteros embebidos para la aceleracin del rendimiento. Finalmente, afirman que cualquier desajuste entre la programacin orientada a objetos y ~as bases de dat?s se puede solucionar mediante tecnologas como JDBC y otras Interfaces de objetos relacionales.
Los objetos y el mercado de bases de datos

En el merca~o, las bases de datos orientadas a objetos puras han tenido un cierto xito en aplicaciones con modelos de datos muy complejos y en aquellas en las
que el modelo de clases y herencia orientada a objetos est muy cerca del modelo real. Sin embargo, las compaas de bases de datos orientadas a objetos han tenido una dificultad real en el camino de la corriente principal. Muchas no han sobrevivido en la 'pri~era dcada del siglo XXI. Las supervivientes han tenido una poca dura, consIguiendo a duras penas alcanzar la marca de 100 millones de dlares an~ales, lograr beneficios sostenibles, si bien han experimentado cambios significativos en la gestin. Sin embargo, los principales fabricantes de bases de datos relacionales han continuado experimentando un crecimiento estable. Las mayores han tenido ganancias anuales de diez mil millones de dlares al ao, adems de que la tecnologa de bases de datos relacionales contina dominando claramente el mercado actual de bases de datos. No es sorprendente que los campos orientados a objetos y relacionales hayan impactado sustancialmente entre s. Con la lenta aceptacin en el mercado de la tecnologa orientada a objetos, los fabricantes de bases de datos orientadas a objetos se han centrado en algunos de los factores que provocaron el xito de la generacin relacional hace dos dcadas. Han formado grupos de estandarizacin, como ODMG (Object Data Management Group), para estandarizar la tecnologa de bases de datos orientadas a objetos. Algunos han agregado adaptadores relacionales, con interfaces estndar (ODBC y SQL) como capas opcionales para el acceso relacional a sus bases de datos. Varios se han centrado en el proceso de estandarizacin internacional y han trabajado para poner capacidades potentes orientadas a objetos en el estndar SQL3. El resultado neto ha sido una tendencia a abrazar o coexistir con el mundo relacional en lugar de competir con l. El reto de la orientacin a objetos ha tenido tambin un impacto significativo en la corriente relacional principal. Algunas caractersticas que comenzaron como capacidades relacionales (por ejemplo, los procedimientos almacenados) se estn ahora pregonando como ventajas orientadas a objetos (por ejemplo, la encapsulacin). Los fabricantes tambin han agregado en sus bases de datos relacionales capacidades orientadas a objetos seleccionadas, corno los tipos abstractos de datos. Las bases de datos relacionales orientadas a objetos proporcionan un hbrido entre las capacidades relacionales y de objetos. Extienden el modelo relacional (algunos diran que pasndose de la raya) para incorporar caractersticas como tablas en tablas, modelando las relaciones entre clases de objetos. Uno de los mayores fabricantes. Informix Software, consigui su capacidad relacional orientada a objetos mediante la adquisicin de Illustra Software. La tecnologa relacional orientada a objetos de Illustra se basaba en el trabajo de Postgres en la Universidad de California de Berkeley, paralelo al sistema relacional de bases de datos pionero de la universidad, Ingres. La versin Informix del producto IlIustra se llam Universal Server de Infor.rnix. Otro de los principales fabricantes, Oracle Corporation, desarroll su propio sistema de bases de datos principal para incluir las tecnologas relacionales orientadas a objetos. Oracle8, introducido en 1998, incorpor varios aos de desarrollo intensivo de Oracle en esta rea, y Oracle9 lo expandi an ms. La respuesta de los fabricantes de bases de datos orientadas a objetos y de los fabricantes relacionales ha tenido tambin un impacto importante en los estndares SQL. El cambio ms significativo al estndar SQL2, incluido en el trabajo
844
845
sobre SQL3, fue la agregacin de capacidades de objelos. Cuando SQL3 fue finalmente aprobado como el estndar oficial SQL: 1999, las nuevas capacidades orientadas a objetos casi doblaban el tamao de la especificacin del lenguaje SQL en trminos de pginas. La adquisicin y desarrollo de bases de datos relacionales orientadas a objetos por parte de los lideres en la industria y la adopcin formal de extensiones oriemadas a objetos de SQL sealan la creciente sinergia entre SQL y el mundo de la tecnologa orientada a objetos.
Bases de datos relacionales orientadas a objetos
Las bases de datos relacionales orientadas a objetos comienzan un fundamento de base de datos relacional y agregan caractersticas seleccionadas que proporcionan las capacidades orientadas a objetos. Este enfoque simplifica la agregacin de capacidades orientadas a objetos para la mayora de fabricantes de SGBDR, cuyos productos SGBDR empresariales se han desarrollado durante 15 o ms aos y reproducir desde cero supondra un coste enorme. Tambin reconoce el gran nmero de sistemas relacionales instalados y ofrece al cliente una forma de actualizacin ms suave (sin mencionar el aumento de ingresos de los fabricantes). Las extensiones orientadas a objetos que comnmente se encuentran en las bases de datos relacionales orientadas a objetos son: Objetos de datos de gran tamao. Los tipos de datos relacionales tradicionales son menores en tamao (enteros, fechas, cadenas de caracteres cortas); los objetos de datos de gran tamao pueden almacenar documentos, audio y video ctips, pginas web y otros nuevos tipos de datos multimedia. Tipos de datos estructurados/abstractos. Los tipos de datos relacionales son atmicos e indivisibles; los tipos de datos estructurados permiten a los grupos de elementos de datos individuales agruparse en estructuras de un nivel mayor que se pueden tratar como entidades en s mismas. Tipos-de datos definidos por el usuario. Las bases de datos relacionales proporcionan normalmente un rango limitado de tipos de datos incorporados; los sistemas y bases de datos orientadas a objetos enfatizan la capacidad del usuario de definir sus propios tipos de datos. Tablas en tablas. Las columnas de las bases de datos relacionales almacenan elementos de datos individuales; las bases de datos relacionales orientadas a objetos permiten a las columnas contener elementos de datos complejos, tales como tipos de datos estructurados o incluso tablas enteras. Esto se puede utilizar para representar jerarquas de objetos. Secuencias, conjuntos y arrays. En una base de datos relacional tradicional, los conjuntos de datos se representan por filas en su propia base de datos, vinculados a una entidad por una clave externa; las bases de datos relacionales orientadas a objetos pueden permitir el almacenamiento directo de colecciones de elementos de datos (secuencias, conjuntos, arrays) en una nica columna.
normalment~on
Procedimientos almacenados. Las bases de datos relacionales tradicionales proporcionan interfaces basadas en conjuntos, tales como SQL, para almacenar, seleccionar y recuperar datos; las bases de datos relacionales orientadas a objetos proporcionan interfaces procedimentales, tales como procedimientos almacenados, que encapsulan los datos y proporcionan interacciones estrictamente definidas. Controladores e identificadores de objetos. Una base de datos relacional pura requiere que los datos en cada fila de la base de datos misma (la clave principal) identifiquen de forma nica a la fila; las bases de datos relacionales orientadas a objetos proporcionan soporte incorporado para la identificacin de las filas, u otros identificadores nicos para los objetos.
Soporte de grandes objetos

Las bases de datos relacionales se han enfocado tradicionalmente en el procesamiento de los datos del negocio. Almacenan y manipulan los elementos de datos que representan cantidades de dinero, nombres, direcciones, cantidades, fechas, horas y cosas similares. Estos tipos de datos son relativamente sencillos y requieren pocas cantidades de espacio de almacenamiento, desde unos pocos bytes para un entero que alberga el pedido o las cantidades del inventario a unas pocas docenas de bytes para el nombre de un cliente, direccin de un empleado o descripcin del producto. Las bases de datos relacionales se han optimizado para gestionar filas que contienen hasta unas pocas docenas de columnas de este tipo de datos. Las tcnicas que utilizan para gestionar el almacenamiento en disco y para indexar los datos parten de que las filas de datos ocuparn entre unos pocos cientos y miles de bytes. Los programas que almacenan y recuperan los datos pueden albergar fcilmente docenas o cientos de estos tipos de elementos de datos en memoria, y almacenar y recuperar filas de datos de una vez mediante bferes de memoria razonablemente dimensionados. Las tcnicas de procesamiento por filas para los resultados de las consultas relacionales funcionan bien. Muchos tipos modernos de datos tienen caractersticas bastante diferentes de los datos tradicionales. Una nica imagen grfica de alta resolucin para mostrar en la pantalla del pe puede requerir cientos de miles de bytes, o ms, de almacenamiento. Un documento de un procesador de textos, como un contrato o el texto de este libro, puede ser an ms grande. El texto HTML que define las pginas web y los archivos PostScript que definen las imgenes impresas son otros ejemplos de elementos de datos orientados al documento mayores. Incluso una pista de audio de alta calidad relativamente corta puede ocupar millones de bytes, y los videoclips pueden tener cientos de megabytes o incluso gigabytes de datos. Al ser las aplicaciones multimedia ms importantes, los usuarios han deseado gestionar estos tipos de datos junto con el resto de datos en sus bases de datos. La capacidad de gestionar eficientemente los objetos grandes, frecuentemente denominados objetos grandes binarios (BLOB), fue una de las primeras ventajas reivindicadas por las bases de datos orientadas a objetos.
846
BLOB
847
en el modelo relacional
El primer enfoque para admitir BLOB en las bases de datos relacionales fue a travs del sistema operativo subyacente y su sistema de archivos. Cada elemento de datos
BLOB
Un tipo CLOB de Oracle almacena hasta 4 gigabytes de datos de caracteres de un byte en la base de datos. Un tipo NCLOB de Oracle almacena datos de caracteres multibyte como un
BLOB.
individual se almacenaba en su propio archivo del sistema operativo_ El nombre
del archivo se ubicaba en una columna de caracteres en una tabla, como un puntero al archivo. Se. poda buscar en el resto de columnas de la tabla para encontrar filas que cumplieran un cierto criterio. Cuando una aplicacin necesitaba manipular el contenido del ELOE asociado con una de las filas, lea el nombre del archivo y recuperaba los datos del BLOB. La gestin de la entrada/salida del archivo era responsabilidad de la aplicacin. Este enfoque funcionaba, pero estaba sujelO a errores y requera que un programador comprendiera las interfaces tanto del SGBDR como del sistema de archivos. La falta de integracin entre el contenido BLOB y la base de datos era aparente. Por ejemplo, no se poda pedir a la base de datos que comparara dos elementos de datos BLOB para ver si eran el mismo, y la base de datos no poda proporcionar siquiera capacidad bsica de bsqueda de texto para el contenido BLOB. En la actualidad, la mayora de los principales SGBD empresariales proporcio.nan un soporte directo para uno o ms tipos de datos BLOB. Se puede definir que una columna contenga uno de estos tipos de datos BLOB y usarla en ciertas situaciones de instrucciones SQL. Normalmente hay restricciones sustanciales con los datos BLOB; as, no se permite su uso en una condicin de reunin o en una clusula GROUP BY. Sybase proporciona dos tipos de datos de gran tamao. Su tipo de datos TEXT puede almacenar hasta dos mil millones de bytes de datos de texto de longitud variable. Se puede utilizar un conjunto limitado de capacidades SQL (tales como el operador de bsqueda de texto LIKE) para buscar el contenido de las columnas TEXT. Un tipo de datos similar IMAGE puede almacenar hasta dos mil millones de bytes de datos binarios de longitud variable. Microsoft SQL Server admite estos tipos, ms un tipo de datos NTEXT que permite hasta mil millones de caracteres de texto en lenguaje nacional de 2 bytes. DB2 de IBM proporciona un conjunto similar de tipos de datos. Un tipo de objeto de caracteres de gran tamao de DB2 (eLoB) almacena hasta dos mil millones de bytes de texto. Un tipo de objeto de caracteres de gran tamao de dos bytes en DB2 (DacLoa) almacena hasta mil millones de caracteres de 2 bytes. Un objeto binario de gran tamao de DB2 (BLoa) almacena hasta dos mil millones de daM tos binarios. Oracle ha proporcionado histricamente dos tipos de datos para objetos de gran tamao. Un tipo de datos LONG almacenaba hasta dos mil millones de datos de texto. Un tipo de datos LONG RAW almacenaba hasta dos mil millones de bytes de datos binarios. Oracle restringa el uso del tipo LONG a solamente una nica columna por tabla. Con la introduccin de Oracle8, el soporte para datos BLoa se expandi considerablemente: Un tipo. BLOB de Oracle almacena hasta 4 gigabytes de datos binarios en la base de datos.
Un tipo BFILE de Oracle almacena datos binarios de gran tamao en un archivo externo a la base de datos. Los tip~s BLOB, CLOB Y NCLOB se integran estrechamente en la operacin de Oracle, mcluyendo soporte para transacciones. Los datos BFILE se gestiona~ mediante un puntero en la base de datos hacia un archivo del sistema operatIvo externo. No est admitido por la semntica de la transaccin Oracle. Se proporcionan funciones PL/SQL especiales para manipular datos BLOB, CLOB y NCLOB desde los procedimientos almacenados PL/SQL, como se describe en la siguiente seccin. El soporte para datos de objetos de gran tamao de Universal Server de 1nfor- . mix es similar al de Oracle. Admite objetos de gran tamao sencillos y objetos de gran tamao elaborados: Un tipo BYTE Informix es un objeto de gran tamao sencillo que datos binarios. Un tipo TEXT Informix es un objeto de gran tamao sencillo que datos de texto. Un tipo BLOB Informix es un objeto de gran tamao elaborado que datos binarios. Un tipo CLOB Informix es un objeto de gran tamao elaborado que datos de texto (caracteres). almacena almacena almacena almacena
Los objetos de gran tamao Informix almacenan hasta un gigabyte de datos. Se debe recuperar o almacenar todo el objeto de gran tamao como una unidad desde la aplicacin, <.> se puede copiar entre la base de datos y un archivo del sistema operativo. Los objetos de gran tamao elaborados pueden almacenar hasta 4 terabytes de datos. Se proporcionan funciones Informix especiales para procesar objetos de gran tamao elaborados en trozos ms pequeos y manejables. Estas funciones proporcionan acceso aleatorio a los contenidos de un objeto Informix elaborado, similar al acceso aleatorio tpico proporcionado por los archivos del sistema operativo. Informix tambin proporciona controles avanzados sobre el registro histrico, la gestin de transacciones y la integridad de datos para objetos de gran tamao elaborados.
Procesamiento especializado de
BLOB
Puesto que los BLOB pueden ser muy grandes, comparados con los elementos de datos normalmente utilizados por sistemas SGBDR, cuentan con problemas especiales en varias reas:
848
'1,
----.J
Captulo 24: SOL y fos objetos
849
Almacenamiento de datos y optimizacin. Almacenar un elemento BLOS en lnea con los otros contenidos de la fila de una tabla destruira la optimizacin que el SGBD realiza para ajustar los datos de la base de datos adecuadamente en pginas que coinciden con el tamao de las pginas de disco. Por esta razn los datos BLOS siempre se almacenan en reas de almacenamiento separadas fuera de lnea. La mayora de marcas de SGBD que admiten BLOS proporcionan opciones de almacenamiento BLOB especiales, incluyendo espacios de almacenamiento con nombre que se especifican cuando se crea la columna tipo BLOB. Almacenamiento de datos BLOB en la base de datos. Debido a que un BLOS puede tener decenas o cientos de megabytes, la mayora de los programas no pueden albergar a la vez lOdos los contenidos de un 8L08 en un bfer de memoria. Procesan porciones del 8L08 cada vez (por ejemplo, pginas de un documento de gran tamao o imgenes individuales de un videt\~). Sin embargo, las API de SQL incorporado y SQL normal estn diseMdas para un procesamiento por filas (mediante las instrucciones INSERT y UPDATE) que almacena los valores para todas las columnas en la fila cada vez. Se requieren tcnicas especiales para poner los datos en una columna BL08 de una base de datos trozo a trozo, mediante varias llamadas a la API por columna 8LOB. Recuperacin de datos BLQB de la base de datos. ste es el mismo tema que recuperar los datos, pero a la inversa. Las API de SQL incorporado y SQL normal estn diseadas para el procesamiento de la instruccin SELECT O la instruccin FETCH, que recuperan los valores de los datos para todas las columnas de una fila cada vez. Sin embargo, debido a que un valor 8LOB almacenado puede tener decenas o cientos de megabytes, 10 normal es que la mayora de los programas no puedan almacenar todos a la vez en un bfer de memoria. Se requieren tcnicas especiales para recuperar los datos de la columna 8L08 de la base de datos, trozo a trozo. de forma que la aplicacin los pueda procesar. Registro histrico de transacciones. La mayora de los SGBD admiten las transacciones mediante el mantenimiento anterior y posterior de las imgenes de datos posteriores en un registro histrico de transacciones. Debido al potencial mayor tamao de los datos BL08, la sobrecarga del registro histrico podra ser extrema. Por esta razn muchas SGBD no admiten el registro histrico de datos BLOB o permiten el registro histrico, pero proporcionan la posibilidad de activarlo y desactivarlo. Varios SGBD solucionan estos problemas mediante API extendidas que admiten especficamente manipulacin BLOB. Estas llamadas proporcionan acceso aleatorio a segmentos individuales de los contenidos BLOB, permitiendo al programa recuperar o almacenar el BLOB en trozos manejables. Oracle8 introdujo esta capacidad para manipular sus tipos de datos LOS (caracteres y binarios) en procedimientos almacenados escritos en el lenguaje PUSQL. Estas capacidades son similares a las proporcionadas por otras bases de datos relacionales orientadas a objetos, tales como Universal Server de Informix.
Cuando un procedimiento almacenado lee una columna L08 de una tabla, GracIe no devuelve realmente los contenidos de la columna, sino que devuelve un localizador de los datos LOB (en trminos de objetos, un controlador para el LOB). El localizador se utiliza junto a nueve funciones de procesamienlo de L08 especiales que el procedimiento almacenado puede entonces utilizar para manipular los datos almacenados reales en la columna LOB de la base de datos. Veamos una breve descripcin de cada funcin de procesamiento LOB:
dbms_lob. read
(localizador, nmero, desplazamiento, bfer). Lee en el bfer PL/SQL el nmero indicado de bytes/caracteres del L08 identificado por el localizador, comenzando por el desplazamiento. dbms_lob.write (localizador, nmero, desplazamiento, bfer). Escribe el nmero indicado de bytes/caracteres del bfer PUSQL en el LOB identificado por el localizador, comenzando por el desplazamiento. dbms_lob.append (localizadorl, localizador2). Agrega todo el contenido del LOB identificado por localizador2 al final de los contenidos del LOB ideo tificado por localizador}. dbms_lob. erase (localizador, nmero, desplazamiento). Borra los contenidos del L08 identificado por el localizador en desplazamiento con un n mero de bytes/caracteres; para LOS basados en caracteres se insertan espa cios, y para L08S binarios se insertan ceros binarios. dhms_l.ob.copy (localizadorl, localizador2, nmero, desplazamientol, desplazamiento2). Copia nmero de bytes/ caracteres del LOB identificado por localizador2 de desplazamienro2 en el LOB identificado por localizador} de desplazamiento}. dbms_lob.trim (localizador!, nmero). Ajusta el L08 identificado por el. localizador al nmero indicado de bytes/caracteres. dbms_lob. substr (localizador, nmero, desplazamiento). Devuelve (como una cadena de texto devuelve un valor) el nmero indicado de bytes/caracte res del L08 identificado por el localizador, comenzando por el desplazamiento; el valor devuelto de esta funcin se puede asignar a una variable PUSQL
VARCHAR.
(localizador). Devuelve (como valor entero) el nmero de bytes/caracteres del LOB identificado por el localizador. dbms_lob. compare (localizadorl, localizador2, nmero, desplazamientol, desplazamiento2). Compara el LOB identificado por localizadori con el LOB identificado por localizador2, comenzando por desplazamiento} y desplazamiento2 respectivamente, para un nmero de bytes/caracteres; devuelve cero si son el mismo, y un valor distinto si no lo son. dbms_l.ob.instr (localizador, patrn, desplazamiento, i). Devuelve (como un valor entero) la posicin en el LOB identificado por el localizador donde coincide la i-sima ocurrencia del patrn; el valor devuelto se puede utilizar como un desplazamiento en llamadas posteriores de procesamiento L08.
dbms_lob.getlength
Oracle impone una restriccin ms sobre las actualizaciones y modificaciones de los valores L08 que se realizan mediante estas funciones. Los L08S pueden im-
----
850
851
poner una sobrecarga inaceptablemente alta sobre los mecanismos de transaccin de Gracle, por lo que Oracle normalmente no bloquea los contenidos de un elemento de dato Loa cuando se lee la fila que contiene el LOB mediante una aplicacin O rutina PUSQL. Si se van a actualizar los datos LOE, la fila debe estar bloqueada explcitamente antes de modificarla. Esto se hace mediante la inclusin de una clusula FOR UPDATE en la instruccin SELECT que recupera el localizador LOB. Veamos un fragmento PUSQL que recupera una fila que contiene un LOB el cual, a su vez, contiene texto documental y actualiza 100 caracteres en el medio de los datos LOE:
declare
puede tratar como una nica unidad cuando es, ms conveniente. Los tipos de datos estructurados o compuestos en las bases de datos relacionales orientadas a objetos proporcionan la misma capacidad en un contexto SOBD, Universal Server de lnformix admite los tipos de datos abstractos mediante el concepto de tipos de datos fila, Se pue(1e pensar en un tipo fila como en una secuencia estructurada de elementos de datos individuales, denominados campos. Veamos una instruccin CREATE TABLE de Informix para una tabla sencilla .PERSONAL que utiliza un tipo de datos fila para almacenar informacin del nombre y la direccin:
CREATE TABLE NUM_EMPL NOMBRE NOMBRE INICIAL APELLIDOS DIRECCION CALLE CIUDAD PROVINCIA CODIGOPOSTAL PRINCIPAL SUFIJO PERSONAL INTEGER, ROW( VARCHAR(IS). CHAR(l), VARCHAR(20 ROW ( VARCHAR(35), VARCHAR{15), CHAR(21. ROW( INTEGER, INTEGER);
'ob
begin
CLOB buftexto varchar (255) ;
/* Poner el texto a insertar en el bfer /
/* Obtener el localizador de LOB y bloquear las actualizaciones del LOB */
select from where for
document_lob into lob documentos id_documento = '34218' update;
/* Escribir 500 nuevos bytes de texto en el LOB */
dbms_lob.write(lob,lOO,500,buftexto); cornmit; end;
Tipos de datos abstractos (estructurados)

Los tipos de datos contemplados en el modelo de datos relacional son valores de datos sencillos, indivisibles y atmicos, Si un elemento de datos como una direccin est realmente compuesto por la direccin de una calle, ciudad, provincia y cdigo postal, se tienen dos opciones como diseador de bases de datos: se puede tratar la direccin como cuatro elementos de datos separados, cada uno almacena-. do en su propia columna, por lo que se pueden buscar y recuperar los elementos de forma individual; o se pueden tratar las direcciones como una nica unidad, en cuyo caso no se pueden procesar sus componentes individuales en la base de datos. No hay trmino medio que pennita tratar la direccin como una unidad para ciertas situaciones y acceder a sus componentes para otras. Muchos lenguajes de programacin (incluso lenguajes no orientados a objetos como e o Pascal) proporcionan este trmino medio, Admiten los tipos de datos compuestos o las estructuras de datos con nombre, La estructura de datos se compone de elementos de datos individuales o estructuras de menor nivel, a las cuales se puede acceder de forma individual. Sin embargo, toda la estructura de datos se
Esta tabla tiene tres columnas. La primera, NUM_EMPL, tiene tipo de datos entero, Las ltimas dos, NOMBRE y DIRECCION, tienen un tipo de datos fila indicado por la palabra clave ROW seguida por una lista entre parntesis de los campos que forman la fila, El tipo de datos de la fila de la columna NOMBRE tiene tres campos, El tipo de datos de la fila de la columna DIRECClN tiene cuatro campos. Los ltimos cuatro campos tienen un tipo de datos fila y consisten en dos campos, En este ejemplo sencillo, la jerarqua slo tiene dos niveles de profundidad, pero la capacidad puede (y frecuentemente lo hace) extenderse a niveles adicionales. Los campos individuales de las columnas de la tabla son accesibles a las instrucciones SQL mediante una extensin de la notacin SQL de puntos que ya se utiliza para calificar los nombres de una columna con los nombres de la tabla y los nombres de usuario. Al agregar un punto despus del nombre de la columna, se permite especificar los nombres de los campos individuales en una columna. Esta instruccin SELECT recupera el nmero de empleado y el primer y ltimo nombre de todo el personal con un cdigo postal especificado:
SELECT NUM_EMPL, NOMBRE.NOMBRE, NOMBRE,APELLIDOS PROM PERSONAL WHERE DIRECCION.CODIGOPOSTAL.PRINCIPAL = '28';
Supongamos que otra tabla en la base de datos, denominada JEFES, tena la misma estructura NOMBRE que una de sus columnas, Entonces esta consulta recupera los nmeros de los empleados que tambin son jefes:
SELECT NUM_EMPL FROM PERSONAL, JEFES WHERE PERSONAL,NOMBRE
JEFES.NOMBRE;
852
'CIUDAD VARCHAR(151, PROVINCIA CHAR(2). CODIGOPOSTAL TIPO_POSTAL);
Capitulo 24: SaL y los objetos
853
En la primera de estas dos consultas tiene sentido recuperar los campos individuales en la columna NOMBRE. La segunda consulta muestra una situacin en la que es ms conveniente utilizar el nombre de columna completo (los tres campos) como base para la comparacin. Es claramente mucho ms conveniente pedir al SaBD que compare las columnas con los tipos abstractos de datos que especificar comparaciones -separadas para cada uno de los campos individuales. En conjunto, estos ejemplos muestran la ventaja del tipo de datos fila en permitir acceso a los campos en cualquier nivel de jerarqua. Las columnas de tipos de datos fila requieren una gestin especial cuando se insertan datos en la base de datos. La tabla PERSONAL tiene tres columnas, por lo que una instruccin INSERT para la tabla debe tener tres elementos en su clusula VALUES. Las columnas que tienen un tipo de datos tila requieren una constructora ROW especial para poner juntos los elementos de datos individuales en un elemento del tipo fila que coincida con el tipo de datos de la columna. Veamos una instruccin INSERT vlida para la tabla que ilustra el uso de la constructora ROW:
INSERT INTO PERSONAL VALUES {1234, ROW( 'Jos', 'J.', 'Garca'}, ROW('Rosa, 197', 'Castuera', ROW(OG. 420));
Obsrvese que la definicin de un tipo fila con nombre puede depender de otros tipos fila con nombre previamente creados, como se muestra en las definiciones TIPO_DIR y TIPO_POSTAL. Con estos tipos de datos fila, las columnas del nombre y la direccin en la tabla PERSONAL (y cualquier otra columna que alberga datos del nombre o direccin en otras tablas de la base de datos) se pueden definir mediante su uso. El uso agresivo de los tipos de datos abstractos puede por ello ayudar a tener uniformidad en la asignacin de nombres y en los tipos de datos en una base de datos relacional orientada a objetos. Veamos la nueva definicin Informix de la tabla PERSONAL mediante el uso de los tipos de datos abstractos que se acaban de definir:
CREATE TABLE NUM_EMPL NOMBRE DIRECCION PERSONAL INTEGER. TIPO_NOMBRE, TIPO_DIR);
'EX',
Definicin de tipos abstractos de datos

Con las capacidades del lipa de datos fila de Informix ilustradas hasta ahora, cada columna estructurada individual se define aisladamente. Si dos tablas necesitan utilizar la misma estructura de tipo de datos fila, hay que definirlas en cada tabla. Esto viola una de los principios claves del diseo orientado a objetos, que es la reutilizacin. En lugar de hacer que cada objeto (las dos columnas en las dos tablas distintas) tenga su propia definicin, el tipo de datos fila se debera definir una vez y entonces reutilizarlo para las dos columnas. Universal Server de Informix proporciona esta capacidad mediante su caracterstica tipo fila COIl nombre (1os tipos de datos fila mostrados en el ejemplo anterior son tipos de datos fila sin nombre). Con la instruccin CREATE ROW TYPE se crea un tipo fila con nombre Informix. Veamos ejemplos de la tabla PERSONAL:
CREATE ROW NOMBRE INICIAL APELLIDOS TYPE TIPO_NOMBRE VARCHAR(lS) , CHAR(l), VARCHAR(20});
La Figura 24.1 muestra algunos ejemplos para esta tabla y la estructura jerrquica de columnas y campos creada por los tipos de datos abstractos. OracIe admite tipos de datos abstractos mediante una estructura muy similar, con una sintaxis SQL ligeramente diferente. Veamos la instruccin CREATE TYPE para crear la misma estructura de datos abstractos para los nombres y direcciones:
CREATE TYPE NOMBRE INICIAL APELLIDOS TIPO_NOMBRE AS OBJECT ( VARCHAR(15), CHAR(ll. VARCHAR(20);
CREATE TYPE TIPO_POSTAL AS OBJECT ( PRINCIPAL INTEGER, SUFIJO INTEGER); CREATE TYPE CALLE CIUDAD PROVINCIA CODIGOPOSTAL TIPO_DIR AS OBJECT VARCHAR(3Sl. VARCHAR{lSI, CHAR(2). TIPO_POSTAL);
.,
CREATE ROW TYPE TIPO_POSTAL PRINCIPAL INTEGER. SUFIJO INTEGER); CREATE ROW TYPE TIPO_DIR CALLE VARCHAR(3SJ,
Orade llama al tipo de datos abstracto un objeto en lugar de tipo fila. En realidad, el tipo funciona como una clase objeto en la terminologa usual orientada a objetos. Ampliando ms la terminologa orientada a objetos, los componentes individuales de un tipo de datos abstracto Orade se refieren como atributos (correspondientes a los campos Informix descritos anteriormente). El tipo TIPO_DIR tiene cuatro atributos en este ejemplo. El cuarto atributo. CODIGOPOSTAL, es en s mismo un tipo de datos abstracto. Oracle e Informix utilizan la notacin de punto extendida para referirse a elementos de datos individuales en tipos de datos abstractos. Con los tipos abstractos
854
Captulo 24: SOL y fos objetos
855
Tabla PERSONAL
DIRECCIN
NtJ!.LEMPL
Adems de este uso, las tablas con tipos tambin son un componente clave de la nocin Informix de la herencia de tablas, descrito posteriormente en la seccin Herencia.
I CODIGOPQSTAI
SUPIJ
NOMBRE
INICIAL
IAPELLlOOSI
KaJetn Ordi\ez Garca Matas
CALLE
CIUDAD
I Pltl:NINCIA PRIIt1~
H
AN
1234 sus,'m", 1374 Samuel 1421 Jos 1532 RobertO
S. S. J. R.
Mayor,)1 Beln, 104 Rosa, 197 Cava
Madrid
Sevilla C<tstuera Barcelona
EX CA
28 40 06 08
032 001 420 020
Manipulacin de tipos abstractos de datos

Desafortunadamente, los tipos de datos estructurados crean nuevas complicaciones para las instrucciones de actualizacin de la base de datos que deben insertar amo dificar sus valores de datos estructurados. Universal Server de Informix es bastante liberal en sus requisitos de conversin de los tipos de datos para tipos fila sin nombre. Los datos que se asignan a una columna de tipo fila deben simplemente tener el mismo nmero de campos, de los mismos tipos de datos. Se utiliza la constructora ROW, como se mostr en los ejemplos anteriores, para construir elementos de dalas individuales en un valor de tipo fila para insertar o actualizar datos. Para los tipos fila con nombre, los requisitos son ms restrictivos~ los datos que se asignan a una columna de Lipo fila con nombre deben tener realmente el mismo tipo fila con nombre. Se puede lograr esto en la instruccin INSERT convirtiendo de forma explcita el valor al tipo fila construido para tener el tipo de datos
TIPO_NOMBRE:

Figura 24.1. Tabla PERSONAL que utiliza tipos de datos abstractos.
anidados se tienen varios niveles de nombres delimitados por puntos para identificar un ~leme.nto de dalOs individual. El cdigo poslal principal en la labia PERSONAL se ldenufica como:
PERSONAL.DIRECCION.CODIGOPOSTAL PRINCIPAL
Si la tabla perteneciera a otro usuario, SamueI, el nombre calificado sera incluyo mayor:
SAMUEL.PERSONAL.DIRECCION.CODIGOPOSTAL.PRINCIPAL
INSERT INTO PERSONAL VALUES (1234. ROW{ 'Jos', ' J . ' , 'Garcia'): :TIPO_NOMBRE, ROW('Rosa, 197', 'Castuera' , 'EX', ROW{06, 420)));
el uso de tipos fila para ir un paso ms all de su funcin c.omo plantdlas de upo de datos para columnas individuales. Se puede utilizar un upo ~l~.. para ~efinir la estructura de una tabla completa. Por ejemplo, con esta defimclOn de tIpO fila:
CREATE ROW NUM_EMPL NOMBRE DIRECCION TYPE TIPO_PERS INTEGER, TIPO_NOMBRE, TIPO_DIR)
PERSONAL
Informi~ permit~
se puede definir la tabla
utilizando el tipo fila como modelo:
CREATE TABLE PERSONAL OF TYPE TIPO_PERS;
El operador dos puntos dobles convierte la fila construida de tres campos en una fila TIPO_NOMBRE y hace que la clusula VALUES sea compatible con los tipos de datos de las columnas en la tabla. Gracle utiliza un enfoque ligeramente diferente para construir elementos de datos estructurados e insertarlos en columnas que- tienen tipos de datos abstractos. Cuando se crea un tipo de datos abstracto (mediante el uso de la instruccin CREATE TYPE), Oracle define automticamente un mtodo constructor para el tipo. Se puede pensar en el mtodo constructor como una funcin que toma como argumentos los componentes individuales del tipo de datos abstracto y devuelve un valor de tipo de datos abstracto, con todos los componentes abstractos empaquetados juntos. La constructora se utiliza en la clusula VALUES de la instruccin INSERT para pegar los valores de los elementos de datos individuales en un valor de datos estructurados que coincide con la definicin de la columna. Veamos una instruccin INSERT para la tabla PERSONAL:
INSERT INTO PERSONAL VALUES {1234, TIPO_NOMBRE (' Jos', ' J ' . 'Garcia'), TIPO_DIR( 'Rosa, 197', 'Castuera', 'EX', TIPO_POSTAL(06, 420}));
. Las colum~as de esta tabla PERSONAL sern exactamente como eran en los ejemplos anten.ores CREATE T~BLE, pero ahora PERSONAL es una tabla con tipos. El .uso ms bsIco de la capacIdad de tabla con tipos es formalizar la estructura de ~bJeto en la base de dato.s. Cada clase objeto tiene su propio tipo fila, y la tabla con tipos que alberga los objetos (filas) de esa clase se define en funcin del tipo fila.
856
Captulo 24: SQL y los objetos
857
Las constructoras (TIPO_NOMBRE, TIPO_OIR, TIPO_POSTAL) realizan las mismas funciones que la constructora ROW realiza en Informix y tambin proporciona la conversin de tipos requerida para asegurar la correspondencia de tipos de datos estricta.
Herencia
El soporte para tipos de datos abstractos da al modelo de datos relacional un fundamento para las capacidades basadas en objetos. El tipo de datos abstracto puede incorporar la representacin de un objeto, y los valores de sus campos individuales o subcolumnas son sus atributos. Otra caracterstica importante del modelo orientado a objetos es la herencia. Con la herencia se pueden definir nuevos objetos como un tipo particular de un tipo de objeto existente (clase) y heredar los atributos predefinidos y comportamientos de ese tipo. La Figura 24.2 muestra un ejemplo de cmo puede funcionar la herencia en un modelo de datos de los empleados de una compaa. Todos los empleados son miembros de la clase PERSONAL y todos tienen los atributos asociados con ser un empleado (nmero de empleado, nombre y direccin). Algunos empleados son fabricantes y tienen atributos adicionales (tales como una cuota de ventas y la identidad de su gestor de ventas). Otros empleados son ingenieros, con un conjunto diferente de atributos (tales como los grados acadmicos o el proyecto actual al que estn asignados). Cada uno de estos tipos de empleados tiene su propia clase, que es una subclase de PERSONAL. La subclase hereda todas las caractersticas de la clase superior en la jerarqua (se desea recorrer todos los datos principales del personal, tambin en el caso de ingenieros y fabricantes). Sin embargo, las subclases tienen informacin adicional nica para su tipo de objeto. En la Figura 24.2 la herencia de clase baja a una tercera capa para los ingenieros, diferenciando entre tcnicos, desarrolladores y gestores.
El mecanismo de herencia de tipos abstractos de datos de Universal Server de Informix proporciona una forma sencilla de definir los tipos de datos abstraeros (tipos fila de Informix) que corresponden a la herencia natural de la Figura 24.2. Consideremos que ya se ha creado el tipo fila TIPO_PERS Inforrnix, como en el ejemplo de la seccin Definicin de tipos abstractos de datos, de este captulo, y se ha creado una tabla con tipos, denominada PERSONAL, basada en este tipo fila. Veamos algunas instrucciones CREATE ROW TYPE que utilizan las capacidades de herencia de Informix para otros tipos de la jerarqua:
CREATE ROW TYPE TIPO_VENTAS JEF_VEN INTEGER, SUELDO HONEY (9,2) , CUOTA MONEY(9,2)) UNOER TIPO_PERS; CREATE ROW SUELDO EXPER UNDER TYPE TIPO_ING HONEY(9,2), INTEGER TIPO_PERS;
'*
,. Nmero de empleado del jefe de ventas Sueldo anual
*'
*'
'*
/* Aos de experiencia */
Sueldo anual
*'
CREATE ROW TYPE TIPO_JEF COMP MONEY(9,2)) UNDER TIPO_ING; CREATE ROW TYPE TIPO_TEC SUELDO_HORA MONEY(5,2)) UNDER TIPO_ING;
'*
Complemento anual
*'
,. Sueldo por hora .,
Representantes
(TIPO_VENTAS)
Ingenieros
(TIPO_ING)
El tipo definido para los tcnicos (TIPO_TEC) es un subtipo (subclase) del tipo ingeniero (TIPO_ING), por lo que hereda todos los campos del tipo del personal (TIPO_PERS), ms los campos agregados en el nivel TIPO_ING, ms el campo adicional agregado en su propia definicin. Un tipo abstracto que se define bajo (UNDERl otro tipo y hereda sus campos se denomina subtipo del tipo de nivel superior. A la inversa, el tipo de nivel superior es un supertipo de los tipos de nivel definidos por debajo (UNDER). Con este tipo de jerarqua definida es sencillo para Inforrnix crear las tablas con tipos que las utilizan. Veamos algunas instrucciones lnformix que crean una tabla para ingenieros, tablas separadas para gestores y tcnicos, y otra tabla para albergar los datos de los fabricantes:
CREATE TABLE OF TYPE CREATE TABLE OF TYPE CREATE TABLE OF TYPE CREATE TABLE OF TYPE INGENIEROS TIPO_ING; TECNICOS TIPO_TEC; JEFES TIPO_JEF; REPS TIPO_VENTAS;
Tcnicos
(TIPO_TEC)
Jefes (TIPO_JEF)
Figura 24.2.. Jerarqua de clase natural para una aplicacin de personal.
858
859
La jerarqua de tipos ha subvertido la complejidad de las definiciones de los tipos de datos y ha hecho que la estructura de la tabla sea muy sencilla y fcil de definir. El resto de caractersticas de la tabla pueden (y deben) todava estar definidas en la definicin de la tabla. Por ejemplo, la tabla de fabricantes contiene una columna que es realmente una clave principal a la tabla de personal, por lo que sus definiciones de tabla podran incluir, probablemente, una clusula FOREIGN KEY como sta:
CREATE TABLE QF TYPE FOREIGN KEY REFERENCES REPS TIPO_VENTAS (JEF_VEN) PERSONAL (NUM_EMPL) ;
todava se basan en una jerarqua de tipos definida, pero ahora tienen entre s una jerarqua paralela. Veamos un conjunto de instrucciones CREATE TABLE que implementan esta herencia de tabla.
CREATE TABLE OF TYPE UNDER CREATE TABLE OF TYPE UNDER CREATE TABLE OF TYPE UNDER CREATE TABLE OF TYPE UNDER INGENIEROS TIPO_ING PERSONAL; TECNICOS TIPO_TEC INGENIEROS; JEFES TIPO_JEF INGENIEROS; REPS TIPO_VENTAS PERSONAL;
La herencia de tipos crea un vnculo en la estructura de las tablas que se basan en los tipos fila definidos._ pero las tablas permanecen independientes entre s en funcin de los datos que contienen. Las filas insertadas en la tabla TECNICOS no aparecen automticamente en la tabla INGENIEROS ni en la tabla PERSONAL. Cada una es una tabla independiente que contiene sus propios datos. Una clase diferente de herencia, la herencia de tablas, proporciona un nivel muy diferente de vnculo entre los contenidos de la tabla, haciendo que las tablas sean muy parecidas a las clases de objetos. Se describe en la siguiente seccin.
Herencia de tablas: implementacin de clases de objetos

Universal Server de Informix proporciona una capacidad denominada herencia de tabla que cambia la estructura de la tabla de una base de datos desde el modelo relacional tradicional y la transforma en algo ms parecido al concepto de una cla,.se de objetos. Me,diante el uso de la herencia de tabla es posible crear unajerarqUIa de tablas con tipOS (clases), como la mostrada en la Figura 24.3. Las tablas
'
I
J
(TIPO_PERS)
PERSONAL
I
I
I
r
Figura 24.3.
UNDER
REPS
\UNDER INGENIEROS (TIPO_ING) UNDERj
Cuando se define de esta forma una tabla (como bajo otra tabla), hereda muchas caractersticas de su supertabla adems de la estructura de la columna, Hereda la clave externa, la clave principal, la integridad referencial y las restricciones de comprobacin de la supertabla, cualquier desencadenador definido en la supertabla, as como ndices, reas de almacenamiento y otras caractersticas especficas de Informix. Es posible evitar esta herencia especficamente incluyendo las caractersticas omitidas en las instrucciones CREATE TABLE de las supertablas. Una jerarqua de tipos de tablas tiene un profundo impacto en la forma en la que el SGBD Universal Server trata las filas almacenadas en las tablas. Las tablas en la jerarqua forman ahora una coleccin de conjuntos anidados, como se muestra en la Figura 24.4. Cuando se inserta una fila en la jerarqua de tabla se sigue insertando en una tabla en concreto. Juan Garca, por ejemplo, est en la tabla TECNICOS, mientras que Samuel Ordez est en la tabla INGENIEROS Y Susana Martn est en la tabla PERSONAL. Sin embargo, las consultas SQL se comportan de una formabastante diferente. Cuando se realiza una consulta en una base de datos sobre una de las tablas en la jerarqua, se devuelven no solamente las filas de la tabla, sino tambin de todas las subtablas incluidas en esa tabla. Esta consulta:
SELECT FROM PERSONAL;
(TIPO_VENTAS)
,1
",UNDER JEFES (TIPO_JEFF)
,
I
I
NICOS
devuelve las filas de la tabla PERSONAL y las filas de las tablas y REPS. De igual forma, esta consulta:
SELECT FROM INGENIEROS;
INGENIEROS, TEC-
TCNICOS (TIPO_TEC)
Una jerarqua de herencia de tablas en Informix.
devuelve las filas de TECNICOS y JEFES adems de INGENIEROS. El SGBD trata ahora las tablas como una coleccin anidada de filas, y una consulta sobre una
860
861
Conjunto PERSONAL
La misma lgica se aplica para las instrucciones UPDATE. La siguiente cambia el nmero de empleado, sin considerar en qu tabla de la jerarqua est la fila del empleado:
UPDATE PERSONAL SET APELLIDOS: 'CastaBo' WHERE NUM_EMPL = 1234;
Conjunto INGENIEROS
--------
Conjunto REPS
Conjunto TECNICOS
Nuiia Yepes
......------...
Conjunto JEFES
De nuevo, la construccin ONLY se puede utilizar para restringir el mbito de la operacin UPDATE a solamente las filas que aparecen en la tabla con nombre y no en las que aparecen en sus subtablas. Por supuesto, cuando se opera en un nivel dado en la jerarqua de tabla, las instrucciones SQL se pueden referenciar solamente a las columnas que se definen en ese nivel. No se puede utilizar esta instruccin:
DELETE FROM PERSONAL WHERE SUELDO < 20000.00;
puesto que la columna SUELDO no existe en la tabla PERSONAL de mayor nivel (clase). Se define solamente para algunas de sus subtablas (subclases). Se puede utilizar esta instruccin:
Figura 24.4. Conjuntos anidados representados por una jerarqua de herencia
de tablas.
DELETE FROM JEFES WHERE SUELDO < 20000.00;
tabla (conjunto de filas) se refiere a todas las filas incluidas en el conjunto. Si se desean recuperar solamente las filas que aparecen en el nivel superior de la tabla, se debe utilizar la palabra clave ONLY:
SELECT FROM ONLY(INGENIEROS};
TE.
El SGBD aplica la misma lgica del conjunto de filas a las operaciones Esta instruccin DELETE:
DELE-
DELETE FROM PERSONAL WHERE NUM_EMPL : 1234;
borra de fonna satisfactoria la fila del nmero de empleado 1234 sin importar qu tabla de la jerarqua comiene la fila. La instruccin se interpreta como borra cualquier fila del conjunto PERSONAL que cumpla este criterio. Como con las consultas, si se desea borrar solamente las filas que aparecen en la tabla INGENIEROS de la jerarqua, pero no las filas de cualquier otra de sus subtablas, se puede utilizar esta instruc.cin:
DELETE FROM.ONLY(INGENIEROSl WHERE NUM~EMPL : 1234;
puesto que SUELDO se define en este nivel de la jerarqua de la tabla (clase). Como se observ, la herencia de la tabla mueve la operacin de Universal Server de Informix bastante lejos del campo de la base de datos relacional y dentro el mu~orientado a objetos. Los puristas relacionales apuntan a ejemplos como el antenor para defender que las bases de datos relacionales orientadas a objetos traen consigo peligrosas inconsistencias. Realizan esta clase de preguntas: por qu un INSERT de una fila en una tabla debera provocar que de repente apareciera en otras dos tablas? Y por qu una instruccin DELETE buscada que no coincide con ninguna fila de la tabla debera provocar que otras- filas de otras tablas desaparecieran? Por supuesto, la jerarqua de tablas ha dejado de comportarse estrictamente como si fuera un conjunto de tablas relacionales y en su lugar ha adoptado muchas de las caractersticas de una clase de objetos y una jerarqua de clases de objetos. Si esto es bueno o malo depende del punto de vista. Significa que se debe ser muy cuidadoso al aplicar suposiciones en la base de datos relacional en una implementacin relacional orientada a objetos
Conjuntos, arrays y colecciones

En una base de datos relacional, las tablas son solamente la estructura utilizada para representar un conjunto de objetos. Por ejemplo, el conjunto de ingenieros en nuestra base de datos de personal se representa por las filas de la tabla INGENIE-
----
862
863
ROS. Supongamos que cada ingeniero tiene un conjunto de ttulos acadmicos (por ejemplo, un licenciado en Ciencias Fsicas por la UCM, un doctor en Ingeniera Elctrica de Barcelona, elc.) q~e se van a almacenar en la base de datos. El nmero de ttulos de cada ingeniero variar (de ninguno para algunos ingenieros a quizs media docena para otros). En una hase de datos relacional pura hay solamente una forma correcta de agregar esta informacin al modelo de datos. Se debe crear una nueva tabla, TITULOS, como se muestra en la Figura 24.5. Cada fila en la tabla TITULOS representa un ttulo acadmico individual que tiene alguno de los ingenieros. Una columna en la tabla TITULOS alberga el nmero de empleado del ingeniero que tiene el ttulo descrito en una fila particular y sirve como clave externa a la tabla INGENIEROS, vinculando las dos tablas en una relacin padre/hijo. Las otras columnas en la tabla TITULaS describen las particularidades del ttulo. Se ha visto el tipo de estructura de tabla relacional padrelhijo. mostrada en la Figura 24.5. muchas veces a lo largo de los captulos anteriores y ha sido una construccin bsica de las bases de datos relacionales desde el comienzo. Sin embargo. hay algunas desventajas en el hecho de que sea sta la nica forma de modelar los conjuntos de atributos de datos. En primer lugar, la base de datos tiende a tener una gran cantidad de tablas y relaciones de claves externas, y resulta difcil de comprender. En segundo lugar, muchas consultas comunes necesitan reunir tres, cuatro O ms tablas para obtener las respuestas requeridas. En tercer lugar, con las implementaciones de las reuniones relacionales proporconadas por la mayora de los SGBD. el rendimiento de las consultas se deteriorar, al suponer ms y ms reuniones.
Un modelo orientado a objetos de los ingenieros y sus ttulos tendera a rechazar la estructura de tabla de la Figura 24.5. Sostendra que los ttulos no son objetos sustanciales por s mismos, por lo que no merecen su propia tabla. En realidad son atributos del ingeniero que alberga los ttulos. Ciertamente, se asocia a cada ingeniero un nmero variable de ttulos, pero el modelo orientado a objetos no tendra problema con representar esta situacin como un array o un conjunto de datos en el objeto ingenieros. Las bases de datos relacionales orientadas a objetos incorporan la vista orientada a objetos de los datos y admiten conjuntos, arrays y otros tipos de datos ~e la coleccin. Se puede definir una columna en una tabla para tener uno de estos tipOS de datos. Entonces contendr no un nico elemento de datos, sino un conjunto de elementos de datos. Las extensiones especiales de SQL permiten a un usuario, o ms frecuentemente a un procedimiento almacenado. manipular el conjunto de datos como un todo o acceder a los miembros individuales del conjunto.
Definicin de colecciones
Universal Server de Infonnix incorpora las colecciones de atributos mediante sus tipos de datos coleccin. Alberga tres tipos diferentes de datos coleccin: Listas. Una lista es una coleccin ordenada de elementos de datos, los cuales tienen el mismo tipo. En una lista existe el concepto de primer elemento, ltimo elemento y n-simo elemento. Los elementos en la lista no. tienen por qu ser nicos. Por ejemplo, una lista de los nombres de los empleados contratados en el ltimo ao, en orden de contratacin, podra ser {'Javier', 'Mara', 'Samuel', 'Jacinto', 'Juan'}. Multiconjuntos. Un multiconjunto es una coleccin desordenada de elementos de datos todos los cuales tienen el mismo tipo. No hay un concepto de secuencia ~n los elementos de un multiconjunto; sus elementos no tienen implcito un orden. Los elementos no tienen por qu ser nicos. La lista de los nombres de los empleados se puede considerar un multiconjunto si no importa el orden de contratacin: {'Jacinto', 'Samuel', 'Juan', 'Jacinto', 'Mary'}. Conjuntos. Un conjunto es una coleccin desordenada de elemen~os ~e datos nicos todos los cuales tienen el mismo tipo. Como en un multIconJunto, no hay co~cepto de primero o ltimo; el conjunto no tiene orden implcito. Los elementos deben ser valores nicos. Los nombres en los ejemplos anteriores no seran un buen ejemplo, pero los apellidos podran serlo: {'Garca', 'Ordez', 'Martn" 'Azaedo', 'Snchez'}. Para ilustrar el concepto de datos de la coleccin, expandiremos las tablas en nuestro ejemplo de base de datos relacional orientada a objetos, como sigue: La tabla REPS incluir los objetivos de ventas para el primero, segundo, tercer y cuarto trimestre. Los objetivos trimestrales se pueden representar de forma natural como una columna de tipo lista agregada a la tabla REPS. Los
Tabla INCENIEl{()S
I
NUH.-OlPLI NOKIlRE
-~
Susana Sa!llUel Josll
I
1
CALLE Mayor, 31 Beln, 104
Rosa.
DIRECCIN CIUDAD IJ ICODlGOPOSTAL PROVIOCIAlPlI!l:IP"'4SUF1JO
1INICIAL IAP!Lt.lOOsl
1234
1374 1421 1534:
,. ,.
J.
Martn Ord6t1ez Garcia
U7
Madrid Sevilla ~ Ca.tuera EX
'" " "
001
no
'"
45.000 30.000e: 34 .SOO:
~,J
EXPER
, , "
Tabla TTULOS
NUM-.U!PL
"TUW UNIVERSIDAD
Cl11ve exeernll
12)4 1234 137& 1421
'1"
= " = "'" 'l "'"

OC,
~
ClC
Figura 24.5.
Modelo relacional de los ingenieros y sus ttulos.
864
Captulo 24: SOL V los objetos
865
trimestres tienen un orden natural (primero a cuarto), la cuota para cada trimestre Liene el mismo tipo de dalos (money) y los valores no son necesariamente nicos (es decir, las cuotas para el primer y segundo trimestre pueden
ser la misma). La tabla INGENIEROS incluir informacin sobre los tlUlos acadmicos que cada ingeniero tiene. Se almacenarn dos elementos de dalos sobre cada ttulo: el ttulo real (licenciado, doctor, ingeniero superior, etc.) y la universi-
Tabla REPS tfOKBRE NUM,J:KPL tDreRE HUCIA!. Al'EU.ltCS PlRECCIfl'
4261 Nuria
N.
Vepcs
dad. Estos datos se almacenarn en una columna rnulticonjunto agregada a la tabla INGENIEROS, porque es posible tener dos entradas idnticas (por ejemplo, un ingeniero puede tener un ttulo de licenciado en ingeniera y un ttulo de licenciado en empresariales en la misma universidad). La tabla TECNICOS incluir informacin sobre los proyectos a que cada tcnico est asignado. Cada tcnico puede tener asignados dos o ms proyectos, pero cada proyecto tiene un nombre nico. Este dato se almacenar como una columna de tipo conjunto agregada a la tabla TECNICQS. El valor de los datos debe ser nico, pero no se asocia con ellos un orden determinado.
4316 Javier J.
Ropis
2598
32 ooOE 690.000 nO.OOOE 165.0ooE 190.000E 21S.000E
Tabla T.CN I<.-U>;
IlHBRE !'IUM.-E:MPLI NOIIBRE IINICIALIAPELLIlXIsl 1421 Juan Garcia
,.
CALL~
DIRECCIN
ICIUDAD/PJIOVINCIt.
Veamos algunas instrucciones ALTER TABLE de Informix que implementan estos cambios en las tablas previamente definidas:
ALTER TABLE REPS ADD OBJ_TRI LIST(MONEY{9,2); ALTER TABLE TECNICOS ADD PROYECTO SET(VARCHAR(lS)) ALTER TABLE ADD TITULO UNIVERSIDAD INGENIEROS ( TITULaS MULTISET(ROW( VARCHAR(3I, VARCHAR{lS);
/* cuatro objetivos
IS37 lh .:>.noH. 1618 Jorge
,.
F~to
Neus

aDla PERSONAL OOKBRE
.. ... ... ..... .. .. ... ..... .. ... ... .....
=~~~~
-IOJ SUElJXU-IO
16.7S 20 SOE 19.7SE
PROYI!:CTO bingo
nl1itR~aisR
atlas gon::o binC/o
trimestrales */
DIRECCIN
/* proyectos asignados */
CODIGOPOSTAL NUM_EMPL NOMBRJINI;IJ"PELLIJ CALLE1IUD:bROVINCIA PllJIlCm:irsunJOl SUELOO EXPER 4S.000E Martn 1234 Sasana S.
/* informacin del titulo */
1374 SMnuel 1439 Sara
,.
s.
Ord6t1e:: Zapata
.. .,. .. .. ... ... .. ...
30.000E 34.000
, , "
TTULOS TTULOIUlllvtRSlDAD
'" " ",

",
<>OC
w om om
~
OC><
Estos tipos de columna coleccin crean una estructura fila en una fila en la tabla que los contiene, como se muestra en la Figura 24.6. En el caso de la tabla INGENIEROS, la estructura se podra describir de forma ms precisa como una tabla en una tabla. Naturalmente, el modelo relacional de tablas fila/columna con elementos de datos atmicos se ha extendido considerablemente con la introducci6n de los tipos de datos coleccin. Universal Server de Informix permite utilizar colecciones de una forma bastante general y entremezclarlos con otras extensiones relacionales orientadas a objetos. Una coleccin puede ser un campo de un tipo de datos fila. Los elementos de una coleccin pueden ser tipos de datos fila. Tambin es posible definir las colecciones dentro de colecciones donde eso tenga sentido. Por ejemplo, los proyectos en este ejemplo podran tener subproyectos que debe supervisar cada tcnico. En cada nivel de complejidad adicional, la complejidad del lenguaje de procedimientos almacenados (SPL) y las expresiones SQL que se requieren para manipular los elementos de datos y procesarlos crece.

Figura 24.6.
Tablas con columnas cuyo tipos son colecciones de datos.
Ocacle tambin proporciona un gran soporte para los datos de tipo coleccin mediante dos extensiones relacionales orientadas a objetos diferentes: Arrays variables. Un array variable es una coleccin ordenada de elementos de datos, todos con el mismo tipo de datos. No hay requisito de que los elementos en el array sean nicos. Se define el nmero mximo de elementos de datos que pueden aparecer cuando se especifica un tipo de array variable en una columna. Gracle proporciona extensiones a SQL para que acceda a los elementos individuales en el array.
866
867
Tablas anidadas. Una tabla anidada es realmente una tabla en una tabla. Una columna con una tabla anidada contiene elementos de datos individua~ les que son en s mismos tablas. Oracle almacena los datos de la tabla anidada separados de los de la tabla principal que los contiene, pero utiliza extensiones SQL para procesar las referencias anidadas a las tablas internas. Al contrario que con el array variable, una tabla anidada puede contener cualquier nmero de filas.
Se puede declarar que una columna en una tabla tenga una estructura VARRAY (arcay variable) o TABLE OF (tabla anidada). Veamos algunas instrucciones CREATE TYPE Y CREATE TABLE que utilizan arrays variables y tablas anidadas para conseguir estructuras de tabla como las mostradas en la Figura 24.6:
.CREATE TABLE NUM_EMPL NOMBRE DIRECCION JEF_VEN REPS ( INTEGER, TIPO_NOMBRE, TIPO_DIR, INTEGER.
Consultas sobre datos de tipo coleccin

Las columnas cuyos valores son colecciones complican el proceso de consultar las labias que los contienen. En la lista de elementos de SELECT se generan varios datos para cada fila de resultados de consulta. En las condiciones de bsqueda, no contienen elementos de datos individuales, sino que algunas veces es conveniente tratarlos como conjuntos de datos. Las bases de datos relacionales orientadas a objetos proporcionan normalmente un conjunto limitado de extensiones SQL o conceptos SQL extendidos existentes para proporcionar consultas sencillas que comprenden datos de colecciones. Para consultas ms avanzadas, requieren que se escriban programas en el lenguaje de procedimientos almacenados con estructuras de bucle que procesan los elementos de datos de las colecciones uno a uno. Para las consultas, Informix trata los tipos de coleccin como si fueran un conjunto de valores de datos, como los valores que se pueden devolver mediante una subconsulta. Veamos una consulta que encuentra cualquier tcnico que trabaja en un proyecto llamado bingo:
SELECT NUM_EMPL. NOMBRE FROM TECNICOS WHERE 'bingo' IN (PROYECTOS);
SUELDO MONEY(9.2) , CUOTA MONEY{9,21, OBJ_TRI VARRAY(4) OF NUMBER{9.2);
/- nmero de empleado del jefe */ /- sueldo anual -/ /* cuota de ventas -/ 1- cuatro objetivos. trimestrales -/
CREATE TYPE TIPO_TIT AS OBJECT ( ( TITULO VARCHAR(3), UNIVERSIDAD VARCHAR(15); CREATE TABLE NUM_EMPL NOMBRE DIRECCION SUELDO EXPER TITULaS NJ;:STED TABLE INGENIEROS ( INTEGER. TIPO_NOMBRE, TIPO_DIR, NUMBER(9.2). /- salario anual -/ INTEGER, /- anos de experiencia -/ TABLE OF TIPO_TIT); TITULOS STORE AS TABLA_TITULOS;
La informacin cuatrimestral de la tabla REPS es la que ms fcilmente se representa como una columna de array variable de Oracle. Habr exactamente cuatro trimestres de infoonacin, por lo que el tamao mximo del array se conoce por adelantado. En este ejemplo, el array variable contiene datos sencillos como elementos, pero tambin es comn definir arrays variables cuyos elementos sean tipos de datos abstractos (estructurados). La informacin del ttulo acadmico para la tabla INGENIEROS se representa como una tabla anidada. Para un elemento de datos como ste. se podra decidir ubicar un lmite superior al nmero de filas y utilizar una estructura de array variable en su lugar, pero, en general, si el mximo nmero de elementos es desconocido, la eleccin correcta es una tabla anidada. En este caso la tabla anidada tiene un tipo de datos abstracto compuesto de dos atributos. Cada fila de la tabla anidada contendr informacin sobre el ttulo y la universidad que lo conced.i.
El nombre de la columna con valor de coleccin (en este caso, la columna con valor de conjunto PROYECTOS) aparece entre parntesis. lnformix trata los miembros de la coleccin como un conjunto y aplica la condicin de coincidencia IN. En SQL interactivo se puede poner una columna con un valor coleccin en la lista de elementos de seleccin. Informix muestra la coleccin de datos como SET, LIST o MULTISET en la salida mostrada. Para procesar los datos con valor coleccin en la lista de seleccin de una solicitud mediante programacin (esto es, mediante un programa que utiliza ESQL o una API en el nivel de llamadas), se deben utilizar extensiones API especiales y/o extensiones al lenguaje de procedimientos almacenados InfomUx. Oracle proporciona capacidades adicionales para procesar tablas anidadas en consultas SQL. La palabra clave especial THE aplana la tabla anidada, produciendo una tabla no anidada con una fila para cada fila de la tabla anidada en cada fila de la tabla principal. Veamos una consulta que muestra las universidades que han dado un titulo a uno de los ingenieros:
SELECT NEST.UNIVERSIDAD FROM THE (SELECT TITULOS FROM INGENIEROS WHERE NUM_EHPL = 1234) NEST;
La consulta en los parntesis internos es una consulta para la tabla principal Selecciona la columna que contiene la tabla anidada, pero podra seleccionar tambin otras columnas. La operacin TRE, aplicada a los resultados de la consulta, las aplana, creando una fila para cada fila de la columna anidada en cada fila de la tabla principal. Se asigna un alias a la tabla aplanada (NEST en este
(INGENIEROS).
868
Captulo 24: SaL y los objetos

INSERT INTO TECNICOS VALUES (TIPO_NOMBRE (. Samuel', 'S.', 'Garca' l , TIPO_DIR( 'Cruz', 'Madrid', M'. TIPO_POSTAL(28, 002, PROYECTOS ( 'atlas', 'piscis', 'bingo') l; INSERT INTO INGENIEROS VALUES (TIPO_NOMBRE('Julio', 'J.', 'Atos'l, TIPO_DIR ( 'Campos', 'Blanes', 'CA', TIPO_POSTAL (Oa, 100), TITULOS(TITULO_TYPE('IS'. 'UB'), TITULO_TYPE ( 'IS', 'UPM'), TITULO_TYPE('OOC'. 'UCM')));
869
ejemplo), y se convierte en el origen de resultados de la consulta candidata de la clusula FROM de la consulta principal de nivel superior. Con esta tabla como origen, la consulta principal en este ejemplo es bastante sencilla; selecciona una columna que se origin en la tabla anidada. La posibilidad de aplanar tablas anidadas de esta forma y procesarlas como si fueran realmente versiones reunidas de dos tablas separadas es realmente bastante potente. Permite expresar muchas consultas en SQL de alto nivel, que de otra forma requeriran recurrir a procedimientos almacenados. Sin embargo, la lgica interna de estas consultas y la tarea de construirlas correctamente puede ser extremadamente complicada, como incluso este ejemplo sencillo comienza a mostrar.
Manipulacin de datos de tipo coleccin

Se utilizan extensiones a la sintaxis SQL estndar para insertar nuevas filas en una tabla que contenga columnas con valor de coleccin. lnformix proporciona tres constructoras (la constructora SET, la constructora MULTISET y la constructora.LIsT) para este propsito. Transforman una lista de elementos de datos en las colecciones correspondientes que han de insertarse. Veamos un par de instrucciones INSERT que ilustran su uso con las tablas de la Figura 24.6:
INSERT INTO TECNICOS VALUES (1279, ROW('Samue1', 'S.', 'Garca'), ROW('Cruz', 'Madrid', 'M', ROW(28, 002)), SET{'atlas', 'piscis', 'bingo'}"); INSERT INTO INGENIEROS VALUES (1281, RDW('Julio', 'J.', 'Atos'), ROW{'Campos'. 'Slanes', 'CA', RQW(Oa. 100), MULTISET{ROW(' IS', 'UB'). ROW( '15', 'UPM'), ROW( 'DOC', 'UCM')}~);
Colecciones y procedimientos almacenados

Las colecciones poseen problemas especiales para los procedimientos almacenados que recuperan y manipulan los datos en las tablas que los contienen. Oracle e Informix proporcionan caractersticas del lenguaje de procedimientos almacenados especiales para este propsito. En Informix se deben utilizar variables de tipo coleccin del SPL especiales. Veamos un fragmento de procedimiento almacenado SPL que gestiona la columna de coleccin PROYECTOS de la tabla TECNICOS:
define col_proy collection: define un-proyecto varchar(15); define num_proy integer; define nombre_empl tipo_nombre;
1* alberga la coleccin de proyectos *1 1* alberga los proyectos individuales *1 1* nmero de proyectos *1 1* bfer con el nombre de los tcnicos *1
1* Comprueba cuntos proyectos est asumiendo el tcnico *1 select cardina1ity(proyectosl into num-proy from tecnicos where num_empl : 1234; 1* Si hay demasiados proyectos, entonces se niega a agregar uno ms *1
if (num-proy > 61 then .
La primera instruccin inserta una nica fila en la tabla TECNICOS con un conjunto de tres elementos en la columna PROYECTOS. La segunda inserta una nica fila en la tabla INGENIEROS con un multiconjunto de tres elementos en la columna TITULaS. Puesto que los miembros de este multiconjunto particular son en s mismos tipos fila, se debe utilizar para cada elemento la constructora fila. Graele utiliza un enfoque diferente para construir los datos con valor coleccin e insertarlos en la tabla. Recurdese de la discusin de los tipos de datos abstractos de Draele que cada tipo de datos abstracto de Oracle tiene automticamente un mlodo constructor asociado que se utiliza para construir un elemento de datos en el tipo abstracto con elementos de datos individuales. Este concepto se extiende a los arrays variables y las tablas anidadas. Se proporciona automticamente un mtodo constructor para cada arcay variable o tabla anidada y se utiliza en las instrucciones INSERT: .
1* Recupera la fila, tcnico *1
incluyendo el conjunto de proyectos para el col-proy
select nombre, proyectos into nombre_empl, from tecnicos where num_emp1 : 1234;
1* Agrega el proyecto 'gonzo' a la lista para este tcnico *1 insert into tab1e(col_proy) values ('gonzo');
1* Busca en la lista de proyecto uno a uno *1

foreach proj_cursor for
----.:
870
Captulo 24: SaL y los objetos
871
select inta un-proyecto from table(col-proy)

if (un-proyecto = 'atlas') then begin update table(col_proy) (proyecto) set proyecto = 'bingo' where current of proj_cursor. exit foreach; end;
end if;
end foreach;
Actualiza la fila de la base de datos con la lista de proyectos modificada */ update tecnicos set proyectos = col-proy where num_empl = 1234;
/~
El ejemplo muestra varios aspectos de la gestin de colecciones en el SPL de Informix. En primer lugar, la coleccin se recupera de la base de datos en una variable SPL como un tipo de datos coleccin. Tambin sera posible recuperarla .en una variable explcitamente declarada con el tipo SET (o, en otras situaciones, un tipo LIST o MULTSET). La coleccin almacenada en la variable entonces se trata explcitamente comouna tabla para manipular elementos en la coleccin. Para agregar un nuevo proyecto se realiza un IN5ERT en la tabla coleccin. Para encontrar y modificar un proyecto especfico se utiliza un cursor para buscar en la tabla coleccin, y una instruccin UPDATE basada en cursores para cambiar el valor de tin miembro de la coleccin. Obsrvese que el bucle FOREACH recupera cada elemento de la coleccin en una variable, de forma que la rutina SPL lo pueda procesar. Finalmente, los contenidos de la variable coleccin se utilizan para actualizar la columna coleccin en la tabla. Oraele adopta un enfoque similar para procesar los arrays variables. Los elementos individuales de un array en un tipo abstracto de datos estn disponibles mediante referencias con sufijos en un tipo de datos estructurado. El proceso Oraele PUSQL normal para acceder a los elementos de un array variable es: 1.
::lpefador THE para aplanar la tabla en una consulta SQL, y los resultados se procesan con un nico bucle FOR dirigido por cursores. El procesamiento puede ser todava complejo. En particular, el procedimiento almacenado puede necesitar detectar si una fila concreta que viene de los resultados de la consulta es de la misma fila de la tabla principal que la fila anterior y, al detectar un cambio en las filas de la tabla principal, ejecutar un procesamiento especial como calcular subtotales. En este aspecto, el procesamiento de los arrays variables y las tablas anidadas se ca mienza a parecer al procesamiento normal de bucles anidados de los programas COBOL de escritura de informes de hace 3D aos que gestionaban registros principales y detallados. Como ha ilustrado el anlisis de esta seccin, los tipos de coleccin y el procesamiento de elementos individuales de una coleccin tienden al acceso mediante programacin a travs de procedimientos almacenados, ms que por el uso oportuno de SQL. Una de las crticas a las bases de .dalos orientadas a objetos es que suponen una regresin en cuanto a la simplicidad del modelo relacional y reintroducen la necesidad de la navegacin explcita por la base de datos que era parte de las bases de datos prerrelacionales. Ejemplos como estos proporcionan una evidencia de que hayal menos una parte de verdad en la crtica.
Tipos de datos definidos por el usuario

Los sistemas de gestin de datos relacionales orientados a objetos proporcionan generalmente un mecanismo mediante el cual un usuario puede ampliar los tipos de datos incorporados proporcionados por el SGBD con tipos de datos adicionales definidos por el usuario. Por ejemplo, una aplicacin de mapas puede necesitar operar sobre un tipo de datos UBICACION, que consiste en un par de medidas longitud y latitud, cada una de las cuales se compone de horas, minutos y segundos. Para procesar de forma efectiva los datos de localizacin, la aplicacin puede necesitar definir funciones especiales, tales como la funcin DISTANCIA (X, Y) , que calcula la distancia entre dos ubicaciones. Se necesitar redefinir los significados de algunas operaciones incorporadas. como una comprobacin de la igualdad (=) para los datos de localizacin. Una forma mediante la cual Universal Server de Informix admite tipos de datos definidos por el usuario es el tipo de datos OPAQUE. Un tipo de datos OPAQUE es (no sorprendentemente) opaco al SGBD. El SGBD puede almacenar y recuperar los datos con es~e tipo, pero no tiene conocimiento de los trabajos internos del tipo. En trminos orientados a objetos, los datos estn completamente encapsulados. El usuario debe proporcionar de forma explcita (en rutinas externas, escritas en e o en lenguajes de programacin similares) la estructura de datos para el tipo. cdigo para implementar las funciones u operaciones que se pueden ejecutar sobre el tipo (como comparar dos elementos de datos del tipo mediante una igualdad), y cdigo para convertir el tipo opaco entre representaciones internas y externas. Por ello, los tipos de dalas OPAQUE representan una capacidad de bajo nivel para ampliar la funcionalidad principal del SGBD con los tipos de datos que aparecen como si estuvieran incorporados.
2.
3.
Recuperar la fila de la tabla que contiene el array variable en una variable local cuyo tipo de datos est definido para coincidir con la estructura de fila de la tabla, o de las columnas particulares que estn siendo recuperadas. Ejecutar un bucle FOR con un ndice variable n que cuenta desde 1 hasta el nmero de elementos en el array variable. El nmero de elementos est disponible mediante el valor de un atributo especial de la columna de tipo array, denominado COUNT. En el buele FOR se utiliza un sufijo sobre el nombre del array variable para acceder al n-simo elemento del array variable.
Se pued~ utilizar una tcnica similar para procesar las tablas anidadas; sin embargo, normalmente no es necesario. En su lugar, se utiliza generalmente el
872
SOL. Manual de referenda
Captulo 24: SOL V los objetos
873
Se proporciona una capacidad ms bsica de tipos de datos definidos por el usuario mediante la implementacin de tipos de datos DISTINCT en Informix. Un tipo DISTINCT es til para distinguir entre diferentes tipos de datos, lOdos los cuales utilizan uno de los tipos de datos del SOBD incorporados. Por ejemplo, los elementos de datos del nombre de la ciudad y la compaa en la base de datos se pueden definir mediante el tipo de datos VARCHAR (20). Aunque comparten el mismo tipo de datos SGBD, estos datos representan realmente tipos de datos bastante distintos. Normalmente no se comparan los nombres de una ciudad y una compaa, y, sin embargo, el SOBD lo permitir, puesto que las dos columnas VARCHAR(20) son directamente comparables. Para mantener un nivel de integridad de la base de datos mayor, se puede definir cada uno de estos elementos de datos como un tipo de datos DISTINCT:
CREATE DISTINCT TYPE TIPO_CIUDAD AS VARCHAR(20); CREATE DISTINCT TYPE TIPO_NOMBRE_CO AS VARCHAR(20);
Ahora las tablas se pueden crear de modo que contengan daws de ciudad y nombre de clientes en funcin de los tipos de datos TIPO_CIUDAD y TIPO_NOMBRE_CO. Si se intenta comparar columnas con estos dos tipos de datos distintos, SOBD automticamente detecta la situacin y genera un error. Se pueden comparar, pero solamente convirtiendo explcitamente el tipo de datos de un elemento para que coincida con el tipo de datos del otro. Como resultado, los distintos tipos de datos asignados a las diferentes columnas ayudan a mantener la integridad de la base de datos y evitar errores inadvertidos en los programas y consultas ad hoc que se realizan en la base de datos.
conocen la estructura interna de la base de datos a priori, pueden utilizar consultas SQL para averiguar cmo es. Los procedimientos almacenados proporcionan un mlodo para que las bases de datos relacionales ofrezcan capacidades que recuerdan las de los mtodos orientados a objetos. Excepcionalmente, todos los usuarios de una base de datos relacional podran obtener permiso para ejecutar solamente un conjunto limitado de procedimientos almacenados, y ningn permiso de acceso a datos subyacente so bre las tablas de las bases de datos. En este caso, el acceso de los usuarios se acercara a la encapsulacin del ideal orientado a objetos. En la prctica, los procedimientos almacenados se utilizan frecuentemente para proporcionar a los di se adores de aplicaciones el acceso limitado que necesitan. Sin embargo, las capacidades ad hoc de la base de datos estn casi siempre explotadas por herramientas de consulta o programas de informes. Gracle formaliza el vnculo entre los mtodos de objetos y los procedimientos almacenados de la base de datos, permitiendo definir de forma explcita un procedimiento almacenado como una funcin miembro de un tipo de datos abstraclo. Una vez definida de esta forma, se puede utilizar la funcin miembro en consultas que alcanzan al tipo de datos abstracto, de igual forma que si fuera una funcin incorporada del SOBD diseada para funcionar sobre ese tipo. Veamos una redefinicin del tipo de datos abstracto TIPO_DIR que se utiliza para almacenar direcciones, con una funcin miembro relativamente sencilla, denominada OBT_POST_COMPLETO. La funcin toma la parte del cdigo postal de la direccin, la cual almacena un cdigo postal principal de dos dgitos y un sufijo de tres dgitos como dos nmeros separados y los combina en un nmero de cinco dgitos, el cual devuelve.
CREATE TYPE CALLE CIUDAD PROVINCIA CODIGOPOSTAL MEMBER RETURN PRAGMA TIPO_DIR AS OBJECT VARCHAR{35), VARCHAR(15l, CHAR(2), TIPO_POSTAL, FUNCTION OBT_POST_COMPLETO(CODIGOPOSTAL IN TIPO_POSTAL) NUMBER, RESTRICT_REFERENCES{OBT_POST_COMPLETO, WNDS));
Mtodos y procedimientos almacenados

En lenguajes orientados a objetos, los objetos encapsulan los datos y el cdigo de programacin que contienen; los detalles de las estructuras de datos en un objeto y las instrucciones de programacin que gestionan dichas estructuras de datos estn ocultados explcitamente. La nica forma de manipular el objeto y obtener informacin sobre l es mediante los mtodos, que son procedimientos explcitamente definidos, asociados con el objeto (o, ms adecuadamente, con la clase de objetos). Por ejemplo, un mtodo asociado con un objeto cliente podra contener el lmite de crdito actual del cliente. Otro mtodo podra proporcionar la capacidad de cambiar el lmite de crdito. Los datos del lmite de crdito estn encapsulados, ocultos en el objeto cliente. Los datos en las tablas de la base de datos relacional no estn inherentemente encapsulados. Los datos y su estructura estn directamente visibles a los usuarios externos. En realidad, una de las principales ventajas de una base de datos relacional es que se puede utilizar SQL para llevar a cabo consultas ad hoc en la base de datos. Cuando se considera el catlogo del sistema de una base de datos relacional, el contraste c:on el ideal orientado a objetos es incluso ms extremo. Con el catlogo, la base de datos es autodescriptiva, por ]0 que incluso las aplicaciones que no
CREATE TYPE BODY TIPO_DIR AS MEMBER FUNCTION OBT_POST_COMPLETO(CODIGOPOSTAL TIPO_POSTAL) RETURN NUMBER 15 BEGIN RETURN{(CODIGOPOSTAL.PRINCIPAL * 1000) + CODIGOP05TAL.SUFIJO) ; END;
La funcin miembro se identifica como tal en la instruccin CREATE TYPE para el tipo de datos abstracto, siguiendo las lneas que describen los elementos de datos. La clusula adicional PRAGMA dice a Gracle que la funcin no modifica los contenidos de la base de datos, que es un requisito para una funcin que se va a utilizar en expresiones de consulta. Hay varias opciones ms, que estn fuera del
-'--
874
875
mbito de este anlisis. Una instruccin CREATE TYPE BODY separada define el cdigo procedimental real de la funcin. Despus de las primeras palabras de la instruccin, sigue el mismo formato de las instrucciones estndar CREATE PRQCEDURE o CREATE FUNCTION. Una vez que se define la funcin miembro, se puede utilizar en expresiones de consulta como sta, que encuentra los empleados que viven en el cdigo postal 28-005:
28005;
cos, dado que ninguno de ellos tiene idntico nmero de argumentos con idnticos tipos de datos. En el ejemplo anterior, hay tres definiciones CREATE FUNCTION como estas:
/* Calcula el sueldo objetivo de un tcnico */ CREATE FUNCTION OBT_SUELDO_OBJ(PERSON TIPO_TEC) RETURNS MONEY(9,2) AS RETURN (PERSON.SUELDO_HORA * 40 * 52) ENO FUNCTION;
/* Calcula el sueldo objetivo de un jefe */ CREATE FUNCTION OBT_SUELDO_OBJ(PERSON TIPO_JEF) RETURNS MONEY(9,2) AS RETURN (PERSON.SUELDO END FUNCTION;
Universal Server de Informix no tiene un mecanismo extendido como Oracle para transformar los procedimientos almacenados en mtodos orientados a objetos. En su lugar, es posible utilizar un tipo fila de Informix (correspondiente a un tipo objeto de Gracle) como parmetro de una funcin almacenada. Cuando se llama, se pasa a la funcin un dato con el tipo fila apropiado (como el dato abstracto CODIGOPOSTAL en el ejemplo precedente de Orade) y se pueden realizar clculos apropiados. Se podra, por ejemplo, definir una funcin almacenada Informix OBT_POST_COMPLETO () con un nico parmetro del tipo TIPO_POSTAL. Con esa definicin, se podra utilizar la instruccin Oracle SELECT precedente, sin modificar, en la base de datos Informix equivalente. Otra caracterstica potente, asociada con procedimientos almacenados relacionales orientados a objetos, es la sobrecarga de definiciones de procedimientos, que permite procesar diferentes tipos de datos. En una jerarqua de clases objeto, suele ser necesario definir un mtodo que realice las mismas o similares operaciones sobre diferentes clases de objetos. Por ejemplo, se puede desear definir un mtodo (fun cin) QBT_SUELDO_OBJ que puede obtener los sueldos totales anuales objetivo para cualquiera de las subclases de la clase PERSONAL en nuestra base de datos ejemplo. El mtodo (que ser implementado como una funcin almacenada) debera devolver el sueldo total anual objetivo del empleado al que se aplica. Las particularidades de los clculos difieren segn el tipo (clase) de empleo: Para los tcnicos, el sueldo total es la jornada semanal de 40 horas x 52 semanas al ao. Para los jefes, el sueldo total es igual a su sueldo anual ms los complementos. Para el resto de ingenieros, el sueldo total es igual a su salario anual. Para solucionar este problema, se define una rutina OBT_SUELDO_OBJ para cada clase. La rutina toma un objeto (una fila de la tabla TECNICOS, INGENIEROS o JEFES) como su parmetro y devuelve la cantidad calculada. Las tres rutinas tienen el mismo nombre, que es la razn por la cual se dice que el nombre est sobrecargado (se asocia un nico nombre con ms de un procedimiento almacenado). Cuando se llama a la rutina, el SGBD mira el tipo de datos particular del aroumento (esto es, la clase particular del objeto) y determina cul de las rutinas es; la que hay que llamar. .U~iversal Server de lnformix implementa esta capacidad de sobrecarga de procedlmlentos a1?lacenados sin ninguna extensin orientada a objetos adicional. Permite definir muchos procedimientos almacenados diferentes con nombres idnti-
PERSON.COMP)
/* Calcula el sueldo objetivo de un ingeniero */ CREATE FUNCTION OBT_SUELDO_OBJ(PERSON TIPO_ING) RETURNS HONEY{9,2) AS RETURN (PERSON.SUELDO) END FUNCTION;
Con estas definiciones se puede invocar la funcin OBT_SUELOO_OBJ () y pasarle una fila de la tabla INGENIEROS, JEFES o TECNICOS. El SGBD averigua automticamente qu funciones utilizar y devuelve el valor calculado apropiado. Los procedimientos almacenados son incluso ms valiosos para tablas con ti pos mediante la caracterstica posibilidad de sustitucin de Universal Server de Informix. Si se llama a un procedimiento almacenado cuyo argumento es un tipo fila y se pasa una de las filas de una tabla con tipos Informix, en primer lugar buscar un procedimiento almacenado con el nombre apropiado cuyo tipo de datos del argumento sea una coincidencia exacta. Por ejemplo, si se llama al procedimiento almacenado OBT_APELLIDOS () para extraer los apellidos de una fila TIPO_TEC (probablemente de la tabla TECNICOS), Informix busca un procedimiento escrito para procesar los datos TIPO_TEC. Pero si Informix no encuentra dicho procedimiento almacenado, no devuelve inmediatamente un error, sino que busca hacia arriba en la jerarqua de tipos intentando encontrar un procedimiento con el mismo nombre que est definido para un supertipo TIPO_TEC. Si hay un procedimiento almacenado OBT_APELLIOOS () definido para el tipo TIPO_ING, Informix ejecutar ese procedimiento almacenado para obtener la informacin requerida. Si no, continuar hacia arriba en la jerarqua, buscando un procedimiento almacena do OBT_APELLIDOS () definido para el tipo TIPO_PERS. Por ello, la posibilidad de sustitucin significa que se pueden definir procedimientos almacenados (mtodos) para el tipo de nivel superior en la jerarqua a la cual se aplica. Los procedimientos almacenados estn disponibles automticamente para procesar todos los subtipos de ese tipo (esto es, todas las subclases heredan el mtodo de la clase).
Soporte de objetos en el estndar SQL:1999

Como se mencion al comienzo de este captulo, el rea mayor de expansin SQL en el estndar SQL: 1999 fue el soporte relacional orientado a objetos. El
876
877
estndar SQL: 1999 especifica nuevas instrucciones, clusulas y expresiones en el lenguaje SQL en las siguientes reas:
Tipos de datos definidos por el usuario. Tipos de datos compuestos (abstractos).

Valores aITay.
Procedimientos almacenados sobrecargados (polim6rficos). Constructoras de filas y constructoras de tablas que admiten tipos abs. tractos. Expresiones con valor de filas y de tablas que admiten tipos abstractos.
Las extensiones SQL: 1999 no coinciden exactamente con ninguno de los principales productos SGBD relacionales orientados a objetos comerciales en sus especificaciones, pero los conceptos subyacentes son los mismos que los ilustrados en las secciones anteriores para productos especficos. Es probable que en esta rea de SQL se siga el patrn de otros con respecto al estndar. Lentamente, sobre una serie de versiones principales, los principales fabricantes SGBD proporciona rn soporte para la sintaxis SQL: 1999 donde puedan agregar en paralelo su propia sintaxis propietaria y bien establecida. Este proceso acaba de comenzar para el soporte de objetos en SQL:1999. En los aos siguientes las capacidades relacionales orientadas a objetos que importan en las implementaciones continuarn siendo propiedad de los fabricantes.
Las capacidades relacionales orientadas a objetos son particularmente buenas para modelos de datos ms complejos, donde el diseo completo de la base de datos puede ser ms sencillo, incluso cuando las tablas/objetos individuales son ms complejas. Las capacidades relacionales orientadas a objetos son un punto fuerte de los esfuerzos de los estndares SQL3, y es probable que en el futuro sean incorporadas ms bases de datos relacionales.
Resumen
Las bases de datos orientadas a objetos desempearan, probablemente, un papel creciente en segmentos especializados del mercado, corno el diseo en ingeniera, el procesamiento de documentos compuestos y las interfaces grficas de usuario. No estn siendo adoptadas de forma generalizada por aplicaciones de procesamiento de datos de las empresas principales. Sin embargo, se estn ofreciendo bases de datos relacionales orientadas a objetos h.bridas por parte de algunos fabricantes importantes de SOBD. Las bases de datos relacionales orientadas a objetos amplian de forma significativa SQL y los lenguajes de procedimientos almacenados con instrucciones, estructuras y capacidades orientadas a objetos. Las estructuras relacionales orientadas a objetos comunes incluyen tipos de datos abstractos/estructurados, tablas en tablas y soporte explcito para identificadores de objetos. Estas capacidades amplian en gran medida el modelo relacional sencillo y tienden a aadir complejidad en el caso de usuarios casuales o ad hoc. Las extensiones relacionales orientadas a objetos agregadas por varios de los fabricantes SOBO son muy particulares. Hay diferencias conceptuales significativas en los enfoques, as como en los enfoques en la implementacin.
CAPTULO
25
SOL yXML
El Lenguaje de marcas extensible (XML, eXtensible Markup Language) es una de las tecnologas ms importantes que vienen de la evolucin de Internet y World Wide Web. XML es un lenguaje estndar para representar y extraer datos estructuradas. SQL es un lenguaje estndar para definir, acceder y actualizar los datos estructurados almacenados en bases de datos relacionales. Parece obvio a primera vista que debera haber una relacin entre XML y SQL. Las preguntas lgicas son: cul es la relacin? y estn las dos tecnologas en conflicto, o son complementarias entre s? La respuesta incluye un poco de ambas opciones. Este captulo ofrece un repaso de los fundamentos de XML y examina la relacin creciente entre XML y SQL, y cmo XML se est integrando en los principales productos SQL.
XML
Como su nombre indica, XML es un lenguaje de marcas. Comparte muchas caractersticas con su primo ms cercano, el lenguaje de marcas de hipertexto (HDvtL, HyperText Markup lAnguage), que se ha convertido en un lenguaje ampliamente popular como tecnologa principal que hace posibles World Wide Web y los exploradores Web. Los lenguajes tienen orgenes comunes en las marcas de documento, una tcnica que es tan antigua como los negocios de imprenta y edicin. Cuando un documento complejo, como este libro, un peridico o una revista, se va a imprimir, se puede pensar que tiene dos partes lgicas relacionadas. El contenido del documento, que normalmente consiste en texto y grficos, contiene su significado. La estructura del documento (ttulos, subttulos, prrafos, pies) y el formato (fuentes, sangrados, diseos de pgina) ayudan a organizar el contenido y asegurar que se presentan de una forma comprensible. Desde los primeros das de la imprenta y la edicin, los editores han empleado smbolos de marcas y marcas de formato, insertos en los contenidos del documento mismo, para indicar la estructura del documento y cmo se debera dar: formato para su impresin.
879
880
Captulo 25: SOL y XML
881
Cuando entraron en escena los sistemas informticos de edicin. los comandos de marcas insectos en los contenidos de un documento se convirtieron en instrucciones para los programas software de edicin. Cada tipo de software de edicin tena sus propios comandos de marcas, lo que haca complicado cambiar de un sistema a otro. Se desarroll el lenguaje de marcas estndar general (SGML, Standard General Markup Lallguage) como una forma de estandarizar los lenguajes de marcas, y finalmente se adopt como un estndar ISO. De forma ms precisa, SGML es un metalenguaje para definir lenguajes de marcas. Sus inventores reconocieron que ningn lenguaje de marcas podra cubrir todos los requisitos de marcas, pero que todos los lenguajes tenan elementos comunes. Mediante la estandarizacin de estos elementos comunes se pudo crear una familia de lenguajes de marcas ntimamente relacionados. HTML es uno de estos lenguajes de marcas, y se centra especialmente en el uso del hipertexto para vincular documentos entre s. XML es otro de estos lenguajes, centrado principalmente en los tipos y la estructura de los contenidos del documento. Sus races comunes en SGML hacen que HTML y XML sean lenguajes primos, y se reconoce su semejanza. HTML y XML son recomendaciones del World Wide Web Consortium (W3C), definidas mediante especificaciones que W3C desarrolla, vota y posteriormente publica. W3C es un consorcio independiente sin nimo de lucro cuyo propsito es desarrollar y promocionar el uso de estndares asociados con Internet y World Wide Weh. Las recomendaciones W3C tienen un estatus oficialmente adoptado; la terminologa significa que la organizacin W3C promociona y recomienda su uso. Mediante este proceso, HTML y XML son estndares industriales independientes del fabricante. HTML fue el primer lenguaje basado en SGML en tener una amplia popularidad. Los contenidos de toda pgina Web en todo sitio Web en la World Wide Web estn expresados como un documento HTML. Los elementos de marcas especiales, denominados etiquetas en un documento HTML, indican elementos grficos, tales como botones a mostrar en un explorador Web. Las etiquetas tambin describen los vnculos del hipertexto a otros documentos que el explorador debera seguir cuando se pulsa un botn. Otras etiquetas identifican elementos grficos que se van a insertar en el texto HTML cuando se muestra. Como el uso de la World Wide Web explot en los aos 90, HTML se adapt rpidamente para mostrar un contenido mucho ms rico en pginas web con mucho formato. Se inventaron rpidamente etiquetas HTML para controlar el formato de las pginas Web, dirigiendo la visualizacin texto en negrita en cursiva, centrado y sangrados, y la ubicacin del texto en la pgina. En algunos casos estas etiquetas eran dependientes de un explorador Web especfico, tal como el explorador Netscape o Internet Explorer de Microsoft. Con el tiempo una gran parte de las marcas en una pgina HTML se centraban en el formato y presentacin de la informacin. Esto tena la ventaja de que el formato de la pgina Web estaba muy especificado, por lo que las pginas se mostraban de la misma forma sin importar el explorador o dispositivo sobre el cual se mostraba. Tena la desventaja de que la estructura del contenido de la pgina Web tenda a perderse en el formato y los detalles de la presentacin.
Un logro importante, original de SGML, fue el de que un elemento lgico dado, como un ttulo de pgina subseccin de una pgina Web, se podra identificar de forma consistente en cientos de documentos (por ejemplo, en ciemos de pginas de un sitio Web). Una sencilla directiva al explorador, tal como muestra todos los ttulos de subsecciones en azul, negrita, fuente Times New Roman 16 puntos podra entonces asegurar la consistencia en la presentacin de todas las pginas. En su lugar, los autores de pginas Web tendan a marcar explcitamente todo elemento, tales como los ttulos de subseccin con sus propias instrucciones de formato detalladas. Esto se poda fcilmente convertir en inconsisteme y, lo que es peor, un cambio en las instrucciones del formato requeriran cientos de cambios en las pginas individuales, en lugar de especificarse una sola vez para todas las pginas. Una de las principales tendencias que acompaaron el desarrollo de XML fue restaurar un nivel ms lgico, en lugar de un nivel de formato. XML implementa reglas mucho ms rgidas sobre la estructura del documento que HTML. La mayora de sus componentes y capacidades estn centradas en la representacin de la estructura lgica del documento. Los estndares acompaantes, tales como XML Schema, que especifica los tipos de documentos, llevan este objetivo de XML incluso ms all.
Fundamentos de XML
Para comprender las interacciones entre XML y SQL se necesita una comprensin bsica de XML y cmo se utiliza. Si ya se ha comprendido o utilizado XML, se puede saltar esta seccin y continuar con la siguiente. Si no se est familiarizado con XML, esta seccin proporciona una introduccin sencilla, basada en algunos ejemplos de documentos XML. La Figura 25.1 muestra una representacin XML tpica de un documento de texto, un fragmento de la Parte 11 de este libro. Este ejemplo no tiene mucho que ver con el procesamiento de datos o SQL, pero muestra XML en su entorno original e ilustra conceptos XML clave. Cada elemento del documento XML de la figura, cada parte del componente, se representa mediante un elemento XML correspondiente a la estructura sencilla mostrada en la Figura 25.2. Cada elemento se identifica mediante una etiqueta de apertura, que contiene el nombre del tipo de elemento encerrado entre los smbolos menor que ) y mayor que (. En la Figura 25.110s prrafos se identifican mediante una etiqueta de apertura <para>, y las cabeceras se identifican mediante una etiqueta de apertura <header>. El final de cada elemento se identifica mediante una etiqueta de cierre, que de nuevo contiene el nombre del tipo de elemento, precedido por un carcter de barra (1), de nuevo encerrado entre smbolos menor que y mayor que. En la Figura 25.1 los prrafos se acaban con una etiqueta </para>, y las cabeceras con una etiqueta </header>. Entre las etiquetas de apertura y cierre est el contenido del elemento. La mayor parte del contenido de la Figura 25.1 es texto encerrado entre comillas. Se pueden utilizar las comillas sencillas o dobles para
882
883
<?xml version~l.O?> <bookPart partNum;"2" title="Recuperacin de datos"> <para>Las consultas estn en el centro_ para gestionar consultas complejas. </para> <chapter chapNum = "S" revStatus="final"> <title>Fundamentos de sQL</title> <para>Este captulo comienza_ descrito en este captulo."</para> <section> <header hdrLevel="l">Instrucciones</header>
<para>La parte principal de ... en la Figura 5.1.</para>
<para>Toda instruccin SQL... constantes o expresiones.</para> <figure figNum="S.l"></figure> <table tabNuro="S.l"></table>

<para> ANSI/ISO SQL._ En la Tabla 5.3. <para>
<table tabNum="S.2"></table> <table tabNum="S.3"></table> <para>En todo este libro_ en minsculas.</para> <figure figNum;~S.2~></figure> <para>Las variables_ estn SUBRAYADAS.</para> </section> <section> <header hdrLevel;~l">Nombres</header> <para>Los objetos en_ formularios de entrada de datos.</para> <para>El original_ caracteres especiales.</para> <section> <header> hdrLevel;""2">Nombres de tablas</header> <para> Cuando se especifica_o o disef'iador.</para> <para>En un mayor_ nombre de tabla </para> _ etc _. </section> </section> </chapter> <chapter chapNum;-6"> <title>Consultas sencillas</title> <para>De muchas formas_ en la base de datos.</para> <section> _ etc </section> </chapter> _ etc ... </bookPart>
Figura 25.1.
Documento XML de una parte de un libro.
encerrar el texto, siempre que se utilice el mismo tipo de comillas al comienzo y al final del trozo de texto, La Figura 25,1 muestra la jerarqua normal de elementos de la mayora de documentos XML. En el nivel superior est el elemento part, Sus contenidos no son texto, sino otros elementos: una secuencia de elementos chapter. Cada elemento chapter contiene un elemento ti tle, posiblemente algunos elementos introductorios para y seguidamente una serie de elementos section, Cada elemento section contiene un elemento header y uno o ms elementos para, posiblemente entremezclados con algunos elementos figure y algunos elementos tableo Cada elemento para tiene solamente texto corno contenido. Adems de la jerarqua de elementos, la Figura 25.1 muestra algunos ejemplos de atributos, otra estructura XML fundamental. Se asocia un atributo con un elemento XML especfico, y tal atributo describe algunas caractersticas del elemento. Cada atributo tiene un nombre de atributo. En la Figura 25,1 el elemento chapter tiene un atributo denominado chapNum, cuyo valor es el nmero de captulo asociado con ese contenido particular. El elemento chapter tiene otro atributo denominado revStatus cuyo valor indica si el captulo est en borrador, est siendo reescrito o en su forma final. Los elementos <header> individuales, en la Figura 25.1, tambin tienen un atributo denominado hdrLevel que indica si la cabecera est en su nivel superior (nivel 1) o en niveles inferiores (nivel 2 o 3). La primera lnea del documento XML en la Figura 25.1 lo identifica como un documento XML 1.0. El resto de parte del documento describe la estructura del elemento, contenidos de los elementos o atributos de los elementos. Los documentos XML pueden llegar a ser considerablemente ms complejos, pero estos componentes fundamentales son los nicos importantes para la interaccin XMU base de datos, Observes que los nombres de los elementos y atributos consideran las maysculas. Un elemento denominado bookPart y otro denominado bookpart no se consideran el mismo elemento. Esto es diferente del convenio SQL normal para los nombres de tablas y columnas, que no suelen considerar las maysculas. En la Figura 25.1 se muestra, de forma aclaratoria, una notacin adicional abreviada de XML, pero es muy til en la prctica. Para elementos que no tienen contenidos propios sino solamente atributos, el final del elemento se puede indicar con el mismo par de smbolos, menor que y mayor que, que ]a etiqueta de apertura. indicada por una barra justo antes del smbolo mayor que. Mediante el uso de este convenio el elemento de la Figura 25.1:
<figure
figNum~5.1"></figure>
se puede representar como:

<name> Juan
J,
Moreno
Etiqueta de apertura
'-.r----' '
, '----.r---'
Etiqueta de cierre
</name>
Cont-;nido del elemento
<figure figNum;"S.l"
/>
Figura 25.2.
Anatoma de un elemento XML.
La especificacin XML define ciertas reglas que todo documento XML debera seguir, Dicta que los elementos en un documento XML deben estar anidados de forma estricta entre s. La etiqueta de cierre de un elemento de nivel inferior debe
884
Captulo 25: SOL V XML
885
aparecer antes de la etiqueta de cierre de un elemento de nivel superior que lo contiene. El estndar tambin dicta que un atributo debe ser denominado de forma nica en su elemento; es ilegal tener dos atributos con el mismo nombre adjuntos a un nico elemento. Los documentos XML que obedecen estas reglas se describen como documentos XML bien formados.
XML para datos

Aunque las races de XML estn en los documentos y en el procesamiento de documentos. XML puede ser bastante til para representar datos estructurados que se encuentran normalmente en aplicaciones de procesamiento de texto. La Figura 25.3 muestra un documento XML tpico del mundo del procesamiento de datos, un pedido muy simplificado. ste es un tipo de documento bastante diferente al del extracto del libro de la Figura 25.1, pero los componentes clave del documento son los mismos. En lugar de chapter, el elemento superior es compraPedido. Su contenido, como los de chapter, son subelementos (nmeroClience, nmeropedido, fechaPedido y elementoPedido). elementoPedido est compuesto a su vez por otros subelementos. La Figura 25.3 tambin muestra algunas funciones del negocio asociadas con el pedido de compra como atributos del elemento trminos. El atributo envo especifica cmo se va a enviar el pedido. El atributo factura especifica los trminos del crdito para el pedido. Debera ser obvio que el sencillo documento de pedido XML de la Figura 25.3 tiene una gran relacin con la tabla PEDIDOS en la base de datos de ejemplo. Se puede desear compararla con la estructura de la tabla PEDIDOS mostrada en el Apndice A (Figura A.5.). Los niveles inferiores del documento coinciden principalmente con las columnas individuales de la tabla PEDIDOS, excepto el elemento trminos. El elemento de nivel superior en el documento representa una fila com-
pleta de la tabla. La transformacin entre un grupo de documentos de la Figura 25.3 y un conjunto de filas en la tabla PEDIDOS es evideme, mecnica, por lo que debera ejecutar de forma automtica un sencillo programa informlico. Al contrario que la tabla PEDIDOS, el documento XML impone un nivel medio de jerarqua, agrupando la informacin sobre el producto pedido (identificador del fabricante, identificador del producto, cantidad y precio final). En un pedido real este grupo de elementos pueden estar repetidos varias veces, formando varios elementos del pedido. El documento XML se podra ampliar fcilmente para admitir esta estructura, agregando un segundo o tercer elemento elemento Pedido despus del primero. La base de datos de ejemplo no se puede ampliar de forma tan sencilla. Para admitir pedidos con varias lneas la tabla PEDIDOS se tendra que dividir probablemente en dos tablas: una con la informacin de la cabecera del pedido (nmero de pedido, fecha, ID del cliente, etc.) y otra con los elementos del pedido.
XML ySQL
Los orgenes de SGML dan a XML varias caractersticas nicas y tiles, que tienen un fuerte paralelismo con el lenguaje SQL: Enfoque descriptivo. El enfoque XML documenta la estructura diciendo qu elemento del documento es, en lugar de cmo se procesa. Se puede llamar a esto una caracterstica de SQL; que se enfoca en qu datos se solicitan en lugar de en cmo recuperarlos. Construccin de bloques. Los documentos XML estn compuestos de un nmero muy pequeo de bloques de construccin bsicos, que incluyen dos conceptos fundamentales, elementos y atributos. Hay un fuerte paralelismo (aunque no perfecto) entre un elemento XML y una tabla SQL, y entre un atributo XML y una columna SQL. Tipos de documentos. XML define y valida documentos conforme a tipos de documentos especficos que representan documentos reales, como un documento de pedidos, o una carta de respuesta, o un documento de solicitud de vacaciones. De nuevo hay un fuerte paralelismo con SQL, donde las tablas representan diferentes tipos de entidades de la vida real. Aunque hay fuertes paralelismos entre XML y SQL, hay tambin grandes diferencias: Orientacin a documentos frente a orientacin a datos. Los conceptos principales de XML vienen de las estructuras normales del documento. XML est centrado en el texto e implementa una fuerte distincin entre el contenido mismo (1os elementos de un documento) y las caractersticas del contenido (atributos). Los conceptos centrales de SQL vienen de las estructuras de registro de procesamiento de datos normales. Est enfocado sobre los datos, con una serie de tipos de datos (en sus representaciones binarias), y sus es-
<?xml version:"l.O"?> <compraPedido> <nmeroCliente>2117</nmerocliente> <nmeroPedido>112961</nmeroPedido> <fechaPedido>1989-12-17</fechaPedido> <nmeroRep>106</nmeroRep> <trminos envo:"superficie- factura:"Net30"></trminos> <elementoPedido> <fab>REI</fab> <producto>2a441</producto> <cantidad>7</cantidad> <importe>31500.00</importe> </elementoPedido> </compraPedido>
Figura 25.3.
Documento XML para un pedido sencillo.
886
887
tructuras (tablas y columnas) centradas en el contenido (datos). La diferencia entre los modelos XML y SQL pueden producir algunos conflictos o dificultar elecciones cuando se utilizan conjuntamente. Estructura jerrquica frente a tabular. Las estructuras XML naturales son jerrquicas. y reflejan la jerarqua de elementos en la mayora de tipos de documentos (por ejemplo, un libro contiene captulos; los captulos contienen secciones, y las secciones contienen cabeceras, prrafos y figuras). Las estructuras son tambin flexibles y variables. Una seccin puede contener cinco prrafos y una nica figura; la siguiente, tres prrafos y dos figuras, y la siguiente, seis prrafos y ninguna figura. En cambio, las estructuras SQL son tabulares, no jerrquicas, y reflejan los registros tpicos de las aplicaciones del procesamiento de datos. Las estructuras SQL son tambin bastante rgidas. Toda fila de una tabla contiene exactamente las mismas columnas, en el mismo orden'. Toda fila de una tabla contiene exactamente las mismas columnas, en el mismo orden. Cada columna tiene el mismo tipo de datos en todas las filas. No hay columnas opcionales; todas las columnas deben aparecer en todas las filas. Estas diferencias tambin pueden provocar conflictos cuando se utilizan XML y SQL conjuntamente. Objetos frente a operaciones. El propsito principal del lenguaje XML es representar objetos. Si se toma un trozo de texto con significado en XML y se pregunta qu representa?, la respuesta ser un objeto: un prrafo, un pedido o la direccin de un cliente, por ejemplo. El lenguaje SQL tiene un propsito ms amplio, pero principalmente est enfocado a manipular objetos. Si se toma una pieza de texto con significado en SQL y se pregunta qu representa?, la respuesta normalmente ser una operacin sobre un objeto: crear un objeto, borrar un objeto, encontrar uno o ms objetos, o actualizar el contenido de los objetos. Estas diferencias hacen a los dos lenguajes fundamentalmente complementarios en su propsito y uso.
Atributos. Un elemento en un documento XML puede tener uno O ms atri butos con nombre, y cada atributo tiene un valor de texto. Los atributos se adjuntan a un elemento en la jerarqua XML, pero no son el contenido del elemento. Los nombres de los diferentes atributos de un elemento deben ser diferentes, por lo que no se puede tener dos atributos CQn el mismo nombre. Adems, XML trata el orden de los atributos de un elemento como no significativo; aparecen en cualquier orden. Esto difiere del tratamiento XML de los elementos, que tienen una posicin definida en un documento XML y donde la diferencia entre el primero, segundo y tercer elemento hijo de un elemento de nivel superior es significativo.
La existencia de dos formas diferentes de representar los datos en XML significa que hay dos formas legtimas diferentes para expresar el contenido de una base de datos relacional con XML. Estas dos filas de datos:
NUM_PEDIDO FAB PRODUCTO CANTIDAD
----------
-------41004 41004
IMPORTE
-------2B 3
----------
112963 ACI 112983 ACI
3 .276,OO
702,OOE
podran ser representadas por este documento XML cuando los elementos se utilizan para representar valores de columna:
<?xml version~1.0?> <resultadosConsulta> <fila> <numPedido>112963</numPedido> <fab>ACI</fab> <producto>41004</producto> <cantidad>28</cantidad> <importe>3276.00</importe> </fila> <fila> <numpedido>112983</numpedido> <fab>ACI</fab> <producto>41004</producto> <cantidad>3</cantidad> <importe>702.00</importe> </ fila> </resultadosconsulta>
Elementos y atributos
El modelo relacional ofrece solamente una forma de representar los datos en la base de datos (como valores de columnas individuales en filas individuales de una tabla). El modelo de documento XML ofrece dos formas de representar los datos: Elementos. Un elemento en un documento XML tiene contenidos, y los contenidos pueden incluir un dato en la forma de texto para ese elemento. Cuando se representa de esa forma, el valor del dato es una parte fundamental de la jerarqua del documento XML; la jerarqua est formada con elementos. Frecuentemente, un elemento que contiene un dato ser un nodo hoja en el rbol del documento XML; ese elemento ser un hijo de elementos de un nivel superior, pero no tendr l mismo ningn hijo. Esto ser casi siempre verdad para los elementos que representan los datos que vienen de una base de datos relacional. Sin embargo, XML no admite elementos mixtos, que contienen una combinacin de texto (contenido) y otros subelementos.
y se representara con este documento XML cuando se utilizaran los atributos:

<?xml version~"1.0"?> <resultadoSConsulta> <fila numPedido~112963 fab"'"ACI" producto","41004cantidad~"28
importe="3276.00"> </fila>
888
Capitulo 25: Sal y XMl
889
<fila numpedido="112983"
fab"'~ACI
producto=-41004cantidad","3" importe="702.00"> </fila> </resultadosConsulta>
del documento y de los convenios de la organizacin que utiliza XML y SQL. Adems, los estndares impuestos por la industria para el intercambio de documentos mediante el uso de XML pueden dictar un estilo o el otro.
Uso de"XML con bases de datos

Con el rpido crecimiento de la popularidad de XML los fabricantes de productos de bases de datos se han movido rpidamente para ofrecer soporte XML en sus productos. La forma del soporte XML vara, pero tiende a caer en una o ms de estas categoras: Salida de XML. Un documento XML puede representar fcilmente los datos en una o ms filas de los resultados de la consulta. Con este soporte, el SGBD genera un documento XML en respuesta a una consulta SQL, en lugar de los resultados de consulta fila/columna usuales. Entrada de XML. Un documento XML puede representar fcilmente los datos a insertar, como una o ms filas nuevas en una tabla. Tambin puede representar los datos para actualizar una fila de una tabla, o la identificacin de una fila que se ha de borrar. Con este soporte, el SGBD acepta un documento XML como entrada, en lugar de una solicitud SQL. Intercambio de datos de XML. XML es una forma natural de expresar los datos que se yan a intercambiar entre diferentes sistemas SGBD o entre servidores SGBD. Los datos de la base de datos origen se transforman en un documento XML y se envan a la base de datos destino, donde se transforman de nuevo en formato de bases de datos. El mismo estilo de intercambio de datos es til para trasladar los datos entre las bases de datos relacionales y aplicaciones distintas de un SGBD, tales como los sistemas de planificacin de recursos empresariales (Enterprise Resource Planning, ERP) o de integracin de aplicaciones empresariales (Enterprise Application Integra tion, EAI) corporativos. Almacenamiento de XML. Una base de datos relacional puede aceptar fcilmente un documento XML (que es una cadena de caracteres de texto) como un trozo de datos de cadena de caracteres de longitud variable (VARCHAR) u objeto de caracteres de gran tamao. En el nivel ms bsico de soporte XML, un documento XML completo se convierte en el contenido de una columna en una fila de la base de datos. Puede darse un soporte de XML ligeramente ms fuerte si el SGBD permite declarar la columna con un tipo de datos datos XML explcito. Integracin de datos XML. Es posible un nivel ms sofisticado de almacenamiento XML integrado si el SGBD puede analizar un documento XML, descomponerlo en sus elementos y almacenar los elementos individuales en columnas individuales. Se puede utilizar SQL ordinario para buscar dichas columnas, y proporcionar soporte de bsqueda para los elementos en el documento XML. En respuesta a una consulta, el SGBD puede recomponer el documento XML a partir de sus elementos almacenados.
M
Como se podra esperar, hay fuertes partidarios tanto de los mtodos de representacin de elementos como de representacin de atributos, con slidas convicciones. Los partidarios del enfoque de elementos utilizan estos argumentos:
Los elementos son ms fundamentales para el modelo XML que los atribulaS; son los portadores del contenido en todos los lenguajes de marcas (HTML, XML, SGML, etc.) y eJ contenido de Ja base de datos (vaJores de coJumna) se debera representar como contenido en XML.
El orden de los elementos importa y, en algunos casos, tambin la ordenacin de datos en un SGBD (por ejemplo, cuando se identifica una columna por su nmero en la especificacin de una consulta o cuando se utiliza un nmero de columna para recuperar los resultados de la consulta con una API). Los elementos proporcionan una manera uniforme de representar los datos de las columnas, sin considerar si la columna tiene un tipo de datos sencillo y atmico (entero, cadena) o tipos de datos ms complejos, compuestos, definidos por el usuario, admitidos por las extensiones relacionales orientadas a objetos y SQL3. Los atributos no proporcionan esta capacidad (los valores de los atributos son atmicos).
Los partidarios del enfoque de atributo manejan estos argumentos: Los atributos son un correspondencia fundamental con las colum.nas en el modelo relacional. Las filas individuales representan entidades, por lo que se deberan corresponder con elementos. Los valores de columna describen atributos de la entidad (fila) en la cual aparecen; se deberan representar como valores de atributos en XML. La restriccin de nombres de atributos nicos en un. elemento se ajusta a la unicidad requerida de los nombres de columna en una tabla. La naturaleza desordenada de los atributos coincide con la naturaleza desordenada de las columnas en el modelo relacional fundamental (los lugares en que se usan las posiciones de las columnas son atajos de conveniencia, no fundamentales para las relaciones subyacentes). La representacin de atributos es ms compacta, puesto que los nombres de columna aparecen solamente una vez en el formulario XML, no como etiquetas de apertura y cierre. sta es una ventaja prctica cuando se almacena o transmite XML. Los estilos centrados en los elementos y los atributos se encuentran en XML actual y en los productos SQL. La eleccin depende de las preferencias del auLor
890

<cantidad>ll</cantidad> <importe>27500.00</importe> </fila> </resultadosconsulta>
Capitulo 25: SOL y XML
891
Salidas de XML
Una de las combinaciones ms sencillas de la tecnologa XML y las bases de datos es utilizar XML como formato para los resultados de la consulta SQL. Los resuJta~ dos de la consulta tienen un formato estructurado tabular que se puede trasladar fcilmente a una representacin XML. Consideremos esta sencilla consulta de la base de dalos de ejemplo:
SELECT NUM_PEDIDO,
FROM PEDIDOS
FAB.
PRODUCTO,
CANTIDAD,
IMPORTE
WHERE CLIENTE = 2103; NUM_PEDIDO FAB PRODUCTO CANTIDAD
Esto es tpico de la salida que pudiera recibirse de algn producto SOBO popular que actualmente admita la salida de XML. El resultado de la consulta es un documento XML bien formado y autocontenido. Si se enva el resultado a un analizador XML (los analizadores se describen en la seccin posterior Objetos grandes y analizadores), el analizador los interpretar correctamente partiendo de que contiene: Un elemento raz, resul tadosConsul tao CualIo subelementos fila bajo la raz. Cinco subelementos bajo cada elemento fila, y en este caso, los cinco subelementos que aparecen en cada elemento fila y en el mismo orden. Tener una salida de la consulta con formato XML puede ser una ventaja significativa. La salida se puede mandar directamente a programas que aceptan XML como entrada, para su posterior procesamiento. La salida se puede enviar a travs de una red a otro sistema, y debido a su formato XML sus elementos son autodescriptivos (todo sistema o aplicacin que lo recibe interpretar los resultados de la consulta de la misma forma), como cuatro filas de cinco elementos cada una. Dado que la salida est en su formato, no se malinterpretar, debido a las diferencias en las representaciones de datos binarios entre los sistemas de envo y recepcin. Finalmente, si XML se transmite por un vnculo HTTP mediante el uso de los estndares del protocolo simple de acceso a objetos (Simple Object Access ProlOcol, SOAP), el mensaje con formato XML se puede trasladar a travs de cortafuegos corporativos y vincular la aplicacin que lo origina en una compaa a una aplicacin que lo recibe en una compaa diferente. La salida con formato XML tambin tiene algunas desventajas. Una es el tamao en bruto de los datos. El nmero de caracteres en los resultados con fonnato XML es alrededor de cuatro veces el del formato tabular. Si se almacena el fonnulario XML en disco, se requiere cuatro veces ms almacenamiento. Si se enva a otro sistema de computadora por la red, tardar cuatro veces ms en transmitirse o requerir una red con cuatro veces ms ancho de banda para preservar el mismo tiempo de transmisin. stos no son problemas serios en el caso del ejemplo, dada la pequea cantidad de datos, pero pueden ser muy importantes para los resultados con miles o decenas de miles de filas, multiplicadas por cientos de aplicaciones, en un centro de datos empresarial. Este formato de salida de XML sencillo tambin pierde cierta informacin sobre los datos. El smbolo de la moneda que apareca en la visualizacin tabular ha desaparecido, por lo que es imposible determinar, del contenido XML. que los datos tienen un tipo moneda y qu clase de moneda es. Schema XML proporciona una forma de recuperar esta informacin, como se describir posteriormente en la seccin XML Schema, pero con el inconveniente de todava ms aumento en el tamao del texto de los resultados de la consulta.
---------112963
IMPORTE
-------- -------ACl 41004

41004 41002
----------3 .276,OO
702. DO" 4 .104,OO
112983 ACl 113027 ACl 112987 ACl
28 3
54
4100Y
11 27 .SOQ,QO
Si se instruye al SGBD para que saque los resultados de la consulta en formato XML, veamos qu salida podra resultar:
SELECT NUM_PEDIDO, FAB, FROM PEDIDOS WHERE CLIENTE = 2103; PRODUCTO, CANTIDAD, IMPORTE
<?xml version=~l.O?> <resultadosConsulta> <fila> <num-pe dido>112963</nuID_pedido> <fab>ACI</fab> <producto>41004</producto> <cantidad>28</cantidad> <importe>3276.00</importe> </fila> <fila> <nurn_pedido>ll2983</num_pedido> <fab>ACI</fab> <producto>41004</producto> <cantidad>3</cantidad> <importe>702.00</importe> </fila> <fila>
<num-pedido>113027</nu~edido>
<fab>ACI</fab> <producto>41002</producto> <cantidad>54<lcantidad> <importe>4104.00</importe> </fila> <fila> <num-pedido>112987</num-pedido> <fab>ACI</fab> <producto>4100y</producto>
892
893
Entradas de XML
De igual forma que XML se puede utilizar para representar una fila de los resulta
dos de una consulta que es salida de una base de datos, tambin puede emplearse fcilmente para representar una fila de datos que ha de insertarse en una base de datos. Para procesar los datos XML, el SGBD debe analizar el documento XML que contiene los datos que han de insertarse e identificar los elementos de datos individuales (representados como elementos o atributos). El SGBD debe entonces
ajustar (normalmente utilizando nombres de columna) o traducir (usando un esquema especfico SGBD) el elemento correspondiente o los nombres de atributos para columnas en la tabla objetivo que va a recibir los nuevos datos. Conceptualmente, esta sencilla instruccin INSERT:
INSERT INTO OFICINAS (OFICINA, CIUDAD, REGION, VENTAS) VALUES (23, 'Sevilla', 'Oeste',O.OO)
se puede convertir fcilmente en una instruccin equivalente hbrida SQUXML como sta:
INSERT INTO OFICINAS (OFICINA, CIUDAD, REGION, VENTAS) VALUES <?xml version="1.0"7> <fila> <oficina>23</oficina> <ciudad>Sevilla</ciudad> <region>Oeste</region> <ventas>O.OO</ventas> </fila>
Las actualizaciones de la base de datos se pueden gestionar de forma similar. Esta sencilla instruccin UPDATE:
UPDATE OFICINAS SET OBJETIVO = 200000.00, JEF WHERE OFICINA = 23
Aunque varias marcas de SOBD con SQL han agregado la capacidad de procesar operaciones INSERT, UPDATE y DELETE basadas en XML usando este tipo de enfoque, las tcnicas especficas para representar nombres de tabla y columna y los valores de datos en el texto XML, y para asociarlos a estructuras de bases de datos correspondiente, son especficas de cada SGBD. No hay estndares (todava) para el tipo de sintaxis hbrido SQUXML de estos ejemplos. Aunque representar los valores de entrada y actualizacin como pequeos documentos XML es conceptualmente sencillo, presenta algunos aspectos significativos del procesamiento del SOBD. Por ejemplo, la lista de columnas en una instruccin INSERT de SQL parece redundante si el documento XML que contiene los datos a insertar tambin contiene los nombres de columna como nombres de elemento o atri~ buto. Por qu no simplemente borrar la lista de columnas y permitir que el documento XML especifique qu columnas insertar? Para SQL interactivo no hay ningn problema en realizar esto, pero no es probable que se use el fonnato XML por una sesin SQL interactiva. Para el uso mediante programacin de SQL. el problema radica en que el documento XML y los datos que contiene se proporcionarn al SGBD en tiempo de ejecucin. Si los nombres de columna (o incluso el nombre de tabla) tambin estn proporcionados solamente en el documento XML, entonces el SOBD no puede conocer, hasta el momento de la ejecucin, qu tablas y columnas estn afectadas. En esta situacin el SGBD debe utilizar SQL dinmico para gestionar el procesamiento, como se describe en el Captulo 18, con todas sus pegas asociadas sobre el rendimiento. Se producen problemas similares con la clusula WHERE en una instruccin UPDATE o DELETE. Para conseguir el rendimiento y eficiencia en SQL esttico, el SGBD debe conocer con antelacin (cuando se compila el programa) qu condiciones de bsqueda se utilizarn y qu columnas se actualizarn. Un enfoque para este problema es utilizar la forma pararnetrizada de estas instrucciones. Veamos el mismo ejemplo UPDATE utilizando este enfoque:
UPDATE OFICINAS SET OBJETIVO = 7 WHERE OFICINA = ? JEF
lOS
se puede convertir en su instruccin equivalente hbrida SQlJXML:

UPDATE OFICINAS WHERE OFICINA = 23 <?xml version="1.O"7> <update_info> <values> <objetivo>200000.00</objetivo> <jef>lOS</jef> </values> <where>oficina = 23</where> </update_info>
<7xrnl version="l. 07> <update_info> <param>200000.00</param> <param>10S</param> <param>23</param> </update_info>
y una instruccin
RE,
DELETE requiere solamente la especificacin de la clusula WHEusando los mismos convenios.
Con este estilo, el texto XML y el texto SQL son bastante distintos. El texto SQL es autocontenido y se puede procesar en tiempo de compilacin. El texto XML es autocontenido y el SOBD puede asociar los valores de sus parmetros a los parmetros de la instruccin necesarios en tiempo de ejecucin. Este ejemplo sigue el estilo SQL usual para especificar parmetros por su posicin, pero, como consecuencia, el documento XML pierde una gran cantidad de cualidades autodescriptivas. Dependiendo del SOBD, puede ser posible utilizar elementos con nombre en el documento XML y asociarlos a los parmetros de instruccin con nombre en tiempo de ejecucin.
894
895
Intercambio de datos en XML

El SOBD puede admitir el intercambio de datos de forma sencilla incorporando simplemente la salida de XML para los resultados de la consulta y la entrada de XML para las operaciones IN5ERT. Sin embargo, esto requiere que el usuario o programador construya de forma cuidadosa el formato de los resultados de la consulta generada en la base de datos origen, para coincidir con el formato esperado en las operaciones INSERT en la base de datos destino. El intercambio de datos XML es ms til si el SOBD proporciona ms soporte incorporado explcito. Varios productos comerciales de SOBO ofrecen ahora la capacidad de realizar una exportacin masiva de una tabla (o en una operacin ms sofisticada, los resultados de una consulta) en un archivo externo, con formato de documento XML. A la postre, estos productos ofrecen la misma capacidad de realizar una importacin masiva desde este mismo tipo de archivo en una tabla del SGBD. Con este esquema, el documento SML se convierte en una forma estndar de representar los contenidos de la tabla para el intercambio. Obsrvese que, una vez que se ofrecen las capacidades de importacin y exportacin de tablas basadas en XML, su uso no se limita a los intercambios entre bases de datos. El origen del documento XML en el archivo de intercambio de datos podra bien ser una aplicacin empresarial, como un sistema de gestin de la cadena de provisin (Supply Chain Managemen/, SCM). De igual forma, el destino podra ser una aplicacin empresarial. Adems, muchos sistemas EAI admiten ahora Jos archivos XML. Estos sistemas proporcionan ms capacidades de procesamiento e integracin, tales como eliminar datos duplicados y combinar datos de varios archivos de entrada.
Almacenamiento e integracin con XML

Las capacidades de entrada, salida e intercambios de datos de XML ofrecen una forma muy efectiva de integrar bases de datos relacionales existentes con el emergente mundo de XML. Con estos enfoques, XML se utiliza en el mundo externo para representar datos estructurados, pero los datos en la base de datos mantienen su estructura de filas y columnas tabular y binaria. Al proliferar los documentos XML, un paso natura] es considerar el almacenamiento de documentos XML en s mismo como una base de datos.
Almacenamiento XML sencillo con grandes objetos
admiten documentos de hasta 4 gigabytes de datos CLOB o BLOB, lo que es adecuado para la gran mayora de documentos XML. Para almacenar documentos XML mediante BLOS O CLOS, normalmente se definira una tabla que contuviera una columna BLOB o CLOS para albergar el texto del documento y algunas columnas auxiliares (usando tipos de datos estndar) que contengan atributos que identifiquen el documento. Por ejemplo, si una tabla va a almacenar documentos de pedidos, se podran definir columnas auxiliares para albergar el nmero de cliente, la fecha de pedido y el nmero de pedido mediante el uso de datos INTEGER, VARCHAR o DATE, adems de la columna CLOB para el documento XML. Se puede buscar en la tabla de pedidos segn los nmeros de clientes, fechas del pedido o nmeros de pedido y usar las tcnicas de procesamiento del CLOB descritas en el Captulo 24 para recuperar o almacenar el documento XML. Una ventaja de este enfoque es que es relativamente sencillo de implementar. Tambin mantiene una separacin limpia entre las operaciones SQL (tales como el procesamiento de consultas) y las operaciones XML. Una desventaja es que el nivel de integracin XMUSGBD es bastante dbil. En sus implementaciones ms sencillas, un documento almacenado XML es completamente opaco al SGBD; el SGBD no conoce nada sobre sus contenidos. No se puede buscar un documento basado en uno de sus valores de atributos o de elementos a no ser que se haya extrado un atributo o elemento determinado del documento XML y tambin se represente como una columna separada en la tabla. Si se anticipa por adelantado qu tipos de bsquedas son probables, esto no supone una gran restriccin. Algunas bases de datos relacionales orientadas a objetos proporcionan una capacidad de bsqueda ms avanzada para CLOB ampliando la clusula WHERE de SQL con la capacidad de bsqueda de texto completo. Estos productos permiten buscar columnas CLOB como texto, usando el tipo de capacidades de bsqueda de texto encontrado normalmente en procesadores de texto. Esto proporciona una capacidad expandida, aunque normalmente todava limitada, para la bsqueda de documentos XML almacenados como columnas CLOB. Usando bsquedas de texto completas se podra, por ejemplo, ubicar todos los pedidos donde aparezca la frase Zapatas serie 4. Sin embargo, ser difcil o imposible buscar solamente en aquellos documentos XML donde Zapatas serie 4 se encuentre en un elemento de descripcin de un elemento de un pedido. Debido a que el software de bsqueda no conoce explcitamente la estructura de los documentos XML, probablemente tambin devolver filas donde Zapatas serie 4 ocurra en un elemento de comentario o en algn otro comentario.
Objetos grandes y analizadores
Cualquier SGBD basado en SQL que incorpore grandes objetos contiene automticamente soporte bsico para el almacenamiento y recuperacin de documentos ~ML~ La sec~in titulada Soporte de grandes objetos, en el Captulo 24, describI como vanas bases de datos comerciales almacenan y recuperan documentos de texto grande~ mediante los tipos de datos objetos de caracteres de gran tamao (CLOB) u objetos binarios de gran tamao (BLOB). Muchos productos comerciales
Cuando se intercambian entre aplicaciones O almacenan en un archivo o en una columna SGBD CLOB, los documentos XML estn tambin en la forma de texto. Esto hace que los contenidos sean muy transportables, pero difciles de manejar para los programas informticos. Un analizador XML es un trozo de software que traduce los documentos XML de su forma texto a una representacin interna ms afn al programa. Cualquier SGDB basado en SQL que admita XML tendr un
896
897
analizador XML como pane de su software, para su propio uso en el procesamiento XML. Si la marca del SGDB admite CLOB, se puede proporcionar ms integracin con XML permitiendo que un analizador XML opere directamente sobre los contenidos de las columna eLs. Hay dos tipos populares de analizadores XML, que admiten dos estilos de procesamiento XML: Modelo de objetos documento (Document Object Model, DOM). Los analizadores DM transforman un documento XML en una estructura jerrquica en rbol en la memoria principal de la computadora. Un programa puede entonces hacer llamadas al API DOM para navegar por el rbol, movindose arriba y abajo de forma secuencial por la jerarqua del elemento. La API DOM hace que la estructura del elemenLO de un documento XML sea fcilmente accesible a los programadores y simplifica el acceso aleatorio a las porciones del documento. Simple XPI para XML (SAX). Los analizadores SAX transfonnan un documento XML en una serie de retrollamadas a un programa, que informa al programa de cada parte del documento XML segn las va encontrando. Un programa se puede estructurar para que adopte ciertas acciones cuando encuentre el comienzo de una seccin del documento o cuando encuentre un atributo particular. La API SAX impone un estilo ms secuencial de procesamiento sobre el programa que lo utiliza. El estilo de la retrollamada de la API coincide bien con una estructura de programa dirigida por eventos. El tipo de analizador XML validar que un documento XML est bien formado, y tambin puede validar un documento XML en un esquema, como se describe en una seccin posterior de este captulo, XML Schema. Un analizador DOM es prctico cuando el tamao del documento almacenado XML es bastante pequeo; requerir el doble de espacio de memoria que el documento de texto XML, puesto que genera una segunda representacin estructurada en rbol de todo el documento. Para documentos muy grandes, un analizador SAX hace sencillo el procesamiento en trozos pequeos y diferenciados. Sin embargo, el hecho de que todo el documento no est disponible a la vez exige que un programa realice varias pasa das si ste necesita procesar varias secciones del documento que no estn en el orden secuencial.
Clculo de referencias XML
Almacenar documentos XML como objetos grandes en una base de datos es una excelente solucin para algunos tipos de integracin SQUXML. Si los documentos XML son, por ejemplo, documentos del negocio orientados a texto o si son componentes de texto de las pginas Web, entonces hay realmente muy poca necesidad para el SGBD de comprender las interioridades de los documentos XML. Cada documento se puede identificar, probablemente, mediante una o ms palabras clave o <\tributos, que se pueden fcilmente extraer y almacenar como columnas convencionales para la bsqueda.
Si los documentos XML a procesar son realmente registros de procesamiento de datos, la sencilla integracin proporcionada por los objetos grandes puede ser, sin embargo, demasiado primitiva. Probablemente se desear procesar y acceder a los elementos individuales, y buscar basndonos en sus contenidos y atributos. El SGBD ya proporciona estas capacidades para sus datos nativos fila/columna. Por qu el SOBD no puede descomponer automticamente un documento entrante XML, transformando sus contenidos y atributos en un conjunto correspondiente de datos internos fila/columna para su procesamiento? En el otro extremo ya hemos visto cmo este enfoque puede funcionar para transformar los resultados de la consulta fila/columna en un documento XML. Esta misma tcnica se podra utilizar para recomponer un documento XML si se necesitara otra vez en su formato de texto externo. El desafo de transformar documentos XML, que son una representacin de datos externos ~xcelente, a y desde representaciones de datos internos ms tiles para los programas, no es nico para los sistemas de bases de datos. Los mismos problemas se dan, por ejemplo, en el procesamiento con Java de XML, donde es muy deseable transformar un documento XML a y desde un conjunto de instancias de clase Java para su procesamiento interno. El proceso de descomponer un documento XML en sus elementos y atributos, en alguna representacin interna y binaria, se denomina resolucin de referencias (unmarshalling) en la literatura XML. De forma contraria, el proceso de recomponer estas representaciones de elementos y atributos individuales en un documento XML de texto se denomina clculo de referencias (marshalling). Para los documentos XML muy sencillos, el proceso del clculo y la resolucin de referencias son muy sencillos y los productos SOBD comerciales se transforman para albergarlos. Consideremos una vez ms el documento simple de pedi~ dos de la Figura 25.3. Sus elementos se corresponden directamente, uno a uno, con columnas individuales de la tabla PEDIDOS. En su caso ms sencillo, los nombres de los elementos (o atributos) sern idnticos a los nombres de las columnas correspondientes. El SGBD puede recibir un documento XML como el utilizado en la figura, devolver automticamente sus elementos (o atributos, dependiendo del estilo utilizado) en valores de columnas, utilizando los nombres de elementos (o nombres de atributo) para dirigir el proceso. La reconstruccin del documento XML de una fila de la tabla tampoco es un problema. El SGBD debe realizar ligeramente ms trabajo si los nombres de los elementos en el documento XML no coinciden de forma precisa con los nombres de columnas. En este caso se debe especificar alguna clase de asociacin entre los nombres del elemento (o nombres de atributo) y los nombres de columna. Es relativamente sencillo poner dicha asociacin en el catlogo del sistema SOBD. Muchos documentos XML reales y tiles no se corresponden exactamente con filas individuales de una tabla. La Figura 25.4 muestra una sencilla ampliacin del documento XML de pedidos de la Figura 25.3, que incorpora el requisito tpico de la vida real de que un pedido puede contener varios elementos. Cmo se deberan resolver las referencias de este documento XML en una base de datos de ejemplo? Una solucin es convertir cada elemento de lnea del pedido de compra en una fila independiente de la tabla de PEDIDOS (ignoremos por el momento que cada fila en
898
899
<?xml version="l.O"?> <compraPedido> <numeroCliente>2117</numeroCliente> <nmeroPedido>112961<!nmeroPedido> <fechaPedido>1989-12-17</fechaPedido> <nmeroRep>106</nmeroRep> <trminos envio="superficie" factura="Net30"></crminos> <elementoPedido> <fab>REI</fab> <producco>2a441</producto> <cantidad>7</cancidad> <importe>31500.00</importe> </elementopedido> <elementopedido> <fab>ACI</fab> <producto>41003<!producto> <cantidad>lO</cantidad> <importe>6520.00</importe> </elementoPedido> </compraPedido>
Resolucin de referencias.
Documento XMl
.. Calculo de referencias
Tablas de la base de datos
------------------------Figura 25.5.
.,-
--
--{---
Figura 25.4.
Documento de pedido XML ligeramente expandido.
la tabla PEDIDOS debe contener un nico nmero de pedido, puesto que el nmero de pedido es la clave principal). Esto producira alguna duplicacin de los datos, puesto que aparecer el mismo nmero de pedido, fecha de pedido, nmero de cliente y nmero de representante en varias filas. Tambin realizara el clculo de referencias de los datos para reconstruir el documento ms complejo (el SGBD tendra que conocer que todas las filas con el mismo nmero de pedido debera calcular la referencia en un documento XML de pedidos con varios elementos de lnea). Obviamente, el clculo/resolucin de referencias, incluso de este documento sencillo, requiere una asociacin ms compleja. El pedido de compra de varios elementos se queda simplemente en la superficie del clculo y en la resolucin de referencias de los documentos XML. La situacin ms general se muestra en la Figura 25.5, donde el SGBD debe resolver las referencias de un documento XML en varias filas de varias tablas interrelacionadas. Para calcular las referencias del documento, el SGBD debe aplicar las relaciones entre tablas para encontrar las filas relacionadas y recomponer la jerarqua XML. La razn subyacente de esta complejidad es el desajuste entre la estructura jerrquica natural de XML y la estructura normal en filas y columnas de una"base de datos relacional. El clculo y resolucin de referencias se simplifica y se hace ms complejo si el SGBD admite extensiones relacionales orientadas a objetos, tales como los ti pos de datos estructurados. La traduccin a1desde XML puede ser ms sencilla, puesto que las columnas individuales de una tabla pueden ahora tener su propia estructura jerrquica. Un elemento XML de nivel superior (con ~lementos tales
Clculo y resolucin de referencias XML para una base de datos.
como una direccin de facturacin compuesta por la calle, ciudad, provincia, pas y cdigo postal) se puede convertir en una columna que se corresponda con una de tipo abstracto de datos DIRECCION, con su propia jerarqua interna. Sin embargo, la traduccin aldesde XML exige ahora ms decisiones en el diseo de la base de datos, conservando la simplicidad del clculo y resolucin de referencias de los tipos de datos estructurados, frente a la flexibilidad de un enfoque de filas y columnas aplanadas. Varios productos comerciales estn comenzando a ofrecer capacidades de clculo y resolucin de referencias, y han anunciado planes para proporcionar esta capacidad en versiones futuras. La disminucin en el rendimiento de esta traduccin puede ser sustancial y todava queda por ver cun populares sern en la prctica estas capacidades. Sin embargo, si una aplicacin gestiona datos externos en formato XML, debe producirse en algn punto la traduccin entre los datos XML y SQL, y la traduccin en el propio SGBD puede ser el enfoque ms eficiente.
XML y metadatos
Una de las cualidades ms potentes del modelo relacional es su muy rgido soporte para los tipos de datos y estructuras de datos, implementado por las definiciones
900
. :CaptuJo.Q5: SOL y XML
90~
de tablas, columnas, claves principales, claves externas y restricciones. Adems, como se mostr en el Captulo 16, el catlogo del sistema de una base de datos relacional contiene metadatos o datos sobre los datos en la base de datos. Cuando se consulta el catlogo del sistema, se puede descubrir la estructura de la base de datos, incluyendo los tipos de datos para sus columnas, las columnas que comprenden sus tablas y las relaciones entre las tablas. Por el contrario, los documentos XML proporcionan por s mismos solamente metadatos muy limitados. Imponen una estructura de elementos jerrquica sobre sus datos, pero los nicos datos reales sobre la estructura son los nombres de los elementos y atributos. Un documento XML puede estar bien formado y an as tener una estructura bastante irregular. Por ejemplo, no hay nada que permita evi tar que un documento XML bien formado tenga un elemento con nombre que con tenga datos de texto en un ejemplar y subelementos en otro ejemplar, o que un atributo con nombre tenga un valor entero para un elemento y valores de fecha para otro. Claramente, un documento con esta estructura, aunque est bien formado, no representa datos que se transformen de manera sencilla a1desde una base de datos relacional. Cuando se utiliza XML para documentos de procesamiento de datos, se necesita un soporte ms fuerte para los datos y una estructura ms rgida, Los estndares y productos XML han resuelto esta necesidad de varias formas durante la corta historia de las tecnologas XML. stas incluyen:
.";,' pIo, las empresas. de, servicios:financieros estn trabajando en estndares que describen instrumentos financieros (acciones, bonos, etc;) y datos del mer_ ,cado. Las .empresas manufactureras estn trabajando en estndares que des. criban los, documentos de pedidos, confirmaciones de pedidos y cosas parecidas. Estos estndares para los documentos especficos orientados a la industria se construyen normalmente sobre estndares genricos tales como D.TD y XMLSchema. ,. ,o . ,.:.>
:.,
El rea de metadatos XML y estndares para tipos de documentos est evolucionando ,rpidamente. El.consorcio..W3C proporciona-:un sitio Web actualizado ffecuememente en h/lp://www.w3.or;g, el cuaL proporciona acceso a los diferen tes estndares.relacionados con WML.e informacin sobre sus estados. Se puede encontrar informacin sobre estndares especficos para la industria en http:// w.ww.xml.org, 'un sitio organizado y.albergado: p.or OASIS (Organization for the Advanc.ement <?f Structured Inforrnation Systems," org.anizacin para el avance dejos sistemas estructurados de informacin).. EIsitio contiene un registro de estndares 'basados en XML, clasificados por industrias.
~
..
..
:
~.
r~;
'.' ,,'~
:.
'
',.:;
, .- '; Z",
,~" .'~:: ',;,!
.~~:
:.\
Definiciones de tiposde documentos.fOTO)
",:' ,
.' r:... ' :.. ;; ' .. ' '.,
Definiciones de tipos de documentos (DTD, DOCllIllent Type Definition). Una parte de la especificacin original de XML 1.0, las definiciones de tipos de documentos, proporcionaba una forma de especificar y restringir la es tructura de un documento. Los analizadores XML pueden examinar un do cumento XML en el contexto de un DTD y determinar si es un documento vlido (esto es, si cumple con las restricciones DTD). XML-Data. Enviado al W3C en 1998, XML-Data fue un intento temprano para solucionar algunas de las deficiencias en el esquema DTD. Nunca recibi el acuerdo de W3C, pero muchas de sus ideas se han trasladado a la especificacin de XML Schema. Microsoft adapt su propia forma de XML Data, denominndola XML-Data Reduced (XDR), y la implement como parte de su servidor de integracin BizTalk y el explorador Internet Explo rer 5.0. La energa invertida en la propuesta XML-Data se traslad, entre el final del ao 1999 y el ao 2000, a la propuesta XML Schema. XML Schema. Una especificacin independiente que se convirti en una recomendacin W3C en mayo de 2001. XML Schema se construy sobre XML-Data y desarroll las ideas de ste. XML Schema proporciona un soporte de tipos de datos mucho ms riguroso y tiene la ventaja de que la definicin del esquema (los metadatos del documento) se expresa por s misma corno un documento XML, de una forma muy parecida a como se proporcionan los metadatos de la base de datos relacional mediante una estructura de tabla relacional estndar. Estndares de los grupos industriales. Varios grupos industriales se han agrupadq para definir estndares XML para tipos especficos de documentos que son importantes para el intercambio de datos en su indu~tria. Por ejem~
El primer intento de estandarizar: los.metadatos XML estaba "Contenido en la capacidad df::JDefinici6n de tipos-de, dodjinentds (DT.D)" tic"la"especificacin original XML 1.Q. 1.os DTD se utilizan para.especificar la'forma y estructura de un tipo de document'o partioular:(cQmo un' documento' de,pedido"o un documento:de transferenci"tle-fonUos). La 'Figura 25.6 muestra un DTD'que se podra. utilizar para un documento de pedido sencillo en la Figura 25.5. Esta DTD demuestra, solamente
,_',.' : J';;;" ,-;
',;;'_,...
..:
)1:" ,r: ',:
:._';' '::X,::s;:;:.';
~'!fE'i.k~E;'<!.'cb'~ptapedidb . (nurriero'ci.'iente, ninerPedido,

." i!:r:f-, ""hFi;',J... ;:".).
< !A,LI::M::N.~I.nP!lle:C9cliente
"
fecha Pedido ,
(#PCDAT.A) > ...
-
trminos',
elementOPedido*)'>
.<'!;ELEMENT, fecha Pedido
.' <'YA''TL1:ST', t-rn\{116s '" ':',. o' ;verurio" CDATA.; : .. ;#[9-:;t~~~ ... t:;;P!'>-'PA,;~REQUIREQ> . : : . ' , '.'~ ,.~l, ..:. j,' <!P:LEHENT. ~l~mentopedido (fab. producto, ,cantidad. importe).> <'(E:~M'ENT" i:'~b ' f.iPCDATA) > ,'. ' .',
y ' ,. "
, !i:'LEMENT 'teinitnos
~\r;~~~~~' ~~'F.rORep (i peo'ATA) >"

EMPTY>
('PCDATAj >,
:!"
'"
<'Fk'Li~ENT: p~~dcto (#PCDATAj> <'! ELEMENT cantiilaad! (#PCDATA) >' ~,,, ' <!ELEMENT :~mp.o~te, ('PCDATA 'o' , . ',' ~. , :;.;J' ,::'_",,!:
;':A,q
>C
i;[
"y
: ;1
'j
"
':;H,;';'
, . fl
";',;
.. ' "
. i: .. ,; ~ "
,,;: .. :'... l.,
Figura .25.6.! DTD- para un' documento.simple d.e pedidos.
902
903
una fracci6n de las capacidades completas de las DTD, pero ilustra los componentes principales de una DTD tpica. Las entradas ! ELEMENT en la DTD definen la jerarqua de elemento que da al documento su forma bsica. Las DTD mantienen estos tipos diferentes de elementos:
Elemento slo de texto. El elemento contiene solamente una cadena de texto, que puede representar un valor de una nica columna de datos de la base de datos. Elemento slo elemento. El contenido del elemento son otros elementos (subelementos); es el padre en una jerarqua de elementos padre/hijo local. Este tipo de elemento se puede utilizar para representar una fila de una tabla, con subelementos que representan columnas. Elemento con contenido mixto. El elemento puede contener una mezcla de comenidos de texto entremezclados y subelementos. Este tipo no se utiliza normalmente para los contenidos de la base de datos, puesto que esta mezcla de subelementos y datos no aparece de forma natural en la estructura filal columna de las tablas. Elemento con contenido vaco. El elemento no tiene contenido (ni subelementos ni contenido de texto), pero puede tener atributos. Este tipo de elemento puede representar una fila de una tabla cuando sus atributos se utilizan para representar valores individuales de columna. . Elemento con cualquier contenido. El elemento tiene un contenido no restringido. El contenido puede estar vaco o puede contener una mezcla de subelementos y/o texto. Como el elemento de contenido mixto, este tipo no es til normalmente para documentos XML utilizados en el procesamiento de bases de datos.
En la DTD de pedidos de la Figura 25.6, el elemento de nivel superior compraPedido y el elemento elemento Pedido tienen el tipo s6lo elemento. Sus declaraciones listan los subelementos que contienen. Los elementos numeroCliente y fecha Pedido son elementos slo de texto, indicado por las definiciones #-PCDATA. El elemento trminos est vaco; solamente contiene atributos. Ambos atributos tienen valores que son datos de caracteres (indicado por el tipo CDATA); uno es necesario y el otro es opcional, como se indica. Obsrvese que esta DTD combina un estilo datos-corno-elementos (para la informaci6n del cliente) y otro estilo datos-corno-atributos (para los trminos del pedido) solamente por facilitar la comprensi6n. En la prctica se elegira un estilo o el otro para la representacin de los datos y se utilizara de forma conherente para simplificar el procesamiento. Las definiciones de tipos de documentos son fundamentales para hacer que XML sea realmente til, en la prctica, en la representacin de documentos estructurados para el intercambio de datos. Permite definir los elementos esenciales de un documento transaccional, como un pedido o un formulario de empleados, o un formulario de solicitud de la cuota. Con una DTD para la implementacin de dicho documento~ resulta sencillo validar que un documento originado en alguna parte de la compaa, o incluso fuera de la compaa, sea un documento vlido del
tipo especfico y se pueda procesar. Cualquier analizador XML, basado en las API DOM O SAX, es capaz de validar un documento XML en previsin del suministro de una OTO. Adems, es posible declarar de forma explcita la OTD con la que el documento XML se debera ajustar dentro del propio documento. No obstante, las definiciones de tipos de documentos tienen algunos inconvenientes. Carecen de los tipos de datos fuertes encontrados en las bases de datos relacionales. No hay forma de especificar que un elemento debe contener un entero o una fecha, por ejemplo. Las DTD tambin carecen de un buen soporte para tipos definidos por el usuario (o corporacin) o estructuras de subdocumento. Por ejemplo, es posible que el elemento elemento Pedido en la Figura 25.6 aparezca no solamente en un documento de pedidos, sino tambin en un documento de modificacin de pedidos, un documento de cancelaci6n del pedido, un documento de pedidos atrasados y un documento de acuse de recibo del pedido. Sera conveniente definir una vez la subestructura elementoPedido, darle un nombre y entonces referirse a ella en estas otras definiciones de documento; sin embargo, las DTD no proporcionan esta capacidad. Las DTD tambin son de alguna forma restrictivas en los tipos de estructuras de contenido que permiten, aunque en la prctica son lo suficientemente ricas para admitir las clases de documentos transaccionales necesarias para aplicaciones hbridas base de datoslXML. Finalmente, las expresiones utilizadas por las DTD para definir la estructura del documento son una forma ampliada de BNF (Backus Naur Form) (un ejemplo de esto es el asterisco que aparece despus de la declaraci6n elementoPedido en la lista de elementos compraPedido, en la Figura 25.6, que significa este elemento se puede repetir cero o ms veces). Aunque resulta familiar para los estudiantes que tratan con lenguajes informticos, este formato no lo es para aquellos que se acercan a XML desde el mundo HTML de marcas de documento. Todas estas deficiencias se hicieron visibles poco despus de la adopcin de XML 1.0, Y el trabajo comenz definiendo una capacidad de metadatos mayor para documentos XML. Finalmente, estos esfuerzos resultaron en la especificaci6n de XML Schema, descrito en la siguiente secci6n.
XML Schema
XML Schema 1.0 se convirti en una recomendacin W3C oficial en mayo de 2001 y su soporte est creciendo rpidamente en productos comerciales relacionados con XML. Las DTD estn todava ampliamente admitidas para compatibilidad hacia atrs, pero XML Schema ofrece algunas ventajas convincentes y soluciona la mayora de inconvenientes de DTD. La Figura 25.7 muestra el esquema de documento para el documento de pedidos en la Figura 25.5, esta vez definido mediante XML Schema. Es til comparar la declaraci6n de XML Schema de la Figura 25.7 con la declaracin DTD de la Figura 25.6. Incluso este sencillo ejemplo muestra el gran soporte para tipos de datos en XML Schema; los elementos y atributos tienen tipos de datos que se parecen mucho a los tipos de datos SQL. Adems, el esquema en la Figura 25.7 es en s mismo un documento XML, por lo que
904
SQL. Manual de .referencia
.; Captulo,25: .SOL y XML
9Q5
__ I;;:r;
Tabla 25,1. ' Tipos de datos incorporados..en XML Schema

<schema xmlns="http://www.w3.orgi2001/xMLschema-> type="tipoPO 1>
Tipo de datos de XML Schema

Datos llumricos
Integer
-" J>.escripcin
,lir
<element name="compraPedido <complexType n?me="tipoPO">

<sequence> .... l
. Nmero'entero. Enteros positivos solamente. Enteros negativos solamente.

Enter~~,
<element name="numeroCliente" type="integer" <element riame="hmeroPedido type="integer- 1> <element"name="fechaPedido type="date" 1> <element name="nmeroRep type="integer- length=")" 1> <element name="trminos"> <attribute name="envio' type="string" /> <att~ibute name="factura" type="string" /> </element>
. 1>
Positivelnteger Negativelnteger NonNegativelnteger NonPositivelnteger
positivos o cero solamente.
Enteros negativos o cero solamente. .Entero con signo de 32 bits. Entero sin signo de 32 bits. .. , ,., ,~~t!?r<C? ~p'n signo de 64 bits. , ;'Entero,sin signo de 64 bits. '\:Entero con signo de 16 bits.
~:' /Eilter~;sin signo
._
InC
Unsignedlnt Long
.'
<element name= elementoPedido -minOccurs= O

maxOc~urs="unbound~d>
<complexType>
,.
, '
~.,
.,
... ' o . . - .
<s:~~:~~::. name='.'f~b.
type:. string" "length;;"'3 . <elern:nc.; name='"producto type="stri'ng" 1>. '-.1., <element name=cantidad-type=-integer~ .:_., . /> .<el.ement _name.=.if!l~ort:e_. t.yp~=.:decitr~.'l,'. ;,t ':'" .
fractiondigits=2~
>.,
'.'( '.,
'.)" ,
unsignedLOng Short . ,,,) '... h ' UnsignedShort

_ _ . ._
~~
.'.'
~,,:
__ .. _
,
_ .... ._
-.
. " .
t, f'::-"
~L.. l'"
~.'_
.;:. ;;.
de 16 bits.
' , __ 0
'';'1:-: ti-,L!t.'"
A _ _ . _
. _
~-
</~~:;i~:~~:>t' :~."
</element> </sequence> </complexType>
~/$chema>
., ." ".<':.: .:.... :,~. -;.::~

1>
o;.
,~!:': ,<.,. ,j':<~'.~"~"J

'. ;...'. -.-:'"
,.'
Decimal Float Double"" ..

,, '{ . ,:". ,: ; . '
Numrico, con posibles nmeros decimales. Coma flotante con precisi6n estndar. Coma' tlotar,tte: con' precisin -dobl.
J,
;-._ ,,' :'
~,=! -:!',,:".
:c,;
'~'
.-'
u'.
~ '1'
'': 'l';)'
L:;:' 1'-
. ".
;,-
i:-li';:'~-:
'..11,' :i':.:U:,:"':.
;\'=
. ,1 . ;~i
o!
" , . ,.. --;-' ---.C-
<~"
~:'
_U::'':A 1>::: :;;)'!:',;, .... l:,,~, ''I!' :1'I:T~l .')r.

'~-il"''-
Datos de caracteres
String NormalizedString Token
. ~::C"
:,E:
<
Cadena
de.caract~;~s ~d~ longitud ~~i;ble.
-'1 (.,
'j:. '-"l"
,:-,
Figura , . 25,7.
XML Schema para un documento sim'ple de pedidos,

. " "..,'. -; ( ... '. - : . . ':-"
_"
.~,
''''._,.
-:'\....
~-,--:
'.-~;
J,.
': . ij:F '" (':
.;IJ
~l:!"
i,iI:!
';:;'~':';
.,
,.,j,.
Cadena con cafactefes de nu~va )ea, i~~~{no del carro y tabulacin converi:idos,a.espa~~o_<-~ _ Cadena, procesada como normaliz-edStf.fn~; ms eliminaci6n de espacios delante y detrs y
es ms legible para alguien que est familiarizado con los fundamentos de XML
::;-:..
que la DTD de la Figura 25.6.

'~(l\:;:'fo~,(;
j,\ r)
;;:!' >.l:;"'::[;i;:; .';
'o~:. ~;, varios:espacios:tranrliila"ds'-'e"nf'tin hfeo r, '.' ',. ':"-.espacio. ,_ : '';-_;1: 1': .'1.:":'.,1: :,..:,) ~,'-:"!!:';'-.
f:i .. : .l:;~':>,:.:: \;i ~:r '_t;.
Tipos de datos en XNL ' Sch.e.ma . . "
:.:,
';',(.'.
(:,,! ,:,;~:r!,j'; ~~:'::
Desde el punto de' vista de' las bases de datos. tel:fuerte 'soporte dCi)~L:;..St;:hrii para los' tipos .de, datos y' estructuras.de,.datos~e.S-una:-:de Sus(princpaIes"l.ventajas. XML Schema define alrededor'de 20 tipos de.datosincorpO'raaos;''ql,le''se-corres':
~~~;:eI~~:~:E~~;":::;,:-:::'::::;::2~'(:~ofa:;:,i :ir,~~~~@i~,~;;~~;,:;i~;~~;~~;':~,;
Date'time!: .;;'"
.
~.:. ~",i .::
,;.. '
, l . j;' .
ponden bastante bien con los tipos
dedatsu~fiidosen 'S()L,La,Taola'25.Ylistl
jhia-ifi~!;~'J
,.,:'';
1:';:;: :',. ".. ;-:

:.. ' "J:; .. :-; ..;::
,!;;,ll"l;':'; ',;; , ,,'
:~Da~~;h<.?ia (equivalente a_Il'I~STl\MB de: SQJ.i)~,.;: n:,:,i ESp'tio' iem~o'raf(equ:i~ii~h't 'ri'RATIide')':' ,;f'! g'Qt):) "['i.~'l';;:f::i. r,' ,.:.'f:'f!_',i 'Ji; ;~ t,l~;-;.i:I!:"
los tipos ,de datos incorpordos en XML Schema.!TIs importantes .par3.'.e) procesamiento de bases de datos. :. __o - ,".:;'~~~'~ ,{j4:: . rAlo igual que los estndares SQL2,y :SQL3, XML-.Schemaadmite.tipos. de datos definidos por el usuario derivados de estos\tipos im;;or.poJ"adoso,de otros tipos definidos por el usuario. Se puede especificar un;tipo.de datos'gevado como una restriccin.o otro tipo XML. Por ejemplo; veamos unadefinicin;de un tipo
~;i,~,;.jJ'P :l
Gm.on_tru." Gyear,-q::
;)f:C'.,
':l:\;;~fi !:,' ~':r-fSo1~:m~~a:a:6cil~;~i.:" :.. ~_;l~::;;.:.:~:~l:!.:~~:![~":;;'.'~~

,,','.-::'(: Jt-!/!j
,.
~...
-,:"~, 'l'.;~,~ '~l! :;..-,l~vi...iMes.gr~gQriqnQ:-'LJa.I..2).;.
<-'
ln'
.(,~"", .0'
",'; -:~uA-O,<~egriantr(dOOd:a:9999!.(,-!-':.;.: ''::-4' _ .. _ _ '_.. . 1

. . "'_.
~
,.
...
-~.
-. ....
./.", 1J;:;:!'! ,:~ ;-.".Jj ;,(.c.ollfina)
906

Tipos de datos incorporados en XML $chema (continuacin)

<complexType name="tipoDirCliente~> <sequenc:e> <element name="calle" type=string" /> <element name="ciudad" type="string" /> <element narne="provincia~ type="string" /> <element name="cdigoPostal" type="integer" /> </sequence> </compleXType>
907
Tabla 25.1.
Mtodo
Significado
Gday GmonthDay
Da gregoriano (1 a 31).
Mes/da gregoriano.
Otros datos
Boolean Byte unsignedByte base64Binary HexBinary AnyURI Language
Valor TRUE/FALSE.
Dato de byte sencillo. con bit de signo. Dato de byte sencillo. sin bit de signo.
DalO binario, expresado en notacin de base 64. Dala binario, expresado con nOlacin hexadecimal.
Internet URI, tal como http://www.w3.org. Lenguaje XML vlido (ingls, francs ... ).
Tambin se puede crear un tipo de datos definido por el usuario que sea una lista de elementos de datos con otro tipo. Por ejemplo, veamos una definicin para un tipo complejo tipoListaRep, que es una lista de nmeros de empleado de los representantes:
<simpleType name= ~ t ipoListaRep" > <list itemType= " tipoNUmRep" /> </simpleType>
derivado tipoNumRep que restringe el nmero de empleados legales a un campo entre 101 y 199:
<simpleType
name=~tipoNumRep>
XML Schema tambin permite sobrecargar un tipo de datos definido por el usuario, pennitiendo adoptar uno de varios tipos de datos subyacentes dependiendo de la necesidad especfica. Por ejemplo, en la definicin anterior tipoDirCliente, el cdigo postal de la direccin se define como un entero. Esto funciona para los cdigos postales espaoles (excepto en que no preserva los ceros), pero no para los cdigos postales de Canad con seis dgitos, que incluyen letras y dgitos. Un enfoque ms internacional es declarar las versiones espaola y canadiense y posterionnente un cdigo postal ms universal, que puede ser cualquiera de los tipos:
<simpleType
name=~tipocpesS">
<restriction base="integer"> <minlnclusive value="lOl" 1> <maxExclusive value="200" /> </restriction> </simpleType>
<restriction base="integer~> <totalDigits value=S /> </restriction> </simpleType> <simpleType name="tipoCPcan6"> <restric:tion base="string-> <length value=6 /> </restriction> </simpleType> <simpleType name="tipoCPint"> <union memberTypes=tipoCPesS tipoCPcan6" /> </simpleType>
Con este tipo de datos definido se pueden declarar entidades o atributos en un esquema que tengan un tipo de datos tipoNurnRep, y se implementa automticamente la restriccin. XML Schema proporciona un rico conjunto de caractersticas de tipos de datos (denominadas facetas) sobre las cuales se pueden construir restricciones. stas incluyen el tamao de los datos (para datos de cadena y binarios), rangos de datos inclusivos o exclusivos, nmero de dgitos y dgitos fraccionarios (para datos numricos), y listas explcitas de valores permitidos. Hay incluso una capacidad de coincidencia de patrones incorporada, donde los valores de los datos se pueden restringir mediante el uso de una sintaxis de expresin regular como la utilizada en el lenguaje Perl. El XML Schema tambin proporciona la posibilidad de definir tipos de datos complejos, que son estructuras de datos definidos por el usuario. Por ejemplo, veamos una defini~in de un tipo complejo tipoDirCliente que est compuesto de subelementos familiares:
Con las definiciones de tipos de datos especificados por el usuario se puede definir con mayor facilidad estructuras mayores y ms complejas. Por ejemplo, veamos una parte de un documento de pedidos en la Figura 25.7, expandido para incluir una direccin de facturacin y envo y para permitir una lista de representantes:
<complexType name=-compraPedidoType">
... Aqu van otras declaraciones de elementos ...

<element name="DirFactura"
type="tipoDirCliente~
/>
90S
sat. MiUfiJal'de.f'eferncia
1->.~':
':- -Captulo 25, Sal_ y XML

.-
909
<element name= DirEnvo type= tipoDirCliente : <element name="numReps type=-tipoListaRep 1>

o
comilla con otras declaraciones de.elementos...
Elementos y atributos en XML Shema .
"
,."
.,,",;"
..
ma lOcorpora las mlsmo"s tipOS de-elementos bsIcos definidos en el modeloDTD:

!. ':.
~~ ~~~~~~~:t.?s Y}.o~, ~1~!TI.e:"~?sy ~tn~}Jt~s .P7~~J.t~~~s qu~.~p~r~~I~ X:~L.S~~e

",!,'-""J ';', .;
~
Adems del soporte para una rica estructura de tipos de datos, XML Sehem"tanibjn.prO~?~ci~l).,a! ~~ ~icl? voc.':lb.ul3;~~~ P~f:? ~~p~s~_ryc.~~ la ~struc.t~:.~ leg~~.?~ .I.Jn.tipo
"'-;
_'o . '"
~:
":.: ;":
'.
-,..
'1.: .' .. -.,;: ....
I~'
cuencia de elementos, los cuales deben estar presentes en su totalidad. en el orden especificado.- 'Oe'fnna altemativa"se puede' especificar ua e"lccion :oe~el.ementos, indic~ndo que debe aparecer sol~~~~t~,.~h?~ d~~. 9~ ~?~j~~~9~;?~),\I~.O~\'~~:~1f.mentos defimdos. XML Schema .propprp.~~.a ,u~" CQltrql ~Sl.~tl<y" .~e lo~ .<j.,tfibuJ9~ . "Se. puede especificar un atributq, .inqiyidJ.al c9IJlo: opc.ional .o r~q)e;rigo, ,S~: . p'ue~{~~~~pecificar un valor de atributo predeterminado;: ste-sehade 'utilizar.si' no.se proporciona un valor explcito 'en la instancia del'dumento o' un' valor <le atributo' fijo,' que fuerza al atributo a tener siempre el valor'eSpecifitdo"en utFejempl.ai'de dc'itento. Los grupos de. atributos permi.ten definir: y dar nombre a un grupo de atributos gue .nor~':llmerite se' utiliz'iul jritos. l giupq co"rU'pi~lb de ~!6ibt;s: se 'i;!bd' de'la~rat:para
Contenido sencillo. El elemento dispone solamente de eontnii:lo' de texto

(aunque, como se explic en la seccin anterior, el te~~o se puede restringir a datos de un tipo especfico, como unaJecha o.un~ 'valor numri~). ?~te tipo de contenido se define utilizando un elemento simpleContent., , , . :. Contenido solamente elemento. El elemento contiene solamente subeleM .,i':.. :J:;mentos,.. Este~tipo ..d.e:.:.c.ontenido se",define iutilizande. iiri' elemento ;comp:lex!:! ~L
::, :f~nalm~W,te~ ~ $9~7!Tl.':l.P_~o~qf~.1O~?a. s9Pory.~ C?p1P~~fR.R~a. !:~. ~sp',aq,~o,s .~~ ~o,!!3r~.r ~M~,~ gULt;.~~ .~~IIJI,~~~,pflf~ ..~l~a~~p',~.y ges,iu;mar !.1!l?~t:nt~~ v?fapul51,r~l!,~
?n~~J~~ent~~;q~'~_I<~9.~~~.~~3;~?O~~;~qi:n~fe ~l:~p?' 4~.Ji~~ul~s.~, ;~:~~" ;lt ~:~~._
Ty.p.e .... ,;;;);, (..,JW;'~ . .'I,; "o' ():~J; ,:: "":,:) '~'":.: ';':; '..':,l' -';;:'~';::'. '/; !i~:~;d;L.. (: :~, .:. Contenido~Q1ixto.'El~elemenl.ti'i ispone.,de ;una.;~ombnaci6n :d~:sliblemen.,. d
;'J", ltos:y;.sn!propio contenido:de texto,,'AI cotrario queehmodelo DT:D1de.:.con.,. ..:"~:; "tenida' mixto;IXML Schema.requiere que'}a.-:secuen.cia, de.ele~tos:-y.:oqnte: 'J=: . nido itext0 .esre"oefinido:..-de,f<:.lrma. rgida; ;Y:'los documentoS!iVlidos',del:>e~ ~!l .....adecuarse_a la secuencia definida.r:E"ste~tipo de contenido:se .defme.:utilizan~ do un atributo,mi-xed enuni:elemento.compLe)lTYl,:.e:. 'l.':!: ~.:'. ::;;:'-".1 '::t';.;....~ Contenido vaco. El eleme~to solamente contiene atributos, pero no contenido de texto de su propiedad. XML Schema trala esto'come un caso .especial de contenido de slo elemento, sin elementos declarados. Cualquier contenido. El elemento contiene cualguier mezc,la de' ~~inido y subelementos, en cualquier orden. Este tipo de' conien1q:~~.~ef~n:, utilizando el tipo de datos de XML Schema anyType como el tip0:Qe.,datos.del elemento. ; ,. : ... ' , .. "-; . _r:- . '., .'
c:!~n:~~. d~,~strH.cHria. d( j.~t9.s,~~e;~~ ,tifmr~a!J B~.J!l/p'rppq~j~9(4,ifern~e~r.;E.n utia R~~q.?rg~~i~~f~9!"(~~.~~~4tI def!.n~r.,~~pr:~,s~pJac;g~~~ ..~~ el;aiiq~i.*.#da~.p'!i*. 9l.?:j~~'o~ p~ n'eg<?s~~q~~ri~~'~Y"b.siS(rs,.;. :t~es:',?mo u~:~ ~i,~~'.cb9h.:)ii(rqrr~fe: d~)f,b . dueto '0 'n nmero' o((ideltifleac'in d~' lI:>"s !Cli"e'nt~,( 3',f~~qgetlqf .Ij ~,~ ~l.rnage.ri cp.IP~n. ~~WRi~~ i~~f.~, ~~H:~}~~, .d.-~I~a9o.t}~~. ~!f~. ,?e:' ~l.\q~~Ysr-p~ra.~~;?:~\ll:'
~~ (~st!>~fS,l.9j(#;~t~.~ .~~l~~fjq~~~~.~ d.~fin~~.i?n~fp~Jip~:W.a~ 9-JO~: y...d~~l!ra~
t~~ :la~~,~ 90~;~ !.p.~.~}~~s: ..S:?l!~I~.u}Je~, .~t~. ;ac~!:o!1~s? .!pr~~qa5!9r. :~~. ~~tqn,~a~16n ;q7 ~~~~SnYe~:~i~s ~~.:idct~{~:~e d~~e[}~!! ,r,e~?g~~ ~,on}.uH.tarJP.~m~:~?:~~R?~ b,a~'t
!.,.",(.:.,.. ,.';;"I<.;,I '.'
.. J. ~~. ~s:~~~~ l?~~'~~r.,d.epI)4"',.un,~~p'p,.l~.~~~ ~e: ,eJ.~me?~p~i.9.lts:n9~~1~ent~ . se utilizan conjuntamente, y dar un nombre al grupo de elementos. Las declaraciones de elemento posteriores pueden entonces i~cluir todo ,~l.grupo..;con no~~r~ .d~. elementos como una .unidad. Los elementos agrupados tambi-n:proporcio.nah:flexibilidad adicional para la estructuta del elemento. El :grupo puede-especificar.: una -se-
c;~!+e. J9l~~~r.n~!1!~ J1~! ~n ??7l;l;~e~~~.I.),\!'4,~, 't.. I~~98!~J!l~W:? ,~~.,l.~ R':\?~. ,d~.',~.~t9~.' ;ql:l,~ p~e~H:~J~sm~~n~..r:::a~or~ ~I:-.It';~ d r-: ; :i:!',:,~,; .t "-,:r::~:';;; ~,. '_, 'J: '1: .;" L"; ':.;.'
Estos tipos de elementos bsicos pueden apafeceri.ndi~(hialfuerjte~;'l~s 'declaraciones de elementos en el esquema. Tambin se puede esi)ecifiqal:o-que.un elemento puede surgir varias veces en un documento y, opcionalmente,:especificar un mnimo y un mximo nmero de sucesos. XML 'Schern tainbi-el'admire"lo's':vlores NULL al estilo SQL para los vaJO'i'es\'1e los' ele'm'entos, parn'inl:tig~'qu~']-q'~ q:>ntenidos del elemento son desconocidos. La terminologa XML es vlof~ii, ~per ~J.S?p'c~p~~ f(~;r~,; IP:~Stnp. ;E,~t~ .papapf<dacl ,~,i.IPP~.i.fc:a. '\~' c9P'~~P'9P~F.n,c4 9.~: l~~i<!atos
c:q~ju~t~~l.!~ '. d~'~~~Ci9P~~;' (~~;I,~~.Cio~~:~. ~~f~~~q~o~~~,~,~;.alni~B~~~Ja~ ~~ un archIVO e t~~I).t,tfj,<r~l~~ l?.9r, s4,.nop1b~~. Uq}!?Ct;lmento,.~ :~c~~!11~ p~~a ~n nuevo tipo de actiirieto 'puede e:riionces obi-gner-si.is 'defiiCioiie~ y estructrasJ(J datos bsicas de uno o ms espacios de nombres haciendo referencia a los espacios de nombres en la cabecera del esquema. En realidade:,~k~9~~b'ylu{o )CM;L estndar y muchos' de' lbS tipos de datos'incorpora:dos estn definidos'--en un-esYacio..deJOombres mantenido .n el:.sitioiW-eb ,de,la!organizaciqn'W3C:' Un:U;RtL estiJo Internet~identifica-:el,6rigen .dd archi~0"p'ara:.,un:Spa0io:_de,nQlJ;rbres MLJ'::d '.1, .~ ~. .Si' la declaFacin-'de '!Un docuthento_XM1;lScb~maiincorpoci defioiciones: ,de ms de:unespado de nombIs~;lCxiste.uft;.;conflicto-otencial~.par,a':1os nOIDp bresl.'Fcilmente :se podra. haben'elegido eilmismo .nQmbreipor:;desarrollaaores':<ie dos .espaCios d-e nombres' diferentes- ptJ.fa apresentar",dos.estructuras, o .tipos 'de,qa-: tos XML.bastantetliferentes.Par~.e1iminar est:ambigedad.pb(enci.al. ~as,defini~ ciones de los tipos de datos y estructuras XML se.pueden especificar-utilizando nombres 'califitddosi lmediante'.una.tcnica.que se,aseineja estrechamente'all Uso de noinbres'de'columnaicalificadosen SQb 5e..puecl.elasignar uJ;l,1'1.ombre..di.pr.ejijoa cada:espacio-:de . nombres que se';iden-tific,a en i una:caocer.adel esquema" .elJcualse utfliza 'entbn\ces:para: .calificarrefenencias~ a- elementos :en \ese ',espaCi1de nom:bres~ Por facilita:r:la comprensin,.Jos qombres:de1tj"rfijo selhan:,omitido del0s-.ejemplo-s del 'esquema:en':esterc'aptulcu Veamos;una 'cabecera de;'esquema: ms:it:!pi~o~; un extracto de un cuefpo:.de:esque'ma.;qiIe'utili2a~ninbre~ de ,prefijo,!)'i';calificac.in para, reierenciilr el,espaco-de:nombres.oprincipal'de KML' SChetn4:_EllJantellid1 por W9Cr...y un 'espado de'nombres corporativo;:>: 1: .c; .,.:.~~~.):~.Ih :;',H~ g ~~lilJ:lr
J
..'" ,).,ps t?sl?~cio~'d~ !101J!~f,e.s.~adJ!liten, eS,tas ~ap~c;id~de.s. p~.fp1itie94o. rec;oge.r . ~.' e.c:. ,.. ,.(~!t".,,""'.,
910
911
<schema xmlns:xsd=-http://www.w3.org/2001/XMLSchema" xmlns:corp="http://www.miempresa.com/esquemas/compras > <complexType name="compraPedidoType">
Hoja de estilo XML
...aqu van otras declaraciones de elementos...

<element <element <elernent <element name-="fechaPedido type=xsd:date" 1> name="dirFactura" type="corp:tipoDirCliente" 1> name="dirEnvio type="corp:tipaDirCliente" 1> name="numReps type="corp:tipoListaRep nillable="true" />
Documento XML de entrada
." .continan otras declaraciones de elementos...

En este ejemplo, el espacio de nombres XML corporativo se identifica con el prefijo corp. y el espacio de nombres principal de XML Scherna, cor el prefijo xsd. Todas las referencias de tipos de datos estn calificadas por uno de estos prefijos y, como resultado, ya no son ambiguas. Puesto que las referencias calificadas se pueden volver bastante complejas, es tambin posible especificar espacios de nombres predeterminados que minimizan la necesidad de prefijos. El siste~ ma de nombres completo de XML Schema es bastante ms sofisticado que las capacidades mostradas aqu, pero las capacidades estn claramente dirigidas a in corporar la creacin de especificaciones de tipos de documentos muy complejos por grandes grupos de personas. Como con las DTD, el potencial de XML Schema reside en que permite especificar tipos de documentos bien definidos sobre los cuales se pueden validar instancias de documentos individuales. Todos los analizadores XML populares, si implementan las API SAX o DOM, proporcionan validacin basada en XML Schema. Se puede especificar el esquema al que un documento XML reclama conformidad dentro del propio documento, pero tambin se puede pedir a un analizador que valide un documento XML arbitrario con un esquema arbitrario.
~
---- -
-------Figura 25.8.
Documento XML de salida
Procesador XSLT
-----Transformacin de un documento XML con XSLT.
XML y consultas
SQL proporciona una potente y muy til estructura de consultas para encontrar, transformar y recuperar datos estructurados de las bases de datos relac,ionales, por lo que es natural buscar una capacidad de consulta similar para encontrar, transformar y recuperar datos estructurados de documentos XML. Los primeros esfuerzos para definir una capacidad de consulta y transfonnacin se enmarc en un par de especificaciones: eXtensible Stylesheet Language Transformation (XSLT) y XML Path lAnguage (XPath). Como XML, estas especificaciones tienen races en el procesamiento de documentos. XSLT se centra en transfonnar un documento XML, como el mostrado en la Figura 25.8. Una hoja de estilos gobierna la transformacin, seleccionando los elementos del documento XML entrante que se van a transfonnar y dictando cmo se van a modificar y combinar con otros elementos para producir el documento XML de salida. Un uso popular de XSLT es transfonnar una nica versin genrica de una pgina web en varios formularios que sean apropiados para representarlos en diferentes tamaos de pantalla y dispositivos de visualizacin. En el lenguaje XSLT, es frecuentemente necesario seleccionar elementos individuales o grupos de elementos a transformar, o navegar por la jerarqua de ele-
I ,
I
mentas para especificar datos a combinar desde los elementos padre e hijo. XPath surgi como una parte del lenguaje XSLT para seleccin y navegacin de elementos. Rpidamente se hizo patente que XPath era tambin til para otras aplicaciones y la especificacin se dividi de XSLT para tener la suya propia. En los primeros das de XML, XPath fue la capacidad de consultas de hecho para los documentos XML. Ms recientemente, la atencin de la industria se ha centrado en algunas de las deficiencias de XPath como un lenguaje de consultas completo. Se form en W3C un grupo de trabajo para especificar una fonna de consulta bajo el nombre de trabajo XML Query o XQuery. La especificacin pas varios borradores, y los grupos de trabajo XSL (responsable de XSLT y XPath) y XQuery juntaron sus fuerzas. A la bora de la escritura de este libro, XQuery 1.0 y XPath 2.0 estn en estado de borrador en proceso, y los dos lenguajes estn fuertemente vinculados, con sintaxis y semntica comn cuando es posible. Una descripcin completa de XQuery y XPath excedera el mbito de este libro. Debido a que XQuery 1.0 tiene solamente un estado de borrador en proceso, y no de recomendacin oficial, est todava sujeto a cambios en las revisiones de miembros del W3C. Sin embargo, un breve repaso de los conceptos de XQuery y unos pocos ejemplos ilustrarn la relacin con SQL, y es poco probable que estos fundamentos cambien cuando XQuery 1.0 se convierta en un estndar oficial.
Conceptos de XQuery
Si el modelo de datos subyacente al lenguaje SQL es la tabla fila/columna, el modelo de datos detrs de XQuery es la jerarqua estructurada en rbol de nodos que
,
i
912
SQL. MaHual ae, referencia
\
I
CaptuJo,25:-50[ ,y XML
913
represetan iidoCUITiio ){Me ){QueiY utiliza reaiitiiui's'i'i-Ciijrae rl)oi de grano ms fino que la jerarqua qe elementos de los documentos XML y XML Schema. Estos nodos XQuery son reievares paralas consultas al estilo de las bases de datos: Nodo elemento. Este tipo de nodo XQery representa un elemento. Nodo texto. Este tipo de nodo represi'-Ios contenidos del elemento, Es un hijo del nodo elemento correspondiente, ._. NdQ atributo. Este tipo de nodo representa un atributo y un valor deatritito para un elemento. Es un hijo del nodo elemento correspondiente.. '. Nodo documento. Es un nodo elemento especializado que representa l nivel sperior o ra(, de un documento. .~ .'.. ~-; Para nayegar~or un rbol de elementos e identificar uno O ms eleinentp~, P?ra su ..procesamiento, XQuery utiliza una expresin de rula. Una expresi6n~de ruta tiee la mIsr"'lunci6n en XQuery que una expresin de consulta SQL3,.. . descrita en el Captulo 24, tiene en SQL. Una expresin de ruta identifica un nodo individual en el tb-PLd.e_ ~J.em~J1ts.XQP~IY.~ e;sp.ecifica.Qdo upa..~eGyt;.I.lc!a. d.e P,s_o~.a travs de la jerarq!Jja de} __r.bol q.u~,son. necesarios para,llegar al nodo.4s .e2t.presiones de rutas XQuery son de dos tipos:
Tabla 25.2. Al gunas expresiones.de rutas .)(Query normales. . ."" _.. ' ,,:./ .",1"':
~.:\1}F-~i.q~ ~e.J'f.~ .~._
. j.
;r',i "
,~'"
Navegadon . , .'
'(. .
'
\.
seccin/prr
h'ib~o'parteic~pfti'c; .
':'.
,.
..
':i \. ~:~
~'..
Se mueve hariia abajo hast!n elemento hijo seccin, yhadaabaj desde all hasta-un elemento hijo prr. Comi'enza en la parte superior de I"a Jerarqua y se mueve'hacia abajo desde ;libro, despus' por el hijo parte, hasta .un hijo cap!'til,lo. ' Se mueve hacia arriba desde el nodo actual hasta su padre. Se mueve tiriCia arriba hasta el padre del nodo actual; despus hacia abajo hasta "un' nodo hijo captulo. ' .
S.ele~,ciona.c:u;llqui"ern(cxio.hiJqJP~r.r que
,l.:
'."
.. /captulo
: I~.' . .,. ,j'.
~';F
~.
~."
'.'.
~',.>.
:-
..
";,,
('. '',:'
. /Ipr'r
,1 .. 1 " ..
",,'i
!'..:;
. '.1.
aparece'en cualquier pane"por'debajo del rioi:io'eil 'cursO erj")a }erarga. ,'P' 'J' ;
!!.
@n~velCal:?,
,.~.
,,!' , " .. (; :,. :".

j
';::
"
..
...I'~rte"sUl'eqOr (la r'!z)..<!el, rQoL de elemenf9.sy .l?aja. por . . . la jerarqa para '! - . , ' , ' '. .. ., . . . . l ... ."_ . .', . . . , ' ' . . , ".. oI alcanzar ',,' e!.oodo obJellv.o. En etoocumento horo.de ' lal ... ' .' . . ' ...... expreFIgura 25.1 la : ., . : " _, .' '_'l. . ', . , ; '..' :'1,.'".;. 'J .SIO ,de ruta.con raz !parteLibor!cap tulo! s,eccin/prr.navega por 'npfu3foindividual'erl" uri secci'n de ri;~aptulo. , .....'. , " . ~~pr_~in de ruta rela~v,~. q~~ e~pr~si6n c;le ruta r~lativa"c:omie~a.~' el ,. nodo en curso del rbol dei~lementos (el nodo d~nde est. actuah;nente enfo cado el procesamiento)j sp'be y/o baja. por lajerllj"qua pra alcanzar el no~o ,objetivo. En el documento libio de l Figura f5.I,la.expresi6n de ruta relativa seccin!prr navega por un prrafo especfico si el nodo actual es un ,',;: nodo captulo. . . '
'~"_
.j . . _ ..
11. ~XP!~~~~4~~~jr~i~
~o~ ~~z:'PEI~ ~~~e~i~,~_~~i~i~,c<?n iaz;~~mr~'ri~~,:en ~a
-: .. ::.
..'.
Selecciona el atributo niyelCab del nodo actual. -" ..:;.".
/cabecera~nivelcab
,,
'Selecciona el atributo ni veiCab de un nodo cabeceralhijo... Selecciona el tercer elemento hijo con un tipOP"rr. ,. Selecciona tc;>d9S los hijos. del nodo actual. Selecciona todos los nietos prr del nodo ".' actual. ';'.' .Selecciona todos los hijos cap tulo del nodo actual que tienen'un estado de revisin con valor bon:ador.
prr {3]
'. l'."'
*/prr
captulo[@estadoRev=-borrador-j
. Los pasos en una ruta pu~den especificar el movimiento haia ab~JO en el rbol de nodos hacia los nouos hijos que repres~ntan subelem~ntos, c,ontynidos. de elemento~ p atri~P!o,~ .~~ eleme,nt9s}:,O.~, pa~os t.am~in pu~gen esp~?~ficar u~ t:J1oXi~~nt9 h~cia arri~fl al ,nodo padre... pon. c,ada P~s9 se puCfle especifisar un. test .de no.do.~ por el qu~ Sy debe pasCl! p~~, c... ,ntipl!~ l~ ..ruta ,~ayia_ el elyrne~to objetivo. o La Taqla 25;2 muestr,a algunas' e~pfeslOries de r,uta, tpicas y his rutas de navegacin qu'e especifican.' , . . , -. , . . . , . , ..
..
Como SQL, XQuery es un l'enguaje orientado '"conjuntos. Est optimizado para trabajar sobre una secuencia XQuery, una colecci6n ordenada de cero o ms elementos. Los elementos mismos podran ser elementos, 'atributos o valores de datos. Las operaciones XQuery tienden a tomar secuencias como entrada y producir 'secuencias como s'al.ida. Un nico' elemento de datos atmico se trata normalmenle i com'o's1 flier-unaseCi.incia de un elemento: .! ".;
XQuery tambin recuerda a SQL, al ser un lenguaje con tipos fuertes. El documento de trabajo de la especificacin XQuery est evolucionando para alinear los tipos de d~tos XQuery- con los especificados en XML Schema, que se describieron antenornlente en este captulo enla seccinXML Schema. Como SQL3, XQuery proporciona constructores para co.nstruir valores de datos ms complejos. XQuery difiere sustancialmente de SQL, al ser un lenguaje orientado a expresiones en lugar de ser un lenguaje orientado a frases. Todo en XQuery es una expresin que se evala para producir un valor. Las expresiones de ruta son un tipo de expresin XQuery y producen una secuencia de nodos corno resultado. Otras expresiones pueden combinar valores literales, llamadas a funciones, expresiones aritmticas y booleanas y las combinaciones, encerradas nonnalmente entre pa-
9'14
915
rntesis de stas, para formar expresiones arbitrariamente complejas. Las expresiones tambin pueden combinar secuencias de nodos, utilizando operaciones de conjunto, como la unin o interseccin de conjuntos, que coinciden con las operaciones de conjunto SQL correspondientes. Las variables con nombre en XQuery se denotan por un signo de dlar ($) delante de los nombres. Por ejemplo, $numPedido, $oficinaActual y $e seran nombres de variables XQuery vlidos. Las variables se pueden utilizar libremente en expresiones para combinar sus variables con literales y otros valores de valores y valores de nodo. Las variables reciben nuevos valores mediante llamadas a funciones y mediante la asignacin en expresiones for o let.
Obtiene el tercer prrafo del segundo captulo de la parte 2.

/libro/parte[2]/captulo[2]/prr[3]
Procesamiento de consultas en XQuery

Las expresiones de ruta XQuery pueden proporcionar el equivalente XML de la sencilla instruccin SQL SELECT con una clusula WHERE. Consideramos que una coleccin de documentos XML contiene el equivalente XML de los contenidos de la base de datos de ejemplo, con los documentos de nivel superior con los nombres de las tablas en la base de datos de ejemplo y las estructuras de filas individuales con nombre de los equivalentes propios de dichos nombres (por ejemplo, el documento OFICINAS contiene elementos individuales OFICINA para representar las filas de la tabla OFICINAS, etc.). Veamos algunas solicitudes de consulta y sus correspondientes expresiones de ruta:
Estas expresiones no proporcionan el mismo control sobre los resultados de la consulta que la lista SELECT proporciona en las consultas SQL. Tampoco proporcionan el equivalente de los cursores SQL para el procesamiento por filas. XQuery proporciona ambas capacidades mediante las expresiones ForlLet/WherelReturns (expresiones FLWR, pronunciadas en ingls flower n- flor-). Un ejemplo es la mejor forma de ilustrar la capacidad. Una vez de nuevo asumamos un conjunto de documentos XML estructurados para reproducir la base de datos de ejemplo, como en los ejemplos anteriores. Esta consulta implementa una reunin de dos tablas y genera tres columnas especficas de resultados de la consulta:
Listar el nombre de los representantes, fecha de pedido y cantidad de todos los pedidos inferiores a 5.000 , ordenados por cantidad.
<pedidosPequeos> { for $0 in document("pedidos.xml")/Ipedido[importe < 5000.001. $r in document(-representantes xml-l/lrepresentantes[num_empl :$p/pedido/rep) return <pedido Pequeo> { Sr/nombre, $p/fecha-pedido, $p/importe
}
Identificar las oficinas dirigidas por el empleado nmero 108.

/oficinas/oficina[jef:l08l
</pedidoPequeo> sortby (importe)

}
Hallar todas las oficinas con ventas por encima del objetivo.
loficinas/oficinalventas > objetivo)
</pedidosPequeos>
Buscar todos los pedidos del fabricante ACI con- cantidades superiores a 30.000 f.
Ipedidos/pedido[fab : 'ACI' and importe> 35000.00)
Puesto que la base de datos de ejemplo tiene una estructura plana de filas y columnas,lajerarqua XML tiene solamente tres niveles de profundidad. Para ilustrar las posibilidades de consulta en documentos XML ms jerrquicos, consideremos una vez ms el documento libro de la Figura 25.1. Veamos algunas solicitudes de consulta y sus correspondientes expresiones de ruta:
Hallar todos los componentes de captulos que tienen el estado borrador.

/libro/parte/capitulo[estadoRev:'borrador'J/*
En el nivel superior, los contenidos del elemento pedidos pequeos estn especificados por la expresin XQuery encerrada entre las llaves ms exteriores. La expresin for utiliza dos variables para reiterar por los dos documentos, variables correspondientes a las tablas PEDIDOS y REPRESENTANTES. Estas dos variables implementan efectivamente una reunin entre las dos tablas (documentos). Los predicados que al final de cada lnea siguen la palabra clave for se corresponden con la clusula WHERE de SQL. El predicado en la primera lnea restringe la consulta a los pedidos con cantidades superiores a 5.000 . El predicado en la segunda fila implementa la reunin, utilizando la variable $p para vincular filas en la tabla (documento) REPRESENTANTES con las fijas en la tabla (documento) PEDIDOS. La parte return de la expresin for especifica qu elementos se deberan devolver como los resultados de la evaluacin de la expresin. Corresponde a la lista de seleccin en una consulta SQL. El valor devuelto ser una secuencia XML de elementos pedidopequefio y cada elemento viene de un elemento correspondiente en las tablas origen (documentos). De nuevo, las variables de iteracin se utilizan para calificar la ruta especfica hasta el elemento cuyos contenidos se van
_______ J
916
917
a devolver. Finalmente, la parte "sortby de la expresin funcjonacde-Ia"misma:for Ola que la clusula correspondiente ORDER BY de una consulta SQL.
Hay unas pocas capacidades de procesamiento de consulLas adicionales no .ilustradas en este ejemplo_ Se puede utilizar la expresin let en la iteracin for para capturar valores de variables adicionales en elbucle for .que ,se pued:en n.ecesitar en predicados u otras expresiones. !:~ "-:1 ' , : ; '" Una expresin if._then... else admite la ejecucin condicionaL L~~Ju;naiones de agregacin admiten consultasXQuery agrupadas, que s~ Gor.r.etiPQnden con,.l~s c;onsultas de resllmen,SQL desj:ritas en el Captulo 8. Con:e.~t~sj::apacid~des .. la flexibilidad de XQuery es comparable con la de as expresiones.de cons~lta SQL. Sin embargo, como se puede v~r:en el ejemplo, el estilo de laexpr~sio. de. ~onsul, la es bastante diferente, y .refleja.-la orientacin de la expresin" y Inn;m.y fuerte orientacin de navegacin. de 10& documentos XQuery y XML."~T':'. .
.
vos modelos de dalOs en un paso que es lo suficientemente rpido para mantener sus cuotas de mercado. Parece muy probable que las bases de datos relacionales mantengan el tipo de base de datos nativa dominante para las aplicaciones de procesamiento de datos. Pero en estos productos la integracin XML crecer ms estrechamente a lo largo del tiempo y los productos relacionales ofrecern ms y ms caractersticas orientadas a XML
Resumen
Este captulo ha descrito las relaciones entre XML y SQL y entre los documentos XML y las bases de datos relacionales procesados por cada lenguaje: XML tiene sus orgenes en la imprenta y publicacin; se dise originalmente como una forma de indicar y especificar los contenidos de los documentos, La orientacin a los documentos de XML produce una vista jerrquica natural de los datos. El desajuste entre las jerarquas XML y las tablas con filas y columnas de SQL es uno de los retos mayores cuando se integran las dos tecnologas. Los documentos XML estn formados por una jerarqua de elementos. Los elementos pueden llevar contenidos, pueden tener atributos con nombre y pueden tener otros elementos como hijos. La integracin XML con bases de datos relacionales puede adoptar diversas formas, incluyendo salida de consultas XML, entrada XML, intercambio de datos XML y el almacenamiento y recuperacin de datos XML en la base de datos. XML Schema y el estndar anterior XML DTD definen estructuras rgidas para especificar tipos de documentos. Son tiles para restringir los contenidos de los documentos a una forma estndar aceptable para las aplicaciones de procesamiento de datos. XQuery es un lenguaje de consultas emergente para documentos XML Tiene algunos paralelismos con SQL; su enfoque a expresiones y navegacin de rutas lo hace bastante diferente al estilo SQL. Se han introducido bases de datos XML nativas y se estn cambiando para adoptar XQuery como un lenguaje de consultas nativo. Son un desafo al modelo relacional, pero los principales fabricantes de SGBD se estn moviendo rpidamente para proporcionar extensiones XML a sus productos relacionales.
Bases de datos XML
.. '"-'-
Con la proliferacin del uso de XML y documentos XML varias campa.Mas arric;sgarlas se han estado formando para comercializar bases de dai'os XMC -nativas. Normalmente, estas bases de datos almacenan y modelan sus datos .como documentos XML. Los contenidos reales de la 'base de datos se pueden almacenar en una forma nativa como texto XML o en alguna forma analizada, corno la mantenida por un analizador DOM XML. La mayora de los productos de ba~es ,4e datos XML admiten XPath como capacidad principal de consulta, y mu,hosde ellos han agregado extensiones propietarias a XPath para hacerlo un lenguaj-e. de consultas ms completo. Normalmente prometen soporte para XQuery como reemplazo para XPath o como un segundo lenguaje de consulta complementari, 'ta'n'pronto" como se finalice la especificacin XQuery. . ., Los fabricantes de bases de datos XML nativas tienden a ~tener .los. mismos argumentos a favor de sus productos que los fabricantes de las bases de datos orientadas a objetos hacan una dcad,antes. Con -datos. externos represenlfido's de .forma creciente como XML, la mejor coin'cidencia es una'bas'e'de datosque.lleva--el mismo modelo.de -datos subyacente. La. eleccin de ;documento5- XML 'como ;l.rn formato nativo reduce la sobrecarga de resolucin y clculo de' referencias 'XML, pero proporciona el mismo nivel de acceso'y navegaei-en .por elementos y 'atributos individuales. Finalmente., argu'mentan que. con un-a cantidad creciente de usuarios entrenads~en -HTML y XML, na' basede' datos' XML 'puede ser. accesible a ms gente:que flas baSes de datos relaionales basadas en' SQL ;.; '. :~. --:':':., L..as bases de datos XML nativas son relativamente nuevas"enl el mercado a la hora de la escritura de este libro, yes demasiado pronto para juzgar suxito.e impacto finales en el mercado. Parece probable que una base de datos XML nativa pueda ser una buena decisici6n para las necesidades de gestin de'datos:en;un,sitio web basado en XML para almacenar, act:eder'y transfor.mar'doci.neTitos,XMI::: S-in embargo, la historia previa de bases de datos orientadas a objetos<])uras,sugiere que los fabricantes de bases-de datos relacionales 'Son capaces deampliatsus productos princi'pales para incorporar- las caractersticas ms importantes' de-'riue':
CAPTULO
26
El futuro de SOL
SQL y las bases de datos relacionales basadas en SQL son una de las tecnologas ms importantes del mercado informtico actual. Desde su primera implementacin comercial hace unas dos dcadas SQL, se ha ido desarrollando hasta llegar a convertirse en el lenguaje de bases de dalos e.stndar. En esta primera dcada, el apoyo de IBM, la aprobacin de los estndares, y el soporte entusiasta de fabricantes de SGBD hicieron de SQL un estndar dominante para la gestin de datos empresarial. En su segunda dcada, el dominio de SQL se ampli a entornos de com-
putadoras personales y grupos de trabajo y a nuevos segmentos de mercado usuarios

de las bases de datos, tales como los almacenes de datos. En la primera parte de su tercera dcada, SQL es la tecnologa de base de datos estndar para la informtica basada en Internet. La evidencia del mercado muestra claramente la importancia de SQL: La segunda mayor compaa de softwa.re del mundo, Oracle, se ha construido sobre el xito de la gestin de datos relacionales basada en SQL, mediante sus servidores bandera y herramientas de bases de datos y sus aplicaciones empresariales basadas en SQL. rEM, la mayor compaa de computadoras del mundo ofrece su lnea de productos DB2 basada en SQL como base de todas sus lneas de producto, as como para ser utilizada en los sistemas de los competidores, y ha expandido su compromiso con SQL con la adquisicin del SGBD de Inforrnix basado en SQL. Microsoft, la mayor compaa de software del mundo, utiliza SQL Server como la parte fundamental de su estrategia para penetrar en el mercado de informtica empresarial, con ediciones para servidor de sus sistemas operativos Windows y como una parte clave de su arquitectura .NET para repartir servicios Web Internet. Toda compaa significativa de bases de datos ofrece un producto de bases de datos relacionales basado en SQL o acceso basado en SQL a sus productos no relacionales.
919
920
Capftulo 26: El futuro 'de SOL
921
~.-' Td~.:'las principales aplicaciones empresariales empaquetadas (Ellterprise ,-;:. . ..Re.source Planning [ERP], Supply Chain Managemem (S CM], Human Re 'source ManagementJHRMJ, Sales Force Automatioll (SFAJ. CuslOmer RelaJld1../}hip MaiJag-el1iellf. rCRM] y Qtras) ~stn construidas sobre bases._ de,datos basadas en SQL. . }!I! SQL est emergiendo como un estn9"[ para bases de datos especializadas -:. ~_ ~eD.:..aplicaciones quevap de.~deal~ceties"'ae datos, bases de datos de ponti. '10 'ls~a' aplic'ci6neS:' iIlcofporida-s--en' reCtes de telecomunicaciones y comunicaciones de datos. El acceso basado en SQL a las bases de datos es una caracterstica integral de Windows. disponible en la gran mayora de sistemas de computadoras personales, y es una capacidad incorporada de productos software pe populares corno hojas de clculo y generadores de infonnes. El acceso basado en SQL a las bases de datos es una parte estndar de los servidores de aplicaciones para Internet, requerida por la especificacin 12EE.
Este captulo describe algonas de las tendencias actuales y desarrollos ms importantes en el mercado de bases de datos, as como'los proyectos de las principales fuerzas que actuarn.sobre.la gesn de SQL ~ las bases,de datos en .los prximosaos.
'"
Tendencias'del mercado de bases' de datos

El'mercado actual'para l.os productos de gestin' de base's de' datos excede'los 12:000 millones de dlares al ao en beneficios de productos Y. servicios, -mientras'que hace una dcada era de alrededor de 5.000 millones --de 'dlares l ao. En varia's O"csiones, en la' dcada pasada, el mehor crecimibnto';anual en los' beneficios c"tici~ trimestrales de los principales fabricantes de bases de datos llev a los analis(alf a hablar sobre un mercado de bases de datos maduro. Paulatinamente, una ola de nuevos productos o -nuevas' aplicaCiones de gestn de diuo's 'ha producido 'n el mercado un 'crecimiento de dos cifras. La' arquitectura 'Cli~rite/servidor, -las 'aplicaciones ERP, los almacenes de datos' y el anlisis 'del negcio, I's arquitecturas de sitios Web .en tres capas han estimul~do una' nueva 'Ola' de tecnologa de b.~ses de datos' y una nueva ola de implantaciones'de'bases de datos basadas en'SQL Si la historia de las' dos ltimas dtada~ sp'ne\.in indiio; h(tecnologa. eri-bases de datos seguir encontrando nuevas aplicaciones' y generando myores'berieficios en "los aos venidros. Las tendencias que dan forma al mercado son el pJ;"e$agio de un buen est.ado de salud y apuntan a una tensin continua entre la madurz:del mercado y la consolidacin, 'por una parte, -y a nue,:as"y excitantes capacidades' de las bases de datos y' aplicaciones, por otra. . .
Madurez del mercado de las bases de datos empresariales . . .

La tecnologa.d~ las bases de' datos relacionales se ha aceptado'como una tecnologa de procesamiento de datos empresarial principal, y ls "b'ases-d.e datos rela-
cionales se han implantado en.casi-'todas las grandes,corpo~.aciones,~.ebjdo\a~la importancia de las bases de datos corporativas y los aos de experiencia en el uso de Ia teenologa relacionl; muchas. si. no la mayor-a. de I'as .grandes corporaciones, han seleccionado una.nica marca de. SGBD como un e.slndar de-bases de datos empresarial. Una vez. que'dicho:estndar se ha establecido e.implant3do ampliamente en. una compaa, hay una gran. resistencia a cambiar de .marca. Incluso' si un' producto SGBD alternativo puede ofrecer: ventajas para una aplicacin particular o. puede representar una nueva y til caracterstica, .un. anuncio del fabricante estndar de que .esas mismas caracterslicas estn previstas para una versin futura tender a.evitar la prdid-a.,del cliente del.fabricante estndar. H . , . La tendencia de los estndares de bases de datos corporati.vos.ha.sido lade reforzar y endurecer las posiciones del mercado de los p'rincipal~s .fabricantes de SGBD establecidos. La existencia de grandes fuerzas de ventas. relaciones establecidas con los clientes y acuerdos de ventas de gran volumen para varios aos se ha hecho tan importante, si" no ms importante..queJa. ventaja tecnolgica. Con esta dinmica del mercado los jugadores muy establecidos lienden a concentrarse en hacer crecer sus negocios con .sus ,bases existe.mes instaladas, en lugar de intentar robar clientes a los. competidores. En la ltima parte de los aos noventa, los analistas de la industria vieron y predijeron esta tendencia en Informix y Sybase. Oracle,con una cuota de. mercado mucho mayor,.fueJoezada a competir de forma agresiva por nuevas cuentas en su intento de'.mantener su crecimiento de 'beneficios con las licencias. de bases de datos. Microsoft, con -su habitual insolencia en 'el'mercado .de las bases de datos empresariales, adopt un -papel desafiante, intentando mejorar su posicin en las bases de datos de grupos de .trabajo hada prototipos' y -proyectos pilotos de nivel empresa'tial, comq.forma de entrometerse en los negocios empresariales de los jugadores establecidos. El desafo de los estndares de bases de datos corporativas ha tendido a reforzar y consolidar las posiciones en el mercado de los principales fabricantes de SGBD establecidos. Nuevos fabricantes .de bases de. datos tienden a liderarnuevas tecnologas de bases de datos, y crecen vendindoselas a nuevos clientes. Estos nuevos clientes han ayudado a formar la tecnologa ya identificar las reas de solucin donde se pueden conseguir beneficios reales. Despus de unos pocos aos, cuando se han demostrado las ventajas. de la nueva tecnologa, los nuevos fabricantes son fagocitados por grandes jugadores establecidos. Estos fabricantes pueden traer la nueva tecnologa en su base instalada, y utilizan su fuerza en el mercado y sus ventas para imponerse asus competidores. Los primeros aos de la dcada de los noventa asistieron a este panorama de adquisiciones de fabricantes de bases de datos. En los ,ltimos aos de esa dcada se aplic el mismo modelo a fusiones y adquisiciones de fabricantes de SGBD. La adquisicin de Illustra por parte de lnformix (un fabricante relacional orientado a objetos pio nero), Red Brick (un fabricante pionero de almacenes de datos) y Cloudscape (un fabricante pionero de bases de datos Java puras) son tres ejemplos. Solamente unos pocos aos despus 1nformix fue adquirida por 1BM, continuando esta particular cadena de consolidacin." . ' ..
922
Captulo 26: El futuro de SOL
923
Diversidad y segmentacin del mercado

A pesar de la madurez de algunas parles del mercado de bases de datos (especialmente el mercado para sistemas de bases de datos empresariales), se continan desarrollando nuevos segmentos y aparecen nichos que crecen rpidamente. En gran parte de la pasada dcada, el modo ms til de segmentar el mercado de bases de datos ha estado basado en el tamao y escala de la base de datos (haba bases de datos para pe, bases de datos pa~ minicomputadoras, bases de datos para grandes sistemas y, posteriormente, bases de datos para grupos de trabajo). El mercado de las bases de datos actual es mucho ms diverso y est ms adecuadamente segmentado, segn la aplicacin objetivo y las capacidades de la base de datos especializada para solucionar requisitos nicos de la aplicacin. Entre los segmentos de mercado que han aparecido y han experimentado mayor crecimiento, estn: Bases de datos para almacenes de datos, centradas en la gestin de miles de gigabytes de datos, como los datos histricos de las ventas. Bases de datos de procesamiento analtico en conexin (OLAP, online analytic . processing) y bases de datos relacionales de procesamiento analtico en conexin (ROLAP, relational online analytic processing) orientadas a realizar complejos anlisis de los datos para descubrir tendencias subyacentes (minera de datos), permitiendo a las organizaciones adoptar mejores decisiones sobre el negocio. Bases de datos mviles, para soporte de trabajadores mviles tales como representantes, personal de soporte, gente en el campo de servicios, consultores y profesionales mviles. Frecuentemente, estas bases de datos mviles estn enlazadas a una base de datos centralizada para su sincronizacin. Bases de datos incorporadas, que son una parte integral y transparente de una aplicacin vendida por un fabricante de software independiente o un intermediario. Estas bases de datos estn caracterizadas por pequeas huellas y una administracin muy sencilla. Microbases de datos, diseadas para dispositivos de aplicacin tales como tarjetas inteligentes, computadoras en red, telfonos inteligentes y PC de mano y organizadores. Bases de datos residentes en memoria principal, diseadas para aplicaciones OLTP de rendimiento ultra-alto, como las incorporadas en telecomunicaciones y redes de comunicaciones de datos, utilizadas para admitir interaccin del cliente en aplicaciones de Internet de muy alto volumen. Bases de datos agrupadas, diseadas para aprovechar los potentes servidores de bajo coste utilizados en paralelo para realizar tareas de gestin de la base de datos con alta escalabilidad y fiabilidad.
de la compaa. Las decisiones sobre la tecnologa de la base de datos y la estandarizacin del fabricante era parte de la funcin de planificacin de la arquitectura IS de la compaa. Las compaas agresivas se arriesgaron con nuevas tecnologas de bases de datos relativamente poco probadas, en la creencia de que podran ganar ventajas competitivas utilizndolas. El crecimiento de Sybase en el sector de servicios financieros durante los ltimos aos ochenta y principios de los noventa es un ejemplo. En la actualidad la mayora de corporaciones han pasado de la estrategia de hacer aplicaciones a la de comprar aplicaciones de las principales empresas. Algunos ejemplos son las aplicaciones ERP, S.CM, HRM, SFA, CRM, etc. Todas estas reas estn ahora suministradas por aplicaciones empaquetadas em. presariales junto con servicios de consultora y personalizacin proporcionados por grupos de fabricantes de software. Algunos de estos fabricantes han alcanzado beneficios de muchos cientos de millones de dlares. Todos estos paquetes estn construidos tomando como referencia las bases de datos relacionales basadas en SQL. La irrupcin de aplicaciones empresariales dominantes ha tenido un efecto significativo en la dinmica del mercado de bases de datos. Los fabricantes del principal paquete de software empresarial han tendido a admitir productos SGBD de solamente dos o tres de los principales fabricantes de SGBD. Por ejemplo, si un cliente elige implantar SAP como su aplicacin ERP empresarial, las bases de datos subyacentes se restringen a aquellas admitidas por los paquetes SAPo Esto ha tendido a reforzar la posicin dominante de los jugadores del segmento superior de bases de datos empresariales, y dificulta la accin de los nuevos fabricantes de bases de datos. Tambin ha tendido a disminuir los precios promedios de las bases de datos, puesto que el SGBD se ve ms como una parte de una decisin guiada por la aplicacin que como I;lmi decisin estratgica en s misma. La irrupcin de software empresarial empaquetado tambin ha movido el po_ der relativo de las organizaciones IS corporativas y los fabricantes de software empaquetado. Los fabricantes de SGBD tienen actualmente equipos de desarrollo de marketing y negocio enfocados en las principales aplicaciones empresariales para asegurar que las ltimas versiones de las aplicaciones admiten sus SORD, y para incorporar el ajuste de rendimiento y otras actividades. El principal fabricante SGBD independiente, Oracle Corporation, est realizando ambas funciones, proporcionando software SGBD y aplicaciones empresariales principales (que se ejecutan en el SGBD Oracle, por supuesto). El enfoque de un nico fabricante de Oracle ha producido una considerable tensin entre OracIe y los mayores fabricantes de aplicaciones empresariales, especialmente en el campo de sus organizaciones de ventas. Algunos analistas industriales atribuyen el crecimiento de la cuota de mercado de los SGBD de IBM y Microsoft a una tendencia de los fabricantes de aplicaciones empresariales a evitar los productos SGBD de Orade.
Aplicaciones empresariales empaquetadas

Hace una o do~ dcadas la gran mayora de aplicaciones corporativas fueron desarrolladas en la propia corporacin por el departamento de sistemas de informacin
Ganancias de rendimiento del hardware

Una de las contribuciones ms importantes al ascenso de SQL ha sido un dramtico incremento en el rendimiento de las bases de datos relacionales. Parte de este
924
SOL. Manual de referencia_.'
CaptlJ/o'26: EHuturo."de SQL
925
aumento en.el.rendimicntb iue.de1;?ida a;}os~avances en.la tecnologa. de-bases de datos' y optimizacin-de consultas. Sin embargo. la mayor parte'de~la' mejora:enel rendimiento de 'los SOBD 'vino de las gananc;ias en hl potencia d procesamiento de los sistemas.informticos subyacentes, ycambi6 en-e1.software:SGBD diseado para capitalizar dichas ganancias: :Mientras que "elrendimiento d~~ los gr~ndes sistemas ,aument6 de. forma 'sostenida,' las pr.incipales' gananCias 'en e-l rendimiento han.sido en los mercados de.ser-v.idores:basados en UN~ J ,enWindows, donde la potencia.de pfOcesamiento.ha ido;aumentando .eLdoble:() "ms, 'ao tras :ao. ';-:. . Algunos de'los avancesmsdramticos 'en el rendimiento;de Jos .servidotes vienedel crecimiento de los sistemas de: multiprocesamiento 'simtrico (SMP, SY11'i metric Multiprocessing); donde dos, cuatro, .ocho oincluso docenas"de procesadores operan en paralelo, companiendo la.carga de trabajo del' procesamiento. Una arquitectur'};multiprocesad"r se puede utilizar 'en aplicaciones OLTP, donde la car.,. ga ,de' trabajo consiste en muchas 'transacciones .de. bases de:.datos pequeas,";en paralelo. Los fabricantes OLTP tradicionales, como Tandem, siempre han .utilizado una arquiteccura.multiprocesador, y los. mayores.sistemas han utilizado diseos multiprocesador durante. ms de una dcada. En IOs ..aos noventa, los:sistem.as ffiullijirocesador. se, convirtieron -en una parte' principal delmer.cada de 'serv,idores basados en UNIX~;y"al'go despus~'en un factor:imprtnte'en el..-:mereado de los servidores PCdealtas1JrStaCioiles:~~::... ,,: f: i .\,., "'. " . .':~' ,: Con la introduccin 'de.placasmultiproc~sador; los 'sistemas SMP.;onmultiprocesamien~o' de.dos y cuaJro vas consiguieron su ,introduccin; en.el.meccado d los ser:vilores LAN, y..estu.vierori disponibles 'por menos de 10.000' dlares.,En el rango' medio del mercado de servidores basados en UNIX, los servidores de 'bases de datos.de Sun,Hewlett-Packard e.IB-M tienen de forma' habtuaI.8,,0.16 procesadores !j' se venden i~n_ un-precio' de cientos de miles. de, dlares. .Los:. servijiores UNIX nis:potentes::.actuaJmente se':pueden configurar...con ms. de lOO.procesadores y.decerlas de.gigabYtes len. la memoria principal. Estos istemas,: que ,rivalizan con"la potecia,;de ,computain de 'Jos .grandes sistemas tradicionales!'p'reserrtan ! '. 'r;' ';:',11 ; ,;' ......:; ~1, ,~. precios 'multimillonarios: <:; Los sistemas.SMP:tambin ,proporcionaron benefiCios en' el rendimiento',en aplicaciones ,de yuda,.a 'l toma..de,de.cisi"Onesy. anlisis de dtos. Al ser ms' comunes.los setvidores. SMP,- Jos fabricanteli'de SGBD invirtierop.-en: versiones.en paralelo ,de. sus 'sistemas.que"estaban ;disporiibles para; tomar el trabajo de una ~ni ca consulta SQlJ-;compleja_ydividirla en varias rutas deiejediIein en paralelo. Cuando un$GBD.cQIl-capacidades de consulta en paralelo. se instala enun sistema SMP de,cl,latro u .chQ vas,.una consulta.qq.e podra suponer dos horas en 'un 'sistema 'de .un.nicoproCesador, se'puede completar en merlos,de una.hbra.'Las 'coinpaas estn .aprovechandoestamejora en el rendiritiento'basada en 'eJ,baidware; de dos fonnas: obteniendo Tesulta"dos de. anlisis del negocio y.llevando'a cabo'anlisis ms complejos y sofisticados. Los sistemas operativos que admiten nuevas caractersticas de hardware (tales como las arquitecturas multiptoces'adorrhan:retrasado amenudo:la disponibilidad de las capacidades hardware (frecuentemente. durante varios cuatrimestres, o incluso durante a.os); Esto:ha creadoun dilema.especial'para los-fabricantes de'SGBD que neces'irn de'cidii:sf 'saltarse el sistema,'ope'rativo eil;un 'intent~ .den1ejot~r 'el
rendimiento dejas bases de datos. EISGBD Sybase; por ejemplo{ plando se~intr) dujo originalmente.operaba como un nico proceso y asuma.Ja:responsabilidadlde su. propia gestin de. tareas, gesti6n de eventosy. entrada/salida (funciones que Dor.,. malmente:son gestionadas porun:sisterna operatiyo tal como.UNIX o VMS).-:A corto plazo, esto dio .a.Sybase una ;ventaja de rendimiento significativo sbre~los:produc tos SGBD'rivales,:con menOr~Caflacidad de,procesamiento.en paralelo.:: ,T: ,Sin embargo, cuando lleg el soporte SMP a Jos sistemas operativos, muchos de sus beneficios:estuvieron disponibles'de forma automtica_para 'los 'sistemas Fivales;'que se' apoyaron ,en .el' sistema operativo:p.ar.a incorporatfla tarea de la ges" lin, ,mientras:quei Syoase tena la ~sabrecarga.contjnuada de extender: y,.mejorar :su softWare de bajo nivel orientado a la mejora de rendiffiiento~ Este ciclo'ha,esperado diseos SMP,'y .Jos,principales.fabricantes de bases de datos confan.ahora en los,sistemaS operativos'para e}:soporte de hilos'y escalado 8MP.. Pero:an,existen los mismos: compromisos' en las nuevas caractersticas ,hardware. por aparecer, y~:se requieren deei6iones,estratgicas explcitas 'por, parte de los fabricantes de.SOBD. ... ,~ Actualmente,'la. bsqueda de cada -vez mayorrendirniento 'en las bases de datos no, muestra signs de detenerse: Con Jos servidbre,s..,de"mayor rendimiento 'actuales,. que utilizan .cientos.de procesadores"de muchos;gigaherzios; ;los:,ayances en~el hardware han solucionado la mayor sobrecarga del modelo de datos relacionl, haciendo que el rendimiento sea igual, o mejor, que las mejores bases de datos no relacionales del pasado. Al mismo tiempo, por supuesto, contina creciendo la demanda de cada vez mayores tasas transaccionales -en c~da~ez mayres;'J)apes:.de datos. En la parte superior del mercado de bases de datos, parece que nunca se -..:. ., tiene demasiado. r:endimiento de 'la base 'de:datos!'
':,'",
.~,
; ,; ",'.:. ", ",.

.>-.
~,',
,,;,
.,
. ~" . ." ..'" l' . '"
,.-.""
"
'.;',.;'."
Hardware para servidor.es de.bases.de -datos

,._ ...... ''':'':,.:':.;
"Jd' ,;;\0 ..... ;;: ',' '::,:! .:.;
:..' ,)
,0;'.
Oti1Undenciarll :mercado..basada'en eLhar;dware, 'en :Ios:,aos;ochenta i princL7 pios.delos aos noventa, _fue. la' irropci'6n de tcompaias '-que combinaban:,micro=. proeesadores.de'alto -rendimiento; unidades 'de:disaorpdas.'y arquitecnrras multiprocesadoras para,cons'truiT sisteD;las dedkados ique'estl:1vierah op:timizados.comb serYidore!i debases;de datos. Es!0s.fabricantc:;,s.argumhtabanque se poda<.consegu'i(\.n rendimieirto de.flas bases..rle.datos mueho:mejor~con.un:m9tO; de:bases-.de 'd:rtoS;<espeeialmente_diseado quecon'un sistema informtico de propsito: general."Eil 'algunoslcasos-,';sus, sisteinas'!inclujan circuitos"ntegrads de.,aplicaqin especfica:{ASIC i .Applit;,ation.Speei[tclntegrated. Ci-r.cuits), que'i"1plementaban parte de.larJgica,.SGBD:.en(el ~hardware'~para 'una'mxima :yelocidad;, Los,.sistemas de bases 'de datos.dedicadas.de compaas,como Teradata.,y. Sharebase' (antiguamente Britton-Lee) encontraron:..cierta aceptacin..en "'3pJicaeiones; qQe; conllev.aban consultas .complejas en: bases de datos muy.: grandes. Sin embargo;:no.!se.llegaron a converti.r;.en una patte,importante.del mercado. de bases de datos y.Sus fabricantes finalmente desaparecieron o fueron adquiridos por compaas de computadoras mayores, de.propsito generaL .. ' ?:, ,,_.., ; . . . . . . . " . ,::'... ;:.!:' J .::(lUTiosamente,: la :nocin ,de;un .hardware. para.ser..vidores .de;bas.es::de.datos empaquetado, todo en- uno,-~flle brevemente reavivada a fmales de los aos-novenra
~ ~':,. ;
926
Captulo 26: El futuro de SaL
927
por Orade Corporation y su CEO, Larry Ellison. Ellison argumentaba que la era Internet haba visto el xilo de otros productos todo-en-uno, como equipamiento para redes y servidores cach Web. Orade anunci vnculos con varios fabricantes de hardware para bases de datos para construir hardware para bases de datos basado en Orade. Con el tiempo. sin embargo, estos esfuerzos tuvieron poco impacto en el mercado y el entusiasmo de Ocacle por el hardware para bases de datos disminuy6. Varias empresas han adoptado recientemente la idea de hardware para servidores de bases de datos llna vez ms, esta vez en la forma de servidores de cach de bases de datos que residen en una red entre la aplicacin y la base de datos corporativa. Estas tendencias apuntan el amplio xito de la cach de las pginas Web en la arquitectura Internet, y postulan una oportunidad similar de la cach de datos. Al contrario que en las pginas Web, sin embargo, los contenidos de las bases de datos tienden a tener un carcter inherentemente transaccional, lo que hace mucho ms importante y mucho ms complicada la sincronizacin de los contenidos cach con la base de datos principal (para asegurar que las solicitudes resueltas por la cach de la base de datos den la repuesta adecuada). La cuestin de si el hardware cach para bases de datos calar o no se mantiene an abierta al escribir este libro.
Las guerras de las pruebas

Al mudarse las bases de datos relacionales basadas en SQL a la corriente principal del procesamiento de datos empresarial, el rendimiento de la base de datos se ha convertido en un factor decisivo en la seleccin del SGBD. El hecho de que el usuario est centrado en el rendimiento de la base de datos, junto con el inters de los fabricantes de SGBD por vender configuraciones SGBD de alto precio y altos mrgenes, ha generado una serie de guerras de pruebas entre los fabricantes de SGBD. VIrtualmente, todos los fabricantes de SGBD se unieron a la lucha en algn momento de la pasada dcada. Algunos se han centrado en el mximo rendimiento absoluto de la base de datos. Otros ponen el nfasis en el precio/rendimiento y efectividad del coste de su solucin SGBD. Otros ponen el nfasis en el rendimiento para tipos especficos de procesamiento de bases de datos, tales como OLTP u OLAP. En todos los casos los fabricantes pregonan pruebas que muestran el rendimiento superior de sus productos, a la vez que intentan desacreditar las pruebas de sus competidores. Las primeras pruebas se centraron en los tests de los propios fabricantes, y despus aparecieron dos pruebas independientes del fabricante. La prueba del dbito y del crdito simulaba transacciones de contabilidad sencillas. La prueba TPI. definida por primera vez por Tandem, meda el rendimiento OLTP bsico. Estas pruebas estandarizadas todava eran sencillas de manipular por los fabricantes para producir los resultados que los colocaban en la posicin ms favorable. En un intento de traer ms estabilidad y significado a los datos de las pruebas, varios fabricantes y consultores de bases de datos se agruparon para producir pruebas de bases de datos estndares que pudieran permitir comparaciones con significado
entre los diversos productos SGBD. Este grupo, denominado Transaction Processing Council (TPC), defini una serie de pruebas OLTP oficiales, conocidas como TPC-A, TPC-B y TPC-e. TPC tambin asumi una funcin de cmara de compensacin para validar y publicar los resultados de las pruebas realizadas en varias marcas de SGBD y sistemas de computadoras. Los resultados de las pruebas TPC se expresan normalmente en transacciones por minuto (por ejemplo, tpmC), pero es comn ver los resultados referidos normalmente al nombre de la prueba (por ejempln, La marca de SGBD X sobre el hardware Y result en 10.000 TPC-Cs). La prueba TPC OLTP ms reciente, TPC-C, intenta medir no solamente el rendimiento del servidor de bases de datos por s mismo, sino tambin el rendimiento de la configuracin global cliente/servidor. Los modernos servidores, en un nivel de grupo de trabajo con varios procesadores, estn consiguiendo miles o decenas de miles de transacciones por minuto en el test TPC-C. Los servidores SMP empresariales basados en UNIX logran varias decenas o miles de tprnC. Los mejores resultados en sistemas comercialmente disponibles tpicos (una agrupacin de procesadores Alpha de 64 bits de muchos millones de dlares) exceden las 100.000 tpme. Transaction Processing Council ha ido ms all de OLTP para desarrollar pruebas para otras reas del rendimiento de las bases de datos. La prueba TPC-D est enfocada en aplicaciones de almacenes de datos. Las pruebas que comprende TPC-D estn basadas en un tpico esquema de bases de datos en almacenes de datos, e incluyen ms consulta,s de anlisis de datos complejas, en lugar de sencillas operaciones de base de datos ms normales en entornos OLTP. Curiosamente, las pruebas TPC especifican que el tamao de la base de datos debe aumentar al aumentar el nmero de transacciones por minuto anunciado. El resultado de una prueba TPC de 5.000 tpmC puede reflejar los resultados de una base de datos de, por ejemplo, cientos de megabytes de datos, mientras que un resultado de 20.000 tpmC de la misma prueba puede reflejar una prueba en una base de datos de muchos gigabytes. Esta provisin de las pruebas TPC se ha diseado para agregar ms realismo a los resultados de las pruebas, puesto que el tamao de la base de datos y del sistema informtico necesario para albergar una aplicacin con demandas de 5.000 tpm es normalmente mucho menor que la escala requerida para albergar una aplicacin con demandas de 20.000 tpm. Adems del rendimiento en bruto, las pruebas TPC tambin miden el factor precio/rendimiento de la base de datos. El precio utilizado en el clculo lo especifica el consejo como el coste de la propiedad durante cinco aos de la base de datos, incluyendo el precio de adquisicin del sistema informtico, cinco aos de mantenimiento y costes de soporte, etc. La medida del precio/rendimiento se expresa en dlares por TPC (por ejemplo Orade en un servidor DELL de cuatro vas pas la barrera de 500 $ por TPC-C). Mientras que unos nmeros altos son mejores para los resultados de transacciones por minuto, son deseables unos nmeros bajos para las medidas del precio/rendimiento. En los ltimos aos, el nfasis del fabricante en los resultados TPC ha resurgido y vuelto a palidecer. La existencia de pruebas TPC y el requisito de que los resultados TPC sean publicados y auditados ha agregado un nivel de integridad y estabilidad a las afirmaciones de las pruebas. Parece que todava falta algo de tiempo para que las pruebas y comprobaciones del rendimiento sean parte del entorno del
928
Captu.1o-26: El. futuro. de .saL
929
mercado de las bases de datos. En -general, los, resultados de las pruebas pueden ayudar a.ajustar las configuraciones de base de:datos y .hardware a los requisitos de una aplicac,in. De forma -general, las:pequeas ventajas en el rendimiento de una prueba para uILSGBD sobre otra estarn probablemenleenmascaradas por otros
factores': '~
"',
Estandarizacin de SaL
.'
. l,'
La adopcin de un estndar ANSI/ISO SQL.oficialfue uno de Ios -factores -principales que aseguraron la posicin de SQL.como el-lenguaje estndar de base de datos, relaciQnales.,en los aos ochenta.. La conformidad con el estndar ANSI! ISO se ha convertido. en un_elemnto~de:comprobacin para.evaluarlos produc.-. tos 'SGBD, por lo que- cada fabricante'de SGBD!;c0nsidera.."que :su;;producto'es comp~tible b est basado en .el estndar ANSI/ISO .. A :fines/de los-dchenta e inicios! de los noventa, todos los, productos SGBD ,populares evoluciOTiaroo:para adaptarse.:3,laslpartes del estndar :que .representaban' un;u$o,'cmn:Jetr.as'~par tes,.:cb:mo ;el:l(,'~nguaje' de mdulos.Jueton 'ignorados ,de fo.rrna:efectiva; Esto:prp,,: duj0 una lenla convergencia a1rededor,de un lenguaje_SQkcentral'en:Jos.produe, ';.~'! . 0.. . -:: ;. t tostSGBEI.populares: ' :.' .':: '.: 0 - ' -_'" Com'se discuti'en:el Captulo -3, el estndar SQVl er.lfelativament~,dbil. conmuchas -omisiones y reas:'que se dejaron a'.la :eleccin .dela 1mplel1enta~n. Durante :varios aos; el comit de~estndares'trabaj6.eniun,estndaI':.SQL2'.ey;.paridi:. do: que- J:em~diara_esta..debilidad. y. extendiera significativamente~el.lenguaje!SQL. AhontI:ario, que el: primer.eslndal'.SQI.::.oque_especific~ba caraetets.ticaSi,que ya estaban,disp0nibles'en la.rnayoIade..lqs .productos.cSQL, .el est~ml"".s.QL2,'cuan, do, se ;pJ:!bJ ic~:en 1992,-,sU-PUS0 un::intento de J.ider:~,ims, quejde 'Seg~ir,;elrqe.rQado~ Especificaba.'caractestigls:y.:fl;lncion~s;que estaban'iampliameilted.mple~ent:' no das.en .los ,PI;oductos,.SGBD .actuales.-'lales _co~o; lo~<c\lrsotes,'Cle .desplazamiento, 10s.ca.tIQgos del-sistema.eslandarizad:Sl.unuso~f!l& ampli9 de.:las.subconsultas.y unnuev:~ ,esquema,de'mensaJes deerror. Los fabricaqtes de SGBD :estn~tQd3:va:en el proceso de hacer evolucionar sus productos para .ad.J;nitit:todas-las-:caractrsti,,: cas ;de :SQL2: -En 'la prctiCa; las \extepsinnes propjetarias (tales \catDo_-eI. soporte mejoJado. de. datos multimedia..:los procedimientos/almacenad.os f) las.extensiones orientadas a,objetos) han, sido_ fr.ecuente:~en.te,ms importantes: pa;a~'0s_:fabricari~ tes ,de.sGBD~que:un:altbigrad.0 :de conformida~cQn~SQL2 .. :~ ;" .. ".::~:~~ ;d,'. __ ~l.o. '.-" El p.rogres.Q de10s, grupo'.s deiestnd.ares~'SQL,SY .mantuvo mediante.elitrabajo sobre_un estridar.SQL3... que comenz.inaluso anlesl.qe 'que-se publicara eLestn-: dar SQL2. Alaumentar los;.retrasesry eI.timero de reas-que haba:.de solueionar el . siguiente estndar,. ,el.tr:abajo en~SQL31ue;:dividido,:en lesfuer:zos~separados "Y paralelos enfocados sobre eLncleoldeUenguaje,Ja interfaz en:el:ni~el.de.llama-: das (Call~Level Interface.. eLl), los mdulos de almacenamiento persistentesl(procedimientos .alm~cenados)..las transacc;:iones distribuidas, los-.:datos basados en .el tiempo.,:etc. Algunos .de -esto.s esfuerzos. se. pub1icar:Qll.~unos p.ocos.. aos despus como.m.ojQI~lS,al eS'lndarSQL2.de 1992,,8.lanz6 un estndarCLI .compatible!con SQL2 en, 1995, como ,SQL-.CLbUn 'ao' despus"en, ~996.,se lanz".na,capacidad
J : :. . ; . : ':'.,-', , : -:
de:procedimiento almacenado estandarizada comoSQL-PLM. En 1998;se estandariz los vnculos del lenguaje o-rientado a objetos para SQLen la especificacin SQL-OLB. Unconjunto bsico de.capacidades OLAP fueron' publicadas en un estndar SQL-OLAP en 2000. ' .. " , . '_';,' Aunque el progreso continu sobre estas adiciones al estndar 'SQL2. "el trabajo en la parte centraldel lenguaje SQL3 (denominada fundamentos del estndar) se centr en cmo agregar capacidades orientadas a objetos a SQL2. Esto se convirti rpidamente en una actividad .muy controvertida. Los tericos 'de las .bases de datos relacionalesy puristas adoptaron' una fuerte posicin contra muchas de las extensiones propuestas.' Reivindicaban que las propuestas _-confundan temas conceptuales .y de arquitectura (por ejemplo, aadiendo subestructuras ms all de las tablas con 'filas'y columnas) con- temas de implementacin (por ejemplo. temas de rendimientode bases de'datos normalizadas y reuniones multitabla). Los proponentes de las extensiqnes.objeto S.QL3 apuntaban a la popularidad de la programacin. orientada a_objetos iBUaslte-cnicas de .desarroUo, e insistan 'en que la rgida estructura de frias ~y:coliJ.mnaside las bases de datos relacionales se deba extender para abarcar c(~:mceptos-Jde;bje tos~; O "sera .omitida ,por :la re,!oluci6n de!16s .objetos. ;Sumrguni'en1ac;inrf refo~aaa'e'n ~l.mercado;cuando losfabricantes de~os principaLes.SGBIilrrelacionales agigaron :extensiones or.ientadas.8Jobjetos;a-sus produ_ctos..;paratdesafiar la 'ofen~iYa de' las .bases de datos :Orientadas<a.objetos -puras, JY"SU ~'estra{egia fue mny__satisfactoria. ',. "';,., _'. ;_. .;!_ ,,' -..:..La controversia.con~eTtrabaj.o ..SQL3 se,resolvi_finahriente despus de siete a0s de;esfueIzo,con ,la puolicaci6nde1. estndar SQL:1999,(el.tnninoSQL3, que..se utiliz dnrante .eL.desarrollo..de.! estndar~.se1ia reem5.lazado. p.or el. trmillo oficial_S@L:1999)".ELestQdarJS.QL:1999 '.se ~structura'en .una serie ,de ..1.' ' '~'(' ' . " ":~!J:r,.::.(: ,: il.. !!!!,! ;.!;~,;r,~,'.':';-,:;; !;.:~~ :.;".;'~-'" iJ:~; partes: -. ~: ,; i.. r,,[ 'JI., V : ".' ! . J'~. :.. . .. ;;hf; )~: ..;i; '-'~-'..~:~ _ .. ;jl; :,.':. ;1,;, .:' 'J:J~ ;._-.. : ' ._. ~,I .... _ 11: -!~ &irte 1: En.to..rn9. D~scrjbe .loS:b'Qbjetivos:',gJo~b_al~s~-y'.la estrnct,ur.a. Q~l es.t~n~:: ::Qar....asi.com, la, organizacin. de;sus .otras..parte$.~1 :: j( ,:: . :Ji. :'1..:;-: :)'J .} '.' ::,.' . ,.P;>rle 2: Fundamenlps.Es.el cuerpo principal,deJ:estndar.enfocado.al:len' :. '1); ,guaje,S.QL 'mistno"Aqu.se.. especi.ficanJa~. instru~ciOnes .y;clu~ula~ S,QL. ~ .';.','. semntica de las_.:t(ansacciones;.estroctura, de'la_b~se.de: datos ..:privilegios lJ. '-.' ~..~ capacid.aq.es ;simiJ.are~-. Esta. part.e Lt~pJ~n, .contiene, l~s; -e~t~!lsiones. a SQL
~d: ~:)",orlent;1.das.;a9QjetQSl.:~')(; :Ul... :;.._: '.; _":.. ,:;:,~i.~!');'.:I'~' ~:J;<; " :,f: <: ~I' .'.'J'j .:1 i J!I;PJlFte, .3.:IQterfa:z_en,:,el-nlvel, de'.Uam_~da,s.:,CoQtieM las e.x,ten.siones -S.<QL,:, "!: mCLl~1.995) al estndar SQL,9.2; actualizad.as;p:!ra eump)i[~ol1;cSQJ,.;.l999.
Parte 4: Mdulos almacenados persistentes. De forma:;similar,::cpntiene

la~oeXlen,jQn~s,SQL,I1SM,( 199.6}Jl~.e:stnlarISQL-9'2. ctualizado,pa cum,..:L;.. ~i.! !;. ;1'~ :.,j)Hr::; ij~ '-:.d'~::..m:';.:;:::nr"J 'Ji;' l;ll-.iPar~e5:,~nclllosiCon el 'Ienguaje~anfi.t.rj.n~ Tr.~t&:='d_~).aJj jnler;tcs:Qn,~!entre -:::, rtos.Jenguaje:sfan!itpones proce.dinientales (cOTQo:,G>;GIC0BQL}.;y:SQI!..~i ;:\:,..; ~,J.rParfe 9~ Gestin de datos:exter.nos.:DescribeLc.mo una <basa:de:daLOs'b.asa~ (.;n~j da en:SQL (deberfa,gestionar:.los! da.t.o.s.,ext.ernos a_la~bas~)de ...Q~tO~~; li 'H!::': ;.'
li.g 1llir,.conS.QL~.l99.P~1..'j,~il:2
-','i'"
..",.,P,a.le'10:' Vnculoscon, los. lenguajes orieo.l;d.osa<>bjetos"T(t"'con lo :... ::mismo$;ternas ~\le la Parte 5,_pero paralenguajes"p!:ien.tadosra.qbje.l.Qs~j1-. ~.
930
931
Algunas partes del estndar estaban todava en desarrollo cuando se escribi este libro, como se indica por los nmeros que faltan en las paftes. Adems, otros esfuerzos de estandarizacin relacionados con SQL se han dividido en sus actividades independientes. Un estndar independiente est bajo desarrollo para la gestin basada en SQL de datos multimedia, tales como contenidos de documentos de texto completo, audio y vdeo. ste es, en s mismo, un estndar con varias partes; algunas ya han sido publicadas. Otro estndar independiente hace oficial el SQL incorporado para Java, conocido como SQLJ. En el cambio de SQLl a SQL2, y despus de SQL:1999, los estndares oficiales ANSlJISO SQL han aumentado en mbito. El estndar SQLl tena menos de 100 pginas; la seccin Entorno (parte 1) del estndar SQL: 1999 es casi tan grande. La seccin Fundamentos del estndar SQL: l 999 pasa de las 1000 pginas, y las partes actualmente publicadas, en conjunto, sobrepasan las 2000 pginas. El mbito ampliamente expandido del estndar SQL: 1999 refleja la gran utilidad y aplicabilidad de SQL, pero el reto de implementar y adaptarse a un conjunto tan voluminoso de estndares es formidable, incluso para grandes fabricantes de SGBD con grandes plantillas de desarrollo. Conviene indicar que l estndar SQL:1999 adopta un enfoque muy diferente a las afirmaciones de conformidad con el estndar que los estndares SQLI y SQL2. El estndar SQL2 defini tres niveles de conformidad (entrada, intermedio y completo) e indic las caractersticas especficas del estndar que se deben implementar para reivindicar la conformidad en cada nivel. En la prctica, los fabricantes de SOBO encontraron algunas caractersticas en cada nivel importantes para sus clientes, y otras relativamente poco importantes. Por ello, virtualmente, todas las implementaciones SQL actuales reivindican alguna forma de conformidad con SQL2; pero son muy pocas, si hay alguna, las que implementan todas las caractersticas requeridas para la conformidad formal intermedia o completa. Con esta experiencia en mente, el grupo de estndares SQL:1999 defini solamente un nivel SQL nuclear de conformidad, que corresponde grosso modo al nivel de entrada de SQL2 ms algunas caractersticas seleccionadas de los niveles intermedio y completo. Ms all de este SQL nuclear, las caractersticas adicionales se agrupan en paquetes, sobre los cuales se puede sostener de forma individual la conformidad. Hay un paquete para las capacidades SQL-CLI, otro para SQLPSM, otro para las funciones de integridad de datos mejorada, otro para las funciones de fecha y hora mejoradas, etc. Esta estructura permite que los fabricantes de SOBO individuales elijan las reas del estndar que son ms importantes para los mercados particulares a los que sirven y hace ms prctico el cumplimiento de partes del estndar. Al escribir este libro, el estndar SQL: 1999 era demasiado nuevo para sopesar completamente su impacto en el mercado SOBO. Si puede servir como gua la experiencia con SQL2, los fabricantes evaluarn cuidadosamente y de forma individual los nuevos aspectos de la funcionalidad de SQL: 1999 y buscarn mediante la retroalimentacin cules de sus bases de clientes son tiles. Con la nueva funcionalidad requerida por las caractersticas de SQL: 1999, como los tipos de datos defini90s por el usuario y las consultas recursivas, la implementacin de algunas partes de SQL: 1999 supondr ms de un ao incluso para los mayo-
res fabricantes de SGBD. En la prctica el estndar SQLI (SQL-89) define las capacidades SQL principales admitidas virtualmente por todos los productos; el estndar SQL2 (SQL-92) representa el estado actual del arte en los grandes productos de bases de datos empresariales, y el estndar SQL: 1999 es un mapa para el desarrollo futuro. Adems del estndar SQL oficial, los productos IBM y Gracle continuarn representando una poderosa influencia en la evolucin de SQL. Como desarrollador de SQL y un asesor importante de la gestin de IS corporativa. las decisiones de IBM sobre SQL siempre han tenido un impacto principal sobre otros fabricantes de productos SQL. La posicin dominante en el mercado de Gracle le ha dado un papel similar al agregar nuevas caractersticas SQL a sus productos. Cuando los dialectos IBM, Oracle y ANSI SQL han diferido en el pasado, los principales fabricantes de SGBO independientes han elegido seguir los estndares IBM u Oracle. El camino futuro de la estandarizacin SQL aparece, por ello, corno una continuacin de la historia de los ltimos aos. El ncleo del lenguaje SQL continuar estando altamente estandarizado. La mayora de las caractersticas se convertirn lentamente en parte del ncleo y se definirn como paquetes aadidos o nuevos estndares en s mismos. Los fabricantes de bases de datos continuarn agregando nuevas caractersticas propias en un esfuerzo continuado por diferenciar sus productos y ofrecer a los clientes una razn para su compra.
saL en la prxima dcada

La prediccin del camino del mercado de bases de datos y SQL en los prximos cinco a diez aos es arriesgada. El mercado de computadoras se encuentra en medio de una gran transicin a una era dirigida por Internet. Los primeros estados de esa era, dominados por World Wide Web y la interaccin entre el usuario y el explorador, estn dando lugar a una Internet ubicua utilizada para repartir todos los servicios de comunicacin, informacin e interaccin de los negocios electrnicos. La irrupcin del pe y la creacin de la era cliente/servidor de los aos ochenta y noventa ilustra cmo los cambios subyacentes en el mercado de sistemas de computadoras puede producir cambios principales en las arquitecturas de gestin de da~os. Es probable que Internet tenga un impacto tan grande, si no mayor, en las arquitecturas de gestin de datos de los prximos diez aos. No obstante, aparecen varias tendencias como predicciones seguras para la evolucin futura de la gestin de bases de datos. Se analizan en las secciones finales de este captulo.
Bases de datos distribuidas

Al usarse ms y ms aplicaciones en un nivel empresarial o mayor, la posibilidad de que una nica base de datos centralizada admita docenas de aplicaciones princi-
932
SOL Manual-de referencia,,'.
933
paJes y miles de.-usuarios -simultneos. continuar erosianndose. Por contra, .las principales' bases de:datos ,corporativas sern cada ,yez,ms y msdistribuidas, oon baBes de.. .:datos dedicadas' .albergar las principales. aplicadones y reas"funcionales:de Ja corporaein: Para cumplir con los altos niveles de'servicio requeridos. en las aplicaciones corporativas o basadas en Internet, los datos deben estar:distribui.dos; pero para asegurar. la integridad de las ~de_cisiones:y .operaciones del negbcio, la-:.op.eracn de estas bases'dedaLOs distribuidas debe.estar.al~amente coordinada. . Otro factor de "tensin sobre las .arquitecturas-rle bases de datos c.entralizadas ser et.,continuo-,crecimiemo de las computadoras .porttiles y otros dispositivos pOrttiles"de informaein. -Estos dispositivos. son;'por su :naturaleza, ms. tiles:si se p.ueden.convertir-.en una:parte integral de, una,r.~d distribuida..Sin embargo,por su naturale.z.a. tambin.estn cOll~Gtados de forma, ocasional (algunas 'veces funcionan en-modo .conectado; otras en modo pesconectado), y utiliza cedes-por cable O inalmbricas. Las bases de datos principales de las aplicaciones' porttiles deben poder operar en este entorno,ocasionalmente ,conectado. . . . '=.' Estas; tendencias producirn 'una fuerte demanda_para' la distribucin' de' datos. integracin de las bases de ,datos, sincronizacin de datos, cach:de datos, reparto dedatos' y tecnologa.'de bases ,de datos' distribuidas. Bn 'modelo: de datos de Wl tmao' que: se ajus~ a tod,ytransaccibnes distribuidas: no Les:.:el adecuado para el entorno altament:disl:ribido.eo'cualquier Jugarla cualquier, hora 'Que emerger. Por contra, algunas transac~iones .requerirn. una';si:ocronizacin:absoluta conda base de datos centralizada principal, mientras que otras demandarn soporte para transacciones de larga duracin en que la sincronizacin puede durar horas o das. El desarrollo de formas de crear y operar con estos entorno~ distribuidqs, &,i.n h.ac~r que sean la pesadilla de ,los administradores d''ases'de 'datos, ~'ei..ri de-safo'de primer orden para los fabricantes de SG;BD en la siguiente dca~a y una fuente l. " ".,. .... . _. /.... -, pnn~lpal'de beneficios para' los 'fabricantes que~prQpotcionen soluciones prct'icas, , . ' -. . '.' '. ~ ielativam'eite fcile's de'uiiizar. " .. ' .
, ." \ l '
J ' :,:
Internet crea unas grandes y nuevas posibilidades para esta clase de recopilacin de informacin. Literalmente, todo cliente O interaccin del posible cliente con el sitio Web de una compaa, clic a clic, proporciona indicios .potenciales de las necesidades, deseos y comportamiento del cliente, Ese tipo de informacin clic a clic puede general fcilmente decenas de megabytes de datos o ms por da en un sitio Web ocupado. Las bases de datos para gestionar estas cantidades masivas de datos necesitarn incorporar sistemas de almacenamiento multinivel. Necesitarn imponar rpidamente grandes cantidades de nuevos datos, y analizar rpidamente grandes subconjuntos de datos. A pesar de la alta tasa de fracasos en los proyectos de los almacenes de datos, las grandes recompensas en costes operativos reducidos y ms actividades de marketing y ventas continuarn dirigiendo el crecimiento de los almacenes de datos. Adems de la recoleccin y el almacenamiento de datos, habr presin para realizar anlisis del negocio en tiempo real. Grupos de consultoras IS estn escribiendo sobre la empresa con latencia cero o empresas en tiempo real para describir una arquitectura en la cual las interacciones con el cliente se traduzcan directamente en cambios en los planes del negocio con ningn, o muy pequeo, retraso. Para cumplir este objetivo, los sistemas de bases de datos continuarn aprovechan do los avances en la velocidad de los procesadores y tecnologas multiprocesadoras.
Bases de datos de rendimiento ultra-alto

La irrupcin de una arquitectura centrada en Internet est exponiendo a las estructuras de procesamiento de los datos empresariales a nuevas demandas de picos de carga que empequeecen las cargas de trabajo de hace solamente unos pocos aos. Cuando las bases de datos admitan principalmente las aplicaciones caseras utilizadas por unas pocas docenas de empleados a la vez, la cuestin del rendimiento de las bases de datos podra generar frustracin en los empleados, pero no impactaba realmente en los clientes. Con la llegada de los centros de llamada y otras aplicaciones de soporte a los clientes se produjo un mejor acoplamiento entre la gestin de datos y la satisfaccin de los clientes, pero las aplicaciones estaban todava limitadas a muchos cientos de usuarios simultneamente (las personas al telfono en el centro de llamadas). Con Internet, la conexin entre un cliente y las bases de datos de la compaa es directa. Los problemas de rendimiento de la base de datos se traducen directamente en tiempos de respuesta del cliente ms lentos, La no disponibilidad de la base de datos se traduce directamente en prdidas de ventas. Adems, las bases de datos y otras partes de la infraestructura de procesamiento de datos ya no se almacenan en bferes en los altos picos de carga de transacciones. Si una empresa de servicios financieros ofrece comercio interactivo o gestin de la cartera, necesitar prepararse para grandes volmenes de carga en aquellos das en que un fuerte movimiento del precio de la bolsa pueda producir un volumen 10 O 20 veces superior al movimiento promedio. De igual forma, un comerciante en lnea se debe preparar para afrontar la poca de fin de ao de mayores ventas, no slo las tasas de transacciones de mediados de marzo.
.'_:'
;:,F~!)';.
:!
ji i' :.'
,;
: . : '.:"lf!;
v". ~ _ ':.. '?'~'

:,:";'/':
::.:', :_. .
'!
. . . ,-
: ,':'
' . , , ' , ;.' ';.;'/.>:',
1:1' ',:11..
'';
~}l". .. '.'l f'. { "'~"

'; "1;;;-:" .
' .. " .' .I.~' .... ~ ::.J
"'_'L
'"
~/~,~,~ef'l!s;~~' 1a,t~~;m,~s~d~,:"
bSl'oe"oatos
,!"
J.;l.. .? ,'~
; J ':(, :
u:;'/I
Los:\1ti~os':a~'nan' dei1srra:~(f:'c'e '-la:s~tomp::ir;s gli~~\itilzah: tecii~,lbg~ -tle
'Ei ;xit6 :dmpet'ti~o: oe WalMm; poi ejeITpl,d. 'se atri,DiJ.ye:!priI.Ii,.alieifel~ 'su:' iis6.ae'la 't~'6i6ga~tle iii informacin' (conauc'ido p'~la teciiolog~' de"oase's de'ldato)"paTf(segir !s'ln\ie6~ i(io 'y i~riHls'''def6qn didH~?' bas""rH:ios2'n Ids 'datosde tt:anSacdQtl-e.S'de r8~:cj! ro~:'E~t.\perniitr-'3' ibblli~a.fuiFniihitiiitat su's fivefes~'de' invritanQ' y' gesti)hi de forma ms directa sus relaciones con los proveedores. Las tcnicaS' tle irnriera de datos han permitido a las compaas descubrir tendencias inesperadas y relaciones basadas en sus datos acumulados (incluyendo el legendario descubrimiento de un comerciante de que las ventas noctumi53d~pafiareS~stii15~fer.tefete~~ lacionadas con las ventas de cerveza). !:f'i. Parece::e1ar.q.. queJas- compaas cantinuarfl;acumulandotanta.infQrroaO.0n como puedan..de, sus ~clientes{i:'te.ntas, ,inv.entattiQsj, precios . yo Lotr_OS JaPtoe~,.de,l-;negoJ:i ..
valioso-'pueaeh'gaIia('Una'vnt~1a "'ompetinva'timeilda~
de
fdfrrili,la~+esiva ~Y:)trata'n;suslaatos~
coinb':uti' 'activ 'c,ij"(lfativo
934
935
Las demandas del comercio electrnico y el acceso a la informacin de Internet en tiempo real estn ya produciendo factores de transaccin con picos de .carga desde los servicios de Internet ms populares, que son de un orden de magmtud o dos ms rpidos que los sistemas RSGBD basados en disco convencionales ms rpidos. Para cubrir estas demandas las ,compaas cam.biarn a las bases de datos distribuidas y reproducidas. Almacenaran los da.tos calientes en cach. cerca de la interaccin con los clientes en la red. Para cubnr las demandas de piCOS de carga utilizarn bases de datos residentes en memoria principal. Requerirn, en cambio, nuevo soporte para bases de datos para deci?ir los datos a ~l~a~enar en cach y los niveles de sincronizacin y rplica apropIados. En un pnnclpIo estos temas se aplicarn solamente a los sitios princ~pales y de may~r volumen, pero as ~omo la cach de pginas Web se ha convertIdo en una tCnica aceptada y ~senclal para mantener un rendimiento adecuado de los exploradores Web, la cache de los datos calientes se convertir en la arquitectura de gestin de datos de Internet principal al ir creciendo el volumen.
Todava no est claro cmo se racionalizarn estas tendencias y si la lgica del negocio continuar esta migracin a la base de datos o se establecer en una capa del servidor de aplicaciones. Sin importar cul de las tendencias predomine, se requerir una integracin mayor entre los servidores de bases de datos y los servidores de aplicaciones. Varios de los fabricantes de SGBD producen ahora sus propios servidores de aplicaciones y parece probable que proporcionarn la mejor integracin en sus propias lneas de productos. Todava es una cuestin abierta si este enfoque prevalecer en oposicin al enfoque del mejor adaptado.
Bases de datos incorporadas

La tecnologa de bases de datos relacionales ha llegado a muchas partes de la industria informtica, desde pequeos dispositivos de mano a grandes sistemas. Las bases de datos estn por debajo de casi todas las aplicaciones empresariales, como el fundamento para almacenar y gestionar su informacin. La tecnologa de bases de datos admite de forma ms flexible un rango incluso mayor de aplicaciones. Los servjcios de directorio, una tecnologa fundamental para la nueva era de servicios de red de comunicaciones de datos de valor aadido, permiten redes mviles, esquemas de facturacin avanzados, servicios de mensajera inteligentes y capacidades similares. Estas aplicaciones de bases de datos incorporadas se han implementado tradicionalmente utilizando cdigo de gestin de datos propietario y escrito para el cliente integrado con la aplicacin. Este enfoque especfico de la aplicacin produjo el mayor rendimiento posible, pero a costa de una solucin de la gestin de datos inflexible y difcil de mantener. Con la disminucin del precio de las memorias y los procesadores de mayor rendimiento, las bases de datos relacionales basadas en SQL flexibles pueden ahora soportar estas aplicaciones econmicamente. La ventaja de una base de datos incorporada basada en estndares es sustancial. Sin un compromiso serio en el rendimiento, se puede desarrollar una aplicacin de una forma ms modular, los cambios en la estructura de la base de datos se pueden gestionar de forma transparente, y los nuevos servicios y aplicaciones se pueden implantar rpidamente sobre las bases de datos existentes. Con estas ventajas, las aplicaciones de bases de datos incorporadas parecen destinadas a una nueva rea de crecimiento potencial para SQL y la tecnologa de bases de datos relacionales. Como en otras muchas reas de la tecnologa de la informacin, el ltimo triunfo de las bases de dat9s basadas en SQL es que desaparezcan dentro del desarrollo de otros productos y servicios -siendo invisibles como componente independiente, pero vitales para el producto o servicio que los contiene.
Integracin de los servicios de Internet y de red

En la era de Internet, la gestin de las bases de datos ir convirtindose en solamente un servicio de Internet ms, y debe estar fuertemente integrado con otros servicios, como el de mensajera, servicios de transacciones y la gestin de la red. En algunas de estas reas, los estndares estn bien establecidos, tal como el estndar XA para la gestin de transacciones distribuidas. En otros, los eS,tndares estn en ciernes o acaban de emerger, como el estndar SOAP para enViar datos XML a travs del protocolo HITP, y los estndares UDDI para buscar servicios en un entorno de red distribuido. La arquitectura de muchas capas que est dominando las aplicaciones centrales de Internet tambin plantea nuevas cuestiones sobre qu funciones se deberan realizar por parte del gestor de la base de datos y por otros componentes del sistema de informacin global. Por ejemplo, cuando las transacciones de red se ven desde el punto de vista de las bases de datos distribuidas, un protocolo de compromiso de dos fases, implementado de una forma propia por un fabricante SOBD, puede proporcionar una solucin. Cuando las transacciones de red conllevan una combinacin de aplicaciones heredadas (por ejemplo, transacciones eles de un gran sistema), actualizaciones de la base de datos relacional y mensajes entre aplicaciones, el problema de la gestin de transacciones se traslada fuera de la base de datos y se requieren mecanismos externos. Un compromiso similar supone la irrupcin de servidores de aplicaciones basados en Java como una plataforma de capa intermedia para ejecutar la lgica del negocio. Antes de la era Internet los procedimientos almacenados se convirtieron en una tcnica SGBD aceptada para incorporar la lgica del negocio en la base de datos misma. Ms recientemente Java ha emergido como un lenguaje de procedimientos almacenados viable, una alternativa a anteriores lenguajes propios de los fabricantes. Ahora los servidores de aplicaciones crean una plataforma alternativa para la lgica del negocio escrita en Java, en este caso externa a la base de datos.
Integracin de objetos
Lo ms desconocido en la futura evolucin de SQL es cmo se integrar con las tecnologas orientadas a objetos. Las modernas herramientas de desarrollo de apli-
936
937
caciones y las metodologas estn basadas en tcnicas orientadas a objeLOs. Dos lenguajes orientados a objetos, C++ y Java, dominan el desarrollo del software, tanto en el lado del cliente como del servidor. Sin embargo, los principios principales de filas y columnas del modelo de datos relacional y SQL estn enraizados en la muy anterior etapa de COBOL de registros y cambios. no de objetos y mtodos. La solucin de los fabricantes de bases de datos orientadas a objetos al desajuste relaciones/objetos ha sido el completo descarte del modelo relacional en favor de las estructuras de bases de datos puramente de objetos. Pero la falta de estndares, la abrupta curva de aprendizaje, la falta de formas de consulta sencillas y otras desventajas han evitado que las bases de datos orientadas a objetos puras tengan un xito significativo en el mercado hasta la fecha. Los fabricantes de bases de datos relacionales han respondido al desafo de las bases de datos orientadas a objetos adoptando caractersticas orientadas a objetos, pero el resultado ha sido una proliferacin de caractersticas no estndar y propias y ex~ tensiones SQL. Es claro que la tecnologa de bases de datos relaciones y la tecnologa de objetos debe estar ms estrechamente integrada si las bases de datos relacionales van a permanecer como una parte integral de la siguiente generacin de aplicaciones. Varias tendencias son visibles actualmente:
Todava esta por ver si estas extensiones a SQL y al modelo relacional pueden integrar satisfactoriamente los mundos de SGBDR y de objetos. Los fabricantes de bases de datos orientadas a objetos continan manteniendo que las capacidades orientadas a objetos construidas sobre un RSGBD no pueden proporcionar la clase de integracin transparente necesaria. La mayor parte de ellos han adoptado de forma entusiasta XML como la corriente ms nueva de la tecnologa de objetos. Los fabricantes de SGBD empresarial han anunciado y agregado capacidades sustanciales relacionales orientadas a objetos Y. ms recientemente, productos de integracin XML y caractersticas, pero es difcil determinar cmo se estn usando muchos de ellos. Adems, la irrupcin de XML como un estndar Internet importante ha dado lugar a una nueva ola de desafos a las bases de datos que ofrecen bases de datos XML nativas. Con todas estas alternativas competidoras, la integracin de las tecnologas orientadas a objetos en el mundo de las bases de datos relacionales parece cierta. La ruta especfica que esta evolucin adoptar permanece como el mayor desconocido en el futuro de SQL.
Resumen
SQL contina desempeando una funcin significativa en la industria de computadoras y parece que continuar siendo una importante tecnologa central: Las bases de datos basadas en SQL son productos software lderes para los tres mayores fabricantes de software en el mundo: Microsoft, Oracle e IBM. Las bases de datos basadas en SQL operan sobre todas las clases de sistemas de computadoras, desde grandes sistemas y servidores de bases de datos a clientes con computadoras de mesa, porttiles y PDA manuales. Todas las aplicaciones empresariales principales utilizadas en grandes organizaciones confan en bases de datos SQL de clase empresarial para almace nar y estructurar sus datos. Las bases de datos basadas en SQL han respondido satisfactoriamente a los desafos del modelo de objetos, con extensiones SQL en las bases de datos orientadas a objetos/relacionales. Las bases de datos basadas en SQL estn respondiendo a las necesidades de las arquitecturas basadas en Internet incorporando XML e integrndose con los servidores de aplicaciones.
Las interfaces basadas en Java a RSGBD. tales como JDBC y SQL incorporado para Java, continuarn aumentando rpidamente su popularidad. Java se convertir en un lenguaje de procedimientos almacenados ms importante para implementar la lgica del negocio con un RSGBD. Virtualmente todos los fabricantes de SGBD principales han anunciado planes para . admitir Java como una alternativa a sus propios lenguajes de procedimientos almacenados. Los productos SGBD aumentarn su soporte para tipos de datos abstractos y complejos que exhiben capacidades orientadas a objetos, tales como la encapsulacin y la herencia. Aparte del acuerdo de alto nivel sobre la necesidad de almacenar objetos en una estructura de filas y columas, los detalles (tablas anidadas, arrays. columnas complejas) varan sustancialmente. El estndar SQL:1999 para las extensiones orientadas a objetos a SQL in~ fluir en los productos de los fabricantes, pero lentamente, mientras los fabricantes continan buscando ventajas competitivas y usuarios fieles con las extensiones orientadas a objetos. Las interfaces orientadas a los me",sajes, incluyendo los disparadores de las bases de datos que generan mensajes externos al SGBD para la integracin con otras aplicaciones, crecern en importancia, al hacer que la base de datos sea un componente ms activo para integrar los sistemas. XML emerger como un formato estndar importante para representar los datos recuperados de una base de datos SQL y los datos a introducir o actualizar en una base de datos. Los fabricantes de SGBD ofrecern extensiones de SQL para almacenar y recuperar documentos XML y para buscar y recuperar sus contenidos.
Parte VII
APNDICES
APENDICE
La base de datos de ejemplo
La mayora de los ejemplos de este libro estn basados en la base de datos que se describe en este apndice. La base de datos de ejemplo contiene datos que admite una aplicacin simple de procesamiento de pedidos para una pequea empresa de distribucin. Consiste en cinco tablas:
CLIENTES.
REPRESENTANTES.
Contiene una fila por cada cliente de la empresa. Contiene una fila por cada representante de "la empresa. OFICINAS. Contiene una fila por cada una de las cinco oficinas de ventas de la empresa en las que trabajan empleados. PRODUCTOS. Contiene una fila por cada tipo de producto disponible a la venta.. PEDIDOS. Contiene una fila por cada pedido fonnulado por un cliente. Por simplificar se considera que cada pedido se refiere a un solo producto.
La Figura A.l muestra grficamente las cinco tablas, las columnas que contienen y las relaciones padre/hijo entre ellas. La clave primaria de cada tabla est sombreada. Las cinco tablas de la base de datos de ejemplo se pueden crear usando las instrucciones CREATE TABLE que se muestran a continuacin:
CREATE TABLE INUM_CLI EMPRESA REP_CLI LIMITE_CREDITO PRIMARY REY FOREIGN KEY REFERENCES ON DELETE CLIENTES INTEGER NOT NULL. VARCHAR(20) NOT NULL. INTEGER. MONEY. (NUH_CLI). TIENEREP (REP_CLI) REPRESENTANTES SET NULL)
CREATE TABLE OFICINAS
941
942

INTEGER NOT NULL, VARCHAR(15) NOT MULL, VARCHAR(lOJ NQT NULL. INTEGER, MONEY, MONEY NOT NULL, (OFICINA). TIENEJEF (JEFI REPRESENTANTES SET NULL) REPRESENTANTES INTEGER NOT NULL, VARCHAR(15) NOT NULL, INTEGER, INTEGER, VARCHAR(lO) , DATE NOT NULL, INTEGER, MONEY, MONEY NOT NULL, (NUM_EMPL), (JEFE) REPRESENTANTES SET NULL, TRABAJA EN (OFICINA_REP) OFICINAS SET NULL) PEDIDOS INTEGER NQT NULL, DATE NOT NULL. INTEGER NOT NULL. INTEGER.
Apndice A: La base de datos de ejemplo
943
(OFICINA CIUDAD REGlON JEF OBJETIVO VENTAS PRIMARY REY FOREIGN KEY REFERENCES ON DELETE CREATE TABLE (NUM_EMPL NOMBRE EDAD OFICINA_REP PUESTO FECHA_CONTRATO JEFE CUOTA VENTAS PRIMARY KEY FOREIGN KEY REFERENCES ON OELETE FOREIGN KEY REFERENCES ON DELETE CREATE TABLE (NUM_PEDIDO FECHA_PEDIDO CLIENTE REP
TIENEJEF OFICINAS OFICINA CIUDAD REGION

JEF
OFICINA_REP PUESTO VENTAS FECHA_CONTRATO JEFE TRABAJAEN CUOTA OBJETIVO

VENTAS
t)
REPRESENTANTES Nm'CEMPL NOMBRE

EDAD
PRODUCTOS ID_FAB ID_PRODUCTO DESCRIPCION PRECIO

STOCK
SERVlDOPOR PEDlDODE
CLIENTES NUM CLI EMPRESA REP_CLI LIMITE CREDITO
FORMULADOPOR TIENEREP
PEDIDOS NOM_PEDIDO FECHA_PEDIDO CLIENTE

REP FAB
PRODUCTO CANTIDAD IMPORTE
1--
Figura A.1.
La estructura de la base de datos de ejemplo.
FAB eHAR(3) NOT NULL,

PRODUCTO CHAR(5) NOT NULL, CANTIDAD INTEGER NOT NULL, IMPORTE MQNEY NOT NULL,
PRlMARY KEY (NUM_PEDlDO).
Las Figuras A.2 a A.6 muestran los contenidos de cada una de las cinco tablas de la base de datos de ejemplo. Los resultados de las cuestiones planteadas en los ejemplos de este libro se basan en los datos mostrados en estas figuras.
FOREIGN KEY REFERENCES ON DELETE FOREIGN KEY REFERENCES ON DELETE FOREIGN KEY REFERENCES ON DELETE CREATE TABLE (IO_FAB ID_PRODUCTO DESCRIPCION PRECIO STOCK PRIMARY KEY
FORMULADO POR (CLIENTE) CLIENTES CASCADE, SERVIDOPOR (REP) REPRESENTANTES SET NULL, PEDIDODE (FAB, PRODUCTO) PRODUCTOS RESTRICT) PRODUCTOS CHAR(3) NOT NULL, CHAR(5) NOT NULL, VARCHAR(20) NOT NULL, MONEY NO~ NULL, INTEGER NOT NULL, (ID_FAB, ID_PRODUCTO))
944
Apndice A: La base de datos de ejemplo
945
NUM eLI EMPRESA

2111 JCP S.A. 2102 Filas 2103 Acm. 2123 Cruz e hijos 2107 Ace Internacional 2115 Sierras S.A. 2101 Jarandil1a Ltd.
REP eLI
103 101 lOS 102 110 101 106 loa 103 102 107 109 106 lOS 102 102 109 loa 104 103 101
LIMITE CREDITO
50.00a,DaE:
~PEDIDO
SO.oaO,ooE
40.000,OO 35.000,OO 20.00Q,QO 65.000,OO
65.000.oae:
112961 113012 112989 113051 112968 113036 113045 112963 113013 113058 112997 112983 113024 113062 112979 113027 113007 113069 113034 112992
FECHA PEDIDO CLIENTE REP FA' PRODUCTO CANTIDAD IMPORTE 2117 106 REI 2A44L 7 31.500,00 17/12/1989 11/01/1990 03/0111990 10/0211990 12110/1989 30/01/1990 02/0211990 17/12/1989 14/0111990 23/02/1990 08/01/1990 2111 105 ACI 41003 2101 106 FEA 114 2118 108 OSA XK47 2102 101 ACI 41004 2107 110 ACI 4100Z 2112 loa REI 2A44R 2103 lOS ACI 41004 2118 loa "C 41003 2108 109 FEA 112 2124 107 .,C 41003 2103 lOS ACI 41004 2114 108 OSA XK47 2124 107 FEA 114 2114 102 ACI 4100Z 2103 105 ACI 41002 2112 108 IMM 773C 2109 107 IMM 775C 2107 110 REI 2A45C 2118 108 ACI 41002 2111 103 REI 2A44G 2108 101 ACI 4100X 2120 102 IMM 779C 2106 102 REI 2A45C 2106 102 OSA XK47 2108 109 IMM 779C 2118 loa OSA XK47 2103 105 ACI 4100Y 2111 103 ACI 4100X 2113 101 REI 2A44R 3S 6 4
3.745,00~
1.458,00~
1.420,00~
2112 Zeta Producciones

2121 QMA Asociados
2114 Orin Ltd.
50.000,OoE
4S.000,OO 20.0aO.OOE
40.DaO,OO
34
9 10 2a 1 10 1 6 20 10 6 S4 3
22
3.978,00~
22.500. OO~
2124 Pascual Hermanos 2108 Henche & Lpez 2117 J.P. Sotoca 2122 Toledo S.A. 2120 Rico S.A.
2106
45.000,00~
3.276,00~
55.00a,OOE: 35.000,OO Ja.OOo,OOE
652.00~
1 4ao.00' 652,004 702,004 7.100,004 2.430,004 15.000,004 4.104,004 2.925,004 31.350,004 632, OO. 760,004 2.100,004 lSO, OO.
50.000.00E
F. L6pez S.A.
65.000,OO
25.000,QO
2119 Salomn S.A. 2118 Mejorada Sistemas 2113 bero & Sagaz 2109 Chen Asociados 2105 AAA Inversiones
60.000,OO 25.QOO,OO
20.0aD,OOE:
45.00Q,QO
2711211989 20/01/1990 24/0211990

1211011989
Figura A.2.
La tabla CLIENTES.
22/0111990 08/01/1990
02103/1990 29/01/1990
a 10 6 6 2
24
04/11/1989
12/10/1989 15/0211990
'NH DlPL
NOIlBRE
.~,
ortewll UF
U 11 21 11 12 12
'" ". ro,
Bruno ..... 0""0..
""da
J~e~
SUsana santOS
Bernardo s"ch tl<Lniol Rui4tobo
Len Pablo Cnn
'" sa-td Clavd '" '" --. ,.. ,ro re.l... ro, '"
ro'
.. ..
" " " " " " "
"ro
. ...
..
RepreHnOanOe llep..eS40ntante R.p......"" .....t" vp v""ta.. J.ta VenO . . Repn . .nOan.e W~ ~ ..u."tant" 2l Jete Venta .. 12 ....tanu
~~_
PI:CI\1l CO/l'rRll'l'O 12/0211988

U/I0I1ta,
,,,
,~
~,
VENTAS
112975 113055 113048 112993 113065 113003 113049 112987 113057 113042
10/12/1n'
14/0611988 19/05/1987
20110/1186 1l/01/1UO
'" '" ro, '"

'" ro.
"
'" '"
HO.OOo,OOE lOO.Ooo,oOE 350.000, OOE 275.lHlO.OOE 200.000.0OE loO.OOO.OOE
36'.Hl,00E
392.H5,OOE U4.050.0OE 2U.!l2.0OE lU.594.00E lOS. 67l. OOE 75.t85,00E Ul.I65.0OE: 2U:n5.0CIE 186.012 OOE
10/02/1990
04/01/1989 27/02/1990 25/01/1990 10/0211990 31/12/1989
i.750,004
1.896,004 2.130,00' 5.625,004 776.00' 27.500,004 600, OO. 22.500,004
121l0/Un
22 Re .. _.""u,nt"
~:~~~~~::~
l50.lHlO.OOE 275.000. OCIE lOO.OOO OCIE
6 3 2 11 24 S
18/0211990
0210211990
Figura A.3.
La labia REPRESENTANTES.
OFICINA
CIUDAD 22 Daimiel 11 Navarra 12 Castelln 13 Almeria 21 Len
REGI N Oeste Este Este Este Oeste
JEF
OBJETIVO VENTAS 300.000,00 186.042,OO lOa 575.0aO,aO 692.637,00 106 104 800.0aO,OOE 735.042,00 350.000,OO 367.911,OO lOS 725.000,OO 835.915,OO 108
Figura A.5.
La tabla PEDIDOS.
Figura A.4.
La tabla OFICINAS.
946
DESCRIPCIN ID FAB ID PRODUCTO Rueda 2A45C REI Zapata pequea 4100Y ACI OSA SIC IMM ACI ACI SIe IMM OSA REI XK47 41672 779C 41003 41004 41003 887P XK48 2A44L 112 887H 41089 41001 775C 4100Z XK48A 41002 2A44R 773C 4l00X 11. 887X 2A44G Reductora Plato 90-kg brazo Serie 3, cable Serie 4, cable Hlice Buln Reductora Llave Huso Barrilete Retn Serie 1, cable 50-kg brazo Zapata mediana Reductora Serie 2, cable Riostra 30-kg brazo Zapata grande Montura del motor Brazo reten Hilo de cobre
PRECIO 79,00: 2.750,OO: 355,OO 180,OO 1.875,OO 7,OO 117,00: 652,00 250,00 134,00 4.500,OO 148,00 54,OO 225,00 55,OO 1.425,OO 2.S00,OO 177,OO 76,OO 4.S00,OO: 975,OO: 25,OO 243,OO: 475,OO 350,OO:
STOCK 210 2S 38 O 9 207 139 3 2. 203
APNDICE
Perfiles de los fabricantes de bases de datos

Los fabricantes de sistemas de bases de datos perfilados en este apndice han sido seleccionados debido a sus posiciones nicas en la amplia industria de bases de datos. Se incluyen los proveedores de productos SGBD empresariales lderes, algunas pequeas compaas que son lderes en nuevas reas de tecnologa, pioneros de nuevos segmentos del mercado de bases de datos y fabricantes vinculados a tecnologa de bases de datos incorporadas. Es fcil que cualquier compilacin como sta diste de ser exhaustiva, por lo que la omisin de una compaa no significa que sus productos o capacidades sean inferiores a las de los fabricantes perfilados aqu. Colectivamente, estas compaas y perfiles presentados ilustran el paisaje del software y mercado de servicios de bases de datos actual, que mueve muchos miles de millones de euros. Los fabricantes son: A2i, lne. Arbor Software (ahora Hyperion Solutions Corporation) Birdstep Teehnology Computer Assoeiates (Jasmine, Ingles) Computer Corporation of Ameriea (Model 204) Empress Software eXcelon (OhjectStore, XIS) Gupta Teehnologies (SQLBase) Hewlett-Packard (NonStop SQL) IBM Corporation (OB2, lnfonnix, Cloudscape) lnformix Software (ahora parte de IBM) Microsoft Corporation (SQL Server) MySQLAB .Objectivity Oracle Corporation (Oracle, RdbNMS) Persistence Software Pervasive Software PointBase
947
12
lIS 223 78 277 S 28
FEA
IMM sIe AeI IMM ACI OSA AeI REI IMI< AeI
37
167
12
28
37
15
FEA
!MM
32
14
REI
Figura A,6. La tabla PRODUCTOS.
948

Apndice B: Perf/es de los fabricantes de bases de datos
949
PostgreSQL Quadbase Systems Red Brick Systems (ahora parte de lnformix Software) Sybase. lne. TimesTen Performance Software Versant Corporation
A2i, Inc. (www.a2i.com)

Fundada en 1993, A2i desarrolla y comercializa un sistema de edicin de catlogos integrado sobre bases de datos para diferentes medios que centraliza la gestin de los datos del catlogo, simplifica el proceso de prod!lccin del catlogo y automatiza completamente el flujo de trabajo para la produccin del catlogo. El sistema incluye herramientas para crear, disear y publicar catlogos impresos y electrnicos, admite edicin de una fuente nica para diferentes medios a papel, CO-ROM y Web, y adems gestiona de forma eficiente catlogos que contienen cientos de millones de elementos. Todos los productos de software A2i estn en la parte superior de un SGBD basado en SQL. Incluyen aceleradores del rendimiento que mejoran el acceso al catlogo en un factor 10 a 1000 veces superior al de SQL, y presenta funcionalidad adicional especfica del catlogo que admite exploracin y ordenacin interactiva de grandes bases de datos de formas que seran imposibles utilizando solamente un SGBD basado en SQL tradicional. La tecnologa de bsqueda paramtrica de A2i (una alternativa a los formularios de consulta al estilo de SGBD que es intuitiva, fcil de utilizar y muy, muy rpida) permite a un usuario buscar todo un catlogo y localizar cualquier elemento o grupo de elementos en cuestin de segundos, de entre miles o millones de elementos a uno o varios en solamente unas pocas pulsaciones del ratn.
tidimensionales propietarias y se integra con las bases de datos relacionales convencionales. La ltima versin, lanzada al mercado bajo el nombre comercial Essbase XTD, est posicionada como una plataforma de inteligencia del negocio y se ejecuta en varios sistemas operalivos diferentes. En 1998, Arbor se uni a Hyperion Solutions Corporation para crear una compaa de 500 millones de dlares (beneficios anuales) centrada en los informes y en el anlisis del negocio. La lnea de productos ha crecido para incluir un negocio sus tancioso en productos de integracin y servicios de personalizacin. Contiene aplicaciones desde anlisis de un nico usuario sobre estaciones de trabajo Windows hasta implantaciones OLAP empresariales basadas en Web para cientos de usuarios.
Birdstep Technology (www.birdstep.com)

Birdstep Technology es una empresa de software noruega centrada en los sistemas inalmbricos y soluciones incorporadas. Birdstep entr en el negocio de las bases de datos con su adquisicin en septiembre de 2001 de Raima Corporation. Raima, fundada en 1982, fue un fabricante de bases de datos pionero centrado en el mercado de bases de datos sobre IBM Pe. Su producto inicial db_VISTA fue lanzado por primera en 1984. Ha sido continuamente mejorado con los aos y combinado con un gestor de objetos para crear el producto Raima Database Manager (RDM), ahora comercializado por Birdstep. Un producto Raima ms reciente, Velocis Database Server, fue lanzado por pri. mera vez en 1993. Velocis es un sistema de bases de datos relacionales basado en SQL con una interfaz DBC. Est diseado como una base de datos incorporable y la compaa 10 enfoca a desarrolladores de aplicaciones profesionales (fabricantes de software independientes o FSI y VAR (Value-Added Resellers) que lo utilizan como fundamento para las bases de datos. Velocis se ejecuta sobre Windows, Windows NT, OS/2 Y muchas variantes de sistemas operativos basados en UNIX. Una caracterstica distintiva del servidor Velocis es su soporte explcito de los punteros incorporados del modelo de datos de red en una base de datos basada en SQL. Una instruccin CREATE JOIN especifica una relacin explcita, implementada con punteros de red del estilo de las bases de datos, que se almacenan en la estructura de la base de datos. Estos pueden ser entonces usados con sintaxis SQL, proporcionando un rendimiento muy rpido. Velocis admite interfaces para lenguajes ClC++, Java, Visual Basic, Delphi, Perl, as como la interfaz ODBC estndar en la industria. Birdstep vende el producto Velocis como una edicin servidor del Raima Data Engine. Hay una Mobile Edition complementaria para su uso en dispositivos porttiles con conectividad inalmbrica. Una tercera edicin est enfocada a aplicaciones incorporadas.
Arbor Software (www.hyperion.com)

Arbor fue uno de los primeros lderes en el desarrollo de bases de datos y herramientas de procesamiento en conexin analtico (OLAP, Online Analytic Processirig). El servidor OLAP insignia Arbor de Essbase se introdujo por primera vez en 1992 y fue el pionero en muchas capacidades que tienen ahora un lugar en los sistemas analticos. Las grandes corporaciones utilizan normalmente el conjunto de productos Essbase para crear infonnes integrados, anlisis y sistemas de planificacin. Las versiones actuales del producto Essbase admitenprocesamiento e informes analticos cliente/servidor y basados en Web. Tambin admiten datos precalculados (una caracterstica propia de la mayora de sistemas OLAP) y clculos dinmicos sobre la marcha. Otra mejora principal del producto Essbase es la capacidad OLAP distribuida, la cual permite a las bases de datos LAP ser divididas entre la red de computadoras. Essbase admite sus propios formatos de bases de datos mul-
Computer Associates (www.cai.com)

Computer Associates (CA) es una de las compaas de software independiente mayores en el mundo. Inicialmente centrada en software para grandes sistemas,
-'
950
Apndice B: Perfiles de los fabricantes de bases de datos
951
la compaa ha expandido continuamente su enfoque para proporcionar una extensa lnea de productos y servicios de software para el procesamiento de datos empresariales. CompUler Associates se ha construid~ principalme~te mediante la adquisicin, aprovechando sus grandes ventas dIrectas y relacIOnes bien establecidas con ejecutivos de sistemas de informacin senior Fertuoe 500. Mediante sus adquisiciones ha agregado de forma continuada ms pro~ duetos a su catlogo. lngres, uno de los primeros sistemas de bases de datos relacionales que aparecieron en el mercado, es ahora un producto de Computer Associates. Se desarroll originalmente en la Universidad de California de Berkeley como un proyecto de investigacin, bajo la direccin del profesor Michael Stonebreaker. El proyecto de investigacin se convirti en la fundacin de una compaa independiente, que finalmente cambi su nombre al de logres Corporation en los aos ochenta. logres y su lenguaje de consulta nativo QUEL fueron un competidor inicial de SQL, que fue superado por su rival Dracle Corporation. Aunque la mayora de los analistas afirmaron el claro liderazgo tcnico de Ingres, los esfuerzos de marketing y ventas agresivas de Oracle, junto con el apoyo de IBM a SQL, dieron finalmente a SQL el dominio del mercado. Finalmente, Ingres se adapt para admitir SQL, que emergi6 como el estndar dominante. En los aos noventa, logres fue vendida al grupo ASK y finalmente a Computer Associates. La versin actual del producto, Advantage lngres Enterprise Relational Database, es un amplio lote de productos de gestin de bases de datos relacionales. El ncleo Ingres/SGBD se ha aumentado mediante una capacidad que vincula el SGBD a la Web. El producto incluye acceso ODBC basado en estndares, un gestor de datos distribuidos sofisticado y soporte XML incorporado. Se ejecuta sobre la mayora de plataformas de servidor UNIX y versiones del servidor Windows. Computer Associates tambin ofrece Jas mine Object Database, un nuevo SGBD orientado a objetos. Aunque anunciado como una soluci6n SGBD completa con una moderna arquitectura orientada a objetos, las dos reas pri~cipa les de Jasrnine son las aplicaciones multimedia e Internet. El ncleo del SGBD est fuertemente orientado a objetos, y muestra caractersticas de herencia mltiple, ejemplares y mtodos y propiedades de las clases, y mtodos de conjuntos. Los mtodos para el SGBD orientado a objetos de Jasmine se pueden escribir en C, C++ o Java. Jasmine incluye una extensa librera de clases con soporte para tipos de datos multimedia (imgenes, secuencias de animacin, audio, vdeo, texto enriquecido y diseo de pginas). CA est claramente posicionando a Jasmine como una nueva generacin de bases de datos puramente orientada a objetos. No est posicionada para tener capacidades relacionales orientadas a objetos y no ofrece ningn acceso SQL a sus propias capacidades de gestin de datos. CA persigue la integracin de lasmine con bases de datos relacionales dorsales (Oracle, Sybase, Informix, SQL Server, DB2) y archivos de grandes sistemas (VSAM y CA-IDMS). El vnculo a un dorsal Ingres es especialmente estrecho, con gestin de transacciones integrada fuertemente, seguridad y gestin de rplicas.
Computer Corporation of America Iwww.cca-int.com)

Computer Corporation of America (CCA) es una de las compaas pioneras de software y ha estado implicada en la gestin de datos desde su fundacin en 1965. Desarrolla y vende uno de los primeros sistemas SGBD: Model 204. El producto se ha mejorado sustancialmente con los aos, pero el foco contina siendo los grandes sistemas. Model 204 contiene una interfaz SQL de acuerdo con ANSI, incluso aunque la estructura subyacente sea una arquitectura de base de datos en red. La estructura de red se manifiesta en la capacidad de tablas incorporadas de Model 204 (esencialmente una estructura tabla dentro de una tabla). Aunque las bases de datos en red perdieron su vigencia con la llegada de SQL y el modelo relacional, algunas de las mismas capacidades proporcionadas por los sistemas en red estn ahora apareciendo en los nuevos sistemas relacionales orientados a objetos. La estructura de tabla anidada ofrecida por Model 204 es un ejemplo de dicha capacidad, que aparece en sistemas relacionales orientados a objetos de lnformix y en extensiones orientadas a objetos Oracle8 de Oracle. . La versin actual de Model 204 incluye opciones de consulta en muluprocesador y en paralelo para aplicaciones de almacn de datos. Con los aos, estas estructuras de ndices se han vuelto bastante sofisticadas y ahora incluyen mapas de bits, asociaciones, rboles B y esquemas de listas de registros. Otra caracterstica nica de Model 204 es el soporte para consultas iterativas (consultas que se llevan a cabo con los resultaoos de consultas previas). El acceso basado en SQL a bases de datos Model 204 de grandes sistemas est disponible mediante el producto Connect* de CCA, el cual ofrece ODBC y API OLE-DB para acceso a bases de datos remotas desde Windows y estaciones de trabajo cliente basadas en UNIX. CCA tambin proporciona System 1032, un producto de bases de datos de alto rendimiento para el sistema operativo OpenVMS (el sucesor del popular V~XJ VMS de Digital Equipment de los aos ochenta y noventa). System 1032 est onentado a aplicaciones de consulta de alto rendimiento. Aunque no es originalmente para bases de datos relacionales, ofrece acceso mediante ODBC y SQL.
Empress Software Iwww.empress.com)

Empress Software produce un sistema de bases de datos relacionales ANSI SQL para aplicaciones incorporadas. La compaa fue fundada en 1979 en Tronto, Canad, y actualmente sus oficinas centrales estn en Washington De. Los SG~? de Empress ofrecen interfaces API ODBC lIamables y SQL incorporado. Tamblen ofrece un conjunto de bajo nivel de llamadas para acceso a bases de datos que estn bajo la capa de acceso SQL. Estas llamadas proporcionan acceso d~recto .a la capa de gestin de almacenamiento de Empress para operaciones .d~ msercln, actualizacin, borrado y recuperacin de registros de muy alto rendimiento: El SGBD de Empress se ejecuta en muchos sistemas basados en ~ dlfe.rentes, incluyendo varios soportes para Windows, Windows NT y ~na .sene ?e SIstemas operativos en tiempo real utilizados normalmente para aplIcaCIOnes mcorpo-
952
953
radas. Ofrece una rica coleccin de tipos de datos ms funciones y procedimientos definibles por el usuario. Para las aplicaciones basadas en Internet, Empress tambin ofrece interfaces para lenguajes de secuencias de comandos para los lenguajes de secuencias de comandos Perl y Tclrrk.
tienen su operacin no necesita mantenimiento, adems de una arquitectura ampliable. Se proporcionan interfaces OnBC 3.0 y JDBC. Los productos de la compaa complementan el ncleo de SQLBase ofreciendo algunas herramientas de desarrollo software, escritura de informes, conectividad a bases de datos de gran~ des sistemas y capacidades similares.
eXcelon (www.exln.coml Hewlett Packard (www.hp.coml

eXcelon fue fundado como bjecl Design, uno de los primeros fabricantes de bases de datos basadas en objetos en 1988 en BurlinglOn, Massachusetts (Estados Unidos). La versin inicial de su sistema de bases de datos orientado a objetos
ObjeclStore fue lanzada en 1990. La base de dalos ObjeclSlore se puede utilizar como una base de datos orientada a objetos independiente (BDOO) o como una solucin con cach proporcionando un acceso rpido y orientado a objetos a los datos que se han obtenido de una base de datos relacional frontal tal como Gracle oDB2. En los ltimos aos de los noventa, cuando el mercado de bases de datos orientadas a objetos se atasc, Object Design invirti en un producto XML de bases de datos, llamado eXcelon, y finalmente adopt el nombre de este producto en febrero de 2000. Despus de ms o menos un ao, la compaa asegur su base instalada de clientes bjectStore volviendo a crear una divisin Object Design, responsable de la lnea de productos ObjectStore, que permanece como un producto principal de la compaa en la actualidad. En mayor de 2001, eXcelon ampli de nuevo sus ofertas con C-bridge, una compaa de servicios profesionales. En la actualidad sus productos incluyen la BDOO ObjectStore, una base de datos XML denominada XIS, un producto de cach de datos de servidores de aplicaciones denominado lavlin y servicios profesionales para el desarrollo e implantacin de soluciones basado en estas tecnologas.
Gupta Technologies (www.guptaworldwide.coml

Gupta Technologies fue fundado por un antiguo gestor de la divisin de microcomputadoras de Oracle, Umang Gupta. El nombre inicial de la compaa estaba enfocado como un SGBD y herramientas de desarrollo de bases de datos y redes de rea local para Pe. Cambiado el nombre a Centura Software en los ltimos aos de los noventa, la compaa ha vuelto a su nombre original y ahora se enfoca en software y herramientas de desarrollo para bases de datos incorporadas, principalmente enfocadas en fabricantes de software independientes y VAR. SQLBase, El producto SaBD estrella de la compaa ha evolucionado considerablemente desde sus orgenes como una base de datos independiente y clientel servidor para mM PC bajo MS-DOS. Ha crecido para incorporar Windows NT y NetWare como servidores de bases de datos. Centura actualmente est enfocado en SQLBase para aplicaciones para dispositivos pe y sub-PC tales como los PC de mano, el hardware de informacin basado en tecnologa RISC (por ejemplo, telfonos inteligentes) e incluso tarjetas inteligentes. Deja una pequea huella y
Los productos de bases de datos SQL NonStop de Hewlett-Packard son resultado de su unin con Compaq en 2002. Varios aos antes, en 1997, Compaq (en esa poca un fabricante de PC y servidores con arquitectura Intel) adquiri Tandem Computers, uno de los primeros lderes en el mercado de sistemas de computadoras tolerante a fallos. Muchos sistemas Tandem son utilizados por servicios financieros y compaas de transporte para el uso en aplicaciones de procesamiento de transacciones interactivas que demanda una operacin sin interrupciones 7 das a la semana y 24 horas al da. Por ejemplo, los sistemas Tandem ejecutan muchas de las redes ATM de los principales bancos y muchas de las bolsas principales. Los sistemas anteriores de Tandem se ejecutaban en el sistema operativo TXP privativo y las aplicaciones tolerantes a fallos normalmente se escriban en el lenguaje de aplicaciones de Tandem (Tandem Applicarion Language, TAL). Los sistemas Tandem ms recientes se basan en sistemas operativos UNIX. La gestin de las bases de datos para aplicaciones sobre sistemas Tandem ha sido proporcionada por muchos aos mediante un SGBDR desarrollado por Tandem basado en SQL, llamado NonStop SQL. Debido al gran nfasis OLTP de Tandem, NonStop SQL ha sido el pionero en varias tcnicas especiales tales como los discos en espejo. Tambin aprovecha la arquitectura multiprocesador inherente de Tandem y proporciona capacidades de bases de datos distribuidas. La interfaz de programacin para NonStop SQL es mediante SQL incorporado. Durante los aos ochenta y principios de los noventa, virtualmente todo fabricante de minicomputadoras tena su propia implementacin basada en SQL privativo (Digital con RdbNMS, Hewletl-Packard con Allbase/SQL, Data General con DG-SQL, etc.). Con los aos. el resto de fabricantes de sistemas ha llegado a la conclusin que el alto coste en el mantenimiento de sus SGBDR con caractersticas competitivas era prohibitivo. Tambin tenan dificultad en gestionar las funciones duales de competir con fabricantes SGBD independientes (tales como Oracle) y trabajar con ellos como compaeros ISV en sus plataformas. Como consecuencia, Hewlett-Packard (mediante su adquisicin de la antigua lnea de productos Tandem) es el nico fabricante principal de sistemas que permanece (excepto IBM) con sus propio SGBDR basado en SQL privativo. NonStop SQL es todava un producto importante para la base de clientes Tandern. Ha lanzado dos versiones. NonStop SQL MP es un sistema de bases de datos distribuido y altamente paralelo, diseado para ejecutarse en sistemas con 2 a ms de 4.000 procesadores. NonStop SQL MX es una versio NonStop SQL extendida con capacidades relacionales orientadas a objetos.
954
Apendice B: Perfiles de los fabricantes de bases de datos
955
IBM Corporation (www.ibm.com)

lBM, la mayor compaa de computadoras del mundo, tambin est entre los mayores fabricantes de software. Los investigadores de IBM fueron los pioneros en el concepto de base de datos relacionales, inventaron el lenguaje SQL y produjeron el primer prototipo de base de datos relacional (System/R) en los aos setenta. En las siguientes dos dcadas, la base de datos relacional lder de IBM (DB2) para sus grandes sistemas promovi varias capacidades relacionales que han abierto el camino a los productos de lderes SGBDR y a generaciones de estndares SQL. En este mismo tiempo, la tecnologa de bases de datos relacionales se desarroll sobre plataformas de sistemas de computadoras IBM, incluidos grandes sistemas de tiempo compartido, minicomputadoras, estaciones de trabajo y servidores basados en UNIX y computadoras personales. En los ltimos noventa, IBM se movi agresivamente para traer todos estos productos de gestin de datos IBM bajo un nico paraguas (utilizando el nombre OB2-Universal Database) y para ofrecer su tecnologa de bases de datos relacionales DB2 a plataformas no JBM de otros fabricantes lderes del sistema UNIX. Adems de su propio desarrollo de bases de datos, IBM expandi su alcance de b~ses de datos sustancialmente, con la adquisicin en 200 l de los negocios relacIOnados con las bases de datos de Informix Software. Informix ha sido pionero de los SOBD basado en UNIX, con su producto estrella Informix desarrollado internamente. 1nformix tambin ha sido un voraz fagocitador de otras compaas y tecnologas de bases de datos, incluidos la pionera de bases de datos relacionales orientadas a objetos IIlustra (I996) Yel pionero de las bases de datos Java Cloudscape (1999). Muchos de estos productos de bases de datos sobreviven como parte de la lnea de productos de software de gestin de datos. En la actualidad, DB2-Universal Database es un sistema de bases de datos relacional basado en SQL completo y empresarial. Las implementaciones DB2 se ejecutan en un amplio rango de plataformas, desde computadoras personales a las mayores agrupaciones de grandes sistemas 1BM. DB2 se puede considerar una implementacin SQL bastante completa y amplia, especialmente en aspectos que han sido baluartes tradicionales de IBM, tales como gran disponibilidad, fiabilidad, mantenibilidad y soporte mundial (conjunto de caracteres internacional). Los productos adjuntos y herramientas admiten desarrollo de software para soporte de herramientas, capacidades de bases de datos distribuidas, almacenes de datos, rplica y distribucin de datos y la mayora de reas de la actividad de bases de datos. Aunque IBM ha hecho que sus productos estn disponibles sobre plataformas no IBM, la gran mayora de instalaciones de IBM DB2 se dan sobre s.isten:as de computadoras IBM y se venden como parte de los sistemas empresanales mtegrados basados en IBM, y la fuerza del ncleo de DB2 est en los arandes
sis~asDB2. ~
de datos Red Brick proporciona un servidor de inteligencia de negocios especializado, pero sus funciones coinciden considerablemente con las herramientas Bl y OLAP de la lnea de producto DB2. UniVerse est enfocado en la gestin de datos basada en cliente/servidor y web, con una baja sobrecarga de gestin, pero tambin con un considerable solapamiento con otros productos IBM. Finalmente, es de notar que IMS (una base de datos jerrquica no SQL cuyo origen es anterior ai modelo relacional) permanece como un producto IBM de gestin de datos muy importante, con desarrollo continuado.
Informix Software (vase IBM Corporation)

Informix fue uno de los lderes originales en el mercado de bases de datos relacionales basadas en UNIX. El primer SaBD relacional de la compaa se implement sobre sistemas de microcomputadoras basados en UNIX a principios de los aos ochenta, y se conoca por su eficiencia y compacidad. En 1985, Informix fue reescrito como un SGBD basado en SQL e introducido como lnformix-SQL. Fue posteriormente pasado a un amplio nmero de sistemas, desde PC mM bajo MS-DOS a grandes sistemas AmdahI que se ejecutan sobre UNIX. lnformix fue tambin uno de los primeros fabricantes de bases de datos en expandir sus ofertas de productos ms all del motor de la base de datos para incluir herramientas de desarrollo. Su familia de productos Informix-4GL incorpora l desarrollo de aplicaciones interactivas basadas en formularios. A principios de los aos noventa Informix expandi su lnea de productos al rea de la automatizacin de oficinas, incluyendo entre otros productos una hoja de clculo integrada con una base de datos denominada Wingz. Este esfuerzo no fue muy satisfactorio ante la monstruosa familia Oflice de Microsoft, e Informix cambi sus capacidades bsicas de la base de datos. Uno de sus productos principales durante la mitad de los aos noventa fue Informix Parallel Server, la tecnologa lder en la llamada tecnologa de consulta en paralelo. Parallel Server divide el procesamiento de una nica consulta compleja en varias operaciones paralelas, que pueden aprovechar los servidores de multiprocesamiento simtrico (SMP). Posteriormente, Informix estableci una posicin lder en la tecnologa relacional orientada a objetos mediante la adquisicin de Ilustra. Ilustra era una arriesgada empresa de software de bases de datos, liderada por Michael Stonebreaker (el mismo profesor de Berkeley que haba liderado el desarrollo de Ingres aos antes). Un efecto colateral de la adquisicin de Ilustra fue la proliferacin de lneas de productos y equipos de desarrollo en Infonnix, lo que supuso alguna confusin entre los clientes de lnformix. Cuando el mercado de bases de datos empresariales se convirti en una carrera con tres caballos en los ltimos aos noventa, Informix se encontr como un competidor mucho ms pequeo que los tres grandes (Oracle, IBM y Microsoft). Los recursos de Informix tambin se dividieron entre sus negocios de gestin de datos originales y un negocio emergente y de mayor crecimiento en herramientas de integracin de datos empresariales. lnformix vendi la parte de bases de datos de su negocio a IBM en abril de 2001, por ms de 1.000 millones de euros.
_ El pionero en SaBD relacionales orientados a objetos, Hlustra, sobrevive en la lmea de productos de IBM como Informix Dynamic Server, y mantiene una cuota de mercado significativa sobre sistemas basados en UNlX. El producto Cloudscape est disponible en mM, y se distingue como una base de datos completamente Java adecuada especialmente para aplicaciones de informtica porttil. El almacn
956
saL. Manual de referencia
957
La parle de la integracin de datos del negocio se denomin AscentiaI Software y contina siendo un foco en ese mercado.
Microsoft Corporation (www,microsoft.comJ

Microsoft Corporation, la compaa de software para computadoras personales mayor del mundo, es tambin un fabricante principal en el mercado de bases de datos basadas en SQL. La primera incursin de Microsoft en los productos de bases de datos vinieron en 1987 y comenz como un movimiento defensivo. Con el anuncio de OS/2 Extended Edition, IBM intent establecer una gestin de bases de datos incorporada y comunicaciones de datos como componentes claves de un sistema operativo pe de clase empresarial. En 1988, Microsoft respondi con SQL Server, una versin del SGBD Sybase pasado a OS/2. Aunque Microsoft posteriormente abandon OS/2 a favor de su propio sistema operativo Windows NT, SQL Server contina como su SGBD principaL En la actualidad, SQL Server es un producto principal en el segmento de bases de datos para grupos de trabajo, y Microsoft se est moviendo de forma agresiva para establecerse como un SGBD de clase empresarial en competencia con Oraele y DB2. A partir de su experiencia previa con SQL Server, Microsoft se movi en otros frentes para expandir sus funciones como fabricante de bases de datos. A principios de los aos noventa, Microsoft adquiri Foxbase Corporation, desarrollador del SGBD Foxbase. Foxbase se haba establecido como un clan muy satisfactorio de dBASE, el producto de bases de datos ms popular y utilizado en PC. Mediante la adquisicin, Microsoft desafi a Bodand Intemational, que haba adquirido los derechos de dBASE poco antes. Mientras que la adquisicin de Foxbase se enfoc ms en la base instalada de pe y el mercado relativamente maduro de las bases de datos para PC de archivos planos y basados en caracteres, el desarrollo interno de Microsoft se centr en el nuevo mercado creciente de bases de datos relacionales ligeras para PC con capacidades grficas. Despus de varios desarrollos de prototipos iniciales no fructferos, se lanz el nuevo producto resultado, Microsoft Access. Microsoft contina en la actualidad como un producto de bases de datos ligero independiente y como un pilar para bases de datos de produccin basadas en SQL. Microsoft tambin se movi de forma agresiva para habilitar a Windows corno una plataforma de acceso y desarrollo de bases de datos. Su primer movimiento importante en esta rea fue la introduccin de Open Database Connectivity (ODBC), un acceso a bases de datos para API basada en SQL. Microsoft construy la capacidad ODBC en Windows y foment con xito el grupo SQL Access Group, una asociacin de fabricantes de bases de datos, para adoptarlo corno un estndar de API llarnable para bases de datos. Esta primera versin de ODBC se construy finalmente sobre los estndares ISO formales y CL! (SQL CaU-Level Interface). Microsoft ha continuado evolucionando ODBC y expandiendo sus capacidades. .
I
l'
Microsoft tambin ha construido otras API de acceso a bases de datos sobre ODBC. El primer paso fue incorporar acceso de base de datos en el entorno OLE (Object Linking and Embedding) de Microsoft para vincular aplicaciones entre s. La parte OLElDB de la familia OLE proporcion acceso a los datos independientes del origen y confi en ODBC como su arquitectura subyacente para trabajar con bases de datos relacionales. Posteriormente, con el nuevo papel de OLE en el entorno de componentes ActiveX, se agreg otra capa a la jerarqua de acceso a la base de datos. El conjunto de componentes Active Data Objects (ADO) proporciona acceso a los datos en la arquitectura Component Object Model (COM) de Microsoft. De nuevo, las capacidades ADO estn en la capa superior de ODBC para el acceso a bases de datos relacionales. En paralelo con la evolucin de la capacidad de acceso a bases de datos Windows, Microsoft se ha expandido de forma continuada y ha mejorado las capacidades de SQL Server. SQL Server 7, introducido en 1998, supuso un paso adelante importante. SQL Server 2000 continu esta tendencia y trajo un marketing paralelo para establecerlo como un producto de bases de datos de clase empresarial. Las caractersticas de SQL Server han crecido para incluir un servidor OLAP integrado y capacidades de informacin de negocios, poniendo a Microsoft en competicin con los fabricantes de almacenes de datos y las capacidades de bases de datos orientadas a almacenes de datos de Orac1e y DB2. El paquete superior Enterprise Edition proporciona agrupaciones de conmutacin por error, soporte multiprocesador de sistemas SMP hasta de 32 vas y servicios de rproduccin mucho ms extensivos para bases de datos distribuidas en lnea y sin conexin y, ms recientemente, soporte XML como parte de la iniciativa de servicios Web en .NET de Microsoft. El debate sobre la disponibilidad de SQL Server para la gestin de datos empresariales contina, pero Microsoft sigue trabajando, versin a versin, hacia ese objetivo.
MySQL AB (www,mysq/.comJ
MySQL AB es una compaa sueca que publica y distribuye la base de datos SQL de cdigo abierto ms popular, MySLQ. Fundada por dos suecos y un finlands (David Axmark, AlIan Larsson y Monty Widenius), la misin de la compaa es hacer la gestin superior de datos disponible para todos. La compaa pertenece principalmente a sus socios fundadores y tiene el objetivo flrme del modelo de fuente abierta. El software MySQL, incluido el cdigo fuente, est disponible para su uso no comercial bajo una licencia GNU. Los socios han hecho crecer MySQL como una compaa virtual, con empleados distribuidos por el mundo. La compaa obtiene sus beneficios del soporte, formacin y otros servicios asociados con MySQL, as como de licencias comerciales. Se han descargado varios millones de copias gratuitas. El producto MySQL se distingue por tener un tamao bastante pequeo y ofrecer un gran rendimiento. Las capacidades del producto continan creciendo con una base activa de usuarios que contribuye a las mejoras. Monty Widenius, el principal autor del producto MySQL original, acta como moderador para las contribuciones y orquesta las versiones formales desde MySQL AB.
958
Apendice B: Perfiles de los fabricantes de bases de datos
959
Objectivity (www.objectivity.com)
Objectivity fue uno de los primeros fabricantes de bases de datos orientados a
o~jetos y ha mejorado d~ forma continuada su SGBDOO Objectivity/DB con los anos. Ha agregado capacldades tolerantes a fallos y de rplica de datos a su motor
de base de datos principaL Se proporciona acceso a Objectivity/DB desde C++. Java y SmallTalk. Aunque Objectivity sigue firmemente centrada en una arquitectura orientada a objetos, se ha movido para proporcionar acceso basado en SQL l su motor de bases de datos orientadas a objetos, mediante ODBe y API propietarios. El lenguaje SQL utilizado mediante estas interfaces contiene muchas extensiones para adaptar el acceso a las estructuras de bases de datos objeto. Los identificadores de objetos en la base de datos Objectivity/DB se asocian automticamente con identificadores de filas disponibles mediante la interfaz SQL. Las asociaciones de objetos en ~~OO estn disponibles para su uso como un criterio de reunin SLQ. Los procedimientos almacenados y disparadores se presentan mediante caractersticas SQL extendidas. La sintaxis SQL extendida tambin se proporciona para acceder a los elementos de arrays y estructuras de objetos anidadas, que aparecen como columnas complejas para el usuario SQL. Estas capacidades proporcionan ventajas de acceso basado en SQL a muchas capacidades orientadas a objetos de ObjectivitylDB, pero a expensas de una sintaxis SQL muy fuera del estndar. El pr~ducto ObjectivitylDB est centrado en la gestin de datos complejos en una ampho ra~go de entornos operativos. Est implantado en grandes bases de datos empresanales y proporciona a cientos de usuarios acceso a terabytes de datos. En el otro extremo, .ObjectivitylDB est posicionado como un componente incorporable para la gestin de datos en sistemas de ti~mpo real.
Oracle Corporation (www.oracle.com)

Oracie .Corporatio.n fue el primer fabricante SOBD en ofrecer un produclO SQL comercIal, precedIendo al propio anuncio de IBM en casi dos aos Durante los aos oc:.henta, Oracle creci para convertirse en el mayor fabricante de SGBD independIente. En la actuali~ad es el co~petidor de SGBD empresarial dominante, y vende ~us productos mediante un eqUIpo de ventas directo, agresivo, adems de una sene de canales adicionales. El SGBD de Oracle se implement originalmente en rninicomputadoras Digital, pero el centro de gravedad de las ventas del sistema OracIe se traslad a minico.mp.utadoras ba~adas en UNIX y a servidores en los aos noventa. Una de las p.nnclpales ventajas de Oracle es su portabilidad. Est disponible en docenas de s~stema~ de computadoras diferentes, desde porttiles basados en Windows medIant: SIstemas basados en Sun, HP y sistemas IBM basados en UNIX hasta gran?es sistemas. IBM. Mediante el uso de software de red Oracle, muchas de estas ImplementaCIOnes Oraele pueden participar en una red distribuida de sistemas Oraele. Con e~tas capacidades Oracle ha conseguido implantaciones de bases de datos en el mbIto empresarial y ha sido efectivo en mantener su posicin lder en el
mercado como un estndar de bases de datos corporativas impuesto por el departamento de sistemas de informacin en muchas organizaciones. Oracle SGBD estaba basado originalmente en el prototipo SystemIR de IBM y ha permanecido generalmente compatible con productos basados en SQL de IBM. En los ltimos aos, Oracle ha realizado un marketing agresivo del rendimiento OLTP de su SOBO, utilizando resultados de las pruebas para sistemas multiprocesador para dar sustancia a su reivindicacin como lder en el rendimiento OLTP. Una serie de anuncios en las publicaciones industriales de informtica proclamaban un importante nivel de 100.000 TPC-C transiciones por minuto en una agrupacin de servidores SMP 64-bit Digital Alpha de altas prestaciones. Gracle ha combinado de forma coherente buena tecnologa con ventas agresivas y campaas de marketing de gran perfil (incluida la presencia de su flamante CEO y fundador, Larry ElJison). Ha expandido su lnea de productos para incluir no solamente software SGBD y herramientas de desarrollo y gestin de bases de datos, sino tambin software para aplicaciones empresariales orientado a aplicaciones financieras y de gestin del negocio. Los productos centrales de servidor de Gracle tambin incluyen un servidor de aplicaciones para implementar aplicaciones Internet de varias capas. Oracle tambin adquiri la base de datos relacional Rdb, de Digital Equipment Corporation, recogiendo una gran.base de usuarios Digital que se est convirtiendo a sus productos OracIe. Los ingresos en servicios de consultora y mantenimiento tambin representan una parte importante de sus beneficios. Tambin ha anunciado que har disponibles varios de sus productos de forma subcontratada, permitiendo a los clientes utilizarlos de una forma efectiva. En la actualidad, los beneficios de licencias SGBD son menos de la mitad de los beneficios anuales de Orac1e, pero la gestin de datos empresariales contina siendo el ncleo del negocio de la compaia. Oracle8 y Oracle8i, introducidos en 1998 y 1999 respectivamente, y Oracle 9i, introducido en el 2000, representaron unos pasos importantes en la evolucin del SGBD Oracle. Poseen capacidades extensivas relacionales orientadas a objetos, incluidos tipos de datos abstractos, estructuras de objetos (tales como tablas anidadas, arrays y secuencias), API Java (SQL incorporado para Java y API lIamable JDBC) y capacidades especializadas para un alto rendimiento OLTP sobre sistemas SMP y almacn de datos. Para adaptarse a un amplio rango de sistemas, continan proporcionndose capacidades SGBD de bajo nivel mediante el producto Oracle Light para sistemas porttiles. Gracle 9i est especialmente centrado en la integracin del SGBD Oracle con las tecnologas Internet, tales como servidores Web y de aplicaciones. Adems, el mercado para Oracle9i a ubicado un fuerte foco sobre la fiabilidad y escalibidad, de la que se dice que es irrompible. Oracle considera que Microsoft es su principal competidor y adopta una arquitectura de computadoras empresariales centrada en la red para combatir la vista centrada en PC de Microsoft. En la visin de OracIe, la forma del almacenamiento de datos fundamental es el sistema de base de datos centralizado para toda la informacin en una organizacin, que debera estar accesible en cualquier momento y en cualquier lugar mediante Internet. Un control central y una administracin ms sencilla proporcionada por esta arquitectura son los puntos de venta claves para Oracle en las organizaciones rs empresariales.
960
Apndice 8: Perfiles de los fabricantes de bases de datos
961
Oracle tambin est siguiendo de forma agresiva un enfoque de un fabricante para las tiendas empresariales de tecnologas de la informacin. Con la introduccin de los paquetes de aplicaciones de OracIe en los aos noventa, OracIe se convirti en un competidor para fabricantes de aplicaciones empresariales como SAP, BAAN y PeopleSofl. La adicin del servidor de aplicaciones Oracle puso a OracIe en competencia para servidores de aplicacin BEA y Sun, as como con WebSphere, de lBM. Con su conjunto de productos de aplicaciones, bases de datos y software intermedio, el mensaje de Oracle a organizaciones corporativas IT es que la mejor forma de desarrollar sus aplicaciones en sus compaas es con un enfoque todo-Orade.
Persisten ce Software (www.persistence.com)

Persistence Software estaba inicialmente centrada en un software que cubra el salto entre las tecnologas de desarrollo orientadas a objetos y de mensajera (incluyendo los agentes de solicitud de objetos) y la tecnologa de bases de datos relacional. Sus productos de software intermedio albergaban estructuras y solicitudes de gestin de datos basadas en objetos y las asociaban con bases de datos relacionales almacenadas en los sistemas SGBDR mayores. Uno de los mercados objetivos principales para los productos Persistence ha sido el de servicios financieros. Con el tiempo, Persistence mejor sus productos y los resitu con un servidor de aplicaciones transaccional. La familia de servidores PowerTier de la compaa incluye versiones diseadas para incorporar desarrollo C++ o Java (mediante Enterprise JavaBeans). Una de las caractersticas principales de los servidores PowerTier es la cach en memoria de objetos. Otras capacidades de los servidores incluyen el aislamiento de las transacciones de objetos y los disparadores de objetos. Los servidores continan ofreciendo independencia de la base de datos, integrndose con los motores de bases de datos empresariales principales de Gracle, Informix, Syase y Microsoft. Se incorpora desarrollo de aplicaciones en C++, Java y Visual Basic. Ms recientemente, Persistence ha vuelto a configurar su tecnologa cach y la ha empaquetado en dos productos distintos. Persistence Dynamai es un producto diseado para acelerar la bsqueda webdinmica, mediante la cach de las pginas Web generadas. Persistence EdgeXtend es una cach de datos para servidores de aplicaciones, diseada para acelerar sus operaciones en aplicaciones intensivas sobre bases de datos. Funciona con BEA WebLogic e IBM WebSphere.
desarroll Btrieve, fue adquirida en 1987 por Novell, el fabricante del sistema operativo para redes lder en esa poca (NetWare). Como resultado, Btrieve se convirti en una parte ms comprometida e integrada del sistema operativo NetWare. Las capacidades en capas, incluida NetWare SQL. fueron desarrolladas como capas en la parte superior del gestor de almacenamiento Btrieve. En 1994, Novell decidi volver a centrarse en las capacidades de su sistema operativo en red principal, y sus tecnologas en bases de datos se tradujeron en una nueva compaa, que se renombr como Pervasive Software en 1996. El foco de Pervasive est en las bases de datos basadas en SQL de cosle efectivo para su uso por ISV y VAR. El software empaquetado para comabilidad, control de inventario, procesamiento de pedidos y funciones similares lo utilizan como un gestor de base de datos empaquetado subyacente. Estos productos se venden normalmente a negocios de pequeo y medio tamao, as como a departamentos de grandes compaas. El producto actual de Pervasive, Pervasive SQL, combina sus productos Scalable SQL y Blrieve. Su importancia radica en sus decisivas caractersticas para el mercado de la pequea o mediana empresa. Esto incluye baja administracin de la base de datos, ampliacin para soportar volmenes de negocio, una pequea huella SOBO y la capacidad de gestionar volmenes razonables de datos a bajo precio. Pervasive SQL es usado de forma arrolladora por ISV o VAR y se reparte como un componente empaquetado de sus productos de software, frecuentemente invisible al usuario final.
PointBase (www.pointbase.com)
PointBase es el desarrollador y distribuidor de SGBn PointBase, una base de datos basada en SQL cien por cien Java. La compaa fue fundada en 1998 por Bruce Scott, quien ya haba tenido una carrera exitosa en el negocio de las bases de datos. En 1997, Scott fue uno de los fundadores de Oracle Corporation, responsable de la creacin de varias de las primeras versiones principales de Oracle. En 1984 cofund su segunda compaa exitosa de bases de datos, Gupta Technologies, con su producto SQLBase. Los productos PointBase se centran en permitir informtica porttil, con sus requisitos especiales (rplica y sincronizacin de datos), y proporcionar capacidades de base de datos en una huella en memoria muy pequea en el lado del cliente (por ejemplo, en dispositivos de mano). Para servir a este mercado PointBase se presenta en tres versiones. Una versin micro proporciona la menor huella y es apropiado para entornos muy restringidos, como dispositivos de mano con bateras. Una versin incorporada aumenta la huella para sistemas con una mayor memoria, pero en la que la base de datos est todava invisiblemente incorporada en la aplicacin. Una versin de servidor proporciona el dorsal.
Pervasive Software (www.pervasive.com)

Pervasive Software tiene sus races en los primeros das de las bases de datos para computadoras personales. El gestor de almacenamiento que subyace en los productos Pervasive, Btrieve, se desarroll inicialmente como una base de datos basada en PC para sistemas MS-DOS, en los primeros ochenta. SoftCraft, la c.ompaa que
PostgreSQL (www.postgresql.org)
La base relacional orientada a objetos Postgres tiene sus races en la Universidad de California, en Berkeley, cuna de la base de datos relacional pionera lngres.
962
Apndice 8: Perfiles de los fabricantes de bases de datos
963
Desde fines de los aos ochenta hasta irucios de los noventa, el profesor Michael SlOnehreaker y sus colegas trabajaron en la extensin del modelo relacional para incluir capacidades orientadas a objetos, generando los prototipos de Postgres. A mediados de los aos noventa, Stonebreaker utiliz los fundamentos de Postgres como base para IIlustra, un producto relacional basado en objetos. que finalmente se convirti en el producto principal de Informix, despus de que IIIustra fuera vendida a Informix. En paralelo, un grupo de expertos en bases de datos en Berkeley continu trabajando en Postgres, agregando capacidades SQL y distribuyndolo a la comunidad de investigacin corno PostgreSQL. Dadas sus races en la universidad, Postgres fue un ajuste natural para el movimiento de cdigo abierto y comenz a construirse a s mismo como una base de datos de cdigo abierto. PostgreSQLorg es la organizacin que finalmente se form para organizar y coordinar el desarrollo de PostgreSQL En la actualidad acta como distribuidor, mecanismo de sopone y limpieza para las distribuciones de PostgreSQL, a lo que contribuye una comunidad de usuarios creciente.
Quadbase Systems (www.quadbase.eom)
pe compatibles con IBM. Se ofert originalmente a principios de los aos noventa
Quadbase SQL es un sistema de base de datos cliente/servidor basada en SQL para
corno una base de datos DOS/Windows con una arquitectura de servidor de archivos. Desde entonces ha evolucionado en una base de datos cliente/servidor con soporte para servidores basados en NetWare, Windows y Windows NT. La implementacin Quadbase SQL tiene conformidad con ANSI SQL-92 en el nivel de entrada. Proporciona interfaces de SQL incorporado (para C, C++ y SmallTalk) y una API ODBC lIamable. Quadbase incorpora una serie de caractersticas SQL avanzadas entra las que se incluyen cursores y vistas desplazables y actualizables. Su control de concurrencia multiusuario ofrece la flexibilidad de varios niveles de aislamiento para equilibrar los requisitos de integridad de la base de datos, con especial atencin al rendimiento. Quadbase tambin alberga esquemas de slo lectura que permiten utilizarlo para crear y acceder a bases de datos de slo lectura sobre CO-ROM. En los ltimos aos, la compaa ha aumentado el nfasis en sus herramientas de grficos e informes y ha reducido se esfuerzo en sus productos de gestin de bases de datos.
Las optimizaciones en el sistema Red Brick incluyen alto rendimiento en la carga de datos, con capacidad de carga paralela para explotar sistemas SMP y transfonnacin de datos de alto rendimiento, limpieza y comprobacin de la integridad. El software Red Brick tambin permite preclculo automtico de valores de datos agregados (sumas, promedios, mnimos y mximos) durante el proceso de carga de la labIa. . El SGBO Red Brick tambin se centr en una implementacin de alto rendimiento de la estructura de esquema en estrella, frecuentemente encontrada en apljcaciones de almacn de datos. Su tecnologa STARindex, y la capacidad asociada STARjoin, implementa soporte para esquemas en estrella en la estructura de la base de datos misma. El SOBD tambin [jene como caracterstica ndices de mapas de bits adaptativos para una seleccin rpida de los datos de tablas muy grandes. Las extensiones SQL en el lenguaje RSQL gestionan estructuras de consultas tpicas para la toma de decisiones, tales como seleccionar los tres mayores o el percentil 95 de filas basndose en algunas medidas numricas. A pesar de su temprana introduccin en el mercado de almacn de datos y varios xitos tempranos en clientes, a Red Brick le result difcil mantener su xito inicial. Otros fabricantes de bases de datos mucho mayores, incluyendo Oracle Corporation, Sybase, IBM y finalmente Microsoft, vieron el almacn de datos como una oportunidad de mercado importante y anunciaron (algunas veces con un gran retraso en el lanzamiento) capacidades de almacenes de datos para sus lneas de productos. Aunque sus productos tenan ventajas tcnicas reconocidas, Red Brick vio que sus clientes decidan esperar a sus fabricantes SGBD actuales: ..L a compaa se vendi a Informix Corporation en 1998 y los produclos de geSUOn de bases de datos Informix se vendieron posteriormente a IBM.
Sybase, ne. (www.sybase.eom)

Sybase era una compaa de xito en la mitad de la dcada de los ochenta, ~undada con decenas de millones de dlares de capital de riesgo. El equipo fundaCIOnal de la compaa y muchos de sus primeros empleados provenan de otros fabricantes SGBD, y para muchos de ellos. Sybase representaba la segunda o tercera SOBD que construan. Sybase posicion de una forma bastante efecti:a su producto c~m.o el SGBD relacional para aplicaciones en lnea y puso el nfaSIS en las caractenstlcas tcnicas y de arquitectura que lo distinguan de productos SGBD basados en SQL de su poca. Entre estas caractersticas estn las siguientes: Una arquitectura cliente/servidor, con software de cliente ~jecut~ndos~ sobre estaciones de trabajo Sun y VAX y PC de 18M, y el serVidor eJecutandose sobre sistemas VAXNMS o Sun. Un servidor multihebra que administraba sus propias tareas de gestin y de entrada/salida para una mxima eficiencia. .. Una API para programacin, en lugar de la interfaz SQL incorporada uuhzada por la mayora de fabricantes SGBD de la poca.
Red Briek Systems (vase IBM Corporation)

Red Brick (cuyo nombre est basado en el edificio de ladrillo rojo donde se fund la compaa, en Los Gatos, California) fue uno de los primeros pioneros en el mercado de almacn de datos. Su fundador, Ralph Kimball, sigue siendo un experto reconocido en el almacn de datos. El ncleo de la oferta de la compaa es un SOBD basado en SQL que est fuertemente optimizado para aplicaciones de almacenes de datos..
964
965
Procedimientos almacenados, disparadores y un dialecto Transact-SQL que ampliaba SQL hacia un completo lenguaje de programacin para construir partes sustanciales de una aplicacin en la base de datos misma. Un marketing agresivo y un abanico de primera clase de inversores arriesgados hizo que los analistas industriales prestaran atencin a Sybase, pero fue un posterior trato OEM con Microsoft (el fabricante lder de software para pe) y AshlonTate (el fabricante de bases de datos para pe lder), lo que posicion a la compaa como un fabricante serio de SGBD. Redenominado como SQL Server, el SGBO Sybase se hizo penable a OS/2 (en aquella poca el sistema operativo futuro para pe estratgico de IBM y Microsoft) para que Microsoft lo distribuyese en sistemas informticos de otros fabricantes y Ashton Tate hiciese lo propio mediante canales de venta de ordenadores. Las ventas de la alianza nunca alcanzaron las primeras expectativas, pero impulsaron a Sybase en el mercado de los SGBD como un serio competidor. En la actualidad, SQL Server (varias generaciones despus) contina siendo el SGBD estratgico de Microsoft para Windows NT; Microsoft se ha separado de Sybase, buscando su propia ruta de desarrollo. Sybase contina siendo un fabricante SGBD principal, pero el impacto positivo de su alianza formativa con Microsoft se produjo hace mucho. Las innovaciones que hicieron a Syhase un producto nico en los ltimos aos de los ochenta fueron copiados ltimamente por otros fabricantes SGBD. El impulso inicial de Sybase ciment su posicin lder en los segmentos del mercado que demandaron OLTP de alto rendimiento, incluyendo especialmente aplicaciones para servicios financieros. Estas buenas posiciones perinanecen actualmente como los baluartes de Sybase. Durante los aos noventa, Sybase expandi su lnea de productos para incluir herramientas de desarrollo mediante una combinacin con PowerSoft, uno de los fabricantes lder de herramientas SGBD. Otras uniones y adquisiciones trajeron servicios de consultora y otras tecnologas de gestin de datos. La lnea de productos actual de Sybase tiene tres motores de base de datos distintos, centrados en tres segmentos diferentes del mercado de bases de datos: Sybase Adaptive Server IQ est centrado en almacenes de datos. Tiene como caracteristica las tcnicas de optimizacin de consultas complejas que reivindican mejorar el rendimiento en cien veces los SGBDR convencionales. SQL Anywhere est centrado en computadoras porttiles. Sus caractersticas son una pequea huella y un soporte integrado para clases y objetos Java, as como procedimientos almacenados Java. Sybase Adaptive Server Enterprise es el sucesor de los productos Sybase SQL Server, optimizado para cargas de trabajo OLTP. Sus caractersticas son estrategias de bloqueo flexible y mejoras en el rendimiento de las consultas. Junto con el servidor de aplicaciones Sybase, otros productos de software intermedio, herramientas de desarrollo de bases de datos. productos de mensajera y servicios de consultora, estas lneas de producto hacen de Sybase un proveedor de bases de datos de muchos cientos de millones de dlares.
TimesTen Performance Software (www.timesten.com)

TimesTen es una compaa de bases de datos con capital de riesgo centrada en repartir rendimiento ultra-alto en sistemas de bases de datos residentes en memoria. La compaa se form como un subproyecto de un proyecto de base de datos residente en memoria principal en Hewlett-Packard, y su tecnologa subyacente se ha lanzado como un componente incorporado en los sistemas de telecomunicaciones HP desde 1996. La versin TimesTen de la tecnologa inici su distribucin en 1998. Tiene cnmo caractersticas unas API ODBC y JDBC, y SQL estndar industrial, y se ejecuta en sistemas operativos servidores Windows y servidores basados en UNIX de HP, Sun Microsystems e IBM. La base de datos residente en memoria TimesTen est centrada en aplicaciones con grandes requisitos de rendimiento en sistemas de telecomunicaciones y comunicaciones de datos, aplicaciones Internet de alto volumen y aplicaciones de servicios financieros. Se ha implantado como un gestor de datos independiente en redes porttiles y aplicaciones de comunicaciones de datos. Tambin se ha utilizado como una cach de datos de alto rendimiento en dorsales de sistemas SGBDR basados en disco convencionales en aplicaciones Internet, y como una base de datos independiente para aplicaciones de bolsa y distribucin de datos del mercado. Para aplicaciones OLTP tpicas, el motor TimesTen aumenta al menos en diez veces (1.000 por ciento) el rendimiento de un SGBDR convencional con cach. TimesTen 4, la versin actual, admite direccionamiento de base de datos de 64 bits, y permite bases de datos residentes en memoria de diez gigabytes. Adems de sus caractersticas SGBDR, TimesTen ofrece capacidades de rplica de datos de N vas para configuraciones de alta disponibilidad y compartimiento de carga, y una capacidad de edicin de eventos. Los productos de bases de datos residente en memoria principal de la compaa se han medido con factores de transaccin que exceden los 10 millones de operaciones de lectura SQL (lectura basada en la clave principal) por minuto.
Versant Corporation (www.versant.com)

Yersant fue uno de los primeros fabricantes de bases de datos orientadas a objetos. Su primer producto, SGBDOO, se lanz en septiembre de 1990. La versin actual de su producto de base de datos ofrece interfaces Java, C++ y SmallTalk. El motor de base de datos orientada a objetos es multisesin y multihebra, y se ejecuta en plataformas Windows NT y UNIX. Una de las caractersticas que lo distinguen es su capacidad de tolerancia a fallos con conmutacin automtica por error. Como todos los fabricantes de bases de datos orientadas a objetos puras, Yersant inicialmente se present como un sistema SGBD de siguiente generacin, rechazando a los fabricantes relacionales y sus sistemas como una tecnologa anticuada. Ms recientemente, la compaa ha abierto su SGBDOO al mundo relacional mediante la familia Versant SQL, proporcionando acceso SQL y una API ODBe. SQL y una utilidad Interactive SQL correspondiente estn disponibles para servidores Versant sobre plataformas Solaris, AIX, HP-UX y Windows. Una versin
966
cach del producto Versant, denominada Versant enJin, proporciona una cach de datos orientada a objetos para su uso en conjuncin con servidores de aplicaciones basadas en J2EE. La filosofa de la familia Versant SQL es presentar tantas capacidades SGB. DOO en un modelo relacional como sea posible. Automticamente asigna el esquema de objetos de la base de datos Versant a un esquema SQL correspondiente: por ejemplo, transforma dos clases de objeto con relaciones muchos-a-muchos en dos tablas de base de datos y una tabla de interseccin para representar las relaciones. La informacin del esquema SQL est disponible mediante las vistas virtuales del catlogo SYSTABLES, SYSCOLUMNS y SY8INDEXES. Los punteros incorporados en el esquema del objeto se explotan de forma transparente para mejorar el rendimiento de las consultas. Adems de la interfaz mediante programacin (ODBC) e interactiva SQL, la familia SQL incluye herramientas de carga de datos y extraccin para trasladar informacin entre el SGBDOO Versant y los sistemas SOBDR convencionales.
APNDICE
Referencia de la sintaxis deSQL
El estndar de SQL ANSI/ISO especifica la sintaxis del lenguaje SQL usando una notacin BNF formal. Desafortunadamente, el estndar es difcil de leer y comprender, por varios motivos. En primer lugar, el estndar especifica el lenguaje de forma ascendente, en lugar de descendente, haciendo difcil obtener la imagen general de una instruccin SQL. En segundo lugar, el estndar usa trminos no familiares (tales como expresi6n-detabla y predicado). Finalmente, la notacin BNF en el estndar es muy profunda: proporciona una especificacin muy precisa, pero oculta la estructura relativamente simple del lenguaje SQL. Este apndice presenta una especificacin completa y simplificada en BNF para SQL estndar, como est implementado usualmente en los productos de la mayora de fabricantes de SOBD. En concreto: El lenguaje descrito se ajusta generalmente al requerido para el acuerdo en el"nivel de entrada del estndar SQL2," adems de las caractersticas de acuerdo en los niveles intermedios y completo que se encuentran habitualmenle en los productos SGBD principales. Se omite el lenguaje de mdulos porque se reemplaza virtualmente en todas las implementaciones de SQL por SQL incorporado o por una API SQL. Los componentes del lenguaje se referencian con los nombres comunes que se usan generalmente en la documentacin de los fabrican les de SOBD, en lugar de los nombres tcnicos usados en el estndar. La notacin BNF de este apndice usa los siguientes convenios: Las palabras clave SQL aparecen en caracteres
NO PROPORCIONAL. MAYSCULAS y CON FUENTE
Los elementos sintcticos se especifican en cursiva. La notacin lista-de-elementos indica un elemento o una lista de elememos separados por comas.
967
968

Elemento del lenguaje
demento-de/-tabla dejinicin-de-columna
Apndice C: Referencia de la sintaxis de SOL

Sintaxis
'969
Las barras verticales (1) indican una eleccin entre dos o ms elementos sintcticos alternativos. Los corchetes ([ ]) indican un elemento sintctico opcional encerrado entre ellos. Las llaves ({ }) indican una eleccin entre elementos sintcticos requeridos encerrados entre ellas.
restriccill-de-columna
Instrucciones de definicin de datos

Estas instrucciones definen la estructura de una base de datos, incluyendo sus tablas, vistas y los objetos especficos del SGBD que contiene:
CREATE TABLE tabla ( lista-elemelllos-def-rabla)
DROP TABLE rabia 1 opciones-de-eliminacill) ALTER TABLE
restriccin-de-tabla
unicidad
restriccin-c{ave-extemo ref-clave-externa
dejinicin-de-cofumna I restriccin-de-lObla columna tipo-de-dotos ( DEFAULT ( literal I USER I NULL ) l ( lislo-derestricciones-de-columno l CONSTRAINT nombre-dere.uriccin 1 { NOT NULL 1 unicidad I ref-clave-eXlerna I rest'"..:iun-de_ comprobacin } [ temporizacin.de-restriccin l CONSTRAINT nombre-de-restriccin l { unicidad J restriccin-c/ave-extema J restriccin-de-comproba. cin } [ temporiz.acin-de-restriccin J UNIQUE ( lista-de-columnas) I PRlMARY KEY ( fista-decolumnas) FOREIGN KEY ( lista-de-columnas) refclave-externa REFERENCES tabla 1 ( /ista-de-cofunmas) J [ MATCH FULL 1 PARTIAL l [ ON DELETE accin-ref J
CASCADE 1 SET NULL 1 SET DEFAULT I NO ACTION CHECK ( condicin-de-b.rqlleda) ( INITIALLY IMMEDIATE INITIALLY DEFERRED l ( [ NOT l DEFERRABLE I SELECT I DELETE 1 UPDATE [ ( listode-colllmnas) INSERT [ ( lista-de-columnas) CASCADE 1 RESTRICT
tabla acci611-de-modificaci/I
accin-ref restriccin-de-comprobacin lemporizocilI-de-reslriccin privilegio
CREATE VIEW vista ( ( lista-collmmas) AS especificacin-de-consulta [ WITH CHECK OPTION l DROP VIEW vista [ opciones.deeliminacin CREATE DROP ALTER
i
especijicacin-de-objeto-bd J
opciones-de.e/iminacin
tipo-de-objelo-bd nombre.deobjeto-bd [
tipo-de-objelo-bd [ opciones-de-eliminacin l tipo-de-objeto-bd acci/l-de-modificacin
Instrucciones bsicas de manipulacin de datos

La instruccin SELECT unitaria devuelve una nica fila de datos en un conjunto de variables del anfitrin (SQL incorporado) o variables de un procedimiento almacenado:
SELECT [ ALL DISTINCT l { lista-de-elementos-deseleccin INTO lista-de-variables FROM lista-de-referencios-o-tablas WHERE condicin-de-bsqlleda l
GRANT ( ON { TO { WITH
I lista-de-privilegios) tipo.de-ohjeto-bd nomhre-de-objeto-bd } PUBLIC I lista-de-IlSllarios} GRANT OPTION l

ALL PRIVILEGES
tabla
REVOKE { ALL PRIVILEGES I lisla-de-privifegias) ON { tabla I tipo-de-objeto-bd nombre-de-objeto-bd } FROM { pUBLle I lista-de-usuorios} WITH GRANT OPTION ]
I .. }
Las palabras clave usadas para especificar objetos de la base de datos (tipode objeto-bd) dependen del SOBD especfico. Los objetos de la base de datos normales con privilegios asociados son TABLE, VIEW, SCHEMA, PROCEDURE, DOMAIN, INDEX, y las reas de almacenamiento con nombre, mantenidas por el SOBD. La sintaxis SQL usada para especificar estos objetos es caracterstica del SOBD que los alberga. El conjunto especfico de acci6n-de-modificaciones que se permiten es tambin especfico del SGBD y del tipo de objeto. Los elementos del lenguaje usados en las instrucciones CREATE, DROP, ALTER, GRANT Y REVOKE son:
La instruccin SELECT interactiva devuelve cualquier nmero de.filas de datos en una sesin SQL interactiva (la devolucin de varias filas en SQL incorporado O en procedimientos almacenados requiere instrucciones basadas en cursores):
SELECT [ ALL 1 DISTINCT l { listade-elementos-de-seleccin INTO lisla-devariables-def.onfitrin FROH /ista-de-referellcias-a.rablas WHERE condicin-de-bsqueda ) GROUP BY lista-dereferencias-a-co[lImnas HAVING condicinde-blsqueda l ORDER BY lista-de-elementos-de-ordenacin
I .. )
970
Apndice C: Referencia de la sintaxis de SQL
971
Estas instrucciones modifican los datos de la base de datos:

INSERT INTO tabla
{ VALUES (
La especificacin de una consulta bsica tiene la forma:

SELECT [ ALL
[ ( /ista-deco/umnas ) lislO-de-elememos-a-insertar )
)
J
DISTINCT
{ lista-de-dementos-de-sefeccin
expresin-de-consulUl
FROM
lisla-de-re/erencias-o-tablas WHERE condicin-de-bsqueda l
DELETE FROM tab/e UPDATE
( WHERE condicin-de-bsqlleda ] [ WHERE cOlldic,in-de-bsquedo
GRQUP BY /islade-rejerencias-a-columna l HAVING condicin-de.bsqueda l
tabla SET lis/a-de-asignacin
Instrucciones de procesamiento de transacciones

Estas instrucciones emiten la seal del fin de una transaccin SQL:
COMMIT [ WORK 1 [ WORK
Las referencias a tabla (lista-derejerencias-a-tablas) de la clusula den ser:
FROM
pue-
ROLLBACK
Instrucciones de cursores
Estas instrucciones de SQL para programacin permiten la recuperacin de datos y la actualizacin posicionada:
DECLARE cursor [ SCROLL } CURSOR FOR upresill~de~consulta [ aRDER BY ljsta~de~efementos-deordellacin 1 [ FOR { READ ONLY I UPDATE [ OF lis/a-columnas] } 1 OPEN cursor CLOSE Cllrsor
Una referencia simple a tabla, que consista en un nombre de tabla (posible~ mente calificado). Una referencia derivada a tabla. que consista en una subconsulta (vase el texto que sigue) que produce como resultado una tabla. No todas las marcas de SGBD permiten que aparezcan subconsultas que devuelvan tablas en la clusula FROM. Una referencia a tabla reunida (vase el texto que sigue) que combine datos de dos o ms tablas usando operadores relacionales OUTER JOIN, INNER JOIN o cualquier operador de reunin. No todas las marcas de SOBD permiten que aparezcan especificaciones de reunin en la clusula FROM. Las tablas reunidas se especifican de acuerdo con el estndar SQL2, como sigue; en la prctica, hay una gran variaci6n en los tipos especficos de reuniones albergadas en marcas de SGBD, en concreto, y en la sintaxis usada para especificar varios tipos de reunin:
Tipo de nuni6n
tabla~reunida
Sintaxis
relmi6n-inlema I reunin-uterna 1 reunin~de~unin I reunin~cruzada I ( tabla-reunida) referencia-o-tabla [ NATURAL ] [ INNER } JOIN referencia~a tabla I [ INNER l JOIN referencia-a.tabla { especijicacin.de-reunin 1 referencio.~a~tabla ( NATURAL l (LEFT I RIGHT I FULLj
OUTER JOIN referencia~a~/abfa I [LEFTI RIGHTI FULL) OUTER JOIN
reunin-in/ema
FETCH [ [ dir-bsqueda l FROM l
cursor INTO
lista~de~variables
referellcia-a~tabla
DELETE FROM tabla WHERE CURRENT OF cursor UPDATE tabla SET

lis/a-de~asignacinWHERE
reunin-utema
referencia~a-/abla
CURRENT OF cursor
referencia-a-tabla [
especijicacin-de-reunin l
referencia.a~tabla
La direccin de bsqueda (dir-bsqueda. opcional) se especifica como sigue, y nmero-de-fila se puede especificar como una variable o un literal.
NEXT
reunin-de-unin
reunjn~cruzada
especificacin-de~reun In
1 PRIOR I FIRST I LAST 1 ABSOLUTE nmero-de-fila I RELATIVE nmero-de-fila
UNION JOIN referencia-a-tabla CROSS JOIN ON condjcin-de-bsqueda I USING ( lista-de-columnas l
referencia-o~tabla
referencia-a-tabla
Expresiones de consultas
El estndar SQL2 proporciona un rico conjunto de expresiones para la especificacin de consultas, desde consultas simples a las expresiones de consulta ms complejas que usan operaciones de las bases de datos relacionales para combinar los resultados de consultas ms simples.
El estndar SQLZ permite combinar las especificaciones de consultas bsicas entre s usando las operaciones relacionales orientadas a conjuntos uNloN, EXCEPT e INTER5ECT. La expresin-de-consulta resultante proporciona la capacidad completa del procesamiento relacional de conjuntos del estndar. Encerrada entre parntesis, una expresi6n-de-consulta se convierte en una subconsulta que puede aparecer en varias posiciones de una instruccin SQL (por ejemplo, dentro de ciertas condiciones de bsqueda en la clusula WHERE).
972

juncindislimo funcin-Iodas
Apndice C: Referencia de la sintaxis de SOL

AVG I MAX I MIN I SUM 1 COUNT ( DISTINCT ref-a-columna) AVG J MAX 1 MIN I SUM 1 COUNT ( [ ALL l aprJ
973
No todas las marcas de SGBD permiten todas estas operaciones. Una forma simplificada de la sintaxis de SQL2 (sin los detalles de precedencia de operadores) es:
Expresin expresin-de-consulta
expresin-de-utlin expresin-excepto
Sintaxis
rabIa-simple I tabla-reunida I cxpresin-de-unin I expresinexcepto I expresin-de-inrerseccin I ( expresin-de-consulta ) apresin-de-eonsullO UNION ( ALL l [ espuificacin-de correspondencia l expresin-de-consulra expresin-de-consulla EXCEPT [ ALL l [ especificacinde-corre.rpondcncia ) expresin-de-co/lsulto expresin-de-consulla INTER5ECT [ ALL l [especificacin-de-corr~spond~nciaJ expr~sin-d~-consulta
Elementos de las instrucciones

o
Estos elementos aparecen en varias instrucciones SQL:

Elemento del lenguaje asignacin-set
~l~m~nl0-d~-ord~nacin
d~men1o-d~-insercin
Expresin-de.jnlerucci/l
especijicacin-de-correspondencia
eORRESPONDING
[ BY
( listo-d~-columnas)
subconsulta (
expresin-de-consulta)
elemento-de-seleccin
r~ferencia-a-tabla
Condiciones de bsqueda
Estas expresiones seleccionan filas de la base de datos para procesarlas:
condicin-d~-bsqueda el~m~1lto-debsqueda
ust-d~-bsqu~da
ref-a-columna
Sintaxis columna = ( ~xpr I NULL DEFAULT ) { ref-a-columna I entero} Ase I DEse { valor 1 NULL } expr tabla [ alias-de-tabla [ { rabia I alias} l columna
Elementos simples
Los siguientes son los nombres bsicos y l.a,.s constantes que aparecen en instrucciones SQL:
Elemento del lenguaje tabla columna usuario variable literal entero tipo-de-datos alias cursor Descripcin Nombre de labia Nombre de columna Nombre de usuario de la base de datos Nombre de variable del anfitrin o de un procedimiento almacenado Nmero o literal de cadena encerrado entre comillas Nmero enlero Tipo de dalos SQL Identificador SQL Identificador SQL
test-d~comparacin
test-b~tween
tesr-like
test-d~nulos
tesr-set test-cualllificado
test-d~-existencia
Sintaxis demento-de-bsqueda I elem~nto-d~bsqueda ( AND I OR elemellto-de-bsqueda [ NOT ) { testd~-blsqueda I ( cOlldicin-de-bsqueda) test-de-comparacin J t~sl-b~1Ween I t~stJike 1" t~std~-nulos t~st-set I t~st-cuantificado I test-de-uistellcia expr ( = I <> I < 1 <= I > I >= ) { expr I subconsulta } expr 1 NOT ) BETWEEN upr AND upr. ref-a-columna ( NOT 1 LIKE valor [ ESCAPE valor J re/-o-columna IS I NOT 1 NULL expr [ NOT J IN { listade-valores I subcOlIsulta expr { = I <> I < I <= I > I >= } { ALL I ANY 1 SOME J subconsulta EXISTS subconsulta
Expresiones
Estas expresiones se usan en las listas de seleccin SQL y en las condiciones de bsqueda:
ex"
elemento-de-upresin valor variabledel-anfitrilJ funcin
Sintaxis elememo-de-expresin 1 elemento-de-expresin { + I - I * I I } elemento-de-e.xpresi6n [ + I - } [ valor I "f-a-columna I fUllcin I { expr J } lileral I USER I variabl~-del-allfitrin I variable-de-procedimiemDalmacenado variable [ [ INDICATDR ) variable J COUNT ( * ) I funci61l-dislintO 1 funcin-Iodas
APNDICE
La interfaz del nivel de llamadas de SOL

En aras de la claridad, las rutinas se presentan con dos diferencias con respecto al estndar. Los nombres de los parmetros de las rutinas se abrevian en este apndice para hacer que las rutinas sean ms fciles de leer Y. en algunos casos, para clarificar su funcin. En las llamadas reales a las rutinas desde un programa de aplicacin, se usan los nombres de las variables del programa de aplicacin como entrada y parmetros de salida en lugar de nombres de parmetros. Tambin por evitar confusin, los tipos de datos de los parmetros se escriben aqu en trminos de los tipos de datos reales del lenguaje Consulta (por ejemplo, long, short, *char). El estndar define los parmetros usando constantes simblicas definidas (#define en el lenguaje C) para respresentar estos tipos de datos. El apndice A.I del estndar (ISO/IEC 9075-3:1995) es un archivo de cabecera Consulta que define constantes simblicas para todas las constantes y cdigos especificados en el estndar, y usa los nombres de variables de parmetros completos especificados en el estndar. A continuacin, un resumen de las rutinas organizadas por su funcin:
AllocHandle () FreeHandle () AllocConnect () FreeConnect{) Connect () Disconnect() DataSources() AllocEnv () FreeEnv( ) SetEnvAttr ()
Asigna recursos para el entorno. conexin, descriptor o instruccin. Libera recursos asignados previamente. Asigna recursos para una conexin a una base de datos. Libera recursos de una conexin a una base de datos. Establece una conexin a una base de datos. Finaliza una conexin establecida a una base de datos. Obtiene una lista de servidores SQL disponibles a los que se puede realizar una conexin. Asigna recursos para un entorno SQL. Libera recursos de un entorno SQL. Establece el valor de atributo de un entorno SQL.
975
976
Apndice D: La interfaz del nivel de llamadas de SOL
977
GetEnvAttr (l
AllocStmt () FreeStrnt ()
SetStrntAttr ()
GetSt.mtAttr{)
ExecDirect ()
Prepare () Execute ()
EndTran ()
Obtiene el valor de atributo de un entorno SQL. Asigna recursos para una instruccin SQL. Libera recursos para una instruccin SQL. Establece un rea de descriptor a usar por una instruccin SQL. Obtiene un rea de descriptor de una instruccin SQL. Ejecuta directamente una instruccin SQL. Prepara una instruccin SQL para una ejecucin posterior.
GetFunctions ()
GetInfo () GetTypeInfo()
Obtiene informacin sobre las funciones incorporadas de una implementacin SQL. Obtiene informacin sobre las caractersticas incorporadas de una implementacin SQL. Obtiene informacin sobre los tipos de datos incorporados.
Valores devueltos por CL/

Cada rutina de la interfaz en el nivel de llamadas (CLl, Call-Level Interface) devuelve un valor short con uno de los siguientes valores y significados: Valor devuelto por CLI O
1
Cancel () GetDescField ()
SetDescField ()
GetDescRec ( )
SetDescRec()
CopyDesc ()
NurnResul tCaIs ()
Ejecuta una instruccin SQL previamente preparada. Finaliza una transaccin SQL. Cancela la ejecucin de una instruccin SQL. Obtiene el valor de un campo descriptor. Establece el valor de un campo descriptor. Obtiene los valores de un registro descriptor. Establece los valores de un registr;o descriptor. Copia los valores del rea de descriptor. Determina el nmero de columnas de resultados de la consulta.. Describe una columna de re.sultados de la consulta. Obtiene un atributo de una columna de resultados de la consulta. Enlaza la ubicacin del programa a un valor de parmetro. Procesa los valores de los parmetros diferidos. Proporciona un valor de parmetro diferido o una porcin de un valor de cadena de caracteres. Establece el nombre de un cursor. Obtiene el nombre de un cursor. Busca una fila de resultados de la consulta. Busca una fila de resultados de la consulta con desplazamiento. Obtiene el valor de una columna de resultados de la consulta. Cierra un cursor abierto. Obtiene informacin de error. Obtiene el valor de un campo de registro de diagnstico. Obtiene el valor de un registro de diagnstico. Obtiene el nmero de filas afectadas por la ltima instruccin SQL.
Significado
99
-1
Describecol () ColAttribute () BindPararn( ) PararnData () PutData () SetCursorName ( )

GetCursorName ( )
-2
Instruccin completada con xito. Terminacin con xito y aviso: no se encontraron datos (cuando se recuperan resultados de una consulta). Se necesitan datos (el parmetro dinmico requirido est ausente). Error durante la ejecucin de la instruccin SQL. Error --controlador no vlido en la llamada.
Rutinas generales de gestin de controladores

Estas rutinas se usan para asignar un controlador que ser utilizado por la interfaz CL!, y para liberar un controlador previamente asignado que no se necesita ms. La rutina de asignacin acepta un argumento indicando el tipo de controlador que se asigna. En general, puede ser preferible usar las rutinas en lugar de crear y liberar los tipos especficos de controladores, descritos en sus secciones respectivas. Estas rutinas se deben usar para asignar y liberar los controladores descriptores del programa de aplicacin.
/* Asigna un controlador para usarlo en llamadas eL! posteriores -/ short SQLAllocHandle ( short hdlType, /* IN: cdigo entero del tipo de cont.rolador -, long inHdl, ,- IN: cont.rolador env o conn long -rtnHdl) OUT: cont.rolador devuelt.o
Fetch ()
FetchScroll()
GetData ()
CloseCursor () Error ()
GetDiagField ()
'*
*'*'
/* Libera un controlador asignado previamente con SQLAllocHandle() */
GetDiagRec ()
RowCount ()
short SQLFreeHandle ( short hdlType, long inHdl)
,- IN: cdigo entero del tipo de cont.rolador */ /* IN: controlador a liberar */
978

char
Apndice D: La interfaz del nivel de /Jamadas de SOL

*svrName,
979
Rutinas para la gestin del entorno SOL

Estas rutinas se usan para asignar un controlador de un nuevo entorno SQL, para liberar un controlador de entorno cuando no se necesita ms y para recuperar y establecer el valor de los atributos asociados con el entorno SQL.
/* Asigna un controlador para un nuevo entorno SQL */
short
svrnamlen,
*userName,
char
short char short
, IN: nombre del servidor SQL objetivo , ' IN; longitud del nombre del se:r:vidor SQL ' ' IN; nombre de usuario para la conexin ' , IN: contrasei'l.a de conexin '
IN: longitud de IN; longitud del nombre de usuario '
short SQLAllocEnv (
long *envHdl)
/* OUT:
usrnamlen, "passwd, pswlen)
controlador env devuelto */
,'O Libera un controlador de entorno previamente asignado "/

short SQLFreeEnv ( long envHdl)
/* IN:
/* Se desconecta del short SQLDisconnect ( long connHdl)
" " servidor
,.
contrasea "
SQL "/ IN: controlador de conexin "/
/*
controlador de entorno "/
1* Obtiene el valor de un atributo de entorno SQL "/
short SQLGetEnvAttr( long envHdl, long AttrCode, void ~ rtnVal, long bufLen, long *strLen)
controlador de entorno "/ cdigo de atributo entero"/ /" OUT: valor devuelto "/ /" IN: longitud del bfer rtnVal "/ /* OUT: longitud de los datos actuales */
/* IN: /* IN:
/* Establece el valor de un atributo de entorno SQL */ short SQLSetEnvAttr( long envHdl, /* IN: controlador de entorno */ long AttrCode, /* IN: cdigo de atributo entero*/ void *attrVal, /* IN: nuevo valor de atributo "/ long *strLen) /* IN: longitud de los datos */
/* Obtiene los nombres de los servidores SQL accesibles para la conexin */ short SQLDataSources ( long envHdl, /* IN: controlador de entorno "/ short direction, /* IN: indica la primera o siguiente solicitud */ char *svrname , /* OUT: bfer para el nombre del servidor "/ buflen, short /* IN: longitud del bfer del nombre del servidor ,,/ short "'namlen, /* OUT: longitud actual del nombre del servidor "'/ *descrip, char /" OUT: bfer para la descripcin "/ buf2len, short /* IN: longitud del bfer para la descripcin "/ short *dsclen) /" OUT: longitud real del bfer para la descripcin "/ /* Obtiene el valor de un atributo de la conexin SQL "/ short SQLGetConnectAttr( long connRdl, /* IN: controlador de conexin */ long AttrCode, /* IN: cdigo de atributo entero*/ void *rtnVal. /" OUT: valor devuelto */ long bufLen, /* IN: longitud del bfer rtnVal */ long "strLen) /* OUT: longitud de los datos actuales */ /* Establece el valor de un atributo de conexin SQL */ short SQLSetConnectAttr( long connRdl. /* IN: controlador de conexin */ long AttrCode. /" IN: cdigo de atributo entero"/ void *attrVal, /* IN: nuevo valor de atributo */ long *strLen) /* IN: longitud de los datos */
Rutinas para la gestin de las conexiones SOL

Estas rutinas se usan para crear, terminar y gestionar una conexin con un servidor SQL. Asignan y liberan los controladores usados para mantener el estado de la conexin, establecer y terminar conexiones, gestionar los atributos asociados con una conexin y para obtener una lista de servidores SQL disponibles para la conexin.
/" Asigna un controlador para una nueva conexin SQL */ short SQLAllocConnect ( long envHdl, /" IN: controlador de entorno */ long "'connRdl) /" OUT: controlador de conexin devuelto */ /* Libera un controlador de conexin previamente asignado */ short SQLFreeConnect ( long connAdl) /* IN: controlador de conexin "/ /* Inicia una conexin con un servidor SQL */ short SQLConn~ct( long connRdl, /* IN: controlador de conexin */
Rutinas para la gestin de las instrucciones SOL

Estas rutinas se usan para asignar y liberar el controlador asociado con una instruccin SQL, para pasar el texto de la instruccin SQL a ejecutar y para solicitar la preparacin y la ejecucin real de la instruccin mediante eL!.
980
/*

char short
Apndice o: La interfaz del nivel de llamadas de SOL

stmttext. text1en)
981
Asigna un controlador para gestionar el procesamiento de las instrucciones SQL */ short SQLAlloeStmt ( long envHdl, IN: controlador de entorno long *stmtHdl) OUT: controlador de la instruccin *'
'* '*
*'
,- IN: texto de la instrucci6n SQL ,- IN: longitud del texto de la instruccin *'
*' *'
*' *'
/* Libera un controlador de la instruccin asignado previamente*' short SQLFreeStrnt ( long stmtHdl. ,- IN: controlador de la instruccin long aption) ,- IN: opciones de cursor y desvinculacin -, /*
*'
,- Prepara la instruccin SQL. pasndola en forma de texto SQL short SQLPrepare ( long strntHdl. '* IN: controlador de la instruccin char -stmttext, IN: texto de la instruccin SQL short text1en) '* IN: longitud del texto de la instruccin
'*
*'
Vincula un parmetro de la instruccin SQL a un rea de datos del programa */ short SQLBindParam ( long stmtHdl. IN: controlador de la instruccin short parmnr, IN: nmero del parmetro (1.2.3 ... ) *' short val type, '* IN: tipo de datos del valor proporcionado -, parmtype, short IN: tipo de datos del parmetro colsize. '* IN: tamano de la columna *' short decdigits, short '* IN: nmero de digitos decimales void '* IN: puntero al bfer de valores *value. parm ~, long "1enind) IN: puntero al bfer longitud' indicador -,
'* Execute a previous1y prepared SQL staternent *' short SQLExecute ( long stmtHdl) '* IN: controlador de la instruccin -, '* COMMIT o ROLLBACK una transaccin SQL short SQLEndTran ( short hdltype. '* IN: tipo de controlador -, long txnHdl, IN: controlador env. conn o stmt short compltype) ,- IN: tipo txn (commit'rollback)
'* '*
*'
*'
'*
*' *'
'* '*
*' *'
'*
,- Cancela una instruccin SQL en ejecucin short SQLCancel ( short stmtHdlJ IN: controlador de la instruccin *'
*'
/* Obtiene el valor de un atributo de una instruccin SQL *' short SQLGetStrntAttr (
long long void long long
strntHdl, AttrCode. *rtnVal.

bufLen, *strLen)
'* '* '*
'* IN: IN: '* OUT: '* IN: ,- OUT:
controlador de la instruccin cdigo de atributo entero*' valor devuelto longitud del bfer rtnVal *' longitud de los datos actuales *'
*'
Rutinas para el procesamiento de los resultados de las consultas

Estas rutinas se usan para obtener filas de resultados y para especificar las reas de datos del programa de aplicacin que se usan para recibir los resultados de la consulta.
'* Avanza el cursor a la siguiente fila de los resultados de la consulta -, short SQLFetch ( long strntHdl) '* IN: controlador de la instruccin
*'
/* Establece el valor de un atributo de una instruccin SQL *' short SQLSetStrntAttr( long stmtHdl, IN: controlador de la instruccin long At trCode. '* IN: c6digo de atributo entero*' void *attrVal. '* IN: nuevo valor de atributo long 11 strLenl IN: longitud de los datos *'
*'
*'
*'
Rutinas para la ejecucin de instrucciones SQL

Estas rutinas se usan para pasar el texto de la instruccin SQL a la interfaz eLI y para solicitar la ejecucin de la instruccin SQL, bien inmediatamente o bien despus de haber sido preparada. Tambin controlan la ejecucin de transacciones SQL y la cancelacin de instrucciones que se estn ejecutando.
'* Pasa el texto de la instruccin SQL y solicita su ejecucin short SQLExecDirect ( long . stmtHdl, IN: controlador de la instruccin *'
'* Desplaza el cursor arriba o abajo por los resultados de la consulta short SQLFetchScroll ( '* IN: controlador de la instruccin -, long stmtHdl, ,- IN: direccin (primero'siguiente' short fetchdir, anterior) *' long offsetl IN: desplazamiento (nmero de filas) -,
*'
'*
*'
'*
,- Obtiene los datos de una nica columna de los resultados de la consulta *' short SQLGetData '* IN: controlador de la instruccin *' long s trntRdl, ,- IN: nmero de columna a recuperar *' short co1nr, '* IN: tipo de datos a devolver al short tgttype, programa *'
982

void
"'value, buflen, *lenind) /* IN: puntero al bfer de los datos de columna "/ /" IN: longitud del bfer del programa "/ /" OUT: longitud real y/o ind NULL ,,/
Apndice O: La interfaz del nivel de llamadas de SOL
983
long
shart char shart short
strntHdl, color,
*colname,
buflen,
long long
/* Cierra un cursor para finalizar el acceso a
consulta shart SQLCloseCursor

long
'*'
los resultados de la
(
/" IN: controlador de la instruccin */
*namlen, *coltype, "colsize, *decdigits, "nullable)
stmtHdl)
short
/* Establece un nombre de cursor para un cursor abierto */ shart SQLSetCursorName ( /* IN: controlador de la instruccin */ long strntHdl, /* IN: nombre del cursor */ char cursname, /* IN: longitud del nombre del cursor */ shart namelen)
/* Recupera el nombre de un cursor abierto "/
short short short
'" '" '" '" '" '" '" '"

'"
IN: controlador de la instruccin IN: nmero de la columna a describir OUT: nombre de la columna de lo. resultados de la consulta IN: longitud del bfer del nombre de la columna " OUT: longitud real del nombre de la columna OUT: cdigo del tipo de datos de la columna devuelta OUT: longitud de los datos de la columna devuelta OUT: nmero de d.gitos devueltos de una columna OUT: si la columna puede tener valores NULL "
"'
"'
"'
"'
"'
"' "'
shart SQLGetCursorName ( long s trntHdl , char cursnarne, shart huflen, shart *namlenJ
/" /* /" /*
IN: controlador de la instruccin "/ OUT: bfer del nombre devuelto ,,/ IN: longitud del bfer */ OUT: longitud real del nombre devuelto */
1* Vincula una columna de resultados de la consulta a un rea de
datos del programa */ shart SQLBindCol ( long strntHdl, shart color. ahart tgttype:, void long
value, huElen, lenind)
'" '"
'" '" '" '"
long
IN: controlador de la instruccin IN: nmero de columna a vincular IN: tipo de datos del rea de datos del programa IN: puntero al rea de datos del programa IN: longitud del bfer del programa IN; puntero al bfer de longitud/ indicador
"' "'
"'
"'"' "'
/* Obtiene informacin detallada sobre una columna de resultados de la consul ta * / short SQLColAttribute ( long stmtHdl. IN: controlador de la instruccin */ short colnr, IN: nmero de la columna a describir "/ attrcode, /* IN: cdigo del atributo a recuperar */ short *attrinfo, /* OUT: bfer de la informacin de char atributo */ buflen, /" IN: longitud del bfer del atributo de short la columna ,,/ *actlen) /* OUT: longitud de la informacin del short atributo actual */
'" '"
Rutinas para la gestin de descriptores de los resultados de las consultas

Estas rutinas se usan para obtener una descripcin de los resultados de una consulta usando el mecanismo de descriptores eLl, y para manipular los descriptores para manejar la salida de los resultados de la consulta en las reas de datos del programa de aplicacin. '
/* Recupera informacin usada frecuentemente de un descriptor eLI */ short SQLGetDescRec ( long descHdl, IN: controlador del descriptor short recnr, IN: nmero de registro del descriptor char "name, OUT: nombre del elemento que se describe buflen, IN: longitud del bfer del nombre short *namlen, OUT: longitud real del nombre short devuelto OUT, cdigo del tipo de datos del short "datatype, elemento"/
Rutinas para la descripcin de los resultados de las consultas

Estas rutinas se usan para obtener una descripcin de los resulados de una consulta, incluyendo el nmero de columnas de resultados de la consulta, el tipo de datos y otros atributos de cada columna.
/* Determina el nmero de columnas resultado de una consulta "/ short SQLNumResultCols ( long stmtHdl, /" IN: controlador de la instruccin */ short *colcount) /* OUT: nmero de columnas devuelto */ /* Determina las caractersticas de una columna de resultados de la consulta "/ short SQLDescribeCol
'" '" '" '" '" '"
"'
"'
"'
"'
"'
984

short short short short
Apndice D: La interfaz del nivel de l/amadas de SOL

/~ Copia el contenido de un descriptor eLI en otro descriptor */ short SQLCopyDesc ( long indscHdl, /* IN: controlador del descriptor origen*/ long outdscHdl) /* IN: controlador del descriptor destino~/
985
subtype.
*length, precis.
*scale.
*nullable)
short
/ ' OUT; subcdigo del tipo de datos del elemento 'O, / ' OUT: longitud del elemento ~/ / ' OUT: precisin del elemento, si es numrico ~/ / ' OUT: escala del elemento, si es numrico ~/ / ' OUT: si el elemento puede tener valores NULL ~/
/* Obtiene informacin detallada de un elemento descrito por un descriptor eL! */ short SQLColAttribute ( long descHdl. /~ IN: controlador del descriptor */ /~ IN: nmero de registro del short recnr. descriptor */ /* IN: c6digo del atributo a describir short attrcade. void '"'attrinfo. /* OUT: bfer de la informacin del atributo */ huflen, short /* IN: longitud del bfer del atributo col */ short *actlen) /* OUT: longitud de la informacin del atributo real */
/*
Rutinas para el procesamiento diferido de parmetros dinmicos

Estas rutinas se usan para procesar los parmetros diferidos cuando sus valores se solicitan por la interfaz eL! durante la ejecucin de una instruccin SQL que Jos contiene.
/* Obtiene la etiqueta del parmetro para el siguiente parmetro dinmico requerido */ short SQLParamData ( long stmtHdl, /~ IN: controlador stmt con parmetros dinmicos */ void *prmtag) /* OUT: bfer para el valor devuelto de la etiqueta del parmetro */ /* Obtiene informacin detallada para un elemento descrito por un descriptor eLI */ short SQLPutData ( long strntHdl, /* IN: controlador stmt con parmetros dinmicos */ void *prmdata, /* IN: bfer con datos para el parmetro * / prmlenind) short /* IN: longitud del parmetro o ind NULL */
~/
Establece informacin usada frecuentemente en un descriptor eLI */ short SQLSetDescRec ( long descHdl, /* IN: controlador del descriptor */ short recnr. /* IN: nmero de registro del descriptor */ short datatype, /* IN: cdigo del tipo de datos del elemento*/ short subtype, /* IN: subcdigo del tipo de datos del elemento */ short length. /- IN: longitud del elemento */ short preciso /* IN; precisin del elemento, si es numrico */ short scale, /* IN: escala del elemento, si es numrico */ void *databuf /* IN; direccin del bfer de datos del elemento */ buflen, short /* IN: longitud del bfer de datos */ short *indbuf) /* IN: direcci6n del bfer del indicador para el elemento */
I
Rutinas para errores, estado y diagnstico

Estas rutinas se usan para determinar el motivo de una condicin de error devuelta por eLI, para determinar el nmero de filas afectadas en la ejecucin correcta de la instruccin y para obtener informacin detallada de diagnstico sobre las condiciones de error.
/ ' Devuelve l . anterior . / short SQLError long long long char
1* Establece informacin detallada sobre un elemento descrito por un descriptor eL! */ short SQLColAttribute ( long descHdl. / ' IN: controlador del descriptor ' / short recnr, /' IN: nmero de registro del descriptor ' / short attrcade. / ' IN: cdigo del atributo a describir ,/ void actrnfo. /' IN: bfer con informacin del atributo ' / short huflen) / ' IN: longitud de la informacin del atributo ' /
informacin de error asociada con una llamada CLI

(
envHdl, connHdl, stmtHdl, *sqlstate,
/' /' /' /'
IN: controlador de entorno ' / IN: controlador de conexin ' / instruccin ' / IN: controlador de OUT: valor SQLSTATE de cinco caracteres ' /
,.
986

long char short short *nativeerr, 1 OUT: cdigo de error nativo devuelto */ *msgbuf, 1 OUT: bfer para el texto del mensaje de error * / buElen, 1 IN: longitud del bfer del texto del mensaje de error */ *msglenl l ' OUT: longitud real del mensaje devuelta */
Apndice O: La interfaz del nivel de llamadas de SaL

/* Devuelve informacin sobre CLI */ short SQLGetInfo ( long connHdl, /* short infotype, /* void "infoval, /* short short buElen, *infolen)
987
las capacidades de una implementacin
./* Determina el nmero de filas afectadas en la instruccin SQL previa */ short SQLRowCount ( /* IN: controlador de la instruccin */ long stmtHdl, /* OUT: nmero de filas */ long *rowcnt)
/* Devuelve la informacin de uno de los registros de diagnstico de
IN: controlador de conexin */ IN: tipo de informacin requerida */ OUT: bfer de la informacin devuelta */ /* IN: longitud del bfer de informacin */ /* OUT: longitud real de la informacin devuelta */
/* Determina el nmero de filas afectadas por una instruccin SQL
error de CLI */ short SQLGetDiagRec ( short hdl type, long inHdl, short recnr, char long char short short *sqlstate, *nativeerr, *msgbuf, buElen, *msglen)
IN: cdigo del tipo de controlador */ /* IN: controlador CLI */ /* IN: nmero de registro de error requerido */ /* OUT: cdigo SQLSTATE de cinco caracteres */ /* OUT: cdigo de error nativo devuelto */ /* OUT: bfer para el texto del mensaje de error */ /* IN: longitud del bfer del texto del mensaje de error */ /* OUT: longitud real del mensaje devuelta */
/*
previa */ short SQLGetFunctions ( long connHdl, /* IN: controlador de conexin */ short functid, /* IN: cdigo identificador de la funcin */ *supported) /* OUT: si se admite la funcin */ short /* Determina informacin sobre los tipos de datos soportados */ short SQLGetTypeInfo ( long stmtHdl, /* IN: controlador de la instruccin */ short datatype) /* IN: ALL TYPES o tipo solicitado */
Cdigos de los valores de los parmetros CL!

Estos cdigos se pasan o se obtienen de eL! como valores de parmetros para indicar los tipos de contoladores, los tipos de datos, los tipos de instruccin, etc.
/* Devuelve un campo de uno de los registros de error de diagnstico CLI * / short SQLGetDiagField ( short hdl type. /* IN: cdigo del tipo de controlador */ long inHdl, /* IN: controlador eLI */ short recnr, /* IN: nmero de registro de error requerido */ diagid, short /* IN: identificador del campo de diagnstico */ *diaginfo, void /* OUT: informacin de diagnstico devuelta */ short buflen, /* IN: longitud del bfer de informacin de diagnstico */ short *actlen) /* OUT: longitud de la informacin real devuelta */
Cdigo Cdigos de los tipos de controladores

SQL-environment handle SQL-connection handle
SQL-statement handle SQL-descriptor handle
Valor
1 2
3
4 Cdigos de los tipos de datos de la implementacin SQL CHARACTER 1

NUMERIC
DECIMAL
INTEGER
2
3
4
Rutinas de informacin de la implementacin CL!

Estas rutinas deyuelven informacin sobre la informacin eL! especfica, incluyendo las llamadas eLl, las instrucciones y los tipos de datos que admite.
SMALLINT
FLOAT
5
6
REAL
DOUBLE
7
8
988
Cdigo
Apndice D: La interfaz del nivel de /Jamadas de SaL
989
Valor
Cdigo
MINUTE TO SECQND
Valor
DATETIME
9
10
13
INTERVAL VARCHAR
Cdigos de terminacin de transacciones

COMMIT
ROLLBACK
12
14
O
1
FreeStmt ()
BIT
Implementation-defined <O Cdigos de los tipos de datos del lenguaje del programa de aplicacin CHARACTER 1
NUMERIC DECIMAL
INTEGER SMALLINT
Cdigos de opciones de procesamiento

CLOSE CURSOR
FREE HANDLE UNBIND COLUMNS
2 3 4
1 2 UNBIND PARAMS 3 Cdigos de la orientacin de la bsqueda

1
5
6 7 8 <O
1 2 3
NEXT
FLOAT
REAL DOUBLE
FIRST
LAST
PRIOR
2 3 4
Implementation-defined Subcdigos Da teTime para los tipos de datos SQL

DATE TIME TIMESTAMP TIME w/ ZONE TIMESTAMP wl ZONE
ABSOLUTE
5
6
1
RELATIVE
Cdigos de tipos de datos Ge tDa ta ( )

CHARACTER INTEGER SMALLINT REAL DOUBLE
4
5
4
5
Da teTime
7
8
Cdigos de intervalo Tipos Da teTime

YEAR MONTH
de SQL
Cdigos de rutinas CL! para la llamada GetFunction ()
DAY
HOUR MINUTE SECOND YEAR TO MONTH DAY TO HOUR DAY TO MINUTE DAY TO SECONO HOUR TD MINUTE HOUR TO SECOND
1 2 3
4 5 6 7
8
AllocConnect . AllocEnv AllocHandle AllocStmt BindCol BindParam Cancel CloseCursor ColAttribute Connect CopyDesc DataSources
1 2 1001 3
4
1002
5
1003
6 7 1004 57
9 10
I1
12
APNDICE
El estndar del esquema de la informacin de SOL
Este apndice describe las vistas del esquema de la informacin de SQL especifica~ das por el estndar SQL2 (SQL-92). Estas vistas se deben admitir por cualquier sistema de bases de datos que se ajusten con un nivel intermedio o completo al estndar; no se requieren en el nivel de ajuste de entrada. En la prctica, el soporte de las vistas del esquema de la informacin completas se est introduciendo lentamente en los productos SGBD empresariales. Las vistas hacen que una base de datos de acuerdo con SQL2 sea autodescriptiva. Al consultarlas. un usuario puede determinar informacin relevante sobre todos los objetos de la base de datos (esquemas, tablas, colum-
nas, vistas, restricciones, dominios, conjuntos de caracteres, etc.) que estn accesibles.
La siguiente tabla proporciona informacin sobre los esquemas, tablas y columnas: .
SCHEMATA TABLES COLUMNS
Describe todos los esquemas propiedad del usuario actual Describe todas las tablas a las que puede acceder el usuario actual Describe todas las columnas de las tablas propiedad de o a las que puede acceder el usuario actual
Esta tabla proporciona informacin sobre las vistas:

VIEWS VIEW_TABLE_USAGE VIEW_COLUMN_USAGE
Describe todas las vistas las que puede acceder el usuario actual Describe todas las tablas de las que dependen las vistas Describe las columnas de las que dependen las vistas
Esta tabla proporciona informacin sobre restricciones (unicidad, claves primarias, claves externas, restricciones de comprobacin, asertos):
TABLE_CONSTRAINTS
Describe todas las restricciones sobre las tablas propiedad del usuario
993
994
Apndice E: El estndar del esquema de la informacin de SOL
995
REFERENTIAL_CONSTRAINTS CHECK_CONSTRAINTS KEY_COLUMN_USAGE ASSERTIDNS CONSTRAINT_TABLE_USAGE CONSTRAINT_COLUMN_USAGE
Describe todas las restricciones de clave externa propiedad del usuario Describe todas las restricciones de comprobacin propiedad del usuario Describe las claves definidas por el usuario actual Describe todos los asertos propiedad del usuario actual Describe todas las tablas usadas por las restricciones Describe las columnas usadas por las restricciones
Nombre de columna
CATALOG~NAME
Tipo de datos
VARCHAR(lon)
VARCHAR(lon)
SCHEMA_NAME SCHEMA_OWNER
DEFAULT~CHARACTER_
VARCHAR(lOIl) VARCHAR(lOIl) VARCHAR(lon) VARCHAR(lon)
SET_CATALOG DEFAULT_CHARACTER_ SET_SCHEMA DEFAULT_CHARACTER_ SET_NAME
Descripcin Nombre del catlogo que contiene este esquema Nombre del esquema descrito por esta fila Nombre del creador del esquema Catlogo del conjunto de caracteres predeterminado de este esquema Esquema del conjunto de caracteres predeterminado de este esquema Nombre del conjunto de caracteres predeterminado de este esquema
Esta tabla proporciona informacin sobre los privilegios:

TABLE_PRIVILEGES COLUMN_PRIVILEGES USAGE_PRIVILEGES
Describe los privilegios sobre las tablas Describe los privilegios sobre las columnas Describe los privilegios sobre otros objetos de la base de dalos
La vista
TABLES
Esta tabla proporciona informacin sobre los dominios:

DOMAINS DOMAIN_CONSTRAINTS DOMAIN_COLUMN_USAGE
La vista TABLES contiene una fila de cada tabla definida en el catlogo actual que es acc.esible al usuario actuaL Su estructura se muestra en la tabla siguiente: Nombre de columna
TABLE_CATALOG TABLE_SCHEMA
Describe los dominios accesibles al usuario Describe las restricciones que definen estos dominios Describe las columnas basadas en estos dominios
Esta tabla proporciona informacin sobre los conjuntos de caracteres:

CHARACTER_SETS COLLATIONS TRANSLATIONS
Describe conjuntos de caracteres Describe secuencias de ordenacin Describe traducciones entre conjuntos de caracteres
\ I
TABLE_NAME TABLE_TYPE
Descripcin Nombre del catlogo que contiene VARCHAR(loll) esta definicin de tabla Nombre del esquema que contiene VARCHAR(lOIl) esta definicin de tabla Nombre de la tabla VARcHAR(lon) VARcHAR(maxloll) . TIpo de la tabla (BASE TABLE/VIEW/
GLOBAL TEMPORARY/LOCAL TEMPORARV)
Tipo de datos
y a continuacin hay informacin sobre los lenguajes de programacin admitidos:

SQL_LANGUAGES
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud mxima definida por la implementacin SQL. VARCHAR(maxIon) es un tipo de datos VARCHAR con la longitud mxima permitida por la implementacin SQL.
Describe los lenguajes admitidos y las API SQL
Los contenidos especficos de cada vista del esquema de la informacin se describen en las siguientes pginas.
La vista
COLUMNS
La vista
SCHEMATA
La vista SCHEMATA contiene una fila por cada esquema que es propiedad del usuario actual. Su estructura se muestra en la siguiente tabla:
La vista COLUMNS contiene una fila por cada columna de cada tabla definida en el catlogo actual que es accesible al usuario actual. Su estructura se muestra en la siguiente tabla:
996
997
Nombre de columna
TABLE_CATALOG
COLUMN_NAME
DRDINAL_POSITION
COLUMN_DEFAULT rS_NULLABLE
CHARACTER_MAXIMUM_ LENGTH
CHARACTER_OCTET_ LENGTH NUMERIC_PRECISION

NUMERIC_PRECISION_ RADIX NUMERIC_SCALE
Descripcin Nombre del catlogo que contiene la definicin de tabla que contiene esta columna Nombre del esquema que conliene VARcHAR(lon) la definicin de tabla que contiene esta columna VARcHAR(lon) Nombre de la tabla que contiene esta columna VARcHAR(lon) Nombre de la columna INTEGER > O Posicin de la columna en esta tabla VARCHAR(maxion) Representacin textual del valor predeterminado para la columna VARcHAR(maxlon) Si la columna puede contener valor:es NULL (YES!NO) VARCHAR(max/on I TIpo de datos SQL2 de la columna (representacin textual) INTEGER > O Longitud mxima, en caracteres, de las columnas de longitud variable INTEGER > O Longitud mxima, en bytes, para las columnas de longitud variable INTEGER > O Precisin de las columnas con tipo de datos numricos INTEGER > O Base de la precisin
VARcHAR(lon) INTEGER > O INTEGER > O VARCHAR(lon)
Tipo de datos
Nombre de columna
COLLATION_NAME DOMAIN_CATALOG
Tipo de datos
VARCHAR(fon) VARCHAR(lon) VARcHAR(lon)
DOMAINJlAME
VARCHAR(1on)
Descripcin Nombre de la ordenacin de esta columna, si la hay Catlogo que contiene la definicin del dominio de esta columna Esquema que contiene la definicin del dominio de esta columna Nombre del dominio de esta columna, si lo hay
el tipo de datos de los identificadores SQL; ion es la longitud mxima definida por la implementaci6n SQL. VARCHAR(maxfon) es un tipo de datos VARCHAR con la longitud mxima permitida por la implementacin SQL.
VARcHAR(lon) es
La vista
VIEWS
La vista VIEWS contiene una fila por cada vista definida en el catlogo actual que es accesible al usuario actual. Su estructura se muestra en la tabla siguiente:
Nombre de columna
TABLE_CATALOG
Tipo de datos
VARCHAR(lon) VARCHAR(lon)
Descripcin
Nombre del catlogo que contiene esta definicin de vista Nombre del esquema que contiene esta definicin de vista Nombre de la vista Texto de la instruccin SQL que define la vista Opcin de comprobacin para esta vista (CASCADED/LOCAL/NONE) Si se puede actualizar la vista (VES!
NO)
TABLE_NAME VIEW_DEFINITION
VARCHAR(lon)
VARCHAR(maxlon)
VARCHAR(max/on)
Escala del tipo de datos numrico Precisin para las columnas de tipo de datos Da teTime
DATETIME_PRECISION
CHARACTER_SET_ CATALOG
CHARACTER_SET_ SCHEMA
vARcHAR(lon)
VARcHAR(lon)
COLLATION_CATALOG
vARcHAR(1on) VARcHAR(1on)
Catlogo que contiene la definicin del conjunto de caracteres de esta columna Esquema que contiene la definicin del conjunto de caracteres de esta columna Nombre del conjunto de caracteres de esta columna, si lo hay Catlogo que contiene la definicin de la ordenacin para esta columna Esquema que contiene la definicin de la ordenacin para esta columna
VARCHAR(max/on)
VARCHAR(/on) es el tipo de datos de los identificadores SQL; ion es la longitud mxima
definida por la implementacin SQL.

VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud mxima permitida por la
implementaci6n SQL.
La vista VIEW_TABLE_USAGE contiene una fila por cada tabla de la que depende una vista definida en el catlogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla: .
998
saL.
Apndice E: El estandar del esquema de la informacin de SOL
999
Nombre de columna
VIEW_CATALOG VIEW_SCHEMA VIEW_NAME TABLE_CATALOG TABLE_SCHEMA TABLE_NAME
Tipo de datos
vARcHAR(lon) vARcHAR(lon)
VARCHAR(loll) VARCHAR(lon)
vARcHAR(lon) VARcHAR(lon)
Descripcin Nombre del catlogo que contiene la definicin de la vista Nombre del esquema que contiene la definicin de la vista Nombre de la vista Catlogo que contiene la definicin de la tabla de que depende la vista Esquema que contiene la definicin de la tabla de la que depende la vista Nombre de la tabla de la que depeode la vista
JOII
La vista
TABLE_CON5TRAINT5
La vista TABLE_CONSTRAINTS contiene una fila por cada restriccin de tabla definida por las tablas en el catlogo actual propiedad del usuario actual. Su estructura se muestra en la siguiente tabla:
Nombre de columna
CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_CATALOG TABLE_SCHEMA TABLE_NAME
Tipo de datos
VARcHAR(lon) VARcHAR(lon)
VARCHAR(lon)
VARCHAR(lon)
VARcHAR(lon)
VARCHAR(lon) es el tipo de datos de los identificadores SQL;
es la longitud mxima
Descripcin Nombre del catlogo que contiene la definicin de la restriccin Nombre del esquema que contiene la definicin de la restriccin Nombre de la restriccin Nombre del catlogo que contiene la definicin de la tabla
La vista
VIEW_COLUMN_U5AGE
CONSTRAINT_TYPE
Nombre del esquema que contiene la definicin de la tabla VARcHAR(lon) Nombre de la tabla a la que se aplica la restriccin VARCHAR(maxlon) Tipo de restriccin (UNIQUE/ PRlMARY KEY/FOREIGN KEY/CHECK)
VARCHAR(max/on)
VARCHAR(maxlon)
La vista VIEW_COLUM1CUSAGE contiene una fila por cada columna de la que depende una vista definida en el catlogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
VIEW_CATALOG VIEW_SCHEMA VIEW_NAME TABLE_CATALOG
IS_DEFERRABLE INITIALLY_DEFERRED
Si la restriccin es diferible
NO)
(YES /
Tipo de datos
VARcHAR(lon) VARcHAR(lon) VARCHAR(lol!) VARcHAR(lon)
Descripcin Nombre del catlogo que contiene la definicin de la vista Nombre del esquema que contiene la definicin de la vista Nombre de la vista Catlogo que contiene la definicin de la columna de la que depende la vista Esquema que contiene la definicin de la columna de la que depende la vista Nombre de la tabla que contiene la columna de la que depende la vista Nombre de la columna de la que depende la vista
Si la restriccin est inicialmente diferida (YES/NO)
VARCHAR(/on) es el tipo de datos de los identificadores SQL; Ion es la longitud mxima

VARcHAR(maxlon) es un tipo de datos VARCHAR con la longitud mxima permitida por la
implementacin SQL.
La vista
REFERENTIAL_CON5TRAINT5
TABLE_SCHEMA
VARCHAR(/on)
TABLE_NAME CLUMN_NAME
VARCHAR(lon)
La vista REFERENTIAL_CONSTRAINTS contiene una fila por cada restriccin referencial (relacin clave externa/clave primaria) definida para las tablas del catlogo actual propiedad del usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna Tipo de datos Descripcin Nombre del catlogo que contiene la definicin de la restriccin Nombre del esquema que contiene la definicin de la restriccin
VARCHAR(lon)
CONSTRAINT_CATALOG. VARcHAR(lon) CONSTRAINT_SCHEMA VARcHAR(lon)
VARCHAR(Jon)
e~ el tipo de datos de los identificadores SQL; Ion es la longitud mxima definida por la implementacin SQL.
1000
1001
Nombre de columna
CONSTRAINT_NAME
UNIQUE_CONSTRAINT_ CATALOG
Tipo de datos
vARcHAR(lon)
VARcHAR(lon)
Descripcin Nombre de la restriccin Nombre del catlogo que contiene

la definicin de restriccin de unicidad o de clave primaria de la tabla padre Nombre del esquema que contiene la definicin de restriccin de unicidad o de clave primaria de la tabla padre Nombre de la definicin de restriccin de unicidad o de clave primaria de la tabla padre Tipo de la correspondencia de la clave externa parcial (NONEI PARTIAL/FULL)
Nombre de columna Tipo de datos

CHECK_CLAUSE
Descripcin Texto de la condicin de bsqueda SQL que define la restriccin de control
VARCHAR(maxLon)
VARCHAR(/on) es el tipo de datos de los identificadores SQL; ion es la longitud mxima definida por la implementacin SQL. VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud mxima permitida por la implementaci6n SQL.
UNIQUE_CONSTRAINT_ SCHEMA
VARcHAR(lon)
UNIQUE_CONSTRAINT_ NAME
VARCHAR (ion)
VARcHAR(maxlon)
La vista KEY_COLUMN_USAGE contiene una fila por cada columna que participa en una clave definida en el catlogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
CONSTRAINT_CATALOG
Tipo de datos
VARCHAR(lon)
vARcHAR(mailon)
Regla de actualizacin de la restriccin referencial (CASCADE/SET

NULL/SET DEFAULT/NO ACTION)
VARCHAR(maxlon)
Regla de eliminacin de la restriccin referencial (CASCADE/ SET

NULL/SET DEFAULT/NO ACTION)
CONSTRAINT_SCHEMA
VARCHAR(lon)
VARCHAR(lon) es el tipo de datos de los identificadores SQL; ion es la longitud mxima definida por la implementacin SQL. VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud mxima mayor pennitida por la implementacin SQL.
CONSTRAINT_NAME TABLE_CATALOG
VARcHAR(lon) VARCHAR(/on)
TABLE_SCHEMA
VARCHAR(lon)
La vista CHECK_CONSTRAINTS
TABLE_NAME
VARcHAR(lon)
La vista CHECK_CONSTRAINTS contiene una fila por cada restriccin de control (restriccin de control, restriccin del mbito de control, o definicin del aserto) definida por las tablas del catlogo actual propiedad del usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME
Descripcin Nombre del catlogo que contiene la definicin de la restriccin de clave Nombre del esquema que contiene la definicin de la restriccin de clave Nombre de la restriccin de clave Nombre del catlogo que contiene la definicin de la tabla que contiene la clave Nombre del esquema que contiene la definicin de la tabla que contiene la clave Nombre de la tabla que contiene la columna clave Nombre de la columna Posicin de la columna dentro de la clave
COLUMN_NAME ORDINAL_POSITION
VARcHAR(lon)
INTEGER >
Tipo de datos
vARcHAR(lon)
VARCHAR(lon) vARcHAR(lon)
Descripcin Nombre del catlogo que contiene la definicin de restriccin Nombre del esquema que contiene la definicin de restriccin Nombre de restriccin
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud mxima definida por la implementacin SQL.
La vista ASSERTIONS
La vista ASSERTIONS contiene una fila por cada aserto definido en el catlogo acma} propiedad del usuario actual. Su estructura se muestra en la siguiente tabla:
1002
1003
Nombre de columna
CONSTRAINT_CATALOG
CONSTRAINT_SCHEMA CONSTRAINT_NAME IS_DEFERRABLE INITIALLY_DEFERRED
Tipo de datos
VARCHAR(lon)
Descripcin Nombre del catlogo que contiene la definici6n del aserto Nombre del esquema que contiene VARCHAR(lon) la definici6n del aserto Nombre del aserto VARCHAR(loll) vARcHAR(maxlon) Si el aserto es diferible (YES NO) VARcHAR(maxlon) Si el aserto est inicialmente diferido (YES/NO)
to) definida en el catlogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla:
Nombre de columna
Tipo de datos
vARcHAR(lon) VARcHAR(lon) VARcHAR(lon) VARcHAR(lon) VARcHAR(lon) vARcHAR(lon) VARcHAR(lon)
Tl\BLE_NAME
COLUMN_NAME CQNSTRAINT_CATALOG CONSTRAINT_SCHEMA
CONSTRAINT_NAME
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud mxima definida por la implementacin SQL. VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud mxima permitida por la implementacin SQL.
La vista
CONSTRAINT_TABLE_USAGE
Descripcin Nombre del catlogo que contiene la definicin de la columna Nombre del esquema que contiene la definicin de la columna Nombre de la tabla que contiene la columna Nombre de la columna Nombre del catlogo que contiene la definicin de la restriccin Nombre del esquema que contiene la definicin de la restriccin Nombre de la restriccin
La vista CONSTRAINT_TABLE_USAGE contiene una fila por cada tabla usada por una restriccin (restriccin referencial, de unicidad, de comprobacin o aserto) definida en el catlogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
TABLE_CATALOG TABLE_SCHEMA TABLE_NAME CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud mxima definida por la implementacin SQL.
La vista
TABLE_PRIVILEGES
Tipo de datos
VARcHAR(lon) VARCHAR(/on) VARCHAR(/on)
Descripcin Nombre del catlogo que contiene la definicin de la tabla Nombre del esquema que contiene la definicin de la tabla Nombre de la tabla Nombre del catlogo que contiene la definicin de la restriccin Nombre del esquema que contiene la definicin de la restriccin Nombre de la restriccin
La vista TABLE_PRIVILEGES contiene una fila por cada privilegio sobre las tablas definidas en el catlogo actual que ha sido concedido al usuario actual, concedido a todos los usuarios o concedido por el usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
GRANTOR GRANTEE
VARcHAR(lon) VARcHAR(lon) VARcHAR(lon)
TABLE_CATALOG TABLE_SCHEMA TABLE_NAME
VARCHAR(lOll) es el tipo de datos de los identificadores SQL; Ion es la longitud mxima definida por la implementacin SQL.
La vista
CONSTRAINT_COLUMN_USAGE
PRIVILEGE_TYPE IS_GRANTABLE
Descripcin Identificador de autorizacin del usuario que concede el privilegio VARcHAR(lon) Identificador de autorizacin del usuario al que se le concede el privilegio VARcHAR(lon) Nombre del catlogo que contiene esta definicin de vista VARCHAR(/on) Nombre del esquema que contiene esta definicin de vista vARcHAR(lon) Nombre de la vista VARcHAR(maxlon) TIpo del privilegio (SELECT I INSERT I
VARCHAR(lon) DELETEiuPDATE/REFERENCES) VARcHAR(maxlon)
Tipo de datos
La vista CONSTRAINT_COLUMl'CUSAGE contiene una fila por cada columna usada por una restriccin (restriccin referencial, de unicidad, de comprobacin o aser-
Si el privilegio se concede con la opcin GRANT (YES/NO)
1004
saL.
1005
VARCHAR(lon) es el tipo de datos de los identificadores SQL; ion es la longitud mxima definida por la implementacin SQL. VARCHAR(maxlon) es un tipo de dalos VARCHAR con la longitud mxima mayor permitida por la implementacin SQL.
dido a todos los usuarios o concedido por el usuario actuaL Su estructura se muestra en la siguiente tabla:
Nombre de columna
GRANTOR
Tipo de datos
VARCHAR(/on)
VARCHAR(lon)
Descripcin
Identificador de autorizacin del usuario que concede el privilegio Identificador de autorizacin del usuario al que se le concede el privilegio Nombre del catlogo que contiene la definicin del objeto Nombre del esquema que contiene la definicin del objeto Nombre del objeto Tipo del objeto (DOMAIN/CHARACTER SET/ COLLATION/TRANSLATION)
La vista
COLUMN_PRIVILEGES
GRANTEE
La vista COLUMN_PRIVILEGES contiene una fila por cada privilegio sobre las columnas definidas en el catlogo actual que ha sido concedido al usuario actual, concedido a todos los usuarios o concedido por el usuario actual. Su estructura se muestra en la siguiente tabla:
OBJECT_CATALOG OBJECT_SCHEMA
VARcHAR(lon) VARCHAR(lOIl)
VARcHAR(lon)
Nombre de columna
GRANTOR GRANTEE
Tipo de datos
VARCHAR(lon)
VARcHAR(lon)
TABLE_CATALOG
vARcHAR(lon)
TABLE_SCHEMA
VARcHAR(lon)
TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE
VARcHAR(lon) VARcHAR(lon) VARCHAR(maxlon)
Descripcin Identificador de autorizacin del usuario que concede el privilegio Identificador de autorizacin del usuario al que se le concede el privilegio Nombre del catlogo que contiene la definicin de la tabla que contiene esta columna Nombre del esquema que contiene la definicin de la tabla que contiene esta columna Nombre de la tabla que contiene esta columna Nombre de la columna Tipo del privilegio (SELECT/INSERT/DELETE/UPDATE/REFERENCES)
OBJECT_NAME OBJECT_TYPE
VARcHAR(maxlon)
PRIVILEGE_TYPE IS_GRANTABLE
VARcHAR(maxion)
vARcHAR(maxlon)
Tipo del privilegio (siempre el literal USAGE) Si el privilegio se concede con la opcio GRANT (YESINO)
La vista
DOMAINS
IS_GRANTABLE
VARCHAR(maxlon)
Si el privilegio se concede con la opcin GRANT (YES/NO)
La vista DOMAINS contiene una fila por cada dominio definido en el catlogo actual accesible al usuario actual. Su estructura se muestra en la siguiente tabla:
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud mxima
Nombre de columna
DOMAIN_CATALOG
Tipo de datos
VARCHAR(ion)
VARCHAR(lon)
Descripcin
Nombre del catlogo que contiene la definicin del dominio Nombre del esquema que contiene la definicin del dominio Nombre del dominio Tipo de datos SQLZ en el que se basa la definicin del dominio (representacin textual)
defmida por la implementacin SQL. vARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud mxima permitida por la implementacin SQL.
La vista
USAGE_PRIVILEGES
DOMAIN_NAME DATA_TYPE
VARcHAR(lon) VARCHAR(maxion)
La vista USAGE;_PRIVILEGES contiene una fila por cada privilegio sobre los objetos definidos en el catlogo actual que ha sido concedido al usuario actual, conce-
1006
Apndice E: El estndar de! esquema de la informacin de SaL
1007
Nombre de columna
CHARACTER_MAXIMUM_ LENGTH CHARACTER_OCTET_ LENGTH COLLATION_CATALOG
Tipo de datos
INTEGER > O
Descripcin
Longitud mxima, en caracteres, de
Nombre de columna
CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME DOMAIN_CATALOG
Tipo de datos
VARcHAR(lon)
Descripcin
Nombre del catlogo que contiene esta definicin de restriccin Nombre del esquema que contiene esta definicin de restriccin Nombre de la restriccin Nombre del catlogo que contiene la definicin del dominio sobre el que se aplica la restriccin Nombre del esquema que contiene la definicin del dominio sobre el que se aplica la restriccin Longitud mxima del tipo de datos de longitud variable. en octetos Si la restriccin es diferible (YES I
NO)
los tipos de caracteres de longitud

INTEGER >
variable Longitu<;i mxima de los tipos de datos de longitud variable, en bytes
VARCHAR(lon)
VARcHAR(lon)
Nombre del catlogo que contiene

la definicin de la ordenacin para este dominio
COLLATION_SCHEMA
COLLATION~NAME
VARCHAR(lon)
VARcHAR(lon) VARCHAR(lon)
Nombre del esquema que contiene la ordenacin para este dominio Nombre de la ordenacin para este dominio Nombre del catlogo que contiene la definicin del conjunto de caracteres para este dominio Nombre del esquema que contiene la definicin del conjunto de caracteres de este dominio Nombre del conjunto de caracteres de este dominio Precisa si este dominio est basado en un tipo de datos numrico Base de la precisin Escala ~i este dominio est basado en un tipo de datos numrico Precisa si este dominio est basado en un tipo de datos Da teTime Representacin textual del valor predeterminado del dominio
DOMAIN_SCHEMA
VARCHAR(lon)
DOMAIN_NAME IS_DEFERRABLE INITIALLY_DEFERRED
VARCHAR(lon)
CHARACTER_SET_ CATALDG CHARACTER_SET_ SCHEMA
VARCHAR(maxlon) VARCHAR(maxlon)
vARcHAR(lon)
Si la restriccin est inicialmente diferida (YES /NO)
CHARACTER_SET_NAME NUMERIC_PRECISIDN NUMERIC_PRECISION_ RADIX NUMERIC_SCALE

DATATIME_PRECISIQN
VARCHAR(lon)
VARCHAR(lon)
INTEGER
INTEGER INTEGER
>
O
O O
es el tipo de datos de los identificadores SQL; Ion es la longitud mxima definida por la implementacin SQL. VARcHAR(maxlon) es un tipo de datos VARCHAR con la longitud mxima permitida por la implementacin SQL.
>
>
La vista
DOMAIN_COLUMN_USAGE
INTEGER >
La vista DOMAIN_COLUIDCUSAGE contiene una fila por cada columna usada por un dominio definido en el catlogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla:
DOMAIN_DEFAULT
VARCHAR(maxion)
Nombre de columna
VARCHAR{lon) es el tipo de datos de los identificadores SQL; Ion es la longitud mxima
Tipo de datos
vARcHAR(lon) VARCHAR(lon)
VARcHAR(lon) VARCHAR(/on) VARCHAR(/on)
Descripcin
Nombre del catlogo que contiene la definicin del dominio Nombre del esquema que contiene la definicin del dominio Nombre del dominio Nombre del catlogo que contiene la definicin de la columna Nombre del esquema que contiene la definicin de la columna
definida por la implementacin SQL. VARCHAR(maxlotl) es un tipo de datos VARCHAR con la longitud mxima permitida por la implementacin SQL.
OOMAIN_CATALOG DOMAIN_SCHEMA DOMAIN_NAME
La vista
DOMAIN_CONSTRAINTS
La vista DOMAIN_CONSTRAINTS contiene una fila por cada restriccin de dominio para un dominio definido en el catlogo actual que es accesible al usuario actual. Su estructura se muestra en la siguiente tabla:
1008
Apndice E: El estndar del esquema de fa informacin de SOL
1009
Nombre de columna
TABLE_NAME
Tipo de datos
VARcHAR(lon) VARCHAR(lon)
Descripcin Nombre de la tabla que contiene la

columna
La vista
COLLATIONS
Nombre de la columoa
La vista COLLATIONS contiene una fila por cada ordenacin (secuencia de ordenacin) definida en el catlogo actual que es accesible al usuario actual. Su estructura se muestra en la siguiente tabla:
VARCHAR(Jon) es el tipo de datos de los identificadores SQL; Ion es la longitud mxima definida por la implementacin SQt.
Nombre de columna
COLLATION_CATALOG
La vista
CHARACTER_SETS
COLLATION_SCHEMA COLLATION_NAME CHARACTER_SET_ CATALOG
La vista CHARACTER_SETS contiene una fila por cada conjunto de caracteres definido en el catlogo actual que es accesible al usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
CHARACTER_SET_ CATALOG CHARACTER_ SET_ SCHEMA CHARACTER_SET_NAME
FORM_OF~USE
Tipo de datos
VARcHAR(lon)
vARcHAR(lon)
VARcHAR(lon)
VARCHAR(lon) INTEGER > o VARcHAR(lon)
NUMBER_OF_ CHARACTERS DEFAULT_CQLLATE CATALOG
DEFAULT_COLLATE_ SCHEMA
VARcHAR(lon)
DEFAULT_COLLATE_
VARCHAR(lon)
NAME
Descripcin Nombre del catlogo que contiene la definicin del conjunto de caracteres Nombre del esquema que contiene la definicin del conjunto de caracteres Nombre del conjunto de caracteres Forma de uso del conjunto de caracteres Nmero de caracteres del conjunto de caracteres Nombre del catlogo que contiene la definicin de la ordenacin predeterminada para este conjunto de caracteres Nombre del esquema que contiene la definicin de la ordenacin predeterminada para este conjunto de caracteres Nombre de la ordenacin predeterminada para este conjunto de caracteres
CHARACTER_SET_ SCHEMA
CHARACTER_SET_
NAME
PAD_ATTRIBUTE
Descripcin Nombre del catlogo que contiene la definicin de la ordenacin Nombre del esquema que contiene VARCHAR(lon) la definicin de la ordenacin Nombre de la ordenacin VARCHAR(lon) VARCHAR(lon) Nombre del catlogo que contiene la definicin del conjunto de caracteres sobre el que se define la secuencia de ordenacin VARcHAR(lon) Nombre del esquema que contiene la definicin del conjunto de caracteres sobre el que se define la secuencia de ordenacin VARcHAR(lon) Nombre del conjunto de caracteres sobre el que se define la secuencia de ordenacin VARcHAR(maxlon) Relleno de caracteres (PAD SPACE/
VARcHAR(lon)
NO PAD)
Tipo de datos
La vista
TRANSLATIONS
La vista TRANSLATIONS contiene una fila por cada traduccin (conversin de un conjunto de caracteres en otro) definida en el catlogo actual que es accesible al usuario actuaL Su estructura se muestra en la siguiente tabla:
Nombre de columna Tipo de datos
Descripcin Nombre del catlogo que contiene la definicin de la traduccin Nombre del esquema que contiene la definicin de la traduccin
TRANSLATION_CATALOG VARCHAR(lon) TRANSLATION_SCHEMA VARCHAR(lon)
1010
Apndice E: El estndar del esquema de la informacin de SaL
1011
Nombre de columna
TRANSLATION_NAME SOURCE_CHARACTER_ SET_CATALOG SOURCE_CHARACTER_ SET_SCHEMA CHARACTER_SET_NAME TARGET_CHARACTER_ SET_CATALOG TARGET_CHARACTER_ SET_SCHEMA TARGET_CHARACTER_ SET_NAME
TIpo de datos
VARcHAR(lon)
VARCHAR(lon)
VARCHAR(lon)
VARCHAR(lon)
VARCHAR(Jon)
Descripcin Nombre de la traduccin Nombre del catlogo que contiene la definicin del conjunto de caracteres en el que ocurre la traduccin Nombre del esquema que contiene la definicin del conjunto de caracteres en el que ocurre la traduccin Nombre del conjunto de caracteres en el que ocurre la traduccin Nombre del catlogo que contiene la definicin del conjunto de caracteres en el que ocurre la traduccin Nombre del esquema que contiene la definicin del conjunto de caracteres en el que ocurre la traduccin Nombre del conjunto de caracteres en el que ocurre la traduccin
Nombre de columna
SQL_LANGUAGE_ BINDING_STYLE
Tipo de datos
VARcHAR(maxion)
Descripcin Estilo de vinculacin (por ejemplo,

EMBEDDED/MODULE/oIRECT)
SQL_LANGUAGE_ VARcHAR(maxion) PROGRAMMING_LANGUAGE
Nombre del lenguaje de programacin admitido (por ejemplo, ADA/cl

COBOL/FORTRAN/PASCAL/PLI)
VARCHAR(maxlolI) es un tipo de datos VARCHAR con la longitud mxima permitida por la implementacin SQL.
VARCHAR(lOIf) es el tipo de datos de los identificadores SQL; Ion es la longitud mxima definida por la implementacin SQL.
La vista
SQL_LANGUAGES
La vista SQL_LANGUAGES contiene una fila por cada lenguaje estndar ANSI admitido por esta implementacin SQL. SU estructura se muestra en la siguiente tabla: Nombre de columna Descripcin Texto que identifica la fuente del estndar del lenguaje (por ejemplo. ISO 9075) VARcHAR(maxion) Ao en el que se aprob el estndar (por ejemplo. 1987) VARcHAR(maxion) Nivel de ajuste (1/2)
VARCHAR(maxfon) VARCHAR(maxion)
Tipo de datos
SQL_LANGUAGE_SOURCE VARcHAR(maxion)
SQL_LANGUAGE_YEAR SQL_LANGUAGE_ CONFORMANCE SQL_LANGUAGE_ INTEGRITY SQL_LANGUAGE..,.. IMPLEMENTATION
Integridad
(YES/NO)
NULL
Cadena de caracteres definida por la implementacin, o NULL
APNDICE
Gua de instalacin del CD-ROM
El CD-ROM que acompaa a este libre incluye versiones completas para Windows NT12000 de las tres marcas lderes de SGBD basados en SQL: Microsoft SQL Server 2000 IBM DB2 MySQL
Adems. la ltima seccin de este Apndice contiene instrucciones para descargar una versin de prueba del SGBD Oracle. No son versiones derno incompletas de los productos SGBD. En cambio, son versiones de evaluacin completas del ltimo software de los fabricantes lderes de SGBD, lo que le pennite aprender SQL usando un SGBD actual, analizarlo y comparar cada producto para encontrar el SGBD basado en SQL que se adapte mejor a las necesidades especficas. El CD-ROM tambin incluye archivos de datos que se pueden usar para rellenar las cinco tablas de la base de datos de ejemplo de forma que se puedan ejecutar fcilmente las consultas de ejemplo de este libro. Los archivos residen en el directorio raz del CD-ROM y se denominan:
CLIENTES.DAT OFICINAS.DAT PEDIDOS.DAT PRODUCTOS.DAT REPRESENTANTES.DAT
Disfrute de este CD-ROM nico que slo est disponible con SQL Manual de referencia, el libro ms completo sobre SQL con la coleccin ms completa de
valiosos SGBD basados en SQL de los fabricantes lderes de SGBD.

1013
1014
Apndice F: Gua de instalacin del CD-ROM
1015
El
Estos productos estn sujetos a licencias restringidas de uso; son slo

para fines de evaluacin y, en algunos casos, incluyen mecanismos de expiracin que provocan que el software finafice su operacin 90 o 120 das despus de la instalacin. Vanse las tablas en fas secciones a continuacin para consultar los detalles especficos de cada producto.
Fabricante Fundado Ventas anuales
Microsoft Corporation 1975 27,7 miles de millones de dlares
Instalacin del software SGBD SOL

Cuando se inserta el eD-ROM acompaante en la unidad de CD-ROM, Windows inicia automticamente el programa de instalacin de SGBD en el CD-ROM. El programa pide que se acepte el acuerdo de licencia de McGraw-Hill/Osborne y despus permite seleccionar el SOBD a instalar, como se muestra a continuaci6n:
~
Requisitos de hardware y de software

Microsoft SQL Server 2000 Enterprise Edition requiere el siguiente hardware y software:
Categora Computadora Sistema operativo
DBMS Selection
Ch:Jose Mrl SQl DBMS you woUd ike lo nstal by relecti1g Irom !he ist beIow.
r.
Miacsoft SQl SetVef 2COJ Ertetprice Etion
('.:o IBM DB2 Univel~ DalabMe 7.2 Entesxise EdOOn
Memoria (RAM) Espacio en disco duro Software de Internet Software de red
Mj6Ql3.Z3
ji
NelIt>
f~E~
Requisitos [nteI o compatible Pentium 166MHz o superior. Microsoft Windows NT Workstation 4.0 con SP5 o superior, Windows NT Server 4.0 con SP5 o superior, Windows NT Server 4.0 Enterprise Edition con SP5 o superior, Windows 2000 Professional, Windows 2000 Server, Windows 2000 Advanced Server O Windows 2000 Datacenter Server. 128MB o ms recomendada. Aprox. 250MB para una instalacin tpica. Microsoft Imernet Explorer versin 5.0 o superior. Windows 95, Windows 98, Windows Millennium Edition, Windows NT 4.0 o Windows 2000 software de red incorporado (no se necesita software de red adicional a menos que se est usando Banyan VINES o AppleTalk ADSP; el soporte del cliente Novel! NetWare IPXlSPX se proporciona por el protocolo NWLink de la red de Windows).
Las secciones que siguen contienen instrucciones detalladas para la instalacin de cada marca de SOBD basado en SQL.
Notas sobre la instalacin

El CD-ROM oficial de evaluacin de Microsoft SQL Server 2000 se ha recortado algo para que el software de SQL Server 2000 quepa en el'CD-ROM acompaante. Por tanto, se deben elegir con precisin las selecciones indicadas en las instrucciones de la siguiente seccin, o la instalacin no proceder correctamente. Adems, no hy que intentar instalar OLAP Analysis Services. Si se tienen ms preguntas sobre la instalacin de SQL Server 2000, consltese la gua de insla1aci6n de SQL'Server en el CD-ROM. El archivo es: \MSSQL\books\instsql.chm. Finalmente, si se est instalando SQL Server 2000 en una computadora en la que existe una versin previa de SQL Server, hay que hacer una copia de seguridad de la instalacin previa de Microsoft SQL Server y no instalar SQL Server 2000 en el mismo directorio que la instalacin previa.
Microsoft SOL Server 2000

La siguiente tabla lista los detalles y los datos del producto y la empresa:
Nombre del producto Primera distribucin Plataforma Limitaciones del software SQL Server 2000 Enterprise Edition 1988 Windows NT!2000 Expira 120 das despus de la instalacin
1016
Apendice F: Gua de instalacin del CD-ROM
1017
Instalacin de SOL Server 2000

Para instalar SQL Server 2000 hay que seguir estos pasos: 1. 2. 3. Iniciar sesin en el sistema como miembro del grupo Administradores. Insertar el CD-ROM acompaante en la unidad de CD-ROM. Windows inicia automticamente el programa de instalacin de los SGBD del CD-ROM. Si el programa de instalacin no se inicia automticamente, hay que pulsar dos veces con el ratn SQLINSTALL.EXE en el directorio raz del CD-ROM para iniciarlo manualmente. El programa de instalacin muestra un cuadro de dilogo que pide que se acepte el acuerdo de licencia de McGraw-HiIJlOsbome. Hay que indicar si se acepta el acuerdo y pulsar Next (Siguiente). El programa de instalacin muestra el cuadro de dilogo de seleccin del SGBD (DBMS, Database Management System). Seleccionar Microsoft SQL Server 2000 Enterprise Edition de la lista de posibilidades y pulsar Nexr (Siguiente). Aparece el cuadro de dilogo de bienvenida (Welcome) de la instalacin de SQL Server. Pulsar Next (Siguiente) para continuar. Aparece el cuadro de dilogo del nombre de la computadora (Computer Name). Pulsar Next (Siguiente) para aceptar la seleccin de la computadora local. Aparece el cuadro de dilogo de la seleccin de la instalacin (Insta/latian Selection). Pulsar Next (Siguiente) para aceptar la creacin de un nuevn ejemplar de SQL Server (Crea te A New Instance Of SQL Server) o para instalar herramientas cliente (lnstall Client Tools). Aparece el cuadro de dilogo de la infonnacin del usuario (User Information). Introducir el nombre y la compaa si son diferentes de los valores predeterminados indicados, y pulsar Next (Siguiente). Aparece el cuadro de dilogo del acuerdo de licencia del snftware (Software License Agreement). Pulsar Ves (S) para aceptar el acuerdo. Aparece el cuadro de dilogo de la definicin de la instalacin (!nstallation Definition). Pulsar Nat (Siguiente) para aceptar la seleccin del servidor (Server) y las herramientas del cliente (Client Tools). Aparece el cuadro de dilogo del nombre del ejemplar (Instance Name). Pulsar Next (Siguiente) para aceptar la casilla de verificacin Default (predeterminado) o introducir un nombre de ejemplar si ya se tiene una instalacin previa de SQL Server. Aparece el cuadro de dilogo del tipo de la instalacin (Serup Type). Dejar la opcin Typical (Tpica) seleccionada. El cuadro de dilogo tambin indica los directorios predetenninados en los que se copiarn los archivos de SQL Server. Aceptar los valores predeterminados o pulsar Browse (Examinar) para especificar diferentes directorios y pulsar Next (Siguiente). Aparece el cuadro de dilogo de las cuentas de los servicios (Services Accouhts). Dejar seleccionada la opcin Use The Same Account For Each
15.
16. 17. 18. 19.
4:
5.
Service. Auto Start SQL Server Service (Usar la misma cuenta para cada servicio. Iniciar automticamente SQL Server). Introducir un nombre de usuario y contrasea existente para usarlos para el servicio SQL Server o seleccionar Use the Local System Accoun/ (Usar la cuenta local del sistema) y pulsar Next (Siguiente). Aparece el cuadro de dilogo Aurhentication Mode (Modo de autenticacin). Seleccionar el modo mixto (Mued Mode) e introducir una contrasea para el inicio de sesin sao Aparece el cuadro de dilogo de la copia de archivos (Start Copying Files). Pulsar Next (Siguiente) para continuar. Si se solicita parar tareas en ejecucin, pulsar Nat (Siguiente) para continuar y pulsar Finish (Terminar) para iniciar la instalacin. El programa de instalacin instala SQL Server en el disco duro. Esto puede durar varios minutos. Cuando la instalacin est completa, aparece el cuadro de dilogo Setup Complete (Instalacin terminada). Pulsar Finish (Tenninar) para volver a Windows.
6. 7.
Inicio de SOL Server 2000

Despus de haber instalado SQL Server 2000 se debe reiniciar la computadora antes de poder empezar a usar el software. SQL server se inicia automticamente despus del reinicio de la computadora y cada vez que se inicie posteriormente la computadora. De forma alternativa, para iniciar SQL Server sin reiniciar hay que ir a SQL Server Service Manager (Administrador de servicios de SQL Server) y seleccionar StartlContinue (Iniciar/Continuar).
8.
9.
10. 11.
Desinstalacin de SOL Server 2000

Hay que seguir los siguientes pasos para desinstalar SQL Server 2000:
1.
12.
"
2.
3.
4. 5.
13.
14.
6.
Elegir Inicio 1 Configuracin I Panel de control de la barra de tareas de Windows. Pulsar dos veces en la aplicacin Agregar o quitar programas. Seleccionar Microsoft SQL Server 2000 de la lista de programas instalados actualmente y pulsar CambiarlEliminar. Aparece el cuadro de dilogo Confirmar la supresin de archivos .. Pulsar S para continuar. Aparece el cuadro de dilogo Suprimir archivo compartido'? y pide que se confinne si se desea suprimir los archivos compartidos que no se van a usar ms. Pulsar S a todo para suprimir estos archivos y pulsar S cuando aparezca el segundo cuadro de dilogo de confirmacin. Windows elimina el prngrama SQL Server 2000 del sistema.
1018
Apndice F: Gua de instalacin del CD-ROM
1019
IBM DB2
La siguiente tabla proporciona varios detalles sobre el producto y la empresa:
Instalacin de DB2 Enterprise Edition

Para instalar DB2 Universal Database Enterprise Edition hay que seguir estos pasos:
Nombre del producto Primera distribucin Plataforma Limitaciones del software Fabricante Fundado
Ventas anuales
DB2 Universal Database 7.2 Enterprise Ed~tion 1985 Windows NT12000 Expira 90 das despus de la instalacin IBM Corporation 1911 83,4 miles de millones de dlares
l.
Iniciar sesin en el sistema como usu~o que cumpla los requisitos de la instalacin de DB2. La cuenta en la que se inicie sesin debe estar (a) definida localmente, (b) pertenecer al grupo de Administradores locales y (e) tener los siguientes derechos de usuario avanzado: Actuar como parte del sistema operativo. Crear objeto identificador. Incrementar cuotas. Reemplazar identificador de nivel de procesos.
2. 3.

Microsoft SQL Server 2000 Enterprise Edition requiere el siguiente hardware y software: Categora Computadora Sistema operativo Memoria (RAM) Espacio en disco duro Software de red Otros Requisitos Computadora personal Pentium. Microsoft Windows NT Version 4.0 SP5 o superior, o Microsoft Windows 2000. 128MB o ms recomendada. Aprox. 245MB para una instalacin tpica. TCP/IP, IPX/SPX, Named Pipes, NetBios y MPTN (APPC sobre TCP/IP). Si se tiene instalado el programa antivirus de IBM, se debe desactivar o desinstalar para realizar la instalacin de DB2. 4. 5.
6. 7. 8. 9.

El CD-ROM oficial de evaluacin de IBM DB2 2000 se ha recortado algo para que el software de DB2 quepa en el CD-ROM acompaante. Por tanto, se deben elegir con precisin las selecciones indicadas en las instrucciones de la siguiente seccin, o la instalacin no proceder correctamente. Adems, no hay que intentar instalar OLAP Starter Kit. Si se tienen ms preguntas sobre la instalacin de DB2, consltese la gua de instalacin de DB2 en el CD-ROM. El archivo se encuentra en \lBMDB2\doc\ en\db2i6\db2i6.htm. 10.
11.
Insertar el CD-ROM acompaante en la unidad de CDROM. Windows inicia automticamente el programa de instalacin de los SGBD del CD-ROM. Si el programa de instalacin no se inicia automticamente, hay que pulsar dos veces con el ratn SQLINSTALL.EXE en el directorio raz del CD-ROM para iniciarlo manualmente. El programa de instalacin muestra un cuadro de dilogo que pide que se acepte el acuerdo de licencia de McGraw-HiIUOsborne. Hay que indicar si se acepta el acuerdo y pulsar Next (Siguiente). El programa de instalacin muestra el cuadro de dilogo de seleccin del SGBD (DBMS, Darabase Management System). Seleccionar IBM DB2 Universal Database 7.2 Enterprise Edition de la lista de posibilidades y pulsar Nexr (Siguiente). El programa de instalacin muestra un cuadro de dilogo que pide que se acepte el acuerdo de licencia de IBM Corporation. Indicar si se acepta el acuerdo y pulsar Nexr (Siguiente). . Aparece el cuadro de dilogo de seleccin de productos. Pulsar Nexl (Siguiente) para aceptar la seleccin DB2 Enterprise Edition. Aparece el cuadro de dilogo para seleccionar el tipo de instalacin (Seleer Inslal1ation Type). Pulsar Next (Siguiente) para aceptar la instalacin tpica (Typical). Aparece el cuadro de dilogo (Seleet Destination Loeation) e indica el directorio predeterminado en el que se copiarn los archivos de IBM DB2. Aceptar el valor predeterminado o pulsar Browse (Examinar) para especificar un directorio diferente y pulsar Next (Siguiente). Aparece el cuadro de dilogo para introducir el nombre de usuario y la contrasea (Enter Username and Password). Aceptar el nombre de usuario predeterminado db2admin. introducir una contrasea y pulsar Next (Siguiente). Si ya exista el nombre de usuario db2admin de una instalacin previa de DB2, se debe introducir la contrasea existente para db2admin; en caso contrario, se pedir que se confirme que se desea usar el nuevo nombre de usuario. Aparece el cuadro de dilogo de la copia de archivos (Star, Copyillg Files). Pulsar Next (Siguiente) para continuar.
1020
12.
13.
Apndice F: Gua de instalacin del CDROM
1021
14.
15.
El programa de instalacin instala DB2 en el disco duro. Esto puede du~ rar varios minutos. Aparece el cuadro de dilogo de instalacin del kit de inicio OLAP (Install OLAP Start Kit). Seleccionar no instalarlo (Do Not lnstall The OLAP Starter Kit) y pulsar Continue (Continuar). Cuando la instalacin est completa, aparece el cuadro de dilogo Setup Complete (Instalacin terminada). Pulsar Finish (Terminar) para salir del programa de instalacin de DB2. Se ejecuta automticamente el, programa primeros pasos en DB2 (DB2 Firsl Steps) para empezar a trabajar inmediatamente con DB2.
Fabricante
Fundado
Ventas anuales
MySQL AB 1995 No publicadas

MySQL 3.23 requiere el siguiente hardware y software:
Categora
Inicio de DB2 Enterprise Edition

Despus de haber instalado DB2 Enterprise Edition, se puede usar el programa primeros pasos en DB2 (DB2 First Steps) para empezar a trabajar inmediatamente con DB2. Despus de esto, DB2 se inicia automticamente cada vez que se inicia la computadora.
Computadora Sist~ma operativo Memoria (RAM) Espacio en disco duro Software de red
Requisitos lotel o Pentium compatible. Windows 9x/Me, Windows NT4 SP3 o superior, Windows 2000lWindows XP. 128MB o ms recomendada.
Aprox. 50MB. TCP/IP.
Desinstalacin de DB2 Enterprise Edition

Hay que seguir los siguientes pasos para desinstalar SQL Server 2000:
l.

Si se tienen ms preguntas sobre la instalacin de MySQL, consltense las instrucciones de instalacin de MySQL en el sitio Web de MySQL. En el momento de la publicacin de este libro, las instrucciones de instalacin se encontraban en http://www.mysql.com/doc/W/i/Windows_installation.html. Si este vnculo Web queda anticuado o no es correcto, se pueden buscar en el sitio web principal de MySQL (www.mysql.com) las instrucciones de inst~lacin. Tambin se puede visitar el sitio Web de MySQL para descargar la versin ms reciente del SGBD MySQL.
2. 3. 4. 5.
6.
Elegir Inicio 1 Configuracin I Panel de control de la barra de tareas de Windows. Pulsar dos veces en la aplicacin Agregar o quitar programas. Seleccionar IBM DB2 de la lista de programas instalados actualmente y pulsar CambiarlEliminar. Aparece el cuadro de dilogo Confirmar la supresin de DB2. Pulsar S para continuar. Si se est ejecutando DB2, aparece el cuadro de dilogo INFORMATION y pide que se confirme que se desean para todos los procesos DE2 en ejecucin. Pulsar fes (S) para continuar. Windows elimina todos los programas DE2 del sistema.
Instalacin de MySOL
Para instalar MySQL hay que seguir estos pasos: l. 2. 3. Iniciar sesin en el sistema como miembro del grupo Administradores. Insertar el CD-ROM acompaante en la unidad de CD-ROM. Windows inicia automticamente el programa de instalacin de los SGBD del CD-RM. Si el programa de instalacin no se inicia automticamente, hay que pulsar dos veces con el ratn SQLINSTALL.EXE en el directorio raz del CD-ROM para iniciarlo manualmente. El programa de instalacin muestra un cuadro de dilogo que pi~e ~ue s~ acepte el acuerdo de licencia de McGraw-HilllOsbome. Hay que mdlcar SI se acepta el acuerdo y pulsar Nat (Siguiente).
MySOL
La siguiente tabla proporciona varios detalles sobre el producto y la empresa:
Nombre del producto Primera distribucin Plataforma Limitaciones del software
MySQL 3.23.51 1995 Windows 9x1Me, Windows NT4/2000/XP Ninguna
4.
1022
5.
Apndice F: Gua de instalacin del CDROM
1023
6.
7. 8.
9.
10. 11.
El programa de instalacin muestra el cuadro de dilogo de seleccin del SOBD (DBMS, Database Managemem System). Seleccionar MySQL 3.23 de la lista de posibilidades y pulsar Next (Siguiente). Aparece el cuadro de dilogo de bienvenida (WeLcome) de la instalacin de MySQL. Pulsar Next (Siguiente) para continuar. Aparece el cuadro de dilogo de informacin (Informalion). Pulsar Next (Siguiente) para continuar. Aparece el cuadro de dilogo para elegir la carpeta de destino (Choose Deslinatioll Locatioll) e indica el directorio predeterminado en los que se copiarn los archivos de MySQL. Aceptar el valor predeterminado o BrolVse (Examinar) para especificar diferentes directorios y pulsar Next (Siguiente). Aparece el cuadro de dilogo del tipo de instalacin (Setup Type). Pulsar Next (Siguiente) para aceptar la seleccin tipica (Typical). El programa de instalacin introduce MySQL en el disco duro. Esto puede durar varios minutos. Cuando la instalacin est completa, aparece el cuadro de dilogo Setup Complete (Instalacin tenuinada). Pulsar Finish (Terminar) para salir del programa de instalacin de MySQL.
No obstante se puede descargar la ltima versin del SGBD Orade directamente desde el sitio Web de Oracle. En el momento en que se public este libro, la ltima versin estaba disponible para ser descargada en http://otn.oracle.com/software/products/oracle9i/content.html. McGraw-Hill/Osborne y los autores no se pueden hacer responsables si este vnculo Web mantenido por Oracle caduca o no es correcto en el futuro, as que si el vnculo no funciona se puede probar en el sitio Web principal de Oracle (www.oracle.com) para descargar la versin ms reciente del SGBD Orade.
Inicio de MySOL
Despus de instalar MySQL, se puede ejecutar el programa cliente mysql.exe (ubicado en c:\mysql\bin) desde la lnea de comandos para empezar a trabajar inme-
diatamente con MySQL.
Desinstalacin de MySOL
Hay que seguir los siguientes pasos para desinstalar MySQL:
l. 2. 3. 4. 6. Elegir Inicio J Configuracin I Panel de control de la barra de tareas de Windows. Pulsar dos veces en la aplicacin Agregar o quitar programas. Seleccionar MySQL Servers And Clients de la lista de programas instalados actualmente y pulsar Cambiar!EliminaP). Aparece el cuadro de dilogo Confirmao) la supresin de archivos. Pulsar S) para continuar. Windows elimina los programas de MySQL del sistema.
Descarga del software del SGBD Oracle

La ltima versin del SGBD Oracle ocupa tres CD-ROM, as que en esta edicin de SQL Manual de referencia fue imposible incluirlo en el CD-ROM adjunto con
el resto de marcas de SGBD.
In dice
(3)Smbolos (signo del euro), 914 '" (asterisco), 105-106 @ (signo de la arroba), 804-806 @@@ERROR, 729 @@@SQLSTATUS, 729 [ J (corchetes). 968 { J (llaves). 968 J (lnea verlicar), 968 <> (desigualdad) operador, 222-224 < (menor que), 219. 881, 884 > (mayor que), 219. 881, 884
A2i, perfil del fabricante de bases de datos, 948 acceso a base de datos desde servidores de aplicaciones, 779791 acceso a bases de datos con sesiones
heao,781784
acceso a entidades con sesiones beao, 785-790 mejoras EJB 2.0. 790-791 tipos EJB. 780-781 visin general de, 779780 distribuidas. 819-827 solicitudes distribuidas, 825-827 solicitudes remotas, 821 transacciones distribuidas, 824-825 transacciones remolas, 822-824 visin general de. 819-822 remotas. 35 extractos de tablas. 808-810 rplica de tablas, 810-812 transparencia y, 806-808
acceso de actualizacin, 821 acceso remolo, 802-806 acceso slo en lectura, 821 Active X Data Objects (ADa), 10 actualizaciones con cursores, 530-534 ADa (Active X Data Objects). 10 alias, 376-377 alias de tabla, 153-155,310 CREATE ALIAS, inslruccin, 376 DROP ALIAS, instruccin, 376 transparencia de datos remotos, 806~808 ALL, test, 223-225 almacenamiento fsico, 368-369 almacenes de datos, 757-772 componentes, 760-761 conceptos, 758~760 cubos de hechos, 762-764 dimensiones multinivel, 766768 esquemas en estrella, 764-766 estndar SQL para, 49-51, 919-920 evolucin de, 760-762 extensiones SQL para, 768-769 futuro de, 932-933 mercado creciente, 922 rendimiento de carga y, 769-770 rendimiento de consultas y, 771-772 ALTER, inslrucciones. 356, 382 ALTER TABLE, instrucciones, 370-374 adicin de columnas, 371-372 cambio de las claves primarias y externas, 373-374 eliminacin de columnas, 372-373 Informix, 864 visin general de, 370-371
1025
1026
ndice
aplicaciones, 831 caractersticas de SQL para, 12 implementacin de SQL como, 6-7 procedimientos almacenados y, 832-834 arquitectura de base de datos nica, 387-388 arquitectura de multiprocesador, 923-924 arquitectura de mltiples bases de datos, 388-390 consu1Las cruzadas de bases de datos y, 390 SOBO, aplicacin, 388 ventajas/inconvenientes de, 388-389 arquitectura de red centralizada, 38-39 arquitectura de servidor de archivos, 39-40 arquitectura de sitios Web de tres capas, 777-779 arquitectura de ubicacin mltiple, 390-392 SOBO, aplicacin, 390 ventajas/inconvenientes de, 390-391 arquitectura multicapa, 41~42 arquitectura. Vase tambin estructura de la base de datos aplicaciones de red y bases de datos, 831-837 rplica, 816-821 sitios Web de tres capas, 777-779 arrays, 861-871. Vase lambin arrays variables, Oraele bases de datos relacionales orientadas a objetos y, 845 consulta, 867-868 de parmetros, OOBC, 658-659 definicin, 863-866 manipulacin, 868-869 procedimientos almacenadosy, 869-871 variables de Oracle, 865-866 manipulacin, 868 procesamiento, 870-871 AS/4oo, 43 ASCn, conjunto de caracteres, 185-186 asertos definicin, 375 restricciones avanzadas, 301-303 restricciones de tabla y, 300 ASIC (Applicotion-Specific lntegraled Circuits), 925 ASSERTION, vista, SQL esquema de la informacin, 1001 asterisco (.), 105 atributos base de datos orientada a objetos, 840 CLI (Cal/Level Inlerface), 647-650 tipo de datos abstracto de Oraele, 853-855 atributos, XML documentos y, 881-883 elementos y, 886-889 SQL y, 885 XML Schema, 908909 auditora, 736 aumento del nivel de bloqueo, 345 autenticacin, 429431 autorreuniones, 151-154 AVG ( ), funcin de columna, 184
ndice
1027
ampliacin, arquitectura centralizadas y, 38-39 anlisis de objetos grandes, 895896 anlisis, instrucciones, 484analizadores de DOM (Documem Objecf
Model), 896 ancho de banda, 83 1-834 ANO, palabra clave, 121-123 ANSI (American National Slandards Institute), 9 ANSI/ISO, estndares. 3234 actualizaciones de vistas. 415-416 caracteres comodn, 119 caractersticas de integridad referencial, 287-288 catlogo del sistema. 453-454 claves externas y valores nulos. 299 conformidad de SQL con, 927 estructura de la base de datos, 392-399 nombres de SQL, 80 operaciones aritmticas, 90 palabras clave de SQL, 75-77 REVOKE, instrucciones. 449-450 SQLl, SQL2 y SQU, 32 tipos de datos de SQL, 83-84 ANY, test, subconsultas, 219-223 APJ (interfaces de programas de aplicacin) acceso al SGBo con, 592 arquitectura cliente/servidor y, 594 como alternativa a SQL para programacin, 592 conceptos, 592-594 loBC. Vase IOBC (conectividad con base de datos lava) DBC. Vase eL! (Call-Levellnterface);
ODBC (Open Dalabase Conneclivily) operacin bsica de, 592 Oracle. Vase OCI (Orade Call Interface) SQL Server. Vase dblib, API SQUintegracin de aplicaciones, 482-483 APIlJamable, OOBC, 653 aplicaciones empresariales empaquetadas, 922-923 reglas de negocio y, 306-308 SQL,920 transportabilidad, 35-38 aplicaciones distribuidas en Internet, 51-52 Apple, 35 Arbor Software, 948-949 arquitectura cliente/servidor, 40-41 API y, 594
Backus Naur Form (BNF), notacin, 903, 967 barras verticales (1), 967 basadas en Internet, 44 bases de datos. Vase tambin bases de datos distribuidas actualizacin, 21 adicin, 257-266 base de datos simple de ejemplo, 19-20 carga masiva. 265-266 IN5ERT de una nica fila, 258-262 IN5ERT sobre varias filas, 262265 visin general de, 257258 comercializacin de XML nativo, 916-917 creacin. Vase tambin estructura de la base de datos aljas y sinnimos, 376-378 base de datos simple de ejemplo, 22-23 definiciones de restricciones, 374-376 definiciones de tablas. Vase definicin de labias diferencias de la estructura de las bases de datos en diferentes fabricanSes, 357-358 ndices, 378-382 LOO (lenguaje de definicin de datos) y, 355-356 objetos gestionados, 382385 agrupadas, 922-923 de almacenes de datos, 760 de ejemplo, 941-946 contenido de las tablas de, 944-946 estructura de, 941-943 visin general de, 941 de procesamiento de pedidos. 57 distribuidas, 801-819 acceso remoto, 802-806 acceso, 819-827 aplicaciones de red / arquitectura de bases de datos. 831-837
arquitecturas de rplica, 816819 compromisos de las rplicas, 814-815 desafos de, 795-801 extractos de tablas, 808-810 lenguaje SQL y, 7 protocolo de compromiso de dos fases. 827-830 rplica de tablas, 810-812 rplicas actualizables. 813 transparencia de datos remotos, 806808 visin general de, 80\-802 ejemplo simple actualizacin de datos, 21 adicin de datos, 20 creacin, 22-23 eliminacin datos, 22 proteccin de datos, 21-22 recuperacin de datos, 17- I 9 resumen de datos, 19-20 visin general de. 15-17 el mercado de la prxima dcada. Vase mercado de la prxima dcada eliminacin base de datos simple de ejemplo, 20 DELETE con subconsulta, 269-271 DELETE, instruccin, 266-268 eliminacin de todas las filas. 268269 visin general de, 266 empresariales, 922-923 aplicaciones empaquetadas, 922-924 aplicaciones, 919-920 cach de datos y, 834-835 madurez del mercado, 920-922 en computadoras porttiles. 796-798, 919~ 920 en red, 56-60 acceso, 57 inconvenientes de, 59 navegacin, 58-59 procesamiento de pedidos y, 57 [N (informacin de negocios), base de datos, 758 integridad de datos y, 278 incorporadas. 922, 935 modificacin aClUalizacin de todas las filas, 274 UPDATE con subconsulta, 274-275 UPDATE, instruccin, 271-274 visin general de, 271
1028
ndice
en el nivel de tablas, 335 explcito. 340, 341 parmetros, 340 por intervalo de espera, 345 bloqueos bloqueo explcito. 340 bloqueo, parmetros, 345 compartido y exclusivo, 336 interbloqueos, 336-339 niveles de aislamiento y, 341-345 niveles, 334-335 tcnicas avanzadas. 339 bloques de instrucciones, 713-715 BNF (Backus Naur Form), notacin, 903, 967 bucles controlados por cursor, 726-729, 746 ejecucin condicional y, 702 ejecucin repetida con, 722-724 SQUPSM, 746-747 bsquedas compuestas. 121-124 catlogo del sistema comenlarios, 465466 entidades en, 454-456 esquema de la informacin de SQL2, 472476 estndar ANSInSO, 453-454 funcin de, 452-453 herramientas de consulta y, 453 infamacin de columnas, 459-463 de privilegios, 471-472 de relaciones, 466-469 de tablas, 456-460 de usuarios, 469-470 de vislas, 463-465 otra informacin, 477 catlogo del sistemas. 800-801 catlogos. Vase tambin catlogo del sistema OCI (Orac1e Cal! Interface), 666667 DBC, 655-656 SQL2, estndar, 396 CENTRALHOST, vnculo a la base de datos, 804-805 CHARACTER_SETS, vista, esquema de la infomacin de SQL, 1008 CHECK_CONSTRAINTS, vista, esquema de la informacin de SQL, 1000 ciclos referenciales, 294-298 clases, bases de datos orientadas a objetos, 840-841 clusulas FROM. Vase FROM, clusula GROUP BY. Vase GROUP BY, clusula HAVING. Vase HAVING, clusula instrucciones SQL y, 76 INTO. Vase INTO, clusula ORDER BY. Vase ORDER BY, clusula resumen de, 254 SELECT. Vase SELECT, clusula SET. Vase SET, clusula VALUES. Vase VALUES, clusula WHERE. Vase WHERE, clusula claves externas cambio, 373-374 consultas padrelhijo y, 139-141 definicin. 363-364 integridad referencial y. 286-287 modelo relacional de datos y, 6668 soporte del catlogo para, 466469 valores Null y, 299-300
fndice
1029
bases de datos (com.) mviles, 922 LTP,758-759
orientadas a objetos. Vase 0008 (bases

de dalos orientadas a objetos) procedimientos almacenados y disparadores y. 701-702 relacionales ejemplo simple. 1517
SQL como, 4
tablas representando conjuntos of objetos, 862863 relacionales orientadas a objetos, 844-850 BLOB, procesamiento. 847850 aLOB, soporte, 846-847 conjuntos. arrays y coleccioneS, 863 LOB, soporte. 845 visin general de, 844-845 tendencias del mercado. Vase tendencias del mercado tendencias en el procesamiento de datos y, 701-702 XML, 889-899
almacenamiento e integracin, 894899

entrada, 892894 intercambio de datos, 894
salida. 890-892
visin general de, 889 XML nativas, 916917 BOOO (bases de datos orientadas a objetos), 839-844 caractersticas de, 840-841 historia de, 839 mercado para, 842-&44 pros y contras de, 842 BEGIN DECLARE SECTION, 508 BEGIN TRANSACTIQN, instruccin. 321 BEGIN ... END, secuencia, 713-714 BETWEEN, test, 113-115 bibliotecas de bases de datos. Vase dblib, API bibliotecas. Vase API (interfaces de programas de aplicacin) BIND, programa, 491-492, 539 Birdstep Technology, 949
BLOB
C. lenguaje comprobacin de errOres y, 499-502 declaracin de variables del anfitrin, 508 GET DIAGNOSTICS, comprobacin de errores, 504 SQL incorporado y, 492-495 cach aplicaciones empresariales y, 834-836 servidores de aplicaciones y, 791-793 cach bean, 789-793 CAE (Common Applicarion Environmenl), 615 clculo de referencias, XML, 896-899 CallableStatement, objeto, JDBe. 687-691
Cal/-Levellnrerface. Vase CLI (Call-Level lnlerface)

caracteres comodn, 117-119 caracteres de escape, 119 carga masiva, 258, 265-266 CASCADE, reglas ALTER TABLE, instruccin, 373 ciclos referenciales, 298 dominios, 375 DROP TABLE, instruccin, 370 reglas de actualizacin, 292-293 reglas de eliminacin, 283-289, 292-294 CASE, expresin, 238-240 CAST, expresin, 236-238
(Binary Large Objecls)
almacenamiento XML y, 894-895 procesamiento especializado, 847-850 bloqueo en el nivel de filas, 335 en el nivel de pginas, 335
claves primarias 12 reglas de Codd y, 68 cambio, 373-374 consultas padre/hijo y, 139-141 definicin, 363-364 integridad referencial y, 286-287 modelo relacional de datos. 64-65 soporte del catlogo para, 466-469 eLI (Cal/Leve/lnterface), 615-652, 975991 atributos, 647652 consultas dinmicas. 637-649 consultas, 631-635, 981-984 cursores con nombre. 636 cursores de desplazamiento, 636 ejecucin de instrucciones, 624-630, 980981 ejemplo, programa. 918-620 errores y diagnsticos, 647-648, 985986 especificacin, 34-35 estandarizacin de, 615-616 estruclUras de datos, 621-623 funciones de. 616-618 gestin de la conexin, 978-979 gestin de los conrroladores, 977 gestin del entorno, 978 llamadas de informacin, 651-653. 986 parmetros dinmicos diferidos, 985 procesamiento de transacciones, 630-631 resumen de rutinas, 975-976 secuencia de pasos en, 618-619 valores de los parmetros, 987-991 valores devueltos. 620, 977 CLIENTES, tabla estructura de, 941-943 contenido de. 944 CLOB (Character Lorge Objecrs) almacenamiento XML con, 895 analizadores y, 895-896 soporte del fabricante de. 846-847 CLOSE, instrucciones consultas dinmicas y, 570 consultas multifila y, 521, 528-529 estndar SQL2, 587 Cloudscape, 922 COALESCE, expresin, 240-241 COBOL, lenguaje SQL incorporado y, 492-505 comprobacin de errores y, 500 CODASYL, modelo. 57
1030
ndice
comprobacin de validez, 280-283 columnas, 281-282 definicin, 277 dominios, 282-283 visin general de, 280-281 comprobacin diferida de restricciones, 303306 computadoras personales. Vase Pe (Personal Computer, computadora personal) Computer Associates, 949-950 Computer Corporation of America, 951 condiciones de bsqueda bsquedas compuestas, 121-124 consultas multitabla, 141142 consultas simples, 108 sintaxis de SQL, 972 condiciones de bsqueda de grupos. Vase HAVING, clusula condiciones de bsqueda, subconsultas, 213 225 ALL, test. 223-225 ANY, test, 219223 test cuantificados, 219 test de comparacin, 213-215 test de existencia, 217-219 test de pertenencia a conjuntos, 215217 conexiones SQL, estructuras de datos CLI, 621, 623-624 conjunto de caracteres internacional, 186 conjuntos anidados, 860 conjuntos de caracteres ASCII y EBCDIC, 185-186 internacional, 186 conjuntos de filas, JDBC, 695 conjuntos, 861-871 bases de datos relacionales orientadas a objetos y, 845 consulta. 867-868 definicin, 863866 manipulacin, 868-869 procedimientos almacenados y. 869871 CONNECT TO, instrucciones, 803-804 consorcio X/Open europeo. 615 constantes cadenas, 8687 fecha y hora. 8889 numricas, 86-89 simblicas, 89 visin general de, 85-86 constantes de cadena, 86-87 constantes constantes constantes constantes de fecha, 88-89 de hora, 88-89 numricas, 86 simblicas, 89
ndice
1031
CocId, Dc. E. F. ("Ted") 12 reglas, 68-70 historia de SQL y. 26 modelo relacional de. 59 cdigos de error, transportabilidad de aplicaciones y. 36 cdigos de estado. eLl, 620 cdigos de valores de parmetros, eLl. 987991 colas de conexin IOBC, 670 ODBC, 656-657 COLLATIONS, vista. SQL esquema de la informacin, 1009 COLUMICPRIVILEGES, vista. esquema de la informacin de SQL, 1004
columnas
adicin, 371-372 calculadas, 102-105 catlogo del sistema y, 455, 460-463 coincidentes (reuniones), 138 coincidenles mltiples. 142 concesin de privilegios, 441 de agrupacin consultas agrupadas y. 194 mltiples, 196-198 valores Null y. 199-201 definicin, 359-362 eliminacin. 372-373 nombres, 81 valores de datos, 61-64 COLIDmS, vista, esquema de la informacin de SQL, 995-997 comentarios, catlogo del sistema, 465-466 COHMENT, instruccin, D82, 466 COHMIT TRAN5ACTION, instruccin, Sybase, 323 COHMIT, instrucciones ANSJlISO, modelo de transacciones, 320 comprobacin diferida de restricciones y, 303 cursores y, 534 gestin de transacciones CLI, 630-631 procesamiento de transacciones y, 317 319 protocolo de compromiso de dos fases, 828-830 SQL interactivo y, 321 CommonApplication Environment (CAE), 615 compensacin del enlace, caracterstica, ODBC, 659
vista, esquema de la informacin de SQL, 1002 CONSTRAINT_TABLE_USAGE, vista, esquema de la informacin SQL. 1001-1002 constructoras de toma de decisiones, 720 consultas. Vase tambin subconsuhas ad hoc, 1I agrupadas. 192201 columnas de agrupacin, 194 mltiples columnas agrupadas, 196198 procesamienlo, 195~ 196 restricciones sobre, 198~ 199 valores Null en columnas de agrupacin, 199201 almacenes de datos y, 771-772 avanzadas. 234-254 especificacin SQL2, 248-249 expresiones de consultas, 250-254 expresiones que devuelven escalares. 236-242 expresiones que devuelven filas, 242 246 expresiones que devuelven tablas, 246-249 visin general de, 234-236 clusulas de. 254 CL!, 631-635 correlacionadas, 231 datos coleccin. 867868 de columnas columnas calculadas, 102-105 seleccin, 101lD2 todas las columnas, 105106 de resumen, 181-197 agrupadas. 192-196 AVG( J, 184 clusula H1I.VING sin GROUP BY, 206 clusula HAVING y, 201-205 COUNT( 1, 186-188 DISTINCT. palabra clave, 191192 funcin de columnas. 181-183 MIN( l Y MAX( l, 185186 mhiples columnas agrupadas, 196~ 198 procesamiento de funciones de columnas, 188-189 restricciones sobre condiciones de bsqueda de grupos, 205
CONSTRAINT_COLUMN_USAGE,
restricciones sobre consultas agrupadas. 198-199 SUM( 1, 183-184 valores Null, 189~191, 199-201,205 de una nica fila, SQL incorporado, 514 521 NOT FOUND. condicin. 5 J 6 recuperacin con eSlructuras de datos, 519 recuperacin de valores Null, 517-519 variables de enlrada y salida del anfitrin, 520 visin general de. 514-517 de una nica labia, 127 definicin, 4 dinmicas, 557570 CL!, 637-649 CLOSE, instruccin. 570 dblib, API, 609-615 DECLARE CURSOR, inslruccin, 565-566 DESCRIBE, instruccin. 563-565 ejemplo, programa, 559-562 FETCH, inslruccin. 569 OPEN, instruccin. 565-568 pasos en, 557 SQL2, 584-588 visin general de, 557-558 expresiones, 970-972 herencia de tablas y, 860 instruccin SELECT y. 95-98 instrucciones SELECT y. 17 muItifila, SQL incorporado. 521-530 CLaSE, instruccin, 528 cursores de desplazamiento, 528-530 cursores, 524 DECLARE CURSOR, instruccin, 524-526 FETCH, instruccin, 526-528 OPEN, instruccin, 526 visin general de. 521-523 multitabla alias de tabla y. 154-155 aplicacin a tres o ms tablas, 143-145 aspectos de rendimiento con. 156 autorreuniones y, 151154 ejemplo de dos tablas, 136-137 equirreuniones y, 137 multiplicacin de tablas y, 157158 nombres de columnas calificados y, 148-150 notacin de la reunin externa, 166168
1032
ndice
JDBC, 670-675 controladores de tipo 1, 670-673 controladores de tipo 2, 673-674 controladores de tipo 3, 674-675 controladores de tipo 4, 675 objelo, 841 OCI, 662-664 ODBC,653 rutinas de gestin para, 977 soporte del SGBD, 570 corchetes ([ D, 968 COUNT( 1, 182, 186-188 CREATE, instrucciones, 356, 382 CREATE ALIAS, instrucciones, 376 CREATE ASSERTION, instrucciones, 301, 374-375 CREATE DOKAIN, instrucciones, 375 CREATE INDEX, instrucciones, 381-382 CREATE PROCEDURE, instrucciones 382 funciones de, 706 parmetros de entrada y salida, 707-708 variaciones del dialecto del SOBO, 707708 CREATE RQW TYPE, instrucciones, 852 CREATE SCHEMA, instrucciones, 397-399 CREATE SNAPSHOT, instrucciones rplica de tablas y, 810-812 rplicas esclavas y, 813-815 CREATE TABLE, instrucciones, 361-369 almacenamiento fsico, 367-369 creacin de bases de datos, 22-23 definiciones de elaves primarias y externas, 363-364 definiciones de columna, 359-362 definiciones de tablas, 358, 941-943 Infonnix herencia, 858861 tipos de datos fila, 850-852 MATCH FULL, opcin, 299-300 MATCH PARTIAL, opcin, 300 Oracle, 866 restricciones de comprobacin, 366-367 restricciones de unicidad, 366 valores ausentes y predeterminados, 362-363 CREATE TRIGGER, instrucciones, 735-736 CREATE TYPE, instrucciones, Oraele, 853855, 866-869 CREATE VIEW, instruccin, 405 criterio de seleccin de filas, equirreuniones, 141-142 cubos de hechos, 762-764 cursiva, elementos de la sintaxis SQL especificados en, 967~968 cursores actualizaciones y eliminaciones basadas en cursores, 530-535 CL! y, 636 consultas multifila y. 521-524 cursores de desplazamiento, 528530, 636 instruccin DECLARE CURSOR y, 524-525 instrucciones basadas en cursores, 524-528 posicionamiento con, FETCH y CLaSE, 526 procesamiento de transacciones y. 534 repeticin de procedimientos almacenados basados en cursores, 725-729 SQUPSM y, 747-748 cursores con nombre, CLl. 636 cursores de actualizacin, 691 cursores de bloque, ODBC, 659 cursores de desplazamiento CL!,636 consultas multifila y, 528-530 instruccin FETCH y, 531 JDBC, 668, 691-693
ndice
1033
consuhas (conr.) reglas para el procesamiento, 158159 reuniones externas por la izquierda y por la derecha. 163-166 reuniones internas y externas, 159-163 reuniones simples (equirreuniones). Vase reuniones simples (equirreuniones) reuniones sin igualdad. 147-148 reuniones y. 137-139 ___ seleccin de todas las columnas y. 150-151 resultados, 97101 simples bsquedas compuestas. 121-124 columnas calculadas, 102-105
condiciones de bsqueda, 108
consultas de una nica tabla, 127 filas duplicadas, 106}07 ordenacin de resultados,124-127 seleccin de columnas. 101-1 02 seleccin de filas, 107-108 test de comparacin, 109-113 test de encaje de palrones, 117-119 test de pertenencia a conjuntos, IIS117 test de rango. 113-115 test de valores NULL,119-121 todas las columnas, 105-106 UNION, operaciones, 128131 uniones mltiples, 132-133 SQU, 235-236 SQL2. Vase consultas avanzadas XML, 910-916 conceptos de XQuery, 911-914 procesamiento en XQuery. 914-916 visin general de, 910-912 contenido de elemento vaco DTD,902 XML Schema, 908 contenido s610 elemento, XML Schema, 908 CONTINUE, instrucciones, 724 contraseas, usuario, 429431 control de acceso, 21-22 control de flujo, instrucciones, 724, 745-747 controladores bases de datos relacionales orientadas a objetos y. 845 CL!, 621-622 de condiciones, SQUPSM, 749-750 descriptor. 646-647
Database 2. Vase DB2 (Databast! 2) datos adicin. Vase bases de datos, adicin a almacenamiento, 847 compatibilidad, 800 .de instantneas, 810-812 eliminacin. Vase bases de datos, eliminacin de modificacin. Vase bases de datos, modificacin ordenacin en almacenes de datos, 768 proteccin, 2122 requeridos, 278, 279-280 resumen, 19-20 vistas mltiples, 11 DB2 (Database 2) actualizaciones de vistas y, 416 almacenamiento fsico, 369 arquitectura de base de datos nica y, 388 bloqueos mltiples. 336 cdigos de tipos de datos SQLDA, 564 COMMENT, sintaxis de la instruccin, 466 consultas en SQL dinmico y, 587588 dialectos de SQL dinmico y, 571-574 grupos de usuarios, 432 informacin de permisos, 471 reglas de actualizacin. 291-292 reglas de eliminacin, 289290
soporte de disparadores, 309.310 soporte de SQL en, 9 SYSCAT.COLUMNS, vista, 461-462 SYSCAT. KEYCOLUSE, vista, 468 SYSCAT. REFERENCES, vista, 467 SYSCAT. TABLES, vista, 456-458 SYSCAT.VIEWS, 463 versin de IBM de. 28-29 dBASE,45 dbbind ( ), 604 tlbdata ( ), 605-607 dbgetrow ( 1, 607-608 dblib, API, 594~614 actualizaciones posicionadas, 608-609 comparadas con SQL incorporado, 595-597 consultas dinmicas, 609-615 funciones. 594-595 interaccin entre los programas y el servidor SQL, 595-597 lotes de instrucciones, 598-599 manejo de errores, 599-602 procesamiento de consultas recuperacin aleatoria de filas, 607-608 recuperacin de valores Null, 604-605 recuperacin mediante punteros, 605 607 . visin general de, 602-604 visin general de, 594 dbnextrowl 1,604-606 dbresults{ l, 599 DEALLOCATE PREPARE, instrucci6n, 576577 DECLARE CURSOR, instruccin, 521, 524-525, 533-534, 565-566 DECLARE TABLE, instruccin, 495496 DEFERRA.BLE, restriccin, 305 definicin de datos dinmicos, 11 sintaxis de las instrucciones SQL, 967969 definicin de tablas, 358-374 adicin de columnas, 371-372 almacenamiento fsico, 367-369 ALTER TABLE, instruccin, 370-374 claves primaria y externa, 363-364, 373-374 CREATE TABLE, instrucciones, 359, 359-369 definiciones de columna, 359-362 DROP TABLE, instruccin, 369370 eliminacin de columnas, 372-373 restricciones de comprobacin, 366-367 restricciones de unicidad, 365-366 valores ausentes y predeterminados, 362363
1034
ndice
instruccin, 549 tests, 217 FETCH. instruccin, 526-527, 569-570 FROM clusula y, 155 funcin de columnas. 183 GET DIAGNOSTICS, instruccin, 503 GRANT, instrucciones, 438-439 INSERT sobre varias filas, 262 instruccin SELECT nica, 514-515 instruccin UPDATE posicionada, 530-531 IS NULL, test, 124 LOCR TABLE, instruccin, 341 NULLIF, expresin, 241 OPEN, instruccin, 526, 566 PREPARE, instruccin, 547548 REVORE, instrucciones, 444 subconsultas, 210 test de comparacin de subconsultas, 214 test de comparacin, 110 test de ~Ilcaje de patrones, 117 test de pertenencia a conjuntos de subconsultas, 215 test de pertenencia a conjuntos, 117 test de rango, l 13 UPDATE, instrucciones, 272 WHENEVER, instruccin, 504-506 WHERE, clusula, 121 dialectos de SQL dinmico, 570574 comparacin entre Oracle y OB2, 571-574 conversin de tipos de datos y, 574 visin general de, 570 DIFFERENCE, operaciones, consultas SQL2, 250-253 dimensiones multinivel, almacenes de datos, 766-768 DISCONNECT, instruccin, SQL, 804 disparadores, 735-743 consideraciones sobre, 742 estndares, 312-313, 753-754 integridad referencial y, 310-311 Orade PUSQL y, 741742 SPL de Informix y, 739741 tendencias en el procesamiento de datos y, 736 Transact-SQL y, 737-738 ventajas/inconvenientes, 311-312, 701 702 visin general de, 735-736 dispositivos de mano, 796-798 dispositivos lgicos de bases de datos, Sybase, 368
EXECUTE, EXISTS,
ndice
distincin de la caja (maysculas y minsculas) nombres de elementos y atribulos de XML,881-882 palabras clave de SQL, 96 DISTINCT tipos de datos, Informix, 872 DISTINCT, palabra clave consultas de resumen y, 191-192 filas duplicadas y, 106-107 Documelll Type Definitiolls. Vase OTD
1035
definicin dinmica de dalos, 11 DELETE posicionada, instruccin, 267. 531534 DELETE. instrucciones
DELETE con subconsulta, 269271
eliminacin de datos. 20 eliminacin de todas las filas. 268-269 herencia de tablas y. 860 problemas de la clusula WHERE y. 893 visin general de, 266281 DELETE, privilegio. 433 DESCRIBE, instrucciones consultas dinmicas y, 563-565 estndar SQL2. 585 Dracle y DB2, 571-572 descriptores CL!, 646-647 OCI, 665-666 SQL dinmico, 578-584 estructura de, 578-579 instrucciones de gestin, 579-580 SET DESCRIPTOR, instruccin, 582583 desigualdad (<, operador, 213-224 diagramas sintcticos ALTER TABLE, instruccin. 370-374 bucles controlados por cursor en SQU PSM,748 CASE, expresin, 238-240 CAST, expresin, 236 CLOSE, instruccin, 528 COALESCE, expresin, 240 COMMIT y ROLLBACK, instrucciones, 318 constructora de valores de filas, 242 constructora de valores de tablas, 246 control de flujo en SQLIPSM, 747 CREATE INDEX, instruccin, 380381 CREATE PROCEDURE de SQUPSM, 746 CREATE SCHEMA, instrucciones, 398 CREATE TABLE, il)Strilcciones, 360 CREATE TRIGGER, instruccin, 754-755 CREATE VIEW, instruccin, 405 DB 2COMHENT, instruccin, 466 DECLARE CURSOR, instruccin, 524, 565566 DELETE, instruccin, 266-281 DESCRIBE, instruccin, 563 DROP SCHEMA, instrucciones, 399 DROP TABLE, instruccin, 369 estructuras de bloque en SQUPSM, 749 EXECUTE IMMEDIATE, instruccin, 541
(Documem Type Defillitioll.r)

documentos comparacin de SQL con XML, 886 tipos XML y SQL, 885 XML bien formado, 882 DOMAIN_COLUIoRCUSAGE, vista, SQL DOMAIN_RESTRICCIONES, vista, esquema de la informacin de SQL, 1006-1007 OOMAINS, vista, esquema de la informacin de SQL, 1005-1006 dominios, SQL2, 478 DROP ALIAS, instrucciones, 376 DROP ASSERTION, instrucciones, 375 DROP INDEX, instrucciones, 382 DROP SCHEMA, instrucciones, 398-399 DROP TABLE, instrucciones, 23, 369-370 DROP VIEW, instrucciones, 419-420 DROP, insU1Jcciones, 357, 382 OTO (Documem Type Defillitiolls) comparacin de XML Schema con, 901-904 definicin, visin general de, dinmico, contenido web (dYllamic web
! ELEMENT, OTO. 901 elemento con cualquier contenido, 902-909 elemento contenido, XML Schema, 908 elemenlo de contenido mixto, 902-903 elemento s610 elemento, OTO, 902-903 elemenLo slo texto, OTO, 902-903 elementos de instrucciones, 973 en SQL, instrucciones, 973 jerarqua OTO, 901903 nombres y constantes SQL, 973 XML Schema, 908-910 XML y SQL, 886-889 XML, 882-883 y atributos, 886-889 eliminaciones con cursores, 530-534 Ellison, Larry, 925 Empress Software, 951-952 encapsulacin bases de datos orientadas a objetos y, 842 procedimientos almacenados y, 730-731 END DECLARE SECTION, 508-509 ElIlerprise Application Software (EAI), 810 Ellterprise Java Beans. Vase EJB
(Emerprise Java Beans)

entidad bean, EJB, 781-782, 785-789 entorno SQL, estructuras de datos CLl, 621623 entrada, XML, 889, 892-894 equilibrio de carga, 818-820 equirreuniones. Vase reuniones simples (equirreuniones) errores en tiempo de ejecucin, 497 esquema de definicin, 472 esquema de la base de datos, 392393 esquema de la infonnacin, SQL, 1007-1008 ASSERTIONS, vista, 1001 catlogo del sistema y, 476 CHARACTER_SETS, vista, 1008 CHECK_CONSTRAINTS, vista, 1000 COLLATIONS, vista, 1009 COLUMlCPRIVILEGES, vista, 1004. COLUMNS, vista, 995-997 CONSTAAINT_COLUMN_USAGE, vista, 1002-1003 CONSTRAINT_TABLE_USAGE, vista, 1002 DOMAIN_COLUMN_USAGE, vista, 1007-1008 DOMAIN_RESTRICCIONES, vista, 1006-1007 DOMAINS, vista, 10051006 KEY_COLUMN_USAGE, vista, 1001 REFERENTIAL_CONSTRAINTS, vista, 999
content), 776-777
EAI (Enterprise Applicatioll Software), 810 EBCDIC, conjunto de caracteres, 185-186 ejbCreate( 1, mtodo, 788-789 ejbLoad ( 1, mtodo de retrollamada, 788-789 ejbPostCreate ( l, mtodo, 788 ejbRernove ( ), mtodo, 788
EJB (Enterprise Java Beans)

estandarizacin del servidor de aplicaciones y, 778-779 mejoras, 790-791 visin general de, 780 ejbStore ( l, mtodo de retrollamada, 788, 789 ejecucin asncrona, OOBC. 658 ejecucin condicional, 702, 720-722
1036
ndice
fndice
1037
esquema de la informacin, SQL (com.) SCHEMATA, visla, 994-995 SQL_LANGUAGES, vista, 1010-1011 TABLE_PRIVILEGES, vista, 1003 TABLE_RESTRICClONES, vista, 999 TABLES. vista, 995 TRANSLATIONS, vista, 1009-1010 USAGE_PRIVILEGES, vista, 1004-1005 VIEW_COLUMN_USAGE. vista. 998999 VIEW_TABLE_USAGE, vista, 998 VIEWS, vista, 997 visin general de, 993994 esquemas. Vase tambin esquema de la informacin de SQL almacenes de dalos, 762 base de dalos. 393 en copo de nieve. 768 en estrella, almacenes de datos, 764-766 SQLl,392-393 SQL2, 396-399 estaciones de trabajo, 796-798 estndares. Vase tambin ANSIIlSO estndares; SQUPSM (SQUPersistent SlOred Modules) bases de datos orientadas a objetos, 842 capacidades de los objetos, 844 disparadores, 312-313, 742-744, 753-754 estndares XlOPEN, 32 Internet e integracin de los servicios de red, 934-935 interoperabilidad entre bases de datos, 34-35 otros estndares, 34 procedimientos almacenados, 742744 servidores de aplicaciones, 778-779 SQL, 9, 927-931 SQL:1999,875 SQL1 actualizaciones de vistas, 4 J 6 esquemas, 392-393 estructura de la base de datos, 386 reglas de eliminacin, 288 restricciones sobre consultas INSERT sobre varias filas, 265 SQL2 catlogo del sistema, 472-476 catlogos, 395 consultas avanzadas. Vase consultas avanzadas consultas dinmicas y, 584-588 dominios gel sistema, 476 esquemas, 396-399
instrucciones DELETE y, 271 instrucciones dinmicas, 575-577 privilegios ampliados, 433-435 reglas de actualizacin, 291-292 reglas de eliminacin y, 288-289 restriccin de comprobacin de dominios, 282-283 restricciones avanzadas, 302-303 restricciones de columna de comprobacin, 281-282 restricciones de integridad, 299-300 reuniones cruzadas y de unin, 174-176 reuniones externas, 172173 reuniones internas, 169-172 reuniones multitabla, 176-179 SQLDA, 577-584 tipos de datos, 580581 tipos de restricciones, 302 SQL3,753 transportabilidad de aplicaciones, 35-38 XML, 900 XQuery, 911-912 estructura de la base de datos, 386-399 ANSUIS, estndares, 392-399 arquitectura de base de datos nica, 387388 arquitectura de mltiple ubicacin, 390-391 arquitectura de mltiples bases de datos, 388-390 mltiples servidores, 392 transportabilidad de aplicaciones y, 38 visin general de, 386-387 estructura SQL en ingls, 10 estructura, XML y SQL, 886 estructuras de alto nivel, SQL, 10 estructuras de bloque, 703, 747-749 estructuras de datos CLl, 621-623 consultas de fila nica y, 519-521 ODBC, 653-654 etiqueta de apertura, XML, 88 I-882 etiquetas, HTML, 800-801 eXcelon, 952 excepciones. Vase manejo de errores EXECUTE IMMEDIATE, instrucciones, 541544,575 EXECUTE, instrucciones ejecucin en dos pasos, 545548 EXECUTE con SQLDA, 549-557 EXECUTE con variables del anfitrin, 549 SQL2, 575, 586
test, 217-219 instrucciones, 724 exploracin de conexiones, ODBC, 656 expresiones de consultas, SQL2. 250-254 clusula FROM y. 253 operaciones UNION. INTERSECT y DIFFERENCE, 250-253 visin general de, 250 de fila, SQLl, 235 de ruta, XQuery. 912916 de tabla, SQU, 235 que devuelven escalares, 236-242 CASE, expresin, 238-240 CA-ST, expresin, 236238 COALESCE, expresin. 240-241 NULLIF, expresin, 241242 que devuelven filas, 242246 comparaciones de valores de fila, 245 constructora de valores de fila, 242244 subconsultas con valores de fila, 244 246 que devuelven tablas, 247-249 constructora de valores de tablas, 246-247 especificacin de consultas, 248-249 subconsultas con valores de tablas, 247-248 SQL, 89-90, 970-972, 972-973 extensibilidad, 12-13 eXtensible Markup 1Anguage. Vase XML (eXtensible Markup .Language) eXtensible Stylesheet Language Transformation (XSLT), 910911 extensiones SQL, almacenes de datos, 768-769 extractos de tablas, 808-810
EXISTS/NOT EXISTS, EXIT,
fabricantes. Vase tambin tendencias del mercado acceso a bases de datos remotas, 803806 bases de datos distribuidas, 800801 capacidades orientadas a objetos, 841-844 de bases de datos, 947966 A2i,948 Arbor Software. 948 Birdstep Technology, 949 Computer Associates, 949 Computer Corporation of America, 951 Empress Software, 951 eXcelon, 952
Gupta Technologies, 952 Hewlett Packard. 953954 IBM Corporation, 954-955 Informix Software, 955-956 lista de, 948 Microsoft Corporation, 956957 MySQL AB, 957 Objectivity, 958 Oracle Corporation, 958960 Persistence Software, 960 Pervasive Software, 960 PointBase, 961 PostgreSQL, 961 Quadbase Systems, 962 Red Brick Systems, 962 Sybase. lnc., 963 TimesTen Performance Software, 965 Versant Corporation, 965 servidores de aplicaciones, 779 FALSE, palabra clave, 121 Federal In/ormarion Processing Standard (FIPS), 9, 32 FETCH, instrucciones consultas dinmicas y, 569 mu1tifila consultas y, 521, 526528 estndar SQL2, 587 filas adicin a bases de datos, 257 valores de datos y. 62-63 filas duplicadas consultas simples, 106-) 07 funcin de columnas y, 191 I92 filas, consultas filas duplicadas, 106107 seleccin. 107-108 FIPS (Federal In/ormarion Prdcessing Standard), 9. 32 FOR, bucles, 722-724, 726-727 FOREACH, bucles, 727-728 FOREIGN KEY, clusula, 363-364 FORTRAN, lenguaje, 492-495 FROH, clusula consultas multitabla y, 155 expresiones de consultas y, 253254 instrucciones SELECT y, 96-98 fuentes de datos, lDBC, 694 funcin de columnas AVG( 1,184 COUNT( 1,186-188 MIN( 1 y MAX( l, 184186 procesamiento, 188-190
1038
ndice
gupos de trabajo Novell. 48 Gupta Technologies. 952 identificadores de usuarios, 428-432 autenticacin de usuarios, 429-431 grupos de usuarios. 431-432 seguridad en tiempo de ejecucin y, 490491 visin general de, 428-429 IF ... TREN ... ELSE, 713, 720-721, 745-747 IlIustra Software, 922 capacidades orientadas a objetos. 844 IMS (lnformalion Management Syslem), 56 IN (informacin de negocios), base de datos, 758 IN, test, lI5-ll7. Vase tambin test de pertenencia a conjuntos (IN) 115117 independencia del fabricante. 8. 654-655 ndices asociativos, 381 como estructura de almacenamiento, 378 CREATE INDEX, .instruccin, 380-382 de rboles B. 381 de rboles T. 381 de mapas de bits, 381 DROP INDEX, instruccin, 381 soporte para, 3 tipos de, 38] ventajas de, 379 informacin de diagnstico. CLI, 647-649, 985-986 informacin de negocios (lN), base de datos, 758 informacin de relaciones, catlogo del sistema, 466-469 lnformation Management System (IMS), 56 lnformix Software acceso a bases de datos remotas, 805-806 capacidades orientadas a objetos. 844 estructura de la base de datos, 358 informacin de claves primarias y externas, 469 informacin de tablas, 459 mercado de las bases de datos empresariales y, 922 perfil del fabricante, 955-956 SYSCOLUMNS, 462 infraestructura de la industria informtica, SQLy,14 Ingres LOCK TABLE, instruccin. 340 proyecto Ingres, 28-29 ubicaciones mltiples de almacenamiento, 367
ndice
1039
funcin de columnas (eom.)

SUM( 1, 183-184
Valores nulos y. 189-191

visin general de. 181-183
funciones almacenadas, 715-717 funciones predefinidas, estructuras del lenguaje SQL, 9091
gestin de bases de dalos para trabajo en grupo, 48-5 J gestin de errores CL!, 648-649, 985-986
dblib Y SQL incorporado. 602 dbl ib, API, 599602

lOBC,691 OCI, 666-667 procedimientos almacenados, 729-731 SQLiPSM, 749-751 gestin de errores, SQL incorporado instruccin WHENEVER y, 502-505 SQLCODE y. 497-500 SQLSTATE y. 500502 tipos de errores, 497 gestin de la conexin, OCI, 663 gestor de controladores lOBC, 676-679 ODBC, 653-655 get { J. mtodo de acceso, EJB, 790 GET DESCRIPTOR, instrucciones, 585 GET DIAGNOSTIC$, instrucciones, Sal, 503504 GET READY. mensaje, 828-830 GOTO, instrucciones. 724 grandes sistemas (mainframesJ, 796798 de mM (mainframesJ, 44 GRANT OPTION, clusula, 441-444, 446448 GRANT, instrucciones, 438-444 permisos y, 21 privilegios de columna, 440 transmisin de privilegios con la clusula GRANT OPTION, 441-444 visin general de, 438-440 GROUP BY, clusula. Vase tambin consultas agrupadas; RAVING, clusula instruccin SELECT y. 97 mltiples columnas agrupadas, 196-198 vistas y, 410 grupos, usuarios. 431-432 guerras de pruebas, fabricantes de bases de dalos, 926-928
hardware del servidor de bases de datos. 925-926 HAVING, clusula, 201-206 consultas correlacionadas y, 231 instruccin SELECT y, 97 restricciones sobre, 205 subconsultas y, 207-209, 230233 uso sin GROUP BY, 206 valores Null y, 205 visin general de, 201-205 <header>, etiqueta, XML, 881-882 herencia de tipos, 858 herencia, 856-862 base de datos orientada a objetos, 840 definicin, 856 tabla, 858-861 visin general de, 856-858 herramientas de anlisis de datos, 760 herramientas de carga de almacenes de datos, 760 herramientas de consulta, 452 Hcwlett Packard, 953-954 hijo. Vase relacin padrelhijo HTML (HyperText Markup LanguageJ, 879-881
IBM Corporation
acceso a bases de datos distribuidas y, 820-827 estrategia de base de datos unificada,
44
estructura de la base de datos y, 357 lnea de productos de, 920 LOCK TABLE, instruccin, 340-341 mercado de las bases de datos empresariales y, 922 obligaciones de SQL, 9 perfil del fabricante, 954-955 SAA (Systems Applicotioll Architecture), 34 soporte de datos BLOB, 846 versin de 082, 28-29 identificadores de autorizacin. 393394, 429. Vase tambin identificadores de usuarios identificadores de objetos, 845
inicializacin, OCIo 663-664 IN5ERT de una nica fila, 258-262 insercin de todas las columnas, 261 insercin valores Null, 261 visin general de. 258-261 IN5ERT sobre varias filas, 258, 262-265 INSERT, instrucciones adicin de datos, 20 CREATE TABLE instrucciones y, 359 entrada XML y, 893 insercin de todas las columnas, 261 insercin de valores Null, 261 INSERT de una nica fila, 258-262 INSERT sobre varias filas. 262265 tablas replicadas y, 810 INSERT, operaciones. XML, 894 IN5ERT, privilegio, 432 instruccin DELETE con bsqueda, 267-268 instrucciones estructura de, 7577 estructuras de datos eLI y, 621 lista de, 75-76 palabras clave potenciales, 79-80 palabras clave, 78-79 procesamiento. 483-485 sintaxis, 79 SQL incorporado, 492-495 integridad bases de datos distribuidas e, 800 de datos comprobacin de validez. 280-283 datos requeridos, 279-280 integridad de las entidades, 283285 integridad referencial. Vase integridad referencial prdida de, 277278 reglas de negocio, 307-313 restricciones avanzadas, 300-307 restricciones, 277-278 vislas e, 404 de las entidades definicin, 278 unicidad y valores Null e, 284-285 referencial. 285300 ciclos referenciales. 294-298 claves externas y valores nulos e, 299-300 definicin, 278 disparadores e, 310-311 eliminaciones en cascada y actualizaciones, 292-294
1040
ndice
integracin de SQL con, 13-14 Internet e integracin de los servicios de red, 934-935 orientacin a objetos de, 676-677 servicios web, 52 Java2 Enterprise Edilion. Vase J2EE (Java2 Enterprise Editian) JDBe (conectividad con base de datos Java), 669-696 cursores de desplazamiento y de actualizacin, 691-693 enfoque basado en API, 483 historia y versiones, 669670 instrucciones lIamables, 687-691 instrucciones preparadas, 984-687 integracin de SQL en, 13-14 manejo de errores, 691 objetos y mtodos de la API, 676-679 opciones avanzadas, 694-696 procesamiento de consullas, 682-684 procesamiento de instrucciones, 679-681 recuperacin de metadatos, 693-694 tipos de controladores, 670-676 JNDI (Java Naming & Direcrory Interface), 669 JO IN, operaciones, SQL2, 250 ITP (Java Transaction Prolocol), 827 lenguajes de bases de datos, 11 de marcas, XML, 879-880 de modo dual, SQL, 482 de programacin consuhas sobre una sola fila y sobre varias y, 514 estructuras de datos y, 519 incorporacin de SQL en, 485 lipos de datos y, 509510 de secuencias de comandos, 776-777 lenguaje, SQL constantes, 86-89 expresiones, 8990 funciones predefinidas, 90-92 instrucciones, 75-76 LDO y LMO y, 355-357 nombres, 77-81 tipos de datos, 81-86 valores Null, 91-92 visin general de, 4-5 LIKE, test, 117119 LIST, datos coleccin, 863, 868 lista de elementos, SQL, 967 listado de componentes, base de datos, 55-56 llamada a procedimientos almacenados, 708-710 llamadas de informacin, CLI, 651-652 llaves ({ 1), 968LMD (lenguaje de manipulacin de datos) funciones de, 355-356 sintaxis de las instrucciones y, 969-970 SQL como, 257 LOB, procesamiento, Oracle, 848-850 LOB (Large Objects). Vase tambin BLOB (Binary Large Objecrs); CLOB (C/aracler lArge Objects) almacenamiento XML con, 895 analizadores y, 895-896 manipulacin OCI de, 667668 soporte para, 844-845 LOCK TABLE, instruccin, 340-341 lotes de instrucciones dblib, API, 598-599 OOBC, 658
MATCH FULL, opcin, TABLE, 299-300
ndice
1041
integridad (COllt.) integridad de datos. Vase integridad referencial problemas de corrupcin. 286-288
instrucciones CREATE instrucciones
MATCH PARTIAL, opcin, CREATE TABLE, 300

MAX(
reglas de actualizacin e. 284292 reglas de eliminacin e. 288-292 visin general de, 285-286 rplicas aClUalizables e, 813 transacciones distribuidas e, 830 interbloqueos bases de datos distribuidas e, 799-801 procesamiento de transacciones e, 338-340 intercambio de datos, XML. 889-894
interfaces de programas de aplicacin. Vase API (Application Program Interfaces) interfaces en el nivel de llamadas, 5. Vase tambin eLl (Cal/-Leve! Interface) interfaces grficas de usuario (GUn, 831 IntemationaJ Standards Organization (1S0),
9
Internet
acceso a bases de datos, 7. 13
conexiones. 796-798
gestin de grandes volmenes de datos, 836 integracin de los servicios de red y, 934-935 interoperabilidad, 34-35 interoperacin entre base de datos, 34-35 1NTERSECT, operaciones, SQL2, 250-253 1NTO, clusula, instrucciones INSERT, 258 15 NULL, test, 119-121 ISO (Intemalional Standards Organization),
KEY_COLUMICUSAGE,
vista, esquema de la informacin de SQL, 1001
J2EE (Java2 Enterprise Edition) estandarizacin de servidores de aplicaciones, 778779 integracin de SQL en, 13-14 servicios web, 52 Java Database Conneclivity. Vase roBC (conectividad con base de datos Java) Java Naming &.: Directory Interface (INDI), 669 Java Transaction Protocol (JTP), 827 Java. Vase tambin JDBC (conectividad con base de datos Java) API, 668-669 integracin de objetos y, 936
LDO (lenguaje de definicin de datos) CREATE, DROP y ALTER, 356 funciones de, 355-356 gestin de objetos con, 382-385 lenguaje de administracin de bases de datos, SQL, 7 de consultas interactivo, 6, 10 de definicin de datos. Vase LOO (Data Definilion Language) de manipulacin de datos. Wase LMD (lenguaje de manipulacin de datos) de pasarela de bases de datos, SQL, 7 de procedimientos almacenados, 702, 869-870 de programacin de bases de datos, SQL,
7, JI
mainframes. Vase grandes sistemas (mainframes) marcadores, ODBC, 660
1,182,184-186 mayor que (, operadores, 219, 881-884 menor que ), operador, 219, 881-884 mercado de la prxima dcada, 931-937 almacenes de datos, 931-933 bases de datos de rendimiento ultraalto, 933-934 bases de datos distribuidas, 931 bases de datos incorporadas, 935 integracin de objetos, 935-937 Internet/integracin de los servicios de red, 934-935 MetaDara, objetos, JDBC, 676, 693-695 metadatas, recuperacin, 693-695 meladatos XML definicin, 899 .' OTOs y, 901-904 visin general de, 899901 XML Schema y. 903 mtodo constructor, Oracle, 865 mtodos de acceso, EJB 2.0, 790 de seleccin, EJB, 791 del buscador, EJB, 791 orientados a objetos, 841 procedimientos almacenados y, 872-875 microbases de datos, 922 Microsoft Corporation . .NET framework, 52 mercado de las bases de dalas empresariales y, 920 perfil del fabricante, 956-957 soporte de ODBC, 35 soporte de SQL, 8-11 SQL Exception, roBC, 69J SQL Server. Vase SQL Server Windows. Vase Windows, sistemas operativos MINt J, 182, 184-186 minicomputadoras, 44-45 modelo de datos jerrquico, 55-56 acceso, 56 bases de datos de lista de componentes y, 55 IMS como ejemplo de, 56-57 inconvenientes de, 5859 XML,886
1042
ndice
NOT, palabra clave, 121124 notacin con puntos, 854 NULL, valor, lest, 109, 119-121 NULLIF, expresin, 241242 OCI (Oraele Cail Interface), 662-669 conexin con el servidor de Oracle. 663666 controladores, 662663 ejecucin de instrucciones, 664-665 funciones, 661 gestin de transacciones, 666667 manejo de descriptores, 666 procesamiento de consultas, 665666 visin general de, 660 ODBC (Open Database COllllectivity), 652. 660. Vase tambin CL! (CallLevel Interface) arquitectura, 653 basado en el estndar CLl, 34-35 capacidades extendidas. 656-660 enfoque API de, 482483 entre plataformas, 35 estructura de, 653-654 funciones del catlogo, 655 independencia del fabricante y, 654 soporte de Mjcrosoft para SQL en, 811 visi6n general de, 652 OOMO (Object Data Management Group), 843 OFICINAS, tabla contenido de, 944945 copia, 808 estructura de, 941-943 OlAP (Online Analytical Processing), 51.
ndice
1043
modelo relacional de datos, 59~68 12 reglas de Codd. 68-71 caractersticas de SQL y. JO claves externas, 67-68 claves primarias, 64-65 ejemplo base de dalos, 6().62 procesamiento de pedidos y. 60 relaciones. 66-67 tablas. 62-64 visin general de, S9 modelos de datos. Vase tambin modelo relacional de datos bases de datos en red, 5659 jerrquico. 55-56 sistemas de gestin de archivos. 53-55 modelos de transacciones, 319-323 motores de bases de datos. 6 msg_rtn ( 1, 600 multiprocesamiento simtrico (SMP, Symmelric Multiprocessing) ampliacin horizontal con, 791 ganancias de rendimiento de, 923-925 versiones y. 350 MULTISET, dalos coleccin, 863. 868-869 MySQL AB, 957
Native. API, controladores, lDBe. 673-674 navegacin. XQuery, 912-913 NCLoe, tipos, Oracle. 846-847 Ncubos (Ndimensional). 762-764 .NET. entorno. 52 neutrales ante la red, controladores, IDBC. 674-676 niveles de aislamiento, 340-345 nodo atributo, XQuery. 911 nodo documento, XQuery, 911 nodo elemento, XQuery, 911 nodo texto, XQuery, 911 nodos, XQuery, 911 nombres calificados, espacios de nombres XML,909 nombres de columnas calificados. 81. 149-150 nombres de tablas calificados, 80 NOT DEFERRABLE, restriccin, 305 NOT EXISTS/EXISTS/, test, 217219 NOT FaUNO, condicin, 516-517 NOT NULL, restricci6n, 302
OASIS (Organization for the Advancement of Structured Information Systems), 901 Object Data Management Group (ODMO), 843 Object Linking y Embeddillg (OLE). 10 Objectivity, fabricantes de bases de datos, 958 objetos almacenamiento con grandes, 894-895 analizadores y grandes. 895896 bases de datos orientadas a objetos. 839-844 bases de dalas relacionales orientadas a objetos, 844850 binarios de gran tamao. Vase BlOB (Binary Large Objects) conexin, JDBC, 676, 678. 680 conjuntos/arrays/colecciones, 861-871 consulta, 867-868 definicin, 863-866 manipulacin, 868869 procedimientos almacenados y, 869-871 visin general de, 861863 de caracteres de gran tamao. Vase CLOB (Character Large Objects) de gran tamao. Vase BlOB (Binary Large Objects); ClOB (Character Large Objects); LOB (Large Objects) de seguridad. 432 gestionados. 382385 herencia. 856-861 tabla, 858-861 visin general de, 856 instruccin, JDBC, 676, 679681 mtodos y procedimientos almacenados. 872-875 seguridad y, 426 soporte en SQl:1999, 875 tipos abstractos de datos (estructurados), 850-856 tipos de datos definidos por el usuario, 871-872 XML y SQL, 886
922
OLE (Object Linking and Embedding), 10
OLTP (Online Transaction Processing) almacenes de datos y, 49-50, 758-759 aplicaciones, 924, 926-927 consultas multitabla y, 156 proliferacin de SQL y, 47-48 Online Analytical Processing (OLAP), 51,922 OPAQUE, tipos de datos, lnformix, 871 Open Database ConneclivjlY. Vase ODBC (Open Database Conneclivity) OPEN, insl11Jcciones consultas dinmicas y, 566-568 consultas multifila y, 521, 526 estndar SQL2, 586 operaciones aritmticas, 90, 177 masivas, ODBC. 659 por lotes, lDBC, 669 operadores de comparacin. Vase tambin test de comparacin
< (menor que). 219. 881, 884 <> (desigualdad), 222, 224 > (mayor que), 219. 881, 884 ALL, test, 223 ANY, test, 219 optimizacin bases de datos distribuidas y, 800 de instrucciones, 485 OR, palabra clave, 121124 Oracle Caillnterface. Vase OCI (Oracle Call Interface) Oracle Carporation acceso a bases de datos remotas, 804-805 arquitectura de base de datos nica y, 388 cach de la base de datos. 793 capacidades orientadas a objets. 844 consultas de columnas, 460 conversin de tipos de datos, 855 dialectos dinmicos, 571574 enfoque de fabricante nico de, 922-924 estructura de la base de datos, 357-358 xito de SQl y, 920 hardware del servidor, 925 informacin de claves primarias y externas, 469 informacin de tablas, 458 LOCK TABLE, insl11Jcci6n, 340 manipulacin de datos coleccin, 868 mercado de las bases de datos empresariales y. 920 mtodos, 872-874 notacin de la reunin externa, 168 perfil del fabricante, 958-960 primer producto SGBD comercial de, 29 procedimientos almacenados, 870-873 procesamiento BLOB, 848850 rplica de tablas, 810812 soporte BLOB, 846-847 tablas anidadas en consultas SQl, 867 tipo de datos coleccin. 866 tipos abstractos de datos, 853855 Oracle PUSQl, 74)743 ordenacin de datos. Vase ORDER BY, clusula aRDER BY, clusula, 97, 124-127,210 Organization for the Advancement of Structured Information Systems (OASIS), 901 orientacin a objetos. SQL, 13,935-936
1044
ndice
PoinlBase, 961 PostgreSQL, 961 predicados, 108. Vase tambin condiciones de bsqueda prefijos, espacios de nombres XML, 910 PREPARE, instruccin. 545-548, 576 PreparedStatement, objeto. lDBC, 684 687
4
ndice
procedimientos almacenados (cont.) parmetros de salida, 716-719 procesamienlo de datos y, 701 repeticin con cursores. 725-729 SQUPSM y, 752-753 valores devueltos, 715-717, 719-720 variables, 710713 ventajas de, 7304732 procesamiento de consultas
dblib
1045
OS/2, 47 consultas mullitabla y, 159-163 definicin, 161 notacin. 166~168 reuniones externas reuniones externas por la izquierda y por la derecha. 163166 SQL2, estndar, 172173
PRIMAR)' KE),
palabras clave, SQL. 967

<para>, eliqueta, XML, 881-882
parmetros array' OOBC, 659 bloqueo, 339, 345 con nombre, Oracle y DB2, 571 de entrada, 627628, 707-708 de salida, 707-708. 717-719 dinmicos diferidos. 985 ejecucin de instrucciones con, 626-630 entrada, 627-629 paso diferido, 629 paso diferido de parmetros, 629 pe (Personal Compurer, computadora personal) acceso estndar a bases de datos para, 35 dalos procesamiento comerciales y. 796798 proliferacin de SQL y, 45-47
PEDIDOS, labia
comparacin del orden de compra XML con, 884-885 contenido de, 945 estructura de, 941-943 permisos proteccin de datos y, 21-22 vislas del catlogo de DB2y, 471 Persistence Software, 960 persistencia gestionada por hean definicin, 787 gestionada por contenedor y, 789-790 uso, 788 gestionada por el contenedor aplicacin, 788-789 definicin, 787 limitaciones de, 789-790 Pervasive Software, 960 ?LlSQL,741-742 planes de aplicacin instrucciones y,.485 optimizacin, 491192, 539
clusula, 263-264 restriccin, 302 privilegios de propiedad, 435-436 privilegios, 432-436 ampliados, 433 4435 catlogo del sistema y, 455, 471-472 concesin, 438-441 propiedad, 435 retirada, 444-450 tablas y vistas y. 432 transmisin, 441-444 visin general de, 426 problemas de datos inconsistentes, 328-330 de la actualizacin perdida, 326-327 de la insercin fantasma. 327-330 de lectura desfasada, 328 de lectura no repetible, 327 de los datos no comprometidos, 327-328 procedimientos almacenados. Vase tambin SQLJPSM (SQUPersiste1l1 Stored Modules): disparadores aplicacin de ejemplo, 704-706 aplicaciones cliente/servidor y, 832834 bases de datos relacionales orientadas a objetos y, 845 bloques de instrucciones, 713-715 colecciones y, 869-871 con nombre, 703 conceptos, 702-703 creacin, 706-708 definidos por el sistema, 733 ejecucin condicional, 720-722 ejecucin repetida, 722-724 estndares para, 743-744 externos, 7344735 implementaciones SGBO de, 733 instrucciones de flujo de control, 724 llamada, 708-710 llamada, 736 manejo de errores, 729-731 mtodos y, 872875
comparadas con SQL, 604 recuperacin aleatoria de filas, 607-608 recuperacin con punteros, 605607 recuperacin de valores Null, 604-605 visin general de, 602-604 inSlrucciones SQL2. 584 JDBC, 682-684 OCI, 664-666 OOBC, 659-660 reglas, 234 de instrucciones con API CLI, 624-630 dblib, API, 598-599 JDBC, 679-681 OCI, 664-666 OOBC, 658 de transacciones bloqueo explcito, 340 bloqueos compartidos y exclusivos, 338 CLI, 630-63 I cursores y, 534 ejemplos, 315-318 instrucciones COMMIT y ROLLBACK y, 317-318 instrucciones, 970 interbloqueos, 338-339 modelos de transacciones, 319 4323 niveles de aislamienlo, 341-345 niveles de bloqueo, 333-335 OCI, 666-668 parmetros de bloqueo, 345 problemas de la actualizacin perdida, 326327 de la insercin fantasma, 330-331 de los datos inconsistentes, 328330
de los datos no .comprometidos, 327-328 proliferacin de SQL y, 47 registro histrico de transacciones y, 323-325 simultaneidad, 331-333 tcnicas avanzadas de bloqueo, 339 versiones y, 346-350 interactivo de transacciones. Vase OLTP (Online Tran.saclion Processing) multiusuario, 326 paralelo, 771 producto canesiano de dos tablas, 157, 174 producto de dos tablas, 157 PRODUCTOS, tabla contenido de, 946 copia, 808 4810 estructura de, 941-943 programadores, 1I programas, SQL incorporado desarrollo, 486-490 implemenlacin, 490 4492 propietarios de red, controladores, lDBC, 675-676 proyecto System/R, 28 prueba del dbito y el crdito, 926 prueba TPl, 926 pruebas de Transaction Processing Council (TC?), 926-928 puenles JDBClODBC, 670-673 puestos de datos, 761 punteros, 605-607. Vase tambin controladores puntos de revisin, 321, 670
Quadbase Syslems, 962
ROA (Remote Database Acce.s.s), 34-35 READ COMMITTED, nivel de aislamienlo, 342343 READ ONCOMMITTED, nivel de aislamiento, 342-343 recuperacin aleatoria de filas, 607-608 recuperacin de dalas. 17-19,69. Vase tambin consullas recuperacin de una nica fila, 111 recuperacin, bases de datos distribuidas, 801 Red Brick lntelligelll SQL (RISQL), lenguaje, 769
1046
ndice
relaciones mltiples, 67 reuniones simples (equirreuniones) y, 139141. 145-147 Relational OnLine Analytie Processing (ROLAP). 51. 922 rendimiento almacenes de datos, 769772 bases de datos de rendimiento ultraalto, 933 bases de datos distribuidas, 799-800 bases de datos orientadas a objetos, 843 de la carga, 769-771 del hardware, 923925 en tiempo de ejecucin, 730 consultas multitabla y, 156 hardware, 923-925 transacciones distribuidas, 830 vistas y, 404 REPEATABLE READ, nivel de aislamiento, 342-343 rplicas actualizables, 813815 acceso a bases de datos remotas, 810-812 arquitecturas, 816-821 bases de datos empresariales, 835 compromisos, 814-815 equilibrio de carga y, 818 esclavas, 813-814 extractos de tablas, 808-810 maestras, 813-815 tablas,8lO812 REPRESENTANTES, tabla, 941944 resolucin de referencias, XML, 897-900 restriccin referencial (FOREIGN KEY), 302 restricciones asertos, 300-302, 375 avanzadas, 300306 asertos, 301-302 comprobacin diferida, 303-306 restricciones, 300-306 SQL2. 302-303 tcnicas avanzadas de bloqueo, 339-346 tipos de, 300-301 CHECK, restricciones, 281-283, 302 comprobacin diferida, 303-306 de columna, 281282, 300 de comprobacin columnas y, 281-282 comparadas con disparadres, 312 CREATE TABLE, instrucciones y, 365-367 restricciones (eont.) dominios y, 282283 restricciones avanzadas y, 302 de dominio, 282-283, 300, 375 definicin, 375 restricciones de tabla y, 300 visin general de, 282283 de tabla, 299"300 de unicidad instrucciones CREATE TABLE y, 365 integridad de las entidades y, 284-285 definicin, 374-376 lista de, 277279 NOT NULL, restricciones, 279-280, 302 PRIMARY KEY, restriccin, 302 referenciales (FOREIGN KEY), 286, 302 UNIQUE, restricciones, 284-285, 302 RESTRICT, regla de eliminacin instruccin ALTER TABLE y, 373 instruccin DROP TABLE, 370 reglas CASCADE, 288-289, 297 RESTRICT, reglas, 375 resultados de las consultas rutinas de descripcin, 982-984 rutinas de procesamiento, 981-982 Resul tSet (conjunto de resultados), objetos. JDBC. 677. 683-684 retrollamadas, 896 reuniones. Vase tambin consultas multitabla cruzadas, SQL2, 173176 de unin, SQL2, 173-176 definicin, 137 externas por la derecha, 163-167 externas por la izquierda, 163167 internas consultas multitabla y, 159-163 definicin, 161 SQL2 y. 169-172 mltiples,,132133 multitabla, 176-179 simples (equirreuniones), 137-147 aplicacin a tres o ms tablas, 143145 claves primarias y externas y, 139141. 147 consultas padreJhijo, 139-141 criterio de seleccin de filas y, 141-142 mltiples columnas coincidentes, 142 visin general de, 137-139 sin igualdad, 147 subconsultas y, 225-226
REVOKE,
fndice
1047
Red Brick Syslems, 922, 962 redes. Vase tambin bases de datos distribuidas arquitectura centralizada, 38-39 arquitectura cliente/servidor, 40-41 arquitectura de servidor de archivos, 39AO arquitectura mullicapa, 42 reduccin de trfico, 731 REFERENCES, privilegio, SQL1, 433~435 referencia de la sintaxis. SQL, 967-973 condiciones de bsqueda, 972 elementos de instrucciones, 973 elementos simples, 973 expresiones, 972 expresiones de consultas. 970--972 instrucciones de cursor, 970 de definicin de datos, 967-969 d~ procesamiento de transacciones, 970 de manipulacin bsica de datos, 969-970 referencias correlacionadas. 229 externas, 212213, 229 REFERENTIAL_CONSTRAINTS, vista, esquema de la informacin de SQL, 999 registros histricos de transacciones, 323 327. 848 reglas de actualizacin, DB2 actualizaciones en cascada, 292-293 ciclos referenciales y, 297 visin general de, 290-292 consistencia, integridad de datos, 272 eliminacin, 288293 ciclos referenciales y, 297 eliminaciones en cascada, 292-293 estndar SQL 1, 288 estndar SQL2, 288-290 eliminacin, 375 negocio definicin, 278-279 procedimientos almacenados y, 732 negocio de integridad de datos, 306-313 disparadores, 308313 visin general de, 306-310 relacin padre/hijo integridad referencial y, 286287 modelos jerrquicos y, 5556 modelos relacionales y, 66-67
instrucciones, 444-450 clusula GRANT OPTION y, 446~448 estndares ANSIIISO, 448-450 permisos y, 21-22 visin general de, 444-446 RISQL (Red Briek /melUgem SQLJ, lenguaje, 769 ROLAP (Relational 01lLine Analytie Processing), 5 1, 922 ROLLBACK TRANSACTION, instruccin, Sybase. 321 . ROLLBACK, instrucciones comprobacin diferida de restricciones y, 303 cursores y, 534-535 gestin de transacciones eLl y, 630-631 modelo de transacciones ANSI/ISO y, 319 procesamiento de transacciones y, 317319 protocolo de compromiso de dos fases, 828-830 SQL interactivo y, 321 ruta con raz, expresin, XQuery, 912913 ruta relativa, expresin, XQuery, 912913 rutinas de estado, CLl, 985-986 CLl Vase CLI (eall-Level Jnteiface) SQL. 978-980 creacin, 745 ejecucin de instrucciones, 979 gestin de instrucciones, 979 gestin de la conexin, 978-979 gestin del entorno, 978
SAA (Syslems Applieation Arehiteelure), 34 salida. XML. 889. 890-891 SAVE TRANSACTION, instruccin, Sybase, 321 SAX (Simple XPl for XML), analizadores, 896 SCHEMATA, vista, esquema de la informacin de SQL. 994-995 secuenciabilidad de transacciones, 332 secuencias, bases de datos relacionales orientadas a objetos, 845 secuencias de ordenacin, transportabilidad de aplicaciones, 37 seguridad conceptos, 426-428 en tiempo de ejecucin, 491-492 GRANT, instrucciones, 438-444 identificadores de usuarios, 428-432 objetos de seguridad, 432433 privilegios, 433-436
1048
ndice
set ( ), mtodo de acceso, EJB, 790 SET DEFAULT, regla de eliminacin, 289290 SET DESCRIPTOR, instruccin, 582-583, 585 SET LOCK, instruccin, 345 SET NULL regla de eliminacin, 289-290 SET TRANSACTION, instrucciones, 335, 344 SET, clusula, 274, 893 SET, datos coleccin, 863, 868-869 SOBO (sistema gestor de bases de datos) AP1 y, 482-483 aplicaciones empresariales empaquetadas y, 922-923 arquitectura centralizada. 38-39 cliente/servidor, 40-41 de servidor de archivos, 39-40 multicapa, 42 componentes de, 6 controladores, 570 CREATE PROCEDURE, instrucciones, 707-708 CREATE/DROP/ALTER, convenios, 383385 definicin, 4 fabricantes, 8 funciones de, S grupos de usuarios, 432 historia de, 25-26 informacin de claves primarias y externas, 466-469 de columnas, 462 de permisos, 471 de tablas, 458-459 de vistas, 463-465 del catlogo del sistema, 477 modelos de datos, 53 motor de la base de datos como el corazn de, 6 papel de SQL en, 25-26 parmetros de bloqueo, 345 primeros productos, 28-30 privilegios, 435 / procedimientos almacenados. 703, 710713, 733-734 soporte de los ndices, 380 SQL dinmico y, 538, 571-574 tablas del sistema, 455-456 tipos de datos, 509-510 vistas actualizacin, 416 eliminacin, 419 manejo, 403 SGBDR (sistema gestor de bases de datos relacionales), 26 SOML (Standard General Markup ulIIguage), 880881 signo de la arroba (@), 804-806 signo del dlar ($), 927 signo del euro (), 914 Simple XPI para XML (SAX), analizadores~ 896 sinnimos, 376 . creacin de bases de datos y, 376-377 transparencia de datos remotos, 806-807 sistema gestor de bases de datos relacionales (SGBDR), 26 sistemas basados en UNIX, 43, 45 sistemas de gestin de archivos, 5355 sistemas gestores de bases de datos. Vase SOBO (sistema gestor de bases de datos) sitios Web arquitectura de tres capas, 777-779 primeras implementaciones de, 775777 SMP (Symmetric Multiprocessing). Vase multiprocesamiento simtrico sobrecarga de procedimientos almacenados. 751-752, 874 solicitudes distribuidas, bases de datos distribuidas, 825-827. solicitudes remotas, 82] soporte de aplicaciones empresariales, 12-13 spaddserver ( >, procedimiento almacenado del sistema, 804 spdropserver ( ), procedimiento almacenado del sistema, 804 SPL (Stored Procedure Language), 703, 869-870 SPL de Informix, 739-741 SQL (Structured Query Language), 2632 aceptacin comercial, 30-32 caractersticas y ventajas, 7-14 como lenguaje de modo dual, 481 como primeros productos SOBD, 28-29 estndares. Vase, estndares, SQL estandarizacin y, 928-931 hitos en el desarrollo de, 2627 instrucciones. Vase instrucciones lenguaje. Vase lenguaje, SQL papeles de, 6-7 proliferacin de, 42-52 almacenes de datos y, 49-51 aplicaciones distribuidas en Internet, 51-52
ndice
1049
seguridad (cont.) procedimientos almacenados y, 731 REVOKE. instrucciones, 444-450 viSlaS y. 404, 436-438 SELECT. clusula. 96. 98 SELECT, instrucciones. 95-98 caracterstica UNION, 128 clusula FROM, 98 clusulas de. 96-97 consultas agrupadas y. 195-196 consultas de una nica fila y. 513-514 consultas multitabla y. 158-159 funcin de columnas en, 188}89 HAVING, clusula, 203-204
manipulacin de datos. inslI1.lcciones, 969-970

recuperacin de datos, 17 resultados de las consultas de, 128 seleccin de todas las columnas, 105-106, 150-152 5ELECT. clusula. 98 subconsultas comparadas con, 209-210 tablas reproducidas. 810 SELECT, privilegio, 433 SERIALIZABLE, nivel de aislamiento, 342 series de hora, 768 servicios de red, 934935 servicios web, SI-52 servidores de aplicaciones acceso a bases de datos con sesiones bean, 782-784 acceso a entidades con sesiones hean, 785789 arquitecturas de sitios Web de tres capas y, 777-779 bases de datos access y, 779-780 cach,791-794 en Internet, 919 funcin de, 42 mejoras EJB 2.0, 790791 primeros sitios Weby, 775-777 tipos EJB, 780-781 visin general de, 775 servidores de redes de rea local, 796~798 servidores mltiples, 392 servidores. Vase tambin arquitectura cliente/servidor conexin con el servidor de Oracle, 663-664 estructuras de mltiples servidores, 392 ganancias de rendimiento en, 923-925 sesin bean, EJB, 781784, 781782 con estado, 782-783, 783-785 sin estado, 782-783
bases de datos para trabajo en grupo, 48-49 estrategia de IBM sobre base de datos unificada, 44 minicomputadoras, 44-45 PCs, 45-47 procesamiento de transacciones y, 47 sistemas basados en UNIX, 45 proyecto SystemlR y, 28 redes. Vase bases de datos distribuidas rutinas. Vase rutinas, SQL semejanzas de XML con, 885-886 sintaxis. Vase referencia de la sintaxis, SQL SQL Access Group, 34-35. 615 SQL CalJ-Levellnterface. Vase CLI (Cal/Level Interface) SQL Communications Area (SQLCA), 497-498 SQL Data Area. Vase SQLDA (SQL Data Area) SQL dinmico conceptos, 539-541 ejecucin de instrucciones en dos pasos, 544-547 EXECUTE con SQLDA, 549-557 EXECUTE con variables del anfitrin, 549 EXECUTE IMMEDIATE, instruccin, 541-544 EXECUTE, instruccin, 548 limitaciones de SQL esttico y, 537-539 PREPARE. instruccin, 547 transportabilidad de aplicaciones y, 37 SQL esttico. Vase tambin SQL incorporado, 800 SQL incorporado actualizaciones y eliminaciones con cursores, 530-535 conceptos, 486 consultas de una nica fila, 514-521 NOT FOUND, condicin, 5 I6 recuperacin con estructuras de dalaS, 519-520 recuperacin de valores NulJ, 517-519 variables del anfitrin de entrada! salida y, 520 visin general de, 514-516 consultas multifila, 521530 CLOSE, instruccin, 528 cursores de desplazamiento, 528-530 cursores y, 524 DECLARE CURSOR, instruccin, 524-525 FETCH, instruccin, 526-528
1050
ndice
ndice
1051
SQL incorporado (cont.)

instruccin, 526 visin general de. 521-524 cursores y procesamiento de transacciones. 534 dbl ib, API y. 597 declaraciones de labias. 495-497 desarrollo de programas. 486-490 implementacin de programas. 490-492 instrucciones simples. 492-495 limitaciones de, 537-538 manejo de errores, 497-500, 500-502, 602 procesamiento de consultas, 604 tipos de errores, 497 variables del anfitrin declaracin, 508-509 (ipos de datos y, 509-510 valores Null y, 511513 visin general, 506-508 visin general de, 5, 481-483 WHENEVER, instruccin, 502-505 SQL interactivo consultas de una nica fila y. 514 consultas multifila y. 514, 521 instrucciones COMMIT y ROLLBACK y, 321 instrucciones INSERT Y. 261 transportabilidad de aplicaciones y, 35-36 SQL para programacin. Vase lambin SQL incorporado papel de SQL en, 320 procesamiento de instrucciones y, 484-485 tcnicas, 479-483 transportabilidad de aplicaciones y, 35 SQL Server. Vase tambin dblib, API estructura de la base de datos, 357 infonnacin de claves primarias y externas, 469 infonnacin de tablas, 459 interaccin de los programas, 597 notacin de la reunin externa, 166 sistemas operativos Windows y, 46-47 SYSOBJECTS, tabla, 459 tabla SYSPROTECTS, 472 tabla SYSUSERS, 470 tendencias del mercado y, 919-920 SQUPSM (SQUPers;slent Stored Modules), 743-753 capacidades de los procedimientos almacenados, 752-753 caractersticas principales de, 743-745 control de flujo, instrucciones, 745-747
OPEN.
creacin de rutinas SQL, 745 estructura de bloques, 747-749 gestin de errores, 749-751 operaciones de cursor, 747-748 sobrecarga del nombre de las rutinas, 751752 SQL: 1999, 753-755, 875 SOL_LANGUAGES, vista, esquema de la informacin de SQL, 1010-1011 SQL2 dinmico, 575-588 consultas, 584-588 instrucciones, 575-577 SOLDA y, 577-584 tipos de datos, 580-5&1 visin general de, 575 SQLCA (SQL CommunicatiollS Area), 516 SQLCODE manejo de errores con, 497498 NOT FOUND, condicin, 516
SQLDA
,.
(SQL Data Area), 549-557
cdigos de tipos de datos para DB2, 564 instrucci6n EXECUTE y, 555-557 instrucci6n OPEN y, 567 Oracle y DB2, 572-574 partes fija y variable de, 551-557 paso de datos a la instrucci6n EXECUTE, 550-551 SQLError 1 ), 647-649 SQLException, mtodos, JDBC, 691
SQLSTATE
condici6n NOT FaUNO, 516 manejo de errores con, 500-502 SQLVAR, 562-564
subconsultas (com.) subconsultas correlacionadas, 228-230 test ALL, 223-225 test ANY, 219-223 test cuumificados, 219 test de comparaci6n, 213-215 test de existencia, 217-219 test de pertenencia a conjuntos, 215-217 UPDATE con subconsulta, 274-275 visi6n general de, 207-208 subtipos, 857 SUH( l, 183-184 supertipo, 857 Sybase, Inc., 44-45 acceso a bases de datos remotas, 803-804 aumento de importancia, 922923 dialecto Transact-SQL y, 321 dispositivos lgicos de bases de datos, 368 estructura de la base de datos, 357-358 gestin de objetos, 382 perfil del fabricante, 963-964 procedimientos almacenados y, 832-833 soporte de datos BLOB, 846 SYSCAT.COLUKNS, vista, DB2, 461-462 SYSCAT. KEYCOLUSE, vista, DB2, 468 SYSCAT. REFERENCES, vista. DB2, 467 SYSCAT _TABLES, vista, DB2, 456-458 SYSCAT. VIEWS, DB2, 463 SYSCOLUMNS, Infonnix, 463 SYSOBJECTS, tabla, SQL Server, 459 Systems Applicalion Architecture (SAA), 34 SYSUSERS, tabla, SQL Server, 470
Standard General Markup Language

(SGML), 880 subconjuntos de tablas verticales, arquitectura de rplica, 817-818 subconjuntos de tablas horizontales, arquitectura de la rplica, 816-817 subconsultas anidadas, 226-228 clusula HAVING y, 230-233 clusula WHERE y, 210-212 comparadas con SELECT, instrucciones, 209-210 correlacionadas, 228-230 DELETE con subconsulta, 267 limitaciones of SQL 1, 234 referencias externas, 212 reuniones y, 225-226 subconsultas anidadas, 226-228 tablas, 62-64. Vase tambin consultas mu1titabla anidadas, Dracle en consultas SQL, 867 manipulaci6n, 868 procesamiento, 870-871 visi6n general de, 866-867 bases de datos relacionales orientadas a objetos y, 845 catlogo del sistema y, 454, 456460 claves externas, 67-68 claves primarias, 64-65 como objeto de seguridad, 432 con espejo, arquitectura de las rplicas, 818 consultas, 135137, 143-148 contenido de, 944946
del sistema 12 reglas de Codd y, 70 catlogo del sistema y, 452 SGBD y, 455-456 transportabilidad de aplicaciones y, 36 estructura de filas y columnas, 63-64 estructura de, 941-943 fuente, 401, 402 herencia, 858861 multiplication, 157-158 nombres, 8081 rplica. Vase rplica SQL incorporado, 495-496 vacas, 64 virtuales, 7071 TABLE_PRIVILEGES, vista, esquema de la informaci6n de SQL, 1003 TABLE_RESTRICCIONES, vista, esquema de la informacin de SQL, 999 TABLES, vista, esquema de la infonnaci6n de SQL,995 TPC (Transaction Processing Council) pruebas, 926-928 tendencias del mercado, 920-931 aplicaciones empresariales empaquetadas, 922-923 diversidad y segmentacin, 922-923 estandarizacin, 928931 ganancias del rendimiento del hardware, 925-926 guerras de pruebas, 926-928 hardware de los servidores de bases de datos, 925-926 importancia de SQL, 919-920 madurez del mercado empresarial, 920921 terminacin del programa, 320 test cuantificado (ANY y ALL) ALL, test, 223-225 ANY, test, 219223 visi6n general de, 219 de comparaci6n, 109-113 comparaciones de valores. de filas, 246 encaje de patrones, 117-119 pertenencia a conjuntos, 115-117 rangos, 113-115 recuperaci6n de una nica fila, 111 reuniones y, 147-148 subconsultas y, 213-215 valores nulos y, 112-113, 119-121 visi6n general de, 109, 109-11 J
1052
test (con!.)
In dice
transacciones distribuidas, bases de datos distribuidas, 824-825 remotas, 823824 simultneas bloqueo y. 334-348 procesamiento de transacciones y, 331-333 versiones y, 347 Transact-SQL, 308-312, 737-739 TRANSLATIONS, vista, esquema de la informacin de SQL, 1009-1010 transparencia, datos remotos, 806-807 transportabilidad caracterfsticas SQL y, 9 estndares SQL y, 35-38 variaciones de los tipos de datos y, 84-86 TRUE. palabra clave, 121 instrucciones (com.) con subconsulta, 274-275 visin general de, 271-274 UPDATE, privilegio, 433 USAGE_PRIVILEGES, vista, esquema de la informacin de SQL, 1004-1005 usuarios catlogo del sistema y, 455, 469470 grupos de usuarios, 431-433 seguridad y, 426
UPDATE, UPDATE
ndice
1053
de encaje de patrones caracteres comodn y. 117-119 caracteres de escape y. 119 consultas simples. 117-119 visin general de. 109, 117 de pertenencia a conjuntos (IN) cansullas simples. 115-117
subconsuhas, 215-217
visin general de, 109 de rango. 109. 113115 tiempo de compilacin errores, 497 y en tiempo de ejecucin, 485 TimesTen Performance Software, 965 lipo 1, controladores, JDBC. 670-673 tipo 2. controladores. JDBC. 673-674 tipo 3. conlroladores, IDBe. 674-675 lipo 4. conlroladores. JDBC, 675 lipos de datos absLraclos (estructurados), 850-856 bases de datos relacionales orienladas
validacin de instrucciones, 427 valores agregados, almacenes de datos, 768 ausentes y predeterminados, 362-363 de datos de filas y columnas, 62-63 devueltos
CLl.977
procedimientos almacenados, 715-717
a objetos y, 844
definicin. 852-855 manipulacin, 855-856 visin general de, 850-852 ANSI/ISO SQL. 83-84 cdigos SQLDA para DB2, 564 coleccin, 863-868 datos de consulta, 867-868 definicin, 863-866 manipulacin de datos, 868-869 procedimientos almacenados y, 869-871 conversin de enteros a decimales, 90 de filas, lnformix, 850-852 definidos por el usuario, 844, 871-872 definicin del usuario, 844, 871-872 dialectos dinmicos y, 574 Orade vs. DB2, 574 problemas de transportabilidad y, 84-86 SGBD. 82-83 SQL2. 580-581 transportabilidad de aplicaciones y, 36 variables del anfitrin y, 509-512 XML Schema, 904-908 tipos de filas con nombre, lnformix, 852853. 856 todas las columnas consultas multitabla y, 150-151 consultas simples y, 105-106 trabajo en grupo, Windows NT, 48
operaciones, 128-130 anidadas, 132 expresiones de consultas SQL2, 250-253 filas duplicadas y, 130-132 mltiple, 131-133 ordenacin de y, 131 UNIQUE, palabra clave, 380 UNIQUE, restriccin, 302 Universal Server de Informix capacidades orientadas a objetos, 844 colecciones y procedimientos almacenados y.869-871 consulta de datos coleccin, 867-868 conversin de tipos de datos, 855 herencia de tablas, 858-861 herencia, 856-858 manipulacin de datos coleccin, 868-869 mtodos y procedimientos almacenados, 873-875 soporte de objetos de gran tamao, 847 tipo de fila con nombre, 852-853 tipos abslractos de datos, 855 tipos de datos coleccin, 863-869 tipos de datos fila, 850-852 UPDATE, instrucciones actualizacin de bases de datos, 21 actualizacin de todas las filas, 274 herencia de tablas y, 861 posicionada, 531-534, 608-609 problemas de la clusula SET/WHERE en, 892-893
UNION,
Null
12 reglas de Codd y. 68-70 bsquedas compuestas y, 121-123 clusula HAVING y, 199-201 claves externas y, 299-300 columnas de agrupacin y,199-201 consultas de una nica fila y, 517-519 definiciones de columna y, 362-363 estructuras del lenguaje SQL y, 91-93 expresin COALESCE y, 240~241 funcin de columnas y, 189-190 recuperacin con dblib, API, 604-605 restricciones de unicidad y, 284-285 reuniones cruzadas y de unin y, 175-176 tests de comparacin y, 112113 variables del anfitrin y, 51J-513 VALUES, clusula, 258, 261 variables con nombre, 703 de entrada del anfitrin, 520 de salida del anfitrin, 520 del anfitrin declaracin, 506-508 entrada y salida, 520 estructura de datos como, 519-520 EXECUTE y, 549 tipos de datos, 509-512
valores Null y, 511-S13 visin general, 506-508 denotacin en XQuery, 912-913 procedimientos almacenados, 710-713 Versant Corporalion, 965 versiones, 346-350 implementacin, 346-350 ventajas/inconvenientes, 350351 visin general de, 346-347 VIEW_COLUHN_USAGE, vista, esquema de la infonnacin de SQL, 998-999 VIE\CTABLE_US1I.GE, vista, esquema de la infonnacin de SQL, 997 VIEWS, vista, esquema de la infonnacin de SQL.997 vistas actualizacin, 414-419 ANSUISQ, estndares, 415-416 comprobacin de actualizaciones, 416-419 opciones del SGBO, 416 visin" general de, 414-415 agrupadas, 409-412 catlogo del sistema y, 455, 463-465 como objeto de seguridad, 432 creacin, 405-414 subconjuntos de filas y columnas, 409 visin general de, 405-412 vistas agrupadas, 410-412 vistas horizontales, 405-407 vistas reunidas, 412-414 vistas verticales, 407409 de mltiples datos, 11 de subconjuntos de filas y columnas, 409 eliminacin, 419-420 funciones de, 401-402 horizontales, 405-407, 436 manejo del SOBO de, 403 materializadas, 420-422 nombres y referencias, 403 restriccin del acceso a columnas con, 436-437 restriccin del acceso a filas con, 438 restricciones sobre la aplicacin de seguridad con, 438 reunidas, 412-414 tablas fuente y, 402 transparencia de datos remotos, 806-808 ventajas/inconvenientes, 404 verticales, 407-409
1054
ndice
bases de datos, 889-899, 916-917 almacenamiento e integracin, 899 entrada, 892-894 intercambio de dalaS. 894 salida. 890~892 visin general de, 889 consultas. 910-916 definicin, 879~881 elementos y atributos, 886-889 entrada XML, 889, 892-894 espacios de nombres, 909-910 integracin de dalaS. 889 intercambio de datos, 889, 894 metadatos. 899~91 O DTD y, 901-903 visin general de, 899-901
W3C (World Wide Web Consortium) definicin, 879-881 estandarizacin de XML, 900 estandarizacin de XQuery, 911 WalMart, 932-933 WHENEVER, instruccin, 502-505 acciones. 504 condiciones de excepcin, 502 ventajas de, 505 \'IHERE, clusula, 96 consultas de dos tablas y. 157 DELETE, instrucciones. 267 problemas con instrucciones UPDATE/ DELETE, 893 seleccin de filas y. 107-108 subconsultas y. 207-208, 210-212 UPDATE, instrucciones, 271273 WHILE. bucles. 722-724, 728-729 Windows. sistemas operativos acceso a bases de datos y, 919920 soporte de SQL en, 8-10 SQL Server y, 4748 trabajo en grupo en Windows NT, 48 World Wide Web Consortium. Vase W3C (World Wide Web Consortium)
894~
XML Schema,
904~91O
XlOPEN, estndares, 34, 615 XA. protocolo, 827
XML (eXtensible Markup Language)

almacenamiento. 894~899 clculo de referencias, 896~899 definicin. 889 objetos grandes y analizadores. 895~ 896 visin general de. 894
para datos, 884-889 salida XML. 889, 890-892 SQL comparado con, 885-886 visin general de, 881-884 XML Pat" iAnguage (XPath), 910-912 XML Schema, 900. 904~91O XML-Data, 900 XPath (XML Path Lallguage), 910 XQuery bases de datos nativas XML y, 916-917 conceptos. 911-914 historia de, 910-912 procesamiento de consultas en, 914-916
XSLT (eXtensible Srylesheet Llmguoge Transformation), 91O~912
st, mensaje, 830

Manual de Referencia SQL

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual de Referencia SQL

Uploaded by

Copyright:

Available Formats

I

Agradecimientos Introduccin ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PARTE 1 Visin general de SQL

2. Una introduccin a SQL

El modelo relacional de datos .,., La base de datos de ejemplo, . "

Arquitectura Arquitectura Arquitectura Arquitectura SQL SQL SQL SQL

centralizada , del 'servidor de archivos cliente/servidor mullicapa _

Tipos de datos ... ,",."., .. ',.,' ............... ,",

' , , , ,., ' _ . .

Funciones predefinidas ., Datos ausentes (valores NULL) Resumen .

La proliferacin de SQL . , . , . . , . , . , , .. , . , SQL y la estrategia de la base de datos unificada de IBM

SQL y las aplicaciones distribuidas en Internet Resumen

4. Bases de datos relacionales

, oO oO_,., , ..... ' ...........

119 121 124 127 128

205 205 206 206

SubconsuJtas y expresiones de consultas ...................

151 154 155

158 159 163

PARTE IJI Actualizacin de datos

257 257 258 262 265

266 266 268 269

PARTE IV Estructura de la base de datos

Creacin de bases de datos

319 321 323 325 326

401 403 404 404

405 405 407 409 410

414 415 416 417 419 420

Eliminacin de vistas (DROP Vistas materializadas * Resumen

Seguridad en SQL .......................................

432 432 436 438

448 450 451

El catlogo del sistema

Dialectos de SQL dinmico ...............................

SQL dinmico y el estndar SQL2

588 591 600

Las API de SQL Conceptos de las API

730 733 733

735 736 737

SQL y los almacenes de dalos

PARTE VI SQL hoy y maana

706 708 710

777 779 780 782 786

SQL y los objetos ......................................

El futuro de SQL .........................................

PARTE VII Apndices Apndice A.

Perfiles de los fabricantes de bases de datos

Gupla Technologies (www.guptaworldwide.com) Hewlett Packard (www.hp.com)

El estndar del esquema de la informacin de SQL ....

IBM Corporation (www.ibm.com) lnformix Software (vase IBM Corporation)

Referencia de la sintaxis de SQL ................

968 969 970 970 970

973 973 97S

Gua de instalacin del eD-ROM

1013 1014 1014 1015 1015 1016

La interfaz del nivel de llamadas de SQL

lnstalacin del software SGBD SQL Microsoft SQL Server 2000 .

Valores devueltos por eL! . Rutinas generales de gestin de controladores.

Brownlow. Jennifer Malnick. Martin Przybyla. Greg Gnntle y Chrisa Hotchkiss.

Organizacin del libro

Nota del editor: segunda del ingls. primera en castellano.

Convenciones usadas en este libro

Por qu este libro es para usted

VISiN GENERAL DE Sal