Manual de Referencia para LeapfrogDescrição completa
Descripción completa
Manual de Referencia para LeapfrogDescripción completa
Descripción: manual de SQL server
SQLDescripción completa
Guía o manual de referencia de VBA para aplicaciones, colecciones y objetos en macros de ExcelDescripción completa
Manual Básico de SQLDescripción completa
Descripción: Manual Referencia c++
manual de referencia oficial de Debian en PDFDescripción completa
manual de referencia oficial de Debian en PDF
Descripción completa
Descripción: sql server 2016 Por docente Gabriela Penaloza
Manual de refencia luaDescripción completa
Descripción completa
Este es una manual para nivel principiantes, esta diseñado para ayudar en el aprendisaje de este poderoso gestor de base de datos, SQL Server 2000, Consta de 194 hojas con ejemplos practicos…Descripción completa
El lenguaje SQL __ _ . El papel de SQL _.•......•.....•.•...... Características y ventajas de SQL , . Independencia del fabricante . Transportabilidad entre sistemas informáticos . Estándares SQL _ __ .' __ .. _. _ . Acuerdos y obligaciones de IBM (DB2) __ . . Obligaciones de Microsoft (SQL Server, ODBC y ADO) Fundamentos relacionales . Estructura de alto nivel en inglés , .. Consultas ad hoc interactivas . Acceso mediante programación a bases de datos. _ _. _ . Vistas múltiples de los datos _. __ _ . Lenguaje completo de base de datos _ __ .. Definición dinámica de datos _ _ _. _ . Arquitectura cliente/servidor . . . Soporte de aplicaciones empresariales . Extensibilidad y tecnología de objetos _.•... Acceso a bases de datos en Internet . Integración de Java (IDBC) . _ _ . Infraestructura de la industria .
4
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
2. Una introducción a SQL Una base de datos simple Recuperación de datos _ Resumen de datos .. ._ _ Adición de datos a la base de datos .. " , ." , ,., Eliminación de datos Actualización de la base de datos Protección de datos . Creación de bases de datos .. Resumen
-_ _.. _. _ _ ,
.
15
.
15
. . . .
19 20 20 21 21
59 .
..
60
62
..
.
,
.
64 66 67
,
68 71
PARTE 11 Recuperación de datos
25
,
. ,
26
_
28 28
,
. _
Estándares de SQL ...................•.. , ....••.....•...... ' Los estándares ANSIJISO ", Otros estándares de SQL "·,, · ODBC y el grupo de acceso SQL SQL y transportabilidad .. . . SQL y redes .,., .. , .. ,.",. .,.,.,,.,., , , , ....• ' , , , . , . oO.,"
oO,
,
··.oO
centralizada , del 'servidor de archivos cliente/servidor mullicapa _
.
,
, _ . .
La proliferación 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
.
, _, ,._
.
_ ,
SQL y las bases de datos de trabajo en grupo ".,', SQL y los almacenes de datos ,.,.,
SQL y las aplicaciones distribuidas en Internet Resumen
4. Bases de datos relacionales .
.. '
..
oO,
Los primeros modelos de datos . Sistemas gestores de archivos Bases de datos jerárquicas Bases de datos en red ..
SQL y la gestión de bases de datos Una breve historia de SQL ,... . . "" Los primeros años .. , , , , Los primeros productos relacionales Productos de mM Aceptación comercial _. _
. , . ".. , . " numéricas , .. , de cadena de fecha y hora simbólicas
,
,.,.,
Funciones predefinidas ., Datos ausentes (valores NULL) Resumen .
40
47
"
8J
Tipos de datos ... ,",."., ..• ',.,' ••......•......... ,",
39
44 45 45
oO
Instrucciones , Nombres ,., , ,., Nombres de tablas Nombres de columnas
29 30 32 32 34 35 36 38 38
44
Fundamentos de SQL
,
,
,.,
81
'
86 86
_ . .
87
'
oO
,
.
'
,
,
.
... _.....••.....••.....••......•.
88
89 89 90 91 93
.
95
La instrucción SELECT _•......•......•......•......•••.... La cláusula SELECT _....•......••.....•......••.... , . La cláusula FROM ..... Resultados de las consultas , . Consultas simples ., ,."...... ,.,., ' Columnas calculadas _. _. . _ _ _ _ Selección de todas las columnas (SELECT *) _
95 98 98 98
Consultas simples
Filas duplicadas (DISTINCT) .. ,
, oO oO_,., , .....• ' ......•.....
Selección de filas (cláusula WHERE) . . , Condiciones de búsqueda ," ,., ,.,." . El test de comparación (=. <>. <, <=, >, >=) . El test pe rango (BETWEEN) .. _ . . _ . _ .•.• _ ....••... El test de pertenencia a conjuntos (IN) . _ . El test de encaje de patrones (LIKE) "
JOl 102 105
106
107 109 110
113 115
117
x
Contenido
El lesl de valores nulos (15 NULL) . Condiciones compueslas de búsqueda (ANO. QR Y NOT) . Ordenación de los resultados de las consultas (cláusula ORDER BY) . Reglas para el procesamienLO de consuhas sobre una sola tabla . Combinación de los resultados de las consultas (UNION)" . . Uniones y filas duplicadas * Uniones y ordenación" .. . __ . Uniones múltiples" . __ . _......•......•.................... Resumen. . . . . . . . . . . . . . . . . . .. _......•.....•......••...... 7.
Consultas multitabla (reuniones)
Un ejemplo de consulta con dos tablas ......•.............•..... Reuniones simples (equirrcuniones) . _ _. Consultas padrelhijo . Reuniones con criterios de selección de filas . Encaje de múltiples columnas . Consultas con tres), más labIas ................•.......... Otras cquirreuniones .. . _. _ . Reuniones sin igualdad _ _...............•........... Considemciones sobre SQL y consultas multitabla ...•......••.. Nombres calificados de columnas ...............•......•... Selecciones de todas las column
8. Consultas de resumen Funciones de columna _•...... _ Cálculo del lolal de una columna (SUM) Cálculo de la media de una columna (AVG) . . . . • . . . . . . • • . . . _ . . Búsqueda de valores extremos ('UN y MAX) Recuento de valores de datos (COUNT) .........•..•.•.•••••. _
Contenido
119 121 124 127 128
130 131 132
133 135
Funciones de columna en ht lista de selección . Valores NULL y funcione de columna _. Eliminación de filas duplicadas (DISTINCT) ...........••.... Consultas de agrupación (CI
205 205 206 206
SubconsuJtas y expresiones de consultas .....••....••..........
207
Uso de las subconsullas _. _ _ _. _. Concepto de subconsulta . _.. _ __ . _...•.... Subconsultas en la cláusula WHERE . Referencias externas _.. _ . Condiciones de búsqueda en las subconsultas ... _.... _ El test de comparación 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 cláusula 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 209
135
137 139
9.
141 142 143
145 146
148
149 150
151 154 155 156 157
158 159 163 166 168
169 172
173 176 179
xi 188
189 191 192
196 198 200 201
210 212 213
213 215 217
219 225 226
228 230 232
234 236 242 246
249 254
PARTE IJI Actualización de datos
181 181 183 184 185 186
10.
Actualizaciones de la base de datos ...........•......••......
257
Adición de datos a la base de datos .............•.... _.•.... _. La instrucción IN5ERT sobre una sola fila ....•.. _ _. _. . . La instrucción INSERT sobre varias filas _. • . Utilidades de carga masiva _. . . . . . . • . . . . . .
257 258 262 265
xii
Contenido
266 266 268 269
Eliminación de datos de la base de datos ........•...... La inslrucción DELETE . . . . . . . . . . . . . . . . . . . • . • . . . . • . Eliminación de todas las lilas . DELETE con subconsulla * ModifIcación de datos de la base de datos La instrucción UPDATE Actualización de todas las filas . UPDATE con subconsulla * Resumen
JI.
Integridad de datos
271
271 274 274
276 .
Concepto de la integrIdad de datos . Datos requeridos Comprobación simple de validez. Restricciones de comprobación 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 eliminación y actualización *' ...............••.... Eliminaciones y actualizaciones en cascada * Ciclos referenciales * . . Claves externas y valores NULL '" ........•••... Restricciones avanzadas (SQL2) Asertos ........... . . Tipos de restricciones en SQL2 . . . . . . . . . . . . . Comprobación diferIda de restricciones . Reglas de negocio ......... . ..............•......... Concepto de disparador . Disparadores e integridad referencial . Ventajas e inconvenientes de los disparadores . Djsparadores y el estándar SQL ................•......... Resumen.
12.
Procesamiento de transacciones
El modelo de transacCIones ANSl/ISO Otros modelos de transacciones .. Transacciones: entre bastidores Transacciones y procesamiento multiusuario El problema de la actualización perdida ..
Conceplo de transacción ............................•... COMMIT y ROLLBACK . . . . . . . . . .
El problema de los daLOs no comprometidos El problema de los datos inconsistentes El problema de la inserción fantasma Transacciones simultáneas ............ Bloqueo * Niveles de bloqueo . Bloqueos compartidos y exclusivos lnterbloqueos * Técnicas avanzadas de bloqueo * Versiones * . Funcionamiento de las versiones * Ventajas e inconvenientes de las versiones * Resumen
Contenido
315 317
319 321 323 325 326
14.
Creación de bases de datos
.
365
355 357 358 359 369 370 374 375 375 376
El lenguaje de definición de datos Creación de bases de datos. Definiciones de tablas . Creación de tablas (CREATE TABLE) . Eliminación de una tabla (DROP TABLE) _. Cambio de la definición de una tabla (ALTER TABLE) Definición de restricciones. . . . Asertos . Dominios Alias y sinónimos (CREATE/DROP ALIAS) Índices (CREATE/DROP INDEX). . ..........•. Gestión de otros objetos de la base de datos Estructura de la base de datos . Arquilectura de base de datos única Arquitectura de múltiples base de datos Arquitectura de ubicación múltiple Bases de datos en múltiples servidores . Estructura de la base de datos y el estándar ANSI/ISO .....•.. Catálogos en SQL2 ..............•.... Esquemas en SQL2 . Resumen .
SQL dinámico Límites de SQL estático Conceptos de SQL dinámico Ejecución de instrucciones dinámicas Ejecución dinámica en dos pasos
440
451
El catálogo del sistema El concepto de catálogo del sistema El catálogo y las herramientas de consulta El catálogo y el estándar ANSI/ISO Contenido del catálogo Información de tablas _ _. _ Información de columnas Información de vistas ._ Comentarios Información de relaciones Información de usuarios Información de privilegios El esquema de la información de SQL2 Otra información del catálogo Resumen
18.
448 450
..•........•.. . . . ..
427
432 432 436 438
481
SQL incorporado Técnicas de programación en SQL .. _ Procesamiento de instrucciones en el SGBD __ . _ Conceptos de SQL incorporado . Desarrollo de un programa SQL incorporado Ejecución de un programa SQL incorporado Instrucciones simples de SQL incorporado Declaración de tablas Manejo de crrores Uso de variables del anfitrión Recuperación de datos con SQL incorporado Consultas de una única fila Consultas de múltiples filas Eliminaciones y actualizaciones con cursores _. _ Los cursores y el procesamiento de transacciones Resumen
414 415 416
425
REVOKE y
17.
422
.
.
PARTE V
412
Seguridad en SQL ...........................•......•......
Resumen. . .. . . .. .. . . .
16.
. VIEW)
xv
Programación con SQ L
(CHECK
OPTION)
Eliminación de vistas (DROP Vistas materializadas * Resumen
405 405 407 409 410
Contenido
Dialectos de SQL dinámico ..............•......•......•..... SQL dinámico en Oracle •.. ................... _
19.
.
SQL dinámico y el estándar SQL2
.
instrucciones básicas de SQL2 dinámico SQL2 y SQLOA SQL2 y consultas de SQL dinámico Resumen _
.
Las API de SQL Conceptos de las API
547 548 557 563 565 566 569 570 570 571 575 575
.
577
. .
584
588
..
591
.
600
,-xvi
La API dbi lb (SQL Server) . . Técnicas básicas de SQL Server Consull.as de SQL Server _. Actualizaciones posicionadas . Consultas dinámicas _. ODBC y el estándar SQUCLI .. . . La estandarización de la imerfaz en el nivel de Ila~adas (CLI) Estructuras CLl . ProcesamienlO de inslrucciones CLl Errores e información de diagnóstico en CLJ Atributos de CL! Llamadas de información a eL! La API de ODBC .. La estructura de ODSC ODBC y la independencia del SGBD . Funciones del catálogo de ODSC Capacidades ampl ¡adas de ODBC La interfaz de llamadas de Oracle (OCl) Conlroladores OCI . . Conexión a un servidor de OracJe Ejecución de inslrucciones . Procesamiento de los resultados de una consulta Manejo de descriplores . . . . . . . . . . . Gestión 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 _ .
Conceptos de los procedimienLos almacenados Un ejemplo básico Uso de Jos procedimientos almacenados .. Creación de un procedimiento almacenado Llamada a un procedim.iento almacenado Variables de los procedimientos almacenados Bloques de instrucciones . . Devolución de un valor Devolución de valores por parámetros Ejecución condicional
702 704 706
. .
. . .
706 708 710 713
715 717
720
721 724
22.
725
. . . .
729
730 733 733 734
.
735 736 737 739 741 742
743 744 753
754 757
SQL y los almacenes de dalos
Conceplos de los almacenes de daLos . Componentes de un almacén de datos La evolución 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. . . . . . . . . . . .
666 666 668 669 670 676 696
Procesamiento de bases de dalos y procedimientos almacenados
Ejecución repelida
OLra~ conslrUClOra~
. de flujo de control Repetición con cursores . Gestión 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 TrunsacL·SQL Disparadores en SPL de lnrormix Disparadores en PLlSQL de Gracle Olras consideraciones sobre los disparadores Procedimientos almacenados. disparadores y el estándar SQL El estándar de Jos procedimientos almacenados SQLlPSM Estándares de disparadores en SQL: 1999 . Resumen .
PARTE VI SQL hoy y mañana 20.
xvii
Contenido
Contenido
758
760 761 762 762 764 766 768 769 769 771
. . . . . . . . .
772
.. .. .
775
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 .......... ...............
775
SQL l' los servidores de aplicaciones.. .. .. .... . .. .. .
777 779 780 782 786
790 791 793
xviii
23.
24.
Contenido
Redes SQL y bases de datos distribuidas
Contenido
795 795 801 802 806 808 810 813 814 816 819 821
El desafío de la gestión de datos distribuidos . Distribución de datos: enfoques prácticos _. _ . Acceso a bases de datos remotas _..............• _.. Transparencia de los datos remotos _ Extractos de tablas . Réplica de tablas ...•.......•.....•.. Réplicas actualizables . Compromisos de las réplicas . Arquitecturas normales de réplica. . . ..............•. 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 .. Gestión de grandes volúmenes de datos en Internet Resumen . . . . . .. .. .......... . .
824 825 827 831 831 832 834 836 838
SQL y los objetos ....................•.....••.....•........
839
Bases de datos orientadas a objetos . Características 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) .........•........ Definición de tipos abstractos de datos . Manipulación de tipos abstractos de datos Herencia . Herencia de tablas: implementación de clases de objetos _. Conjuntos, arrays y colecciones . . _ _ _. Definición de colecciones Consultas sobre datos de tipo colección . Manipulación de datos de tipo colección . Colecciones y procedimientos almacenados . Tipos de dalos definidos por el usuario . .....•.. _.
Métodos y procedi mientas almacenados Soporte de objetos en el estándar SQL: 1999 Resumen. ... .. ... ... . ...........•........
875 876
SQL)' XML
879
872
879
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 integración 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 __ . Resu¡nen . . . . . . . . . . . _.....•.......•.
El futuro de SQL ...........................•..............
919
Tendencias del mercado de bases de datos . Madurez del mercado de las bases de datos empresariales . . Diversidad y segmentación del mercado Aplicaciones empresariales empaquetadas . Ganancias de rendimiento del hardware . . . . Hardware para servidores de bases de datos ........•........ Las guerras de las pruebas . Estandarización de SQL . SQL en la próxima década . .....•....... Bases de datos distribuidas . Almacenes de datos masivos Bases de datos de rendimiento ulLra-aho Integración de los servicios de Internet y de red Bases de dalos incorporadas integración de objetos _ Resumen .. _. . .
IBM Corporation (www.ibm.com) lnformix Software (véase 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 (véase IBM Corporation) Sybase, Inc. (www.sybase.com) TimesTen Performance Software (www.ti.mesten.com) Yersant Corporation (www.versant.com)
Apéndice C.
. . . .
Referencia de la sintaxis de SQL .•..•.......••......
Instrucciones de definición de datos Instrucciones básicas de manipu"laci6n de datos Instrucciones de procesamiento de transacciones Instrucciones de cursores Expresiones de consultas .... Condiciones de búsqueda Expresiones Elementos de las instrucciones Elementos simples ..
Apéndice D.
.
La interfaz del nivel de llamadas de SQL
Valores devueltos por eL! . Rutinas generales de gestión de controladores.
Rutinas para la gesti6n del enlorno SQL Rutinas pan¡ la gestión de las conexiones SQL Rutinas para la gestión de las instrucciones SQL Rutinas para la ejecución de instrucciones SQL Rutinas para el procesamiento de los resultados de las consultas Rutinas para la descripción de los resultados de las consultas Rutinas para la gestión de descriptores de los resultadm. de las consultas H.utinas para el procesamiento diferido de parámetros dinámicos Rutinas para errores. estado y diagnóstico Rutinas de información de la implementación CL! Códigos de los valores de los parámetros eL!
983 985 985 986 987
El estándar del esquema de la información de SQL ....
993
Apéndice 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
lnstalación del software SGBD SQL Microsoft SQL Server 2000 . Requisitos de hardware y de software Notas sobre la instalación Inslalación de SQL Server 2000
. 1017 . 1017 1018 . . . 1018 1018 Notas sobre la instalación . Instalación de DB2 Enterprise Edition . 1019 Inicio de DB2 Enterprise Edition . . 1020 1020 Desinstalación de DB2 Enterprise Edition 1020 MySQL . Requisitos de hardware y de software _ . 1021 Notas sobre la instalación . 1021 Instalación de MySQL . 1021 Inicio de MySQL .. 1022 Desinstalación de MySQL . 1022 Descarga del software del SGBD Oraele .......•......••....... 1022 Inicio de SQL Server 2000 Desinstalación de SQL Server 2000 IBM DB2 Requisitos de hardware y de software
Índice...
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 también al equipo de McGraw-Hill/Osborne, incluyendo a Jane
Brownlow. Jennifer Malnick. Martin Przybyla. Greg Gnntle y Chrisa Hotchkiss.
1025
xxiii
Introducción
Esta edición I de SQL. Manual de referencia proporciona un tratamiento extenso y profundo del lenguaje SQL para usuarios, tanto técnicos como no, programadores, profesionales de procesamiento de datos y directivos que deseen comprender el impacto de SQL en la industria informática actual. Este libro ofrece un marco conceptual para comprender y usar SQL, describe la historia de SQL y los estándares SQL, y explica el papel de SQL en varios segmentos de la industria informática, desde el procesamiento de datos de la empresa y los almacenes de datos (data warehouses) hasta las arquitecturas de los sitios web. Esta edición contiene capítulos enfocados especialmente en el papel de SQL en las arquitecturas de los servidores de aplicaciones, y la -integración de SQL con XML y otras tecnologías basadas en objetos. Este libro mostrará paso a paso el uso de las características de SQL, con muchas ilustraciones y ejemplos reales para aclarar los conceptos de SQL. El libro también 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 aplicación. El CD-ROM adjunto contiene versiones de prueba-reales de tres importantes fabricantes de SOBD, además 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 código abierto MySQL. En algunos de los capítulos, el tema tratado se explora en dos ámbitos diferentes -una descripción fundamental del tema y una discusión avanzada orientada a profesionales informáticos que necesitan comprender los aspectos internos de SQL. La información avanzada se trata en secciones marcadas con un asterisco (*). No es necesario leer estas secciones para comprender lo que es y hace SQL.
Organización del libro El libro está dividido en seis partes que tratan varios aspectos del lenguaje SQL: • La Parte Uno, «Visión general de SQL», proporciona una introducción a SQL y una perspectiva de mercado de su papel como lenguaje de bases de datos. Sus cuatro capítulos describen la historia de SQL, la evolución de los estándares SQL y cómo se corresponde SQL con el modelo de datos relacional y
I
Nota del editor: segunda del inglés. primera en castellano.
xxv
xxvi
•
•
•
•
•
,
Introducción
Introducción
con tecnologías anteriores de bases de dalos. La Parte Uno también contiene un breve recorrido de SQL que ilustra concisamente sus características más importantes y proporciona una visión general de todo el lenguaje. La Parte Dos. «Recuperación de datos», describe las características de SQL que permiten realizar consultas a la base de datos. El primer capítulo de esta parte describe la estructura básica del lenguaje SQL. Los siguientes cuatro capítulos comienzan con las consultas SQL más simples y progresivamente se construyen cansullas más complejas, incluyendo consultas sobre varias tablas, consultas de resumen y consultas que usan subconsultas. La Parte Tres, «Actualización de datos», muestra cómo se puede usar SQL para añadir nuevos datos a la base de datos, borrar los datos de la base de datos y modificar datos existentes en ella. También describe los aspectos de la integridad de las bases de datos que surgen al actualizar los datos, y cómo SQL trata estos aspectos. El último de los tres capítulos de esta parte estudia el concepto de transacción en SQL y su soporte para el procesamiento de transacciones multiusuario. La Parte Cuatro, «Estructura de la base de datos», estudia la creación y administración de una base de datos basada en SQL. SUS cuatro capítulos muestran cómo crear tablas, vistas e índices que forman la estructura de una base de datos relacional. También describe el esquema de seguridad de SQL, que impide los accesos no autorizados a los datos, y el catálogo del sistema de SQL, que describe la estructura de la base de datos. Esta parte también estudia las diferencias significativas entre las estructuras de bases de datos soportadas por varios productos SGBD basados en SQL. La Parte Cinco, «Programación con SQL», describe cómo los programas de aplicación usan SQL para el acceso a bases de datos. Estudia SQL incorporado, especificado por el estándar ANSI y usado por mM, Oracle, Ingres, Informix y muchos otros productos SGBD basados en SQL. También describe la interfaz de SQL dinámico que se usa para construir tablas de bases de datos de propósito general, tales como los generadores de informes y programas de exploración de bases de datos. Finalmente, esta parte describe las API (Application Programming Interface, interfaz de programación de aplicaciones) de SQL, incluyendo ODBC, el estándar ISO CL! (Cal/-Level Interface, interfaz en el nivel de llamada) y IDBC, el estándar 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 mañana»,. examina el uso de SQL en varias de las áreas de aplicación actuales y destacadas, y el estado vigente de los productos SGBD basados en SQL. Dos capítulos 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 capítulos adicionales describen las bases de datos distribuidas basadas en SQL, la influencia de las tecnologías de objetos sobre SQL y la integración de SQL con las tecnologías XML. Finalmente, el último capítulo explora el futuro de SQL y algunas de las tendencias más importantes en la gestión de datos basada en SQL.
xxvii
Convenciones usadas en este libro Esta edición de SQL Manual de referencia describe las características de SQL y las funciones disponibles en los productos SGBD más conocidos, así como las descritas en los estándares 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 prácticas más 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 términos técnicos 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 MAYÚSCULAS y CON FUENTE NO PROPORCIONAL. Los nombres de las funciones de la API de SQL aparecen en minúsculas y con fuente no proporcional. Los listados de programa aparecen con fuente no proporcional y usan la convención habitual de caja para el lenguaje de programación de que se trate (mayúsculas para COBOL y FORTRAN, minúsculas para C y Java). Nótese que estas convenciones se usan s610 para mejorar la legibilidad; la mayoría de las implementaciones de SQL aceptarán instrucciones tanto en mayúsculas como en minúsculas. Muchos de los ejemplos de SQL incluyen resultados de consultas, que aparecen inmediatamente después de la instrucción SQL como si se tratase de una sesión interactiva. En algunos casos, los resultados de consultas largas se truncan después de unas cuantas filas; esto se indica con elipsis (...) a continuación de la última fila de los resultados de las consultas.
Por qué este libro es para usted Esta edición 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 cómo se usa. Este libro no es específico de ninguna marca o dialecto de SQL. En cambio, describe el estándar, el núcleo del lenguaje SQL y pasa a describir las diferencias entre los productos SQL más populares, incluyendo Oracle, Microsoft SQL Server, la base de datos universal DB2 e Inforrnix de IBM, Sybase y MySQL. También explica la importancia de los estándares basados en SQL, tales como ODBe y IDBC, y los estándares ANSI/ISO para SQL y las tecnologías relacionadas con SQL. Esta edición contiene nuevos capítulos y secciones que estudian las últimas innovaciones de SQL en las áreas de las tecnologías 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 más avanzados. Su estructura permitirá empezar rápidamente a usar SQL, pero el
xxviii
Introducción
libro continuará adquiriendo valor al usar las características más complejas del lenguaje. Se puede usar el software SQL del CO-RüM adjunto para probar los ejemplos y adquirir práctica 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 tecnologías de informaci6n --desde los ordenadores personales, los almacenes de datos y sitios web hasta aplicaciones distribuidas basadas en Internet-. Los primeros capítulos describen la historia de SQL, su papel en el mercado y su evoluci6n desde las primeras tecnologías de bases de datos. Los últimos capítulos describen el futuro de SQL y el desarrollo de nuevas tecnologías de bases de datos, tales como bases de datos distribuidas, extensiones de SQL orientadas a objetos, bases de datos de informaci6n comercial e integración de las bases de datos con XML. Si se es un programador, este libro ofrece un tratamiento muy completo de la programación con SQL. A diferencia de los manuales de referencia de muchos productos SGBD, ofrece un marco conceptual p<\ra la programación SQL, explicando tanto el por qué como el cómo del desarrollo de aplicaciones basadas en SQL. Compara las interfaces de programación SQL ofrecidas por todos los pro~ ductos principales SQL, incluyendo SQL incorporado, SQL dinámico, ODBC, JDBC y API propietarias tales como Oracle Call Interface. La descripción y comparación de las técnicas de programación proporciona una perspectiva que no se encuentra en ningún otro libro. Si se está eligiendo un producto SGBD, este libro ofrece una comparación de las características de SQL y los beneficios ofrecidos por varios fabricantes de SOBO. Se explican las diferencias entre los productos SOBD más importantes, no sólo en términos técnicos, sino también en términos de su impacto en las aplicaciones y su posición competitiva en el mercado. El software SGBD del CD-ROM adjunto se puede usar para probar estas características en un prototipo de su propia aplicación. En resumen, tanto los usuarios técnicos como no técnicos se pueden beneficiar de este libro. Es la fuente de información más extensa disponible sobre el lenguaje SQL, las características y beneficios de SQL, productos populares basados en SQL, la historia de SQL y el impacto de SQL en la dirección futura-de la industria de las tecnologías de la información.
Parte 1
VISiÓN GENERAL DE Sal
f
L
Los primeros cuatro capítulos de este libro proporcionan una perspectiva y una introducción rápida a SQL. El Capítulo l describe lo que es SQL y explica sus principales características y beneficios. En el Capítulo 2, un recorrido rápido de SQL muestra muchas de sus capacidades con ejemplos simples y rápidos de programar. El Capítulo 3 ofrece una perspectiva de mercado de SQL a través de su historia, describiendo los estándares SQL y los fabri· cantes principales de los productos basados en SQL, e identificando las razones de la importancia actual de SQL. El Capítulo 4 describe el modelo de datos relacional en el que se basa SQL y lo compara con modelos de datos anteriores.
CAPíTULO
1
¡
Introducción
I
.~
j
1
El lenguaje SQL y los sistemas de bases de datos relacionales basados en él son una de las tecnologías básicas más importantes de la industria informática. Durante más de dos décadas SQL ha pasado de su primer uso comercial a ser un segmento del mercado de productos y servicios informáticos valorado en decenas de miles de millones de euros al año, y SQL es hoy en día el lenguaje estándar para las bases de datos informáticas. Literalmente centenares de productos de bases de datos, que se ejecutan en sistemas infonnáticos 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 estándar oficial internacional para SQL y se ha ampliado dos veces. Prácticamente todos los principales productos de software para empresas confían en SQL para la gestión de los datos, y SQL se halla en el núeleo de los productos de bases de datos de Microsoft, Oraele e IBM, las tres mayores empresas de software del mundo. SQL también se halla en el corazón de los productos de bases de datos de código abierto que están ayudando a incrementar la popularidad de Linux y del movimiento de código abierto. Desde sus oscuros comienzos como proyecto de investigación de IBM. SQL ha saltado a una posición destacada como importante. tecnología infonnática y como poderosa fuerza de mercado. ¿Qué es, exactamente, SQL? ¿Por qué es importante? ¿Qué puede hacer y cómo funciona? Si SQL es verdaderamente un estándar, ¿por qué hay tantas versiones y dialectos diferentes? ¿Cómo son los productos más populares de SQL, como SQL Server, Gracle. Infonnix, Sybase y DB2, comparados entre sí? ¿Qué relación tiene SQL con los estándares de Microsoft, como ODBC y COM? ¿Cómo conecta IDBC a SQL con el mundo de Java y con la tecnología de objetos? ¿Qué papel desempeña 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 volúmenes de transacciones? ¿Cómo afectará SQL al modo en que se emplean las computadoras, y cómo puede obtenerse el máximo de esta importante herramienta de gestión de datos?
3
li, 4
.~.
~
SOL. Manual de referencia
El lenguaje SOL SQL es-una herramienta para la organización, gestión y recuperación de los da~ tos almacenados en bases de datos informáticas. El acrónimo SQL es la abrevia~ tura de Srructured Query Language (lenguaje estructurado de consultas). Por motivos históricos, SQL se suele pronunciar «sicuel» (en inglés), pero también se utiliza la pronunciación 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 específico de bases de datos, denominado bases de datos relacionales. La Figura 1.1 muestra el modo en que trabaja SQL. El sistema informático de la figura tiene una base de datos que almacena información importante. Si el sistema informático se halla en una empresa, puede que la base de datos almacene datos de inventario, de producción, de ventas o de nóminas. En una computadora personal puede que la base de datos almacenara datos sobre los cheques emitidos, listas de personas y de sus números de teléfono o datos extraídos de un sistema informático mayor. El'programa informático 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 recepción 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 confusión. En primer lugar, SQL es mucho más que una herramienta para consultas, aunque ése fuera su propósito original y la recuperación de datos siga siendo una de sus
funciones más importantes. SQL se utiliza para controlar LOdas las funciones que el SOBD ofrece a los usuarios, entre las que se hallan:
1I:~
• Definición de los datos. SQL permite que el usuario defina la estructura y la organización de los datos almacenados y las relaciones entre los elementos de datos almacenados. • Recuperación de los datos. SQL permite que el usuario o un programa de aplicación recupere de la base de datos los dalas almacenados y los emplee. • Manipulación de los datos. SQL permite que el usuario o un programa de aplicación actualice la base de dalas añadiendo 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, añadir 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, protegiéndola así del deterioro debido a las actualizaciones inconsistentes o a los fallos del sistema.
.~ '¡¡~i "
f,l i~,¡
:~
·ti¡ in, í"l
f' :tI
i
~
),
~
~
m ~i
de·d Datos
¡; ~¡
}~nOOll.
m
¡¡
110101 101110
" 1 i.
Sistema informático
Figura 1.1.
Uso de SOL para el acceso a bases de datos.
5
JI
.~ Solicitud SOL
Capítulo 1: Introducción
lí
l ~
~
SQL es, por tanto, un lenguaje completo para el control y la interacción COIl sistemas de gestión de bases de datos. En segundo lugar, SQL no es, en realidad, un lenguaje informático completo como COBOL, C, C++ o Java. SQL no contiene ninguna sentencia IF para la comprobación 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 gestión 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 explícita 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 informática. 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 inglés, completadas con «palabras ruido}) que no añaden nada al significado de la frase pero que hacen su lectura más naturaL Hay unas cuantas inconsistencias en el lenguaje SQL, y también hay algunas reglas especiales para evitar la construcción 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 estándar 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 rápido por SQL del Capítulo 2 ofrecerá una buena visión general del lenguaje y de sus posibilidades.
6
Capítulo 1: Introducción
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 informática y «comprar SQL», En cambio, SQL es un componente integral de los sistemas de gestión 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 lípico, y el modo en que SQL actúa como el pegamento que los mantiene unidos. El motor de bases de dalos es el corazón 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 aplicación escritos por los usuarios e, incluso, de otros sistemas informáticos. Como muestra la figura, SQL desempeña 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
•
fI
010011 110101 101110
•
Herramientas de programación
•
Motor de la base
'f~~
~d.datOrs
_
Características y ventajas de SaL SQL es a la vez un lenguaje sencillo de comprender y una herramienta completa para la administración de los datos. A continuación se indican algunas de las característ.icas principales de SQL y las fuerzas del mercado que les han permitido tener éxito:
Base de datos
A otras marcas
de SGBD
Figura 1.2.
mostrarlos en la pantalla. lo que proporciona una herramienta práctica y fácil de utilizar para las consultas ad hoc a las bases de datos. ~QL es un lenguaje de programación de bases de datos. Los programadores Incorporan comandos de SQL en los programas de aplicación 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 técnica para el acceso a las bases de datos. SQL es un lenguaje de administración de bases de datos. El responsable de la administración 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 interactúan con los datos empresariales y los servidores de aplicaciones de Internet utilizan SQL como lenguaje estándar para el acceso a las bases de datos empresariales. SQL es un lenguaje de bases de datos distribuidas. Los sistemas de gestión de bases de datos distribuidas utilizan SQL para ayudar a distribuir los datos por muchos sistemas informáticos interconectados. El software SGBD de cada sistema utiliza SQL para comunicarse con los demás sistemas, enviando solicitudes de acceso a los datos. SQL es un lenguaje de pasarelas de bases de datos. En las redes informáticas con mezcla de diferentes productos de SGBD, SQL suele utilizarse como pasarela que permita a unas marcas de SGBD comunicarse con las otras.
SQL, por tanto, se ha manifestado como una herramienta útil y potente para enlazar personas, programas y sistemas infonnáticos con los datos almacenados en las bases de datos relacionales. .
:LY I
sistemas informáticos
7
Componentes de un sistema gestor de bases de datos típico.
i
I I
1 I
• • • •
Independencia del fabricante. Transportabilidad entre sistemas informáticos. Estándares SQL. Acuerdos y obligaciones de IBM (DB2).
8
SOL. Manual de referencia
• • • • • • • • • • • • • •
Capítulo 1: Introducción
Obligaciones de Microsoft (SQL Server, ODBC y ADO). Fundamentos relacionales. Estructura de alto nivel en inglés. Consultas ad hoc interactivas. Acceso mediante programación a bases de da(Qs. Vistas múltiples de los dalos. Lenguaje completo de base de datos. Definición dinámica de datos. Arquitectura cliente/servidor. Soporte de aplicaciones empresariales. Extensibilidad y tecnología de objetos. Acceso a bases de dalOS en Internet. Integración de Java (lOBe). Infraestructura de la industria.
Éstas son las razones por las que SQL se ha situado como la herramienta estándar para la administración de datos en las computadoras personales, las minicomputadoras y los grandes sistemas. Todas se describen en los apartados siguientes.
9
nómicas pueden utilizarse como prototipos para aplicaciones de bases de datos basadas en SQL antes de pasarlas a sistemas multiusuario de elevado coste.
Estándares SOL El organismo estadounidense de normalización (American National Standards Insti tute, ANSI) y la Organización Internacional de Normalización (Inlernational Standards Organization, ISO) publicaron un primer estándar para SQL en 1986, que se amplió en 1989, y nuevamenle en 1992 y en 1999. SQL también es un estándar federal para procesamiento de información de EE UU (U. S. Federal Information Processing Standard, FIPS), lo que lo transforma en un requisito fundamental para los grandes contratos informáticos del gobierno estadounidense. A lo largo de los años otros grupos internacionales, gubernamentales estadounidenses y de fabricantes han liderado la normalización 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 estándar ANSl/ ISO. LbS estándar en evolución sirven de sello oficial de aprobación de SQL y han acelerado su aceptación en los mercados.
Independencia del fabricante Todos los fabricantes principales de SGBD ofrecen SQL, y ningún producto nuevo de bases de datos ha tenido un éxito importante en la última década 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 mínimo esfuerzo de conversión y una pequeña readaptación 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 más importantes de su temprana popularidad y sigue siendo hoy en día una característica importante.
Transportabilidad entre sistemas informáticos ~,
Í' - .•
Los productos de bases de datos basados en SQL se pueden ejecutar en sistemas informáticos 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 informáticos 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 tamaño 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-
Acuerdos y obligaciones de IBM (DB2) SQL fue inventado originalmente por investigadores de lB M, y desde entonces se ha transformado en un producto estratégico 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 señal clara de la dirección lOmada por IBM para que la siguieran los demás fabricantes de bases de datos y de sistemas en los albores del desarrollo de SQL.y de las bases de datos relacional.es. Más adelante, el compromiso y el amplio sopone de IBM aceleraron la aceptación por los mercados de SQL. La influencia de IBM en SQL hoy en día llega mucho más. allá de su propio negocio de sistemas informáticos. Los productos basados en SQL que ha desarrollado O adquirido IBM se ejecutan hoy en día en una amplia gama de hardware, en muchos casos de fabricantes informáticos de la competencia como Sun O Hewlett-Packard.
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
Capítulo 1: Introducción
SOL. Manual de referencia
una API en el nivel de llamadas basarla en SQL. Las principales aplicaciones de software de Windows (hojas de cálculo, 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, más orientadas a objetos, como parte de su tecnología Enlace e incrustación de objetos (Object Linking and Embedding, OLE DB) y, más 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 años ochenta del siglo pasado, introdujo SQL Server como su propia oferta basada en SQL. SQL Server sigue siendo hoy en día un producto insignia de Microsoft y un componente fundamental de su arquitectura .NET para servidores web.
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 fácil de comprender. El modelo relacional tiene también un sólido fundamento teórico que ha guiado la evolución e implementación de las bases de datos ·relacionales. Aprovechando una ola de aceptación provocada por el éxito del modelo relacional, SQL se ha transformado en el lenguaje de bases de datos para las bases de datos relacionales.
Estructura de alto nivel en inglés Las instrucciones de SQL tienen el aspecto de frases sencillas en inglés, 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 cómo 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.
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 nítido contraste con los días o semanas que tardaría un programador en escribir un programa personalizado para informes. Debido a la capacidad para consultas ad hoc de SQL los datos resultan más accesibles y pueden utilizarse para ayudar a una organización a tomar decisiones mejores y más informadas. La capacidad para
11
consullas ad hoc de SQL fue una ventaja importante respecto de las bases de datos no relacionales en los primeros tiempos de su evolución, y más recientemente ha seguido siendo una ventaja fundamental sobre las bases de datos basadas solamente en objetos.
Acceso mediante programación a bases de datos SQL es también 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 ofrecían un conjunto de herramientas para el acceso med.iante programación y un recurso de consulta diferente para las solicitudes ad hoc, sin ninguna sinergia entre los dos modos de acceso.
Vistas múltiples 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 sólo vea los datos de su departamento o región de ventas. Además, 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.
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 día mucho más allá de la recuperación de datos. SQL ofrece un lenguaje completo y consistente para la creación de bases de datos, la administración de su seguridad, la actualización de su contenido, la recuperación 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 más productivos.
Definición dinámica de datos Mediante SQL se puede modificar y expandir de manera dinámica la estructura de las bases de datos, aunque los usuarios estén teniendo acceso al contenido de la
12
SOL. Manual de referencia
base de datos. Esto supone un importante avance respecto de los lenguajes estáticos de definición de datos, que impedían el acceso a las bases de datos mientras se modificaba su estructura. SQL ofrece, por tanto. la máxima flexibilidad, lo que permite que las bases de datos se adapten a los requisitos cambiantes mientras las aplicaciones en línea siguen funcionando sin interrupción.
Arquitectura cliente/servidor SQL es un vehículo natural para la implementación de aplicaciones mediante una arquitectura distribuida cliente/servidor. En este papel, SQL sirve de enlace entre los sistemas informáticos visibles al usuario, optimizados para la interacción con el usuario, y los sistemas subxacentes especializados en la gestión de las bases de datos, 10 qu.e permite que cada sistema h~ga lo que mejor ~ace. SQL también permite que las computadoras persomile1s funcionen como sistemas visibles para los servidores de red o para bases de dátos de minicomputadoras y de grandes sistemas, ofreciendo acceso a los datos empresariales desde las aplicaciones de las computadoras personales.
Soporte de aplicaciones empresariales Todas las aplicaciones empresariales de gran tamaño 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 gestión de datos y pueden aprovecharse de las herramientas y de las habilidades de programación 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 automática una demanda inducida de nuevas copias de software de bases de datos.
Extensibilidad y tecnologia de objetos El principal desafío al prolongado dominio de SQL como estándar de bases de datos ha surgido de la aparición de la programación basada en· objetos y de la introducción de bases de datos basadas en objetos como extensión de la amplia tendencia del mercado hacia la tecnología basada en objetos. Los fabricantes de bases de datos basadas en SQL han respondido a este reto ampliando y mejorando
Capítulo 1: Introducción
13
lentamente SQL para incluir características orientadas a objetos. Estas bases de datos «relacionales orientadas a objetos», que siguen estando basadas en SQL. se han constituido en una alternativa más popular que las bases de datos «sólo orientadas objetos» y han perpetuado el dominio de SQL durante la última década._ La última ola de la tecnología orientada a objetos, incrustada en el estándar 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 volverán 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 estándares, SQL halló un nuevo papel a finales de los años noventa del siglo pasado como estándar 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 páginas web la información de las bases de datos, y utilizaron SQL como lenguaje común para las pasarelas de bases de datos. Más recientemente la aparición 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 estándar entre las capas de aplicaciones y de bases de datos. En el futuro, el papel de SQL en Internet se ampliará más allá de las arquitecturas de los sitios web para incluir la gestión de datos para las aplicaciones colaboradoras y los objetos distribuidos en una arquitectura de servicios web.
Integración de Java (JDBC¡ Un área importante de desarrollo de SQL en los últimos cinco o diez años ha sido la integración 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 estándar 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 estándar a datos en la especificación de la edición empresarial Java2 (Java2 Enterprise Edition, J2EE), que define el entorno operativo proporcionado por todos los principales servidores de aplicaciones de Internet. Además de su papel como lenguaje de programación desde el que se utilizan bases de datos, muchos de los principales fabricantes de bases de datos también 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 lógica empresarial dentro de las propias bases de datos. Esta tendencia hacia la integración entre Java y SQL asegurará que se mantenga la importancia de SQL en la nueva era de la programación basada en Java.
14
SOL. Manual de referencia
Infraestructura de la industria Quizás el factor más importante de los que han contribuido a la creciente importancia de SQL sea la aparición de toda una infraestructura de la industria informática 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 introducción de datos, las herramientas de diseño, las herramientas de programación 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 formación 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 consultoría, optimización y ajuste de rendimiento de SQL. Todas las partes de la infraestructura tienden a reforzarse entre sí y contribuyen al éxito actual de las demás partes. En pocas palabras, para resolver problemas de gestión de datos la solución más sencilla, de menor riesgo y de menor coste casi siempre es una solución basada en SQL.
CAPíTULO
2
Una introducción a SOL
Antes de sumergirnos en los detalles de SQL, conviene desarrollar una perspectiva global del lenguaje y del modo en que trabaja. Este capítulo contiene una introducción rápida a SQL que ilustra sus principales características y funciones. El objetivo de esta introducción rápida 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 capítulo, tendrá más bien una familiaridad básica con el lenguaje SQL y una visión general de sus posibilidades.
Una base de datos simple Los ejemplos de la introducción rápida se basan en una base de datos relacional simple para una pequeña compañía de distribución. La base de datos, que se muestra en la· Figura 2.1, almacena la información necesaria para implementar una pequeña aplicación de procesamiento de pedidos. Específicamente, almacena la información siguiente: • • • •
Los clientes que compran los productos de la compañía. 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 mayoría, 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 continuación se verá ]a manera en que se puede utilizar SQL para manipular los datos. d~tos
15
16
SOL. Manual de referencia
Capítulo 2: Una introducción a SOL
Tabla PEDIDOS 1l\W~PEPUlO
Tabla onCINAS
PZC>IA..-PEDIDO
112961
11/1211989
CLIEIlTE
u,
,~
,~~
2117
106 RE!
2"441.
113012
11/01/1990
2111
105 ACI
41003
112989
03/0111990
nOl
106 FEA
U.
113051
¡O/OUU90
2118
108 OSA
~"
112968
12110/1989
101 ACI
HOO'
113016
)0/0111990
210. 2101
110 ACI
41002
113045
0210211"0
2112
108 REI
11296]
11112119119
no]
¡as .\el
2"'HR 41004
113(1)
U/Olll990
:1118
108 BIc
Hao]
11305. 112991
.l/OUIno
2108
109 FEA
08l0H1990
2l:i!4
101 BIC
'" HaO)
1un3
nH2I1989
2101
lOS ACI
U004
lU024
20/0111990
211t
loa~
2HD2I1990
2124
~"
lD062
107 !'EA
11297g
12/1011989
HU
102 ACI
UOOt
Ill021
22/0111"0 08/0111990 0210111990
2101 2112
105 hel 1081HM
41002
lUOO? 113069
10/0211990
04/0111989
2106
102 REI
2USC
113065
2110211990
2106
.102
~"
IlJ003
25/0111990
2108
109 1101
me
10/02119'0
2118 210J 2111 2113
I08fOSA 105 ACI 103 Ael 101 Rl:I
4100Y 4100X 2AUIl
11J049 112981 llJ051 1l30U
12110/1'19 1510211990
31/1211989 18/0211990 02102/1990
REI
iln REI
Ul!!
719C
,
'"
.., "
J1.500,OOE
", "• "• ,•
U
",
NlIvarra
Esee
Castellón
Este
l.'20,DOE 3.978.00€
13 Almeria
Esee
21 León
Qesee
652.DOE
1.no.OD€ 652.00€ 70l,apE: 1.IOO.OOE
l.(lO.QoE .S.OOO.DOE
4.104.00€ 2.92S,00€
2102 Filas 2103 2t2.3 Cruz e hijos 2101 Ace lntenuleio.... ¡ 211S Sierra.. S ..... ,~
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 año actual. La instrucción de SQL que recupera los datos de la base de datos se denomina SELECT. Esta instrucción de SQL recupera los datos deseados: SELECT CIUDAD, OFICINA, VENTAS FROM OFICINAS CIUDAD
La instrucción 5ELECT pide tres fragmentos de los datos -la ciudad, el número de la oficina y el importe de las ventas- de cada oficina. También 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 después de la solicitud. La instrucción SELECT se emplea para todas las consultas de SQL Por ejemplo, a continuación se ofrece una consulta que muestra un listado de los nombres y las ventas en el año actual de cada representante que figura en la base de datos. También mu'estra la cuota (objetivo de ventas) y el número de la oficina en que
18
Capítulo 2: Una introducción a SOL
SQL. Manual de referencia
trabaja cada uno.- En este caso, los datos provienen de la tabla de representantes siguiente, VENTASREPS: SELECT NOMBRE,
REP_OFICINA,
VENTAS.
CUOTA
19
Se puede utilizar la misma técnica 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ó. También se puede pedir a SQL que ordene los pedidos de acuerdo con su importe:
FROM VENTASREPS
NOMBRE
REP_OFICINA
VENTAS
---------------- ------------ -----------13 11 21
Bruno Arteaga María Jiménez Susana Santos Samuel Clavel Bernardo Sánchez Daniel Ruidrobo Tomás Saz León Freire Pablo Cruz Neus Azcárate
SQL también 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
NUM_PEDIDO, CLIENTE, PEDIDOS IMPORTE> 25000,OO€ BY IMPORTE
NUM_PEDIDO
CLIENTE PRODUCTO
----------- -------112987 113069 112961 113045
PRODUCTO,
2103 2109 2117 2112
-------4l00Y 775C 2A44L 2A44R
CANTIDAD,
IMPORTE
CANTIDAD
IMPORTE
11 22
27.S00,00€ 31.350,00e: 31.500,00€ 4S.000,00e:
--------- ----------7
10
Resumen de datos SQL no sólo recupera de la base de datos fragmentos individuales de datos, sino que también puede utilizarse para resumir el contenido de la base de datos. Se desea averiguar el tamaño promedio de los pedidos de la base de datos. Esta solicitud pide a SQL que examine todos los pedidos y averigüe su importe promedio: SELECT AVG(IMPORTE) FROM PEDIDOS AVG(IMPORTE) 8.256,37€
También se podría pedir el tamaño promedio de los pedidos de un cliente concreto: SELECT AVG(IMPORTE) FROM PEDIDOS WHERE CLIENTE = 2103
Los datos solicitados (incluida la diferencia entre las ventas y la cuota de cada representante) vuelven a aparecer en una tabla de filas/columnas, Quizás se prefiera centrar la atención en los representantes cuyas ventas son menores que sus cuotas. SQL permite recuperar esa clase de información selectiva muy fácilmente, añadiendo una comparación matemática a la solicitud anterior:
AVG(IMPORTE)
SELECT NOMBRE, VENTAS, CUOTA, FROM VENTASREPS WHERE 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 número de cliente y luego sume Jos pedidos de cada -cliente:
NOMBRE Bernardo Sánchez Neus Azcárate
VENTAS 142.594,OOe: 186.042,00€
(VENTAS - CUOTA)
CUOTA (VENTAS-CUOTA) 200.000,OO€ 300.000,OO€
-57.406,00€ -1l3.958,OO€
8.895,50e:
SELECT CLIENTE, SUM(IHPORTEj FROM PEDIDOS GROUP BY CLIENTE
20
Capítulo 2: Una introducción a SOL
SOL. Manual de referencia
CLIENTE 2101 2102 2103 2106 2107 2108
2109 2111 2112 2113 2114
2117 2118 2120 2124
21
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 instrucción DELETE:
SUM(IMPORTE) 1.458,OO€
3.978,QO€ 35.582,OO€
DELETE FROM REPRESENTANTES WHERE VENTAS < CUOTA
4.026,OO€ 23.132,OO€
2 filas eliminadas.
7.255,OO€ 31.350,OO€
6.445,QO€ 47.925,Oü€ 22.S00,OO€ 22.10Q,QO€
Actualización de la base de datos También se puede utilizar SQL para modificar los datos que ya se hallan almacenados en la base de datos. Por ejemplo, para aumentar el límite de crédito de Filas a 75.000 €, habría que utilizar la instrucción de SQL UPDATE:
31.500,OO€
3.60S,OO€ 3.750,QO€ 3.D82,QO€
UPDATE CLIENTES SET LIMITE_CREDITO = 75000.00 WHERE EMPRESA = 'Filas'
Adición de datos a la base de datos
1 fila actualizada.
También se puede utilizar SQL para añadir datos nuevos a la base de datos. Por ejemplo, supóngase que se acaba de abrir una oficina comercial regional Oeste en Daganzo, con un objetivo de' ventas de 275.000 €. A continuación puede verse la instrucción INSERT que añade la nueva oficina a la base de datos, como oficina número 23:
La instrucción UPDATE también puede realizar de manera simultánea varias modificaciones en la base de datos. Por ejemplo, esta instrucción UPDATE eleva la cuota de todos los representantes en 15.000 €:
UPDATE REPRESENTANTES SET CUOTA = CUOTA + 15000.00
OFICINA)
1 fila insertada.
De manera parecida, si María Jiménez (número de empleado 109) suscribe a un nuevo cliente, Acme Industrial, esta instrucción INSERT añade el cliente a la base de datos como cliente número 2125 con un límite de crédito de 25.000 €: INSERT INTO CLIENTES (EMPRESA, REP_CLI. NUM_CLI, LIMITE_CREDITO) VALUES ('Acme Industrial', 109, 2125, 25000.00) 1 fila insertada.
Eliminación de datos Al igual que la instrucción de SQL INSERT añade datos nuevos a las bases de datos, la instrucción de SQL DELETE elimina datos de las bases de datos. Si Acme Industrial decide pasarse a la competencia unos días más tarde, se puede eliminar de la base de datos la información de cliente de Acme con esta instrucción: DELETE PROM CLIENTES WHERE COMPANY = 'Acme Industrial' 1 fila eliminada.
8 filas actualizadas.
Protección de datos Un papel importante de las bases de datos es proteger los datos almacenados del acceso por usuarios no autorizados. Por ejemplo, supóngase que la secretaria, María, no ha sido autorizada con anterioridad a introducir en la base de datos los datos de los clientes nuevos. Esta instrucción de SQL le concede ese permiso: GRANT INSERT ON CLIENTES TO MARIA Privilegio concedido.
De manera parecida, la siguiente instrucción de SQL da a María permiso para actualizar y para recuperar datos de los clientes con la instrucción SELECT: GRANT UPDATE, SELECT ON CLIENTES TO MARIA Privilegio concedido.
22
SOL. Manual de referencia
Capítulo 2: Una introducción a SOL
Si ya no se permite a María añadir clientes nuevos a la base de datos, la instrucción REVQKE se lo impedirá: REVOKE INSERT ON CLIENTES FROM MARIA Privilegio revocado.
23
Una vez creada la tabla, se pueden rellenar con datos. A continuación se ofrece una instrucción INSERT para un nuevo envío de 250 cables de la serie 7 (producto ACI-410Q7), que cueslan 225,00 € cada unidad ': INSERT INTO PRODUCTOS VALUES
('ACI',
(ID_FAB,
'41007',
ID_PRODUCTO, DESCR!PCION,
'Serie 7 cable',
225.00,
PRECIO,
STOCK)
250)
1 fila insertada.
De manera parecida, la instrucción REVOKE revocará todos los privilegios de María 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 instrucción DROP TABLE: DROP TABLE PRPDUCTOS
Privilegio revocado. Tabla eliminada.
Creación de bases de datos
Resumen
Antes de poder almacenar datos en una base de datos hay que definir la estructura de los datos. Supóngase que se desea ampliar la base de datos de ejemplo añadiendo una tabla de datos de los productos que vende la empresa. Para cada producto los datos que hay que almacenar son los siguientes: • • • • •
Un código de identificación del fabricante de tres caracteres. Un código de identificación del producto de cinco caracteres. Una descripción del producto de treinta caracteres como máximo. El precio del producto. La cantidad actualmente en inventario.
La instrucción de SQL los datos de Jos productos:
CREATE TABLE
define una nueva tabla para almacenar
Esta introducción rápida 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 más frecuencia. Para resumir: • Se puede utilizar SQL para recuperar datos de la base de datos, empleando la instrucción SELECT. Se pueden recuperar todos los datos almacenados o sólo 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, añadiendo datos nue vos con la instrucción INSERT, eliminando datos con la instrucción DELETE y modificando los datos existentes con la instrucción 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
• 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 más críptica que los ejemplos anteriores de instrucciones de SQL, la instrucción 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 numérico que acepta la mayoría de SGBD para la entrada de datos interactiva con SQL es el anglosajón, 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 según el convenio numérico en español.
CAPíTULO
3
SOL en perspectiva
SQL es a la vez un lenguaje estándar defacto y un lenguaje estándar oficial para la gestión de bases de datos. ¿Qué significa que SQL sea un estándar? ¿Qué papel desempeña SQL como lenguaje de bases de datos? ¿Cómo llegó SQL a ser un estándar y qué repercusión está teniendo el estándar SQL en las computadoras personales, las redes de área local, las minicomputadoras y Jos grandes sistemas? Para responder a estas preguntas este capítulo sigue la historia de SQL y describe su papel actual en el mercado informático.
SOL Y la gestión de bases de datos Una de las tareas principales de los sistemas informáticos es almacenar y gestionar datos. Para realizar esta tarea comenzaron a aparecer programas informáticos especializados conocidos como sistemas gestores de bases de datos a finales de los años 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 permitían que el sistema informático desempeñara un papel más activo en la gestión de los datos. Aunque los sistemas gestores de bases de datos se desarrollaron en primer lugar en los grandes sistemas informáticos, su popularidad se extendió rápidamente a las minicomputadoras y, posteriormente, a las computadoras personales y a las estaciones de trabajo. Hoy en día, muchos sistemas gestores de bases de datos operan en compuladoras servidoras especializadas. La gestión de bases de dalOs ha desempeñado también un papel fundamental en la explosión de las redes informáticas y de Internet. Los primeros sistemas de bases de datos se ejecutaban en grandes sislemas informáticos monolíticos, en los que la información, el software de gestión de bases de datos y el usuario o la aplicación que tenían acceso a la base de datos operaban lodos en el mismo sistema. Los años ochenta y noventa del siglo pasado vieron la explosión de un nuevo modelo cliente/servidor para el acceso a bases de dalOs, en el cual un usuario o un programa de aplicación que se ejecute en una computadora personal tienen acceso
25
26
SOL. Manual de referencia
a una base de datos de un sistema informático diferente mediante una red. A fines de los años noventa, la creciente popularidad de Internet y del World Wide Web entrelazaron aún más los ámbitos de las redes y de la gestión de datos. Actualmente, los usuarios necesitan poco más que un explorador web para tener acceso a las bases de datos e interactuar con ellas, no sólo dentro de sus propias organizaciones, sino en todo el mundo. A menudo estas arquitecturas basadas en Internet implican tres o más sistemas informáticos diferentes -una computadora que ejecuta el explorador web e interactúa con el usuario, conectada a un segundo sistema que ejecuta un programa de aplicación 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 día la gestión de bases de datos es un negocio enorme. Las compañías de software independientes y los fabricantes de computadoras facturan miles de millones de euros cada año en productos de gestión de bases de datos. La inmensa mayoría de las aplicaciones informáticas 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 categorías de aplicaciones de crecimiento más rápido, como la Planificación de recursos empresariales (Enterprise Resource Planning, ERP), la Gestión de relaciones con los clientes (Customer Relationship Management, CRM), la Gestión de la cadena de suministros (Supply Chain Management, SCM), la Automatización 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 específicamente como servidores de bases de datos; estos sistemas constituyen por sí mismos un mercado de varios miles .de millones de euros al año. 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 gestión de bases de datos se vincula de este modo a todos los segmentos del mercado informático. Desde fines de los años ochenta se ha hecho tan popular un tipo específico de SGBD, denominado sistema gestor de bases de datos relacionales (SGBDR), que es la forma estándar 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 específicamente un lenguaje para bases de datos relacionales empleado para trabajar con bases de datos relacionales.
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 años de historia. El concepto de base de datos relacional fue desarrollado originalmente por el Dr. E. F. Cad(! (<
Capítulo 3: SOL en perspectiva
Codd define el modelo relacional de bases de datos. IBM comienza el proyecto System/R. Se publica el primer artículo 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 estándares de SQL. IBM anuncia DB2. Se ratifica el estándar ANSI SQLl. Sybase introduce SGBDR para el procesamiento de transacciones. Se ratifica el estándar 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 especificación de acceso a bases de datos SQL Access Group. Microsoft publica la especificación ODBC. Se ratifica el estándar 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 tecnología paralela de servidores de bases de datos. Se publican el API estándar 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 integración de Java. Microsoft SQL Server 7 ofrece soporte de bases de datos para Windows NT en ámbito empresarial. Oracle Si ofrece integración 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 integración 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.
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 años
El artículo de Codd desató un frenesí de investigación en bases de datos relacionales, incluido un importante proyecto de investigación de IBM. El objetivo del pro. yecto, denominado System/R, era comprobar la operatividad del concepto relacional y proporcionar experiencia en la implementación real de un SGBO relacional El trabajo en SystemIR comenzó a mediados de los años 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 mínimo de SGBD relacional. Además del propio SGBD, el proyecto SystemlR incluía el trabajo en los lenguajes de consulta a bases de datos. Uno de estos lenguajes se denominó SEQUEL, acrónimo de Lenguaje estructurado de consulta en inglés (Slruelured English Query Language). En 1976 y 1977 el prototipo de investigación de System/R se volvió a escribir desde el principio. La nueva implementación soportaba consultas multitabla y permitía que varios usuarios compartieran el acceso a los datos. La implementación de SystemIR se distribuyó a varios sitios clientes de IBM para su evaluación 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 había renombrado como SQL, O Lenguaje estructurado de consultas (Structured Query Language). Pese al cambio de nombre, la pronunciación inglesa SEQUEL se mantuvo, y continúa usándose hoy en día. En 1979 el proyecto de investigación System/R llegó a su final, e IBM concluyó que las bases de datos relacionales no sólo eran factibles, sino que podían 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 gestión de bases de datos y, finalmente, acabó cambiando su nombre por el de su producto insignia. Hoy en día 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 informáticos de Berkeley de la Universidad de California también estaban investigando en las bases de datos relacionales a mediados de los años setenta. Al igual que el equipo de investigación de mM, crearon un prototipo de SGBD relacional y denominaron Ingres a su sistema. El proyecto lngres incluía un lenguaje de consultas, denominado QUEL, que, aunque más estructurado que SQL, era menos similar al inglés. Muchos de los expertos actuales en bases de datos debe!1 su vinculación 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 compañías emergentes de bases de datos orientadas a objetos. En 1980, varios profesores abandonaron Berkeley y fundaron Relational Technology, Inc., para crear una versión comercial de Ingres, que se anunció en 1981. Ingres y Oracle se convirtieron rápidamente en grandes rivales, pero su rivalidad ayudó a llamar la atención hacia la tecnología de las bases de datos relacionales en esta etapa inicial. Pese a su superioridad técnica en muchos aspectos, logres se convirtió en un claro jugador de segundo nivel en este mercado, que competía 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 estándar SQL. Hacia mediados de los noventa, la tecnología Ingres se había vendido a Computer Associates, uno de los principales fabricantes de software para grandes sistemas.
Los primeros productos relacionales
Productos de IBM
El proyecto SystemIR y su lenguaje de bases de datos SQL se dieron a conocer con detalle en las revistas técnicas durante los años setenta. Los seminarios sobre tecnología de bases de datos ofrecían debates sobre las ventajas del nuevo y herético modelo relacional. Hacia 1976 parecía evidente que IBM se estaba entusiasmando con la tecnología relacional de bases de datos y que estaba estableciendo un importante compromiso con el lenguaje SQL. La publicidad de System/R atrajo la atención de un grupo de ingenieros de Menlo Park, California, que consideraron que la investigación de IBM presagiaba un mercado comercial para las bases de datos relacionales. En 1977 formaron una
Mientras Oracle e Ingres corrían a convertirse en productos comerciales, el proyecto System/R de IBM también se había 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 versión de SQLIDS para VMlCMS, un sistema operativo que se empleaba con frecuencia en los grandes sistemas de IBM en las aplicaciones de los centros informáticos empresariales. En 1983, IBM introdujo también Database 2 (DB2), otro SGBD relacional para sus grandes sistemas. DB2 operaba bajo el sistema operativo MVS de IBM, que
Los primeros años
30
SOL. Manual de referencia
era el burro de carga utilizado en los grandes centros de procesamiento de datos de los grandes sistemas. La primera versión de DB2 comenzó a distribuirse en 1985. y los empleados de IBM la saludaron como una pieza estratégica de la tecnología 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 estándar de facto. La tecnología DB2 se ha migrado actualmente a todas las líneas de productos de IBM, desde las computadoras personales a los servidores de red y los grandes sistemas. En 1997. IBM llevó aún más allá la estrategia multiplataforma de DB2, anunciando versiones de DB2 para sistemas informáticos 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. Según la mayor parte de los analistas de la industria, IBM es el segundo fabricante más importante de software de gestión 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.
Aceptación comercial Durante la primera mitad de los ochenta, los fabricantes de bases de datos relacionales luchaban por conseguir la aceptación comercial de sus productos. Los produc:tos relacionales presentaban varias. desventajas en relación con las arquitecturas tradicionales de bases de datos. Excepto los productos de IBM, las bases de datos relacionales procedían de pequeños fabricantes emergentes. Y, salvo los productos de 1BM, las bas~s de datos relacionales tendían a ejecutarse en minicomputadoras, en lugar de en los grandes sistemas de 1BM. Los productos relacionales, sin embargo, tenían una ventaja importante. Sus lenguajes de consultas relacionales (SQL, QUEL y otros) permitían a los usuarios formular consultas ad hoc a la base de datos -y obtener respuestas inmediatassin necesidad de escribir ningún programa. En consecuencia. las bases de datos relacionales comenzaron a convertirse poco a poco en aplicaciones de centros informáticos como herramientas de soporte de decisiones. Hacia mayo de 1985, Oracle proclamó con orgullo que tenía más de mil instalaciones. lngres se instaló en un número de sitios comparable. DB2 y SQUDS también se aceptaron poco a poco y contaron sus instalaciones combinadas'en poco más de mil sitios. En la segunda mitad de los años ochenta del siglo pasado SQL y las bases de datos relacionales se aceptaron rápidamente como la tecnología 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 versión, proclamando su superioridad sobre el competidor y un rendimiento doble o triple que el de la versión anterior. Las mejoras de la potencia de procesamie~to del hardware informático subyacente también ayudaron a mejorar el rendimiento.
.Capítulo 3: SaL en perspectiva
31
Las fuerzas del mercado también fomentaron la popularidad de SQL a fines de los años ochenta del siglo pasado. IBM incrementó su promoción de SQL, situando a DB2 como la solución de gestión de datos para los años noventa. La publicación del estándar ANSI/ISO para SQL en 1986 otorgó estatus oficial a SQL como estándar. SQL también se afianzó como estándar en los sistemas informáticos basados en UNIX, cuya popularidad se aceleró en los años ochenta. A medida que las computadoras personales se hacían más potentes y se conectaban en redes de área local (local area networks, LAN), fueron necesitando una gestión de bases de datos más sofisticada. Los fabricantes de bases de datos para pe adoptaron SQL como la solución 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 años 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 solución práctica 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 información mucho más económicos. La supremacía de SQL en el mundo de las bases de datos no se ha librado de desafíos. A principios de los años noventa, la programación orientada a objetos se había implantado como el método preferido para el desarrollo de aplicaciones, especialmente para las computadoras personales y sus interfaces gráficas de usuario. El modelo de objetos. con sus objetos, sus clases, sus métodos y su herencia, no proporcionaba un encaje ideal con el modelo relacional de tablas, filas y columnas de datos. Surgió una nueva generación 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 había 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 año. A medida que SQL creció para abordar una variedad cada vez mayor de tareas de gestión de datos, el enfoque «un·tamaño-sirve-para-todos» dio muestras de agotamiento. A finales de los años noventa, la gestión de bases de datos ya no era un mercado monolítico. Surgieron sistemas especializados de bases de datos para dar soporte a diferentes necesidades del mercado. Uno de los segmentos de crecimien· to más rápido 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 incorporación a SQL de nuevos tipos de datos (como los datos multimedia) y los principios de orientación a objetos. Un tercer segmento de importancia fueron las bases de datos móviles para las computadoras personales portátiles que podían operar tanto conectadas como desconectadas de un sistema centralizado de bases de datos. 'Otro
32
SOL. Manual de referencia
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, diseñado para niveles de rendimiento muy elevados. Pese a la aparición de subsegmenlos del mercado de bases de datos, SQL ha seguido siendo un denominador común de lodos ellos. A medida que la industria informática se prepara para este nuevo siglo. el dominio de SQL como el estándar 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 años indica que SQL y el modelo relacional tienen una enorme capacidad para aceptar las nuevas necesidades de gestión de datos y adaptarse a ellas.
Estándares de SaL Uno de los desarrollos más importantes en la aceptación de mercado de SQL es la aparición de estándares de SQL. Las referencias al «estándar de SQL» suelen hacer referencia al estándar oficial adoptado por el organismo estadounidense de normalización (American National Standards Institute, ANSI) y la Organización Internacional de Normalización (International Standards Organization, ISO). Sin embargo, hay otros estándares importantes de SQL, como el estándar de/acto para algunas partes del·lenguaje 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 estándares ANSI/ISO El trabajo en el estándar oficia! de SQL comenzó en 1982, cuando ANSI encargó a su comité X3H2 la definición de un lenguaje estándar 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 estándar de jacto en el mercado, el comité seleccionó SQL como lenguaje para las ,bases de datos relacionales y centró su atención en normalizarlo. El estándar ANSI para SQL resultante se basaba principalmente en SQL de DB2, aunque contenía algunas diferencias importantes respecto de DB2. Tras varias revisiones el estándar se adoptó oficialmente como estándar ANSI X3.135 en 1986, y como estándar ISO en 1987. El gobierno estadounidense ha adoptado desde entonces el estándar ANSI/ISO como Estándar federal para el procesamiento de la información (Federalln/ormatioll Processing Standard, FIPS). Este estándar, líger.amente revisado y ampliado en 1989, suele denominarse SQL-89 o estándar SQLI.
Capítulo 3: SOL en perspectiva
33
Muchos de los integrantes de los comités de estándares de ANSI y de ISO eran representantes de los fabricames de bases de datos que tenían 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 estándar 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 adhesión al estándar ANSI/ISO resultante, pero hicieron el estándar relativamente débil. Para abordar los agujeros del estándar original, el comité ANSI continuó su trabajo y se distribuyeron borradores de un nuevo estándar más riguroso, SQL2. A diferencia del estándar de 1989, los borradores de SQL2 especificaban características muc'ho más allá de las halladas en los productos SQL comerciales en vigor. Se propusieron incluso más modificaciones de gran alcance para un posterior estándar SQL3. Además, los borradores de estándares intentaban estandarizar oficialmente panes del lenguaje SQL en que las diferentes Imarcas de SGBD habían definido diferentes estándares propietarios desde hacía mucho tiempo. En consecuencia, los estándares propuestos SQL2 y SQL3 resultaron mucho más polémicos que el estándar SQL inicial. El estándar SQL2 superó el proceso de aprobación de ANSI y se aprobó definitivamente en octubre de 1992. Mientras que el estándar original de 1986 ocupaba menos de cien páginas, el estándar SQL2 (denominado oficialmente SQL-92) ocupa cerca de seiscientas páginas. El comité de estándares de SQL2 reconoció el gran avance logrado desde SQLI hasta SQL2 creando explícitamente tres niveles de cumplimiento de los estándares de SQL2. El nivel de cumplimiento más bajo (nivel inicial) sólo exige una capacidad adicional mínima respecto del estándar SQL-89. El nivel de cumplimiento intermedio (nivel intermedio) se creó como un avance posible respecto de SQL-89, pero que evita los aspectos más complejos y la mayoría de los problemas dependientes del sistema y de las marcas de SGBD. El tercer nivel de cumplimiento (completo) exige una implementación completa de todas las posibilidades de SQL2. A lo largo de las seiscientas páginas del estándar la descripción de cada característica incluye una definición de los aspectos concretos de esa característica que deben soportarse para conseguir un cumplimiento inicial, intermedio o completo. Pese, a la existencia del estándar SQL2 desde hace más de diez años, en la práctica los productos comerciales de SQL más populares no implementan completamente la especificación SQL2, y no hay dos productos comerciales de SQL que soporten exactamente el mismo dialecto de SQL. Además, a medida que los fabricantes de bases de datos introducen nuevas posibilidades, amplían continuamente.sus dialectos de SQL y se apartan más del estándar. No obstante, el núcleo central del lenguaje SQL se ha estandarizado bastante. Donde se podía lograr sin dañar a los clientes o a las características ya existentes los fabricantes han adaptado sus productos para que cumplan con el estándar SQL-89, y con las posibilidades más útiles del estándar SQL2.
34
SOL. Manual de referencia
Entretanto, se continúa trabajando en estándares posteriores a SQL2. El esfuerzo de SQL3 se fragmentó finalmente en esfuerzos de estandarización 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 estandarización afrontados por SQL2. Otras, como las extensiones de SQL orientadas a objetos no están todavía disponibles de manera general o completamente implementadas, pero han generarlo un alto grado de debate. Con la mayor parte de los fabricantes que sólo han implementado recienlemente las principales posibilidades de SQL2, y con la diversidad de extensiones de SQL disponibles hoy en día en productos comerciales, el trabajo en SQL3 ha alcanzado menos importancia comercial. El «verdadero» estándar de SQL, por supuesto, es el lenguaje SQL implementado en los productos que están generalmente aceptados por el mercado. En su mayoría los. programadores y los usuarios tienden a seguir las partes del lenguaje que son bastante parecidas en una amplia gama de productos. La innovación de los fabricantes de bases de datos sigue impulsando la invención de nuevas posibilidades de SQL; algunos productos permanecen en el mercado durante años sólo para asegurar la compatibilidad con productos anteriores, y algunos logran el éxito comercial y pasan a ser de aceptación general.
Otros estándares de SOL Aunque es el más ampliamente reconocido, el estándar ANSI/ISO no es el único estándar para SQL. X/OPEN, un grupo de fabricantes europeos, también adoptó SQL como parte de su conjunto de estándares para un entorno portátil de aplicaciones basado en UNIX. Los estándare·s x/OPEN han desempeñado un papel importante en el mercado ¡nfonnático europeo, donde la transportabilidad entre sistemas informáticos de diferentes fabricantes es una preocupación fundamental. Por desgracia, el estándar x/OPEN se diferencia del estándar ANSI/ISO en varias áreas. IBM también incluyó SQL en la especificación de su audaz proyecto de los años noventa del siglo pasado Arquitectura de aplicación de sistemas (Syslems Applicalion Architeclure, SAA), que prometía que todos sus productos de SQL acabarían pasándose a este dialecto SQL de SAA. Aunque SAA no logró cumplir sus promesa de unificar la línea 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 línea. de productos RS/6000 de estaciones de trabajo y de servidores basados en UNIX. Hacia 1997 IBM había llevado a DB2 más allá de su propia línea de productos y había 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ó aún más sus posición en el software para bases de datos en plataformas de hardware que no son de IBM con su adquisición en 2001 de la base de datos Informix. Con el liderazgo histórico de IBM en la tecnología de las bases de datos relacionales, el dialecto de SQL'incorporado por DB2 es un estándar de jaclo muy potente.
Capítulo 3: SOL en perspectiva
35
ODBC y el grupo de acceso SOL Un área importante de la tecnología de bases de datos no abordada por los estándares oficiales es la interoperatividad entre bases de dolos -los métodos mediante los cuales se pueden intercambiar datos entre bases de datos diferentes, generalmente a través de una red. En 1989 un grupo de fabricantes formó el Grupo de acceso SQL (SQL Access Group) para abordar este problema. La especificación 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 especificación 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 estándar del Grupo de acceso SQL tuvo mucho más impacto en el mercado. Ante la insistente petición de Microsoft, el Grupo de acceso SQL amplió su campo de atención para incluir una interfaz en el nivel de llamadas para SQL. Basada en un borrador de Microsoft, la especificación Interfaz en el nivel de llamadas (CalJ-Levellnlerface, CU) resultante se publicó en 1992. La misma especificación de Conectividad abierta de bases de datos (Open Oatabase Connectivity, OOBC) de Microsoft, basada en el estándar CLI, se publicó ese mismo año. Con el poder de mercado de Microsoft tras él y la bendición de «estándares abiertos» del Grupo de acceso SQL, OOBC se ha implantado como la interfaz estándar 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 estándar de la industria en los dos entornos de interfaz gráfica más 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 estándar ANSI/lSO, con la publicación del estándar de la Interfaz en el nivel de llamadas para SQL (SQUCall-Levellnterface, CLI). Hoy en día, OOBC está en su cuarta revisión de importancia como estándar 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 aplicación 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 planificación de recursos empresariales y la gestión de la cadena de suministros a aplicaciones para computadoras personales como las hojas de cálculo, las herramientas de consulta y los programas de elaboración de infonnes. La atención de Microsoft ha pasado de OOBC a in~ terfaces de nivel superior (como OLEJDB) y, más recientemente, a los objetos de datos de ActiveIX (ActiveIX Data Objects. ADO), pero estás nuevas interfaces se apilan sobre üOBC para el acceso a bases de datos relacionales, y ésta sigue siendo una tecnología fundamental para el acceso a bases de datos entre diferentes plataformas.
SOL Y transportabilidad La existencia de estándares publicados para SQL ha generado unas cuantas afirmaciones exageradas sobre SQL y la transportabilidad de las aplicaciones. Se sue-
36
SOL. Manual de referencia
Capitulo 3: SOL en perspectiva
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 estándar 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 estándar SQL2 pero todavía no se han .implementado en los productos comerciales, figuran:
•
• Códigos de error. El estándar SQL-89 no especifica los códigos de error que hay que mostrar cuando SQL o.etecta un error, y cada implementación comercial utiliza su 'propio conjunto de códigos. El estándar SQL2 especifica los'códigos de error estándar. • Tipos.de datos. El estándar SQL-89 define un conjunto mínimo de tipos de datos,'pero'omite algunos de los tipos más populares y útiles, corno las cadenas de caracteres ,de .longitud variable, las fechas y las horas y los datos de monedaJEI·estándar SQL2 aborda'este problema, pero no los tipos de datos «nuevos», 'como Jos gráficos.y los objetos multimedia. • Tablas'del'sistema. El estándar SQL-89'no dice nada respecto de las tablas del 'sistema que ofrecen información 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 sólo en los grados de cumplimiento más elevados, que la mayoría de los fabricantes todavía no ofrece. • SQL interactivo. El estándar especifica sólo la programación con SQL utilizado por los programas de aplicación, no SQL interactivo. Por ejemplo, la instrucción SELECT utilizada para consultar la base de datos en SQL interactivo está ausent~ en el estándar SQL-89. Una vez más, el estándar SQL2
•
•
•
I
APllc:c;ón
Aplicación 2
I
l
. I
Aplicacion 3
~.J
.+
+.
SOL «eS;ándarll
I
*
Figura 3.1.
. 'APll,,:ción
I
I
..
+
SGBD
SGBD
SGBD
1
2
3
El mito de la transportabilidad de SOL.
¡ 1
¡
J
•
37
aborda este problema, pero mucho después de que todos los principales vendedores de SGBD tuvieran posibilidades bien establecidas de SQL interactivo. Interfaz para programación. El estándar original especifica una técnica abstracta para emplear desde el interior de SQL unos programas de aplicación escritos en COBOL. C, FORTRAN y otros lenguajes de programación. Ningún producto comercial de SQL utiliza esta técnica, y hay variaciones considerables entre las interfaces para programación utilizadas realmente. El estándar SQL2 especifica una interfaz incorporada para SQL para los lenguajes de programación más populares, pero no una interfaz en el nivel de llamadas. El estándar SQUCLI de 1995 abordó finamente el acceso a SQL mediante programación, 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 dinámico. El estándar SQL-89 no incluye las características necesarias para desarrollar partes visibles al usuario de finalidad general, como las herramientas para búsqueda y los redactores de informes. Estas características, conocidas como SQL dinámico, se hallan en casi todos los sistemas de bases de datos de SQL, pero varían significativamente de un producto.a otro. SQL2 incluye un estándar para SQL dinámico. 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 semánticas. Como los estándares 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 eliminación de filas duplicadas. Secuencias de ordenación. El estándar SQL-89 no aborda la secuencia de ordenación (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 estándar SQL2 incluye una especificación elaborada de manera que los programas y los usuarios pueden solicitar una secuencia de ordenación determinada, pero es una característica de nivel avanz.ado que no está incluida, por lo general, en los productos comerciales. Estructura de las bases de datos. El estándar 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 conexión inicial con la base de datos varían ampliamente y no son transferibles. El estándar SQL2 crea más uniformidad pero no puede enmascarar por completo estos detalles.
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
Capitulo 3: SOL en perspectiva
SOL. Manual de referencia
Gracle e Ingres. En esta arquitectura el SGBn y los datos físicos residen en una minicomputadora o gran sistema central, junto con el programa de,aplicación que acepta ·las entradas desde el terminal del usuario y muestra los datos en la pantalla del usuario. El programa de aplicación se comunica con el SGBD empleando SQL. Supóngase que el usuario escribe una consulta que exige una búsqueda secuencial en la base de datos, como puede ser una solicitud de búsqueda del'tamaño 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 aplicación como el de la base de datos tienen lugar en la computadora central, por lo que la ejecución 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 ampliación. Según se agregan usuarios, cada uno de ellos añade carga de trabajo de procesamiento de la aplicación al sistema. Como el sistema es compartido, cada usuario experimenta un rendimiento deteriorado a medida que el sistema se va cargando.
SQL comenzaron a surgir a principios de los años 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 conversión de tipos de datos, traduce los códigos de error, etc. La transportabilidad transparente entre diferentes marcas de SGBD, basada en SQL estándar, es el principal objetivo de SQL2 y de üDBC, y se ha alcanzado un progreso significativo. Hoy en día, casi todos los programas que albergan varias bases de datos incluyen controladores específicos para comunicarse con cada una de las principales marcas de SOBD, y suelen incluir un controlador ODBe para tener acceso a las demás.
SOL Y redes El espectacular crecimiento de las redes informáticas en los años noventa tuvo un importante impacto en la gestión de bases de datos y dio a SQLuna·nueva importancia. A medida que las redes se hicieron más' comunes, las aplicaciones que tradicionalmente se ejecutaban en una minicomputadora o en un gran sistema central pasaron a redes de área local de estaciones de·trabajo de mesa y servidores. En estas 'redes SQL desempeña un papel crucial como enlace entre la aplicación que se ejecuta en la estación de trabajo de mesa con una interfaz gráfica de usuario y el SGBD que gestiona los datos compartidos en un servidor efectivo en costes. Más 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 lógica 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 evolución' de las arquitecturas de red de las bases de datos y el papel de SQL en cada una de ellas.
39
Arquitectura del servidor de archivos
-1
¡
,.
La introducción de las computadoras personales y de las redes derárea local llevó al desarrollo de la arquitectura del servidor de archivos, .que puede verse en la Figura 3.3. En esta arquitectura, una aplicación 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 tradicionál de las bases de datos utilizada por DB2, SQUDS, y las bases de datos originales de minicomputadoras como
Servidor de archivos
Base _1
•• :
Gran sistema
SoticitudesL_,_-.d de E/S de disco ~ aloques de disco
Pulsaciones---+ , - - - - - - , - - - - - - ,
,;~. :' \~
Aplicación
+- Caracteres L
----'
\~
Figura 3.3. Figura 3.2.
de datos y archivos ompartido
Gestión de bases de datos en una 'arquitectura centralizada.
La gestión de las bases-de datos en una arquitectura de servidor de archivos.
40
SOL. Manual de referencia
Capítulo 3: SaL en perspectiva
ción de una computadora personal solicita Jos datos de un archivo compartido, el software de red recupera del servidor de manera automática el bloque solicitado del archivo. Las primeras bases de dalos de computadoras personales, como dBASE y, más 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 típicas que sólo 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, considérese la consulta formulada en el ejemplo anterior. Como la consulta exige una búsqueda secuencial de la base de datos, el SGBD solicita de la base de datos de manera repetida bloques de datos, que se ubican físicamente al otro lado de la red, en el servidor. Finalmente se solicitarán todos los·bloques del archivo y enviados por la red. Obviamente, esta arquitectura produce un tráfico de red muy intenso y un bajo rendimiento para las consultas de este tipo.
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 años noventa, SQL se convirtió en el lenguaje de bases de datos estándar para la comunicación entre las herramientas visibles para el usuario y el motor subyacente en esta arquitectura. Considérese una vez más la consulta que solicita el tamaño 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 también 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 aplicación visible para el usuario lo muestra en la pantalla de la computadora personal. La arquitectura cliente/servidor reduce el tráfico 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 exhibición 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 más 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 años noventa, estas ventajas hicieron de la arquitectura cliente/servidor el esquema más popular para la implementación de nuevas aplicaciones. Todos los productos SGBD más populares -Gracle, Informix, Sybase, SQL Server, DB2 y muchos más- ofrecían posibilidades de cliente/servidor. La industria de las bases de datos creció para incluir muchas empresas que ofrecían herramientas para la creación de aplicaciones cliente/servidor. Algunas provenían de las propias empresas de bases de datos; otras procedían de empresas independientes. Al igual que las demás arquitecturas, la arquitectura cliente/servidor presentaba sus inconvenientes. El principal era el problema de la gestión 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 aplicación de una gran empresa, el departamento de sistemas informáticos tenía que actualizar millares de sistemas de computadoras personales, uno a uno. La situación era aún peor si había que sincronizar las modificaciones del programa de aplicación con modificaciones en otras aplicaciones, o con el propio sistema SGBD. Además, con las computadoras personales en las mesas de los usuarios, éstos tendían a añadir nuevo software personal propio o a modificar la configuración de sus sistemas. Estas modificaciones solían transtornar el funcionamiento de las aplicaciones ya existentes, lo que incrementaba la carga de trabajo del soporte técnico. Las empresas desarrollaron estrategias para solucionar estos problemas, pero a fines de los años noventa había una creciente preocupación sobre la gestionabilidad de las aplicaciones cliente/servidor en las grandes redes distribuidas de computadoras personales.
Arquitectura cliente/servidor La Figura 3.4 muestra la siguiente etapa de la evolución 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 ,------¡
~.9
\;---¡, Figura 3.4.
Il:'§~.
pe
-'\;---¡,
La gestión de bases de datos en una arquitectura cliente/servidor.
I
L
41
1-
42
SOL. Manual de referencia
Capítulo 3: SOL en perspec.tilt8
43
Arquitectura multicapa Con la -implantación de Internet y, especialmente, de World Wide Web, la arquitectura de las bases de datos de red dio otro paso en su evolución. Al principio la web se utilizaba para tener acceso a documentos estáticos (explorarlos), y evolucionó fuera del mundo de las bases de datos. Pero, cuando el empleo de los exploradores web se hizo más amplio, no pasó mucho tiempo antes de que las empresas pensaran en utilizarla como una manera sencilla de proporcionar acceso también a las bases de datos empresariales. Por ejemplo, supóngase que una empresa empieza utilizando la ·web para proporcionar información de sus productos a los clientes poniendo a su disposición en su sitio web descripciones de los productos y gráficos. El siguiente paso natural era dar a los clientes acceso a la información 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 métodos utilizados para conectar los servidores web con los sistemas SOBD evolucionaron rápidamente entre fines de los años 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 algún 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 algún motivo, más compleja que una mera página web, el servidor web transfiere la solicitud a un servidor de aplicaciones, cuyo papel es manejar la lógica empresarial necesaria para procesarla ~solicitud, A menudo la solicitud implica el acceso a una aplicación 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 estándar para la comunicación 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 servidores·de aplicaciones ·se ha convergido alrededor del estándar Edición empresarial Java2 (Java2 Enterprise Edition, J2EE), la conectividad Java para bases de datos (Java DataBase Connectivity, JDBe) se ha implantado como el API estándar para el acceso de los servidores de aplicaciones a las ·bases de datos.
La proliferación de SaL Como estándar para el acceso a las bases de datos relacionales, SQL ha tenido una importante repercusión en todas las facetas del mercado informático. IBM ha adoptado SQL como tecnología unificadora de las bases de datos para su línea de productos. Las bases de datos basadas en SQL dominan el mercado de los sistemas
Servidor de bases de datos
•• 1
Gran sistema
e
Sistema
"
Base de datos
SGSD
ro
OLTP heredado
~
U
·•
'O E
Páginas web estáticas
.• s ro
Servidor web Software del servidor web
~ u
Servidor de aplicaciones Servidor de' aplicaciones (lógica empresarial)
o
'~
, ,•
o;
~ Q ro :¡¡
".", ro Q ro
u
Explorador web
.,~ .~-.
\'-~
Figura 3.5.
La gestión de bases de datos en una arquitectura de Internet de tres
capas. infonnáticos basados en UNIX. En el mercado de las computadoras personales las bases de datos de SQL en sistemas operativos Windows orientados a servidores están planteando un serio desafío a la dominación de UNIX como platafonna de procesamiento de bases de datos, especialmente para las aplicaciones departamentales. SQL está aceptado como tecnología para el procesamiento en conexión de transacciones (online transaction processing, OLTP), lo que refutan completamente la idea generalizada en los años ochenta de que las bases de datos relacionales nunca ofrecerían un rendimiento lo bastante bueno para las aplicaciones de procesamiento de transacciones. El almacenamiento de datos y las aplicaciones de bús· queda de datos basadas en SQL son el estándar 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 más personalizados, y de los servicios de información que son una ventaja fundamental del comercio electrónico.
44
SOL. Manual de referencia
SOL Y la estrategia de la base de datos unificada de IBM SQL ha desempeñado un papel fundamental como lenguaje común 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 aún más 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 informáticos 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 implementación de SQL se ejecuta sobre la familia de sistemas de tamaño mediano para empresas de IBM, dirigidos a las pequeñas 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 versión 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.
SOL en las minicomputadoras Las minicomputadoras fueron uno de los más fértiles 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 línea de transacciones, también consideró VAX una de sus principales plataformas. A lo largo de los años ochenta, los fabricantes de minicomputadoras también desarrollaron sus propias bases de datos propietarias que utilizaban SQL. Digital consideró tan importantes las bases de datos relacionales que incluyó una versión en tiempo de ejecución 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-
Capítulo 3: SOL en perspectiva
45
neral sustituyó a sus bases de datos anteriores como herramienta estratégica de gestión de datos. Además, 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· gía importante para los sistemas informáticos de gama media. A mediados de los años noventa, los produclOS SQL de los fabricantes de SQL habían desaparecido en su mayor parte, derrotados en el mercado por el software multiplataforma de Oracle, Inforrnix, Sybase y Q(fOS fabricantes. En línea con esta tendencia, la imp0rlancia de los sistemas operativos propietarios de las minicomputadoras también 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 solución de gestión de datos predilecta para los sistemas informáticos basados en UNIX. Originalmente desarrollado en los BeU Laboratories, UNIX se hizo popular en los años ochenta del siglo pasado como sistema operativo estándar independiente del fabricante. Se ejecuta en una amplia gama de sistemas informáticos, desde estaciones de trabajo a grandes sistemas, y se ha transformado en el sistema operativo estándar para los sistemas servidores de alta gama, incluidos los servidores de bases de datos. A principios de los años ochenta del siglo pasado ya se disponía 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 específicamente para UNIX. Ninguna de ellas ofrecía originalmente soporte para SQL, pero hacia 1985 Unify ofreció un lenguaje de consultas SQL e Informix se había vuelta a escribir como Informix-SQL, con soporte integral de SQL. Hoy en día los productos SOBD de Oracle, DB2, Informix y Sybase dominan el mercado de bases de datos basadas en UNIX y están 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 búsqueda constante de· mayor rendimiento de las bases de datos de SQL ha generado algunas de las tendencias más importantes en el hardware de los sistemas UNIX. Entre ellas figuran la aparición del multiprocesamiento simétrico (symmelric multiprocessing. SMP) como arquitectura habitual de los servidores y el empleo de tecnología RAID (Redundan! Array ollndependent Disks, array redundante de discos independientes) para incrementar el rendimiento de E/S.
SOL en computadoras personales Las bases de datos han sido populares en las computadoras personales desde los primeros días del PC de IBM. El producto dBASE de Ashton-Tate alcanzó una
46
SOL. Manual de referencia
base instalada de más de un millón de computadoras personales basadas en MSDOS. Aunque estas primeras bases de datos para computadoras personales solían presentar los datos de forma tabular, carecían 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 cabían 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 típica configuración 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. Además del producto OS/2 estándar, mM anunció un OS/2 Extended Edition (OS/2 EE) propietario con una base de datos SQL incorporada y soporte de comunicaciones. Con esta introducción 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 estándar a otros fabricantes de computadoras personales, Microsoft necesitaba una alternativa a Extended Edition. Microsoft respondió obteniendo la licencia del SGBD de Sybase, que se había desarrollado para VAX, y comenzó a adaptarlo a OS/2. En enero de 1988, en un movimiento sorpresa, Microsoft y Ashton-Tate (el líder en bases de datos para computadoras personales de la época con su producto dBASE) anunciaron que venderían conjuntamente el producto basado en OS/2 resultante, rebautizado SQL Server. Microsoft vendería SQL Server con OS/2 a los fabricantes de c;omputadoras; Ashton-Tate vendería 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) añadió su apoyo a SQL Server invirtiendo en Sybase. Más adelante, ese mismo año, Ashton-Tate renunció a sus derechos exclusivos de distribución minorista y vendió su.inversi6n a Lotus. SQL Server para OS/2 sólo obtuvo un éxito limitado. Pero, en el típico 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 relación se volvió menos cooperativa y más competitiva. Finalmente, Sybase y Microsoft se fueron cada uno por su lado. La ascendencia común de los productos SQL de Sybase y de Microsoft todavía puede verse en posibilidades de los productos y en algunas extensiones comunes de SQL (por ejemplo, los procedimientos almacenados), pero las líneas de productos ya han divergido de manera significativa. Hoy en día 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 tamaño y en ]a escala de las aplicaciones de
Capítulo 3: SOL en perspectiva
47
bases de datos que podía 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. Además 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 (amaño, 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 repercusión en las aplicaciones de procesamiento en conexión 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 conexión de escaso volumen, donde su rendimiento más lento no suponía un·'inconveniente. Para las aplicaciones OLTP, en las que centenares de usuarios necesitaban acceso con conexión a los datos y tiempos de respuesta inferiores al segundo, el Sistema de gestión de la información (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, diseñada especialmente para las aplicaciones OLTP. El SGBD de Sybase se ejecutaba en minicomputadoras VAXNMS y estaciones de trabajo Sun, y se centraba en el máximo rendimiento con conexión. OracIe Corporation y Relational Technology comunicaron poco después que también ellos ofrecerían versiones OLTP de sus populares sistemas de bases de datos Oracle e Ingres. En el mercado UNIX, Informix anunció una versión 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 versión 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 más exigentes, y animó a los clientes a considerarlo una seria alternativa a IMS. Las pruebas de rendimiento de OLTP se han convertido hoy en día en una herramienta de ventas estándar para las bases de datos relacionales, pese a las serias dudas sobre la precisión 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 años noventa, en que los avances en la tecnología relacional y un hardware informático más potente llevaron a velocidades de transacción cada vez más altas. Los fabricantes de SGBD comenzaron a promover sus productos de acuerdo con su rendiiento OLTP y, por unos años, la publicidad de las bases de datos se centró
48
Capítulo 3: SQL en perspectiva
SOL. Manual de referencia
casi en su totalidad en estas guerras de pruebas de rendimiento. Una organización 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 sólo sirvieron para intensificar la obsesión de los fabricantes por el rendimiento. A fines de los años 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 implementación de aplicaciones OLTP. Desde una situación de «inadecuado para OLTP» , SQL ha crecido hasta ser el fundamento estándar de la industria para la creación
49
Este fenómeno, así como el soporte popular de las computadoras personales una década antes, estimuló el rápido crecimiento del segmento de bases de datos para trabajo en grupo. Hoy en día SQL está bien establecido como estándar 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 más rápidamente. Desde 'este sólido dominio del segmento del trabajo en grupo, los sistemas servidores basados en Windows están 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 años ochenta y noventa supuso una nueva oportunidad para la gestión 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 día 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 años noventa, Novell también 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 días de las redes de área local de computadoras personales, NetWare se había establecido como el sistema operativo de red dominante para los servidores de 'archivos y de impresión. Mediante acuerdos con Oracle y con otras empresas, Novell intent9 extender también este liderazgo a los servidores de bases de datos para trabajo en grupo. La llegada de Windows NT al mundo de la informática 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 ofrecía una clara ventaja en rendimiento frente a NT como servidor de archivos para trabajo en grupo, NT tenía una arquitectura más sólida y de propósito general, más similar a la de los sistemas operativos para minicomputadoras. Microsoft vendió con éxito NT como una plataforma más atractiva para la ejecución 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 vendía) con NT como una plataforma para bases de datos para trabajo en grupo muy integrada. Los departamentos empresariales de sistemas informáticos fueron en principio muy cautos respecto al empleo de tecnología relativamente nueva y sin .probar, pero la combinación NT/SQL Server permitió a los departamentos y a ejecutivos ajenos a los sistemas informáticos emprender por su cuenta proyectos del nivel de trabajo en grupo de menor escala, sin la ayuda de los sistemas informáticos de sus empresas.
Durante varios años, el esfuerzo para hacer de SQL una tecnología viable para las aplicaciones OLTP apartó la 'atención 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 añadido de un nuevo pedido a la base de datos o la determinación 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 también podían 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 informáticos era que los datos acumulados de cada empresa (almacenados en bases de datos de SQL, por supuesto) deberían 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 podían, en teoría, llevar a cabo fácilmente tanto aplicaciones de OLTP como de toma de decisiones, surgieron algunos problemas prácticos 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 búsquedas secuenciales de grandes tablas de las bases de datos para responder a preguntas como el tamaño promedio de los pedidos por región de ventas o la comparación entre las tendencias de inventario entre un año 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 volúmenes de transacciones comerciales alcanzaran su máximo, podría 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 informáticas. El deseo de aprovechar los datos comerciales acumulados, y los problemas prácticos de rendimiento que generaba a las aplicaciones OLTP, llevó al concepto
50
51
Capitulo 3: SOL en perspectiva
SOL. Manual de referencia
de almacén 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 según sea necesario, y se ubican en una base de datos independiente que está dedicada a las consultas para toma de decisiones (el «almacén}»). La extracción y transformación de los datos puede programarse para su procesamiento por lotes fuera de las horas punta. Lo ideal sería que sólo se pudieran extraer datos nuevos o modificados, lo que minimizaría la cantidad de datos que habría que procesar en el ciclo mensual, semanal o diario de puesta al día del almacén. Con este esquema, las consultas de análisis comercial que consumen tanto tiempo utilizan el almacén de datos, y no la base.de datos OLTP, como origen de datos. Las bases de datos relacionales basadas en SQL ,eran una opción clara para el almacenamiento del almacén de datos, debido a su procesamiento flexible de las consultas. Se formó una serie de empresas nuevas para crear las herramientas de extracción y transformación de datos y de consulta de la base de datos necesarias para el modelo del almacén de datos. Además, los fabricantes de SGBD comenzaron a centrar su atención en el tipo de consultas a las bases de datos que los clien-
tes solían ejecutar en los almacenes de datos. Estas consultas solían ser grandes y complejas -como el análisis de decenas o centenares de millones de recibos de cajas registradoras para buscar patrones de adquisición-de productos-, y exigían datos de series temporales -por ejemplo, el análisis de los datos de ventas de productos o de cuotas de mercado a lo largo del tiempo-. También tendían a exigir resúmenes estadísticos de los datos ~ventas totales, volumen promedio de los pedidos, crecimiento porcentual, etc.-, más que los propios datos. Para abordar las necesidades especializadas de las aplicaciones de los almacenes de datos (a menudo denominadas Procesamiento en conexión analítico, 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 sólo de lectura. Asumían funciones estadísticas y otras funciones de tratamiento de datos avanzadas. como el procesamiento incorporado de series temporales, así como el cálculo previo de los datos .estadísticos de las bases de datos, de modo que la recuperación de los promedios y de los totales pudiera ser muchísimo más rápida. Algunas de estas bases de datos especializadas no utili-
zaban SQL, pero muchas sí lo hacían (lo que llevó al término adjunto ROLAP,
. ~
Servidor de bases de_datos LAN
'E
•E o u
·• o
o
Ü ~
Servidor de bases de datos Unix
Gran sistema
l.
Base de Base Base Aplicación datos ¡...... SGBO I¡de datos del+SGBO de datos del+- de negocio de clientes l...'::=:s:;;='J11 productos ~=+=J inventarin heredada
•
.~
~
o
I
,
/
I I
. ~
•
E
8
."."
" '" o
l.~
rl....
-
íg
Figura 3.&.
Herramientas de análisis de datos y elaboración de informes
Solicitud~r;:=t==;-l Sal SGSD
K ~
+-Oatos
El concepto de almacén de datos.
IJ.•
.>
SOL Y las aplicaciones distribuidas en Internet A fines de los años noventa, World Wide Web y la posibilidad de exploración
Herramientas de extracción y formato de datos
.
de Procesamiento analítico relacional en conexión (Relational OnLine Analytic Processing). Al igual que en tantos segmentos del mercado de bases de datos, las ventajas de SQL como estándar demostraron que eran una fuerza importante. El almacenamiento de datos se ha convertido en un segmento de más 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 tecnología habitual para la creación de almacenes de datos.
J
Almacén, de datos -'
web que permitió fueron la. fuerza motriz del crecimiento de Internet. Con su atención en la entrega de contenido en forma de texto y de gráficos. los primeros usos de la web tuvieron poco que ver con la gestión de datos. Sin embargo, hacia mediados de los años noventa gran parte del contenido ofrecido en los sitios web empresariales tenía su orige-Q. en bases de datos empresariales basadas en SQL. Por ejemplo. en e! sitio web comercial de un detallista, las páginas que contienen la información sobre los productos disponibles para la venta, sus precios, la disponibilidad de los productos, las ofertas esp~ciales y.demás suelen crearse a petición del usuario, con base en los datos rec~perados de una base de datos de SQL. La inmensa mayoría de las páginas mostradas por los sitios de subastas en línea o por los sitios de las agencias de viajes en línea se basan, de manera análoga, en los datos recuperados de bases de datos de SQL, transformados al formato de páginas HTML de la web. En el sentido inverso, los datos introducidos por el usuario en los formularios de las páginas del explorador casi siempre se capturan en bases de datos de SQL que forman parte de la arquitectura del sitio web.
52
SOL Manual de referencia
A comienzos de este siglo, la atención de la i.ndustria había pasado a la siguiente fase de internet y al papel que pueden desempeñar las tecnologías de inter· net en la conexión de las aplicaciones de las computadoras entre sí. Estas arquitecturas de aplicaciones distribuidas recibieron una amplia cobertura de la prensa especializada bajo la denominación de servicios web. De acuerdo .con la vieja costumbre de la industria informática, aparecieron bandos enfrentados que defendían diferentes conjuntos de estándares 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 estándar para el intercambio de datos estructurados, como los datos que residen en las bases de datos de SQL. En respuesta a la atención 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, añadiendo a sus productos posibilidades de entrada y salida XML y, en algunos casos, soporte de los tipos de datos XML. La interacción entre XML y SQL es una de las áreas más activas en la gestión de datqs hoy en día, y la actividad en esta área mantendrá a SQL en el centro de atención de la industria hasta bien entrada la primera década del siglo.
CAPíTULO
4
Bases de datos relacionales
Los sistemas gestores de bases de datos organizan y estructuran los datos de modo que los usuarios y los programas de aplicación puedan recuperarlos y manipularlos. Las estructuras de los datos y las técnicas 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? ¿Cómo se almacenan los datos en las bases de datos relacionales? ¿En qué se diferencian las bases de datos relacionales de tecnologías anteriores, como las bases de datos jerárquicas y las bases de datos de red? ¿Cuáles son las ventajas e inconvenientes del modelo relacional? Este capítulo describe el modelo relacional de datos adoptado por SQL y lo compara con estrategias anteriores para la organización de las bases de datos.
Resumen Este capítulo ha descrito el desarrollo de SQL y su papel como lenguaje estándar para la gestión de bases de datos relacionales:
Los primeros modelos de datos
• SQL fue desarrollado originalmente por investigadores de lBM, y el fuerte soporte de IBM es una razón fundamental de su éxito. • Hay estándares oficiales ANSIJISO de SQL y otros varios estándares de SQL, cada uno de ellos ligeramente diferente de los estándares ANSI/ISO. • Pese a la existencia de estándares, hay muchas pequeñas variaciones entre los dialectos comerciales de SQL; no hay dos variedades de SQL exactamente iguales. .. .• SQL se ha convertido en el lenguaje estándar para la gestión de bases de datos en una amplia gama de sistemas informáticos 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.
Cuando la gestión de bases de datos se extendió en los años setenta y ochenta, aparecieron unos cuantos modelos de datos que se popularizaron. Cada uno de estos modelos de datos primigenios tenía ventajas e inconvenientes que desempeñaron 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 contribución 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 introducción de los sistemas gestores de bases de datos, todos los datos almacenados de manera permanente en los sistemas informáticos, como los
53
...
54
Capítulo 4: Bases de daros relacionales
SOL. Manual de referencia
registros de las nóminas 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 ubicación de los archivo~. El sistema gestor de archivos básicamente carecía de modelo de datos; no sabía 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 nómina parecían iguales. El conocimiento sobre el contenido de los archivos -los datos que contienen .y el modo en que esos datos están organizados- se incorporaba en los programas de aplicación que utilizaban el archivo, como se muestra en la Figura 4.1. En esta aplicación para nóminas cada uno de los programas de COBOL que procesaban el archivo maestro del empleado contenía una descripción del archivo (file description, FD) que indicaba la disposición de los datos en el archivo. Si se modificaba la estructura de los datos -por ejemplo, si había que almacenar un elemento de datos adicional para cada empleado-, había que modificar cada programa que tuviera accesq al archivo. Como el número de archivos y de programas crecía con el tiempo, cada vez se dedicaba más 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 años sesenta, al desarrollo de sistemas gestores de bases de
de
Programa de actualización de empleados
FD
I I
I I I
I I I
FD
I I
'.
I I I
datos. La idea subyacente a estos sistemas era sencilla: sacar de cada .programa la definición del contenido y la estructura de los archivos y almacenarla, junto con Jos datos, en una base de datos. Al utilizar la información de la base de datos, el SOBD que la controlaba podría adoptar un papel mucho más activo en la gestión de los datos y de las modificaciones de la estructura de la base de datos.
Bases de datos jerárquicas Una de las aplicaciones más imponantes de los primeros sistemas gestores de bases de datos era la planificación de la producción para las empresas manufactureras. Si un fabricante de automóviles decidía producir diez mil unidades de un modelo de coche y cinco mil de otro modelo, necesitaba conocer el número de piezas que debía encargar a sus proveedores. Para responder a esta pregunta había que descomponer el producto (coche) en sus partes (motor, carrocería, chasis), que a su vez había que descomponer en sus componentes (válvulas, cilindros, bujías), 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 jerárquica natural. Para almacenar estos -datos se desarrolló el modelo jerárquico 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.
J~
Archivo maestro emplea~os
Programa de informes de empleados
I I I
Programa de emisiones de cheques FD ¡ I FD I I
I Figura 4.1.
Aplicación para nóminas que emplea un sistema gestor de archivos.
55
Figura 4.2.
Base de datos jerárquica de una lista de materiales.
56
Capítulo 4: Bases de datos relacionales
SOL. Manual de referencia
Para tener acceso a los datos de la base de dalas un programa, podría llevar a cabo las tareas siguientes: • Hallar un componente determinado por su número (como pudiera ser la puerta izquierda). • «Bajar» hasta el primer nodo hijo (la manilla de la puerta). • «Subir» hasta su nodo padre (la carrocería). • ~overse «de lado» hasLa el siguiente nodo hijo (la puerta derecha). La recuperación de los dalOs en las bases de datos jerárquicas exigía, por tanto, navegar por los registros, subiendo, bajando y desplazándose lateralmente registro a registro. Unos de los sistemas gestores de bases de datos jerárquicas más populares era el Sistema de gestión de la información (Information Management System, IMS) de IBM, que se introdujo por primera vez en 1968. Las ventajas de IMS y de su modelo jerárquico son las siguientes: • Estructura sencilla. La organización de las bases de datos de IMS era fácil de comprender. La jerarquía de la base de datos era análoga al organigrama de una empresa o a un árbol genealógico. • Organización padre/hijo. Las bases de datos de IMS eran excelentes para la representación de las relaciones padre/hijo, como «A es parte de B» o «A
es propiedad de B•. • Rendimiento. IMS almacenaba las relaciones padrelhijo en forma de punteros físicos de un registro de datos a otro, por lo que el movimiento por la base de datos era rápido. Como la estructura era sencilla, IMS podía situar los registros padres e hijos cercanos unos de otros en el disco, lo que minimizaba las operaciones de entrada y salida de disco.
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 jerarquía 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 jerárquico 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 estándar 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 años. Pero, durante los años 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 jerárquicas. Los programas de aplicación podían hacer lo siguiente: • Hallar un registro padre concreto mediante su clave (que puede ser el número de cliente). • Bajar hasta el primer hijo de un conjunto determinado (el primer pedido rea· ¡izado por el cliente).
Clientes
IMS sigue siendo un SGBD muy utilizado en los grandes sistemas de IBM. Su rendimiento bruto lo convierte eñ·la base de datos preferida para las aplicaciones de elevado volumen de procesamiento de transacciones, como el procesamiento de las transacciones de los cajeros automáticos de los bancos, comprobación de los números de las tarjetas de crédito y seguimiento de la entrega de paquetería urgente. Aunque el rendimiento de las bases de datos relacionales ha mejorado espectacularmente en la última década, los requisitos de rendimiento de las aplicaciones de este tipo también se han incrementado, por lo que IMS sigue teniendo un papel que desempeñar. Además, el gran número de datos empresariales almacenado en bases de datos de IMS garantiza que el empleo de IMS se prolongue hasta mucho después de que las bases de datos relacionales hayan eliminado la barrera del rendimiento.
Bases de datos en red La sencilla estructura de las bases de datos jerárquicas se volvió un inconveniente cuando los datos pasaron a tener una estructura más compleja. En una base de
57
Vendedores
Pedidos
Figura 4.3.
Relaciones padre/hijo múltiples.
Productos
58
SOL. Manual de referencia
Conjunto
Figura 4.4.
Una base de datos de red (CODASYL) para el procesamiento de pedidos.
• 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 más, el programador tenía que navegar por la base de datos registro a registro, esta vez especificando la relación por la que hay que navegar, además de la dirección. " Las bases de datos de red tenían varias ventajas: • Flexibilidad. La existencia de varias relaciones padre/hijo permitían a las bases de datos de red representar los datos que no tení~n una estructura jerárquica sencilla. ; . • Estandarización. El estándar 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 presumían de un rendimiento próximo al de las bases de datos jerárquicas. Los conjuntos se representaban como punteros hacia los registros físicos de los datos y, en algunos sistemas, el administrador de la base de datos podía especificar las agrupaciones de los datos de acuerdo con las relaciones de los conjuntos. Las bases de datos de red también tenían sus inconvenientes. Al igual que las bases de datos j-erárquicas, resultaban muy rígidas. Había que especificar las rela-
Capítulo 4: Bases de datos relacionales
59
dones de conjunto y la estructura de los registros con antelación. La modificación de la estructura de la base de datos solía exigir la reconstrucción de toda la base de datos. Tanto las bases de datos jerárquicas como las de red eran herramientas para los programadores. Para responder a una pregunta, como el producto más solicitado por Acme, el programador tenía que escribir un programa que se desplazara por la base de datos. La pila de solicitudes atrasadas de informes personalizados solía extenderse a semanas o meses, y para el momento en que el programa estaba escrito, la información que aportaba solía carecer de valor. Los inconvenientes de los modelos jerárquico y de red motivaron un intenso interés 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 más que una curiosidad académica. Las bases de datos de red siguieron siendo importantes durante los años setenta y principios de los años ochenta, especialmente en los sistemas de minicomputadoras, cuya popularidad iba en aumento. Sin embargo, a mediados de los años ochenta, el modelo relacional se fue imponiendo claramente como la «nueva ola» en gestión de datos. Para principios de los años noventa, la importancia de las bases de datos de red se hallaba en franco declive, y hoy en día ya no desempeñan un papel importante en el mercado de las bases de datos.
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 explícitas 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 versión relacional de la base de datos "de red para el procesamiento de pedidos de la Figura 4.4. Por desgracia, la definición práctica de lo que es u~ base de d3:~oS relacional se volvió mucho menos rotunda que la definición matemática 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 crecía en popularidad, muchas bases de datos que se denominaban «relacionales», en realidad, no lo eran. En respuesta a la degradación del ténnino «relacional», el Dr. CocId escribió un artículo en 1985 en el que establecía doce reglas que debía seguir cualquier base de datos que se denominara «verdaderamente relacional». Las doce reglas de Codd se han aceptado desde entonces como la definición de los verdaderos SGBD relacionales. No obstante, resulta más sencillo comenzar con una definición menos formal: Una base de datos relacional es una base de datos en la que todos los datos visibles para el usuario están 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
SOL Manual de referencia
Capítulo 4: Bases de datos relacionales
61
Tabla PRODUCTOS
OESCRIPCION Serie 3. cable
PRECIO 107,00 €
STOCK 207
Serie 4, cable
117,00 €
139
Hilo de cobre
_ _PEVlOO
Tabla PEDIDOS NUK PEDIDO 112963 112975 112983 113012
CLIENTE
Acme JCP S.A.
Acme JCP S.A.
PRODUCTO 41004 2A44G 41004 41003
PECHA....PWlDO
112961
14
350,00 €
CLID:TE
17112/1989
2117
113012
llfOllU90
2111
112989
0l/01/1990
2101
113051
10/0211991)
2118
112958
12/10/1989
2102
113036
2107 2112
111045
lO/Olflno 02/02/1990
CANTIDAD
112961
1111211989
2101
28 6 6 35
113013
14/01/1990
2118
111058 U2997
n/ovugo 08/0111990
2124
112983
27112/1989
2101
11302.
20/01119'0
2114
... Tabla CLIENTES
2108
113062
24/0211990
2124
112979
12110/1989
2114
113027
22/01/1990
2103
LIMITE CREOITO
113007
08/01/1990
2112
Acme
REP CLI 105
50.000,00 €
JCP S.A.
103
1130H 111014
0210311990 29/01/1990
2109 n01
50.000.00 €
112992 112915
04/11/19U
2118
12110/1989
2111
113055
15/0211990
2108
1130U
10/0211990
2120
112993
0'10111989
2106
113065 113003 11)049
27/0211990 25/0111990
2106
112981
10/0211990 31/12/1989
2118 2103
113057
18/02/1990
2111
n30U
0210211990
211)
EMPRESA
Figura 4.5.
..
Tabla PEDIDOS
Una base de datos relacional para el procesamiento de pedidos.
Esta definición está pensada específicamente para excluir estructuras como los punteros incorporados de las bases de datos jerárquicas 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.
La base de datos de ejemplo La Figura 4.6 muestra una pequeña base de datos relacional para una aplicación 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 Apéndice A contiene una descripción 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 información sobre una clase concreta de entidad: • La tabla CLIENTES almacena datos sobre cada cliente, como el nombre de la empresa, el límite de crédito y el representante que llama al cliente. • La tabla REPRESENTANTES almacena el número de empleado, su nombre, su edad, las ventas en el año 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 región comercial a la que pertenece, etc.
S...... I Ch"s1 Ilernarclo Unchn D&ni .. 1 ku1drobo
1""". Su León Pnin Pablo e ...... Ileu&
Figura 4.6.
A.~'r.te
" " " " "" U
.. ""
Of"ICI
ro"
", " " " " " " " " "
VUlTAS
1I6.0U.00 U2.U1.00 735.0U.00 n7.911.00 1l5.915.00
ro=
,
f: f: f: lE f:
~~ro
Represen""'~.
1210211,.8
/lepres~t4n'"
12110/19$9
Ilepr..s""tant.. VP V..nt...
1011211,.6 14/06/1988
Jefe V"" ....
19/05/1987
Represent.n... l
~O/IO/UU
Il/0III"0
Jefa V"" ....
lUIO/Un
Representan.e
0l/Ol/1981
Repru.. n'an~ ..
It/Il/U88
,u....
... ,.. ... ,. '" '" ..,.,
ro~
~,
~~
350.000.00 E:
l57.911.00 E:
300.000.00 E: )50.000.00 E: 21$.000.00 E:
392.725.00 E: 474.050.00 E:
200.000.00 E:
2".'12.00 € U2.5~ •. 00 E:
lOO.OOO.OO €
l05.673.00 E:
~,
75.985.00 €
l50.000.00 E:
l61.865.00 €
215.000.00 E:
186.775.00 €
lOO.OOO.OO E:
U6.042.00 E:
63
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 Capítulo 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 física -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 año en curso para cada oficina. La columna JEF muestra el número 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 año 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
La base de datos de ejemplo (continuación).
• 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 número de producto, su descripción y su precio.
Tabla OFICINAS
OFICINA CIUDAD 22 Daimiel 11 Navarra 12 Castellón 13 Almería 21 Los Ángeles
t
Tablas El principio organizativo de las bases de datos relacionales es la tabla, una disposición rectangular en filas y columnas de valores de datos. Cada tabla de la base de
La estructura en filas y columnas de las tablas relacionales.
64
Capítulo 4: Bases de datos relacionales
SOL. Manual de referencia
tabla deben tener nombres diferentes, pero no hay nada que prohíba que dos columnas de tablas diferentes tengan nombres idénticos. 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 producción. 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 mínimo, una columna. El estándar ANSI/ISO de SQL no especifica un número máximo de columnas por tabla, pero casi todos los productos comerciales de SQL sí que imponen un límite. Generalmente, el límite es de doscientas cincuenta y cinco columnas o más por tabla. A diferencia de las columnas, las filas de las tablas no tienen ningún 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 garantía 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 disposición de las filas dentro de la tabla. Las tablas pueden tener cualquier número de filas. Las tablas sin ninguna fila son perfectamente legales y se denominan tablas vacias (por motivos obvios). Las tablas vacías siguen teniendo estructura, impuesta por sus columnas; tan sólo no contiene ningún dato. El estándar ANSI/ISO no limita el número 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 límite máximo, pero siempre muy generoso -dos mil millones de filas o más 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 combinación de columnas. La columna ID_FAB identifica al fabricante de cada producto de la tabla, y la ca· lumna ID_PRODUCTO especifica el número de producto del fabricante. La colum· na ID_PRODUCTO podría ser una buena clave primaria, pero no hay nada que impida que dos fabricantes diferentes utilicen el mismo número para sus produc· tos. Por tanto, hay que utilizar una combinación 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 combinación ú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 demás se denominan relaciones en términos matemáticos. El nombre «base de datos relacional» proviene de este término, ya que las relaciones (tablas con filas dife· rentes) se hallan en el corazón 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 explícito a las claves primarias. Los diseñadores de bases de datos solían asegurar que todas las tablas de sus bases de datos tuvie· ran una clave primaria, pero el SoBD en sí mismo no proporcionaba ningún 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 estándar ANSI! ISO se amplió para incluir la definición de soporte de clave primaria y, hoy en día, la mayor parte de los sistemas gestores de bases de datos lo ofrecen.
Claves primarias Como las filas de las tablas relacionales no están ordenadas, no se puede seleccionar una fila concreta por su posición en la tabla. No hay una «primera fila», «última fila» ni «fila decimotercera» de una tabla. Entonces, ¿cómo se puede especificar una fila concreta como, por ejemplo, la fila de la oficina comercial de Daimiel? En las bases de datos relacionales bien diseñadas, cada tabla tiene alguna colum· na o combinación de columnas cuyos valores identifican de manera unívoca cada fila de la tabla. Esta columna (o columnas) se denomina clave primaria de la tabla. Véase una vez más 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 compañía se expande y abre dos oficinas comerciales en la misma ciudad, la columna CIUDAD ya no puede servir de clave primaria. En la práctica los «números de identificación», como los números de oficina (OFICINA en la tabla OFICINAS), los números de empleado (NUM_EMPL en la tabla REPRESENTANTES) y los números de cliente (NUM_CLI en la tabla CLIENTES) suelen escogerse como claves primarias. En el caso de la tabla PEDIDOS no hay opción -lo único que idenli· fica de manera unívoca un pedido es su número de pedido (NUM_PEDIDO).
- - - - ------- -
65
Tabla PRODUCTOS ID_FAS ID PRODUCTO DESCRIPCIÓN
'CI .eI BIC
.
41003 41004 41003
..
PRECIO
STOCK
Serie 3, cable 107,00€ Serie 4, cable 117,00E: Hélice 652,OOE:
139
,
Clave principal
Figura 4.8.
Tabla con una clave primaria compuesta.
207 3
66
SOL. Manual de referencia
Capítulo 4: Bases de datos relacionales
Relaciones j
Una de las principales diferencias entre los modelos relacionales ~ los modelos de datos anteriores es que los punteros explícitos, como las relacIOnes padre! hijo de las bases de datos jerárquicas, están prohibidos en las bases de datos relacionales. No obstante, como es obvio. _estas relaciones también 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 relación obvia entre las filas de la tabla OFICINAS y las de la tabla REPRESENTANTES. ¿El modelo relacional no «pierde información» 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. Obsérvese que la columna OFICINA_REP de la tabla REPRESENTANTES contiene el número 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 números de oficinas hallados en la columna OFICINA de la tabla OFICINA. De hecho, se puede hallar la oficina comercial en la que trabaja Maóa liménez buscando el valor de la columna OFICINA_REP (11) de Maóa 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-
Tabla OFICINAS OFICIN CIUDAD - REGIÓN Oeste Este Este
Tabla REPRESENTATES NOMBRE
lO'
Bruno Arteaga Maria Jimenez
102 106
Susana Santos Samuel Clavel
105
Figura 4.9.
Una relación padre/hijo en una base de datos relacional.
67
lumna OFICINA_REP de la tabla REPRESENTANTES el valor correspondiente (en las filas de María liménez y Samuel Clavel). La relación padre/hijo entre una oficina comercial y la gente que trabaja en eIJa no se pierde con el modelo relacional, tan sólo deja de representarse mediante un puntero explícito almacenado en la base de datos. En lugar de eso, la relación 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 recuperación de la base de datos de los datos relacionados entre sí mediante la manipulación 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 números 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 relación padrefhjjo entre las tablas que las contienen, al igual que las relaciones padre/hijo de las bases de datos jerárquicas. Al igual que una combinación de columnas puede servir de.clave primaria de una tabla, las claves externas también pueden ser una combinación 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 número de columnas y los tipos de los datos de las columnas de la clave externa y de la clave primaria deben ser idénticos entre sr. Una tabla puede contener más de una clave externa si se halla relacionada con más 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 muestra·el ejemplo, el modelo relacional tiene toda la potencia del modelo de red para expresar relaciones complejas.
68
Capítulo 4: Bases de datos relacionales
SOL. Manual de referencia
Tabla CLIENTES f:!'l.PRESA NUM eLI
~
NUI'LEKPL
~
A=e
NOMBRE
112963
Bruno
"'"
"
l7-DIC-89
CLlEIm:
'>L
10
3.
ID FAB ID PRODUCTO DESCRIPCI
Arteag
~\ PEDIDO FECHA_P
Figura 4.10.
Tabla PRODUCTOS
Tabla REPRESENTANTES
41004)
Serie 4.
cable
~ >
~
4.
'" ''''
1\105
P ODUcro
ACI 4 1004)
5.
;. <
.,;
Varias relaciones padre/hijo en una base de datos relacional.
6. 7.
Las 12 reglas de Codd " En su artículo 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 definición semioficial de las bases de datos relacionales. Las reglas proceden del trabajo teórico de Codd sobre el modelo relacional y representan realmente más un objetivo ideal que una definición de las bases de datos relacionales.
2.
bIes de manera lógica recurriendo a la combinación del nombre de una tabla, el valor de una clave primaria y el nombre de una columna. Tratamiento sistemático de los valores NULL. Los valores NULL (que son diferentes de la cadena de caracteres vacía y de las cadenas de caracteres de caracteres en blanco y de cero o de cualquier otro número) están incluidas en los SGBD completamente relacionales para la representación de manera sistemática de la información ausente y de la información no aplicable, independientemente del tipo de datos. Catálogo dinámico con conexión basado en el modelo relacional. La descripción de la base de datos se representa en el nivel lógico 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 mínimo, 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:
• Definici6n de los datos. • Definición de las vistas. • Manipulación de los datos (de manera interactiva y mediante programaci6n). • Restricciones de integridad. • Autorización. • Límites de las transacciones (comienzo, compromiso y retroceso).
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 añadió en DB2 Version 2, se han añadido desde entonces al estándar ANSUISO y aparecen hoy en día en muchos productos comerciales.
l.
69
8.
9.
Regla de la información. Toda la información de las bases de datos relacionales se representa de manera explícita en el nivel lógico 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 atómicos) de una base de datos relacional sean accesi-
10.
1
Regla de la actualización de las vistas. Todas las vistas que, en teoría, sean actualizables también lo son por el sistema. Inserción, actualización y eliminación 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 sólo se aplica a la recuperación de los datos, sino también a la inserción, actualización y eliminación de datos. Independencia de los datos físicos. Los programas de aplicación y las actividades de los tenninales no se ven afectados lógicamente cuando se producen cambios en las representaciones para almacenamiento o en los métodos de acceso. Independencia de los datos lógicos. Los programas de aplicación y las actividades de los terminales no se ven afectados lógicamente cuando se realizan en las tablas base modificaciones de cualquier tipo que preserven la información y que, teóricamente, 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 catálogo, no en los programas de aplicaci6n.
70
SOL. Manual de referencia
11.
12.
Capítulo 4: Bases de datos relacionales
Independencia. de la distribución. Los SGBD tienen independencia de la distribución. Regla de la no subversión. 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 reglas 8 y 9 aíslan a los usuarios o a los programas de aplicación de la implementación de las bases de datos a bajo nivel. Especifican que ni las técnicas 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 informáticos. Los datos distribuidos y los retos de su gestión se describen en el Capítulo 23. Finalmente, la regla 12 evita «otros caminos» de acceso a la base de datos que puedan subvertir su estructura relacional y su integridad.
la vez).
En los primeros años noventa, se hizo popular la compilación de «tablas de puntuación» 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 puntuación solían estar llenas de notas al pie y de salyedades, y no revelaban gran cosa sobre los productos. Hoy en día 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 aplicación que soporten ese sistema concreto de bases de datos y. otros aspectos, más 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, básicamente, 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 lótalización 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 Capítulo 5. . . La regla 4 exige que las bases de datos relacionales se describan a sí mismas. En otros términos, las bases de datos deben contener determinadas tablas de sistema cuyas columnas describan. la estructura de la propia base de·datos. Estas "tablas se describen en el Capítulo 16. . .' , La regla 5,obliga a emplear .un lenguaje relacional de bases del datos, como SQL, aunque no se. exija específicamente que sea,SQL. El lenguaje debe poder albergar las funciones iundamentáles de los SGBD .!.....:;creación de!\)ases de datos, recuperación e introducción de.datos•.implementación 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 más difíciles de·implementar.. en.lapráctica, ·y-hoy en día ningún producto comercial la cumple totalmente. Las Lvistas yJos problemas de su actualización se describen en el Capítulo 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 inserción, eliminación y actualización. Esta regla está pensada para .prohibir las implementaciones que admiten la modificaci6n mediante navegación, sólo una fila cada vez, de la's bases de datos. 'j'
71
Resumen SQL se basa en el modelo relacional de datos que organiza los datos de las bases de datos como un conjunto de tablas:
I l'
1
;
1
i I
]
• Cada tabla tiene un nombre que la identifica de manera unívoca. • Cada tabla tiene una o varias colu:mnas con nombre que están dispuestas en un orden determinado, de izquierda a derecha. • Cada tabla tiene cero o más fiJas, cada una de las cuales contiene un único valor de datos en cada columna. Las filas no están 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 están 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 unívoca cada fila de la tabla. Cada tabla tiene sólo una clave primaria. • Una clave externa es una columna o una combinación de columnas de una tabla cuyos valores son el valor de la clave principal de alguna otra tabla. Cada tabla puede contener más de una clave externa, que la vincula a una o varias tablas. • Una combinación de claves primarias y claves externas crea una relación padre/hijo entre las tablas que las contienen.
Parte II
RECUPERACiÓN DE BATOS ~
Las consultas son el corazón del lenguaje SQL, y muchos usan SQL como herramienta de consulta de bases de datos. Los cinco capítulos siguientes describen las consultas SQL en profundidad. El Capítulo 5 describe las tructuras básicas del lenguaje SQL que se usaD para fQrmar las instrucciones SQL. El Capítulo 6 estudia consultas simples que obtienen datos de una única tabla de datos. El Capítulo 7 expande el estudio a consultas sobre varias tablas. Las consultas que resumen datos .se describen en el Capítulo 8. Finalmente, el Capítulo 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 capítulo comIenza con una descripción detallada de las características de SQL. Describe la estructura' básica.de una instrucción SQL y los elementos básicos del lenguaje, como las palabras clave,-los tipos de datos y las expresiones. También se describe la forma en que SQL maneja los datos con valores NULL. Aunque éstas sean las características básicas
estas diferencias y
I
I
. j.'
. : .•
,
.. .','
. ,¡
. ', ,
.,'. '
'. ~J
..-.
¡
e~t~nsiones.
. .;"_'
Instrucciones El cuerpo principal del lenguaje SQL consiste en unas 40 instrucciones.. Las in~. trucciones más importantes y usadas con mayor frecuencia' se resumen ~én"I2.~'Ta~ bla 5.1. Cada instrucción requiere un'a acción- específica del SGBD, comó ctéár una nueva tabla, recuperar datos o insertar datos nuevos en la base de datos. Todas las ins~cciores,SQL tienen la.mis9Ja.fo~a.,bási<;:a:.JJustrada en la Fig~ra 5.L ~ Cada instrucción SQL comienza con un verbo. una palabra clave que describe lo que hace la instrucción. CREATE, INSERT, DELETE y COMMIT son verbOs -habituales. La instrucción continúa con'una o más·cláusulas. Una cláusula puede especificar los datos sobre los que operará la instrucción, o proporcionar más detalles sobre lo que debe hacer la instrucción. Cada cláusula también comienza con una pahibra clave:' com'ü WHERE, FRÓM," '.i:NTO 'HAVING. A)gunas cláusulas son opcionales, y otras son-obli'gatbrfas. El-confénidd y e""stttittüt'a específicos pueden variar para distintas cláusulas, Muchas cláusulas c'onti'ene"tt1i Í1'ombres de tablas o de columnas; algunas contienen palabras clave, constante,sno expresiones adicionales. El estándar SQL.de ANSI/lSO eSp'ecific~.I,~s,p,¡¡J~!1fas clave SQL que se usan como verbos y en cláusulas. De acuerdo con el estánd~ estas palabras clave no se pueden..llsar .para.denominar_oh}elos.,oeJa baSe Jé:B~tÓ~ tales._como tablas.. colum-
o
'l
...
75
1
76
SOL. Manual de referencia
Tabla 5.1.
I
Capítulo 5: Fundamentos de SQL
77
Instrucciones principales de SQl
nstrucción
Descripción
Nombre de tabla
Manipuúu:ión de datos SELECT
Verbo
~Of:LETE
Recupera datos de la base de datos.
INSERT
Añade nuevas filas de dalos a la base de datos.
DELETE
Elimina filas de datos de la base de datos.
UPDATE
Modifica datos existentes en la base de datos.
¡::;"
~
FROM
Cláu,ula,
REPRESENTANTE~
wtfEM. lIENTAS < 2 OOOO• OO
Palab,., clav:
/
/
.
Definición de datos CREATE TABLE
I
I
DROP TABLE
Elimina una tabla de la base de datos.
ALTER TABLE
Cambia la estructura de una tabla existente.
CREATE VIEW
Añade una nueva vista a la base de dalos.
DROP VIEW
Elimina una vista de la base de datos.
CREATE INDEX
Construye un índice sobre una col,:,-mna.
OROP INDEX
Elimina el índice de una columna. d~
CREATE SCHEMA
Añade un nuevo esquema a la base
DROP SCHEMA
Eliminaun esquema de la base de datos. Añade un nuevo dominio qe valores de datos. Cambia la definición de un dominio. Elimina un dominio de la base de datos.
CREATE DOMAIN ALTER DOMAIN DROP DOMAIN
datos.
Control de acceso GRANT
REVQKE
Concede privilegios de acceso a los usuarios. Elimina privilegios de acceso de los usuarios.
Control de transacciones COMMIT ROLLeACK SET TRANSACTION
Finaliza la transacción actual. Aborta la transacción actual. Define las-características de acceso a datos de la transacción actual.
Programación con SQL DECLARE EXPLAIN OPEN FETCH CLaSE PREPARE EXECUTE DESCRIBE
Nombre ¿umna Constante
Añade una nueva tabla a la base de datos.
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 instrucción SQL para la ejecución dinámica. Ejecuta dinámicamente una instrucción SQL. Describe una consulta preparada.
Figura 5.1.
La estructura de una instrucción SOL.
nas y usuarios. Muchas implementaciones de SQL suavizan esta restricción, 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 estándar SQL2 de ANSI/ISO, que triplica aproximadamente el número de palabras clave reservadas en el antiguo estándar SQLl. El estándar SQL2 también incluye una lista de palabras clave potenciales que son candidatas para revisiones futuras del estándar. En la Tabla 5.3 se incluyen estas palabras clave. A lo largo del libro se ilustran las fonnas ~ceptables de una instrucción SQL mediante un diagrama sintáctico, como el que se muestra en la Figura 5.2. Una instrucción o cláusula SQL válida se construye «siguiendo la línea» en el diagrama sintáctico y en los ejemplos (como DELETE y FRoM,en la Figura 5.2) siempre se muestran en mayúsculas, pero casi todas las implementaciones de SQL admiten tanto mayúsculas como minúsculas en las palabras clave, y a menudo es más conveniente escribirlas en minúsculas. Los elementos variables de una instrucción SQL (como el nombre de la tabla y la condición de búsqueda en la Figura 5.2) se muestran en minúsculas cursivas. Es privativo especificar el elemento apropiado cada vez que se usa la instrucción. Las cláusulas y palabras clave opcionales, tales como la cláusula WHERE de la Figura 5.2, se indican como caminos alternativos en el diagrama sintáctico. Cuando se ofrece la elección de palabras clave opcionales, la elección predetenninada (es decir, el comportamiento de la instrucción si no se especifica ninguna palabra clave) aparece SUBRAYADA.
Nombres Los objetos de una base de datos SQL se identifican asignándoles nombres únicos. Los nombres se usan en las instrucciones SQL para identificar el objeto de
saL.
78
79
Capítulo 5: Fundamentos de SOL
Manual de referencia
Palabras clave potenciales de SQL2 de ANSI/ISO
Tabla 5.3.
< 0'-'
',.- TEST
ABSOLUTE
CROSS
NE:XT
SPACE
ACTION
CURRENT
'"'
AFTER. ;
GLOB~L
NO
soc
ALIAS
AOO
CURRENT_OATE
co
NOT
SQLCOOE
ASYNC
ALL
CURRENT2.TIME
BE:FORE
IGNORE
OTHERS
BOOLEAN
LE:AVE
"PARAMETERS
BREADTH
LESS
COMPLE:TION
LIMIT
PREORDER
SEARCH :.
VIRTUAL
CALL
LOOP
PRIVATE
SENSITIVE
VISIBLE
CYCLE
MODIFY
PROTECTED
SEQUENCE
DATA
N'"
RECURSIVE
SIGNAI¡:
'GOTO
ALLOCATE
NULL.
SQLERROR
OCTET_LENGTH
SQLSTATE SUBSTR1NG
ALTER
CURRENT_USER
GROUP
OR
ANO
CURSOR
HAV1NG
ON
AN'
DATE
HOUR
ONLY
'" ""C
IDENT1TY
OPEN
TABLE
DEALLOCATE
1MMEDIATE
.OPTION
TEMPORARY
O"
ASSERTION
DECIMAL
"
1ND1CATOR
ORDER
AT
DECLARE
1N1TIALLY
OUTER
AUTHORIZATION
DEFAULT
1NNER
OUTPUT
AV'
DEFERRABLE
INPUT
OVERLAPS
BE.GIN
DEFEí!-RED ,
SUM
"'"
OR
DEPTH
NONE
DICT10NARJ ;(
OBJECT
TIMEZONE_HOUR
EACH
OFF'
TIMEZONE_M1NUTE
ELSEIF
0>0
TIME
.TIMESTAMP
DEL~TE,
INSERT
PART1AL
TRA:Lt':l",G
DEse
>NT
POS.1TION
TRANSACT10N
BIT_LENGTH
DESCRIBE
1NTEGER
PRECISION
TRÁNSLATE ::
DESCRIPTOR
CASCADE
:'1NTERSECT 1NTERVAL
iOISCONNECT
CA·SCADEti· CASE
", 'ÓI~~I~¿'TI
INTO 'Ji
. '1S
DOMAIN
1SOLAT10N
CAST
DOVBLE
JÓ1N
CATALOG
DROP
PREPARE
TRANSLATION
P~E:SERVE
TIÜM
PR'rMARY . PRIOR'
TRUE .. ,
PR1V1LEGES
UNIQUE
UN10N
"' ~PROCEOURE
'
UNKNOWN
CHAR
ELSE
'" LANGUAGE
'PUBLIC
CHARACTER
END .
LAST
REAL
CH~_LENGTH
El;ID_EXEC
LEA01NG
CHARACTER_LENGTH
ESCAPE
LEFT.
RELAT1VE
USING
CHECK
EXCEPT
LEVEL
RESTR1CT
VALU~
CLOSE
EXCEPTION
L1KE
RE:VOKE
VALUES
CO!'L~~~E
EXEC
LOCAL
R1GHT
VARCHAR
COLL,ÚE
EXECUTE
LOWER
ROLLBACK
COLLATIÓN
EXIsTS
COLUMN
E:XTERNAL
MAX
SCHEMA
COHMIT
EXTRACT
M"
'SCROLL
'~TCH
'UPOATE
RE:AD
UPPER USAGE
.REFERENCES
USER
0,"
,
ROWS
"
THERE
OPERATORS
ROLE
TR1GGER
. PENOANT
RON
UNDER ';
SÁVEPOINT
VARIABLE
WAIT "":\
SIMILAR
\'iHIut ,. l.;, WITHOUT
SQI¡E:l'¡CEPTION,
REFERENCltJG •• REPL},CE;
.;j
'SQLWARNING
RFSJ;GNAL
STRUCTURE
la base de datos sobre el que la instrucción debería 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 ,base·de ·datos); 'en .el ~stándar original SQLl ¡se especificaron 10s convenios de denominación !de¡estb.s'l0bjet0s: El estándar SQL2,de ANSUISO expande significativamente lajlista de¡entidá.'des con nombre para incluir esquemas (colecciones de tablas');restricciones'{ligadu:" ras sobre los contenidos de las' tablas y'sus rélaciones);ldominios (conjiúHós 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 réplica de 'dato"s: El estándar 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 puntuación especiales. El estándar SQL2 aumentó el máxiino
VJl.RYING
,';
VIEW WHEN WHENEVÉR
COWh:CT
FALSE .
MINUTE'
SECONO
CQNNECTION
FETCH
Momn::E'
. SECTION
CONSTRAINT
FIRST
MONTH
SELECT
WORK
CONSTRAINTS
FLOAT
NAMES
SESSION
WRITE
WHERE'
,1----,...--
DELETE FRDM
rJombre·de-tabfa --~...,.------,
'·WITH
CONTINUE
ROR
NAT10NAL
SESSION_USER
Y"R
CONVERT
FORE1GN
NATURAL
s"'
ZONE
CORRESPONOING
FOUNO
NCRAR
SIZE -
COUNT CREATE
FROM
NULL1F
SMALL1NT
FULL
NUMERIC
SOME
- [:
RETURNS·
!
BE~EEN
OIAGNOSTICS
RETURN
OPERAT10N
TO
BIT'
BY
EQUALS GENERAL
. 'SYSTEM_USER
.~,
80TH
'OLO
.,'
L
+
WHERE
"
condición-de:biísqúeda""C"'-'-"''----'''-+!
• Figura 5.2.
Un diagramálsintácti'ca~deejempID:::~ '¡"~':¡ ;':-,;-.~
80
SOL. Manual de referencia
a 128 caracteres, En la práctica, los nombres albergados.por los productos SOBD basados en SQL varían significativamente. Es común ver restricciones más fuenes sobre los nombres que están conectados con otro software fuera de la base de datos (tales como nombres de usuarios, que pueden corresponder con los nombres de inicio de sesión usados en un sistema operativo), y restricciones más débiles sobre los nombres que son privados a la base de datos. Los diferentes productos también 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.
Capítulo 5: Fundamentos de SOL
81
Nombres de columnas Cuando se especifica un nombre de columna en una instrucción SQL, SQL puede determinar normalmente por el contexto la columna que se pretende. Sin embargo, si la instrucción involucra dos columnas con el mismo nombre de dos tablas diferentes, se debe usar un nombre de columna calificado para identificar sin ambigüedad 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:
Nombres de tablas
REPRESENTANTES. VENTAS
Cuando se especifica el nombre de una tabla en una instrucción 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 pequeños 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 elección de los nombres de las tablas recae en el desarrollador o diseñador de la base de datos. En una base de datos más grande de uso compartido y corporativa, puede haber estándares corporativos para la denominación de tablas, con el fin de' asegurar que los nombres de las tablas no entren en conflicto. Además, la mayoría 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 CUMPLEAÑOS). El SGBD usa la tabla apropiada dependiendo del usuario que esté realizando la consulta. Con los permisos adecuados también 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 podría acceder a la tabla CUMPLE~OS de Susana usando el nombre de tabla 'calificado:
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.CUMPLEARos
Un nombre de tabla calificado se puede usar generalmente en una instrucción SQL en cualquier lugar en que pueda aparecer un nombre de tabla. El estándar SQL2 de ANSIIISO generaliza la noci6n de un nombre de tabla calificado aún más. Permite la creación de una colección de tablas con nombre, denominada esquema. Es posible hacer referencia a una tabla en un esquema específico usando un nombre de tabla -calificado. "Por ejemplo, la referencia a la tabla CUMPLEAÑOS del esquema INFOEMPLEADOS sería: INFOEMPLEADOS.CUMPLEARos
El Capítulq 13 proporciona más información sobre los esquemas, usuarios y otros aspectos de la estructura de una base de datos SQL.
SUSANA. CUMPLEA»OS. FECHA_NAC
Los nombres de columna calificados se pueden usar generalmente en una instrucción SQL en cualquier lugar en que pueda aparecer un nombre simple de columna (sin calificar); en las descripciones de cada instrucción SQL se destacan las excepciones.
Tipos de datos El estándar 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 estándar SQLl original especificó sólo un conjunto mínimo de tipos de datos" El estándar 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 también frecuentemente para contener número de identificación (ID), como cliente, empleado y números de pedidos. • Números decimales. Las columnas con este tipo de datos almacenan números que tienen partes fraccionarias y deben ser calculados con precisión, como las tasas y los porcentajes. Se usan también frecuentemente para almacenar cuentas de dinero.
82
SOL. Manual de referencia
• Números en coma flotante. Las columnas con este tipo de'datos_se,usan para almacenar números científicos que pueden ser objeto de cálculo aproximado, como pesos y distancias. Los número en coma flotant~·pueden.repre: sentar un rango mayor de va,lores que Jos números decimales, pero producen errores de redondeo en los .cálculos. • 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 varían en su longitud de fila en fila, con un tamaño máximo. (El estándar SQLI permitía sólo cadenas de caracteres de longitud fija, que son más fáciles 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 número,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 también común 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 aritmética de fechas y horas. El estándar'SQL2incluye una'especificaciólÍ-elaborada para los tipos de datos DATE, TIME, TIMESTAMP éLrNTERVAL, in'c1u''; yendo soporte para zonas horarias y precisión temporal (por ejemplo; décimás o centésimas de segundo). • Datos booleanos. Algunos productos SQL, como Informix Dynamic Server, albergan valores lógicos (TRUE y FALSE) como un tipo explícito,' y algUiIos también permiten operaciones lógicas (comparaciones, AND y OR, Y'otras) sobre los datos almacenados·con·instrucciones ·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.más). Esto permite a la base de datos almacenar documentos completos,' descripciones de productos~~,artículos.téc.:. nicos,:resúmenes 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,"_ búsquedas.'." • Corrientes de bytes sin estructura. Varios SGBD permiten el almacenamiento y recuperación de secuencias de bytes sin estructura y de longitud variable. Las columnas que contie~en estos datos~¡se usan'para almacenar imágenes de vídeo,comprimidas, código 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 añadiendo 'soporte para cadenas de longitud fija y ,variable de caracteres de.-16 bits .usadas para representar Kanji u otros caracteres asiáticos o árabes. Mientras que las, bases
'/ 1
Capítulo 5: Fundamentos de SQL
83
de datos ·modernas permiten el almacenamiento y recuperación de dichos caracteresl (usando a menudo el convenio UNICODE para representarlos), el soporte;de .la búsqueda y ordenación en los tipos GRAPHIC Y VARGRAPHIC .varía 'ampliamente. La Tabla 5.4 lista los tipos de datos especificados en el estándar ANSUISO de SQL. .
Cadenas de bits de longitud variable*. Números decimales.
Números en coma flotante. Números en coma flotante de baja precisión.
REAL DOUBLE PRECISION
Números en coma flotante de-alta. precisión.
DATE
Fechas del calendario*. .1'
TIME
(precisión)
TIMESTAMP
(precisión)
INTERVAL
* Nuevo tipo de datos en SQL2.
Horas de
reloj~.
Fechas y horas*. Intervalos de tiempo*.
84
SOL. Manual de referencia
Capítulo 5: Fundamentos de SOL
Las diferencias entre los tipos de datos ofrecidos en varias implementaciones SQL son una de las barreras prácticas a la transponabilidad de las aplicaciones basadas en SQL. Estas diferencias han sido resultado de la innovación en la evolución de las bases de datos para la inclusión de un rango más amplio de capacidades. Éste ha sido el patrón habitual:
"
• Un fabricante de SaBn añade un nuevo tipo de datos que proporciona nuevas capacidades útiles para un cierto grupo de usuarios. • Otros fabricantes de SGBD añaden el mismo tipo de datos o similar, e introducen sus propias innovaciones para diferenciar sus productos del resto. • Durante varios años se incrementa la popularidad del tipo de datos y llega a ser parte de la «corriente principal» de tipos de datos albergados por la mayoría de implementaciones de SGBD. • Los cuerpos estándares se involucran en el intento de estandarizar el nuevo tipo de datos y eliminar las diferencias arbitrarias entre las implementaciones de los ~abricantes. Cuanto más se ha asentado el tipo de datos, más difícil es encontrar el compromiso al que se enfrenta el grupo de estandarización. Normalmente esto resulta en una adición al estándar que no se corresponde exactamente con ninguna de las implementaciones actuales. • Los fabricantes de SGBD añaden lentamente soporte para el nuevo tipo de datos estandarizado como una opción a sus sistemas, pero, dado que tienen una gran base instalada que usa la versión antigua (ahora «propietaria») del tipo de datos, deben también 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 eliminación de la versión propietaria. Los datos de fecha y hora proporcionan un ejemplo excelente de este fenómeno 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: Almacena una fecha, como Junio 30, 1991. Almacena un momento del día, como 12:30 P.M. T:IKESTAKP. Un instante específico en la historia, con una precisión mejor que el nanosegundo. .
85
SQL Server se introdujo con un único tipo de datos de fecha y hora, denominadatos TIMESTAMP de DB2. Si Server podría aceptar esta versión de la consulta (sin la aritmética 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 mediodía del 14 de junio de 1989, el representante no se incluiría en los resultados de la consulta de SQL Server, pero sí en los de DB2 (dado que s6lo se almacenó la fecha). SQL Server también alberga aritmética de fechas mediante un conjunto de funciones predefinidas. Así, la consulta al estilo DB2 se puede también 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 también 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 versión de Gracle de la consulta es:
• DATE.
• TIME. •
Se pueden especificar fechas y horas concretas como constantes de cad~ena y se incluye la aritmética de .fechas. A continuación se muestra un ejemplo de una consulta válida 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'
+ 15 DAYS
SELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO >= '14-JUN-89'
Oracle también alberga una aritmética limitada de fechas, de forma que la consulta al estilo DB2 también se puede especificar, pero sin la palabra clave DAYS: SELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO >= '30-HAY-89'
+
15
Finalmente, el estándar SQL2 de ANSIIISO añadió soporte para los datos de fecha y hora con un conjunto de tipos de datos basados en los tipos de datos de DB2,
86
pero no idénticos a éstos. Además de los tipos de datos DATE, TIME YTIME5TAMP, el estándar especifica el tipo de datos INTERVAL, que se puede usar para almacenar un intervalo de"tiempo (por ejemplo, un intervalo medido en"días o una duración medida en horas, minutos y segundos). El estándar también proporciona un método muy elaborado y complejo para manejar la aritmética de fechas y horas, especificando la precisión 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 instrucción 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 aplicación se puede trasladar de una base de datos a otra y puede ser muy transportable si sólo usa las características fundamentales y básicas 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 más compleja sea la aplicación, más probable es que.lIegue alser dependiente {fe-las características' y matices específicos, y, por tanto,·menos'tran'sportable. J d. T ''l'']!'
"
87
Capítulo 5: Fundamentos de SOL
SOL. Manual de referencia 21 -375 2000.00
+4~7500.8778
No se d.ebe poner una coma entre los dígitos de _~na constante numérica, y no todos los dIalectos .de SQL permiten ~l signo positivo. así que es mej?r evitarlo. Para los datos monetarios, la mayoría de implementaciones SQL U$an simplemenM te las_ .const~ntes ~nteras ~ decímales, aunque algunas permiten que se esp~cifique la constante con un símbolo de moneda: . . $0.75 $5000.00 $~567.89
Las constantes en coma flotante (también denominadas literales numéricos aproximados) se especifican usando la notación E, usada comúnmente en los len M guajes de programación corno e y FORTRAN. AqUÍ hay algunas constantes válidas 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..
e
c.o~stante "
Constantes
Constantes de cadena
En algunas instrucciones SQL, un valor de datos numérico, de carácter o de fechas se debe expresar de forma textual. Por ejemplo. en esta instrucción INSERT, que añade un representante a la base de datos: ... . -
El estándar ANSIIISO especifica' gti'e las constantes SQL para ios datos de cuacteres se deben encerrar entre comillas simples (' ....), como en estos ejemplos:
, , el valor de cada ¡columna en' la nueva fila insertada se especifica en' ta..cláusula VALUES.' Los valores de datos,constantes también se usan en expresiones, como en , I ", .•.• :.'. la instrucción SELECT:' . " .•
SELECT CIUDAD FROM OFICINAS
WHERE OBJETIVO>
(1.1 * VENTAS) + 10000.00
El estándar SQL de ANSIIISO especifica el fonnato de las constantes de cadena y numéricas,'o literales,'que'representan valores de datos'específicos. 'La mayoría de implementaCiones de SQL ·siguen estos convenios. . 1:
Constantes numéricas Las constantes enteras y decimales (también denominadas literales numáicos exactos)·se e"sc'riben como números:deciinales ordin-ariós en las instrucciones SQL; como uñ'~signo opcional positivo o negativo. .'.'
'Garcia, Juan J .. '
'Madrid'
'Oeste'
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'
l¡
's'
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'..."):
"Garcia. Juan J..
"Madrid"
".
·Oeste"
Desafortunadamente, las comillas dobles pueden plantear problemas de transportabilidad con otros productos SQL. El estándar SQL2 proporciona la capacidad adicional de especificar constantes de cadena de un conjunto concret~· de caracteres nacionales (por ejemplo, francés O alemán) 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
SOL. Manual de referencia
Capítulo 5: Fundamentos de SOL
Constantes de fecha y hora
También se puede usar la función predefinida de Oracle TO_DATE {} para convertir las constantes escritas en otros formatos. como en este ejemplo:
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 varía de un SGBD a otro. Hay incluso más variaciones introducidas por las diferencias en la forma en que se escriben las fechas y las horas en diferentes países. DB2 alberga varios formatos internacionales diferentes para las constantes de fecha, hora y marca temporal, como se muestra en la Tabla 5.5. La elección del formato se hace al instalar el SGBD. DB2 también alberga duraciones especificadas como constantes especiales, como en este ejemplo:
Nótese que, sin embargo, no se puede almacenar una duración en la base de datos, ya que DB2 no tiene un tipo de datos explícito DURATION. SQL Server también alberga los datos de fecha y hora, y acepta una variedad de formatos diferentes para las constantes de fecha y hora. El SGBD acepta automáticamente 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 también se escriben como constantes de cadena, usando este formato: 15-MAR-90
Formatos de fecha y hora en SOL de IBM
Fonnato:
Ejemplo
Fonnato
, ombre, del formato
de la fecha
de fecha
debora
American (americano)
mmldd/yyyy
511911960
hh:mm am/pm 2: 18 PM
European (europeo)
dd.mm.yyyy
19.5.1960
hh.mm.ss
I
Ejemplo de hora
14.18.08
Japanese (japonés)
yyyy-mm-dd
1960-5-19
hh:mm:ss
14:18:08
ISO
yyyy-rnrn-dd
1960-5-19
hh.mm.ss
14.18.08
Formato TIMESTAMP
yyyy-rnrn-dd hh.mm.ss.nnn .nnn
Ejemplo de TIMESTAMP
~-----
1960-05-19-14. 18.08.048632
SELECT NOMBRE, EDAD FROM REPRESENTANTES WHERE FECHA_CONTRATO = TO_DATE('JUN 141989',
'MON DD YYYY'}
El estándar 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 simbólicas
FECHA_CONTRATO + 30 DAYS
Tabla 5.5.
89
Además de las constantes proporcionadas por el usuario, el lenguaje SQL incluye constantes simbólicas especiales que devuelven valores de datos mantenidos por el propio SGBD. Por ejemplo, en algunas marcas de SGBD, la constante simbólica 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á aún en el futuro: SELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO > CURRENT_DATE
El estándar SQLl e'specificaba sólo una única constante simbólica (la constante USER descrita en el Capítulo 15), pero la mayoría de productos:SQL proporcionan muchas más. ,Generalmente, una constante simbólica puede ~parecer en una instrucción SQL en cualquier lugar en que pueda aparecer cualquier constante ordinaria del mismo tipo de datos. El estándar SQL2 adoptó las constantes simbólicas más útiles de las implementaciones SQL y proporciona CURRENT_DATE, CURRENT_TIME y CURRENT_TIMESTAMP (obsérvense 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'simbólicas, La versión de SQL Server para la consulta anterior es: SELECT NOMBRE, FECHA_CONTRATO FROM REPRESENTANTES WHERE FECHA_CONTRATO> GETDATE(}
Las funciones predefinidas se describen más tarde en este capítulo, en la sección «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 uSádos en las búsquedas. Por
90
SOL. Manual de referencia
Capítulo 5: Fundamentos_de SaL
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 porción del año "Bel valor. Esta consulfillista el nombre y mes de contratación de cad~ representante en la base de datos de ejemplo:
100
FRQM OFICINAS
SELECT NOMBRE, MONTH(FECHA_CONTRATO) FROM REPRESENTANTES·
y esta consulta lista las oficinas cuyas ventas superan en sq.OOO € al objetivo: y esta lista SELECT CIUDAD FROM OFICINAS
1.
El estándar SQL de ANSI/ISO especifica cuatro operaciones aritméticas"que se pueden usar en expresiones: suma (X+Y), resta (X-Y), multiplicación (X*Y) y división (XlY). Se, pueden usar.,paréntesisl para formar expresiones más.complica... ..~j, .) .. 1 das.-como,ésta:.' ;. '1: .. ,~'J
-'o '., " .. '1.05) -
~.
I
1.... :.;
,(OBJETIVO.~
_.~,
"
.9?) ..
, , De manera estricta. los paréntesis no se necesitan en esta consulta porque el estándar ANSI/ISO especifica que la multiplicación y la división tienen una precedencia superior a la suma y la resta. Sin embargo, se deberían usar paréntesis siempre para que las expresiones no sean ambiguas. 'dado que diferentes dialectos SQL usan diferentes reglas. Los paréntesis también incrementan la legibilidad de la instrucCiÓn y hacen que 'las instruccíones S.QL sean más fáciles de mantener.' 'El estándar ANSI/ISO también 'especifica la conversión automática de ti'pos de datos de enteros a números 'decimales, y de números decimales a nÚ,meros en coma flotante. Por taÍúo, se pueden mezclar estos tipos 'de datos en una expresión mimé.rica.'Muchas·iInpleme.ntaciónes SQL albergan otros operadores y' admiten operaciones sobre datos de caráéter y de "fecha. DB2, por ejemplo·, alberga el operador de concatenaCión'·de cadenas', escrit<:l"como dos caracteres ·consecutivos 'de'barra vertical (11). Si las columnas NOMBRE y '-?>PELLIDO contienen los valore·s «Juan» y «García», entonces esta 'expresión' DB2: 1 /, ' " 1 . ,"
(. Sr ./Sra.
,.. :_.
'~l ~
•
1I
NOMBRE
¡t,"
11' ....
11
todos los -representantes contratados en 1988:
SELECT NOMBRE, MONTH(FECHA_CONTRATO) FROM REPRESENTANTES WHERE YEAR(FECHA_CONTRATO¡ = 1988
,:
WHERE VENTAS> OBJETIVO + 50000.00
(VENTAS
91
Las funciones predefinidas también se usan habitualmente para dar formato a los datos. La función predefinida de Orade' TO_CHAR ( ) , por ejemplo, toma un tipo de datos DATE y una especificaCión de formato como argumentos, y devuelve una cadena conteniendo la versión 'con formato de la fecha. En los resultados producidos por esta consulta: SELECT NOMBRE, TO_CHAR(FECHA_CONTRATO. 'OAY MONTH 00, yyyy.) FROM REPRESENTANTES
todas las fechas íendrári el fonnato «Wednesday June 14, 1989» debido a la función predefinida. _. En general, las funciones pre.definidas se pueden especificar en cualquier lugar de una expresión SQL en que ,pueda aparecer una constante del mismo tipo de datos. Las funciones pr~efinidas inéluidas 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 estándar 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.
,."
APELLIDO)
produce la cadena «Sr.lSra. Juan García». Como ya ·se ha mencionado. DB2 también 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 estándar SQLl no las especifica, la mayoría de las implementaciones SQL incluye~ varias funciones· predefinidas. Estas facilidades proporcionan a menudo conversiones de tipos de. datos: Por ejemplo. las funciones 'predefinidas
Datos ausentes (valores NUL'LJ DadQ_que una.base. de datos es. usualmente un.modelo de una situación del mundo real, varias piezas de datos estarán inevitablemente ausentes, serán desconocidas o simplemente no se podrán 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 aún no tiene asignada cuota; este dato está ausente en esa fila de la tabla.'lCabría estar tentado de poner un cero en esa columna, pero no sería un reflejo fiel de la situación. El representante no tiene una cuota cero¡ la cuota simplemente «no se conoce aún». ~l De forma similar, la columna DIRECTOR de la tabla REPRESENTANTES contiene el número de empleado de cada' jefe del representante. Pero Sarnuel Clavel,
92
SOL. Manual de referencia
Funciones predefinidas de SGL2
Tabla 5.6.
Devuelve
Función" BIT_LENGTH CAST
(valor
El número de bits en una cadena de bits.
(cadena) tipo_de_datos)
El valor, convertido al tipo de datos especificado (por ejemplo, llna fecha convertida a una cadena de caracteres).
AS
CARACTER_LENGTH CQNVERT
(cadena
(cadena) conv)
La longitud de una cadena de caracteres. Una cadena convertida como se especifica por la función de conversión.
USING
La
CURRENT_DATE CURRENT_TlME
LOWER
(parte
FROM
POSITION
origen)
(origen
IN
(cadena
TRIM (BOTH
carácter
n
USING FROM
carácter
TRIM (TRAILING
(cadena)
origen)
FROM
TRANSLATE
TRIM (LEADING
actual.
La hora y fecha actual, con la precisión especificada. La parte especificada (DAY, HOUR, etc.) de un valor DATETIME. Una cadena convertida a minúsculas.
(cadena)
(objetivo
SUBCADENA
UPPER
(precisión)
(cadena)
OCTET_LENGTH
fe~ha
La hora actual, con la precisión especificada.
(precisión)
CURRENT_TIMESTAMP EXTRACT
Capítulo 5: Fundamentos de SQL
FOR
trad) cadena)
FROM
carácter
longitud)
cadena)
FROM
cadena)
El número de bytes de 8 bits de una cadena de caracteres. La posición en donde aparece objetivo dentro de la cadena origen. Una porción de la cadena origen,
comenzando en el enésimo carácter, en una longitud longitud. Una cadena traducida como se especifica por la funci6n de traducción. Una cadena con las apariciones a ambos lados de carácter eliminadas. Una cadena con cualquier número de apariciones de carácter al principio eliminadas. Una cadena con cualquier. número de apariciones de carácter al final eliminadas. Una cadena convertida a mayúsculas.
vicepresidente de Ventas, no tiene ningún jefe en la organización de ventas. Esta columna no se aplica a SamueL De nuevo, se podría pensar en introducir un cero o 9999 en la columna, pero ninguno de estos valores sería el número de empleado del jefe de SamueL Ningún valor de datos es válido para esta columna. SQL admite explícitamente 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 <
93
datos real, como 0,473,83 o «Samuel Clavel». En cambio, es una señal, o recordatorio, de que el valor de datos está ausente o es desconocido. La Figura 5.3 muestra los contenidos de la tabla REPRESENTANTES. Nótese que los valores de CUOTA y OFICINA_REP de Tomás 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, ¿cómo se deberían 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 cláusulas SQL. A causa de las reglas, algunas personalidades importantes en bases de datos están convencidas de que no se deberían 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 académicos, los valores NULL son una parte muy enraizada del estándar SQL de ANSI/lSO y se admiten en ·prácticamente todos los productos comerciales de SQL. También desempeñan un papel práctico e importante en las bases de datos de producción. 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).
Resumen Este capítulo ha descrito los elementos básicos del lenguaje SQL. La estructura básica 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 más cláusulas. Cada instrucci6n realiza una única función específica.
Tabla REPRESDnANTES NU~ ~PL
'"' '" ,'"'" no '" '"'" '"
..
,~,
"~~
Bruno AnO!a a Maria Ji.....n. . S"Mna SaHos sa",,,el Clavel Bernardo S&nche. Oaniel Ruidrol>o To..... S~z Lebn Freüe Pablo Cr"~ Ne"s A.~~rate
OFICINA REP 13 11 21 11 n 12 12 4l NULL 21 12
"
"'"
" " " ""
n
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
• Las bases.de datos basadas en SQL pueden almacenar varios tipos de datos, incluyendo texto, enteros, números decimales, números en coma flotante y, usualmente, muchos otros tipos de datos específicos del propio fabricante. • Las instrucciones SQL pueden incluir expresiones que combinan nombres de columna, constantes y funciones predefinidas, usando'operadores aritméticos y otros específicos del propio fabricante. • Las variaciones en los tipos de datos, constantes'y funciones predefinidas hacen que la transportabilidad de las instrucciones SQL sea más difícil que lo que pudiera parecer en un primer momento. • Los valores NULL proporcionan una forma sistemática de manejar datos ausentes o no aplicables en el lenguaje SQL.
CAPíTULO
6
Consultas simples
Por muchas razones, las consultas son el corazón del lenguaje SQL. La instrucción SELECT, que se usa para ~xpresaf. consultas SQL, es la instrucción más potente y compleja de las instrucciones SQL. A pesar de las muchas opciones que ofrece la instrucción SELECT, es posible comenzar simplemente y después construir consultas más complejas. Este capítulo estudia las consultas SQL más simples -las que recuperan datos de una única tabla de la base de datos.
La instrucción
5ELEC'l'
La instrucción 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 instrucción SELECT enJa iJ;ltroducción.a SQL del Capítulo 2. Aquí hay algunas otras consultas de ejemplo que recuperan información sobre las oficinas comerciales:
··Listqr las .oficin~s
~~·~er.qi.aJ._es c~n sus objeti~os y ve,ntas actua:li;..
SELECT CIUDAD, "OBJETIVO, FROM OFICINAS CIUDAD ~'-.------;.-
Listar las ofiéinas comerciales de la región Este . . SELECTO CIUDAD, OBJETivo, FROM·· OFICINAS WHERE REGlON = 'Este'
VENTAS
..
ccm sus,obje"tivos.Y·ventas. ... "
0
95
-'--
96
SOL. Manual de referencia
Capítulo 6: Consultas simples
OBJETIVO
VENTAS
575¿OOO,OO € 800.000,00 € 350.000,00 €
692.637,00 € 735.042,00 €
CIUDAD
----------- ------------- -------------
Navarra Caste116n Almería
367.911,00 €
Listar las oficinas comerciales de la región Este cuyas ventas excedan sus objetivos y ordenadas según el nombre de ciudad. SELECT CIUDAD,
OBJETIVO,
VENTAS
""'-- FROM
FROM OFICINAS
WHERE REGlON = 'Este' AND VENTAS > OBJETIVO ORDER BY CIUDAD CIUDAD
OBJETIVO
L L,
350.000,00 €
367.911,00 €
Navarra
575.000,00 €
692:637,00 €
LHAVING L,
SELECT AVG(OBJETIVO) , AVG(VENTAS¡ FRQM OFICINAS WHERE REGlON = 'Este'
575.000,00 €
AVG(VENTAS) 598.530,00
€
Para las' consultas simples, la solicitud en inglés y la instrucción SELECT de SQL son muy similares. Cuando la solicitud se torna m.ás complicada, se deben usar más características de la instrucción SELECT para especificar de forma precisa la consulta. La Figura 6.1 muestra la forma completa de la instrucción SELECT, que consiste en seis cláusulas. Las cláusulas SELECT y FROM son obligatorias. El resto de cláusulas es opcionaL Sólo se incluyen en una instrucción SELECT cuando se quiere usar las funciones que proveen. La siguiente lista resume la función de cada cláusula: • La cláusula SELECT lista los elementos de datos a recuperar por la instrucción SELECT. Los elementos pueden ser columnas de la base de datos o columnas calculadas por SQL al procesar la consulta. La cláusula SELECT se describe en la siguiente sección. • La cláusula FROM lista las tablas que contienen los datos a recuperar por la consulta. En este capítulo se describen las consultas que toman datos de una única tabla. Las consultas más complejas que combinan datos de dos o más tablas se estudian en el Capítulo 7. • La cláusula WHERE informa a SQL de que incluya sólo ciertas filas de datos en los r~sultados de la consulta. Se usa una condición de búsqueda para especificar las filas deseadas. Los usos básicos de la cláusula WHERE se descri-
MJ.i
1
DISTINC
*
,
especificación
t
-- ,---'-
I
búsqueda
columna-de-
GROUP BY~:ción
¿,Cuáles son los objetivos y ventas de las oficinas de la región Este?
AVG(OBJETIVO)
elemento·de-
If;cóón,.
WHERE condIÓón-de-
VENTAS
Almería
d
f--SELECT-t;
97
condiÓón-debúsqueda
especificaÓón-de-
aRDER BY~~ación
Figura 6.1.
I
,
I
Diagrama sintáctico de la instrucción
SELECT.
ben en la sección «Selección de filas (cláusula WHERE)>>, más adelante en este capítulo. Las que conllevan subconsultas se estudian en el Capítulo 9. • La cláusula 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 Capítulo 8. • La cláusula HAVING indica a SQL que incluya en el resultado sólo determinados grupos producidos por la cláusula GROUP BY. Al igual que la cláusula WHERE, usa una condición de búsqueda para especificar los grupos deseados. La cláusula HAVING se describe en el Capítulo 8. • La cláusula ORDER BY ordena los resultados tomando como base los datos de una o más columnas. Si se omite, los resultados no se ordenan. La cláusula aRDER BY se describe en la sección «Ordenación de los resultados de las consultas (cláusula ORDER BY)>>, más adelante en este capítulo.
98
I
SOL. Manual ·de referencia
Capítulo 6: Consultas simples
,99
La cláusulasELEcT La cláusula SELECT con la que comi~nza cada instrucción SELECT especifica los elementos de datos que recupera la consulta. Los elementos se especifican usual· mente por una lista de selección, una lista de elementos de selección separados por comas. Cada elemento de selección en la lista genera'una única columna de resultados de la consulta, de izquierda a derecha. Un elemento de selección puede ser: • Un nombre de Lolumna. que identifica una columna de la tabla o tablas que aparecen en la cláusula 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 c6ñsulta. • Una expresión SQL. que indica que SQL debe calcular el valor a poner en los resultados, según se especifica en la expresión
Sal interactivo
1
SELECr CIUDAD, REGIÓN FROM OFICINAS
I
---
Consulta
--Resultados de la consulta
I
CIUDAD Daimiel Navarra Castellón Almeria León
Programa .1
En este capítulo se describe cada tipo de eleme·nto de selección.
REGIÓN oeste Este Este Este Oeste
1+-
-' SGBD
Consulta
Base de dato
Programación con Sal
,., ..
La cláusula
FROM
Figura 6.2.
La cláusula FROM c0nsiste en la-palabra clave FRDM seguida por-una lista de especificaciones de tabla separadas-por comas. Cada especificación 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 instrucción SELECT), porque son la fuente de todos'los 'datos de los resultados: Todas las consultas de este capítUlo tienen una única tabla fuente, y cada cláusula FROM contienen un ú~ico 'nombre de tabla. '1,
l'
.,.
Resultados de las consultas "
"',,
El resultado de una consulta' SQL. es siempre uria tábla . .de datos, como las de la base de datos. Si se escribe-una instrucción SELECT usando SQL interactivo, el SGBD 'muestra los resultados de·forma.tabular en-la/pantalla de la computaoora. SI un programa envía 'un consulta al SGBD usando'..programación 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 cláusula son·usualmente 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
la estructura tabular de los resultados de las ·consultas SOL.
Listar los nombres, oficinas y fechas de contratación de todos los lrepresentantes. SELECT NOMBRE, OFICINA_REP, FROM REPRESENTANTES
I
FECHA_CONTRATO
NOMBRE
Bruno Arteaga Mar~a,y'iI!'énez
Susana Santos Samuel Clavel Bernardo Sánchez DanielJ Ru-idrobo- - .,.. ,,-' Tomás Saz León Freire. Pablo C:r;uz Neus Azcá'ra te
En cambio, la siguiente consulta produce una única fila porque sólo un representante tiene el número 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
Capítulo 6: Consultas simples
SOL. Manual de referencia
¿Cuáles son el nombre. la cuota y las ventas del empleado número 107? SELECT NOMBRE. CUOTA, VENTAS FROM REPRESENTANTES WHERE NUM_EMPL : 107 CUOTA
NOMBRE Neus Azcárate
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: ¿ Cuáles son las ventas promedio de nuestros represen/antes? SELECT AV~(VENTAS) FROM REPRESENTANTES AVG (VENTAS)
289.353,20 €
Estos resultados son una tabla, aunque una muy pequeña que s610 tiene una fila y una columna. Finalmente, es posible que una consulta no produzca ninguna fila como resultado, como en este ejemplo:
Listar el nombre y fecha de coiltrato de quienes tengan ventas superiores a 500.000 f.
NOMBRE
Bruno Arteaga Maria Jiménez Susana Santos samuel Clavel Bernardo Sánchez Daniel Ruidrobo Tomás Saz Le6n Freire Pablo Cruz Neus Azcárate
Las consultas más 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 la ubicación, región y ventas de cada oficina comercial.
NOMBRE
CIUDAD
REGlaN
Daimiel Navarra Caste1l6n Almeria Le6n
Oeste Este Este Este Oeste
Listar los representantes, sus cuotas y sus jefes. SELECT NOMBRE, CUOTA, JEFE FROM REPRESENTANTES
loa
Consultas simples
SELECT CIUDAD, REGION. VENTAS FROM OFICINAS
Incluso en esta situación los resultados son una tabla. En este caso es una tabla vacía, con dos columnas y ninguna fila. Nótese que el soporte de SQL par~ dalos ausentes se extiende también 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.
lOa NULL 106 104 101 106 104
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 relación sinérgica con las capacidades de las consultas relacionales de SQL. Las tablas se pueden consultar y las consultas producen tablas.
SELECT NOMBRE. FECHA_CONTRATO FROM REPRESENTANTES WHERE VENTAS> SOOOOO.OO € FECHA_CONTRATO
La instrucción SELECT, para consultas simples como ésta, incluye sólo las dos cláusulas requeridas. La cláusula SELECT da nombre a las columnas requeridas; la cláusula FROM da nombre a la tabla que las contiene. Conceptualmente, SQL procesa la consulta examinando la tabla referenciada en la cláusula 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 selección y produce una única fila de resultados. La consulta devuelve así una fila de datos por cada fila de la tabla.
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.
Resultados de la consulta
CIUDAD
REGIÓN
Daimiel
Navarra
oeste Este
Cast.ellón
Est.e
~64.958.00€
Almería
Este Oeste
17.911,OO€ llO.915.00€
LoOn
OBJETIVO
SELECT ID_FAB, ID_PRODUCTO, FROM PRODUCTOS ID_FAS REI 'CI
QS'
Figura 6.3.
DESCRIPClON,
(STOCK
~
PRECIO)
-1l3.958,OO€ 117.637,OO€
Procesamiento de una consulta simple (sin cláusula WHERE).
Columnas calculadas Además 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 expresión SQL en la lista de selección. Como se estudió en el Capítulo 5, las expresiones SQL pueden incluir la suma, la resta, la multiplicación y la división. También se pueden usar paréntesis para construir expresiones más complejas. Por supuesto, las columnas referenciadas en una expresión aritmética deben tener un tipo numérico. 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
1
Tabla PEDIDOS
Listar la ciudad, región 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
1--->
OBJETIVO)
FAB REI REI IMM
UNIÓN
PRODUCTO 2A44L 2M4R 775C
Resultados de la con sulta
}--+
'CI REI ACI REI REI REI IMM
4100Y 2A44L 4100Z 2A44R 2A44L 2A44R 775C
CANTIDAD > 30.000
(VENTAS-OBJETIVO) -113.958,00 E 117.637,00 €
103
Figura 6.4.
Procesamiento de consultas con una columna calculada.
104
SOL. Manual de referencia
Capítulo 6: Consultas simples
Mostrar los resultados si se eleva la cuota de cada representante en un 3 por ciento de las ventas de este año. SELECT NOMBRE,
CUOTA,
(CUOTA
+
Selección de todas las columnas CUOTA
Bruno Arteaga
María Jiménez Susana Santos Samuel Clavel Bernardo Sánchez Daniel Ruidrobo Tomás Saz
León Freire
Pablo Cruz Neus Azcárate
sultados se muestran en pantalla, pero es crucial en la programación con SQL cuando los resultados se recuperan con un programa y se usan para cálculos.
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 rápida de su estructura y de los datos que contiene. SQL permite usar un asterisco (*) en lugar de la lista de selección como abreviatura de «todas las columnas»:
309.170,19 NULL
360.855,95 283.603,25 305.581,26
Como se mencionó en el Capítulo 5, muchos productos SQL proporcionan operaciones aritméticas 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 selección, como en el siguiente ejemplo con DB2.
Mostrar todos los daros de la tabla
OFICINAS.
SELECT FROM OFICINAS OFICINA CIUDAD 22 11 12 13 21
REGlaN
JEF
Este Este Este Oeste
106 lO' 105 108
OBJETIVO
VENTAS
------- ---- ------------- -----------------------186.042,00 € Daimiel Oeste 108 300.000,00 €
Navarra Castellón A1meria León
575.000,00 800.000,00 350.000,00 725.000,00
€ € € €
692.637,00 735.042,00 367.911,00 835.915,00
€
€ € €
Listar el nombre. mes y año de contrato de cada representante. SELECT NOMBRE, MONTH(FECHA_CONTRATOI, FROM REPRESENTANTES
YEAR(FECHA_CONTRATOI
Las constantes SQL también pueden ser útiles por sí mismas como elementos de una lista de selección. Esto puede ser útil para producir resultados que sean más fáciles de leer e interpretar, como en el siguiente ejemplo. Listar las ventas de cada ciudad.
SELECT· (SALES - TARGET) FROM OFFICES
SELECT CIUDAD, 'tiene unas ventas de' , VENTAS FROM OFICINAS CIUDAD
TIENE UNAS VENTAS DE
----------
--------------------------------tiene unas ventas de 186.042,00 €
Daimiel Navarra Castel1ón A1mería León
tiene tiene tiene tiene
unas unas unas unas
ventas ventas ventas ventas
de de de de
Los resultados de la consulta contienen las seis columnas de la tabla OFICIen el mismo orden, de ¡"zquierda a derecha, que la tabla. El estándar de SQL ANSUISO especifica que una instrucción SELECT puede tener una selección de todas las columnas o una lista de selección, pero no ambas, como se muestra en la Figura 6.1. Sin embargo. muchas implementaciones de SQL tratan el asterisco sólo como un elemento más de la lista de selección (*). Así, la consulta: NAS,
VENTAS
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 distinción es sutil cuando los re-
es legal en la mayoría de los dialectos comerciales de SQL (por ejemplo, en DB2, Oraele y SQL Server), pero no se permite en el estándar ANSI/ISO. La selección de todas las columnas es más apropiada cuando se usa SQL interactivo. Se debería evitar en la programación con SQL porque los cambios de la estructura de la base de datos pueden hacer que el programa falle. Por ejemplo, supóngase que la tabla OFICINAS se haya eliminado de la base de datos y se haya recreado con sus columnas reorganizadas y con una nueva séptima columna. SQL se hace cargo automáticamente cargo de los detalles concernientes a la base de datos de tales cambios, pero no puede modificar el programa de aplicación. 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 añada una nueva.
106
Capítulo 6: Consultas simples
SOL. Manual de referencia
Estas dificultades se pueden evilar si se escribe el programa para solicitar las columnas que se necesitan según su nombre. Por ejemplo, la siguiente consulta produce los mismos resultados que SELECT* FROM OFICINAS. Es también 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 selección, 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. supóngase que se hace esta solicitud:
Listar los números de empleado de todos los jefes de oficinas comerciales. SELECT JEF FROM OFICINAS
JBF
107
Conceptualmente, SQL resuelve esta consulta generando en primer lugar el conjunto completo de resultados (cinco filas) y eliminando después 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 Capítulo 8). Si se omite la palabra clave DISTINCT, SQL no elimina las filas duplicadas. También se puede especificar la palabra clave ALL para indicar explícitamente que se conserven las filas duplicadas, pero es innecesario porque es el comportamiento predeterminado.
Selección de filas (cláusula 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 más. Usualmente no se desea seleccionar sólo algunas de las filas de una tabla e incluir sólo éstas en los resultados de la consulta. La cláusula WHERE se usa para especificar las filas que se desea recuperar. Aquí hay algunos ejemplos de consultas simples que usan la cláusula WHERE:
Mostrar las oficinas donde las ventas superen a los objetivos.
108
la. 104 105 108
SELECT CIUDAD, VENTAS, OBJETIVO FROM OFICINAS WHERE VENTAS > OBJETIVO CIUDAD
Los resultados deJa consulta tienen cinco filas (una por cada oficina), pero dos de ellas son duplicados exactos, ¿Por qué? Debido a que León Freire es jefe tanto de la oficina de León como de la de Daimiel, y su número 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 debería haber esperado s610 cuatro números de empleado en los resultados. Se puede eliminar las filas duplicadas de los resultados insertando la palabra clave DISTINCT en la instrucción SELECT justo antes de la lista de selección. Aquí se ofrece una versión de la consulta anterior que produce los resultados deseados:
Listar los números de empleado de todos los jefes de oficinas comerciales. SELECT DISTINCT JEF FROM OFICINAS JEF
-------Navarra Almería Le6n
VENTAS
367.911,00 € 835.915,00 €
la.
108
350.000,00 € 725.000,00 €
Mostrar el nombre, ventas y cuota del número de empleado 105. SELECT NOMBRE, VENTAS. FROM REPRESENTANTES WHERE NUM_EMPL = 105 NOMBRE Bruno Arteaga
CUOTA
VENTAS 367.911.00 €
CUOTA 350.000,00
€
Mostrar los empleados subordinados de Bernardo Sánchez (empleado número 104).
la' 105
OBJETIVO
------------------------692.637,00 € 575.000,00 €
SELECT NOMBRE, VENTAS FROM REPRESENTANTES WHERE JEFE = 104
¡ti
108
SOL. Manual de referencia
NOMBRE
367.911,00 € 305.673.00 € 286.775,00 €
Tabla REPRESENTANTES
La cláusula WHERE consiste en la palabra clave WHERE seguida de una condición de búsqueda que especifica las filas·a recuperar. En la consulta anterior, por ejemplo, la condición de búsqueda es JEFE = 104. La Figura 6.5 muestra cómo funciona la cláusula WHERE. Conceptualmente, SQL examina cada fila deJa tabla REPRESENTANTES, una a una, y aplica la condición de búsqueda a la fila. Cuando aparece un nombre de columna en ]a condición de búsqueda (como la columna JEFE en este ejemplo), SQL usa el valor de la columna en la fila en curso. Para cada fila, la condición de búsqueda puede producir 'uno de los siguientes tres resultados: • Si la condición de búsqueda 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 condición de búsqueda 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 condición de búsqueda 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 condición de búsqueda de cláusula WHERE. Básicamente, la condición de búsqueda actúa como
( Tabla REPRESENTANTES
Bruno Arteaga María Jiménez Susana Santos SaJIluel Clavel
.
\
Resultados de la consulta
TRUE
NOMBRE
)
JEFE = 104
l'
"-
5lli; 108
NOMBRE
VENTAS
Bruno Arteaga Daniel Ruidrobo Pablo Cruz
(NULL
Bernardo sánchez
106
Daniel Ruidrobo
104
\~
JEFE - 104 JEFE
Figura 6.5,
109
VENTAS
Bruno Arteaga Daniel Ruidrobo Pablo Cruz
!~;
Capítulo 6: Consuftassimp'les
= 104
Selección de filas con la cláusula WHERE.
FALSE
Desconocido
367 911,00 € 305673,00€ 266775,00€
NOMBRE Bruno Arteaga María Jiménez Susana Santos Samuel Clavel Bernardo Sánchez Daniel Ruiclrobo
Resultados de la consulta
JEFE
~
104 106 108
- f-+
NULL
---<[-+
106 104
I~
NOMBRE Bruno Arteaga Daniel Ruidrobo Pablo Cruz
VENTAS 367.911,OO€ 305.673,OO€ 286.775,OO€
~ Filtro
JEFE '" 104
Figura 6.6.
La cláusula WHERE como filtro,
un filtro para las filas de la tabla. Las filas que satisfacen la condición de búsqueda atraviesan el filtro y pasan a formar parte de los resultados. Las filas que no satisfacen la condición de búsqueda quedan atrapadas por el filtro y se excluyen de, los resultados,
Condiciones de búsqueda SQL ofrece un rico conjunto de condiciones de búsqueda que penniten especificar muchos tipos diferentes de consultas de forma eficiente y natural. Aquí se resumen cinco condición básicas de consulta (denominadas predicados en el estándar ANSUISO) y se describen en las secciones subsiguientes: • Test de comparación. Compara el valor de una expresión con el valor de otra expresión. Este test se puede usar para seleccionar las oficinas de la región este o los representantes cuyas ventas están por encima de sus cuotas. • Test de ra;ngo. Comprueba si el valor de una expresión se encuentra en un rango especificado de valores. Este test se puede usar para hallar los representantes cuyas ventas están comprendidas entre 100.000 y 500.000. • Test de pertenencia a conjuntos. Comprueba si el valor de una expresión coincide con uno de un conjunto de valores. Este test se puede usar para seleccionar las oficinas ubicadas en Navarra, Castellón o León. • Test de encaje de patrones. Comprueba si 'el valor de una columna que contiene datos de cadena coincide con un patrón 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 aún un jefe asignado.
110
Capítulo 6: Consultas simples
SOL. Manual de referencia
El test de comparación
(=,
<>,
<,
<=,
>,
Listar las oficinas que no estén dirigidas por el número de empleado J08.
>=)
La condición de búsqueda más usual en una consulta SQL es un test de compara-
ción. En un test de comparación, 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 aritméticas más complejas. SQL ofrece seis formas diferentes de comparar las dos expresiones, como se muestra en la Figura 6.7. A continuación hay algunos ejemplos de test de comparación.
SELECT NOMBRE FROM REPRESENTANTES WHERE FECHA_CONTRATO < 'Ol-ENE-SS' NOMBRE
Susana Santos Bernardo Sánchez Daniel Ruidrobo Pablo Cruz
Listar las oficinas cuyas ventas están por debajo del 80 por ciento de sus objetivos. SELECT CIUDAD, VENTAS. OBJETIVO PROM OFICINAS WHERE VENTAS < (,S OBJETIVO)
Daimiel
CIUDAD
JEF
Navarra Caste1l6n Almeria
106 104 105
• Si la comparación es cierta, el test da un resultado TRUE. • Si la comparación es falsa, el test da un resultado FALSE. • Si alguna de las dos expresiones devuelve un valor NULL. la comparación devuelve un resultado NULL. Recuperación de una única fila
El test de comparación más común es el que comprueba si el valor de una columna es igual a una ~onstante, Cuando la columna es una clave primaria, el test aísla una única fila de la tabla produciendo una única fila de resultados de la consulta, como en este ejemplo:
t
CIUDAD
SELECT CIUDAD. JEF PROM OFICINAS WHERE JEF <> 108
Como se muestra en la Figura 6.7, el test de comparación se escribe «A < > B», de acuerdo con la especificación 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 comparación pueden ocurrir tres resultados:
Hallar los representantes contratados antes de 1988.
;,1
111
VENTAS
OBJETIVO
186.042,00 €
300.000,00 €
Obtener e"l nombre y e/limite. de crédito del cliente número 2107. - - - expresión-l - - , - - -
expresión-2
<> <
<= >
Figura 6.7.
Diagrama sintáctico del test de comparación.
----+-
SELECT EMPRESA, LIMITE_CREDITO FROM CLIENTES WHERE NUM_CLI 2107 EMPRESA
Ace Internacional
LIMITE_CREDITO 35.000,00 €
Este tipo de consulta el es fundamento de los programas de recuperación de datos de bases de datos basados en formularios. El usuario introduce un número de cliente en el formulario y el programa usa el nombre para construir y ejecutar una consulta, Después se muestran los datos en el formulario. Nótese que las instrucciones SQL para recuperar un cliente en concreto por su número, como en este ejemplo, y la recuperación de todos los clientes con ciertas características (como clientes con límite de crédito superior a 25.000 €) tienen
I 1 11' :~I
112
Capítulo 6: Consultas simples
SOL. Manual de referencia
exactamente la misma forma. Los dos tipos de consultas (recuperación según la clave primaria y recuperación basada en búsqueda de datos) serían operaciones muy diferentes en una base de datos no relacional. Esta uniformidad hace que SQL sea mucho más simple de aprender y usar que otros lenguajes de consulta anteriores.
Consideraciones sobre los valores
_exP'es;ón-de-res'l
NOT jBE1'>1EEN
eXp'es;ón-;nfedo,
ANO
113
exp'es;ón-supedo, .....
NULL
figura 6.8.
El comportamiento de los valores NULL en los tests de comparación pueden revelar que algunas nociones «obviamente ciertas» acerca de las consultas SQL no sean realmente ciertas. Por ejemplo, podría parecer que los resultados de estas dos consultas incluirían todas las filas de la tabla REPRESENTANTES:
Diagrama sintáctico del test de rango (BETWEEN).
El test de rango
(BETWEEN)
SQL proporciona una forma diferenre de condición de búsqueda 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 límites 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 rípico.
Listar los represellta1lIes que exceden su cuota. SELECT NOMBRE FROM REPRESENTANTES WHERE VENTAS > CUOTA NOMBRE Bruno Arteaga María Jiménez Susana Santos Samuel Clavel Daniel Ruidrobo León Freire Pablo Cruz
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
LisIar los representantes que no llegan a su cuota.
El test BETWEEN incluye los límites 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:
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 Tomás Saz tiene un valor NULL en la columna CUOTA porque aún no se le ha asignado una cuota. Esra fila no es lisrada por ninguna de las consultas; «desaparece» en el test de comparación. Como muestta esre ejemplo, es necesario reflexionar sobre el manejo de los valores NULL cuando se especifica una condición de búsqueda. En la lógica trivalorada de SQL, una condición de búsqueda puede devolver un resultado TRUE, FALSE 'o NULL. Sólo las filas para las que la condición de búsqueda ofrezca un resultado TRUE se inciuirán en los resultados de la consulta.
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
IMPORTE
113036
22.500,00 €
i
t .~ :11
114
SOL Manual de referencia 112987 113042
Capítulo 6: Consultas simples
27.500,00 € 22.500.00 €
Antes de confiar en este comportamiento es recomendable probarlo en el SGBD particular que se use. Conviene hacer notar que el test BETWEEN no añade realmente nada al poder expresivo de SQL, ya que se puede expresar como dos tests de comparación. El test de rango:
SELECT NUM_PEDlDO, IMPORTE FROM PEDIDOS WHERE IMPORTE BETWEEN 30000.00 AND 39999.99 IMPORTE 112961 113069
A BETWEEN B ANO C
31.500,00 € 31.350,00 €
es completamente equivalente a:
SELECT NUM_PEDIDO. IMPORTE FROM PEDIDOS WHERE IMPORTE BETWEEN 40000.00 ANO 49999.99
"
.,
115
NUN_PEDIDO
IMPORTE
113045
45.000,00 €
lA >= Bl AND (A < = Cl
Sin embargo, el test BETWEEN es una forma más simple de expresar una condición de búsqueda cuando se piensa en términos de rangos de valores.
La versión negada del test de rango (NOT BETWEEN) comprueba los valores que están 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 Jiménez
La expresión de test especificada en el test BETWEEN puede ser cualquier expresión SQL válida, pero en la práctica es generalmente sólo el nombre de una columna, como en los ejemplos anteriores. El estándar ANSIfISO define reglas relativamente complejas para el manejo de los valores NULL en el test BETWEEN: • Si la expresión 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 expresión que define el límite inferior del rango produce un valor NULL, entonces el test BETWEEN devuelve FALSE si el valor es mayor que el límite superior, y NULL en caso contrario. • Si la expresión que define el límite superior del rango produce un valor NULL, entonces el test BETWEEN devuelve FALSE si el valor es menor que el límite inferior, y NULL en caso contrario.
El test de pertenencia a conjuntos
(IN)
Otra condición común de búsqueda 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, Almería o Daimiel. SELECT NOMBRE, CUOTA, VENTAS FROM REPRESENTANTES WHERE REP_OFICINA IN (11, 13, NOMBRE
CUOTA
22) VENTAS
-------------- ------------- -------------
Bruno Arteaga María Jiménez Samuel Clavel Neus Azcárate
350.000,00 300.000,00 275.000,00 300.000,00
-exp'esión-de-'es' - [
Figura 6.9.
NOT
€ € € €
367.911,00 392.725,00 299.912,00 186.042,00
€ € € €
J
Diagrama sintáctico del test de pertenencia a conjuntos IIN).
116
SOL. Manual de referencia
Capítulo 6: Consultas simples
117
'" Hallar todos los pedidos de un jueves de enero de 1990. SELECT NUM_PEDIDO,
FECHA_PEDIDO,
FROM PEDIDOS WHERE FECHA_PEDIDO IN
razones de transportabilidad. es generalmente buena idea evitar listas con un único elemento, como la siguiente:
IMPORTE CIUDAD IN
(' 04-ENE-90·.
'11-ENE-90',
(' Navarra' l
'18-ENE-90·.
y reemplazarla con un test simple de comparación:
'25-ENE-90') NUM_PEDIDO FECHA_PEDIDO
I1iPORTE
CIUDAD =
'Navarra'
3.745,00 €
113012 ll-ENE-90 113003 25-ENE-90
5.625.00 €
Hallar rodos los pedidos de cuatro representantes en concreto. SELECT NUM_PEDIDO, REP, IMPORTE FROM PEDIDOS WHERE REP IN (107, 109, 101, 103)
El test de encaje de patrones
(LIKE)
Se puede usar un test simple de comparación para recuperar las filas que coincidan con un texto en concretQ. Por ejemplo, esta consulta devuelve una fila de la tabla CLIENTES según el nombre: Mostrar eilimite de crédito de Sierras S. A.
IMPORTE
NUM_PEDIDO
REP
112968
101 109 107 107
3.978,00 1.480,00 652,00 2.430,00
107 103
31.350,00 2.100,00
113058 112997 113062 113069
112975 113055 113003 113057 113042
101
150,00
109
5.625,00
103
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 expresión de test en un test IN puede ser cualquier expresión SQL, pero es generalmente un nombre de columna, como en los ejemplos anteriores. Si la expresión 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 expresión de test. Al igual que el test BETWEEN, el test IN no añade nada a la potencia expresiva de SQL, ya que la condición de búsqueda: X
IN
{A,
s,
SELECT EMPRESA, LIMITE_~REDITO FRQM CLIENTES WHERE EMPRESA = 'Sierras S.A.'
Sin embargo, sería 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 patrón especificado. El patrón es una cadena que puede incluir uno o más caracteres comodín. Estos caracteres se interpretan de fonna especial. Caracteres comodín
El carácter comodín signo del porcentaje (%) coincide con cualquier secuencia de varios o ningún caracteres. Aquí hay una versión modificada de la consulta anterior que usa el signo del porcentaje: SELECT" EMPRESA, LIMITE_CREDITO FROM CLIENTES WHERE EMPRESA LIKE 'S% S.A.'
el
es completamente equivalente a: (X
= AlaR
(X
= B)
OR (X
= Cl
Sin embargo, el test IN ofrece una forma mucho más eficiente de expresar esta condición de búsqueda, especialmente si el conjunto contiene más de unos pocos valores. El estándar de SQL ANSIIISO no especifica un límite máximo sobre el número de elementos que pueden aparecer en la lista de valores, y la mayoría de implementaciones comerciales tampoco establecen un límite superior explícito. Por
-nombre-de-columna~LlKEParrónL
L
NOT
-.J
J.. .
. ESCAPE carader-de-escape
Figura 6.10. Diagrama sintáctico del test de encaje de patrones
(LIKE).
118
Capítulo 6: Consultas simples
SOL. Manual de referencia
La palabra clave LIKE indica a SQL que compare la columna NAME con el patrón «8% S. A.». Cualquiera de los nombres siguientes podría coincidir con el patrón: sierras S.A. Segadoras S.A. Sillas S.A. Sandalias S.A.
pero éstos no: Segadoras SA Sierras Ine.
El carácter comodín de subrayado L) coincide con cualquier carácter único. Si se está seguro de que el nombre de la compañía 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 coincidirían con el patrón: Segadoras S.A. Pegadoras S.A. Legadoras S.A.
pero estos nombres no: Secadoras S.A.
Pagadoras S.A.
119
de porcentaje en una columna de datos textuales, por ejemplo, se puede incluir simplemente el signo de porcenlaje en el patrón porque SQL lo tratará como un comodín. Con algunos productos SQL populares no se pueden comparar los dos caracteres comodín. Esto no plantea generalmente problemas serios porque los caracteres comodín no aparecen frecuentemente en los nombres, números de producto y otros datos textuales del tipo que se almacena habitualmente en una base de datos. . El estándar de SQL ANSI/ISO especifica una forma de comparar estos caracteres mediante el uso de un carácter de escape especial. Cuando el carácter de escape aparece en el patrón, el carácter que lo sigue inmediatamente se trata como un carácter literal, en lugar de cómo un carácter especial (se dice que este último carácter está escapado). El carácter escapado puede ser cualquiera de los caracteres comodín o el propio carácter de escape, que ahora tiene un significado especial en el patrón. El carácter de escape se especifica como una cadena constante de un carácter en la cláusula ESCAPE de la condición de búsqueda, como se muestra en la Figura 6.10. Aquí se muestra un ejemplo que usa el signo del dólar ($) como carácter de escape:
Hallar los productos cuyos bolos «A %BC».
identificado~s de
producto comienzan con los sím-
Los caracteres comodín pueden aparecen en cualquier lugar de la cadena patrón y en cualquier número. Esta consulta permite tanto la cadena «Secadoras» como «Pegadoras», y también el final del nombre de la empresa «S. A.» o «S. L.»:
SELECT NUM_PEDIDO, PRODUCTO FROM PEDIDOS WHERE PRODUCTO LIKE 'A$%BC%' ESCAPE '$'
SELECT EMPRESA, LIMITE_CREDITO FROM CLIENTES WHERE EMPRESA LIKE '_egadoras %'
El primer signo de porcentaje del patrón, que sigue al carácter de escape, se trata como un signo de porcentaje literalmente, el segundo funciona como comodín. El uso de los caracteres de escape es muy común en las aplicaciones de encaje de patrones, por In que el estándar ANSUlSO los especificó. Sin embargo, nn formaba parte de las primeras implementaciones de SQL, y se ha adoptado lentamente. Para asegurar transportabilidad, se debería evitar la cláusula ESCAPE.
Se pueden buscar cadenas que no coincidan con un patrón 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 interrogación 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 aplicación infonnática ofrece la capacidad de comparar partes seleccionadas de una palabra o texto. NOT LIKE
Caracteres de escape
*
Uno de los problemas del encaje de patrones de cadenas es cómo hacer la comparación de los propios caracteres comodín. Para comprobar si hay un carácter
El test de valores nulos lIS
NULL)
Los valores NULL crean una lógica trivalorada para las condiciones de búsqueda de SQL. Para una fila dada, el resultado de una condición de búsqueda puede ser TRUE o FALSE, o puede ser NULL porque una de las columnas usadas en la evaluación de la condición de búsqueda contenga un valor NULL. A veces es útil comprobar explícitamente los valores NULL en una condición de búsqueda y manejarlos directamente. SQL proporciona un test especial sobre valores NULL (IS NULL), mostrado en la Figura 6.11, para manejar esta tarea.
l'
I
120
SOL Manual de referencia
i
i l'
'i~
- - nombre-de-columna 15
¡-------,------
I!.' ;;1
NULL
LNOT~
'1,
.
Capítulo 6: Consultas simples
121
La palabra clave NULL no se puede usar aquí porque no es realmente un valor, sino una señal de que el valor es desconocido. Incluso si el test de comparación: OFICINA_REP = NULL
1 11 ;11
:¡:
l'
Figura 6.11. Diagrama sintáctico 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 aún una oficina:
fuese legal, las reglas para el manejo de los valores NULL en las comparaciones haría que su comportamiento fuese diferente del que cabría esperar. Cuando SQL encuentre una fila donde OFICINA_REP fuese NULL, la condición de búsqueda comprobaría: NULL = NULL
Buscar el representante que no tenga aún una oficina asignada. SELECT NOMBRE FRüM REPRESENTANTES WHERE OFICINA_REP 15 NULL NOMBRE Tomás Saz
La forma negativa del test de valores NULL (1S NOT NULL) encuentra las filas que no contienen un valor NULL: Listar los representantes que
ten~an
oficinas asignadas.
¿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 condición de búsqueda debería dar un resultado NULL. Dado que la condición de búsqueda no produce un resultado cierto, la fila se excluye de los resultados de la consulta -precisamente lo opuesto de lo que se esperaría-o Como resultado de la forma en que SQL maneja los valores NULL en las comparaciones, se debe usar explícitamente el valor NULL para comprobar los valores NULL.
Condiciones compuestas de búsqueda
(AND, OR
Y NOT)
SELECT NOMBRE
FROM REPRESENTANTES WHERE OFICINA_REP r5 NOT NULL NOMBRE Bruno Arteaga Maria Jiménez Susana Santos Samuel Clavel Bernardo Sánchez Daniel Ruidrobo León Freire Pablo Cruz Neus Azcárate
I
A diferencia de las condiciones de búsqueda descritas anteriormente, el test de valores NULL no puede devolver un resultado NULL. Siempre es TRUE o FALSE. Puede resultar extraño que no se pueda comprobar un valor NULL usando una simple condición de búsqúeda de comparación, como:
I
SELECT NOMBRE FROM REPRESENTANTES WHERE OFICINA_REP = NULL
I '¡
I,
ti
Las condiciones simples de búsqueda 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 lógica se pueden combinar estas condiciones simples de búsqueda de SQL para formar otras más complejas, como la que se muestra en la Figura 6.12. Nótese que las condiciones de búsqueda combinadas con AND, OR Y NOT pueden ser a su vez condiciones compuestas de búsqueda.
---WHERE
tL:J
cond;c;ón-de-búsqueda
AND
L
OR
Figura 6.12. Diagrama sintáctico de la cláusula WHERE.
122
SOL. Manual de referencia
Capítulo 6: Consultas simples
La palabra reservada OR se usa para combinar dos condiciones de búsqueda cuando cualquiera de ellas (o ambas) debe ser cierta:
Hallar los representantes que estén por debajo de su cuota o con ventas por debajo de 300.000 €. SELECT FROM WHERE DR
Samuel Clavel Bernardo Sánchez Tomás Saz Pablo Cruz Neus A%cárate
CUOTA
VENTAS
275.000,00 € 200.000,00 €
299.912,00 € 142.594,00 €
NULL
75.985,00 € 286.775.00 € 186.042,00 €
275.000,00 €
300.000.00 €
También se puede usar la palabra clave AND para combinar dos condiciones de búsqueda que deben ser simultáneamente ciertas:
Hallar los representantes que estén 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 Sánchez Neus Azcárate
CUOTA
VENTAS
200.000,00 € 300.000,00 €
142.594,00 € 186.042,00 €
Finalmente. se puede usar la palabra clave condición de búsqueda sea falsa:
NOT
para seleccionar filas donde la
Tabla 6.1.
TRUE
FALSE
TRUE
TRUE
FALSE
NULL
FALSE
FALSE
FAL5E
FALSE
N11LL
NULL
FALSE
NULL
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)
La razón por la que podría 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 búsqueda, los valores NULL afectan al resultado de las condiciones compuestas de búsqueda, y los resultados son sutiles. En particular, el resultado de (NULL OR TRUE) es TRUE, [JO NULL, como se podría 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 más de dos condiciones de búsqueda con ANO, OR Y NOT, el estándar ANSI/ISO especifica que NOT tiene la precedencia más alta, seguido de ANO, y después OR. Para asegurar la transportabilidad, siempre es buena idea usar paréntesis y eliminar cualquier posible ambigüedad. El estándar SQL2 añade otra condición lógica de búsqueda, el test IS, a la lógica proporcionada por ANO, OR Y NOT. La Figura 6.13 muestra la sintaxis del test IS, que comprueba si el valor lógico de una expresión o test de comparación es
Neus Azcárate
o
UNKNOWN (NULL).
Por ejemplo, el test IS: ((VENTAS - CUOTA)
Tabla 6.2.
CUOTA
VENTAS
300.000,00 €
186.042,00 €
Al usar las palabras clave AND, OR Y NOT y paréntesis para agrupar el criterio de búsqueda, se·pueden construir criterios de búsqueda muy complejos, ~mo el siguiente:
NULL
Hallar todos los representantes que o bien (a) trabajan en Daimiel, Navarra o CasteIlón; o bien (b) no tienen jefe y están contratados desde junio de 1988; o (e) superan su cuota pero tienen ventas de 600.000 € o menos.
TRUE, FALSE
NOMBRE
La tabla de verdad de AND
AND
Hallar ,odos los representantes que estén por debajo de su cuota pero que sus ventas no estén por debajo de J50.000 €. SELECT NOMBRE, CUOTA, VENTAS FROM REPRESENTANTES WHERE VENTAS < CUOTA AND NQT VENTAS < 150000.00
123
> 10000.00) 15 UNKNOWN
La tabla de verdad de OR
OR
TRUE
FALSE
'rRUE
TRUE
TRUE
TRUE
P'ALSE
TRUE
FALSE
NULL
N11LL
TRUE
NULL
NULL
N11LL
1I
124 1:
i
Capítulo 6: Consultas simples
SOL. Manual de referencia
Tabla 6.3.
Tabla de verdad de
I
NO'!'
I
NQT
'rRUE
FAL5E
NULL
FALSE
TRUE
NULL
- - - aRDER BY
I'n~mbre-de-COlumnaj
I
f----...
Lnumero-de-columna
l-
se puede usar para hallar filas donde la comparación no se pueda realizar debido a que VENTAS o CUOTA tenga un valor NULL. De forma similar, el test 18: I
((VENTAS
~
CUOTA)
>
10000.00)
((VENTAS - CUOTA)
>
! Ordenación de los resultados de las consultas (cláusula 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
I
Figura 6.14. Diagrama sintáctico de la cláusula
BY.
Mostrar las ventas de cada oficina, ordenadas alfabéticamente por región y, dentro de cada región, por ciudad. SELECT CIUDAD, REGlON, VENTAS FROM OFICINAS ORDER BY REGlON, CIUDAD CIUDAD
Listar las oficinas, ordenadas en orden decreciente de ventas, de forma que las oficinas con mayores ventas aparezcan primero.
T
-
FALSE UNKNOWN
SELECT CIUDAD, REGION, FROM OFICINAS ORDER BY VENTAS DESC CIUDAD
REGlON
León
Oeste
VENTAS
VENTAS
¡'li
l
QRDER
ordene los resultados incluyendo la cláusula ORDER BY en la instrucción SELECT. La cláusula 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:
expresión-lógica
l,:
I
I
La primera especificación de orden (REGlON) es la clave de ordenación principal; las siguientes (CIUDAD, en este caso) son progresivamente claves de ordenación menores, usadas como «decisivas» cuando dos filas de resultados tienen los mismos valores de las claves principales anteriores. Al usar la cláusula ORDER BY, se puede solicitar la ordenación en secuencia ascendente o descendente, y se puede ordenar sobre cualquier elemento de la lista de selección de la consulta. De manera predeterminada, SQL ordena los datos en secuencia ascendente. Para pedir una ordenación descendente, se incluye la palabra clave DEse en la especificación de orden, como en el siguiente ejemplo:
ti'
,
DESC~
10000.00)
Para asegurar una transportabilidad máxima, conviene evitar estos tests y escribir las expresiones usando sólo AND, OR Y NOT. No siempre es posible evitar la forma 18 UNKNOWN del test.
11
Ase --1
I5 FALSE
seleccionará las filas donde VENTAS no están significativamente sobre CUOTA. Como muestra este ejemplo, el test 18 no añade realmente potencia expresiva a SQL, ya que el test se podría haber escrito de manera simple: NOT
125
Figura 6.13. El diagrama sintáctico de IS.
- - - - - - - -
835.915,00 €
126
Capítulo 6: Consultas simples
SOL. Manual de referencia
Castellón Navarra Almería Daimiel
Este Este Este Oeste
735.042,00 € 692.637,00 € 367.911,00 €
186.042,00 €
Como se indicó en la Figura 6.14, se puede usar también la palabra clave Ase para especificar un orden ascendenre. pero dado que es la secuencia predeterminada de ordenación, 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 especificación de nombre. En este caso se puede especificar un número de columna en lugar de un nombre de columna, como en este ejemplo:
Listar las oficinas, ordenadas descendentemente según 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
Estos resultados se ordenan según la tercera columna, que es la diferencia entre VENTAS y OBJETIVO de cada oficina. Al combinar números 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 alfabéticamente por región, y dentro de cada región en orden descendente por el rendimiento de sus ventas. SELECT CIUDAD, REGlaN, (VENTAS - OBJETIVO) FRQM OFICINAS aRDER BY REGlaN Ase, 3 DEse CIUDAD
El estánqar SQL2 permite controlar el tipo de orden usado por el SGBD por cada clave de ordenación. Esto puede ser importante cuando se trabaje con con-
I .l
127
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 especificación de SQL2 es muy compleja y, en la práctica, muchas implementa~ ciones de SQL o bien ignoran los aspectos de los tipos de ordenación o usan su propio esquema propietario para el control por el usuario de la secuencia de arde· nación.
Reglas para el procesamiento de consultas sobre una sola tabla Las consultas de una única tabla son generalmente simples, y es fácil de com· prender generalmente el significado de una consulta simplemente leyendo la instrucción SELECT. Sin embargo, cuando las consultas se complican es importante tener una «definición» más precisa de los resultados que producirá una instruc· ción SELECT dada. Los siguientes pasos describen el procedimiento para generar los resultados de una consulta SQL que incluya las cláusulas descritas en este capílUlo. Como muestran estos pasos, los resultados producidos por una instrucción SELECT se especifican aplicando cada una de esta cláusulas, una a una. La cláusu· la FROM se aplica en primer lugar (seleccionando la tabla que contiene los datos a recuperar). A continuación se aplica la cláusula WHERE (seleccionando las filas específicas de la tabla). La cláusula SELECT se aplica a continuación (generando las columnas específicas de los resultados y eliminando los duplicados si se solicita). Finalmente, la cláusula ORDER BY se aplica para ordenar los resultados. Para generar los resultados de una instrucción 5ELECT hay que seguir estos pasos: l. 2.
3.
4. 5.
Comenzar con la tabla referenciada en la cláusula FROM. Si hay un cláusula WHERE, aplicar su condición de búsqueda a cada fila de la tabla, reteniendo las filas para las que la condición de búsqueda 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 selección 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 cláusula ORDER BY, ordenar los resultados como se haya especificado.
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 próximos tres capítulos para incluir las cláusulas restantes de la instrucción SELECT.
128
'''i'
SOL. Manual de referencia
Capítulo 6: Consultas simples
Combinación de los resultados de las consultas (UNION)*
I
tll 11
"
A veces es conveniente combinar los resultados de dos o más consultas en una única tabla de resultados. SQL dispone de esta capacidad mediante la característica UNION de la instrucción SELECT. La Figura 6.15 ilustra cómo usar la operación UNION para satisfacer la siguiente solicitud:
Listar todos los productos en los que su precio supere 2.000 € o cuando se hayan pedido más 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
;1 ii.
SELECT ID_FAS, ID_PRODUCTO FROM PRODUCTOS WHERE PRECIO> 2000.00
4100Y 2A44L 4100Z 2A44R
r-----
ID JEF
ID PRODUCTOS
ACl REl ACl REl
4100Y 2A44L 4100Z 2A44R
r+
I
l'
eUNlÓNJ-1
¡..--..
JEF
PRODUCTO
REl REl lMM
2A44L 2A44R
755c
~¡ Figura 6.15. Uso de UNION para combinar los resultados.
iJ
•
!I
,
Resultados de la consulta
--
11'
1:
Listar todos los productos de los que se hayan pedido más de 30.000 € en un único pedido. SELECT DISTINCT FAB, PRODUCTO FROM PEDIDOS WHERE IMPORTE> 30000.00 FAB
PRODUCTO
IMM REI REI
775C 2A44L 2A44R
Listar todos los productos en los que su precio supere 2.000 € o cuando se hayan pedido más de 30.000 € del producto en un único pedido.
Tabla PRODUCTOS
""
De forma similar, la segunda parte de la solicitud se puede satisfacer con la consulta inferior en la figura:
Como se muestra en la Figura 6.15, la operación 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 instrucción SELECT que especifica la operación UNION es:
Hay restricciones severas sobre las tablas que se pueden combinar en una operación UNION: • Las dos tablas deben contener el mismo número 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 cláusula ORDER BY. Sin embargo, los resultados de la consulta combinada, sí, corno se describe en la siguiente sección. Nótese que los nombres de las columnas de las dos consultas combinadas con no tienen que ser idénticas. En el ejemplo anterior la primera tabla de resul-
UNION
130
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 operación UNION se dejan sin nombre. El estándar de SQL ANSI/ISO especifica una restricción más sobre la instrucción SELECT que participa en una operación UNION. Sólo se pemiten nombres de columna o una especificación de todas las columnas (SELECT *) en la lista de selección, y prohíbe expresiones en ella. La mayoría de implementaciones comerciales de SQL relajan esta restricción y permiten expresiones simples en la lista de selección. Sin embargo, muchas implementaciones SQL no permiten que las instrucciones SELECT incluyan cláusulas GROUP BY o HAVING, y algunas no permiten funciones en la lista de selección (prohiben las consultas de resumen descritas en el Capítulo 8). De hecho, algunas implementaciones SQL ni siquiera albergan la operación UNION.
Uniones y filas duplicadas* Dado que la operación UNION combina las filas de dos conjuntos de resultados, tendería 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. También 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 operación UNION elimina las filas duplicadas como parte de su procesamiento. Así,. el conjunto combinado de resultados contiene sólo una fila del producto REI-2A44L Si se desea conservar las filas duplicadas de una operación UNION, hay que especificar la palabra.clave ALL inmediatamente a continuación de la palabra UNION. Esta forma de la consulta produce dos filas duplicadas para el producto REI-2A44L:
Listar todos los productos para los que el precio sea mayor que 2.000 €, a cuando se hayan pedido más 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!
Capítulo 6: Consultas simples
SOL. Manual de referencia
4100Y 2A44L
ACI
4100Z
RE! IMM RE! RE!
2A44R 775C 2A44L 2A44R
131
Nótese que el manejo predeterminado de las filas duplicadas en la operación y para la instrucción simple SELECT es exactamente opuesto. Para la instrucción SELECT, SELECT ALL (se conservan los duplicados) es la forma predeterminada. Para eliminar filas duplicadas se debe especificar explícitamente SELECT DISTINCT. Para la operación UNION, UNION (se eliminan los duplicados) es la for~ ma predeterminada. Para conservar filas duplicadas se debe especificar explícitamente 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 razón de esta inconsistencia que las formas predeterminadas de SQL se eligieron para producir el comportamiento correcto en la mayoría de las ocasiones: UNION
• En la práctica, la mayoría de instrucciones SELECT simples no producen filas duplicadas, por lo que la forma predeterminada es no eliminar duplicados. • En la práctica, la mayoría de operaciones UNION producirían filas duplicadas no deseadas, por lo que la forma predeterminada es la eliminación de duplicados. La eliminación de filas duplicadas de los resultados es un proceso costoso en tiempo, especialmente si los resultados contienen un gran número de filas. Si se sabe, debido a las consultas individuales implicadas, que una operación UNION no puede producir filas duplicadas, se debería especificar la operación UNION ALL, porque la consulta se ejecutará mucho más rápidamente.
Uniones y ordenación* La cláusula QRDER BY no puede aparecer en ninguna de las dos instrucciones SELECT combinadas con una operación UNION. No tendría mucho sentido ordenar los dos conjuntos de resultados porque se transmitirían directamente a la opera~ ción UNION y nunca serían visibles para el usuario. Sin embargo, el conjunto combinado de resultados producidos por la operación UNION se pueden ordenar especificando la cláusula ORDER BY después de la segunda instrucción SELECT. Dado que las columnas producidas por la operación UNION no tienen nombre, la cláusula ORDER BY debe especificar las columnas por su número de columna. A continuación se muestra la misma consulta de productos que la mostrada en la Figura 6.15, con los resultados ordenados por fabricante y número de producto:
Listar todos los productos para los que el precio sea mayor que 2.000 € o cuando se hayan pedido más de 30.000 € del producto en un único pedido, ordenados por fabricante y número de producto. SELECT ID_FAB, ID_PRODUCTO FROM PRODUCTOS WHERE PRECIO> 2000,00 € UNION
132
SOL Manual de referencia
1
Capítulo 6: Consultas simples
SELECT DISTINCT FAS, PRODUCTO FROM PEDIDOS WHERE IMPORTE> 30000.00
·1
ORDER BY 1,
ACI
4100Y
ACI
4100Z
IMM
?75C
RE!
2A44L
RE!
2A44R
Tabla I(lUI(l"" A sin.
2
Sue
e
(
UNIÓN
..J
George Sil! Harry
J
Sue
UNIÓN
FROM e)
Sue Julia Harry
Julia Harry Mary'¡
UNION anidadas.
Sin embargo, si las uniones implican una mezcla de orden de evaluación sí importa. Si la expresión:
Bruno
.J
J
George
Figura 6.16. Operaciones
SELECT
UNION
y
UNION ALL,
el
A UNIaN ALL B UNION C
María Genaro Fulgencio Susana 'Julia Hilario
se interpreta como: A UNION ALL
(B UNION e)
entonces produce diez filas de resultados (seis de la la tabla A). Sin embargo, si se interpreta como:
Los paréntesis de la consulta indican la operación UNION que se debe realizar primero. De hecho, si todas las operaciones UNION de la instrucción 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
(
Mary
SELECT FRQM A UNION (SELECT PROM B UNION
sil! Mary George Fred
, sil!
La operación UNION se puede usar repetidamente para combinar tres o más conjuntos de resultados, como se muestra en la Figura 6.16. La unión 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 operación UNION. La consulta de la figura se escribe:
1
Resultados de la consulta
George Fred
Julia Harry
Tabla
,1
Mary
Tabla B sil!
Uniones múltiples*
I
133
(A UNION ALL Bl UNION
UNION
interior más cuatro de
e
entonces produce sólo cuatro filas, dado que la UNION externa elimina todas las filas duplicadas. Por esta razón siempre es buena idea usar paréntesis en las operaciones UNION de tres o más tablas para especificar el orden de evaluación pretendido.
(B UNION Cl
(A UNIaN B) UNION C (A UNIaN C) UNION B ,,1,
l', ,1'
, i
f :,
Resumen
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
Este. capítulo es el primero de cuatro sobre las consultas SQL. Ha descrito las siguientes características de las consultas:
(B UNION ALL Cl
• La instrucción SELECT se usa para expresar una consulta SQL. Cada instrucción SELECT produce una tabla de resultados que contiene una o más columnas, y ninguna o varias filas.
(A UNION ALL Bl UNION ALL e (A UNTON ALL cl UNION ALL B
¡::
¡
L
-
134
SQL. Manual de referencia
• La cláusula FROM especifica la tabla o tablas que contienen los datos a recuperar por una consulta. • La cláusula SELECT especifica la columna o columnas de datos que se incluirán en ·Ios resultados, que pueden ser columnas de datos de la base de datos o columnas calculadas. • La cláusula WHERE selecciona las filas a incluir en los resultados aplicando una condición de búsqueda a las filas de la base de datos. • Una condición de búsqueda puede seleccionar filas comparando valores, comprobando un valor con un rango de valores, encajando un patrón de cadena y comprobando si son valores NULL. • Los condiciones simples de búsqueda se pueden combinar con ANO, OR Y NOT para formar condiciones de búsqueda más complejas. • La cláusula ORDER BY especifica que los resultados se deberían ordenar de forma ascendente o descendente según los valores de una o más columnas. • La operación UNION se puede usar en una instrucción SELECT para combinar dos o más conjuntos de resultados en un único conjunto.
CAPíTULO
7
Consultas multitabla (reuniones)
Mucha~
consultas útiles necesitan datos de dos o más 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 región Este mostrando la descripción del producto y el representante (PEDIDOS, REPRESENTANTES, OFICINAS
Y PRODUCTOS).
SQL permite recuperar datos que responden a estas solicitudes con las consultas multitabla que reúnen datos de dos o más tablas. En este capítulo se describen estas consultas y la característica de reunión 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 número de pedido, su importe y el nombre y límite de crédito del cliente.»
Los cuatro elementos de datos solicitados están almacenados claramente en dos tablas diferentes, como se muestra en la Figura 7.1.
135 l
136
SOL. Manual de referencia
I,
Capítulo 7: Consultas multitabla (reuniones)
Tabla PEDIDOS
¡1'
Relación de clave primaria/clave
I
externa
NUM PEDIDO
FECIlA.-PEDlOO
CLIEm'E
""" 113012
17/1?I1
211V
I
112989
11/01/1990
03/01/1990
I
g6f
.e, 106 105 106
C1IN1'IDAD
~;
7
35 6
Tab! a CLIENTES NUM CLI EMPRESA
IMPORTE
34.500,OO€ 3 745,OO€
1 458,OO€
137
REP CLI LIMITE CREDrTO
=,
Hen..,h..
21.22
Toledo S A. \
L6 n ez
109 106 105
1
®
00 000 OO€
~ooo~ 30,000 OO€
\
«Listar todos los pedidos, mostrando el número de pedido,
su importe y el nombre y Ifmite de crédito del e/iente.» Tabla PEDIDOS Tabla CLIEtn'ES
h'U!LPEOIDO
NUM_cIlr I EMPRESA
r
,'-"" I llJ) J.P.
Henche & López
2
Sotoca
Toledo S.A.
REP~CLIILIMITE_~REDITO
109 106 105
11961 11 012 11 989
550oo,oaE
PF:CIII..-PEDIDO CLIENTE
'"
$!V '" '"
17/12/1989 11/01/1990 2111 03/0111990 2101
35000,OaE 30.000,00 €
@
105
II
{~ 1,L
Figura 7.1.
351!:745.00€ 6 1.458,00€
a
MPORTE
-~112961 ~1.500.00€
Una solicitud sobre dos tablas.
• La tabla PEDIDOS contiene el número de pedido y su importe, pero no tiene nombres de cliente ni límites de créditos. • La tabla CLIENTES contiene, los nombres y saldos de los clientes, pero no tiene información de los pedidos.
Figura 7.2.
Sin embargo, hay un enlace entre estas dos tablas. En cada fila de la tabla PE~ la columna CLIENTE contiene el número 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~.ción SELECT que maneja la solicitu~ d~be usar de algún modo este enlace entre las tablas para generar sus resultados. Antes de examinar la instrucción SELECT de la consulta, es instructivo pensar en cómo uno mismo resolvería la solicitud usando lápiz y papeL La Figura 7.2 muestra lo que uno probablen:ente ~arfa:
5.
DIDOS,
IMPORTE
7 :::i1.500.00.$
,,~
Resultados de la ccos NUM PEDIDO
CM'TIDAD
EMPRESA J . P.
sotocl'
/
0
0
/
LIMITE CR¡¡Í:llTO
35.000.00€
Procesamiento manual de una consulta multitabla.
¡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 más pedidos. PEDIDOS
Por supuesto, ésta no.es la única forma de generar los resultados, pero independientemente de cómo se haga, dos cosas serán ciertas: • Cada fila de resultados torna sus datos de un par específico 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 númeróde pedido (112961) y su importe (31.500,00 E), Y copiar ambos valores en la primera fila de resultados. Buscar en la fila el número de cliente que realizó el pedido (2117) e ir a la tabla CLIENTES para encontrar el número de cliente 2117 en la columna
Reuniones simples (equirreunion~;i
CUST_NUM.
Buscar en la fila de la tabla CLIENTES el nombre del cliente (<<1. P. Sotoca,,) y el límite de crédito (35.000,00 E), Ydespués copiarlos en la tabla de resultados.
El proceso de la formación de pares de filas haciendo corresponder los contenidos de las columnas relacionadas se denomina reunión de tablas. La tabla resultante (que contiene datos de las tablas originales) se denomina reunión de dos tablas
~
138
Capítulo 7: Consultas multitabla (reuniones)
SOL. Manual de referencia
(una reunión que se basa en una correspondencia exacta entre las dos reuniones se denomina equirreuni6n. Las reuniones también se basan en otras clases de comparaciones de columnas, como se describe más tarde en este capítulo). 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 explícitos 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 debería sorprender que la instrucción SELECT de una consulta multitabla contenga una condición de búsqueda que especifica el encaje de columnas. Aquí hay una instrucción SELECT para la consulta calculada manualmente en la Figura 7.2: Listar todos los pedidos, mostrando el número de pedido, su importe y el bre y límite de crédito del cliente. SELECT NUM_PEDIDO, IMPORTE, FROM PEDIDOS, CLIENTES WHERE CLIENTE : NUM_CLI
ésta restringe las filas que aparecen en los resultados. Dado que es una consulta de dos tablas. la condición de búsqueda especifica las mismas columnas coincidentes que se usaron en el procesamiento manual de la consulta. Realmente captura el espíritu del encaje de columnas muy bien. diciendo: «Generar los resultados sólo para parejas de filas en las que el número de cliente (CUST) de la tabla PEDIDOS coincide con el número de cliente (CUST_NUM) de la tabla CLIENTES.» Nótese que la instrucci6n SELECT no dice nada sobre c6mo debería ejecutar SQL la consulta. No hay mención acerca de «comenzar con los pedidos» o «comenzar con los usuarios». En su lugar. la consulta dice a SQL qué tipo de resultados deberían aparecer y deja a SQL decidir cómo generarlos.
Consultas padre/hijo Las consultas multitabla más comunes involucran dos tablas que tienen una relación natural padre/hijo. La consulta de los pedidos y clientes de la sección 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 Capítulo 4 se puede recordar que las claves externas y las claves primarias crean la relación padre!hijo en una base de datos SQL. La tabla que contiene la clave externa es el hijo en la relación: la tabla con la clave primaria es el padre. Para incorporar la relación padrelhijo en una consulta hay que especificar una condici6n de búsqueda que compare la clave externa con la clave primaria. Aquí hay otro ejemplo de una consulta que incorpora la relación padre/hijo mostrada en la Figura 7.3:
,,
T bl OFICINlIS OI'INA
REGIÓN
CIUD.>.D '22 Daimiel
Nllvllrrll
"
",.
Deste Este Este Este oest"
Tebl'l\E~
'"
'" '" '"'"
'"
""\M...EHPL
'"'" '" '"". '"no ". '"
Esto se parece a las consultas del capítulo anterior pero con dos nuevas características. En primer lugar. la cláusula FROM lista dos tablas en lugar de una. En segundo lugar. la condición de búsqueda:
lO'
compara columnas de dos tablas diferentes. Estas columnas se denominan columnas coincidentes de las dos tablas. Al igual que todas las condiciones de búsqueda.
Una consulta padre/hijo con OFICINAS y REPRESENTANTES.
140
Capítulo 7: Consultas multitabla (reuniones)
SOL. Manual de referencia
Listar las oficinas y los nombres y puestos de sus jefes.
Listar cada representante y la ciudad y la región en que trabajan. SELECT NOMBRE. CIUDAD. REGION FROM REPRESENTANTES. OFICINAS WHERE OFICINA_REP = OFICINA
SELECT CIUDAD. NOMBRE. PUESTO FROM OFICINAS, REPRESENTANTES WHERE JEF = NUM_EMPL
Pablo Cruz Daniel Ruidrobo Bruno Arteaga Susana Santos León Freire Neus Azcárate
Este Este
Almeria
Este
León León Daimiel
Oeste Oeste Oeste
141
SaI'luel Clavel León Freire León Freire
La tabla OFICINAS (hijo) contiene JEF, una clave externa para la tabla (padre) REPRESENTANTES. Esta relación 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 práctica, como en los dos ejemplos precedentes. Esto es porque las claves primarias y externas son generalmente números identificadores (como los números de oficina y de empleados en los ejemplos) que las personas consideran difíciles de recordar, mientras que los nombres asociados (ciudades, regiones, nombres, puestos) son más fáciles de comprender. Es muy común que se usen números de identificación en la cláusula WHERE para reunir dos tablas, y especificar nombres más descriptivos en la cláusula SELECT para generar las columnas de los resultados.
La tabla REPRESENTANTES (hijo) contiene OFICINA_REP, una clave externa de la tabla OFICINAS (padre). Esta relación 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.
La condición de búsqueda que especifica las columnas coincidentes de una consulta multitabla se puede combinar con otras condiciones de búsqueda para restringir más los contenidos de los resultados. Supóngase que se desea volver a ejecutar la consulta anterior mostrando sólo 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
Figura 7.4.
Una consulta padre/hijo diferente con OFICINAS y REPRESENTANTES.
-
CIUDAD
NOMBRE
PUESTO
Castellón León León
Bernardo Sánchez Freire
Jefe Ventas Jefe Ventas
142
Con la condición de búsqueda adicional, las filas que aparecen en los resultados de la consulta se restringen más. El primer test (JEF = NUM~EMPL) selecciona sólo parejas de filas de OFICINAS y REPRESENTANTES que tienen la relación padre/hijo adecuada; el segundo test selecciona sólo las parejas de filas en las que la oficina está por encima del objetivo.
Encaje de múltiples columnas La tabla PED"IDOS y la tabla PRODUCTOS de la base de datos de ejemplo están 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 términos de la relación padre/hijo, se deben especificar ambas parejas de columnas coincidentes, como se muestra en este ejemplo:
Listar todos los pedidos, mostrando la cantidad y descripción de cada producto.
1
SELECT NUM_PEDIDO, IMPORTE, DESCRIPCION PROM PEDIDOS, PRODUCTOS WHERE FAS ~ ID_FAS AND PRODUCTO ~ ID_PRODUCTO
Serie 2, cable Serie- 2, cable Serie 3, cable Serie 4, cable Serie 4, cable Serie 4, cable Zapata grande Zapata grande
143
Consultas con tres y más tablas SQL puede combinar datos de tres o más tablas usando las mismas técnicas básicas de las consultas de dos tablas. Aquí se muestra un ejemplo simple de una reunión de tres tablas:
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-
Bruno Arteaga Neus Azcárate León Freire Samuel Clavel
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 REPRESENtANTES
Tabla CLIENTES NillLCLI
<..¡u.
EMPRESA
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
Maria Jinlénez
31
11
susana santos
48
21
13
'\
i¡
: I
l'I . '1, ,JI ,
Capítulo 7: Consultas muJtitabla (reuniones)
SOL. Manual de referencia
I
I
!
La condición de búsqueda 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 restricción de SQL sobre el número de columnas involucradas en la condición 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 sólo unas pocas columnas de las tablas.
No es extraño encontrar consultas de tres o ·incluso cuatro tablas en aplicaCiones SQL de producción. Incluso en los confines de la pequeña base de datos de ejemplo, de cinco tablas, no es difícil enconlrar una consulta de cuatro tablas con sentido:
Aquí hay otra consulta de tres tablas que usa una organización 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
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.
La Figura 7.6 muestra las relaciones de esta consulta. La primera relación 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.
NOMBRE
CIUDAD
------------------ ----------------------Acrne Bruno Arteaga Almeria
La Figura 7.7 muestra las relaciones padre/hijo de esta consulta. Se extiende la secuencia de reunión del ejemplo anterior un paso más, enlazando un pedido con su cliente, el cliente con su representante y el representante con su oficina.
La gran mayoría 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.
"
EMPRU...
Filas
Otras equirreuniones
"u
JCP s .....
T.b""~'oo'~ iI
OPICIWL.REP
Hallar lodos los pedidos recibidos en fechas en las que se haya contratado algún lluevo representante. SELECT NUM_PEDIDO., IMPORTE, FECHA_PEDIDO, FROM PEDIDOS, REPRESENTANTES WHERE FECHA_PEDIDO ~ FECHA~CONTRATO
"aSUlIaDOS ae III COfl$una
CA.'lTII»J)
~,= ~
I~ '" '" U
2101
<05
~ ;4
IMPORTE
NUM_PEDIDO·
7 31.S00,00€ 3S 3.74S,00€ ---i 1.,sa,00€
NOMBRE
------------- ---------------------------------3.978,OO€ 12-0CT-89 Maria Jiménez 112968
,
112979 112975 112968 112979 112975
Una reunión de tres tablas con relaciones padre/hijo en cascada.
diferentes (112968,112975 Y 112979) se realizaron el 12 de octubre de 1989, y se contrataron dos representantes (León Freire y Maóa Jiménez) el mismo día. Los tres pedidos y los dos representantes producen seis filas de resultados. Esta relación varios a varios es diferente de la relación uno a varios creada con las columnas coincidentes de la clave primaria y externa. La situación se puede resumir corno sigue:
IMPORTE:
3losaD,oae 3.745.00€ 1.458,OO€
r---t
i
I Figura 7.7.
147
Una reunión 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 relación entre pares de filas es extraña -10 único que inevitablemente hay en común entre los pedidos y los representantes es que han ocurrido en la misma fecha. Sin embargo, SQL reúne de todas formas y sin problemas las tablas. Columnas coincidentes como las del ejemplo generan una relación varios a varios entre las dos tablas. Varios pedidos pueden compartir la fecha de contrato de un representante, y más de un representante puede haber sido contratado en la fecha en que se haya realizado un determinado pedido. Por ejemplo. nótese que tres pedidos
• Las reuniones que encajan las claves primarias con las externas siempre producen relaciones padrelhijo uno a varios. • Otras reuniones también 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 reunión de columnas coincidentes arbitrarias generan relacio· nes varios a varios. Nótese que estas tres situaciones diferentes son independientes de cómo se escriba la instrucción SELECT que expresa la reunión. Los tres tipos de reunión se escriben de la misma forma -incluyendo un test de comparación entre los pares de columnas coincidentes en la cláusula WHERE. No obstante, es útil pensar en las reuniones de esta manera para comprender cómo traducir una consulta en lenguaje natural a la instrucción SELECT correcta.
Reuniones sin igualdad El término reunión 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
SOL. Manual de referencia
Capftulo 7: Consultas multitabla (reuniones)
basadas en la igualdad "entre columnas coincidentes (equirreuniones) son con mucho las más comunes, SQL también permite reunir tablas en términos de otros operadores de comparación. Aquí hay un ejemplo en que se usa un test de comparación «mayor -q"ue» (» como base de una reunión:
II "\
149
• 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 cláusula FROM para simplificar los nombres calificados de columna y permitir referencias no ambiguas a columnas en las autorreuniones.
Listar·lodas 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
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 año para cada oficina; la de REPRESENTANTES contiene las ventas del año de cada representante. Normalmente no hay confusión entre las dos columnas porque la cláusula FROM determina la que es apropiada en cualquier consulta dada, como en estos ejemplos:
------------
300.000,OO€ 300.000,OO€ 300.000,OO€
.'_ ..
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· dición de búsqueda:
Mostrar las ciudades en las que las ventas superan los objetivos. SELECT CIUDAD, VENTAS FROM OFICINAS WHERE VENTAS > OBJETIVO
l.
·CUOTA_ > OBJETIVO
r
1
selecciona un par de .filas donde la columna
CUOTA
de la fila de
REPRESENTANTES
Mostrar todos los represemantes con ventas superiores a 350.000 €.
exc~e-la columna OBJETIVO de la.fila de OFICINAS. Nótese ,que los pares de filas de REPRESENTANTES y OFICINAS seleccionadas se relacionan s6lo de esta forma; no se requiere específicamente que la fila de REPRESENTANTES represente a al-
SELECT NOMBRE, VENTAS FROM REPRESENTANTES WHERE VENTAS> 350000.00
guien"·que·trabaje·en 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 más 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.
Considera.ciones,sobre SQ/..:yconsultas multitabla n' 1:...
,,1,
ll"¡:
,,¡:
SELECT NOMBRE, VENTAS, CIUDAD FROM REPRESENTANTES, OFICINAS WHERE OFICINA_REP = OFICINA
.,.,""
el
Las'corisultas-múltitabla 'descntas"ha'sta ¡momento no him requerido ninguna sintaxis·especüil' de SQ~'o"caractefísticas"del· lenguaje más allá 'de'las descritas para lasJeonsultas 'a 'Una única tabla. Sin embargo,. :algunas consultas multitabla no se pueden expresar sin las características adicionales del lenguaje SQL descritas en las siguientes secciones, En concreto:
Error:
·VENTAS· es un nombre ambiguo de columna
Aunque la descripción en inglés 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 ambigüedad se debe usar un nombre calificado de columna para identificar la columna. Recuérdese del Capítulo 5 que un nombre calificado de columna especifica el nombre de una columna y la tabla que contiene la columna.
• Los nombres calificados de columna se necesitan '3 ';veces'im consultas mul.- " titabla-para'eliminar referencias "ambiguas a ·columnas. '. ~.I'. Das selecciones de todas las·columnas (SELECT "')tienen un significado es" J,~' J. -'pecia): para -las consultas multitabla: ........
-
150
Los nombres calificados de las dos columnas plo son: OFICINAS. VENTAS ,
Capítulo 7: Consultas multitabla (reuniones)
SOL. Manual de referencia VENTAS
en la base de datos de ejem-
Y REPRESENTANTES. VENTAS
Un nombre calificado de columna se puede usar en cualquier lugar de una instrucción 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 versión corregida de la consulta anterior, que usa un nombre de columna calificado:
;
Mostrar el nombre, ventas y oficina de cada representante.
~:
II
i. i I
SELECT NOMBRE. REPRESENTANTES. VENTAS, FROM REPRESENTANTES. OFICINAS WHERE OFICINA_REP = OFICINA NOMBRE
~~~~~-~:~~~:---Saffiuel Clavel Bernardo Sánchez Pablo Cruz Daniel Ruidrobo Bruno Arteaga Susana Santos León Freire Neus Azcárate
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
151
SELECT FROM REPRESENTANTES, OFICINAS WHERE OFICINA_REP = OFICINA
Obviamente, la forma SELECT * de una consulta llega a ser mucho menos práctica cuando hay dos, tres o más tablas en la cláusula FROM. Muchos dialectos SQL tratan el asterisco como una clase especial de nombre de columna comodín 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 selección REPRESENTANTES. * se expande en una lista que contiene sólo las columnas de la tabla REPRESENTANTES:
Lisiar lada /a información de los representantes y los lugares en que trabajan. SELECT REPRESENTANTES.~. CIUDAD, FROM REPRESENTANTES, OFICINAS WHERE OFICINA_REP = OFICINA
REGION
La consulta produciría once columnas de resultados -las nueve de REPRESENlas otras dos columnas solicitadas explícitamente de la tabla de elemento de selección «todas las columnas calificadas» se soporta en muchos pero no en todos los SGBD basados en SQL. No se permitió en el estándar SQLl, pero es parte de la especificación SQL2 de ANSI/ISO. TANTES seguidas de OFICINAS. Este tipo
Autorreuniones Muchas consultas multitabla involucran una relación que una tabla tiene consigo misma. Por ejemplo, supóngase 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 número de empleado del jefe del representante. Podría 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, sería como: SELECT NOMBRE, NOMBRE FROM REPRESENTANTES, REPRESENTANTES WHERE JEFE ; NUM_EMPL
Como se estudió en el Capítulo 6. SELECT * se puede usar para seleccionar todas las columnas de la tabla nombrada en la cláusula FROM. En una consulta multitabla, el asterisco selecciona todas las columnas de todas las tablas de la cláusula FROM. La siguiente consulta, por ejemplo, produciría quince columnas de resultados -las nueve columnas de la tabla REPRESENTANTES seguidas por las seis de la tabla OFICINAS:
Esta instrucción SELECT es ilegal debido a la referencia duplicada a la tabla en la cláusula FROM. Se podría intentar eliminar la segunda referencia a la tabla REPRESENTANTES así:
Listar (oda la información de los representantes y las oficinas en las que trabajan.
SELECT NOMBRE, NOMBRE FROM ~EPRESENTANTES WHERE JEFE = NUM_EMPL
REPRESENTANTES
152
SOL. Manual de referencia
Capitulo 7: Consultas muJtitabla (reuniones)
153
11
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 condición de búsqueda: JEFE
I i'
==
Dado que las columnas de las dos tablas tienen nombres idénticos, todas las referencias a columna están calificadas. En caso contrario, esto parecería 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 continuación está la misma consulta escrita usando los alias para EMPS y JEFES para la tabla REPRESENTANTES:
NUM_EMPL
Las filas que satisfacen esta condición son aquéllas 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 ningún resultado-o No son exactamente los datos que se deseaban recibir según la consulta requerida. Para comprender cómo resuelve SQL este problema hay que imaginar dos co· pias idénticas 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 sería una clave externa de la tabla JEFES, y la siguiente consulta funcionaría:
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
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>
NmCEMPL
'"'
'"'"
I !II
'1
'AN'rES) ''-VI-'''' U" "<'''''<'''''''''''''-'''0>' NOMBRE
Bruno Artell.gll. María Jiméne'l: Susana Santos Samuel Clavel Bernardo Sánche aniel Ruidrobo s Saz Freb::e cruz zcárllte
1
EDAD
"n '" ""
'" H
"'""
EMPS.NOMBRE
JEFES.NOMBRE
Tomás Saz Bruno Arteaga Daniel Ruidrobo Pablo Cruz María Jirnénez Bernardo Sánchez León Freire Susana Santos Neus Azcárate
Daniel Ruidrobo Bernardo Sánchez Bernardo Sánchez Bernardo Sánchez Samuel Clavel Samuel Clavel Sarnuel Clavel León Freire León Freire
OFICONA.-REP
B
La cláusula 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 después del nombre real de la tabla. Como muestra el ,ejemplo, cuando una cláusula FROM contiene un alias de tabla, el alias se debe usar para identificar la tabla en las referencias calificadas a columna. Por supuesto, realmente sólo es necesario usar un alias para una de las dos apariciones de las dos tablas en esta consulta. Se podría haber escrito tan fácilmente como:
n n n
" """"n ""
l·
SELECT REPRESENTANTES. NOMBRE, JEFES.NOMBRE FROM REPRESENTANTES, REPRESENTANTES JEFES WHERE REPRESENTANTES.JEFE = JEFES.NUM_EMPL
I
'11I
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 continuación se muestran algunos ejemplos adicionales de autorreuniones:
1
". I
Listar los representantes con una cuota superior a la de su jefe.
Listar los representantes que trabajan en una oficina distinta a la de su jefe, mostrando el nombre y oficina en donde trabaja cada uno.
Figura 7.10.
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
La Figura 7.10 muestra la forma básica de la cláusula FROM para una instrucción SELECT sobre varias tablas, completada con alias de tabla. La cláusula tiene dos funciones importantes:
• La cláusula
EMPS.NOMBRE
OFICINA_EMP.CIUDAD
JEFES.NOMBRE
OFICINA_JEF. CIUDAD
Bernardo Sánchez Bruno Arteaga León Freire Neus Azcárate
Castellón Almería León Daimiel
Samuel Clavel Bernardo Sánchez Samuel Clavel León Freire
Navarra Castellón Navarra León
PROM identifica ladas las labias que aportan datos a los resultados de la consulta. Cualquier columna referenciada en la instrucción SELECT debe venir de una de las tablas listadas en la cláusula PROM. (Hay una excepción para las referencias externas de las subconsultas, como se describe en el Capítulo 9.) • La cláusula FROM especifica la etiqueta que se usa para identificar la tabla en las referencias calificadas a columnas dentro de la instrucción 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 cláusula PROM, es el que se convierte en la ~tiqueta.
Alias de tablas
'1, "
ti
:I
El único requisito para las etiquetas de tabla en la cláusula FROM es que todas las etiquetas de una cláusula FROM sean distintas entre sí. La especificación SQL2 permite opcionalmente que la palabra clave AS aparezca entre el nombre de la tabla y su alias. Aunque esto hace que la cláusula FROM sea más fácil de leer, no está incluido en todas las implementaciones de SQL. (Nótese que la especificación SQL2 usa el término nombre de correlaci6n para referirse a lo que hemos llamado alias de tabla. La función y el significado de un nombre de correlación son exactamente como se describen aquí; muchos productos SQL usan el término alias, y es más descriptivo en cuanto a la función que realiza un alias de tabla. El estándar SQL2 especifica una técnica similar para designar nombres de columna alternativos, y en esa situación el nombre alias de columna se denomina realmente alias en el estándar).
Como se ha descrito en la sección 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 CUMPLEAÑOS y pertenece al usuario SAM: Lisrar los nombres, las cuotas y cumpleaños de los representantes.
I SELECT REPRESENTANTES. NOMBRE, CUOTA, SAM.CUMPLEA~OS.BIRTH_DATE FROM REPRESENTANTES, CUMPLEARos WHERE REPRESENTANTES. NOMBRE = SAM.CUMPLEAaOS.NOMBRE
es más fácil de leer y escribir si se usan los alias R y
e para las dos tablas:
Rendimiento de las consultas multitabla
Listar los nombres, las cuotas y cumpleaños de los representantes. SELECT R. NOMBRE , CUOTA. C.BIRTH_DATE FROM REPRESENTANTES R, SAM.CUMPLEA&OS C WHERE R.NOHBRE = S.NOMBRE
El diagrama sintáctico de la cláusula FROM.
I \
Al aumentar el número de tablas de una consulta, la cantidad de esfuerzo requerido para manejarlas se incrementa rápidamente. El propio lenguaje SQL no impone ningún límite en el número de tablas reunidas en una consulta. Algunos productos SQL limitan de hecho el número de tablas; un límite cercan? a ocho es algo muy
156
SOL. Manual de referencia
Capítulo 7: Consultas multitabla (reuniones)
común. El alto coste de procesamiento de consultas que reúnen muchas tablas impone un límite práctico aún menor en muchas aplicaciones. En las aplicaciones de procesamiento interactivo de transacciones (OLTP, Online Transaction Processing) es común que una consulta contenga sólo una o dos tablas. En estas aplicaciones el tiempo de respuesta es crítico -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 típicas en la base de datos de ejemplo serían:
,
Ili
:1/
157
los resultados que produce mediante una instrucción SELECT dada, y, en menor medida, la teoría acerca de las bases de datos relacionales sobre las reuniones.
Multiplicación de tablas Una reunión es un. caso especial de una combinación de datos más 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 pequeñas tablas de ejemplo y su producto. Si se especifica una consulta de dos tablas sin una cláusula WHERE, SQL obtiene el producto de las dos tablas como resultado. Por ejemplo, esta consulta:
• El usuario introduce el número de cliente en un formulario y el SOBD devuelve el límite de crédito del cliente, el saldo de la cuenta y otros datos (una consulta a una sola tabla). • Un dependiente examina el número 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).
Mostrar todas las combinaciones posibles de representantes y ciudades.
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 continuación se relacionan algunas consultas típicas para la ayuda a la toma de decisiones para la base de datos de ejemplo:
SELECT NOMBRE, CIUDAD PROM REPRESENTANTES, OFICINAS
obtendría el produclO de las tablas REPRESENTANTES y OFICINAS, mostrando todos los posibles pares de representantes y ciudades. Habría 50 filas de resultados (5 oficinas * 10 representantes = 50 combinaciones). Nótese que la instrucción SELECT es exactamente la misma que se usaría en la reunión de dos tablas, sin la cláusula WHERE que compara las columnas coincidentes, como en:
I
• 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).
Mostrar todos los representantes y las ciudades en que trabajan.
Tabla CHICAS NOMBRE
CIUDAD
Beatri María Susana
Caste116n Barcelona Castellón
La estructura de una reunión
I
Tabla CHICOS
Para las reuniones simples es muy fácil escribir la instrucción SELECT correcta, basada en la solicitud formulada en lenguaje natural, o examinar una instrucción SELECT y determinar lo que hace. Sin embargo, cuando se reúnen varias tablas o cuando las condiciones de búsqueda son complejas, llega a ser muy difícil observar simplemente una instrucción SELECT y determinar lo que significa. Por esta razón es importante definir con más cuidado y más formalmente lo que es una reunión,
NOMBRE
CIUDAD
Jaime Samuel
Daimiel Castellón
Figura 7.11.
~
El producto de dos tablas.
Capítulo 7: Consultas multitabla (reuniones)
SOL Manual de referencia
158
SELECT NOMBRE, CIUDAD FROM REPRESENTANTES, OFICINAS WHERE OFICINA_REP = OFICINA
5. 6.
Estas dos consultas ilustran una relación importante entre las reuniones y los 7.
productos:
Una reunión 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 condición 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 sección.
Reglas para el procesamiento de consultas multitabla Los pasos que siguen al código 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 instrucción SELECT multltabla especificando un procedl~11Iento que siempre genera el conjunto correcto de resultados. Para ver cómo funclOna el procedimiento, considérese esta consulta:
159
Si se especifica SELECT DISTINCT, eliminar todas las filas duplicadas del resultado que se hubieran producido. Si la instrucción 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 cláusula ORDER BY, ordenar los resultados corno se especifique.
Las filas generadas por este procedimiento contienen los resultados de la consulta. Siguiendo los pasos anteriores: l.
2.
3.
4.
La cláusula 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 cláusula vlHERE selecciona sólo las filas de la tabla producto en las que los números de cliente coinciden (NUM_CLI = CLIENTE) Y el número de cliente sea el especificado (NUM_CLI = 2103). Sólo se seleccionan cuatro filas; las otras 626 filas se eliminan. La cláusula 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 cláusula ORDER BY ordena las cuatro filas de la columna NUM_PEDIDO para generar los resultados finales de la consulta.
Listar el nombre de la empresa y rodos los pedidos del cliente número 2103. SELECT FROM WHERE AND ORDER EMPRESA
EMPRESA, NUM_PEDIDO, CLIENTES, PEDIDOS NUM_CLI = CLIENTE NUM eLI = 2103 BY NUM_PEDIDO
IMPORTE
NUM_PEDIDO
IMPORTE
112983 112987 113027
702,OO€ 27 .SOO.OO€ 4 .104.00€
------------------ ----------3.276,OO€ 112963
Acrne Acme Acme Acme
Para generar los resultados de una instrucción SELECT:
1. 2.
3.
l' 4.
Si la instrucción 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 cláusula FROM. Si la cláusula FROM lista sólo una tabla, el producto es esa tabla. Si hay una cláusula WHERE, aplicar su condición de búsqueda ~ ~ada fila ~e la tabla producto, conservando las filas para las que la condiCión 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 selección para produci; una única fila de resultados. Por cada referencia a columna, usar el valor de la columna de la fila en curso.
Obviamente, ningún SOBD basado en SQL resolvería la consulta de esta forma, pero el propósito de la definición previa no es describir cómo un SGBD resuelve la consulta. En cambio, constituye una definición de cómo determinar exactamente lo que «significa» una consulta multitabla -es decir, el conjunto de resultados que debería producir.
Reuniones externas* La operación de reunión de SQL combina la información 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 reunión puede producir resultados inesperados, como se ilustra en estas consultas:
LisIar los representames y las oficinas en las que trabajan. SELECT NOMBRE, OFICINA_REP FROM REPRESENTANTES NOMBRE Bruno Arteaga María Jiménez
OFICINA_REP 13 11
160
Capítulo 7: Consultas multitabla (reuniones)
SOL. Manual de referencia Pablo Cruz Daniel Ruidrobo Bruno Arteaga Susana Santos León Freire Neus Azcarate
21 11 12 12
Susana Santos Samuel Clavel Bernardo Sánchez Daniel Ruidrobo Tomás Saz León Freire
NULL 21 12 22
Pablo Cruz Neus Azcárate
SELECT NOMBRE, CIUDAD FROM REPRESENTANTES, OFICINAS WHERE DFICINA_REP = OFICINA
CIUDAD
María Jiménez Samuel Clavel Bernardo Sánchez Pablo Cruz
Navarra Navarra
Daniel Ruidrobo Bruno Arteaga Susana Santos León Freire Neus Azcárate
Castellón Castellón Almería León León
Daimiel
Estos resullados se generan usando un tipo diferente de operación reunión, denominada reunión externa (indicada con la notación «*=» en la cláusula WHERE). La reunión externa es una extensión de la reunión estándar descrita anteriormente en este capítulo, que se denomina a veces reunión interna. El estándar SQL I especifica sólo la reunión interna; no incluye la reunión externa. Los primeros produc· tos SQL de IBM sólo daban soporte a la reunión interna. Sin embargo, la reunión 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 líderes de Microsoft, Sybase, Oracle e Informix de 18M. La reunión externa también es la forma más natural de expresar un cierto tipo de consultas, como se muestra en el resto de esta sección. Para comprender bien la reunión externa es útil abandonar la base de datos de ejemplo y considerar las dos tablas simples de la Figura 7.12. La tabla CHICAS
Listar los representantes y las ciudades en las que trabajan.
NOMBRE
161
Castellón
Castel16n Castel16n Almeria León León
Daimiel Tabla CHICAS
Basándonos en las descripciones en lenguaje natural de estas dos consultas, probablemente cabría esperar que produjesen el mismo número de filas. Pero la primera consulta incluye una fila cada uno de los diez representantes, mientras que la segunda sólo produce nueve. ¿Por qué? Porque Tomás Saz no está actualmente asignado y tiene un .valor NULL en la columna OFICINA_REP (que es la columna coincidente de la reunión). Este valor NULL no encaja con ninguno de los números de oficina de la tabla OFICINAS, por lo que la fila de Tomás de la tabla REPRESENTANTES no encaja con ninguna. Como resultado, «desaparece» de la reunión. La reunión estándar SQL tiene así el potencial de perder información si las tablas que se reúnen contienen filas que no encajan. Basándonos en la versi6n de la consulta en lenguaje natural cabría esperar que la segunda consulta produjese resultados como los siguientes:
NOMBRE
Ana Beatriz María Nuria SUS41111
,.
ICIUDAD Oenia CastelIón Barcelona NULL CasteU6n
=:
rabra CHICOS NOMBRE
CIUDAD
An' Be4tri Haría Nuria Susana
Denia Castellón Barcelona NULL
Castellón Files
no coincidentes
Tabla resultado de la reunión externa
Listar los representantes y las ciudades en las que trabajan. SELECT NOMBRE. CIUDAD FROM REPRESENTANTES. OFICINAS WHERE OFICINA_REP -; OFICINA NOMBRE
CIUDAD
Saz María Jiménez
NULL
Tomás
AnA
Oflo,s .ClUOMl Ol.ICOS.1lI»lBRE Ol.ICAS.CIIJIWI Barcelona Herminio Barcelona Barcelona José Barcelona Catellón CasteU6n samuel Castellón CalStellón Semuel Denia NULL NULL
NULC HULL
NULC NULC NULL
ClI1CAS. NOKBRE:
Filas no coincidentes
Q
~
"'"',. --+
María
SUS4nII.
Beatriz
- { Nuria
Navarra Samuel Clavel Navarra Bernardo Sanchez Castellón
Figura 7.12.
-
Anatomía de una reunión externa.
NULL
NULC
Jailllt! Genaro
Daimiel NULL
~-
162
SOL. Manual de referencia
Capítulo 7: Consultas multitabla (reuniones)
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 podría usar esta consulta, que forma la reunión 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 :
La reunión interna produce cuatro filas de resultados. Nótese que dos de las chicas (Ana y Nuria) y dos de los chicos (Jaime y Genaro) no están 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 reunión interna. Dos de las filas sin correspondencia (Ana y Jaime) tienen valores válidos 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 ningún otro valor (ni siquiera con otro valor NULL). Supóngase que se desea listar los pares chica/chico que viven en la misma ciudad, y que se incluyan también los que no coincidan. La reunión externa de las tablas CHICAS y CHICOS produce exactamente este resultado. La siguiente lista muestra el procedimiento para la construcción de la reunión externa, y esta reunión se muestra gráficamente en la Figura 7.12. ]. 2.
3.
4.
Empezar con la reunión 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, añadir 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, añadir 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.
A continuación se muestra, Listar las chicas y chicos de la I/usma chica que no encaje.
. <':QL que produce la reunión externa: ClLtu ....
,do cualquier chico o
163
SELECT FROM CHICAS. CHICOS WHERE CHICAS.CIUDAD *;* CHICOS.CIUDAD CHICAS.NOI1BRE
CHICAS.CIUDAD
CHICOS. NOMBRE
CHICOS.CIUDAD
María Susana Beatriz Ana Nuria NULL NULL
Boston Castellón Castel16n Daimiel NULL NULL NULL
Herminio Sarnuel Sarnuel NULL NULL Joime Genaro
Boston Boston Caste1l6n Castellón NULL NULL DalIas NULL
-------------- -------------- --------------------------- Boston María José
La reunión externa de dos tablas contiene ocho filas. Cuatro de las filas son idénticas a las de la reunión interna de las dos tablas. Otras dos filas, de Ana y Nuria, vienen de filas que no encajan de la tabla CHICAS. Estas filas también se han rellenado con valores NULL haciéndolas corresponder con una fila imaginaria con valores NULL en las columnas de la tabla CHICOS, y añadiéndolas a los resultados. Las últimas dos filas, de Jaime y Genaro, vienen de filas que no encajan de la tabla CHICOS. Estas filas también se han rellenado con valores NULL haciéndolas corresponder con una fila imaginaria con valores NULL en las columnas de la tabla CHICAS, y añadiéndolas a los resultados. Como muestra este ejemplo, la reunión externa es una reunión que «preserva información». Cada fila de la tabla CHICOS se representa en los resultados (a veces más de una vez). De forma similar, cada fila de la tabla CHICAS se representa en los re.sultados (de nuevo, en ocasiones más de una vez).
Reuniones externas por la izquierda y por la derecha* Técnicamente, la reunión externa producida por la consulta anterior se denomina reunión externa completa de dos tablas. Ambas tablas se tratan de forma simétrica en la reunión externa completa. Hay otras dos reuniones externas bien definidas que no tratan de fonna simétrica a las dos tablas. La reunión 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 reunión 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 continuación se muestra la reunión 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
164
Capítulo 7: Consultas multitabla (reuniones)
SOL. Manual de referencia
CHICAS. NOMBRE
CHICAS.CIUDAD
CHICOS. NOMBRE
CHICOS.CIUDAD
María Maria Susana Beatriz
Bostan Bostan Castellón Castel16n Daimiel NULL
José Herminio Samuel Samuel NULL NULL
Bostan Bostan Castellón Castel16n NULL NULL
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 reunión 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 reunión 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 continuación se muestra una reunión 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
CHICAS.CIUDAD
CHICOS.NOMBRE
CHICOS.CIUDAD
Maria Maria Susana Beatriz NULL NULL
Boston Boston Castellón Castellón NULL NULL
José Herminio Samuel Samuel Jaime Genaro
Boston Boston Castellón Castellón DalIas NULL
--------------
-------------- --------------
--------------
Esta consulta también 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 simétrica 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 reunión). En una reunión 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 reunión externa por la derecha (la tabla derecha es la mayor, y la izquierda, la menor). En la práctica, las reuniones por la izquierda y por la derecha son más útiles que la reunión externa completa, especialmente cuando se reúnen datos de dos tablas con. una relación padre/hijo (clave primaria/clave externa). Para ilustrarlo considérese de nuevo la base de datos de ejemplo. Ya se ha visto un ejemplo con
165
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 aún asignado a una oficina. Tomás Saz es uno de tales representantes de la base de datos de ejemplo. Cualquier reunión que use la relación REPRESENTANTES~a-OFICINASy espere incluir datos de Tomás Saz debe ser una reunión externa, con la tabla REPRESENTANTES como la tabla mayor. A continuación se muestra el ejemplo usado anteriormente:
Listar los representantes y las ciudades en las que trabajan. SELECT NOMBRE, CIUDAD FROM REPRESENTANTES, OFICINAS WHERE QFICINA_REP -: OFICINA NOMBRE
CIUDAD
Tomás Saz Maria Jiménez Samuel Clavel Bernardo Sánchez Pablo Cruz Daniel Ruidrobo Bruno Arteaga Susana Santos León Freire Neus Azcárate
Nótese en este caso (una reunión externa por la izquierda) que la tabla «hijo» (REPRESENTANTES, la tabla con la clave externa) es la tabla mayor de la reunión 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 Tomás Saz) de la tabla hijo en los resultados, de forma que la tabla se convierta en la tabla mayor en la reunión externa. No importa si la consulta se expresa realmente como una reunión externa por la' izquierda (como se hizo previamente) o como una reunión externa por la derecha como ésta:
Listar los representantes y las ciudades en las que trabajan. SELECT NOMBRE, CIUDAD FROM REPRESENTANTES, OFICINAS WHERE OFICINA ~- OFICINA~REP NOMBRE
CIUDAD
Tomás Saz Maria Jiménez Samuel Clavel Bernardo Sánchez Pablo Cruz Daniel Ruidrobo
Bruno Arteaga Susana Santos León Freire Neus Azcárate
Almería León León Daimiel
Lo que importa es que la tabla hijo es la tabla mayor de la reunión externa. También hay consultas de reunión útiles en las que el padre es la tabla mayor, y la tabla hijo es la menor. Por ejemplo, supóngase 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 podría querer incluir una fila representando a la oficina de Daganzo. Aquí está la consulta de reunión externa que produce estos resultados:
Listar las oficinas y los representantes que trabajan en cada una.
II
SELECT CIUDAD, NOMBRE FROM OFICINAS, REPRESENTANTES WHERE OFICINA ~= OFICINA_REP CIUDAD
María Jiménez Samuel Clavel Bernardo sánchez Pablo Cruz Daniel Ruidrobo Bruno Arteaga Susana Santos León Freire Neus Azcárate NULL
En este caso, la tabla padre (OFICINAS) es la tabla mayor de la reunión 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 desempeña el papel de la tabla mayor. Los roles de las dos tablas están exactamente invertidos con respecto al ejemplo anterior. Por supuesto, la fila de Tomás 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.
Notación de la reunión externa* Dado que la reunión externa no formó parte del estándar SQLl y no se implementó en los primeros productos SQL de 1BM, los fabricantes de SGBD que daban soporte a la reunión externa usaron varias notaciones en sus dialectos SQL. La notación «*=*», usada en los ejemplos anteriores de esta sección, se emplea en
Capítulo 7: Consultas multitabla (reuniones)
167
SQL Server. Esta notación indica una reunión externa añadiendo un asterisco al ~est. de comparación en la cláusula WHERE que define la condición de reunión. Para mdlcar la reunión exte~na de dos tablas, TBLl y TBL2, sobre las columnas COLly COL2, se pone un astensco (*) antes y después del operador de reunión estándar. El test de comparación resultante de la reunión externa completa es: WHERE COLl
~=*
COL2
.Para indicar una reunión externa por la izquierda de TBLl y TBL2, sólo se espeCIfica el primer asterisco, dando el siguiente test de comparación: WHERE COL! *= COL2
. Para indicar una re~nión externa por la derecha de TBLl y TBL2, sólo se espeCifica el segundo astensco, dando el siguiente test de comparación: WHERE COL! =* COL2
. ~e puede usar u.na reunión, ~xterna c.on cualquiera de los operadores de comparaClOn usando la mIsma notaclOn. Por ejemplo, una reunión externa por la izquierda de TBLl y TBL2 que use una comparación mayor igual (>=) produciría un test de comparación como éste:
°
WHERE COL! *>= COL2
. Grade también incluye la operación de reunión externa, pero usa una notación dlfe~ente. Esta notación inicia la reunión externa en la cláusula WHERE incluyendo un signo de suma entre paréntesis después de la columna cuya tabla tiene añadida lafila imaginaria NULL (es decir, la tabla menor de la reunión externa). La reunión externa por la izquierda de TBLl y TBL2 produce la condición de búsqueda: WHERE COLl = COL2
{+)
y la reunión externa por la derecha de queda: WHERE COLl
(+)
TBLl
y
TBL2
produce la condición de bús-
= COL2
Nótese que el signo de suma aparece en el lado opuesto de la comparación con respecto a la notación de SQL Server. Grade no incluye la reunión externa·completa, pero, como se indicó anteriormente, esto no disminuye la utilidad práctica de las reuniones externas de Oracle l.
I N. del T.: A diferencia de versiones anteriores, la versión Oracle 9i incorpora la notación estándar ANSI/ISO SQL: 1999 para las reuniones eXlernas, incluyendo la reunión externa completa.
168
Capítulo 7: Consultas muftitabla (reuniones)
SOL. Manual de referencia
Aunque ambas notaciones para las reuniones externas son relativamente convenientes. son también algo engañosas. Recuérdese que las reglas para el procesamiento de consultas SQL multitabla comenzaban examinando la cláusula FROM de una consulta y construyendo conceptualmente el producto de dos (o más) tablas. Sólo después de que la tabla product.o se construyera, el SGBD comenzaba a eliminar las filas que no satisfacían la condición de búsqueda de la cláusula WHERE. Pero con la notación de SQL Server o de Oracle, la cláusula FROM no indica al SOBD si construir una tabla producto que sea s610 la reunión interna o una que incluya filas con valores NULL de una reunión externa. Para determinarlo, el SGBD debe «anticipar» la cláusula WHERE. Un problema más serio es que una reuni6n entre dos tablas puede involucrar más de un par de columnas coincidentes, y no es claro cómo se debería usar la notación cuando hay dos o tres pares de columnas coincidentes. Aparecen otros problemas con la notación de la reunión externa cuando la reunión se extiende a tres o más tablas. Es fácil extender la noción de una reunión externa a tres tablas: TBLl OUTER-JOIN TBL2 OUTER-JOIN TBL3
Éste es un conjunto de operaciones de la base de datos perfectamente legítimo de acuerdo con la teoría de bases de datos relacionales. Pero el resultado depende del orden en que se realicen las operaciones de reunión externa. Los resultados de: (TBLl OUTER-JOIN TBL2) OUTER-JOIN TBL3
serán, en gen~ral, diferentes de los resultados de: TBLl OUTER-JOIN (TBL2 OUTER-JOIN TBL3)
Al usar cualquiera de las notaciones de SQL Server o de Oraele es imposible especificar el orden de evaluación de las reuniones externas. A causa de ello, los resultados producidos por la reunión externa de tres o más tablas depende de los aspectos específicos de la implementación del SOBD.
Reuniones y el estándar SOL2 Las reuniones externas plantearon un problema a los escritores del estándar SQL2. Dado que las reuniones externas son el único camino para representar algunas consultas extremadamente útiles, fue importante que el estándar SQL2 incluyese soporte para las reuniones externas. Además, las reuniones externas se incluyeron en muchos productos SQL comerciales y llegaron a ser·una parte muy importante del lenguaje SQL. Sin embargo. los métodos usados para representar las reuniones externas variaron ampliamente entre los diferentes productos SQL, como se muestra en las secciones anteriores. Además. todos los métodos usados para denotar reuniones externas en productos comerciales tenían deficiencias y se eligieron fun-
_1
169
damentalmente debido a su menor impacto en el lenguaje SQL más que en su claridad o corrección. Frente a este escenario, el estándar SQL2 especificó un nuevo método para el soporte de las reuniones externas que no estaba basado en la notación establecida de un producto SQL popular en concreto. La especificación SQL2 puso eL soporte de las reuniones externas en la cláusula FRüM con una sintaxis elaborada que permite que el usuario especifique exactamente cómo se deben reunir las tablas fuente. El soporte de la reunión externa en el estándar SQL2 tiene dos ventajas distintas. Primera, el estándar SQL2 puede expresar incluso la más 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 añadido soporte para la mayor parte de la sintaxis, aunque no toda, de la reunión de SQL2 en el momento de escribir este libro. Es razonable esperar que la mayoría de las marcas principales de SOBD la incluirán, y que las características de la reunión en el estilo SQL2 serán parte de la corriente principal de SQL en los próximos años. Las ventajas del soporte extendido de las reuniones en SQL2 tienen el costo de una complejidad añadida con respecto a lo que había sido una de las partes más simples del lenguaje SQL. De hecho, el soporte extendido de las reuniones es parte de una extensión mucho mayor de las capacidades de las consultas en SQL2, que añaden incluso más capacidades y complejidad. Las otras características extendidas incluyen las operaciones de conjuntos sobre los resultados (unión, intersección y diferencia de tablas) y expresiones de consulta mucho más ricas que manipulan filas y tablas, y se permiten usar en subconsultas. Las capacidades extendidas relativas a las reuniones se describen en esta sección. Las otras características extendidas se describen en el siguiente capítulo, después de la discusión de las subconsultas básicas.
Reuniones internas en SOL2* La Figura 7.13 muestra una forma simplificada de la sintaxis SQL2 extendida de la cláusula FRQM. Es más fácil entender todas las opciones proporcionadas considerando cada tipo de reunión una a una, comenzando con la reunión interna estándar y después avanzando a las·diferentes formas -de la reunión externa. La reunión interna estándar de las tablas CHICAS y CHICOS se pueden expresar en el lenguaje SQLl, como: SELECT FROM CHICAS. CHICOS WHERE CHICAS.CIUDAD : CHICOS.CIUDAD
Ésta es todavía una instrucción aceptable en SQL2. Los escritores del estándar SQL2 no podrían realmente haberla hecho ilegal sin «romper» todos los millones de consultas multitabla que se habían escrito hasta comienzos de la década de 1990.
_
170
Capítulo 7: Consultas multitab/a (reuniones)
SOL. Manual de referencia
1-
Pero el estándar SQL2 especifica una forma alternativa de expresar la misma consulta:
Nótese que las dos tablas a reunir están conectadas explícitamente mediante una operación JOIN, y la condición de búsqueda que describe la reunión se especifica ahora en una cláusula ON en la cláusula FROM. La condición de búsqueda que sigue a la palabra clave ON puede ser cualquier condición de búsqueda que especifique el criterio usado para hacer corresponder las filas de las dos tablas reunidas. Las columnas referenciadas en la condición de búsqueda deben venir sólo de dos tablas reunidas. Por ejemplo: pártase de la hipótesis que las tablas CHICAS y CHICOS se hubieran ampliado con la columna EDAD. A continuación se muestra una reunión que encaja pares chica/chico de la misma ciudad y que también 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)
OUTER
LE'" RIGHT
5ELECT FROM CHICAS INNER JOIN CHICOS ON CHICAS. CIUDAD = CHICOS. CIUDAD
En estas reuniones simples de dos tablas, todo el contenido de la cláusula WHEse ha trasladado a la cláusula ON, y ésta no añade ninguna funcionalidad nueva al lenguaje SQL. Sin embargo, recuérdese de este mismo capítulo que en una reunión exterior que involucre tres o más tablas, el orden en que suceden las reuniones afecta a los resultados de la consulta. La cláusula QN proporciona un control detallado acerca de cómo se procesan estas reuniones multitabla, como se describe más adelante en este capítulo. El estándar SQL2 permite otra variación en la reunión interna simple entre las tablas CHICAS y CHICOS. Dado que las columnas coincidentes de las dos tablas tienen los mismos nombres y se comparan según su igualdad (que es el caso habitual), se puede usar una forma alternativa de la cláusula ON especificando una lista de nombres de columnas coincidentes: RE
expresión-dtrreunión
1-
'.,
---¡.JOIN fabla 2
tabla J-
INNER
--------j
ON sends condition yo' T USING(column lisO
FULL
LE'"
aUTER
RIGHT
expresión-de-producto cruzado
r-rabla
J-------
CROSS JOIN
_ _ _ _ tabla2 ........
expresión-da-unión
r--
Figura 7.13.
tab /a 1 - - - - - - - CROSS JOIN
- - - - fabla
2-+e
Cláusula FROM extendida en el estándar SQL2.
SELECT FROM CHICAS INNER JO IN CHICOS USING (CIUDAD. EDAD)
La cláusula USING especifica una lista separada por comas de los nombres de columnas coincidentes, que debe ser idéntica en ambas tablas. Es completamente equivalente a la cláusula ON que especifica explícitamente cada par de columnas coincidentes, pero es mucho más compacta y, por tanto, fácil de entender. Por supuesto, si las columnas coincidentes tienen diferentes nombres en las tablas CHICAS Y CHICOS, hay que usar una cláusula ON o WHERE con un test de igualdad. La cláusula QN también se debe usar si la reunión no conlleva la igualdad de las columnas coincidentes. Por ejemplo, si se desea seleccionar los pares chica/chico en
172
SOL. Manual de referencia
Capítulo 7: Consultas multitab/a (reuniones)
173
o bien:
donde se requiere que la chica sea mayor que el chico, se debe usar una cláusula QN para especificar la reunión:
SELECT FROM CHICAS FULL OUTER JOIN CHICOS USING (CIUDAD)
SELECT FROM CHICAS INNER JOIN CHICOS ON (CHICAS. CIUDAD : CHICOS.CIUDAD ANO CHICAS.EDAD > CHICOS. EDAD)
Como "'a palabra clave INNER es opcional en el lenguaje SQL2, el estándar SQL2 también permite omitir la palabra clave OUTER. La consulta anterior se podría haber escrito:
Hay una variación final de esta consulta simple que ilustra otra característica de la cláusula FRüM de SQL2. Una reunión de dos tablas en la que las columnas coincidentes son exactamente las columnas específicas de las dos tablas que tienen nombres idénticos, se denomina reunión natural, porque usualmente ésta es la forma más «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 reunión natural.usando esta consulta:
SELECT FROM CHICAS FULL JOIN CHICOS USING (CIUDAD)
El SGBD puede inferir de la palabra FULL que se requiere una reunión 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 continuación se muestra la reunión externa por la izquierda de la misma consulta:
SELECT FROM CHICAS NATURAL INNER JO IN CHICOS
SELECT PROM CHICAS LEFT OUTER JOIN CHICOS USING (CIUDAD)
Si se especifica la palabra clave NATURAL, no se pueden usar las cláusulas ON y USING en la especificación de la reunión, porque la reunión natural define específicamente la condición de búsqueda a usar para reunir las tablas -se confrontan todas las columnas con nombres idénticos de columna en ambas tablas. El estándar SQL2 parte de que la reunión «predeterminada» de dos tablas es una reunión interna. Se puede omitir la palabra clave INNER de los ejemplos anteriores y la consulta resultante sigue siendo una instrucción SQL2 válida con el mismo significado.
Como se describió anteriormente en este capítulo, los resultados inciuirán 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 reunión), ,pero los resultados no incluyen filas que no encajan de la tabla CHICOS. Análogamente, la versión de la reunión externa por la derecha de la misma consulta, especificada como:
Reuniones externas en SOL2*
SELECT FROM CHICAS RIGHT OUTER JO IN CHICOS USING (CIUDAD)
El estándar SQL2 proporciona un soporte completo de las reuniones externas usando las mismas cláusulas descritas en la sección anterior para las reuniones internas y palabras clave adicionales. Por ejemplo, la reunión externa completa de las tablas CHICAS y CHICOS (sin las columnas EDAD) se genera con esta consulta:
incluye pares chico/chica y filas que no encajan de la tabla CHICOS (la tabla «derecha» de la reunión), pero no incluye las filas que no encajafl de la tabla CHICAS.
Reuniones cruzadas y reuniones de unión en SOL2*
SELECT FROM CHICAS FULL OUTER JOIN CHICOS ON CHICAS,CIUDAD = CHICOS,CIUDAD
El soporte en SQL2 de reuniones extendidas incluye otros dos métodos para combinar datos de dos tablas. Una reunión cruzada es otro nombre del producto cartesiano de dos tablas, como se describió anteriormente en este capítulo. Una reunión de unión está muy relacionada con la reunión externa completa; sus resultados son un subconjunto de los generados por la reunión externa completa. Aquí hay una consulta SQL2 que genera el producto completo de las tahlas
Como se explicó anteriormente en este capítulo, los resultados de la consulta contendrán 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 también se podría haber escrito como:
CHICAS y CHICOS:
SELECT FROM CHICAS NATURAL FULL OUTER JOIN CHICOS
SELECT FROM CHICAS CROSS JOIN CHICOS
lIII
174
Por definición, el producto cartesiano (a veces denominado producto cruzado. de ahí el nombre CRDSS JOIN, «reunión cruzada» en inglés) 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 selección» asociados con los productos cruzados, así que no se permiten las cláusulas ON y USING. Nótese que la reunión cruzada realmente no añade ninguna nueva capacidad al lenguaje SQL. Se pueden generar exactamente los mismos resultados con una reunión 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 cláusula FROM sólo hace más explícita la reunión cruzada. En la mayoría de bases de datos, la reunión cruzada de dos tablas es por sí misma de muy poco uso práctico. Su utilidad viene realmente como bloque constructor de expresiones de consulta más complejas, que comienzan con el producto cruzado de dos tablas, y después usa las capacidades de las consultas de resumen de SQL2 (descritas en el siguiente capítulo) u operaciones de conjuntos de SQL2 para manipular más los resultados. La reunión de unión en SQLZ combina algunas de las características de la operación UNION (descrita en el capítulo anterior) con algunas de las características de las operaciones de reunión descritas en este capítulo. Recuérdese que la operación UNtaN combina las filas de dos tablas que deben tener el mismo número de columnas y los mismos tipos de datos para las columnas correspondientes. Esta consulta, que usa una operación simple UNION:
tabla. En este aspecto, la reunión de unión 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 reunión de unión es compararlos con ]os resultados de una reunión externa completa de las tablas CHICAS y CHICOS. Los resultados de la reunión de unión 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 definición de la reunión externa de la Figura 7.14, la reunión de unión se produce omitiendo el paso 1 y siguiendo el paso Z y el 3.
FROM CHICOS
Reunión externa por la izquierda
Reunión externa por la derecha
"'" Filas que encajan de TBLl con valores NULL para las columnas de TBL2
"-
Filas ~ue encajan de TBL2 con valores NULL para las columnas de TBLl
Pares de las filas Que no encajan de TBLl/TBL2
Filas que no encajan de TBLl con valores NULL para las columnas de TBL2
V
Filas que no encajan de TBL2 con valores NULL para las columnas de TBLl
Reunión cruzada
Reunión de unión
/ \
1\
y
TBLl 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 unión simple, estos resultados tienen cuatro columnas -todas las columnas de la primera tabla más todas las columnas de la segunda
Pares de las filas coincidentes de TBLl/TBL2
Reunión interna
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 reunión de unión de las tablas CHICAS y CHICOS se especifica con esta consulta SQL2: SELECT FROM CHICAS UNION JOIN CHICOS
'\
Reunión externa completa
SELECT FROM CHICAS UNION ALL
SELECT
175
Capítulo 7: Consultas multitabla (reuniones)
saL. Manual de referencia
(mfitas)
Figura 7.14.
v.' Todos los pares TBLlxTBL2 (m x n filas)
1\
Y'
TBL2 con valores NULL
Relaciones entre los tipos de reunión en SQL2.
(n filas)
1
176
Capitulo 7: Consultas multitabla (reuniones)
SOL. Manual de referencia
tener sólo una de estas filas o ninguna si no hay datos sobre los progenitores del vástago. Las tablas CHICAS, CHICOS Y PROGENITORES proporcionan un rico conjunto de datos para algunos ejemplos de reuniones multitabla. Por ejemplo, supóngase 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 continuación se muestra una consulta que produce la lista:
Finalmente es útil examinar la relación entre los conjuntos de filas producidos por la reunión cruzada, los diferentes tipos de reuniones externas y la reunión 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 reunión cruzada contendrá m x n fiJas. consistentes en todas los pares de filas de las dos tablas. • TBL1 INNER JOIN TBL2 contendrá algún número de filas, f. que es menor que m x n. La reunión interna es estrictamente un subconjunto de la reunión cruzada. Se forma eliminando las filas de la reunión cruzada que no satisfacen la condición de la reunión interna. • La reunión externa por la izquierda contiene todas las filas de la reunión interna más cada fila que no encaje de TBL1, con valores NULL. • La reunión externa por la derecha contiene todas las filas de la reunión interna más cada fila que no encaje de TBL2, con valores NULL. • La reunión externa completa contiene todas las filas de la reunión interna más cada fila que no encaja de TBLl, con valores NULL, más cada fila que no encaja de TBL2, con valores NULL. Grosso modo, sus resultados son iguales a la reunión externa por la izquierda «más» la reunión externa por la derecha. • La reunión de unión contiene todas las filas de TBLl, con valores NULL, más todas las filas de TBL2, con valores NULL. Grosso modo, sus resultados son la reunión externa «menos» la reunión interna.
SELECT FROM ON JOIN ON WHERE
SELECT FROM ON JO IN ON WHERE
CHICAS
CHICAS. NOMBRE, NOMBRE PRO , CHICOS.NOMBRE {(CHICAS LEFT JO IN PROGENITORES PROGENITORES. VÁSTAGO = NOMBRE) CHICOS (CHICAS.CIUDAD : CHICOS.CIUDAD)) (TIPO: "MADRE") OR (TIPO IS NULL)
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 seguirán omitiendo las chicas que no vivan en la misma ciudad que algún chico. Para incluir tam· bién a estas chicas, la segunda reunión también se debe convertir en una reunión externa por la izquierda:
Una ventaja importante de la notación SQL2 es que pennite una .especificación muy clara de las reuniones de tres o cuatro tablas. Para construir estas reuniones más complejas, cualquiera de las expresioñes de reunión mostradas en la Figura 7.1~ y descritas en las anteriores secciones se pueden encerrar entre paréntesis. La expresión de reunión resultante se puede usar por sr mima ·en otra expresión de reunión, como si fuese una simple tabla. Así como SQL permite combinar opera· ciones matemáticas (+, -, * y !) con paréntesis y construir expresiones más complejas, el estándar SQL2. permite construir expresiones de reunión más complejas del mismo modo. Para ilustrar las reuniones multitabla asúmase que se ha añadido 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: Coincide con la columna NOMBRE de las tablas TIPO Especifica PADRE o MADRE Nombre de pila del progenitor NOMBREPRO
Dado que ambas reuniones son internas, cualquier chica que no tenga algún 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 debería cambiar la reunión entre las tablas CHICAS y PROGENITORES en una reunión externa por la izquierda, como ésta:
Reuniones multitabla en SOL2
VÁSTAGO
177
SELECT FROM ON LEFT ON WHERE
CHICAS.NOMBRE, NOMBREPRO, CHICOS.NOMBRE {(CHICAS LEFT JO IN PROGENITORES PROGENITORES. VÁSTAGO = NOMBRE) JOIN CHICOS (CHICAS.CIUDAD : CHICOS.CIUDAD» (TIPO: "MADRE") OR {TIPO IS NULLI
Nótese que la extensión con valores NULL de las filas de la tabla CHICAS de la reunión externa con sus madres también crea alguna complicación adicional en la cláusula WHERE. Las chicas sin madres coincidentes generarán filas no sólo con el nombre de la madre con valor NULL (NOMBREPRO), sino también un valor NULL en la columna TIPO. El criterio simple de selección:
y CHICOS
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
WHERE (TIPO: -MADRE")
•
178
Capítulo 7: Consultas mu/titabla (reuniones)
SOL. Manual de referencia
generaría un resultado «desconocido» para estas filas y no se incluirían en los resultados. i Pero la razón de usar la reunión externa por la izquierda fue asegurarse de que se incluyesen! Para resolver este problema la cláusula WHERE se expande para comprobar también las filas en las que el tipo de progenitor es NUL~. Como ejemplo final supóngase 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 reunión de cuatTo tablas (CHICOS. CHICAS Y dos copias de la tabla PROGENITORES, una para reunir con la información de los chicos los nombres de los padres, y otra para reunir la información 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. Supóngase, 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 reunión PROGENITORES) y (CHICAS reunión PROGENITORES) de la consqlta, pero una reunión interna para la parte (CHICOS reunión 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 ({VÁSTAGO = CHICAS.NOMBRE) ANO (TIPO = -MADRE"))) JO IN (CHICOS LEFT JOIN PROGENITORES AS PADRES ON ((VÁSTAGO = CHICOS.NOMBRE) ANO (TIPO = "PADRE")))) USING (CIUDAD)
Esta consulta resuelve el problema del test de la cláusula WHERE de forma diferente -trasladando el test sobre el TIPO de progenitor a la cláusula ON de la especificación de la reunión. De este modo, el test para el TIPO apropiado de progenitor se realizará cuando el SGBD encuentre columnas coincidentes para construir la reunión, antes de que se añadan las filas con valores NULL a los resultados de la reunión externa. Dado que la tabla PROGENITORES se usa dos veces en la cláusula FRDM, con dos papeles diferentes, es necesario dar dos alias de tabla diferentes para especificar correctamente los nombres en la lista de selección. 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 ambigüedad acerca del orden en que se reúnen las tablas, o sobre cuáles son las reuniones internas o externas. En resumen, la capacidad añadida compensa la complejidad introducida por la cláusula FROM de SQL2. Aunque ninguno de los ejemplos de las consultas incluidos en esta sección tengan cláusulas WHERE u ORDER BY, se pueden usar libremente con la cláusula FROM extendida en SQL2. La relación entre las cláusulas es simple y permanece como se describió antes en este capítulo. El procesamiento especificado en una cláusula USING u DN se aplica como parte de una especificación particular de la
179
reunión en la que aparecen. Cuando se completa el procesamiento de la cláusula selección en la cláubúsqueda que se aplica a reuniones específicas; la cláusula WHERE especifica el criterio de búsqueda 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 cláusula ON especifica el criterio de
Resumen En este capítulo se ha descrito la forma en que SQL maneja las consultas que combinan datos de dos o más tablas: • En una consulta multitabla (una reunión), las tablas que contienen los datos se listan en la cláusula FROM. • Cada fila de resultados es una combinación de datos de una única fila de cada tabla y es la única fila que obtiene sus datos de una combinación particular. • Las consultas multitabla más comunes usan la relación padre/hijo creada por las claves primarias y las claves externas. • En general, las reunión se puede construir comparando cualquier par de columnas de las dos tablas reunidas, usando un test de igualdad o cualquier otro test de comparación. • Se puede pensar que una reunión 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 reunión (interna) estándar 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 estándar SQL2 proporciona un soporte completo para las reuniones internas y externas, y para la combinación de resultados de reuniones con otras operaciones multitabla, como las uniones, intersecciones y diferencias.
'i
CAPíTULO
8
Consultas de resumen
~
Muchas solicitudes de información no requieren el grado de detalle proporcionado por las consultas SQL descritas en los dos últimos capítulos. Por ejemplo, cada una de las siguientes solicitudes piden un único valor o un pequeño número de valores que resumen los contenidos de la base de datos: • • • • • •
¿Cuál es la cuota total de todos los representantes? ¿Cuáles son la mayor y menor cuotas asignadas? ¿Cuántos representantes exceden su cuota? ¿Cuál es el importe de un pedido medio? ¿Cuál es el importe del pedido medio de cada oficina de ventas? ¿Cuántos representantes están asignados a cada oficina .de ventas?
SQL alberga estas solicitudes de datos ~e resumen mediante funciones de columna y las cláusulas GROUP BY y HAVING de la instrucción SELECT, que se describen en este capítulo.
Funciones de columna SQL permite resumir los datos de la base de datos mediante un conjunto de funciones de columna. Una función 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 función de columna AVG () toma una columna de datos y calcula su media. A continuación se muestra una consulta que usa la función de columna AVG () para calcular el valor medio de dos columnas de la tabla REPRESENTANTES:
¿ Cuál 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
I
I I 1"
La Figura 8. J muestra gráficamente cómo se producen los resultados de la consulta. La primera funcjón 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:
SOt1.
I---AVG
Nombre-de-columna-l
(-r Expresión LDISTINCT
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 número de valores de una columna. • COUNT ( *) cuenta las filas de los resultados. •
(LEXpresión---------. J DISTINCT
1,"
i,
183
Capítulo 8: Consultas de resumen
SOL. Manual de referencia
Nombre-de-COlumna"J)
1--- MIN
(Expresión)J------------------.I
1--- MAX
{Expresión)I-----------.:---.:------->!
SUM ()
• AVG ()
COUNT
(T
3- Nombre-de-columna DISTINCT
El argumento de una función de columna puede ser simplemente un nombre de columna, corno en el ejemplo anterior, o puede ser una expresión SQL, como se muestra a continuación:
COUNT
('J
-----------------..1
¿ Cuál es el rendimiento medio de la cuota de nuestros representantes?
• Figura 8.2.
Diagrama sintáctico de las funciones de columna.
Tabla REPRESENTANTES NUM EMPLE NOMBRE
105 109 102 106 104 101 110 108 103 107
I l' I
l',!
r! 1
Bruno Arteaga María Jiménez Susana Santos Samuel Clavel Bernardo Sánchez Daniel Ruidrobo Tomás Saz León Freire Pablo Cruz Neus Azcárate
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 expresión {lOO * (VENTAS/CUOTA}) para cada fila de la tabla REPRESENTANTES y después calcula las medias de la columna temporal.
,
Cálculo del total de una columna
I l'
La función de columna SUM () calcula la suma de los valores de datos de una columna. Los datos de la columna deben tener un tipo numérico (entero, decimal, coma flotante o moneda). El resultado de la función SUM () tiene el mismo tipo de datos básico que los datos de la columna, pero el resultado puede tener mayor precisión. Por ejemplo, si se aplica la función SUM () a una columna de enteros de 16 bits, se puede producir un entero de 32 bits como resultado. A continuación se muestran varios ejemplos que usan la función de columna
1',
300.000,OO€
Figura 8.1.
Operación de una consulta de resumen.
298.253,20€
SUM{}:
(SUM)
184
SQL. Manual de referencia
Capítulo 8: Consultas de resumen
¿ Cuáles son las cuotas y ventas tolales de lOdos los representantes? SELECT SUM(CUOTA). SUM(VENTAS) FROM REPRESENTANTES SUM{CUOTA)
SUM(VENTAS)
2.700.000,00 2.893.532.00€
¿ Cuál es el 10tal de los pedidos de Bruno Arteaga?
ij
I n
I I
SELECT SUM(IMPORTE) FROM PEDIDOS, REPRESENTANTES WHERE NOMBRE = 'Bruno Arteaga' AND REP = NUM_EMPL
Búsqueda de valores extremos
(MIN
y
185
MAX)
Las funciones de columna MIN () y MAX () hallan respectivamente los valores menor y mayor de una columna. Los datos de la columna pueden contener información numérica, de cadena o de fecha y hora. El resultado de la función MIN () O MAX () tiene exactamente el mismo tipo de datos que los datos de la columna. A continuación hay algunos ejemplos que muestran el uso de estas funciones de columna: ¿ Cuáles
SO"
las cuotas mayor y menor asignadas?
SELECT MIN(CUOTA) , MAX(CUOTA) FROM REPRESENTANTES
SUM(IMPORTE) HIN/CUOTA) HAX(CUOTA) 39.327,OO€
200.000,00€ 350.000,OO€
Cálculo de la media de una columna
(AVG)
La función de columna AVG () calcula la media de una columna. Como con la· función SUM ( ) • los datos de la columna deben tener un tipo numérico. Dado que la función AVG () suma los valores de la columna y después lo divide por el número de valores, su resultado puede tener un tipo de datos diferente del de los valores de la columna. Por ejemplo, si se aplica la función AVG () a una columna de enteros, el resultado puede ser un número decimal o en coma flotante. dependiendo del SGBD que se esté usando. A continuación se muestran algunos ejemplos de la función de columna AVG (): Calcular el precio medio de los productos del fabricante AC/.
¿ Cuál es la fecha más antigua de
UIl
pedido en la base de datos?
SELECT MIN(FECHA_PEDIDO) FROM PEDIDOS MIN(FECHA_PEDIDO) 04-ENE-S9
¿ Cuál es el mejor rendimiento en ventas de los representantes? SELECT MAX(lOO • (VENTAS/CUOTA)) FROM REPRESENTANTES MAX(100*IVENTAS!CUOTA))
SELECT AVG(PRECIO) FROM PRODUCTOS WHERE ID_FAS = 'ACI' AVG(PRECIO) S04,29€
Calcular el importe medio de los pedidos de Acme (número de cliente 21.03). SELECT AVG(IMPORTE) FROM PEDIDOS WHERE CLIENTE = 2103 AVG(IMPORTE) 8.895,50€
135,44
Cuando las funciones de columna MIN () Y MAX () se aplican a datos numéricos, SQL compara los número en orden algebraico (los números grandes negativos son menores que los números pequeños negativos, que son menores que cero, el cual es a su vez menor que todos los números positivos). Las fechas se comparan secuencialmente (las fechas anteriores son menores que las posteriores). Al usar HIN () Y MAX () con datos de cadena. la comparación 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 dígitos vienen antes que las letras en la secuencia de ordenación, y todos los caracteres en mayúscula vienen antes de los caracteres en minúscula. En los grandes sistemas (mainframe) de IBM, que usan el conjunto de caracteres EBCDIC, los caracteres en minúscula preceden a los caracteres en mayúscula. y los dígitos vienen des-
186
SOL. Manual de referencia
Capítulo 8: Consultas de resumen
pués de las letras. A continuación se muestra una comparación de las secuencias de ordenación de ASCII y EBCDIC de una lista de cadenas, de las menores a las mayores: ASCII
EBCDIC
1234ABC
acme mfg.
5678ABC
zet.a carpo
ACME MFG. Acrne Mfg.
Acme Mfg.
ZETA Zeta acme zeta
Zeta Carpo
CQRP. Carpo mEg. carpo
187
¿ Cuántos representantes exceden su cuota? SELECT COUNT(NOMBRE} FROM REPRESENTANTES WHERE VENTAS > CUOTA COUNT(NOMBRE} 7
ACME MFG.
¿Cuántos pedidos de más de 25.000- están registrados?
ZETA CORP.
1234ABC 5678ABC
La diferencia en las secuencias de ordenación significa que una consulta con una cláusula ORDER BY puede producir diferentes resultados en dos sistemas diferentes. Los caracteres internacionales plantean problemas adicionales (por ejemplo,
los caracteres acentuados en francés, alemán, español, italiano, o las letras del alfabeto cirílico usados en griego y ruso, O los símbolos kanji usados en japonés). Algunas marcas de SOBD usan algoritmos de ordenación internacional especiales para ordenar estos caracteres en su posición correcta en cada lenguaje. Otros simplemente los ordenan de acuerdo con el valor numérico del código asignado al carácter. Para manejar estos aspectos, el estándar SQL2 incluye un soporte elaborado para los conjuntos de caracteres nacionales, conjuntos de caracteres definidos por el usuario y secuencias de ordenación alternativas. Desafortunadamente, el soporte de estas características de SQL2 varía ampliamente entre diferentes productos SGBD populares. Si una aplicación maneja texto internacional se debe experimentar con el SGBD particular para determinar cómo s-e manejan estos caracteres. .
SELECT COUNT(IMPORTE) FROM PEDIDOS WHERE IMPORTE> 25000.00 COUNT (IMPORTE) 4
Nótese que la función COUNT () ignora los valores de Jos elementos de datos de la columna; simplemente cuenta cuántos elementos de datos hay. Como resultado, no importa realmente la columna que se especifique como argumento de la función COUNT ( ). El último ejemplo se podría haber escrito simplemente como: SELECT COUNT (NUM_PEDIDO) FROM PEDIDOS WHERE IMPORTE> 25000.00
4
Recuento de valores de datos
(COUNT)
La función de columna COUNT () cuenta el número de valores de datos de una columna. Los datos de la columna pueden ser de cualquier tipo. La función COUNT ( ) siempre devuelve un entero, independientemente del tipo de datos de la columna. A continuación se muestran varios ejemplos de consultas que usan la función de columna COUNT ( 1: ¿ Cuántos clientes hay? SELECT COUNT(NUM_CLI) FROlo1 CLIENTES
21
De hecho, es difícil pensar en la consulta como «contar los importes de pedidos» o «contar los números de pedido»; es mucho más fácil pensar cómo «contar los pedidos». Por esta razón, SQL alberga una función de columna especial, CQUNT (* ) , que cuenta filas en lugar de valores de datos. A continuación se muestra la misma consulta, reescrita de nuevo esta vez con la función COUNT (*) : SELECT COUNT(*) FROM PEDIDOS WHERE IMPORTE> 25000.00 COUNT(*) 4
Si se piensa en la función COUNT (*) como una función de «recuento de filas», esto hace que la consulta sea más fácil de leer. En la práctica, la función COUNT ( * ) se usa casi siempre en lugar de la función CQUNT () para contar filas.
Las consultas simples con una función de columna en su lista de selección son muy fáciles de comprender. Sin embargo. cuando la lista de selección incluye varias funciones de columna, o cuando el argumento de una función de columna es una expresión compleja, la consulta puede ser difícil de l~er y comprender. Los siguientes pasos muestran las reglas del procesamiento de consultas SQL expandido una vez más para describir cómo se manejan las funciones de columna. Como antes, las reglas están pensadas para proporcionar una d.efinición precisa de lo que significa una consulta, no una descripción de cómo resuelve realmente el SGBD los resultados de la consulta. Para generar los resultados de una consulta de una instrucción SELECT:
8.256.37€
247.69l.00€
(lOO'AVa (IMPORTE/CUOTA) ) 2,51
24,4:>
Sin las funciones de columna, sería: SELECT IMPORTE, IMPORTE, IMPORTE/LIMITE_CREDITO, FROM PEDIDOS, CLIENTES, REPRESENTANTES WHERE CLIENTE = NUM_CLI AND AND REP = NUM_EMPL
IMPORTE/CUOTA
y produciría 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 función de columna puede aparecer en la lista de selección en cualquier lugar en que pueda aparecer un nombre de columna. Por ejemplo, puede ser parte de una expresión que sume o reste los valores de dos funciones de columna. Sin embargo, el argumento de una función de columna no puede contener otra función de columna, porque la expresión resultante no tiene sentido. Esta regla se conoce a veces como «es ilegal anidar las funciones de columna». También es ilegal mezclar funciones de columna y nombres de columnas normales en una lista de selección, de nuevo porque la consulta resultante no tendría sentido. Por ejemplo, considérese esta consulta: SELECT NOMBRE, SUH(VENTAS) FROM REPRESENTANTES
El primer elemento de selección 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 razón, o todas las referencias a columna de la lista de selección aparecen en el argumento de una función de columna (produciendo una consulta de resumen), o la lista de selección no contiene ninguna función de columna (produciendo una consulta detallada). Realmente. la regla es un poco más compleja cuando se consideran las consultas agrupadas y las subconsultas. Los refinamientos necesarios se describen más adelante en la sección «Condiciones de búsqueda de grupos».
ALL. ORDER BY,
il89
AVG(IHPORTE/LIHITE_CREOITO)),
AVG (IMPORTE) SUM (IMPORTE) (100' AVG (IMPORTE/LIMITE_CREOITO))
l. Si la instrucción 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 cláusula FROM. Si la cláusula FRQM lista una única tabla, el producto es esta tabla. 3. Si hay una cláusula WHERE, aplicar su condición de búsqueda a cada fila de la tabla producto, conservando las filas para las que la condición de búsqueda es TRUE (y descartando aquellas para las que la condición es FALSE o NULL). 4. Para cada fila restante, calcular el valor de cada elemento de la lista de selección 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 función 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 instrucción 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 7. Si hay una cláusula se especifique.
I
Capítulo 8: Consultas de resumen
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 habría que imaginar cómo funcionaría la consulta sin las funciones de columna, produciendo muchas filas de resultados detallados. Después habría que imaginar a SQL aplicando las funciones de columna sobre los resultados detallados. produciendo una única fila de resumen. Por ejemplo, considérese la siguiente consulta compleja:
Valores
Hallar el importe medio de los pedidos. ellolal de los importes, la media de los impories de los pedidos como un porcenlaje dellímile de crédilo del cliente, y el imporle medio de los pedidos como un porcemaje de la cuota del represemallle.
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
Capítulo 8: Consultas de resumen
SOL. Manual de referencia
como resultado. ¿Qué ocurre si uno o más de los valores de datos de la columna es un valor NULL? El estándar SQL de ANSI/ISO especifica que los valores NULL de la columna se ignoran por las funciones de columna. Esta consulta muestra cómo la función COUNT () ignora los valores NULL de una columna: SELECT COUNT{*), COUNT(VENTAS) , COUNT(CUOTA) FROM REPRESENTANTES COUNT(*)
COUNT(VENTAS}
10
10
La tabla
COUNT(CUOTA)
contiene diez filas, así que COUNT (*¡ devuelve un recuento de diez. La columna VENTAS contiene diez valores que no son NULL, así que la función COUNT (VENTAS) también devuelve un recuento de diez. La columna CUOTA es NULL para el último representante contratado. La función COUNT (CUOTA) ignora este valor NULL y devuelve un recuento de nueve. A causa de estas anomalías, la función COUNT (*) se usa casi siempre en Jugar de COUNT ( ) , a menos que se desee excluir explícitamente 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:
SUM(VENTAs) sUM(CUOTA}
(SUM!VENTAS)
-
SUM(CUOTA)),
SUM(VENTAs-CUOTA)
(SUM(VENTAS)-SUM(CUOTA))
sUM(VENTAS-CUOTA)
193.532,OO€
117.547,OO€
2.893.532,OO€ 2.700.000,OO€
Se esperaría que las dos expresiones: (SUM(VENTAS)
-
SUM(CUOTA)) y
sUM(VENTAS¡
resume el total de ventas de los diez representantes, mientras que la expresión: SUH(CUOTA)
resume el tata] de ventas de sólo los nueve valores de cuota que no son NULL. La expresión: -
SUM(CUOTA)
calcula la diferencia de estas dos cantidades. Sin embargo, la función de columna: SUM(VENTAS-CUOTA)
• Si alguno de los valores de datos de una columna es NULL, se ignora para el propósito del cálculo del valor de una función de columna. • Si cada elemento de datos de la columna es NULL, entonces SUM (), AVG (), MIN () y MAX () devuelven un valor NULL; la función COUNT () devuelve el valor cero. • Si no hay elementos de datos en la columna (es decir, la columna está vacía). entonces las funciones de columna SUM (1, AVG (), MIN () Y MAX () devuelven el valor NULL; la función 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 estándar es muy claro en esta área, los productos comerciales SQL pueden producir resultados diferentes del estándar, especialmente si todos los valores de datos de una columna son NULL o cuando una función de columna se aplica a una tabla vacía. Antes de asumir el comportamiento especificado por el estándar se debería contrastar con el SGBD que se use.
Eliminación de filas duplicadas
(DISTINCT)
SUM{VENTAS-CUOTA)
de la lista de selección produjesen resultados idénticos, pero el ejemplo muestra que no lo hacen. El representante con un valor NULL en la columna CUOTA es de nuevo la razón. La expresión:
SUM(VENTAS)
tiene un valor del argumento distinto de NULL sólo 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 función SUM ( ) . Por tanto, las ventas del representante sin cuota, que se incluyen en el cálculo anterior, se excluyen en este cálculo. ¿Cuál es la respuesta «correcta»? ¡Las dos! La primera expresión calcula exactamente lo que dice: «la suma de VENTAS, menos la suma de CUOTA». La segunda expresión también calcula exactamente 10 que dice: «la suma de (VENTAS-CUOTA)>>. Sin embargo, cuando aparecen valores NULL, los dos cálculos no son el mismo. El estándar ANSI/ISO especifica estas reglas precisas para el manejo de valores NULL en las funciones de columna:
9
REPRESENTANTES
SELECT SUM (VENTAS 1 , SUM(CUOTA), FROM REPRESENTANTES
191
Recuérdese del Capítulo 6 que se puede especificar la palabra clave DISTINCT al principio de la lista de selección para eliminar filas duplicadas de resultados. También se puede pedir a SQL que elimine valores duplicados de una columna antes de aplicarle una función de columna. Para eliminar valores duplicados, se incluye la palabra clave DISTINCT antes del argumento de la función de columna, inmediatamente después del paréntesis de apertura. A continuación se muestran dos consultas que ilustran la eliminación de filas duplicadas en las funciones de columna: ¿ Cuántos puestos diferentes tienen los representantes? SELECT COUNT{DISTINCT PUESTO} FROM REPRESENTANTES COUNT{DISTINCT PUESTO) 3
192
SOL. Manual de referencia
Capítulo 8: Consultas de resumen
¿ Cuántas oficinas de ventas tienen representalltes que superen sus cuolas?
193
¿ Cuál es el importe medio de los pedidos de cada representante? SELECT REP, AVG(IMPORTE) FROM PEDIDOS GRQUP BY REP REP AVG(IMPORTE)
5ELECT COUNT(DISTINCT OFICINA_REPI FROM REPRESENTANTES WHERE VENTAS > CUOTA
El estándar SQLl especifica que cuando se use la palabra clave DISTINCT, el argumento de la función de columna debe ser un nombre simple de columna; no puede ser una expresión. El estándar permite la palabra clave DISTINCT en las funciones de columna SUM () y AVG (). El estándar 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 estándar también 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 función COUNT (1<) porque no trata en absoluto con una columna de valores de datos simplemente cuenta filas. El estándar 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. Además, la palabra clave D1ST1NCT se puede especificar sólo una vez en una consulta. Si aparece en el argumento de una función de columna, no puede aparecer en ninguno otro. Si se especifica antes de la lista de selección, no puede aparecer en ninguna de las funciones de columna. La única excepción es que D1STINCT se puede especificar una segunda vez dentro de una subconsulta (contenida dentro de la consulta). Las subconsultas se describen en el Capítulo 9.
La primera consulta es una simple consulta de resumen, como en los ejemplos anteriores de este capítulo. La segunda consulta produce varias filas de resumen una fila por cada grupo, resumiendo los pedidos de cada representante. La Figura 8.3 muestra cómo funciona la segunda consulta. Conceptualmente, SQL resuelve la consulta como sigue:
w
Consultas de agrupación (cláusula
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
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 cláusula GROUP BY de la instrucción SELECT proporciona esta capacidad. La función de la cláusula GROUP BY se comprende más fácilmente mediante un ejemplo. Considérense estas dos consultas:
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 cláusula GROUP BY se denomina consulta de agrupación 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 agrupación de la consulta, porque determman cómo se d¡Vlden las filas en grupos. A continuación se muestran ejemplos adicionales de consultas de agrupación:
¿ Cuál es el rango de las cuotas asignadas en cada oficina? SELECT OFICINA_REP, MIN(CUOTA), FROM REPRESENTANTES GROUP BY OFICINA_REP
Si la instrucción 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 cláusula FROM. Si la cláusula FROM lista una única tabla, el producto es esta tabla. Si hay una cláusula WHERE, aplicar su condición de búsqueda a cada fila de la labia producto, conservando las filas para las que la condición de búsqueda es TRUE (y descanando aquellas para las que la condición es FALSE
o NULL). 4.
OFICINA_REP COUNT{*) 1
2 3 1
2 1
¿ Cuántos clientes diferentes atiende cada representante? •clientes del representante'. REP _eLI
Si hay una cláusula GROUP BY, organizar las filas restantes de la tabla producto en dos grupos. de forma que las filas de cada grupo tengan idénticos valores en todas las columnas de agrupación. 5. Si hay una cláusula HAVING, aplicar su condición de búsqueda a cada grupo de filas, conservando los grupos para los que la condición de búsqueda es TRUE (y descartando aquellos para los que la condición es FALSE o NULL). 6. Para cada fila restante (o grupo de filas), calcular el valor de cada elemento de la lista de selección 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 función 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 instrucción 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.
COUNT{DISTINCT NUM_CLI) CLIENTES DEL REPRESENTANTE REP_CLI 3 clientes del representante 4 clientes del representante
del del del del
Hay un vínculo íntimo entre las funciones de columna SQL y la cláusula GROUP Recuérdese que las funciones de columna toman una columna de valores de datos y producen un único resultado. Cuando está presente la cláusula GROUP BY, dice a SQL que divida los resultados detallados en grupos y que aplique la función 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 agrupación. Para generar los resultados de una consulta de una instrucción SELECT:
2.
SELECT OFICINA_REP, COUNT(*) FROM REPRESENTANTES GROUP BY OFICINA_REP
SELECT COUNT (DISTINCT NUM_CLII, FROM CLIENTES GROUP BY REP_CLI
clientes clientes clientes clientes
BY.
l.
¿ Cuántos representantes están asignados a cada oficina?
NULL 11 12 13 21 22
3 1 2 2
195
101 102
9.
Si hay una cláusula se especifique.
ORDER BY,
ordenar los resultados de la consulta como
Las filas generadas por este procedimiento forman los resultados de la consulta.
196
SOL. Manual de referencia
Capítulo 8: Consultas de resumen
Agrupación de múltiples columnas
210S 210S 2109 2111 2111
SQL puede agrupar los resultados de la consulta en términos de los contenidos de dos o más columnas. Por ejemplo, supóngase que se desean agrupar los pedidos por representante y por cliente. Esta consulta agrupa los datos basándose en ambos criterios: Calcular los pedidos totales para cad~ cliente de cada representante. SELECT REP, CLIENTE,
GROUP BY REP, CLIENTE REP CLIENTE SUMIIMPQRTE) 2102 2108 2113
2106
3.978,OO€ 150,OO€ 22.S0Q,QO€
2120
4.026.00€ 15.000,OO€ 3.750,OO€
2111
2.700,OO€
2103
35.582,OO€
2111
3.745.00€
2114
150,00€ 7.10S,OO€ 31.3S0,O€. 2.700,0€· 3.745,O€.
Nótese que también 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 aplicación que use SQL para programación y calcular los subtotales en la lógica del programa. Los desarrolladores originales de SQL Server trataron esta limitación de SQL estándar añadiendo una cláusula COMPUTE opcional al final de la instrucción SELECT. La cláusula COMPUTE calcula los subtotales y los sub-subtotales, como se muestra en este ejemplo:
SUM(IHPORTE)
FROM PEDIDOS
101 101 101 102 102 102 103 105 105
101 109 107 103 105
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
Incluso con varias columnas de agrupación, SQL proporciona s610 un único nivel de agrupación. 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 cláusula GROUP BY tendrá automáticamente el efecto colateral de ordenar los datos, pero se puede omitir esta ordenación con una cláusula ORDER BY, como se muestra a continuación:
REP CLIENTE 101
IMPORTE
2102
3.978,OO€
sum 3 _978, OO€:
REP CLIENTE 101
Calculflr el total cf..e los pedidos de cada cliente de cada representante, ordenados por cliente y, dentro de cada cliente, por representante"
IMPORTE
2108
150,00€
sum 150,OO€:
SELECT FROM GROUP ORDER
CLIENTE, REP, SUM(IMPORTE) PEDIDOS BY CLIENTE, REP BY CLIENTE, REP
REP CLIENTE
IMPORTE
-- - -- - - ----.- --- --- - - - --101
2113
22.S00,OO€
sum CLIENTE REP SUM(IMPORTE) 22.500,OO€: 2101 2102· 2103 2106 2107
106 101 105 102 110
197
surn
1.4SB,OO,€
3.97B,OO€: 35. SB2, OO€: 4.026,OO€: 23.132,OO€:
26.628,OO€ avg
S.B76,OO€
..
Capitulo 8: Consultas de resumen
SOL. Manual de referencia
198
También hay restricciones sobre los elementos que pueden aparecen en la lista de selección de una consulta de agrupación. Todos los elementos de la lista de selección deben tener un único valor para cada grupo de filas. Básicamente, esto significa que un elemento de selección de una consulta de agrupación puede ser:
IMPORTE
REP CLIENTE
------------ --------2.130,oaE:
102
2106
102
2106
199
1.896.00€
,uro
• Una constante • Una función de columna, que produce un único valor resumiendo las filas del grupo • Una columna de agrupación, que por definición tiene el mismo valor en cada fila del grupo • Una expresión que contenga combinaciones de lo anterior
En la práctica, una consulta de agrupación siempre incluirá tanto una columna de agrupación como una función de columna en la lista de selección. Si no aparece ninguna función de columna, la consulta se puede expresar de forma más sencilla usando SELECT DISTINCT, sin GROUP BY. A la inversa, si no se incluye una columna de agrupación en los resultados, ¡no será posible decir qué fila de los resultados vienen de qué grupo! Otra limitación de las consultas de agrupación es que SQL ignora la información sobre las claves primarias y las externas al analizar la validez de una consulta de agrupación. Considérese esta consulta:
IMPORTE
REP CLIENTE
----------- ------------3.750,OO€ 102
2120
suro 3.150.00€
,uro 22.776.00€ avg
5.694,QO€
Calcular el total de los pedidos de cada representante.
La consulta proct!.lce una fila de resultados por cada fila de la tabla PEDIDOS,
ordenados pur
CLIENTE
dentro de
REP.
Además, calc~la 1~ suma de los
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 cláusula COMPUTE no es nada estándar, y de hecho ~s ~~lca en .el dIalecto Transact-SQL usado en SQL Server. Además, viola los prInCIpIOS báslcos de las consultas relacionales porque los resultados de la instrucción SELECT no son una tabla, sino una combinación extraña de diferentes tipos de filas. No obstante, como muestra el ejemplo, puede ser muy útil.
Restricciones sobre las consultas de agrupación Las consultas de agrupación son sujeto de algunas limitaciones ~lgo estrictas. Las columnas de agrupación deben ser columnas reales de las tablas h~tadas en la cláusula FROM ·de la consulta. No se pueden agrupar las filas en térmmos del valor de una expresión calculada.
SELECT FROM WHERE GROUP
NUM_EMPL, NOMBRE, SUM(IMPORTE) PEDIDOS, REPRESENTANTES REP = NUM_EMPL BY NOM_EMPL
Error: «NOMBRE» no es una expresión GROUP BY
Dada la naturaleza de los datos, la consulta tiene perfectamente un buen sentido porque la agrupación del número de empleado de un representante es de hecho la misma agrupación que sobre el nombre del representante. Más precisamente, la columna de agrupación 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 explícitamente como columna de agrupación. Para corregir el problema se incluye simplemente la columna NOMBRE como una segunda columna de agrupación (redundante):
Calcular el total de los pedidos de cada representante. SELECT FROM WHERE GROUP
NUM_EMPL, NOMBRE, SUM(IMPORTE) PEDIDOS, REPRESENTANTES REP = NUM_EMPL BY NUM_EMPL, NOMBRE
Capítulo 8: Consultas de resumen
SOL. Manuaf de referencia
200
SUM (IMPORTE)
NUM_EHPL NOMBRE
-------------------------------------26.628,OO€ 101 Daniel Ruidrobo 102 Susana Santos
103 Pablo Cruz
105 106 107 lOa 109
Bruno Arteaga Samuel Clavel Neus Azcárate León-Freire María Jiménez
Por supuesto, si el número de empleado del representante no se necesita en los resultados de la consulta, se puede eliminar completamente de la lista de selección, dando:
Valores NULL en las consultas de agrupación Un valor NULL plantea un problema esp~cial cuando aparece en una columna de agrupación. Si el valor de la columna es desconocido, ¿en qué grupo se deberla situar la fila? En la cláusula 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 cláusula GROUP BY forzaría que SQL reemplazase cada fila con una columna de agrupación NULL en un grupo separado por sí mismo. En la práctica, esta regla no es muy útil. En su lugar, el estándar SQL de ANSI/ ISO SQL considera que dos valores NULL son iguales para los propósitos de la cláusula GROUP BY. Si dos filas tienen valores NULL en las mismas columnas de agrupación" e idénticos valores en todas sus columnas de agrupación con valbres diferentes de NULL, se agrupan en el mismo grupo de filas. La pequeña tabla de
Figura 8.4.
La tabla PERSONAS.
el
ejemplo de la Figura 8.4 ilustra manejo de ANSI/ISO de los valores cláusula GROUP BY, como se muestra en esta consulta:
NULL
en la
SELECT PELO, OJOS. COUNT(*) FROM PERSONAS GROUP BY PELO. OJOS PELO
OJOS COUNT(*)
Marrón NULL NULL Marrón Marrón Marrón
Azul Azul NULL NULL Marrón Marrón
1
2
2 3 2 2
Aunque este comportamiento de los valores NULL en la agrupación de columnas está especificado claramente en el estándar ANSI/ISO, no está implementado en todos los dialectos de SQL. Conviene construir una pequeña tabla de test y comprobar el comportamiento de cada SGBD en particular antes de confiar en ningún comportamiento específico.
Condiciones de búsqueda de grupos (cláusula HAVING) Al igual que la cláusula ~IHERE se puede usar para seleccionar y descartar las filas individuales que participan en una consulta, la cláusula HAVING se puede usar para seleccionar y descartar los grupos de filas. El formato de la cláusula HAVING es paralelo al de la cláusula WHERE, que consiste en la palabra clave HAVING seguida de una condición de búsqueda. La cláusula HAVING especifica así una condición de búsqueda para grupos.
Capítulo 8: Consultas de resumen
202
SOL. Manual de referencia
203
Las condiciones de búsqueda que se pueden especificar en la cláusula HAVING son las mismas que las usadas en la cláusula WHERE, como se describió en los capítulos 6 y 9. A continuación se muestra otro ejemplo del uso de una condición de búsqueda de grupos:
Un ejemplo proporciona la mejor forma de comprender el papel de la cláusula HAVING. Considérese esta consulta: ¿Cuál es eL importe medio de fas pedidos de cada representante los cuyos pe· didas superan los 30.000 €?
Para cada oficina con dos O más personas, calcular la cuota total y las ventas totales para lodos los representantes que trabajan en ella.
5ELECT RE?, AVG(IHPORTEI PROM PEDIDOS
GROO? BY RE? HAVING SUM(IMPORTE}
>
30000.00
REP AVG(IMPORTE) 105 106 107 108
, i
7.865. 40€ 16.479, oo€ 1l.477,33€ 8.376,14€
SELECT FROM WHERE GROUP HAVING
CIUDAD, SUM(CUOTA) , SUM (REPRESENTANTES, VENTASJ OFICINAS, REPRESENTANTES OFICINA ~ OFICINA_REP BY CIUDAD COUNT(*) >= 2
La Figura 8.5 muestra gráficamente cómo resuelve SQL la consulta. La cláusula GROUP BY organiza primero los pedidos en grupos por represent~nte. La cláusula HAVING elimina después cualquier grupo donde el total de los pedid.os en el gru~o no exceda los 30.000 €. Finalmente. la cláusula SELECT calcula el Importe medIO de los pedidos para cada grupo restante y genera los resultados de la consulta.
Los siguientes pasos muestran las reglas para el procesamiento de consultas SQL, expandidos de nuevo para incluir las condiciones de búsqueda de grupos. Para generar los resultados de una consulta de una instrucción SELECT: 1.
Si la instrucción 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 cláusula FROM. Si la cláusula FROM lista una única tabla, el producto es esta tabla. Si hay una cláusula WHERE, aplicar su condición de búsqueda a cada fila de la tabla producto, conservando las filas para las que la condición de búsqueda es TRUE (y descartando aquellas para las que la condición es FALSE o NULL). Si hay una cláusula GROUP BY, organizar las filas restantes de la tabla producto en dos grupos, de forma que las filas de cada grupo tengan idénticos valores en todas las columnas de agrupación. Si hay una cláusula HAVING, aplicar su condición de búsqueda a cada grupo de filas, conservando los grupos para los que la condición de búsqueda es TRUE (y descartando aquellos para los que la condición es FALSE o NULL).
6.
< 7.
Funcionamiento de una condición de búsqueda de grupos.
..
Para cada fila restante (o grupo de filas), calcular el valor de cada elemento de la lista de selección 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 función 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.
204
Capítulo 8: Consultas de resumen
SOL. Manual de referencia
8.
Si la instrucción 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
5. 6.
205
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.
ALL.
9.
Si hay una cláusula se especifique.
QRDER BY.
ordenar los resultados de la consulta como
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.
2. 3.
4.
Reúne 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 cláusula HAVING. Calcula la cuota total y las ventas totales para cada grupo.
A continuación se muestra otro ejemplo más, que usa todas las cláusulas de la instrucción 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
=
DESCRIPCION
STOCK
PRECIO STOCK SUM(CANTIDAD)
----------------------------------------------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
15 12 5
30 16 15
22
Como se describió anteriormente. DESCRIPCION, PRECIO y STOCK se deben especificar como columnas de agrupación en esta consulta, sólo porque aparecen en la lista de selección. Realmente no contribuyen en nada al proceso de agrupación ID_FAB e ID_PRODUCTO especifican completamente una única fila de la tabla PRODUCTOS, haciendo automáticamente que las otras tres columnas tengan un único valor en cada grupo.
Restricciones sobre. las condiciones de búsqueda de grupos La cláusula HAVING se usa para incluir o excluir grupos de filas de los resultados, así que la condición de búsqueda 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 condición de búsqueda en una cláusula HAVING puede ser: • Una constante • Una función de columna que produce un único valor que resume las filas del grupo • Una columna de agrupación, que por definición tiene el mismo valor en cada fila del grupo • Una expresión que contenga una combinación de lo anterior En la práctica, la condición de búsqueda de la cláusula HAVING incluirá siempre al menos una función de columna. Si no, la condición de búsqueda se trasladaría a la cláusula WHERE y se aplicaría a filas individuales. La forma más sencilla de determinar si una condición de búsqueda pertenece a la cláusula WHERE O a HAVING es recordar cómo se aplican las dos cláusulas: • La cláusula WHERE se aplica afilas individuales, así que las expresiones que contiene se deben poder calcular sobre filas individuales. • La cláusula HAVING se aplica a grupos de filas, así que las expresiones que contiene se deben poder calcular sobre grupos de filas.
Para procesar esta consulta, SQL realiza conceptualmente los siguientes pasos: . 1. 2. 3.
4.
Reúne las tablas PEDIDOS y PRODUCTOS para determinar la descripción, 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 búsqueda de grupos Al igual que la condición de búsqueda de la cláusula WHERE, la condición de búsqueda de la cláusula HAVING puede producir uno de estos tres resultados: • Si la condición de búsqueda es TRUE, el grupo de filas se conserva y contribuye como una fila de resumen a los resultados.
206
SOL. Manual de referencia
• Si la condición de búsqueda es FALSE, se descarta el grupo de filas y no contribuye a ninguna fila-de resumen de los resultados. • Si la condición de búsqueda es NULL, se descarta el grupo de filas y no contribuye a ninguna fila de resumen de los resultados.
CAPíTULO
Las anomalías que ocurren con los valores NU~L .en la condició~ de búsqueda son las mismas que en la cláusula WHERE; se descnbieron en el CapItulo 6.
HA VING
sin GROUP BY .
La cláusula HAVING se usa casi siempre en conjunción con la cláusula GROUP BY, pero la sintaxis de la instrucción SELECT no 1.0 requiere..Si aparece una cláusula HAVING sin una cláusula 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 cláusula HAVING se aplican a un, y sólo 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 cláusula HAVING sin la cláusula correspondiente GROUP BY se ve rara vez en la práctica.
Resumen En este capítulo 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 mínimo y el máximo de una columna, contar el número de valores de datos en una columna o contar el número de filas de resultados de la consulta. • Una consulta de resumen sin una cláusula 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 cláusula GROUP BY genera múltiples filas de resultados cada una resumiendo las filas de un grupo en concreto. • La cláusula ~AVING actúa como una cláusula WHERE para grupos, seleccionando los grupos de filas que contribuyen al resumen de los resultados de la consulta.
9
Subconsultas y expresiones de consultas
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 <
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 más simples de una subconsulta, ésta aparece dentro de una cláusula WHERE o HAVING de otra instrucción SQL. Las subconsul-
207
208
SOL. Manual de referencia
Capítulo 9: Subconsultas y expresiones de consultas
Concepto de subconsulta
tas proporcionan una forma natural y. eficiente de manejar las solicitudes de consultas que se expresan en términos de los resultados de otras. A continuación se muestra un ejemplo de tal solicitud:
La Figura 9.1 muestra la forma de una subconsulta SQL. La subconsulta se encierra entre paréntesis; sin embargo, tiene la forma familiar de una instrucción SELECT, con una cláusula FROM y cláusulas opcionales WHERE, GROUP BY Y HAVING. La forma de estas cláusulas en una subconsulta es idéntica a la de la instrucción SELECT, y realizan sus funciones normales cuando se usan dentro de una subconsulta. Hay, no obstante, algunas diferencias entre una subconsulta y un instrucción SELECT real:
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 condición. Parece razonable que la instrucción SELECT que expresa la consulta pueda ser corno: SELECT CIUDAD FROM OFICINAS WHERE OBJETIVO
>
209
• En la mayoría 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 selección en su cláusula SELECT.
???
El valor «???» se debe rellenar y debe ser igual a la suma de las cuotas de los representantes asignados a la oficina en cuestión. ¿Cómo se puede especificar ese valor en la consulta? Por el Capítulo 8 se sabe que la suma de las cuotas de una oficina determinada (digamos, por ejemplo, el número de oficina 21) se puede obtener con esta consulta:
r-ISELECT
-t:
ALL
=r
I!;:Ción -'n',-------" elemento-de-
DISTINCT SELECT SUM(CUOTA) FROM REPRESENTANTES WHERE OFICINA_REP ~ 21
Pero sería poco eficaz tener que escribir esta consulta, escribir los resultados y escribir en la consulta anterior la cantidad correcta. ¿Cómo se pueden poner los resultados de esta consulta en la consulta anterior en lugar de los signos de interrogación? Podría 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
L-.
WHERE
fespecificac:ón-de+tablas
condición-de-búsqueda
~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 añade 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 cláusulas WHERE o HAVING. En la cláusula WHERE ayudan a seleccionar filas individuales que aparecen en los resultados. En la cláusula HAVING ayudan a seleccionar grupos de filas que aparecen en los resultados de la consulta.
I
L
columnas-de-
agrU~aCión ~
~HAVING condición-de-búsqueda
~
~
~
)
.¡.
•
Figura 9.1.
-
Diagrama sintáctico de las subconsuJtas.
210
SOL. Manual de referencia
Capítulo 9: Subconsultas y expresiones de consultas
• La cláusula ü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 más adelante en la sección «Referencias externas». • En la mayoría de implementaciones, una subconsulta no puede ser la UNION de varias instrucciones SELECT diferentes; s610 se permite una única SELECT. (El estándar SQL2 permite expresiones de consultas mucho más potentes y alivia esta restricción, como se describe más adelante en la sección «Consultas avanzadas en SQL2».)
Es más conveniente usar la subconsulta, pero no es esencial. Usualmente, la subconsultas no son tan simples. Por ejemplo, considérese de nuevo la consulta de la sección 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 Castellón León
Subconsultas en la cláusula WHERE Las subconsultas se usan más frecuentemente en la cláusula WHERE de una instrucción SQL. Cuando aparece una subconsulta en la cláusula WHERE, funciona como parte del proceso de selección de filas. Las subconsultas más simples aparecen dentro de una condición de búsqueda y producen un valor que se usa para comprobar la condición de búsqueda. A continuación se muestra un ejemplo de una subconsulta simple:
En este caso (más normal), la subconsulta no se puede calcular una vez para toda la consulta. La subconsulta produce un valor diferente para cada oficina, en términos de las cuotas de los representantes para esa oficina en particular. La Figura 9.2 muestra
Tabla REPRESENTANTES Subconsulta
-+@{:"= "'" ''"0'",'
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)
>?
,}
PROM REPRESENTANTES WHERE OFlCINJ\.ftEP ~ 22
FROM OFICINAS})
NOMBRE
Tabla OFICINAS OFICINA CIUDAD
Bernardo Sánchez
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 después en la condición de búsqueda 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 número de la com- . pañía. De hecho, se podría 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 número en una consulta WHERE simple: WHERE CUOTA < 275000
L.0{~ELECT SUM (CumA) }>7 FROM REPRESENTANTES l'o'HERE OFICINI\...REP .. 21
Figura 9.2.
Funcionamiento de la subconsulta en la cláusula 1'1HERE.
212
SOL. Manual de referencia
Capítulo 9: Subconsultas y expresiones de consultas
conceptualmente cómo realiza SQL la consulta. La consulta principal obtiene sus datos de la tabla OFICINAS y la cláusula WHERE selecciona las oficinas que se incluirán en los resultados de la consulta. SQL va por las filas de la tabla OFICINAS una a una, aplicando el test establecido en la cláusula WHERE. La cláusula 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 número, y la cláusula WHERE compara el número con el valor de OBJETIVO, seleccionando o descartando la oficina en curso en términos de la comparación. Como muestra la figura, SQL lleva a cabo repetidamente la subconsulta, una vez por cada fila comprobada en la cláusula WHERE de la consulta principal.
Condiciones de búsqueda en las subconsultas . Las subconsultas aparecen usualmente como parte de la condición de búsqueda de una cláusula WHERE o HAVING. El Capítulo 6 describió las condiciones simples de búsqueda que se pueden usar en estas cláusulas. Además, la mayoría de productos SQL ofrecen estas condiciones de búsqueda en las subconsultas: • Test de comparación en subconsultas. Compara el valor de una expresión con el valor producido por la subconsulta. Este test se parece al test simple de comparación. • Test de pertenencia al conjunto devuelto por una subconsulta. Comprueba si el valor de una expresión 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 expresión 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. Considérese de nuevo la consulta de las secciones anteriores:
El test de comparación en subconsultas !=, <>, <, <=, >, >=)
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>
I
I l'
l'
I
213
Este test de comparación en subconsultas es una forma modificada del test simple de comparación, como se muestra en la Figura 9.3. Compara el valor de una expresión con el valor producido por una subconsulta y devuelve un resultado TRUE si la comparación 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)
El papel de la subconsulta en esta instrucción SELECT es calcular la cuota total de los represenFantes que trabajan en una oficina en concreto -específicamente, la oficina que se está comprobando en la cláusula WHERE de la consulta principal-o La subconsulta hace esto examinando la tabla REPRESENTANTES. Pero obsérvese que la columna OFICINA de la cláusula 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 cláusula 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 cláusula FROM de la consulta principal. Como muestra el ejemplo anterior, cuando el SGBD examina la condición de búsqueda 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.
---expresión
--,'r--
----,-- subconsulta---+-. <>
< <=
> >=
Figura 9.3.
-
Diagrama sintáctico del test de comparación en subconsultas.
~
214
Capítulo 9: Subconsultas y expresiones de consultas
SOL Manual de referencia
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 = 'Almería')
DESCRI PC ION
215
STOCK
Serie 3, cable Serie 1, cable Serie 2, cable
207 277 167
El test de comparación en subconsultas especificado por el estándar SQLl e incluido por todos los productos SOBO líderes permite que una subconsulta aparezca sólo en la parte derecha del operador de comparación. Esta comparación:
NOMBRE
A < (subconsulta) Bruno Arteaga Susana Santos León Freire
se permite, pero esta otra:
La subconsulta del ejemplo devuelve el objetivo de ventas de la oficina de AImería. El valor se usa después para seleccionar a los representantes cuyas cuotas son superiores al objetivo obtenido. El test de comparación en subconsultas ofrece los mismos seis operadores de comparación (=. <>, <, <=, >, >;:.) disponibles para el test de comparación. 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 comparación no tiene sentido y SQL informa del error. Si la subconsulta no produce filas o produce un valor NULL, el test de comparación devuelve NULL (desconocido). A continuación se muestran más ejemplos de este test:
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')
EMPRESA Acme Toledo S.A.
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')
(subconsulta) > A no se permite. Esto no limita la capacidad de los tests de comparación, porque el operador en cualquier comparación de desigualdad siempre se puede dar la vuelta de forma que la subconsulta se sitúe en la parte derecha de la desigualdad. Sin embargo. significa que a veces se debe invertir la lógica del lenguaje natural para obtener una forma de la solicitud en una instrucción SQL legaL El estándar SQL2 eliminó esta restricción y permite que la subconsulta aparezca en cualquier lado del operador de comparación. De hecho, el estándar SQL2 va mucho más allá y permite que se aplique un}est de comparación a una fila completa de valores. en lugar de a un único valor. Esta y otras características más avanzadas de expresión de consultas se describen en las últimas secciones de este capítulo. 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.
El test de pertenencia a conjuntos
(IN)
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
- - expresión-de-test
¡--,--IN------ subconsulta
...
LNOT-I
Figura 9.4.
Diagrama sintáctico del test de pertenencia a conjuntos en su Itas (IN).
subcon~
216
SOL. Manual de referencia
Capítulo 9: $ubconsultas y expresiones de consultas
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 continuación se muestra un ejemplo simple:
SELECT EMPRESA FROM CLIENTES WHERE NUM_CLI IN (SELECT FROM WHERE ANO AND AND EMPRESA
Listar los represemames que trabajan en oficinas que esIán por encima de sus objetivos.
217
DISTINCT CLIENTE PEDIDOS FAB = 'ACI' PRODUCTO LIKE '4100%' FECHA_PEDIDO BETWEEN '01-ENE-90' '30-JUN-90')
Acme Ace Internacional Henche & L6pez JCP S.A.
SELECT NOMBRE FROM REPRESENTANTES WHERE OFICINA_REP IN (SELECT OFICINA FROM OFICINAS
WHERE VENTAS
>
OBJETIVO)
En cada uno de estos ejemplos la subconsulta produce una columna de valores de datos, y la cláusula 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 explícitamente en la instrucción.
NOMBRE
Maria Jiménez Samuel Clavel Bruno Arteaga Susana Santos León Freire
El test de existencia
La subconsulta produce un conjunto de números de oficina donde las ventas SQn superiores a sus objetivos (en la base de datos de ejemplo hay tres de estas oficinas con números 11, 13 y 21). La consulta principal comprueba a continuación cada fila de la tabla REPRESENTANTES para determinar si un representante en concreto trabaja en una oficina con uno de estos números. A continuación se muestran otros ejemplos de subconsultas que comprueban la pertenencia a conjuntos:
(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 ningún test de comparación simple que se parezca al test de existencia; se usa sólo con subconsultas. A continuación se muestra un ejemplo de una solicitud que se puede expresar de forma natural con un test de existencia:
Listar los represimtantes que no trabajan en oficinas dirigidas por León Freire (empleado lOS).
Listar los productos para los que se haya recibido un pedido de 25.000 € o más.
SELECT NOMBRE FROM REPRESENTANTES WHERE OFICINA-REP NOT IN (SELECT OFICINA FROM OFICINAS WHERE JEF = 108)
La solicitud se podría reescribir fácilmente 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 cuestión), (b) tenga un importe de al menos 25.000 €.
NOMBRE Bruno Arteaga Maria Jiménez Samuel Clavel Bernardo Sánchez Daniel Ruidrobo Pablo Cruz
~EXISTS
subconsulta
LNcrr~
Listar t040s los clientes que han formulado pedidos de zapatas de ACI (fabricante ACI, números de producto que comienzan en 4100) entre enero y junio de 1990,
Figura 9.5.
-
Diagrama sintactico del test de existencia
(EXISTS).
...
218
Capítulo 9: Subconsultas y expresiones de consultas
SOL. Manual de referencia SELECT EMPRESA PROM CLIENTES WHERE REP_CLI
La instrucción SELECT usada para obtener la lista requerida de productos se parece a la solicitud reescrita:
(SELECT PROM WHERE AND NOT EXISTS ( SELECT FROM WHERE ANO EMPRESA
Listar las oficinas donde haya un representante cuya cuota represente más del 55 por ciento del objetivo de la oficina.
Llave Riostra Zapata
219
pequei\a
SELECT CIUDAD FRQM OFICINAS WHERE EXISTS (SELECT FROM REPRESENTANTES WHERE OFICINA_REP ~ OFICINA ANO CUOTA> (.55 .. OBJETIVO))
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 números 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á vacía), 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 lógica 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. . Nótese que la condición de búsqueda no usa realmente los resultados de la subconsulta. Simplemente comprueba si la subconsulta produce resulta~d~s. Por esta razón, 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 podría haber escrito así:
Nótese 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 práctica, 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 más.
Tests cuantificados (ANY y ALL)
SELECT DESCRIPCION FROM PRODUCTOS WHERE EXISTS (SELECT FROM WHERE AND AND
CIUDAD Daimiel Almeria
*
La versión de la subconsulta del test IN comprueba si un valor de datos es igual a algún valor de una columna de los resultados de una subconsulta. SQL proporciona dos tests cuantificados, ANY y ALL, que extienden esta noción a otros operadores de comparación, 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.
PEDIDOS PRODUCTO ~ ID PRODUCTO FAB ~ ID_FAB IMPORTE >~ 25000.00)
En la práctica, la subconsulta de un test EXISTS se escribe siempre usando la notación SELECT ,o,. A continuación se muestran ejemplos adicionales de consultas que usan EXISTS:
El test ANY
*
El test ANY se usa en conjunción con uno de los seis operadores de comparación 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
Listar los clientes asignados a Susana Santos que hayan fonnulado un pedido superior a 3.000 €.
;"
Capítulo 9: Subconsultas y expresiones de consultas
220
SOL. Manual de referencia
- - - - expresión-de-test
I
=
-¡-[,
1---<>----1.I
ANY
T
221
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 estándar de SQL ANSIfISO. Se puede usar en general cualquiera de ellas, pero algunas marcas de SGBD no admiten SOME. El test ANY puede ser difícil de entender a veces porque implica un conjunto completo de comparaciones, no sólo simplemente una. Si se lee el test de forma ligeramente diferente a como aparece en la instrucción puede ayudar. Si aparece el test ANY:
subconsulta----+-·
ALL
< ----1
WHERE X < ANY
f--<=----1
(SELECT Y ... )
en lugar de leer este test como:
>
----1 ·donde X es menor que algún Y seleccionado ... •
,--->=-.l
Figura 9.6.
se puede probar a leerlo como: "donde, para algún Y,
Diagrama sintáctico de los tests de comparación cuantificados (ANY y ALL).
X es menor que Y·
Cuando se usa este truco, la consulta precedente se convierte en:
SeLeccionar Los representantes en los que, para aLgún pedido anotado por el representante, ellO por ciento de La cuota del representante es menor que el impar/e del pedido.
el operador de comparación 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 continuación se muestra un ejemplo de una solicitud que se puede expresar con el test ANY:
Si la subconsulta en un test ANY no produce filas de resultados o si los resultados incluyen valores NULL, la operación de un test ANY puede variar de un SGBD a otro. El estándar 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:
Listar los representantes que han formulado un pedido que representa más del 10 por ciento de su cuota. SELECT NOMBRE
FROM REPRESENTANTES WHERE (.1 * CUOTA) < ANY (SELECT IMPORTE
• Si la subconsulta produce una columna vacía de resultados, el test ANY devuelve FALSE -no se produce ningún valor en la subconsulta para el que se cumpla el test de comparación. • Si el test de comparación es TRUE para al menos uno de los valores de datos de la columna, entonces la condición de búsqueda ANY devuelve TRUE -hay realmente algún valor producido por la subconsulta para el que se cumple el test de comparación. • Si el test de comparación es FALSE para cada valor de datos en la columna, entonces la condición de búsqueda ANY devuelve FALSE. En este caso se puede afirmar que no se ha producido ningún valor en la subconsulta para el que se cumpla el test de comparación. • Si el test de comparación no es TRUE para algún valor de datos de la columna, pero es NULL (desconocido) para uno o más valores de datos, entonces la condición de búsqueda ANY devuelve NULL. En esta situación no se puede afirmar si hay un valor producido por la subconsulta para el que se cumple el
FROM PEDIDOS
WHERE REP : NOM_EMPLl NOMBRE Samuel Clavel León Freire
Neus Azcárate
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 cláusula WHERE de la consulta principal calcula a continuación ellO por ciento de la cuota del representante actual y lo usa como valor de test, comparándolo con cada importe de pedido producido por la subconsulta. Si algún pedido supera el valor calculado del test, el test ANY devuelve TRUE, y el representante se
PRESENTANTES,
•
....
222
SOL. Manual de referencia
Capítulo 9: Subconsultas y expresiones de consultas
test de comparación; puede que lo haya y puede que no dependiendo de los valores «reales» (aún desconocidos) para el dato NULL.
223
Siempre se puede convertir una consulta con un test ANY en una consulta con un test EXISTS, trasladando la comparación dentro de la condición de búsqueda 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
El operador de comparación ANY puede ser muy sutil de usar en la práctica, especialmente en conjunción con el operador de comparación desigualdad (<». A continuación se muestra un ejemplo que ilustra el problema:
EXISTS: SELECT NOMBRE, EDAD FROM REPRESENTANTES WHERE NOT EXISTS {SELECT FROM OFICINAS WHERE NUM_EMPL
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:
NOMBRE SELECT NOMBRE, EDAD FROM REPRESENTANTES WHERE NUM_EMPL <> ANY (SELECT JEF FROM OFICINAS)
EDAD
María Jiménez Susana Santos Daniel Ruidrobo Tomás Saz Pablo Cruz Neus Azcárate
La subconsulta:
JEF}
31 48 45 41 29 49
SELECT JEF
FROM OFICINAS
El test ALL •
produce obviamente los números de empleado de Jos directores y, por tanto, la consulta parece decir:
Al igual que el test ANY, el test ALL se usa en conjunción con uno de los seis operadores de comparación 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 comparación 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 continuación se muestra un ejemplo que se puede resolver con el test ALL:
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 incluirían a todos los representantes y, por tanto, fallarían al responder la cuestión planteada. La consulta correcta es:
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 NOMBRE, EDAD FROM REPRESENTANTES WHERE NOT (NUM_EMPL :
SELECT CIUDAD, OBJETIVO FROM OFICINAS WHERE (.50 • OBJETIVO) < ALL (SELECT VENTAS FROM REPRESENTANTES WHERE OFICINA_REP : OFICINA)
NOMBRE María Jiménez Susana Santos Daniel Ruidrobo Tomás Saz Pablo Cruz. Neus Azcárate
ANY (SELECT JEF FROM OFICINAS')
CIUDAD
EDAD
Daimiel Navarra Almería
31 48 45 41 29
300.000,OO€ 575.000,OO€ 350.000,OO€
Conceptualmente, la consulta principal comprueba cada fila de la tabla OFIuna a una. La subconsulta halla todos los representantes que trabajan en la
49
cINAs'
.. ,,-
OBJETIVO
1...
224
SOL Manual de referencia
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, comparándolo 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 difícil de comprender porque implica un conjunto completo de comparaciones, no sólo una única. De nuevo, ayuda el leer el test de forma ligeramente diferente a como aparece en la instrucción. Si aparece este test ALL: WHERE X
<
ALL (SELECT Y ... )
Capítulo 9: Subconsultas y expresiones de consultas
~
225
Los errores sutiles que pueden ocurrir cuando el test ANY se combina con el operador de comparación de desigualdad también 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 comparación dentro de la subconsulta.
«»
Subconsultas y reuniones Es posible que se haya reparado a lo largo de este capítulo en que muchas de las consultas que se han escrito con subconsuItas se podrían 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:
en lugar de leerlo corno: -donde X es menor que todos Y seleccionados
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 operación del test ALL puede variar de un SGBD a otro. El estándar 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 vacía de resultados, el test ALL devuelve TRUE. El test de comparación no se cumple para ningún valor de la subconsulta; simplemente no hay valores. • Si el test de comparación es TRUE para todos los valores de datos de la columna, entonces la condición de búsqueda ALL devuelve TRUE. De nuevo, el test de comparación se cumple para cada valor producido por la subconsulta. • Si el test de comparación es FALSE para algún valor de datos en la columna, entonces la condición de búsqueda ALL devuelve FALSE. En este caso el test de comparación no se cumple para ningún valor de datos producido por la consulta. • Si el test de comparación no es FALSE para ningún valor de datos de la columna, pero es NULL (desconocido) para uno o más valores de datos, entonces la condición de búsqueda ALL devuelve NULL. En esta situación no se puede afirmar si hay un valor producido por la subconsulta para el que se cumple el test de comparación; puede que lo haya y puede que no, dependiendo de los valores «reales» (aún desconocidos) para el dato NULL.
LiSTar los nombres y edades de los representantes que trabajan en las oficinas de la región oeste. SELECT NOMBRE. EDAD FROM REPRESENTANTES WHERE OFICINA_REP IN (SELECT OFICINA FROM OFICINAS WHERE REGION ~ 'Oeste') NOMBRE
EDAD
Susana Santos Le6n Freire Neus Azcárate
48 62 49
Esta forma de la consulta refleja estrechamente la solicitud planteada. La subconsulta da una lista de oficinas de la región oeste y la consulta principal halla los representantes que trabajan en una de las oficinas de la lista. A continuación se muestra una forma alternativa de la consulta usando una reunión de dos tablas:
Listar los nombres y edades de los representantes que trabajan en las oficinas de la región oeste. SELECT FROM WHERE AND
NOMBRE. EDAD REPRESENTANTES. OFICINAS OFICINA_REP : OFICINA REGION = 'Oeste'
NOMBRE Susana Sa~tos León Freire Neus Azcárate
EDAD 48 62 49
Esta forma de la consulta reúne la tabla REPRESENTANTES con la tabla OFICIpara hallar la región en la que trabaja cada empleado, y después elimina las filas de los empleados que no trabajan en la región oeste.
NAS
226
Capítulo 9: Subconsultas y expresiones de consultas
SOL. Manual de referencia
Cualquiera de las dos consultas hallará los representantes correc!os, y ninguna es mejor o peor. Muchas personas encontrarán que la primera forma (con una subconsulta) es más natural porque la solicitud en lenguaje natural no pide ninguna información acerca de las oficinas, y porque parece un poco extraño 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 región 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 reunión equivalente. A continuación se muestra un ejemplo simple: Listar los nombres y edades de representantes que estén 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
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 reunión.
Subconsultas anidadas Todas las consultas descritas hasta ahora en este capítulo 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 continuación 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 estén asignados a oficinas de la región de ventas este. SELECT EMPRESA FROM CLIENTES WHERE REP_CLI IN (SELECT NUM_EMPL
227
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 más interna: SELECT OFICINA FROM OFICINAS WHERE REGION = 'Este'
produce una columna que contiene los números de oficina de las oficinas de la región este. La siguiente subconsulta: SELECT NUM_EMPL FROM REPRESENTANTES WHERE OFICINA_REP IN (subconsulta)
produce una columna que contiene los números de empleado de los representantes que trabajan en una de las oficinas seleccionadas. Finalmente. la consulta más exterior: SELECT EMPRESA FROM CLIENTES WHERE REP_CLI IN (subconsultaj
detennina los clientes cuyos representantes tienen uno de los números de empleado seleccionados. La misma técnica usada en esta consulta de tres niveles se puede usar para construir consultas con cuatro o más niveles. El estándar SQL de ANSIIISO no especifica un número máximo de niveles de anidamiento, pero en la práctica una consulta llega a consumir mucho tiempo al aumentar el número de niveles. La consulta también llega a ser difícil de leer, comprender y mantener cuando contiene más de uno o dos niveles de subconsultas. Muchas implementaciones de SQL restringen el número de niveles de subconsulta a un número relativamente pequeño.
228
Capítulo 9: Subconsultas y expresiones de consultas
SOL. Manual de referencia
229
En esta consulta no sería 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 €) Ydespués convirtiendo la consulta principal en:
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 están 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 cláusula 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 cláusula FROM de la consulta principal, o a una tabla listada en la cláusula 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 más 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 cláusula FRQM de la propia subconsulta o de la cláusula FROM de la consulta que contiene a la subconsulta. Para minimizar esta posibilidad de confusión, SQL siempre interpreta una referencia a columna en una subconsulta usando la cláusula FROM posible más próxima. Para ilustrarlo, en este ejemplo se usa la misma tabla en la consulta y en la subconsulta:
SELECT CIUDAD FROM OFICINAS WHERE VENTAS < 550000.00
Listar los representantes mayores de 40 años y que dirigen a un representante que supere su cuota.
Las implementaciones comerciales de SQL detectan automáticamente esta situación 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:
SELECT FROM WHERE AND
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 continuación se muestra un ejemplo:
Listar las oficinas de ventas cuyas yemas esláll por debajo del objetivo medio. SELECT CIUDAD PROM OFICINAS WHERE VENTAS < (SELECT AVG(OBJETIVO) FROM OFICINAS) CIUDAD
Daimiel Almeria
Listar todas las oficinas cuyos objetivos excedan la suma de las cuotas de los representantes que trabajan en ellas:
NOMBRE REPRESENTANTES EDAD > 4 o NUM_EMPL IN (SELECT JEFE FROM REPRESENTANTES WHERE VENTAS > CUOTA)
NOMBRE Samuel Clavel
SELECT CIUDAD FROM OFICINAS WHERE OBJETIVO>
León Freire
(SELECT SUM(CUOTA) FROM REPRESENTANTES WHERE OFICINA_REP = OFICINA)
CIUDAD Castellón León
Por cada fila de la tabla OFICINAS a comprobar en la cláusula 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 cláusula 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 números de empleado de sus jefes. SQL puede centrar su atención ahora en la consulta principal, seleccionando los jefes cuyos números 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
Capítulo 9: Subconsultas y expresiones de consultas
SOL. Manual de referencia
la referencia externa. Esta solicitud, que añade una condición más a la anterior, muestra cómo hacerlo:
re
La Figura 9.7 muestra conceptualmente cómo 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 después usarla repetidamente en la cláusula HAVING. La consulta principal recorre la tabla PEDIDOS, hallando todos los pedidos de los productos ACI, y agrupándolos por representante. La cláusula HAVING comprueba a continuación 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 cláusula SELECT produce una fila de resumen para cada grupo, mostrando el nombre del representante y el importe medio de los pedidos de cada uno. También se puede usar una subconsulta correlacionada en la cláusula HAVING. Dado que la subconsulta se evalúa 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 agrupación de la consulta externa, O estar contenida en una función de columna. En el último caso, el valor de la función de columna del grupo de filas que se comprueba se calcula como parte del procesamiento de subconsultas.
Listar los jefes mayores de 40 años y que dirigen a un representante que supecuota y que no trabaje en la misma oficina de ventas que el jefe.
Sil
. SELECT NOMBRE
FROM REPRESENTANTES JEFES WHERE EDAD>
231
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 León 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 condición de búsqueda 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.
Tlbla REPRESENTAm'ES
Tabla PEDlOOS
Subconsultas en la cláusula HAVING* JOIN
Aunque las subconsultas se encuentran a menudo en la cláusula WHERE, también se pueden usar en la cláusula HAVING de una consulta. Cuando. aparece una subconsulta en la cláusula HAVING, funciona como parte de la seleccIón de grupos de filas realizada por la cláusula HAVING. ~onsidérese esta consulta con una subconsulta:
GROUP
" Tabla AGRUPADA
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
NUliJ'EDlOO 112!168 113055
NOMBRE, AVG(IMPORTE) REPRESENTANTES, PEDIDOS NUM_EMPL = REP FAB = 'ACI' BY NOMBRE AVG(IMPORTE} > (SELECT AVG(IMPORTE) FROM PEDIDOS)
Funcionamiento de la subconsulta en la cláusula HAVING.
saL.
232
Capítulo 9: Subconsultas y expresiones de consultas
Manual de referencia
Si la solicitud anterior se cambia ligeramente, la subconsulta de la cláusula se convierte en una subconsulta correlacionada:
HAVING
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
WHERE REP = NUM_EMPLl NOHBRE
AVG (IMPORTE)
233
• 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 algún valor. • Los tests cuantificados (ANY y ALL) usan uno de los operadores simples de comparación para compara un valor de test con todos los valores devuehos por la subconsulta, comprobando si se cumple la comparación 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 versión final de las reglas para el procesamienlo de. consultas SQL, extendidas para incluir subconsultas. Proporciona una definición completa de los resultados producidos por una instrucción SELECT.
7.B65,4a€
Bruno Arteaga susana Santos
15.00Q,QO€
Tomás Saz
22.S00,OO€
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 cláusula 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 capítulo ha descrito las subconsultas, que permiten usar los resultados de una consulta para ayudar en la definición de otra. Antes de continuar con las consultas avanzadas de la especificación SQL2, se resumirán las subconsultas: • Una subconsulta es una «consulta dentro de otra». Las subconsultas aparecen dentro de las condiciones de búsqueda de las subconsultas· en la cláusula WHERE o HAVING. • Cuando aparece una subconsulta en la cláusula 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 cláusula 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 comparación usa uno de los operadores simples de comparación para contrastar un valor de test con el único valor que devuelve la subconsulta.
Para generar los resultados de una consulta de una instrucción SELECT: 1. Si la instrucción 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 cláusula FROM lista una única tabla, el producto es esta tabla. 3. Si hay una cláusula WliERE, aplicar su condición de búsqueda a cada fila de la tabla pro· ducto, conservando las filas para las que la condición de búsqueda es TRUE (y descartando aquellas para las que la condición es F....LSE o NULL). Si la cláusula H....VING contiene una subconsulta, ésta se ejecuta por cada fila que se este comprobando. 4. Si hay una cláusula 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 agrupación. 5. Si hay una clausula HAVING. aplicar su condición de búsqueda a cada grupo de filas, conservando los grupos para los que la condición de búsqueda es TRUE (y descartando aquéllos para los que la condición es FALSE o NULL). Si la cláusula 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 selección 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 función 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 instrucción 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 cláusula aRDER BY, ordenar los resultados de la consulta como se especifique. las filas generadas por este procedimiento forman los resultados de la consulta.
Figura 9.8.
Reglas de procesamiento de consultas SOL (versión final).
234
SOL. Manual de referencia
Capítulo 9: Subconsultas y expresiones de consultas
Consultas avanzadas en SQL2* Las consultas SQL descritas hasta aquí en los capítulos 6 al 9 son las caracterÍsticas principales proporcionadas por la mayoría de implementaciones SQL. La combinación de características que representan -la selección de columnas en la cláusula SELECT, el criterio de selección de filas de la cláusula WHERE, las reuniones mullitabla de la cláusula FROM, las consultas de resumen en las cláusulas GRQUP BY y HAVING. y las subconsulLas para solicitudes más complejas- dan al usuario un potente conjunto de posibilidades de recuperación y análisis de datos. Sin embargo, los expertos en bases de datos han indicado varias limitaciones de estas características, incluyendo las siguientes: • No hay toma de decisiones dentro de las subconsultas. Supóngase 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 año, según el que sea mayor. Con las características estándar de las consultas es difícil de hacer. O bien supóngase 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 más difícil de escribir usando consultas SQL estándar. Se debe incluir cuatro consultas SQL separadas (una por cada trimestre) y el programa debe seleccionar la consulta a ejecutar en términos de la entrada del usuario. Este caso simple no es muy difícil, pero en un caso más general, el programa podría llegar a ser más complejo. • Uso limitado de subconsultas. El ejemplo más simple de esta limitación es la restricción de SQLI que establece que una subconsulta sólo puede aparecer en el lado derecho de un test de comparación en una cláusula 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 más directa con esta consulta: SELECT OFICINA FROM OFICINAS WHERE (SELECT SUM{CUOTA) FROM REPRESENTANTES WHERE OFICINA_REP ~ OFICINA)
<
En este simple ejemplo no es difícil invertir la lógica, pero la restricción es cuando ~enos una molestia, e impide comparar los resultados de dos subconsultas, por ejemplo. • Expresio~es de fila Ii~itadas. Supóngase 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 IdentIficaCIón (un par ID fabricante I ID producto) coincide con un conjunto de valores y sería 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 estándar 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 después usar la vista como si fuera una tabla real en la cláusula 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 permitiría que se sustituyese la definición 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 instrucción SQLI legar. En su lugar hay que dar la vuelta a la desigualdad: SELECT OFICINA FROM OFICINAS WHERE OBJETIVO
235
ISELECT SUM(CUOTA) FROM REPRESENTANTES WHERE OFICINA_REP ~ OFICINA)
Pero el estándar SQLI no permite una subconsulta en esta posición de la cláusula WHERE. Más claramente, el SGBD debería ser capaz de determinar el significado .de esta consulta, dado que debe hacer básicamente el mismo procesamiento para Interpretar la definición de la vista PEDIDOSGRANDES. . Como m~estran estos ejemplos, el estándar SQLl y los productos SGBD prinCIpales que Implementan este nivel del estándar 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 estándar SQL2 incluye varias pOSIbIlIdades de consultas avanzadas que se centran en la eliminación de estas
236
Capitulo 9: Subconsultas y expresiones de consultas
SOL. Manual de referencia
menle tipos de datos similares, como los enteros de 2 y 4 bytes. Sin embargo, si se intenta comparar los datos numéricos y de caracteres, por ejemplo, el estándar dice que el SGBD debería generar un error. El estándar considera que esto es una condición de error incluso si la cadena de caracteres contiene datos numéricos. Se puede, sin embargo, pedir explícitamente que el SGBD convierta tipos de datos usando la expresión CAST, cuya sintaxis se muestra en la Figura 9.9. La expresión CAST tiende a tener poca importancia cuando se están escribiendo directamente instrucciones en una interfaz interactiva de SQL. Sin embargo, puede ser crítico cuando se use SQL desde un lenguaje de programación cuyos lipos de datos no coincidan con los tipos de datos incluidos por el estándar SQL. Por ejemplo, la expresión CAST de la cláusula 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:
restricciones y en hacer más general el lenguaje SQL. El espíritu de estas características de SQL2 tiende a ser que un usuario sea capaz de escribir una expresión de consulta que tenga sentido y que la expresión de consulta sea una consulta legal. Dado que estas capacidades de SQL2 constituyen la expansión principal del lenguaje sobre el estándar SQL 1, la mayoría de ellas se requieren sólo en el nivel completo del estándar.
Expresiones escalares (50L2) Las capacidades de consultas extendidas de SQL2 son las que proporcionan más potencia de manipulación y cálculo de datos entre valores de datos individuales (denominados escalares en el estándar SQL2). Dentro del lenguaje SQL, los valores de datos individuales tienden a tener tres fuentes:
SELECT NOMBRE, CAST OFICINA_REP AS VARCHAR, FROM REPRESENTANTES
• 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.
FECHA_CONTRATO AS VARCHAR
La expresión CAST puede aparecer generalmente en cualquier lugar en el que pueda aparecer una expresión escalar en una instrucción SQL. En este ejemplo ~e usa en la cláusula WHERE para convertir un número de cliente en cadena de caracteres en un entero, de forma que se pueda comparar con los datos de la base de datos:
En esta consulta SQL: SELECT NOMBRE, NUM_EMPL, FECHA_CONTRATO, (CUOTA * FROM REPRESENTANTES WHERE (OFICINA_REP = 13) OR PUESTO = 'VP VENTAS'
237
.9)
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 cláusula WHERE. Los números 9 y 13 Yla cadena de caracteres «VP VENTAS» generan, de forma similar, valores de datos individuales. Si esta inslrucción SQL apareciese dentro de una programa SQL incorporado (descritos en el Capítulo 17), la variable de programa num_oficina podría contener un valor de datos individual, y la consulta podría se como:
En lugar de especificar un tipo de datos en la expresión CAST, se puede especificar un dominio SQL2. Los dominios son colecciones específicas de valores de datos legales que se pueden definir en la base de datos bajo el estándar SQL2. Se describen completamente en el Capítulo 11 debido al papel que desempeñan en la inlegri· dad de datos de SQL. Nótese que también se puede generar un valor NULL del tipo de datos apropiado para usar en las expresiones SQL usando la expresión CASTo Los usos más comunes de la expresión CAST son:
SELECT NOMBRE, NUM_EMPL, FECHA_CONTRATO, (CUOTA * .9) FROM REPRESENTANTES WHERE (OFICINA_REP = :num_oficina) OR PUESTO = 'VP VENTAS'
• 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 básicas, SQL2 añade el operador CAST para la conversión explícita de datos, el operador CASE para la toma de decisiones, la operación NULLIF para crear condicionalmente un valor NULL, y el operador COALESCE para crear condicionalmeme valores distintos de NULL.
f---CAST
(TeXP'e5'Ón-de-vaIO'T NULL
La expresión CAST (SQL2)
El estándar SQL tiene reglas bastante restrictivas sobre la combinación de datos de tipos diferentes en expresiones. Especifica que el SGBD convertirá automática-
Figura 9.9.
•
~
AS
T'ipa-da-da,as})
Lnomb~e-.dedomIniO
Diagrama sintáctico de la expresión CAST de SQL2.
~.
238
SOL. Manual de referencia
Capítulo 9: Subconsu/tas y expresiones de consultas
como una cadena de caracteres, pero se sabe que realmente contiene números (es decir, cadenas de dígitos) o fechas (cadenas que se pueden interpretar como día/mes/año). • Convertir datos de tipos de datos albergados por el SGBD que no son admilidos por el lenguaje de programación anfitrión. Por ejemplo, la mayoría de lenguajes de programación anfitriones no tienen tipos de datos explícitos 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, todavía 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 operación UN10N, sus columnas deben tener tipos de datos idénticos. Esto se puede conseguir con el uso de CAST en las columnas de una de las tablas. La expresión CASE (SQL2)
La expresión CASE de SQL2 proporciona una toma de decisiones limitada dentro de expresiones SQL. SU estructura básica, mostrada en la Figura 9.10, es similar a la instrucción 1F ... THEN ... ELSE que se encuentra en muchas lenguajes de programación. Cuando el SGBD encuentra una expresión, evalúa la primera condición de búsqueda, y si es TRUE, entonces el valor de la expresión CASE es el yalor de la primera expresión resultado. Si el resultado de la primera condición de búsqueda no es TRUE, el SGBD procede con la segunda condición de búsqueda y comprueba si es TRUE. Si lo es, el valor de la expresión CASE es el valor de la segunda expresión resultado, y así sucesivamente, A continuación se estudia un ejemplo simple del uso de la expresión CASE. Supónganse que se desea un análisis AlBIC de los clientes de la base de datos de ejemplo de acuerdo con sus límites de crédito. Los clientes A son los que tienen límites de crédito superiores a 60.000 €, los clientes B son los que tienen límites de crédito superiores a 30.000 €, Y los clientes e son el resto. Al usar SQL1, habría que obtener los nombres de cliente y los límites de crédito de la base de datos y después usar un programa de aplicación que buscase los valores de los límites de
1- CASE -
WHEN
condición-debúsqueda
THEN T
expresiónresultado
' - NULL
Figura 9.10.
-.r-------,.,----.... expresión-
crédito y asignar una clasificación A, B o C. Al usar la expresión puede hacer que el SGBD haga el trabajo:
de SQL2 se
SELECT EMPRESA, CASE WHEN LIMITE_CREDITO > 60000 THEN 'A' WHEN LIM1TE_CREDITO > 30000 THEN '8' EL SE 'c' PROM CLIENTES
Por cada fila de resultados, el SOBD evalúa la expresión CASE comparando primero el límite de crédito de 60.000, y si la comparación es TRUE, devuelve A en l~ segunda columna de los resultados" Si la comparación falla, se hace la comparación con 30.000 y se devuelve B si esta segunda comparación es TRUE. En caso contrario, la tercera columna de los resultados contendrá C Éste es un ejemplo muy simple de la expresión CASE". Los resultados de la expresión CASE son lodos literales aquí, pero en general pueden ser cualquier expresión SQL. De forma análoga, no hay requisito respecto a que las comprobaciones en cada cláusula WHEN sean similares, como lo son aquí. La expresión CASE también puede aparecer en otras cláusulas de una consulta. A continuación se muestra un ejemplo de una consulta donde es útil en la cláusula WHERE. Supóngase que se desea halJar el total de las ventas de los representantes ·por oficina. Si un representante no ha sido asignado aún a una oficina, esa persona debería eslar incluida en el total de la oficina de su jefe. A continuación 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 estándar SQL2 proporciona una versión abreviada de la expresión CASE para la situación habitual en la que se desea comparar un valor de alguna clase con una secuencia de valores de datos (usualmente literales), Es(a versión de la sintaxis de CASE se muestra en]a Figura 9.11. En lugar de repelir una condición de búsqueda de la forma: valor_de_comprobación ;:: valor]
t- CASE _ comprobaclon valor-de-..
ELSE , - - resultado L - NULL
Diagrama sintáctico de la expresión CASE de SQL2.
CASE
239
expresión-
CASE valor THEN.,- resultado -;¡¡rr-----::==;:--...
L-
expresión-
NULL
ELSE
-r- resultado l-NULL
Figura 9,11.
Sintaxis alternativa de la expresión CASE de SOL2.
240
SOL. Manual de referencia
Capítulo 9: Subconsultas y expresiones de consultas
en cada cláusula WHEN, permite especificar una sola vez el cálculo valor_de_comprobación. Por ejemplo supóngase que se desea generar una lista de todas las oficinas mostrando los nombres de sus jefes y las ciudades y provincias en las que están ubicados. La base de datos de ejemplo no incluye los nombres de las provincias, por lo que la consulm debe generar esta información por sí misma. A conti-
CASE OFICINA WHEN WHEN WHEN WHEN WHEN FROM OFICINAS, REPRESENTANTES WHERE JEF = NUM_EMPL
11 12 13 21 22
THEN THEN THEN THEN THEN
'Navarra' 'Sevilla' 'Barcelona' 'cádiz' 'Madrid'
Uno de Jos usos más comunes de la capacidad de toma de decisiones de la expresión 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 algún valor literal (tal como la palabra «ausente») o por algún valor predeterminado cuando se use SQL para generar un informe. A continuación se muestra un informe que lista los representantes y sus cuotas. Si un representante no tiene aún asignada una cuota, se asume que se debe listar en su lugar las ventas actuales del representante. Si por alguna razón las ventas actuales fuesen también NULL (desconocidas), se debería listar un importe de O. La instrucción CASE genera la lógica 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 lógica de gestión de valores NULL se necesita frecuentemente, así que el estándar SQL2 incluye una forma especializada de la expresión CASE, la expresión COALESCE, para ello. La sintaxis de la expresión COALESCE se muestra en la Figura 9.12. Las reglas de procesamiento de la expresión COALESCE son muy sencillas. El SOBD examina el primer valor de la lista. Si su valor no es NULL, es
t-COALESCE (C~:::...==r)
0.00)
Como se puede ver comparando las dos consultas, la simplicidad de la sintaxis de COALESCE hace que el significado de la consulta sea más sencillo de ver en un primer vistazo. Sin embargo, la operación de las dos consultas es idéntica. La expresión COALESCE añade simplicidad, pero no nuevas capacidades al lenguaje SQL2. La expresión NULLIP ¡SQL2)
La expresión COALESCE ¡SQL2)
Figura 9.12.
el valor de la expresión 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 expresión. En caso contrario, el SGBD va al tercer valor, y así sucesivamente. A continuación se muestra el mismo ejemplo anterior expresado mediante COALESCE, en lugar de con la expresión CASE:
que
hace el trabajo: SELECT NOMBRE, CIUDAD,
241
Si bien la expresión 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 código especial que se usa para indicar que el dato estaba ausente. Por ejemplo, supóngase, en la base de datos de ejemplo, la situación en la que un representante no tuviese aún 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 situación en una consulta SQL y sustituir ese valor NULL por el «código» cero. La expresión NULLIF, mostrada en la Figura 9.13, se usa para este propósito. Cuando el SGBD encuentra una expresión 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 expresión genera un valor NULL. En caso contrario. la expresión genera el primer valor. A continuación se muestra una consulta que maneja el caso en el que los números ausentes de oficina se representan con un cero: SELECT FROM WHERE GROUP
CIUDAD, SOM(VENTASl OFICINAS, REPRESENTANTES OFICINA ~ (NULLIF OFICINA_REP, BY CIUDAD
.•
Diagrama sintáctico de la expresión COALESCE de SOL2.
O)
t-NULLIF(C:::==rl
Figura 9.13.
••
Diagrama sintáctico de la expresión NULLIF de SOL2.
242
SOL. Manual de referencia
Capítulo 9: Subconsultas y expresiones de consultas
En conjunto. las expresiones CASE, COALESCE y NULLIF proporcionan una sólida 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 mayoría de lenguajes de programación (bucles, bifurcaciones, etc.), pero sí una gran flexibilidad en las expresiones de consulta. El resultado neto es que el SaBD puede hacer más trabajo de procesamiento, reflejándose en los resultados de las consultas, y dejando menos trabajo para el usuario humano o el programa de aplicación.
,,
243
(1§exp,"s:~:~.vaJO' )~.
I
CEFAULT
, I--------,-expresión-de-valor.---------l
Expresiones de filas (SQL2)
-NULL-
Aunque las columnas y los valores de datos escalares que contienen son los bloques constructores de una base de datos relacional, la estructuración de columnas en filas que representan entidades del mundo real, tales como oficinas individuales, clientes o pedidos, es una de las más importantes características del modelo relacional. El estándar SQLl, y la mayoría 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. Básicamente, 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 estándar SQL2 va más 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 comparación SQL y otras estructuras SQL. La constructora de filas (SQL2)
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 más habitual. la constructora de filas es una lista separada por comas de valores literales o expresiones. Por ejemplo, a continuación 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 expresión es una únic~ fila de datos con seis columnas. La palabra clave NULL en cuarta posición indica que la cuarta columna de la fila cons. truida debe contener una valor NULL (desconocido). La palabra clave DEFAULT de la quinta posición indica que la quinta fila construida debería 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 instrucción IÑSERT para añadir una nueva fila a una tabla.
Diagrama sintáctico de la constructora de filas de SQL2.
Cuando una constructora de filas se usa en la cláusula WHERE de una instrucción SQL, los nombres de columna también pueden aparecer como elementos de datos individuales dentro de la constructora de filas o como parte de una expresión dentro de la constructora de filas. Por ejemplo, considérese esta consulta: Listar el mímero 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')
Bajo las reglas nonnales del procesamiento de consultas SQL, la cláusula WHERE se aplica a cada fila de la tabla PEDIDOS, una a una. La primera constructora de la cláusula WHERE (a la izquierda del signo igual) genera una fila de dos columnas que contiene el código de fabricante y el número 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 código (literal) del fabricante ACI y el número de producto 41002. El signo igual compara ahora dos filas de valores, no dos valores escalares. El estándar SQL2 define este tipo de comparación de filas para la igualdad, que se procesa comparando una por una cada columna de las dos filas. El resultado de la comparación 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 número de pedido, la cantidad y el importe de todos los pedidos de zapatas ACf-41002.
244
Capítulo 9: Subconsultas y expresiones de consultas
SOL. Manual de referencia
SELECT NUM_PEDIDO, CANTIDAD,
SELECT NUM_PEDIDO,
IMPORTE
(FAS = 'ACI')
FECHA_PEDIDO
FROM PEDIDOS
FROM PEDIDOS
WHERE
245
AND
(PRODUCTO =
'41002')
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 simplificación de la apariencia de consultas más complejas, y pueden llegar a ser incluso más útiles al combinarlas con sub· consultas que devuelven filas. 5ubconsultas que devuelven filas 150L2) Como se ha descrito anteriormente en este capítulo, el estándar SQLI proporciona las subconsultas para expresar consultas más 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 expresión dentro de la instrucción 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 estándar SQL2 expande drásticamente la capacidad de las subconsultas incluyendo el soporte de subcollsultas que devuelven filas. Una subconsulta que devuelve filas devuelve no sólo 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, supóngase que se desea mostrar los números de pedido y las fechas de todos los pedidos formulados del producto más caro de la base de datos de ejemplo. Una forma lógica de empezar a construir la consulta SQL apropiada sería encontrar una expresi6n que proporcione la identidad (ID de fabricante y de producto) del producto más caro en cuesti6n. A continuación se muestra una consulta que halla el producto correcto:
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)
Ignorando la posibilidad de varios productos con el mismo precio máximo, 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 instrucción SELECT para obtener la información del pedido:
Listar los .números y fechas de lodos los pedidos formulados para el producto con el mayor precio unitario.
WHERE {FAB,
PRODUCTO}
:
(SELECT ID_FAS, ID_PRODUCTO FROM PRODUCTOS WHERE PRECIO = (SELECT MAX(PRECIO) PROM PRODUCTOS»
La cláusula WHERE más externa de esta consulta contiene una comparación 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 cláusula WHERE para resolver la consulta externa, el valor de esta expresión 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 expresión de filas de la parte izquierda del signo igual. Es posible expresar esta consulta sin la subconsulta que devuelve filas, pero la consulta resultante sería mucho menos inmediata:
Listar los números 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»))
En lugar de una comparación de una única fila en la cláusula 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 comparación se debe dividir, la subconsulta interna para hallar el precio máximo se debe repetir también. En general. la forma de la consulta que usa la expresión de filas es una traducción más directa de la solicitud en lenguaje natural, y es más fácil de leer y comprender. Comparaciones de filas (50L2) El uso más habitual de las expresiones de filas en la cláusula 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 (quizás 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 estándar SQL2 también pro-
246
SOL. Manual de referencia
Capítulo 9: Subconsultas y expresiones de consultas
pordona dos formas para los tests de comparación de desigualdad y de rangos. Al comparar dos filas según su igualdad, SQL2 usa las mismas reglas que se usarían 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 comparación se centra en la segunda fila, después en la tercera y así sucesivamente. A continuación se muestran las comparaciones resultantes de las filas construidas de tres columnas derivadas de la tabla
Nótese que las filas individuales de la constructora de tablas no se restringen a sólo 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 instrucción legal INSERT de SQL2 que ilustra estas capacidades:
('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
Expresiones de tablas (50L2) Añadir tres oficinas a la tabla Además de las capacidades extendidas para las expresiones que contienen valores simples de datos escalares y valores de filas, el estándar SQL2 amplía espectacularmente las capacidades de procesamiento de consultas SQL para el procesamiento de tablas. Proporciona un mecanismo para la construcción de una tabla de valores de datos dentro de una instrucción SQL. Permite subconsultas que devuelven tablas y amplia los test de las subconsultas SQLl para manejarlas. También permite que aparezcan subconsultas en muchos otros lugares dentro de llna instrucción SQL -por ejemplo, una subconsulta puede aparecer en la cláusula FROM de una instrucción SELECT como sus tablas fuente-o Finalmente, proporciona capacidades desarrolladas para la combinación de tablas, incluyendo las operaciones UNIaN, INTERSECTION
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)
Como en el ejemplo anterior, la cláusula VALUES de esta instrucción 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 número 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 cláusula 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 región de la oficina de Navarra (número 12).
y DIFFERENCE.
La constructora de tablas (SQL2)
SQL2 permite especificar una tabla de valores de datos dentro de una instrucción SQL usando una expresión constructora de tablas, cuya sintaxis se muestra en la Figura 9.15. En su forma más 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 instrucción INSERT de SQL2 usa una constructora de tablas como la fuente de datos a insertar en una base de datos. Mientras que la instrucción INSERT de SQLI (descrita en el Capítulo 10) permite insenar sólo una única fila de datos; la instrucción INSERT de SQL2 insena tres filas en la tabla OFICINAS.
~VALUESlconstructo:a-de-fiIasJ
Figura 9.15.
OFICINAS.
Subconsultas que devuelven tablas (SQL2)
Así como SQL2 expande el uso de subconsultas que devuelven escalares en subconsuItas que devuelven filas, también 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 cláusula WHERE o HAVING, donde se combina con formas extendidas de los tests de subconsultas. Por ejemplo, supóngase 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. Quizás la forma más inmediata de expresar esta solicitud sea en esta instrucción SQL2 que usa una subconsulta que devuelve tablas:
lO
Listar la descripción y el precio de todos los productos con pedidos individuales superiores a 20.000 €.
"Diagrama sintáctico de la constructora de tablas SOL2.
1
248
SOL Manual de referencia
SELECT DESCRIPCION.
Capítulo 9: $ubconsultas y expresiones de consultas
PRECIO
FROM PRODUCTOS
WHERE (ID_FAB.
ID_PRODUCTO)
IN (SELECT FAB,
PRODUCTO
FROM PEDIDOS
r--
SELECT
I
1
I
nombre-de-tabla
WHERE IMPORTE> 20000.00l
*rl
expresión-de valor
La consulta externa es una representación inmediata de la solicitud en lenguaje natural-pide la descripción y el precio de los productos cuya identificación (como en los ejemplos previos, un par ID de fabricante/ID de producto) coincide con algún conjunto de productos. Esto se expresa corno un test de pertenencia a conjuntos de la subconsulta en la cláusula 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 Capítulo 7 se desprende que se puede expresar como la reunión de las tablas PRODUCTOS Y PEDIDOS con una condición de búsqueda compuesta:
Listar la descripción y el precio de lOdos los productos con pedidos individua· les superiores a 20.000 €. SELECT FROM WHERE ANO ANO
Ésta es una instrucción igualmente válida, pero se ha eliminado más de la con· sulta en lenguaje natural y por tanto es más difícil de comprender para la mayoría de las personas. Al hacerse más complejas las consultas, la capacidad de usar sub· consultas que devuelven tablas llega a ser incluso más útil que la simplificación y clarificación de solicitudes SQL. La especificación de consulta en SQL2
El estándar SQL2 formaliza la definición de lo que informalmente hemos estado denominando instrucción SELECT o una consulta en los últimos tres capítulos en un bloque constructor denominado especificación de consulta. Para una completa comprensión de las capacidades de expresión de tablas en SQL2, es útil comprender esta definición formal. La forma de una especificación de consulta en SQL2 se muestra en la Figura 9.16. Sus componentes deberían resultar familiares por los capítulos anteriores: • Una lista de selección especifica las columnas de los resultados. Cada columna se especifica con una expresión que dice al SGBD cómo calcular su valor. Se puede asignar un alias opcional a la columna con una cláusula AS . • Las palabras clave ALL y UNIQUE controlan la eliminación de filas duplicadas de los resultados.
PROM
:::r-----------------l - respeCifjca';.c~;o:·n=.:d:e=' tab'!J I
[ WHERE condiciÓn·de·
búsqueda
Figura 9.16.
~
I
f
[GROUP BY
lista·decolumnas
TIHAVING
condición-de· j búsqueda
Especificación de consulta en SQL2: definición formal.
• La cláusula FROM especifica las tablas que contribuyen a los resultados de la consulta. • La cláusula WHERE describe cómo el SGBD debería determinar las columnas que se incluyen en los resultados y las que se descartan. • Las cláusulas GROUP BY y HAVING unidas controlan la agrupación de resultados de consultas individuales en una consulta de agrupación, y la selección de grupos de filas para la inclusión o exclusión en los resultados finales. La especificación de una consulta es el bloque constructor básico en el están· dar SQL2. Conceptualmente describe el proceso de combinar datos de las tablas de la cláusula FROM en una tabla de filas y columnas de resultados. El valor de la especificación de una consulta es una tabla de datos. En el caso más simple, una especificación de consulta en SQL2 consiste en una especificación simple de consulta. En un caso un poco más complejo, se usa una especificación de consulta para describir una subconsulta, que aparece dentro de otra especificación de consulta (externa). Finalmente, las especificaciones de consulta se pueden combinar usando operaciones de tablas para formar expresiones de consulta de propósito general, como se describe en la siguiente sección.
Expresiones de consulta (SOL2) El estándar SQL2 define una expresión de consulta como la forma completa y de propósito general con la que se puede especificar una tabla de resultados en el
250
SOL. Manual de referencia
lenguaje SQL2. Los bloques constructores básicos que se pueden usar para crear una expresión de consulta son los siguientes: • Una especificación 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 explícita 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 explícito 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 Capítulo 7. Una operación JOIN toma dos tablas como entrada y produce una tabla de resultados de consulta combinados de acuerdo con la especificación de la reunión. • UNION. La operación UNION de SQL2 proporciona soporte explícito para la mezcla de filas de dos tablas compatibles (es decir, dos tablas con el mismo número de columnas y con los mismos tipos de datos en las columnas correspondientes). La operación UNION toma dos tablas como entrada y produce una única tabla mezclada de resultados de consulta. • DIFFERENCE. La operación 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 operación 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 operación 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.
Capítulo 9: Subconsultas y expresiones de consultas
251
(SELECT FAS, PRODUCTO FROM PEDIDOS WHERE IMPORTE> 30000.00) UNION (SELECT ID_FAB. ID_PRODUCTO FROM PRODUCTOS WHERE (PRECIO * STOCK) > 30000)
Mostrar todos los productos para los que hay un pedido superior a 30.000 € Y más 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 €.
UII
pedido superior a 30.000 €.
(SELECT FAB, PRODUCTO FROM PEDIDOS WHERE IMPORTE> 30000.00) EXCEPT (SELE~T ID_FAS, ID_PRODUCTO FROM PRODUCTOS WHERE PRECIO < 100,00€)
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 eliminación de filas duplicadas. Esto se puede hacer especificando las formas UNION ALL, INTERSECT ALL y EXCEPT ALL de las operaciones. Nótese 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 tendrán siempre el mismo nombre en cada una de las tablas a combinar. Como conveniencia, SQL2 permite especificar las columnas correspondientes en una cláusula CORRESPONDING unida a la operación UNION, INTERSECT o EXCEPT. A continuación se muestra el ejemplo anterior de UNJON modificado para la situación en la que las tabla~ PEDIDOS Y PRODUCTOS tienen nombres de columna paralelos para el ID de fabricante y de producto: M
Las operaciones UNION, INTERSECT y DIFFERENCE de SQL2 Las operaciones UNION, INTER5ECT y DIFFERENCE de SQL2 proporcionan operaciones de conjunto para la combinación de dos tablas de entrada para formar una tabla de salida. Las tres operaciones requieren que las dos tablas de entrada sean compatibles bajo unión -deben tener el mismo número de columnas, y las columnas correspondientes de cada tabla deben tener tipos de datos idénticos-o A continuación se muestran unos ejemplos simples de expresiones de consulta en SQL2 con las operaciones UNlüN, INTERSECT y DIFFERENCE en términos de la base de datos de ejemplo:
Mostrar todos los productos para los que hay un pedido superior a 30.000 € o más de 30.000 € de stock disponible.
252
SOL. Manual de referencia
Capítulo 9: $ubconsultas y expresiones de consultas
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.
PRODUCTO)
¡SELECT • PROM PRODUCTOS
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 operación UNION, SQL2 incluso permite dejar vacía la lista explícita 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
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 especificación de una consulta se puede usar para renombrar o asignar nombres a las columnas de resultados de consultas individuales que se combinan con la operación UNION. Si se elimina el supuesto de que las tablas PRODUCTOS y PEDIDOS usan los mismos nombres de columna, aún es posible usar la forma coRRESPONDING de la operación 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 más general en que las consultas conllevan columnas calculadas o son consultas de agrupación, la cláusula CORRESPQNDING y los alias de columna pueden ayudar a clarificar el significado de la consulta.
253
Expresiones de consulta en la cláusula FRDM
Las expresiones de consulta SQL2 proporcionan un método mucho más potente y flexible para generar y combinar tablas de resullados que la simple subconsulta y las operaciones UNION proporcionadas por el estándar SQL l. Para hacer que las expresiones de consulta sean incluso más útiles y de propósito general, el estándar SQL2 permite que aparezcan casi en cualquier lugar en que pueda aparecer una referencia a tabla en una consulta SQL1. En panicular, una expresión de consulta puede aparecer en lugar del nombre de una tabla en la cláusula FROM. A continuación se muestra un ejemplo simple de una consulta SQL2 para la base de datos de ejemplo que usa esta característica: Mostrar los Ilombres y el total de los mejores pedidos de los cliellles con límires de crédito 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)
El segundo <
254
SOL. Manual de referencia
no de consultas puede ser muy diferente del plan aparente de la instrucción SQL real, pero al producir los mismos resultados, el efecto neto es trasladar la sobrecarga debida a la optimización de las personas al SGBD.
Consultas SaL: un resumen final Esto concluye el estudio de las consultas SQL y de la instrucción SELECT que comenzó en el Capítulo 6. Como se describió en los capítulos 6 al 9, las cláusulas de la instrucción SELECT proporcionan un conjunto potente y flexible de capacidades para la recuperación de datos de la base de datos. Cada cláusula desempeña un papel específico en la recuperación de datos:
Parte flI
ACTUALIZACiÓN DE DATOS
• La cláusula FRQM especifica las tablas fuente que aportan datos a los resultados. Cada nombre de columna en el cuerpo de la instrucción SELECT debe identificar sin ambigüedades una columna de estas tablas, o debe ser una referencia externa a una columna de una tabla fuente de una consulta externa. • La cláusula 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 cláusula WHERE se evalúan para cada fila individual. • La cláusula GROUP BY, si se encuentra, agrupa las filas individuales seleccionadas por la cláusula WHERE en dos grupos. • La cláusula HAVING, si se encuentra, selecciona grupos de filas para participar en los resultados de la consulta. Las subconsultas en la cláusula HAVING se evalúan por cada grupo de filas. • La cláusula 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 cláusula ORDER BY, si se encuentra, ordena los resultados finales en términos de una o más columnas. • Las capacidades de expresión de consultas en SQL2 añaden 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.
SQL no es sólo un lenguaje de consultas, sino que además 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 añaden, eliminan y modifican datos de una base de datos. El Capítulo II describe la forma en que SQL mantiene la integridad de los datos almacenados cuando éstos se modi~can. El Capítulo 12 describe las características de procesamiento de transaccI~nes con SQL que permiten actualizaciones simultáneas de la base de datos debidas a diferentes usuarios.
1:
t
L
CAPíTULO
10
Actualizaciones de la base de datos
'.
SQL es un lenguaje completo para la manipulación de datos que no sólo se utiliza para las consultas a bases de datos, sino también para modificar y actualizar los mismos. En comparación con la complejidad de la instrucción 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 válidos y que la base de datos siga siendo autoconsistente, incluso en caso de fallos del sistema. El SGBD también debe coordinar las actualizaciones simultáneas realizadas por varios usuarios, asegurándose de que los usuarios y sus modificaciones no interfieran entre sí. Este capítulo describe las tres instrucciones de SQL que se utilizan para modificar el contenido de las bases de datos: • INSERT. • DELETE. • UPDATE.
Añade nuevas filas de datos a las tablas. Elimina filas de datos de las tablas. Modifica los datos de las bases de datos.
En el Capítulo 11 se describen los servicios de SQL para el mantenimiento de la integridad de los datos. El Capítulo 12 trata del soporte de SQL cuando concurren varios usuarios.
Adición de datos a la base de datos Se suele añadir 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
SOL. Manual de referencia
Capítulo 10: Actualizaciones de la base de datos
• Cuando se contrata a un nuevo representante, hay que añadir una fila nueva a la tabla REPRESENTANTES para almacenar sus datos. • Cuando un representante suscribe a un nuevo cliente, hay que añadir una fila nueva a la tabla CLIENTES, que representa a ese cliente nuevo. • Cuando un cliente realiza un pedido, hay que añadir 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 Juárez, con los datos personales siguientes: Nombre: Edad: Número de empleado: Puesto: Oficina: Fecha de contratación: Cuota: Ventas durante el año en curso:
En cada caso se añade la fila nueva para que la base de datos siga siendo un modelo preciso del mundo real. La unidad de datos más pequeña que puede añadirse a una base de datos relacional es una sola fila. En general, los SGBD basados en SQL proporcionan tres maneras de añadir filas de datos a las bases de datos: sobre una única fila. La instrucción INSERT sobre una única fila añade una sola fila de datos nueva a una tabla. Suele emplearse en las aplicaciones cotidianas -por ejemplo, programas de introducción de datos. • INSERT sobre varias filas. La instrucción INSERT sobre varias filas extrae filas de datos de otra parte de la base de datos y las añade a una tabla. Suele emplearse en procesamientos de fin de mes o de fin de año, 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 añade 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 infonnático o recopilados desde varios sitios. • INSERT
La instrucción IN5ERT sobre una sola fila La instrucción INSERT sobre una sola fila, que puede verse en la Figura 10.1, añade una fila nueva a una tabla. La cláusula INTD especifica la tabla que recibe la nueva fila (la tabla destino), y la cláusula 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 nombre·detabla
---r----------:r-----,
Ésta es la instrucción ejemplo:
INSERT
Herminio Juárez
36 111 Jefe de ventas Almería (oficina número 13) 25 de julio de 1990 Por asignar 0,00 €
que añade a Don Herminio a la base de datos de
AJiadir a Herminio Juárez como nuevo representante. INSERT INTO REPRESENTANTES (NOMBRE, EDAD, NUM_EMPL, VENTAS, PUESTO, FECHA_CONTRATO, OFICINA_REP) VALUES (' Herminio Juárez', 36, 111, 0.00, 'Jefe Ventas', '25-JUL-90', 13) 1 fila
insertada.
La Figura 10.2 ilustra de manera gráfica el modo en que SQL ejecuta la instrucción IN5ERT. Conceptualmente, la instrucción INSERT crea una sola fila de datos que coincide con la estructura de columnas de la tabla, la rellena con los datos de la cláusula VALUES y, luego, añade la nueva fila a la tabla. Las filas de las tablas no están ordenadas, por lo que no existe el concepto de inserción de la fila en la parte superior de la tabla, en la inferior o entre dos filas. Tras la instrucción 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. Supóngase que Don Herminio recibe ahora su primer pedido, de InterCorp, un nuevo cliente al que se le asigna el número de cliente 2126. El pedido es de veinte cables ACI-41004, con un importe total de 2.340 € Y se le ha asignado el número de pedido 113069. Éstas son las instrucciones INSERT que añaden a la base de datos el nuevo cliente y el pedido:
nombre-de(~/um~)
Insertar un nuevo cliente y un pedido par'!.. Don Herminio.
,
INSERT INTO CLIENTES (EMPRESA. NUM_CLI. LIMITE_CREDITO, VALUES ('InterCorp'. 2126, 15000.00. 111) VALUES ( T I c o n s t a n t 8 1 1 ) - - - - - - - - - - - -__ ••
~NULL~
,
Figura 10.1.
Diagrama sintáctico de la instrucción INSERT sobre una sola fila.
bprese:l,anu 12-OCT_89 Repre.""tanu IO-DIC-86 U-JUN-88 J9-MI,Y·67 bp
J.r. ven,..
""" I
-". '" ", ",
~u
'" '" ", ."
'"
NULLI
0.00
I
261
en esa tabla, o la instrucción INSERT fallará. El esquema de seguridad y los permisos de SQL se describen en el Capítulo 15. La finalidad de la lista de columnas de la semencia INSERT es que coincidan Jos valores de los datos de la cláusula VALUES con las columnas que los van a recibir. La lista de valores y la lista de columnas deben contener el mismo número 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 estándar 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 ambigüedad en los nombres de las columnas, ya que todos deben hacer referencia a nombres de columnas en la tabla destino. Inserción de valores NULL
~.
~~
3S0.00G,OO€
367.U1.00€
lOO.OOO.Dae
J92.125,OO€
350.000,ooE
474.050,OO€
275.000.00€
299.H2.DaE
2Do.oaO,ooe
H2.59 •• 00€
lOO.OaO.OOE
30S.613.00€
3S0.0aO.ooe 275.000.00€ lOO.OOG.GG€
15".85.00€ 361.165.00€ 211i.715.GG€ 186.0'2.GO€
,=,
Inserción de una sola fila.
Cuando SQL inserta en una tabla una nueva fila de datos, asigna de manera automática un valor NULL a todas las columnas cuyo nombre no se halle en la lista de columnas de la instrucción INSERT. En esta instrucción INSERT, que añadió 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 Juárez' , 36, 111. 0.00, 'Jefe Ventas', '25-JUL-90', 13)
En consecuencia, la fila recién añadida tiene un valor NULL en las columnas y JEFE. como puede verse en la Figura 10.2. Se puede hacer más explícita la asignación de valores NULL incluyendo estas columnas en la lista de columnas y especificando la palabra clave NULL en la lista de valores. Esta instrucción INSERT tiene exactamente el mismo efecto que la anterior: CUOTA
Como muestra este ejemplo, la instrucción INSERT puede hacerse muy larga si hay muchas columnas de datos, pero su formato sigue siendo muy directo. La segunda instrucción INSERT utiliza la constante de sistema CURRENT_DATE en su cláusula VALUES, lo que hace que se inserte la fecha actual como fecha del pedido. Esta constante del sistema se especifica en el estándar SQL2 y la incluyen muchos de los productos SQL más 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 instrucción INSERT con SQL interactivo para añadir filas a una tabla que aumenta de tamaño muy raras veces, como la tabla OFICINAS. En la práctica, sin embargo, los datos sobre los nuevos clientes, pedidos o representantes se añaden casi siempre a la base de datos mediante un programa de introducción de datos orientado a los formularios. Cuando se concluye la introducción de datos, el programa de aplicación inserta la nueva fila de datos empleando SQL para programación. Independientemente de si se emplea SQL interactivo o para programación, la instrucción INSERT es la misma. El nombre de tabla especificado en la instrucción INSERT suele ser un nombre de tabla no calificado, que especifica una tabla que posee el usuario. Para insertar datos en una .tabla poseída por otro usuario se puede especificar un nombre de tabla calificado. Por supuesto, también hay que tener permiso para insertar los datos
Como un servicio más, SQL permite omitir la lista de columnas de la instrucción INSERT. Cuando se omite la lista de columnas, SQL genera de !llanera automática 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 instrucción INSERT anterior como: INSERT INTO REPRESENTANTES VALUES (111, 'Herminio Juárez' , 36, 13, '25-JUL-90', NULL. NULL, 0.00)
'Jefe Ventas'-,
262
Capítulo 10: Actualizaciones de la base de datos
SOL. Manual de referencia
Cuando se omite la lista de columnas hay que utilizar la palabra clave NULL en la lista de valores para asignar de manera explícita valores NULL a las columnas, como puede verse en el ejemplo. Además, la secuencia de valores de datos debe corresponder exactamente con la secuencia de columnas de la tabla. La omisión de la lista de columnas es conveniente en SQL interactivo porque reduce la longitud de la instrucción INSERT que hay que escribir. Para SQL con programación la lista de columnas se debe especificar siempre, ya que bace el programa más fácil de leer y de comprender. Además, 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 explícita de columnas puede funcionar bien durante meses o años y. de repente. comenzar a generar errores si algún administrador de la base de datos modifica el número o los tipos de datos de las columnas.
La instrucción INSERT sobre varias filas La segunda forma de la instrucción INSERT, que puede verse en la Figura 10.3. añade varias filas de datos a su tabla destino. En esta forma de la instrucción INSERT los valores de los datos de las filas nuevas no se especifican de manera explícita dentro del texto de la instrucción. En vez de eso. el origen de las nuevas filas es una consulta a una base de datos, especificada en la instrucción. La adición de filas cuyos valores provienen de la misma base de datos puede parecer, en principio, extraña, pero resulta muy útil en algunas situaciones especiales. Por ejemplo, supóngase que se desea copiar el número 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 instrucción INSERT sobre varias filas proporciona una manera concisa y eficiente de copiar los datos:
Copiar los pedidos antiguos a la tabla PEDIDOSANTIGUOS. INSERT INTO SELECT FROM WHERE
Esta instrucción INSERT parece complicada, pero, realmente, es muy sencilla. La instrucción identifica la tabla que va a recibir las filas nuevas (PEDIDOSANTIGUOS) y las columnas que van a recibir los datos. igual que en la instrucción INSERT sobre una sola fila. El resto de la instrucción es una consulta que recupera los datos de la tabla PEDIDOS. La Figura 10.4 ilustra gráficamente la opera· tiva de esta instrucción 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 situación en la que se puede utilizar la instrucción INSERT sobre varias filas. Supóngase 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 ejecutarán combinarán datos de las tablas CLIENTES, REPRESENTANTES Y PEDIDOS. Estas consultas a las tres tablas se ejecutarán bastante rápido en nuestra pequeña base de datos de ejemplo, pero en una base de datos empresarial real, con muchos millares de filas. tardarían 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 página 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
113049 112987 113057 113042
10-FEB-90 31-DIC-89 lB-FEB-90 02-FEB-90
2118
IMPORTE)
9 filas insertadas.
2103 2111 2113
PROOOC'!'t
''''" "" '" '" m ,,, ,,,,,, '"'"'" '"Q"
2A44L 41003
'"
Q" XK47
,C> 4l00Y
'" '" '" '"' '"
4l00X 2A44R
""'~
, ," • 2 U
",
1"
31.500.00 27.500,00 600,00 22.500.00
I
Diagrama sintáctico de la instrucción INSERT
sob~e
varias filas.
Consulta SELECT NUloLPEDIDO. FECIlA....PEOlOO, IMPORTE FROM PEDIDOS WHERE FECf!A.-PEDlDO <: • 01-ENE-90'
Resultados de la consulta NUlLPEDI
FECI\A.-PEDlOO
112961 17-DIC-B9 112968 12--ocT-89
IH.PORTE 31.500.00 3.978.00
112993 04-ENE-89 112987 3l-DIc-89
1.896.00 27.500.00
,
=oJ-consulta~.
(~um~)
Figura 10.3.
IMPORTE 31.500.00 3.745.00 1.458,00 1.420,00
Tabla PEDIDOSjoNI'IGUOS f,'UM..-PEDIDO FECHA.-PEDIDO IMPORTE
nombre·
263
Figura 10.4.
Inserción de varias filas.
1
264
111
Capítulo 10: Actualizaciones de la base de datos
SOL. Manual de referencia
• Los resultados de la consulta deben contener el mismo número de columnas que la lista de columnas de la instrucción 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. Sólo se puede especificar una instrucción SELECT. • La tabla destino de la instrucción INSERT no puede aparecer en la cláusula FROM de la consulta ni de ninguna subconsulta que pueda conte::", r. Esto prohíbe la inserción en la propia tabla de una parte de sí.
Información sobre las columnas
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)
IMPORTE EMPRESA NOMBRE REND FAB
PRODUCTO CANTIDAD
Una vez creada la tabla PEDIDOSGRANDES. se puede utilizar la instrucción SERT sobre varias filas para rellenarla:
Cargar los datos para su análisis en la tabLa
Las dos primeras restricciones son estructurales, pero las dos últimas se incluyeron en el estándar simplemente para evitar complejidades. En consecuencia, estas restricciones se relajaron en el estándar SQL2. El estándar permite hoy en día operaciones UNION y JO IN y expresiones en la consulta, permitiendo básicamente que los resultados de una consulta general a la base de datos se recuperen y se inserten en una tabla con la instrucción INSERT. También permite varias formas de autoinserción, en las que la tabla origen de los datos que hay que insertar y la tabla destino son la misma.
IN-
PEDIDOSGRANDES.
INSERT INTO PEDlDOSGRANDES SELECT FAS, WHERE AND AND
, Utilidades de carga masiva Los datos que hay que insertar en una base de datos suelen descargarse de otro sistema informático 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 instrucción INSERT sobre una sola fila para añadir 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 inserción 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 rápidamente 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 más de seis horas. Por este motivo la mayor parte de los productos SGBD comerciales incluyen una característica de carga masiva que carga en una tabla los datos de un archivo a gran velocidad. El estándar SQL ANSI/ISO no incluye esta función, y suele ofrecerse más bien como un programa de utilidad independiente que como parte del lenguaje SQL. La utilidad de cada fabricante ofrece un conjunto de características, funciones y comandos ligeramente diferente. Cuando se utiliza SQL desde el interior de un programa de aplicación 'se suele ofrecer otra técnica para insertar de manera más eficiente una gran cantidad de datos en una base de datos. La instrucción de programación INSERT estándar 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 más filas (a menudo hasta de centenares de filas) como parte de una sola instrucción INSERT masiva. Todos los
6 filas insertadas.
En una base de datos de gran tamaño esta instrucción INSERT puede tardar un rato en ejecutarse porque implica una consulta a tres tablas. Cuando se complete la instrucción, los datos de la tabla PEDIDOSGRANDES duplicará la infonnación de otras tablas. Además, la tabla PEDIDOSGRANDES no se actualizará de manera automática cuando se agreguen a la base de datos nuevos pedidos, por lo que sus datos se pueden quedar rápidamente desactualizados. Cada uno de estos factores parece un inconveniente. Sin embargo, las consultas para el análisis de los datos posteriores a la tabla PEDIDOSGRANDES pueden expresarse de manera muy sencilla -se transforman en consultas a una sola tabla. Además, cada una de estas consultas se ejecutará mucho más rápido que si fuera una reunión de tres tablas. En consecuencia, probablemente se trate de una buena estrategia para llevar a cabo el análisis, especialmente si las tres tablas originales son de gran tamaño. En esta situación es probable que la tabla PEDlOOSGRANDES se utilice como tabla temporal para la realización del análisis. Se creará y llenará·de datos, que representarán una instantánea del estado de los pedidos en un momento dado, se ejecutarán los programas de análisis y luego la tabla se vaciará o se desechará. El estándar SQLI especifica varias restriccioñes lógicas para la consulta que aparece dentro de la instrucción INSERT sobre varias filas: • La consulta no puede contener ninguna cláusula ORDER BY. En todo caso, resulta inútil ordenar los resultados de la consulta, ya que se van a insertar en una_tabla que, como todas las tablas, carece de orden.
~
265
-
266
Capítulo 10: Actualizaciones de la base de datos
SOL Manual de referencia
datos proporcionados deben ser para filas nuevas de la única tabla que es el destino de la instrucción INSERT, y debe nombrarse en la cláusula INTO. La ejecución de una instrucción 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 más eficiente. ya que sólo 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 más respecto de las instrucciones INSERT sobre una sola fila, en función de la marca del SGBD y del tipo concreto de datos que se esté insertando.
Eliminación 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, también hay que eliminar sus filas de la tabla REPRESENTANTES. Si se los traslada, hay que actualizar sus columnas OFICIN~REP.
.--------+••
~DELETE FROM nombre-tabla-r
.
L
Figura 10.5.
267
WHERE
c~ndici6n~bÚSqUeda]
Diagrama sintáctico de la instrucción DELETE.
La cláusula WHERE de este ejemplo identifica una sola fila de la tabla REPREque SQL elimina de la tabla. La cláusula WHERE debería tener un aspecto familiar -se trata, exactamente, de la misma cláusula WHERE que se especifica en las sentencias SELECT para recuperar la misma fila de la tabla-. Las condiciones de búsqueda que pueden especificarse en la cláusula WHERE de la instrucción DELETE son las mismas disponibles en la cláusula WHERE de la instrucción SELECT, como se describe en los capítulos 6 y 9. Recuérdese que las condiciones de búsqueda de la cláusula WHERE de las sentencias SELECT puede especificar una sola fila o un conjunto de filas, según la condición de búsqueda concreta. Lo mismo puede decirse de la cláusula WHERE de las sentenCias DELETE. Supóngase, por ejemplo. que el cliente de Don Herminio, InterCorp (número de cliente 2126), ha llamado para cancelar todos sus pedidos. A continuación se muestra la sentencia DELETE que elimina los pedidos de la tabla SENTANTES,
PEDIDOS:
Eliminar todos los pedidos de InterCorp (número de cliente 2126). 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 más pequeña que puede eliminarse de una base de datos relacional es una sola fila.
La instrucción
DELETE FROM PEDIDOS WHERE CLIENTE ~ 2126 2 filas eliminadas.
DELETE
La instrucción DELETE, que puede verse en la Figura 10.5, elimina las filas de datos seleccionadas de una sola tabla. La cláusula FROM especifica la tabla destino que contiene las filas. La cláusula WHERE especifica las filas de la tabla que deben eliminarse. Supóngase que Herminio Juárez, el nuevo representante contratado anteriormente en este capítulo, acaba de decidir abandonar la empresa. La instrucción DELETE que elimina su fila de la tabla REPRESENTANTES se muestra a continuación.
Eliminar a Herminio Juárez de la base de datos. DELETE FROM REPRESENTANTES WHERE NOMBRE ~ 'Herminio Juárez' 1 fila eliminada.
En este caso, la cláusula WHERE selecciona varias filas de la tabla PEDIDOS, y SQL elimina de la tabla todas las filas seleccionadas. Conceptualmente, SQL aplica la cláusula WHERE a cada fila de la tabla PEDIDOS, elimina aquellas en las que la condición de búsqueda da un resultado TRUE y conserva aquellas en las que la condición de búsqueda da un resultado FALSE o NULL. Como este tipo de instrucción DELETE busca en la tabla las filas que hay que eliminar, a veces se denomina instrucción DELETE con búsqueda. Este término se usa para diferenciarla de otra forma de la instrucción DELETE, denominada instrucción DELETE posicionada, que siempre elimina una sola fila. La instrucción DELETE posicionada sólo se aplica a SQL para programación y se describe en el Capítulo 17. A continuación se ofrecen varios ejemplos más de instrucciones DELETE con búsqueda:
268
SOL. Manual de referencia
Eliminar todos los pedidos realizados antes del 15 de noviembre de 1989. FROM PEDIDOS WHERE FECHA_PEDIDO
Capítulo 10: Actualizaciones de la base de datos
se de que son las que se desea eliminar y, s610 enlonces, utilizar la cláusula en una instrucción DELETE.
269 WHERE
DEL~TE
<
'lS-NOV-89'
DELETE con subconsulta
5 filas eliminadas.
Eliminar lodas las filas de los clientes atendidos por Bruno Arteaga, María Jiménez o Daniel Ruidrobo (números de empleado 105, 109 Y JOl). DELETE FROM CLIENTES WHERE REP_CLI IN
(lOS,
109,
101)
7 filas eliminadas.
Eliminar todos los representantes contratados antes de julio de 1988 a los que no se les ha asignado todavía cuota.
Las instrucciones DELETE con condiciones de búsqueda sencillas, como las de los ejemplos anteriores, seleccionan las filas para su eliminación con base únicamente en el contenido de las propias filas. A veces la selección de filas debe hacerse en términos de datos de otras tablas. Por ejemplo, supóngase que se desea eliminar todos los pedidos tramitados por Susana' Santos. Sin conocer su número 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:
Hallar los pedidos tramitados por Susana Santos.
DELETE FROM REPRESENTANTES WHERE FECHA_CONTRATO < 'Ol-JUL-8S' AND CUOTA 15 NULL
SELECT FROM WHERE AND
o filas eliminadas.
NUM_PEDIDO
Eliminación de todas las filas La cláusula WHERE de las instrucción DELETE es opcional, pero casi siempre se halla presente. Si se omite la cláusula WHERE de una instrucción DELETE, se eliminan todas las filas de la tabla destino, como ocurre en este ejemplo:
Eliminar todos los pedidos. DELETE FROM PEDIDOS 30 filas eliminadas.
Aunque la instrucción DELETE produce una tabla vacía, no elimina la tabla PEDIDOS de la base de datos. La definición 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 definición de la tabla hay que utilizar la instrucción DROP TASLE (que se describe en el Capítulo 13). Debido al daño potencial que puede causar una instrucción DELETE de este tipo hay que tener la precaución de especificar siempre una condición de búsqueda y de asegurarse de que realmente selecciona las filas que se desea eliminar. Al utilizar SQL interactivo resulta una buena idea emplear primero la cláusula WHERE en una instrucción SELECT para mostrar las filas seleccionadas. Hay que asegurar-
Pero no se puede utilizar una reunión en una instrucción ción DELETE paralela es ilegal:
DELETE.
La instruc-
DELETE FROM PEDIDOS, REPRESENTANTES WHERE REP = NUM_EMPL ANO NOMBRE = 'Susana Santos' Error: se ha especificado más de una tabla en la cláusula FROM
La manera de tratar esta solicitud es utilizar una de las condiciones de búsqueda de la subconsulta. A continuación puede verse una forma válida de la instrucción 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
SOL. Manual de referencia
Capítulo 10: Actualizaciones de la base de datos
La subconsulta halla el número de empleado de Susana Santos, y la cláusula WHERE selecciona los pedidos con el valor correspondiente. Como muestra este ejemplo, las subconsultas pueden desempeñar un papel importante en la instrucción DELETE, porque permiten eliminar filas en términos de la información de otras tablas. A continuación se ofrecen dos ejemplos más de instrucciones DELETE que milizan condiciones de búsqueda 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)
1 fila eliminada.
Las subconsultas en la cláusula WHERE pueden anidarse igual que en la cláusula WHERE de la instrucción SELECT. También pued.en contener referencias externas a la tabla destino de la instrucción DELETE. A este respecto, la cláusula FROM de la instrucción DELETE funciona igual que la cláusula FROM de la instrucción SELECT. A continuación se ofrece un ejemplo de solicitud de eliminación 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')
271
de la fila de la tabla CLIENTES que está examinando la instrucción DELETE. La subconsulta de este ejemplo es una subconsulta correlacionada, como se describe en el Capítulo 9. Las referencias externas suelen hallarse en las subconsultas de las instrucciones DELETE, ya que implementan la reunión entre la(s) tablas(s) de la subconsulta y la tabla destino de la instrucción DELETE. En el estándar SQL1, una restricción del emple
Modificación 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 mínima de datos que puede modificarse en una base de datos es una sola columna de una única fila.
16 filas eliminadas.
Conceptualmente, esta instrucción DELETE opera fila a fila por la tabla CLIENY verificando la condición de búsqueda. 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 número de cliente
La instrucción
UPDATE
TES
La instrucción 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
Capítulo 10: Actualizaciones de la base de datos
SOL. Manual de referencia
273
WHERE OFICINA_REP = 12
l- UPDATE nombre-tabla SET
fnombre-co,umna
=
3 filas actualizadas.
expresión
I
En este caso la cláusula 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 instrucción UPDATE recorriendo la tabla REPRESENTANTES fila a fila, actualizando las filas para las que la condición de búsqueda 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 instrucción UPDATE se denomina a veces sentencia UPDATE con búsqueda. Este término la distingue de una forma diferente de la instrucción UPDATE, denominada instrucción UPDATE posicionada, que siempre actualiza una sola fila. La instrucción UPDATE sólo se aplica a SQL para programación y se describe en el Capítulo 17. A continuación se ofrecen varios ejemplos más de instrucciones UPDATE con búsqueda: TANTES
WHERE condición-de-búsqueda
•
I
• Figura 10.6.
Diagrama sintáctico de la instrucción
UPDATE.
que hay que actualizar se nombra en la instrucción, y hay que tener los permisos necesarios para actualizar la tabla y cada una de las columnas que vayan a modificarse. La cláusula WHERE selecciona las filas de la tabla que hay que modificar. La cláusula SET especifica las columnas que se van a actualizar y calcula sus nuevos valores. A continuación se ofrece un ejemplo de la instrucción que cambia el límite de crédito y el representante de un cliente:
Elevar el límite de crédito de Acme a 60.000 € Y reasignarlo a María Jiménez (número de empleado 109).
Reasignar todos los clientes atendidos por los números de empleado 105, 106 o 107 al empleado número 102. UPDATE CLIENTES SET REP_CLI = 102 WHERE REP_CLI IN (105, 106, 107) 5 filas actualizadas.
Asignar una cuota de 100.000 € a cualquier representante que no tenga cuota actualmente.
UPDATE CLIENTES
SET LIMITE_CRED1TO = 60000.00, WHERE EMPRESA = 'Acme'
REP_CLI
109
1 fila actualizada.
En este ejemplo la cláusula WHERE identifica una sola fila de la tabla CLIENTES, y la cláusula SET asigna valores nuevos a dos de las columnas de esa fila. La cláusula WHERE es exactamente la misma que se utilizaría en una instrucción DELETE o SELECT para identificar la fila. De hecho, las condiciones de búsqueda que pueden aparecer en la cláusula WHERE de las instrucciones UPDATE son exactamente las mismas que las disponibles en las instrucciones SELECT y DELETE. Al igual que la instrucción DELETE, la instrucción UPDATE puede actualizar varias filas al tiempo con la condición de búsqueda adecuada, como en este ejemplo:
Trasladar a todos los representantes de la oficina de Castellón (número 12) a la oficina de Navarra (número 11) Y bajar sus cuotas un diez por ciento. UPDATE REPRESENTANTES SET OFICINA_REP = 11, CUOTA
.9 * CUOTA
UPDATE REPRESENTANTES SET CUOTA = 100000.00 WHERE CUOTA 15 NULL 1 fila actualizada.
La cláusula SET de la instrucción UPDATE es una lista de asignaciones separadas por comas. Cada asignación identifica una columna destino que hay que actualizar y especifica el modo de calcular su nuevo valor. Cada columna destino sólo debe aparecer una vez en la lista; no debe haber dos asignaciones para la misma columna destino. La especificación 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 ambigüedad en los nombres de las columnas, ya que deben hacer referencia a las columnas de la tabla destino. La expresión de cada asignación puede ser cualquier expresión de SQL válida que dé como resultado un valor del tipo de datos adecuado para la columna destino. La expresión debe ser calculable en términos de los valores de la fila que se
274
SOL. Manual de referencia
Capítulo 10: Actualizaciones de la base de datos
esté actualizando en la tabla destino. En la mayor parle de las implementaciones de los SGBD la expresión no puede incluir funciones de columna ni subconsultas. Si una expresión de la lista de asignaciones hace referencia a una de las columnas de la tabla destino, el valor utilizado para calcular la expresión es el valor de esa columna en la fila actual antes de que se aplique ninguna actualización. Lo mismo ocurre con las referencias a columnas que tienen lugar en la cláusula WHERE. Por ejemplo, considérese la instrucción UPDATE (algo foriada):
<
400000.00, 400000.00
VENTAS
4 filas actualizadas.
CUOTA
Antes de la actualización, Bruno Arteaga tenía un valor de CUOTA de 350.000 € Y un valor de VENTAS de 367.911 €. Tras la actualización su fila tiene un valor de VENTAS de 350.000 €, no de 400.000 €. El orden de las asignaciones en la cláusula, por tanto, carece de importancia; las asignaciones pueden especificarse en cualquier orden.
Actualización de todas las filas La cláusula WHERE de la instrucción qPDATE es opcional. Si se omite la cláusula WHERE, se actualizan todas las filas de la tabla destino, como en este ejemplo:
/ncremenrar todas las cuotas un cinco por ciento.
10 filas actualizadas.
A diferencia de la instrucción DELETE, en la que la cláusula WHERE casi nunca se omite. la instrucción UPDATE sin cláusula WHERE lleva a cabo una labor útil. Básicamente, realiza una actualización masiva de toda la tabla, como se demuestra en el ejemplo anterior.
con subconsulta
UPDATE CLIENTES SET REP_CLI : lOS WHERE CUST_REP IN (SELECT NUM_EMPL FROM REPRESENTANTES WHERE VENTAS < (.8 • CUOTAl)
2 filas actualizadas.
Hacer que todos los representantes que atienden a más de tres cliellles informen directamente a Samuel Clavel (número de empleado /06). UPDATE REPRESENTANTES SET JEFE = 106 WHERE 3 < (SELECT COUNT{*) FROM CLIENTES WHERE REP_CLI
NUM_EMPL)
1 fila actualizada.
UPDATE REPRESENTANTES SET CUOTA = 1.05 * CQUOTA
UPDATE
UPDATE CLIENTES SET LIMITE_CREDITO = LIMITE_CREDITO + SOOO.OO WHERE NUM_CLI IN (SELECT DISTINCT CLIENTE FROM PEDIDOS WHERE IMPORTE> 25000.00)
Reasignar todos los clientes atendidos por representantes cuyas ventas estén por debajo del ochenta por ciento de su cuota.
UPDII.TE OFICINAS
5ET CUOTA WHERE CUOTA
275
*
Al igual que con la instrucción DELETE, las subconsultas pueden desempeñar un papel importante en la instrucción UPDATE, ya que permiten seleccionar las filas que hay que actualizar con base en la información contenida en otras tablas. A continuación se ofrecen varios ejemplos de instrucciones UPDATE que utilizan subconsultas:
/ncrement.ar en 5.000 € el límile de crédito de todos los clientes que hayan realizado pedidos por encima de 25.000 f.
Al igual que en la instrucción DELETE, las subconsultas de la cláusula WHERE de la instrucción UPDATE pueden anidarse a cualquier nivel y pueden contener re· ferencias externas a la tabla destino de la instrucción 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 instrucción UPDATE. La subconsulta de este ejemplo es una subconsuIta correlacionada, como se describe en el Capítulo 9. Las referencias externas suelen hallarse en las subconsultas de las instrucciones UPDATE, ya que implementan la reunión entre las tablas de la subconsulla y la tabla destino de la instrucción UPDATE. Se aplica la misma restricción de SQLI que a la instrucción DELETE: la tabla destino no puede aparecer en la cláusula FROM de ninguna subconsulta en ningún 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 cláusula WHERE de la instrucción UPDATE. El estándar SQL2 también eliminó esta restricción y especifica que las referencias a la tabla destino en las subconsultas se evalúan como si no se hubiera actualizado ninguna fila de la tabla destino.
276
SOL. Manual de referencia
Resumen Este capítulo describe las instrucciones de SQL que se utilizan para modificar el contenido de las bases de datos:
:
CAPíTULO
• La instrucción INSERT sobre una sola fila añade una fila de datos a una tabla. Los valores para la nueva fila se especifican en la instrucción como constantes. • La instrucción INSERT sobre varias filas añade cero o más filas a una tabla. Los valores para las nuevas filas provienen de una consulta, que se especifica como parte de la instrucción INSERT. • La instrucción DELETE elimina cero o más filas de datos de una tabla. Las filas que hay que eliminar se especifican mediante una condición de búsqueda. • La instrucción UPDATE modifica los valores de una o más columnas en cero O más filas de una tabla. Las filas que hay que actualizar se especifican mediante una condición de búsqueda. Las columnas que hay que actualizar y las expresiones que calculan sus nuevos valores se especifican en la instrucción UPDATE. • A diferencia de la instrucción SELECT. que puede operar sobre varias tablas, las instrucciones INSERT, DELETE y UPDATE sólo trabajan sobre una tabla a la vez. • La condición de búsql!eda utilizada en las instrucciones DELETE y UPDATE tiene la misma forma que la condición de búsqueda de las instrucciones
11
Integridad de datos
La expresión integridad de los datos hace referencia a la corrección 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 añadir a la base de datos datos no válidos, 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 eléctrico. • Se pueden aplicar las modificaciones realizadas sólo parcialmente, como puede ocurrir al añadir un pedido para un producto sin ajustar la cantidad disponible para la venta.
SELECT.
Uno de los papeles más importantes de los SGBD relacionales es el mantenimiento de la integridad de los datos almacenados en la medida en que sea posible. Este capítulo presenta las características del lenguaje SQL que ayudan en esta tarea al SGBD.
Concepto de la integridad de datos Para mantener la consistencia y corrección 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 actualización 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
SOL. Manual de referencia
Capítulo 11: Integridad de datos
• Datos requeridos. Algunas columnas de la base de dalOs deben contener un valor de datos válido en cada fila; no se permite que estén 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. • Comprobación 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 números de pedido a partir de 100001,
• Consistencia. Muchas transacciones del mundo real provocan múltiples actualizaciones de las bases de datos. Por ejemplo, la aceptación del pedido de un cliente puede suponer la adición 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 continúe 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.
de modo que el dominio de la columna NUM_PEDIDO son los enteros positi-
•
•
•
•
279
vos mayores de cien mil. De manera parecida, los números 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 unívoca al producto representado por esa fila. Los valores duplicados son ilegales, ya que no permitirían que la base de datos distinguiera un producto de otro. Se puede pedir al SGBD que haga cumplir esta restricción 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 válido de la columna OFICINA de la tabla OFICINAS, o el representante estará asignado a una oficina no válida. Se puede pedir al SGBD que haga cumplir esta restricción de claves externa/primaria. Otras relaciones de datos. La situación 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 están 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 prohíba la aceptación de pedidos para los que no haya existencias suficientes. Se puede pedir al SGBD que compruebe cada nueva fila que se añada a la tabla PEDIDOS para asegurarse de que el valor de su columna CANTIDAD no viola esta regla de negocio.
El estándar ANSI/ISO de SQL especifica algunas de las restricciones de integridad de datos más sencillas. Por ejemplo, alberga la restricción de datos necesarios y se implementa de una manera uniforme en casi todos los productos comerciales de SQL. Las restricciones más complejas, como la de las reglas de negocio, no vienen especificadas en el estándar ANSI/lSO, y hay una amplia variación en las técnicas y en la sintaxis de SQL utilizadas para albergarlas. Las.características de SQL que alojan las cinco primeras restricciones de integridad se describen en este capítulo. El mecanismo de las transacciones de SQL, que alberga la restricción de consistencia, se describe en el Capítulo 12.
Datos requeridos La restricción para la integridad de los datos más sencilla exige que las columnas contengan valores que no sean NULL. El estándar ANSI/lSO y la mayor parte de los productos comerciales de SQL admiten esta restricción al permitir que se declare una columna como NOT NULL cuando se crea la tabla que contiene esa columna. La restricción NOT NULL se especifica como parte de la instrucción CREATE TABLE, que se describe en el Capítulo 13. Cuando se declara una columna como NOT NULL, el SGBD hace que se cumpla la restricción asegurándose de que: • Cada instrucción INSERT que añada 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 explícita como implícitamente) da lugar a un error. • Cada instrucción 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 también dan lugar a un error. Un inconveniente de la restricción NOT NULL es que generalmente se debe especificar cuándo 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 cuáles no. También hay un problema lógico poten-
\
---!...-
280
SOL. Manual de referencia
cial con la adición 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 restricción de datos (recién) impuesta. La imposibilidad de adición de restricciones NOT NULL a las tablas ya existentes también 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 no·se halla presente, lo que aborra espacio de almacenamiento en disco. La adición y eliminación dinámica de restricciones NQT NULL exigiría, por tanto, la reconfiguración sobre la marcha de las filas almacenadas en el disco, lo que no resulta práctico en bases de datos de gran tamaño.
Comprobación simple de validez El estándar 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 sólo 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 instrucción INSERT o UPDATE intenta almacenar en esa columna una cadena de caracteres o un número decimal. No obstante, el estándar SQLI y muchos productos comerciales de SQL no ofrecen ningún modo de restringir una columna a determinados valores de datos. El SGBD no ofrecerá ningún obstáculo a la inserción en una fila de REPRESENTANTES del número de empleado 12345, aunque los números de empleados de la base de datos de ejemplo tengan, por convenio, sólo tres cifras. También se aceptaría una fecha de contratación de 25 de diciembre, aunque la empresa esté cerrada el día de Navidad. Algunas implementaciones comerciales de SQL ofrecen características suplementarias para la comprobación 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 validación correspondiente, un programa escrito por el usuario que comprueba si los valores de los datos son válidos. DB2 invoca el procedimiento de validación cada vez que una instrucción de SQL intenta modificar una fila de la tabla o insertar una nueva y presenta al procedimiento de validación los valores de las columnas propuestos para esa fila. El procedimiento de validación comprueba los datos e indica, mediante el valor de su respuesta, si son aceptables. El procedimiento de validación 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 validación no puede tener acceso a la base de
Capítulo 11: Integridad de datos
281
datos, por lo que no se puede utilizar para buscar valores únicos o relaciones entre claves primarias y externas. SQL Server también ofrece una posibilidad de validación de datos al permitir la creación 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 validación de DB2, las reglas de SQL Server se escriben en el dialecto de Transacl-SQL que utiliza SQL Server. Por ejemplo, a continua· ción se muestra una instrucción 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
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 validación de DB2, las reglas de SQL Server no pueden hacer referencia a columnas ni a otros objetos de la base de datos. El estándar SQL2 ofrece un soporte más amplio de las comprobaciones de validez mediante dos características diferentes -las restricciones de comprobación 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 válido. La característica de la comprobación 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 definición de muchas columnas diferentes cuyos valores legales de datos sean iguales..
Restricciones de comprobación de columnas (SQL2) Las restricciones de comprobación de SQL2 son condiciones de búsqueda, como las condiciones de búsqueda de las cláusulas WHERE, que producen valores verdadero o falso. Cuando se especifica una restricción de comprobación para una columna, el SGBD comprueba de manera automática el valor de esa columna cada vez que se inserta o que se actualiza una fila para asegurarse de que la condición de búsqueda se cumple. En caso contrario, la instrucción INSERT o UPDATE falla. Las restricciones de comprobación de las columnas se especifican como parte de la definición de las columnas en la instrucción CREATE TABLE, que se describe en el Capítulo 13. Considérese este fragmento de una instrucción CREATE TABLE, modificado a partir de la definición de la base de datos de ejemplo para incluir tres restricciones de comprobación: CREATE TABLE REPRESENTANTES (NUM_EMPL INTEGER NOT NULL
282
SOL. Manual de referencia CHECK (NUM_EMPL BETWEEN 101 AND 199), EDAD INTEGER CHECK (EDAD >= 18),
CUOTA MONEY CHECK (MONEY >= 0.01
La primera restricción (para la columna NUM_EMPL) exige que los números de empleado válidos sean números de tres cifras comprendidos entre 101 y 199. La segunda restricción (para la columna EDAD) evita de manera parecida la contratación de menores de edad. .La tercera restricción (para la columna CUOTA) evita que un representante tenga una cuota inferior a 0,00 €. Estas tres restricciones de comprobación de columnas son ejemplos muy sencillos de la posibilidad especificada por el estándar SQL2. En general, los paréntesis que siguen a la palabra clave CHECK pueden contener cualquier condición de búsqueda válida que tenga sentido en el contexto de la definición de una columna. Con esta flexibilidad las restricciones de comprobación 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», más adelante en este mismo capítulo.
Dominios (SQL2) Los dominios de SQL2 generalizan el concepto de restricción de comprobación y permiten aplicar de manera sencilla la misma restricción de comprobación 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 instrucción de SQLZ CREATE OOMAIN, que se describe en el Capítu!o 13. Al igual que con la definición de restricción de com~ probación, se emplea una condición de búsqueda para definir el rango de los valores legales de los datos. Por ejemplo, a continuación se ofrece una instrucción CREATE DOMAIN de SQL2 para crear el dominio ID_EMPLEADO_VALIDO, que incluye a todos los números de empleado: CREATE DOMAIN ID_EMPLEADO_VALIDO INTEGER CHECK (VALUE BETWEEN 101 AND 199)
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 instrucción CREATE TABLE de ejemplo para la tabla REPRESENTANTES tendría el aspecto siguiente:
La ventaja de emplear un dominio es que, si las columnas de otras tablas contienen también números 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
Otra ventaja de los dominios es que la definición de los datos válidos (como los números de empleado válidos de este ejemplo) se almacena en un punto central de la base de datos. Si la definición se modifica posteriormente (por ejemplo, si la empresa crece y se deben permitir números de empleados del rango 200-299), resulta mucho más sencillo modificar una definición 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 gestión 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, resultaría 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 número 106-. Por este motivo, el requisito de que las claves prima. rias tenganvalores únicos se denomina restricción de integridad de las entidades.
284
I
285
Capítulo 11: Integridad de datos
SOL Manual de referencia
En las primeras bases de datos comerciales de SQL no se daba soporte a las claves primarias, pero hoy en día resulta muy frecuente. Se añadió a DB2 en 1988 y al estándar ANSlIISO original en una actualización intermedia, antes de que apareciera el estándar SQL2 completo. La clave primaria se especifica como parte de la instrucción CREATE TABLE, que se describe en el Capítulo 13. La definición de la base de datos de ejemplo del Apéndice A incluye definiciones de claves primarias para todas las tablas, siguiendo la sintaxis del estándar ANSI/ISO. Cuando se especifica una clave primaria para una tabla, el SGBD comprueba de manera automática la unicidad del valor de la clave primaria de cada instrucción 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 fallarán y generarán 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 «quizás», en función del valor «real» de los datos que faltan (NULL). Por este motivo, el estándar SQL exige que cada columna que forme parte de una clave primaria se declare como NOT NULL. Se aplica la misma restricción a cada columna que figure en una restricción 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 Capítulo 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 unívoca 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 relación 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, supóngase que se desea restringir los datos de la labIa REPRESENTANTES de modo que dos representantes no puedan tener exactamente el mismo número en la tabla. Este objetivo se puede conseguir imponiendo una restricción de unicidad a la columna NOMBRE. El SGBD hace que se cumpla la restricción de unicidad del mismo modo en que hace que se cumpla la restricción de clave primaria. Cualquier intento de insertar o actualizar una fila de la tabla que viole la restricción de unicidad fracasará. El estándar ANSUISO para SQL utiliza la instrucción 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 publicación del estándar ANSIIISO, y DB2 las transformó en parte de su instrucción CREATE INDEX. Esta instrucción es una de las instrucciones para administración de la base de datos que tratan del almacenamiento físico de la base de datos en el disco. Normalmente, el usuario de SQL no tiene que preocuparse de estas instrucciones en absoluto; sólo las utiliza el administrador de la base de datos. Muchos productos comerciales de SQL siguieron la práctica original de DB2 en lugar del estándar ANSrnSO para las restricciones de unicidad y exigieron el empleo de una instrucción CREATE INDEX. Las versiones posteriores de DB2 añadieron una restricción de unicidad a la instrucción CREATE TABLE. La mayor parte de los otros fabricantes comerciales han seguido el mismo camino y, hoy en día, incluyen el estándar ANSurSO para la restricción de unicidad.
Tabla REPRESENTANTES I NUM EMPL NOMBRE 105 Bruno Arteaga 109 Maria Jiménez 102 Susana Santos 106 samuel Clavel lO' Bernardo Sánchez 101 Daniel Ruidrobo 110 Tomás Saz 108 León Freire 103 Pablo Cruz 107 Neus Azcárate
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 restricción de unicidad. Supóngase que se in,tenta insenar una fila con una clave primaria que sea NULL (o parcialmente NULL, si la clave primaria está compuesta por más de una ~olumna). Debido
más filas REPRESENTANTES (hijos) con números de oficina coincidentes. De manera parecida, cada fila REPRESENTANTES (hijo) tiene exactamente una fila OFICINAS (padre) con un número de oficina coincidente. Supóngase que se ha intentado insertar una nueva fila en la tabla REPRESENTANTES que contenía un número de oficina no válido, como en este ejemplo: INSERT INTQ REPRESENTANTES VALUES
Aparentemente, no hay nada erróneo en esta instrucción INSERT. De hecho, muchas implementaciones de SQL añadirán la fila con éxito. La base de datos mostrará que Gabriel Suárez trabaja en la oficina número 31, aunque no aparezca ninguna oficina número 31 en la tabla OFICINAS. La fila recién insertada rompe claramente la relación padrelhijo entre las tablas OFICINAS y REPRESENTANTES. De hecho, el número de oficina de la instrucción INSERT es probable que sea un error -puede que el usuario pretendiera escribir el número de oficina 11, 21 o 13. Parece claro que se debe obligar a que cada valor legal de la columna OFICINA_REP coincida con algún valor que aparezca en la columna OFICINA. Esta regla se conoce como restricción 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 añadió el soporte de la integridad referencial a DB2 en 1989, y la integridad referencial se añadió al estándar SQLl tras su edición inicial. La mayor parte de los fabricantes de SGBD de hoy en día soportan las restricciones de integridad referencial.
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 actualización: • Inserción de una fila hijo nueva. Cuando una instrucción INSERT añade 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 inserción de la fila deteriorará la base de datos, ya que habrá un hijo sin padre (un huérfano). Obsérvese que la inserción de una fila en la tabla padre no supone nunca un problema; sencillamente, se transforma en un padre sin hijos.
287
• Actualización 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 instrucción 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á huérfana. • Eliminación 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 huérfanos. Los valores de la clave externa (OFICINA_REP) de estas filas ya no coincidirán con ningún valor de la clave primaria (OFICINA) de la tabla padre. Obsérvese que la eliminación de una fila de la tabla hijo no plantea ningún problema; el padre de esa fila simplemente tiene un hijo menos tras esa eliminación. • Actualización 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 huérfanos debido a que sus claves externas ya no coinciden con ningún valor de la clave primaria. Las características de integridad referencial del estándar 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 instrucción INSERT. Si no coinciden con un valor de la clave primaria, se rechaza la instrucción INSERT. En la Figura 11.1 esto significa que antes de que se pueda añadir 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 restricción 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 ningún valor coincidente en la clave primaria, la instrucción 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 más, esta restricción tiene sentido en la base de datos de ejemplo. El tercer problema (DELETE de una fila padre) es más complejo. Por ejemplo, supóngase que se cerrara la oficina de León y se quisiera eliminar la fila correspondiente de la tabla OFICINAS en la Figura 11.1. Cabría preguntarse lo que ocurrirá con las dos filas hijos de la tabla REPRESENTANTES que representan a los representantes asignados a la oficina de León. En función de la situación se deseará: • Evitar que se elimine la oficina hasta que se haya reasignado a los representantes. • Eliminar también de manera automática a los dos representantes de la tabla REPRESENTANTES.
• Definir la columna OFICINA_REP de los dos representantes como NULL, indicando que se desconoce su asignación de oficina. • Definir la columna OFICINA_REP de los dos representantes con algún valor predeterminado, como el número de oficina de la oficina central de Navarra,
288
Capítulo 11: Integridad de datos
SaL. Manual de referencia
indicando que los representantes se reasignan de manera automática a esa oficina. El cuarto problema (UPDATE de la clave primaria de la tabla padre) tiene una complejidad parecida. Por ejemplo, supóngase que, por alguna razón, se desea modificar el número de la oficina de León 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 León. Una vez más hay cuatro posibilidades lógicas:
• Evitar que el número de oficina se modifique hasta que se haya reasignado a los representantes. En este caso, primero habría que añadir una fila nueva a la tabla OFICINAS con el nuevo número de oficina de León, luego actualizar la tabla REPRESENTANTES y, finalmente, eliminar la fila antigua de la tabla OFICINAS para León. • Actualizar de manera automática el número de oficina de los dos representantes en la tabla REPRESENTANTES, de modo que sus filas sigan vinculadas con la fila de León de la tabla OFICINAS, mediante su nuevo número de oficina: • Definir la columna OFICINA_REP de los dos representantes como NULL, indicando que su asignación de oficina es desconocida. • Definir la columna OFICINA_REP de los dos representantes con un valor predeterminado, corno el número de oficina de la cenrral de Navarra, indicando que los representantes se reasignan de manera automática a esa oficina. Aunque algunas de estas opciones puedan parecer más lógicas que otras en este ejemplo concreto, resulta relativamente sencillo encontrar ejemplos en que cualquiera de las opciones sea la solución correcta, si se desea que la base de datos modele con precisión la situación del mundo real. El estándar SQLI sólo ofrecía la primera posibilidad para los ejemplos anteriores -prohibía la modificación de los valores en uso de las claves primarias y la eliminación de filas que contuvieran una clave primaria-o DB2, sin embargo, permitía otras opciones mediante su concepto de reglas de eliminación. El estándar SQL2 ha ampliado estas reglas de eliminación a reglas de eliminación y actualización, que tratan tanto la eliminación de filas padre como la actualización de las claves primarias.
Reglas de eliminación y actualización
*
Para cada relación padre/hijo creada por una clave externa de una base de datos, el estándar SQL2 permite especificar una regla de eliminación y una regla de actualización asociadas. La regla de eliminación 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 eliminación: • Regla de eliminación RESTRICT. La regla de eliminación RESTRICT evita que se elimine una fila de la tabla padre si esa fila tiene hijos. Las instruccio-
289
nes DELETE que intenten eliminar una de estas filas padres se rechazarán 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 eliminación CASCADE. La regla de eliminación CASCADE indica al SGBD que cuando se elimine una fila padre, también se deben eliminar automáticamente de la tabla hijo todas sus filas hijos. Para la Figura 11.1 esta regla puede resumirse así: «La eliminación de una oficina elimina de manera automática a todos los representantes asignados a esa oficina». • Regla de eliminación SET NULL. La regla de eliminación SET NULL indica al SGBD que cuando se elimine una fila padre se debe definir automáticamente como NULL el valor de la clave externa de todas sus filas hijo. Las eliminaciones en la tabla padre generan, por (anta, una actualización «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 asignación actual de oficina de sus representantes». • Regla de eliminación SET DEFAULT. La regla de eliminación SET DEFAULT indica al SGBO que, cuando se elimina una fila padre. el valor de la clave externa de sus filas hijos debe definirse automáticamente como el valor predeterminado de esa columna concreta. Las eliminaciones de la tabla padre provocan, por tanto, una actualización «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 asignación actual de oficina de sus representantes es la oficina predeterminada especificada en la definición de la tabla REPRESENTANTES». Hay unas pequeñas diferencias entre las implementaciones de SQL2 y de DB2 de las reglas de eliminación. La implementación actual de DB2 no incluye la regla SET DEFAULT; ésta sólo viene especificada en el estándar SQL2. El estándar SQL2 llama realmente NO ACTION a·la regla RESTRICT ya descrita. La denominación de SQL2 es algo confusa. Significa: «Si se intenta eliminar una fila padre que todavía tenga hijos, el SOBD no emprenderá ninguna acción sobre esa fila». No obstante, el SGBD generará un código de error. De manera intuitiva, el nombre de DB2 para esta regla, restrict, parece una descripción mejor de la situación -el SGBD restringirá (impedirá) la operación DELETE y generará un código de error. Las versiones recientes de DB2 admiten tanto la regla de eliminación RESTRICT como la regla de eliminación NO ACTION. La diferencia entre ellas es el momento de aplicación de la regla. La regla RESTRICT se aplica antes que ninguna otra restricción; la regla NO ACTION se aplica después de las demás restricciones referenciales. En casi todas las circunstancias las dos reglas operan de manera idéntica. Al igual que la regla de eliminación indica al SOBO lo que debe hacer cuando un usuario intente eliminar una fila de la tabla padre, la regla de. actualización indica al SOBO lo que debe hacer cuando un usuario intente actualizar el valor de
290
Capítulo 11: Integridad de datos
SOL. Manual de referencia'
una de las columnas de la clave primaria de la tabla padre. Una vez más, hay cuatro posibilidades, que recuerdan a las disponibles para las reglas de eliminación: • Regla de actualización RESTRICT. La regla de actualización 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 rechazarán 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 número de una oficina si tiene asignados representantes». • Regla de actualización CASCADE. La regla de actualización 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 también de manera automática en la tabla hijo para que coincida con la nueva clave primaria. Para la Figura 11.1 esta regla puede resumirse así: «La modificación del número de una oficina modifica automáticamente el número de oficina de todos los representantes que tenga asignados». • Regla de actualización SET NULL. La regla de actualización SET NULL indica al SGBD que cuando se actualice el valor de la clave primaria de una fila padre, se debe definir de manera automática como NULL el valor de la clave externa de todas sus filas hijos. Las modificaciones de la clave primaria generan, por tanto, una actualización «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 número de una oficina, hay que indicar que la asignación actual de oficina de sus representantes es desconocida». • Regla de actualización SET DEFAULT. La regla de actualización 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 automáticamente como el valor predeterminado de esa columna concreta. Por tanto, las modificaciones de la clave primaria de la tabla padre generan una actualización «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 número de una oficina, hay que cambiar de manera automática la asignación de oficina de sus representantes a la oficina predeterminada especificada en la definición de la tabla REPRESENTANTES». Las mismas diferencias entre DB2 y el estándar SQL2 descritas para las reglas de eliminación son aplicables para las reglas de actualización. La regla de actualización SET DEFAULT sólo se halla presente en el estándar, no en la implementación actual de DB2. La regla de actualización RESTRICT es un convenio de denominación de DB2; el estándar SQL2 también llama NO ACTION a esta regla de actualización. Se pueden especificar dos reglas diferentes, como regla de eliminación y regla de actualiza-ci6n de una relaci6n padre/hijo, aunque, en la mayor parte de los ca-
291
SOS, las dos reglas serán idénticas. Si no se especifica ninguna regla, el valor predeterminado es la regla RESTRICT, ya que presenta el riesgo mínimo de destrucción o modificación 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 relación entre un pedido y el vendedor, deba utilizar la regla RESTRICT para eliminación y actualización. No debería resultar posible eliminar de la base de datos información de productos ni modificar
su número de producLO si sigue habiendo pedidos pendientes de esos pro· duetos. • Para la relación 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 relación con la empresa. En ese caso, al eliminar al cliente, también habrá que eliminar los pedidos pendientes de ese cliente. De manera parecida, las modificaciones del número de cliente deben transmitirse de manera automática a los pedidos de ese cliente. • Para la relación 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 podría utilizarse la regla SET DEFAULT para asignar de forma automática esos pedidos al vicepresidente de ventas. Es probable que esta relación deba utilizar la regla de actualización CASCADE, para que las modificaciones en los números de empleado se transmitan automáticamente a la tabla PEDIDOS.
Eliminaciones y actualizaciones en cascada
293
Tabla OFICINAS OFICINA 22 11 12
CIUDAD Daimiel Navarra Castellón 13 Almeria 21 León
La regla RESTRICT para eliminaciones y actualizaciones es una regla de un solo nivel -sólo afecta. a la tabla padre de la relación-o La regla CASCADE, por otra parte, puede ser una regla multinivel, como puede verse en la Figura 11.3. Supóngase para esta discusión que las relaciones OFICINAS/REPRESENTANTES Y REPRESENTANTES/PEDIDOS que aparecen en la figura tienen reglas CASCADE. Planteémonos lo que ocurre cuando se elimina la oficina de León de la tabla OFICINAS. La regla CASCADE de la relación OFICINAS/REPRESENTANTES indica al SGBD que elimine también de manera automática todas las filas de REPRESENTANTES que hagan referencia a la oficina de León (oficina número 21). Pero la eliminación de la fila de Susana Santos de REPRESENTANTES pone en funcionamiento la regla CASCADE para la relación REPRESENTANTES/PEDIDOS. Esta regla indica al SGBD que elimine de manera automática todas las filas de PEDIDOS que hagan referencia a Susana (número de empleado 102). La eliminación, por tanto, genera una eliminación en cascada de representantes, lo que causa una eliminación en cascada de pedidos. Como muestra el ejemplo, las reglas de eliminación CASCADE deben especificarse con cuidado, ya que pueden generar una eliminación automática generalizada de datos si se utilizan de manera incorrecta. Las reglas de actualización en cascada pueden crear actualizaciones multinivel parecidas si la clave externa de la tabla hijo también es su clave primaria. En la práctica, 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 actualización y de eliminación 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 eliminación SET
Figura
11,3.
Dos niveles de las· reglas
CASCADE.
para la relación OFICINAS/REPRESENTANTES. Esta vez, cuando se elimina la oficina de León, la regla de eliminación SET NULL indica al SGBD"que defina la columna OFICINA_REP como NULL en las filas de REPRESENTANTES que hacen referencia a la oficina número veintiuno. No obstante, las filas siguen en la tabla REPRESENTANTES, Yla repercusión de la operación de eliminación sólo llega a la tabla hijo. NULL
109 Maria Jiménez 102 Susana Santos 106 Samuel Clavel
295
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 sólo incluye dos tablas, pero también es posible crear ciclos de tres o más tablas. Independientemente del número de tablas que impliquen, los ciclos referenciales plantean problemas especiales para las restricciones de la integridad referencial. Por ejemplo, supóngase 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 harán evidentes en un momento). Considérese esta solicitud de actualización de la base de datos y las instrucciones INSERT que intentan implementarla:
EDAD OFICINA REP PUESTO
11 21 11
31 48 52
Representante
Representante Jefe Ventas
Clave externa Tabla OFICINAS OFICINA I CIUDAD 22 Daimiel 11 Navarra 12 Castellón 13 Almería 21 León
Clave externa Tabla REPRESENTANTES NUM-EMPL NOMBRE EDAD OFICINA REP PUESTO 37 105 Bruno Arteaga 13 Representante 109 María Jiménez 31 11 Representante 102 Susana Santos .8 21 Representante 106 Samuel Clavel 52 11 VP Vent.as 33 12 Jefe Ventas lO' Bernardo Sánchez 101 Daniel Ruidrobo 12 Representante 45 110 Tomás Saz 41 NULL Representante lOa Le6n Freire .2 21 Jefe Ventas 103 Pablo Cruz 29 12 Representante 107 Neus Azcárate 22 Representante 49 Clave primaria
Figura ".5.
Un ciclo referencial.
296
Capítulo 11: Integridad de datos
SaL. Manual de referencia
Se acaba de contralar a U!l representante, Benjamín Aláez (número de empLeado 115), que es el jefe de una oficina nueva de Dos Hermanas (número de oficina 14). INSERT INTO REPRESENTANTES VALUES
Por desgracia, la primera instrucción INSERT (para Benjamín Aláez) fallará. ¿Por qué? Porque la fila nueva hace referencia a la oficina número 14, que todavía nO,se halla en la base de datos. Por supuesto. la inversión del orden de las instrucciones INSERT no ayuda:
Los ciclos referenciales también restringen las reglas _de eliminación y de actualización que pueden especificarse para las relaciones que fonnan el ciclo. Considérense 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 NIÑOS muestra a cuatro chicos y las chicas que les gustan, que forman un ciclo referencia~.--Las tres relaciones del ciclo especifican la regla de eliminación RESTRICT. Obsérvese 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 relación y, por tanto, está protegida de la elimina· ción por la regla RESTRICT. Debido a esta anomalía 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
Tabla MASCOTAS I GUSTA NOMBRE Fino Samuel Ringo Benito Simbad José
La primera instrucción INSERT (para Dos Hermanas, en este caso) seguirá fallando, ya que la nueva fila hace referencia al empleado número 115 como jefe de la oficina, y Benjamín Aláez no se halla todavía en la base de datos. Para evitar este bloqueó de inserciones, como mínimo una de las claves externas del ciclo referencial debe permitir los valores NULL. En la definición 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 inserción de las dos filas puede lograrse con dos instrucciones INSERT y una instrucción UPDATE, como puede verse a continuación:
el
"':S'
pn¡maria
RESTRICT
Tabla CHICAS NOMBRE GUSTA Fino Susana Juanita Simbad Beatriz Ringo
Clave externa Tabla CHICOS GUSTA NOMBRE Benito Juanita Beatriz Samuel José Susana Gustavo Juanita
UPDATE REPRESENTANTES SET OFICINA_REP = 14 WHERE NUM_EMPL = 115
Como muestra el ejemplo, hay veces en que sería conveniente que no se comprobara la restricción de integridad referencial hasta que se realice una serie de actualizaciones interrelacionadas. Por desgracia, este tipo de comprobación compleja dif~rida no lo proporciona la mayor parte de las implementaciones actuales de SQL. El estándar SQL2 especifica algunas posibilidades de comprobación diferida, com9 se describe más adelante en el apartado «Comprobación diferida de restricciones».
297
CI~ve
.
i
pnmana
Figura 11.6.
RESTRICT
Un ciclo con todas las reglas RESTRICT.
298
SOL. Manual de referencia
Capítulo 11: Integridad de datos
Claves externas y valores Clave externa
I
Tabla MASCOTAS
Ringo
GUSTA Samuel Benito
Simbad
José
NOMBRE
Fino
el
,.,~
P'imaria
CASCADE
Clave externa Tabla CHICAS NOMBRE GUSTA Susana Fino Juanita Simbad
Beatriz Ringo
a_.~ primaria
CASCADE
Clave
externa
Tabla CHICOS
NOMBRE
Benito
GUSTA Juanita
Beat.riz Susana Gustavo Juanita
Samuel José
CI~ve
i
. primaria
CASCADE
Figura 11.7.
Un ciclo ilegal con todas las reglas CASCADE.
las tres reglas de eliminación se han cambiado a CASCADE. Supóngase que se intenta eliminar a Benito de la tabla CHICOS. Las reglas de eliminación 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 pequeñas pudiera resultar práctico, pero para una base de datos de producción con millares de filas, rápidamente se volvería 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 más tablas en que todas las reglas de eliminación sean CASCADE. Como mínimo, una de las relaciones del ciclo debe tener una regla de eliminación RESTRICT o SET NULL para romper el ciclo de eliminaciones en cascada.
NULL
299
*
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 Tomás Saz, ya que a Tomás todavía no se le ha asignado ninguna oficina. Pero el valor NULL plantea una pregunta interesante sobre la restricción de integridad referencial creada por la relación entre la clave primaria y la clave externa. ¿Coincide el valor NULL con alguno de los valores de la clave primaria? La respuesta es «quizás» -depende del valor real de los datos que faltan o son desconocidos. El estándar SQLl de ANSI/ISO da por supuesto de manera automática que una clave externa que contiene un valor NULL satisface ]a restricción 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 restricción 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. Supóngase por un momento que la tabla PEDIDOS de la base de datos de ejemplo permitiera valores NULL en la columna PRODUCTO, y que la relación PRODUCTOS/PEDIDOS tuviera una regla de eliminación SET NULL. (No se trata de la estructura real de la base de datos de ejemplo, por los motivos que se expondrán 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 estándar ANSI/ISO dan por supuesto que la fila cumple la restricción de integridad referencial para PEDIDOS y para PRODUCTOS, aunque ningún producto de la tabla PRODUCTOS tenga el identificador de fabricante ABe. La regla de eliminación SET NULL puede producir un efecto parecido. La eliminación 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, sólo las columnas de la clave externa que acepten valores NOLL se definirán como NULL. Si hubiera una sola fila en la tabla PRODUCTOS para el fabricante DEF, la eliminación de esa fila haría que sus filas hijos de la tabla PEDIDOS pasaran a tener su columna PRODUCTO definida como NULL, pero su columna FAB seguiría teniendo el valor DEF. En consecuencia, las filas tendrían un valor de FAB que no coincidiría con ninguna fila de la tabla PRODUCTOS. Para evitar crear esta situación se debe ser muy cuidadoso con los valores NULL en las claves externas compuestas. Una aplicación 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 estándar SQL2 aborda este problema dando al administrador de la base de datos más control sobre el manejo de los valores NULL en las claves externas para
300
Capítulo 11: Integridad de datos
SOL. Manual de referencia
301
las restricciones de integridad. La restricción de integridad de la instrucción 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.
• Opción MATCH FULL. La opción MATCH FULL exige que las claves externas de las tablas hijos coincidan totalmente con la clave primaria de la tabla padre. Con esta opción 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 eliminación y de actualización. • Opción MATCH PARTIAL. La opción 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 opción el manejo de los valores NULL en las reglas de eliminación y de actualización se realiza como ya se ha descrito.
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 restricción de columna que aparezca para la definición de una columna dada puede especificarse también como aserto. En la práctica, probablemente sea mejor espe· cificar cada restricción de la base de datos donde parezca que encaja de manera más natural, dada la situación del mundo real que la base de datos está intentando modelar. Las restricciones que se apnquen globalmente a toda la situación (procesos comerciales, relaciones entre clientes y productos, etc.) deberían aparecer como asertos. Las restricciones que se apliquen a un tipo concreto de entidad (un cliente o un pedido) deberían aparecer como restricciones de tabla O de columna en la tabla correspondiente que describa ese tipo de entidad. Cuando la misma restricción se aplique a muchas columnas diferentes de la base de datos que se refieran al mismo tipo de entidad, resultará apropiado un dominio.
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 específicas. El estándar SQL2 va más allá de estas posibilidades para incluir una posibilidad mucho más 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 definición 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 definición de cada columna en la instrucción CREATE TABLE. • Dominios. Una forma especializada de restricción de columna. Ofrecen una posibilidad limitada de definición 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 restricción adicional, que se especifica como parte de la definición 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 instrucción CREATE DOMAIN. • Restricciones de tabla. Se especifican como parte de la definición 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 instrucción CREATE TABLE que define cada tabla. Generalmente aparecen como un grupo tras las definiciones de las columnas, pero el estándar SQL2 les permite aparecer intercaladas con las definiciones de las columnas. • Aser~os. El tipo más general de restricción 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 capítulo ya han aparecido ejemplos de los tr~s primeros tipos de restricciones. Los asertos se especifican mediante la instrucción de SQL2 CREATE ASSERTION. A continuación 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 cuanélo se viola el aserto. El aserto que causa el error puede resultar obvio en una base de datos pequeña de ejemplo, pero en una base de datos de gran tamaño que puede contener docenas o centenares de asertos, resulta fundamental conocer el aserto que se ha violado. A continuación 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 límite de crédito: CREATE ASSERTION credito-pedidos CHECK (CLIENTE.LIMITE_CREDITO <=
110
supera su
302
SOL. Manual de referencia SELECT SUM(PEDIDOS.IMPORTE) FROM PEDIDOS WHERE PEDIDOS.CLIENTE = CLIENTE NUM_CLIJ
Como muestran estos ejemplos. los asertos de SQL2 se definen mediante una condición de búsqueda, que se encierra entre paréntesis 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 instrucción INSERT, UPDATE o DELETE, se contrasta la condición de búsqueda con la modificación (propuesta) del contenido de la base de datos. Si la condición de búsqueda sigue siendo TRUE, se permite la modificación. Si la condición de búsqueda pasara a ser falsa. el SGBD no llevará a cabo la modificación propuesta y se devolverá un código de error, que indicará la viola· ción de un aserto. En teoría, los asertos pueden ocasionar una sobrecarga de procesamiento de la base de datos muy grande, ya que se comprueba cada instrucción que pueda modificar la base de datos. En la práctica, el SGBD analiza el aserto y determina las tablas y columnas a las que afecta. Sólo las modificaciones que afecten a esas tablas o columnas en concreto activarán la condición de búsqueda. Pese a todo, los aser· tos deben definirse con mucho cuidado para asegurarse de que suponen una sobrecarga razonable para la ventaja que ofrecen.
Capítulo 11: Integridad de datos
303
nes de clave externa en un mismo sitio en la definición de la tabla, en lugar de tenerlas dispersas por las definiciones de las columnas. • Restricción CHECK. La restricción CHECK puede aparecer como restricción de columna o de tabla. También es el único tipo de restricción que forma parte de la definición de dominios o de asertos. La restricción de comprobación se especifica como condición de búsqueda, al igual que la condición de búsqueda que aparece en la cláusula WHERE de las consultas a las bases de datos. La restricción se cumple si la condición de búsqueda tiene el valor TRUE. A cada restricción de la base de datos (independientemente de su tipo) se le puede asignar un nombre de restricción para identificarla de manera unívoca frente a las otras restricciones. Probablemente no sea necesario asignar nombres de restricción en bases de datos sencillas en que cada restricción se halle claramente asociada con una sola tabla, columna o dominio, y en las que haya poca posibilidad de error. En bases de datos más complejas, que tengan varias restricciones en una misma tabla o columna, puede resultar muy útil identificar cada restricción por su nombre (especialmente cuando comiencen a producirse errores). Obsérvese que la restricción de comprobación de los asertos debe tener un nombre de restricción; este nombre se convierte de manera efectiva en el nombre del aserto que contiene esa restricción.
Tipos de restricciones en SQL2 Comprobación 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: • Restricción NOT NULL. La restricción NOT NULL sólo puede aparecer como restricción de columna. Evita que se asigne a la columna un valor NULL. • Restricción PRIMARY KEY. La restricción PRIMARY KEY puede aparecer como restricción de columna o de tabla. Si la clave primaria consta de una sola columna, puede que resulte más conveniente la restricción de columna. Si consta de varias columnas, debe especificarse como restricción de tabla. • Restricción UNIQUE. La restricción UNIQUE puede aparecer como restricción de columna O de tabla. Si la restricción de unicidad de valores sólo se aplica a una columna, la restricción de columna es la manera más sencilla de especificarla. Si la restricción de unicidad de valores se aplica a dos o más columnas (es decir, la combinación de valores de esas columnas debe ser única en todas las filas de la tabla), entonces se debe utilizar la modalidad de restricción de tabla. • Restricción referencial (FOREIGN REY). La restricción referencial (FOREIGN KEY) puede aparecer como restricción de columna o de tabla. Si la clave externa consta de una sola columna, puede que resulte más adecuada la restricción de columna. Si consta de varias columnas, debe especificarse como restri~ción de tabla. Si una tabla tiene muchas relaciones de clave externa con otras tablas, puede que resulte más adecuado reunir todas sus restriccio-
En su forma más 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 ejecución de cada instrucción INSERT, UPDATE o DELETE-. En los sistemas de bases de datos que sólo manifiestan una conformidad de nivel intermedio o inicial con el estándar SQL2, se trata del único modo de operación permitido para las restricciones de la base de datos. La conformidad plena con el estándar SQL2 especifica una posibilidad adicional de comprobación diferida de las restricciones. Cuando se difiere la comprobación de las restricciones no se comprueban las restricciones para cada instrucción de SQL. En lugar de eso, la comprobación de las restricciones se mantiene en suspenso hasta el final de cada transacción SQL. (El procesamiento de las transacciones y las instrucciones SQL asociadas se describe con detalle en el Capítulo 12). Cuando la instrucci6n de SQL CQMMIT indica que se ha completado la transacción, el SaBD comprueba las restricciones diferidas. Si se cumplen todas las restricciones, se puede seguir adelante con la instrucción CQMMIT y la transacción puede completarse con normalidad. En ese momento las modificaciones realizadas a la base de datos durante la transacción se hacen permanentes. Si, no obstante, la transacción propuesta violara alguna de las restricciones, la instrucción COMMIT fallaría y la transacción retrocedería -es decir, se desharían todos las modificaciones de la base de datos propuestas, y la base de datos volvería a su estado previo al comienzo de la transacción.
304
SQL. Manual de referencia
Capítulo 11: Integridad de datos
305
La comprobaci6n diferida de las restricciones puede resultar muy importante cuando se deben realizar simultáneamente varias actualizaciones de la base de datos para conservarla en un estado consistente. Por ejemplo, supóngase que la base de datos de ejemplo contuviera este aserto:
tante es DEFERRABLE si se desea diferir su operación. Obsérvese también que estos atributos de restricción sólo definen la diferibilidad de una restricción ---es decir, si su operación puede diferirse-. La definición de la ·restricción también puede especificar el estado inicial de la restricción:
Asegurarse de que el objetivo de cuota de cada oficina es igual a la suma de las cuolas de sus represelllantes.
• Restricción INITIALLY IMMEDIATE. Las restricciones INITIALLY IMMEDIATE son las que se inician como restricciones inmediatas; es decir, se comprobará de manera inmediata para cada instrucción de SQL. • Restricción INITIALLY DEFERRED. Las restricciones INITIALLY DEFERRED son las que se inician como restricciones diferidas; es decir, su comprobación se difiere hasta el final de las transacciones. Por supuesto, esta opción no puede especificarse si la restricción se define como NOT DEFERRABLE.
Sin la comprobación diferida de las constantes esta restricción impediría de hecho la adición 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 relación correcta hay que añadir las filas de los nuevos representantes con sus cuotas correspondientes (mediante una instrucción INSERT) e incrementar la cuota de la oficina correspondiente en la misma cantidad (mediante la instrucción UPDATE). Si se intenta ejecutar la instrucción INSERT en la tabla REPRESENTANTES en primer lugar, la tabla OFICINAS no se habrá actualizado todavía, el aserto no será TRUE y la instrucción fallará. De manera parecida, si se intenta ejecutar la instrucción UPDATE en la tabla OFICINAS en primer lugar, la tabla REPRESENTANTES no se habrá actualizado todavía, el aserto no será TRUE y la instrucción fallará. La única solución a este dilema es posponer la comprobación 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 válido. El mecanismo de restricciones diferidas de SQL2 ofrece esta posibilidad y mucho más. Cada restricción (de cualquier tipo) de la base de datos puede identificarse al crearla o definirla como DEFERRABLE o NQT DEFERRABLE: • Restricción DEFERRABLE. Las restricciones DEFERRABLE son aquellas cuya comprobación puede diferirse al final de las transacciones. El aserto del ejemplo anterior es una restricción que debe ser diferible. Al actualizar las cuotas o añadir nuevos representantes a la base de datos resulta ciertamente deseable poder diferir la comprobación de las restricciones, como mostraba el ejemplo. • Restricción NOT DEFERRABLE. Las restricciones NOT DEFERRABLE son aquellas cuya comprobación no puede diferirse. La restricción de clave primaria, una restricción de unicidad, y muchas restricciones de comprobación de columna suelen caer en esta categoría. Estas comprobaciones de integridad de los datos no dependen de otras interacciones de la base de datos. Pueden y deben comprobarse después de cada instrucción de SQL que intente modificar la base de datos. Dado que ofrece ]a comprobación de integridad más restrictiva, el valor predeterminado es NOT DEFERRABLE. Hay que declarar de manera explícita que una cons-
La restricción se pone en el estado inicial especificado cuándo se crea. También se vuelve a colocar en su estado inicial al comienzo de cada transacción. Dado que ofrece la comprobación de integridad más restrictiva, el valor predeterminado es INITIALLY IMMEDIATE. Las restricciones se deben declarar de manera explícita INITIALLY DEFERRED si se de:sea que inicie de manera automática cada transacción en estado diferido. . SQL2 afj.ade otro mecanismo más· para controlar el procesamiento inmediato o diferido de las restricciones. Se puede modificar de manera dinámica el procesamiento de las restricciones durante la operación de la base de datos mediante la instrucción SET CONSTRAINTS. Por ejemplo, supóngase 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
./
La comprobación inmediata inicial hace que .se procese la restricción, instrucción a instrucción, para todo el procesamiento normal de ]a base de datos. Sin embargo, para la transacción especial que añade un nuevo representante a la base de datos, hará falta diferir de manera temporal el procesamiento de la restricción. 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 instrucción COMMIT finaliza la transacción, se vuelve a colocar la restricción totales_cuota en modo IMMEDIATE, debido a la especificación
306
SOL. Manual de referencia
Capítulo 11: Integridad de datos
INITIALLY IMMEDIATE. Si hubiera más trabajo que hacer tras la instrucción upDATE previa al final de la transacción, se podría volver a poner manualmente de nuevo en modo IMMEDIATE empleando esta instrucción:
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 eliminación del pedido o la modificación de su importe también 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 eliminación de pedidos, la modificación de la cantidad o el cambio de producto también deben pravo· car los ajustes correspondientes en la columna STOCK.
SET CQNSTRAINTS totales_cuota IMMEDIATE
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 instrucción: SET CQNSTRAINTS ALL DEFERRED
Las posibilidades de SQL2 para la comprobación diferida de restricciones forman un servicio muy completo para la gestión 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 publicación del estándar. DB2, de IBM, por ejemplo, incluye la posibilidad de comprobación diferida de las restricciones y alberga las opciones de aplazamiento tipo SQL2. No obstante, su instrucción SET CONSTRAINTS, se aparta del estándar SQL2. Opera en las tablas de la base de datos, activando y desactivando el aplazamiento de la comprobación de las restricciones asociadas con el contenido de cada tabla.
Estas reglas caen fuera del ámbito del lenguaje SQL, tal y como lo definía el estándar SQLl y lo implementan muchos productos SGBD basados en SQL de hoy en día. El SGBD asume la responsabilidad del almacenamiento.y ~a organización de los datos y de asegurar su integridad básica, pero el cumplimIento de las reglas de negocio es responsabilidad de los programas de aplicación que tienen acceso a la base de datos. Depositar la carga del cumplimiento de las reglas de negocio en los programas de aplicación que tienen acceso a la base de datos presenta varios inconvenientes: • Duplicación del esfuerzo. Si seis programas diferentes tratan con diferentes actualizaciones de la tabla PEDIDOS, cada uno de ellos debe incluir código que haga que se cumplan las reglas relativas a las actualizaciones de PEDIDOS.
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 organización. Por ejemplo, puede que la empresa modelada por la base de datos de ejemplo tenga reglas como las siguientes: • No se permite a ningún cliente formular pedidos que excedan su límite de crédito. • Se debe informar al vicepresidente de ventas siempre que se conceda a un cliente un límite de crédito superior a 50.000 €. • Los pedidos sólo pueden conservarse en los libros durante seis meses; los pedidos con más de seis meses de antigüedad deben cancelarse y volver a formularse. Además, suele haber reglas de contabilidad que deben seguirse para conservar la integridad de los totales, las cuentas y otros importes almacenados en la
307
/
• 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 deberán identificar todos los programas que hacen que se cumplan las reglas. localizar el código y modificarlo de manera correcta. • Complejidad. Suele haber muchas reglas que recordar. Incluso en ]a pequeña base de datos de ejemplo un programa que maneje las modificaciones de los pedidos debe preocuparse de hacer cumplir los límites de crédito, 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 aplicación hagan cumplir l~s reglas de negocio no es exclusivo de SQL. Los programas de aplicación han teOldo ~sa responsabilidad desde los primeros días de los programas de COBOL y_los sIstemas de archivos. No obstante. hay una lenta tendencia a 10 largo de los anos a atnbUlr más «comprensión» de los datos y más 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 inclusión 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
1
SOL. Manual de. referencia
radores comenzó a aparecer en muchos productos SGBD de SQL a comienzos de los años 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 aplicación cada año, la posibilidad de centralizar la definición y la administración 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 modificación del contenido de una tabla, el usuario puede especificar una acción ~sociada que deba ejecutar el SGBD. Los tres eventos que pueden desencadenar una acción son los intentos de INSERT. DELETE o UPDATE las filas de una tabla. La acción 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 añade 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-
tarse en el importe del pedido. • La columna STOCK del producto solicitado debe disminuir en la cantidad encargada. Esta instrucción 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 automática: 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
La primera parte de la definición del disparador indica a SQL Server que el disparador debe invocarse siempre que se intente ejecutar una instrucción INSERT sobre la tabla PEDIDOS. El resto de la definición (tras la palabra clave AS) define la acdón del disparador. En este caso, la acción es una secuencia de dos instruccio-
Capítulo 11: Integridad de datos
309
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 amplía de manera sustancial el lenguaje SQL para dar soporte a los disparadores. Entre otras extensiones no mostradas aquí están ¡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 estándar ANSI/ISO SQL2. Al igual que ocurre con otras características de SQL cuya popularidad antecedió a su normalización,. é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 auténticas diferencias en las posibilidades subyacentes. El soporte de los disparadores en DB2 ofrece un ejemplo instructivo de estas diferencias. A continuación puede verse la misma definición 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;
El comienzo de la definición del disparador incluye los mismos elementos que la defi1ición de SQL Server, pero los reordena. Indica de manera explícita a DB2 que hay que invocar al disparador después de que se inserte en la base de datos cada pedido nuevo. DB2 también permite especificar que hay que ejecutar el disparador antes de que la acción desencadenante se aplique al contenido de la base de datos. Esto no tiene sentido en este ejemplo, ya que el evento desencadenante es una operación INSERT, pero lo tiene para las operaciones UPDATE o DELETE.
La cláusula 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 definición del disparador. Tiene la misma función que la palabra clave INSERTED en el disparador de SQL Server. La instrucción hace referencia a los valores nuevos de la fila insertada porque se trata de un disparador de la operación INSERT. En los disparadores de la operación DELETE se hace referencia a los valores antiguos. En los disparadores de la operación UPDATE DB2 ofrece la posibilidad de hacer referencia tanto a los valores viejos (previos a UPDATE) como a los nuevos (posteriores a UPDATE).
310
, "
,
SOL. Manual de referencia
Capítulo 11: Integridad de datos
BEGIN ATOMIC y END sirven como paréntesis alrededor de la secuencia de instrucciones SQL que definen la acción desencadenada. Las dos instrucciones upDATE con búsqueda del núcleo de la definición del disparador son modificaciones directas de sus equivalentes en SQL Server. Siguen la sintaxis estándar de SQL para las instrucciones UPDATE con búsqueda, empleando el alias de tabla especificado por la cláusula 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 continuación se ofrece otro ejemplo de definición de disparador, esta vez empleando lnformix Universal Server:
Los disparadores también pueden emplearse para ofrecer formas ampliadas de integridad referenciaL Por ejemplo, DB2 ofrecía inicialmente eliminaciones en cascada mediante su regla de eliminación CASCADE, pero no soportaba las actualizaciones en cascada si se modificaba el valor de alguna clave primaria. Esta limitación, sin embargo, no hace falta aplicarla a los disparadores. El siguiente disparador de SQL Server hace que la actualización de la columna OFICINA de la tabla OFICINAS pase en cascada a la columna OFICINA_REP de la tabla REPRESENTANTES: CREATE ON FOR AS
CREATE TRIGGER PEDIDONUEVO INSERT üN PEDIDOS AFTER (EXECUTE PROCEDURE PEDIDO_NUEVO)
Este disparador vuelve a especificar una acción que tiene que realizarse después de que se inserte el nuevo pedido. En este caso, las diferentes instrucciones de SQL que forman la acción desencadenada no pueden especificarse directamente en la definición 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 varían bastante. Los disparadores, ciertamente, se hallan entre los aspectos menos transportables de las bases de datos de SQL de hoy en día.
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 señalan que el mecanismo de los disparadores es más flexible que la integridad referencial estricta proporcionada por el estándar ANSI/ISO. Por ejemplo, a continuación se ofrece un disparador que hace que se cumpla la integridad referencial en la relación OFICINAS/REPRESENTANTES, Y muestra un mensaje cuando falla algún intento de actualización: CREATE ON FOR AS
TRIGGER ACTUALIZAR_REP REPRESENTANTES INSERT, UPDATE IF ((SELECT COUNT(*) FROH OFICINAS, INSERTED WHERE OFICINAS.OFICINA = INSERTED.OFICINA_REPI BEGIN PRINT -Número de oficina especificado no válido." ROLLBACK TRANSACTION ENn
O)
311
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
Como en el ejemplo anterior de SQL Server, las referencias DELETED. OFICINA INSERTED. OFICINA del dispaqldor hacen mención a los valores de la columna OFICINA antes y después de la instrucción UPDATE, respectivamente. La definición
e
del disparador debe poder diferenciar entre estos valores anteriores y posteriores para poder llevar a cabo las correspondientes acciones de búsqueda y actualización especificadas por el disparador.
Ventajas e inconvenientes de los disparadores Durante los últimos años 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 Capítulo 20) se han difuminado, por lo que la acción desencadenada por una sola modificación de la base de datos puede estar definida por centenares de líneas de programación de procedimientos almacenados. El papel de los disparadores, por tanto, ha evolucionado más allá del cumplimiento de la integridad de los datos hacia una posibilidad de programación 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 actualización de la base de datos. Esto puede reducir espectacularmente la complejidad de los programas de aplicación que tienen acceso a la base de datos. Los disparadores también 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 configuración de la base de datos se hace una tarea más
ji
I
312
Capítulo 11: Integridad de datos
SOL. .Manual.de referencia
compleja. Los usuarios de los que se podía esperar razonablemente que crearan pequeñas aplicaciones ad hoc con SQL hallarán que la lógica de programación de los disparadores hace la tarea mucho más difícil.. • 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 acción de la base de datos iniciada por un programa puede generar otras acciones ocultas.
• Implicaciones ocultas para el rendimiento. Con los disparadores almacenados en el interior de la base de datos las consecuencias de la ejecución de las instrucciones de SQL ya no son completamente visibles para los programadores. En especial, una instrucción de SQL aparentemente sencilla puede, teóricamente, desencadenar un proceso que implique la búsqueda secuencial de una tabla de la base de datos de tamaño muy grande, lo que tardaría mucho en completarse. Estas implicaciones para el rendimiento de cualquier instrucción SQL resultan invisibles para los programadores.
Disparadores y el estándar SOL Los disparadores fueron una de las características más 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 estándar SQL2 ofreció una oportunidad para normalizar la implementación de los disparadores en los SGBD, el comité de normalizaCión introdujo en su lugar las restricciones de comprobación. Como muestran los ejemplos de disparadores y de restricciones de comprobación de los apartados anteriores, las restricciones de comprobación pueden emplearse de manera efectiva para limitar los datos que pueden añadirse 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 añadido de filas o la modificación 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 estándar SQL3. Otros expertos han argumentado que los disparadores suponen una contaminación de la función de gestión de datos de las bases de datos, y que las funciones desempeñadas por los disparadores corresponden a los lenguajes de cuarta generación (Fourth Generation Languages, 4GLs) y a otras herramientas de las bases de datos, más que a los propios SGBD. Mientras continúa el debate, los productos de SGBD han experimentado nuevas posibilidades de disparadores que se extienden más 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 automática acciones como el envío de correo, el aviso a un usuario o ellanzamiento de otro programa para la realización de una tarea. Esto hace a los disparadores todavía más "útiles y se sumará al debate sobre su inclusión en futuros estándares
313
oficiales de SQL. Independientemente de la posición oficial, los disparadores se han hecho una parte cada vez más importante del lenguaje SQL en las aplicaciones empresariales durante los últimos años.
Resumen El lenguaje SQL ofrece varias características 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 validación de los datos en SQL estándar se limita a la comprobación del tipo de datos, pero muchos productos SGBD ofrecen'\otras características de validación. • Las restricciones de integridad de las entidades aseguran que la clave primaria identifique de manera unívoca 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 estándar SQL2 y las implementaciones más recientes ofrecen un amplio soporte a la integridad referencial, como las reglas de eliminación y de actualización que indican al SGBD el modo en que debe tratar la eliminación y la modificación 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 ejecución de las instrucciones INSERT, DELETE o UPDATE. "Las restricciones de comprobación ofrecen una manera más limitada de incluir las reglas de negocio en la definición de las bases de datos y hacer que el SGBD consiga que se cumplan.
CAPíTULO
12
\
Procesamiento de transacciones Las actualizaciones de las bases de datos suelen ser desencadenadas por eventos del mundo real, como la recepción de un pedido nuevo de un cliente. De hecho, la recepción de un pedido nuevo no genera una actualización, sino esta serie de cuatro actualizaciones en la base de datos de ejemplo: • • • •
Añadir 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.
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 situación 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 cálculos serán incorrectos. La secuencia de actualizaciones, por tanto, debe ser una proposición todo o nada de la base de datos. SQL ofrece precisamente esta posibilidad mediante sus características de procesamiento de transacciones, que se describen en este capítulo.
Concepto de transacción Una transacción es una secuencia de una o varias instrucciones de SQL que forman conjuntamente una unidad lógica de trabajo. Las instrucciones de SQL que fonnan la transacción suelen estar íntimamente relacionadas y llevan a cabo acciones interdependientes. Cada instrucción de la transacción lleva a cabo una parte de la tarea, y todas ellas son necesarias para completarla. La agrupación de las instrucciones como una sola transacción indica al SGBD que toda la secuencia de
315
316
Capítulo 12: Procesamiento de transacciones
SOL. Manual de referencia
3·17
~
instrucción debe ejecutarse de forma atómica -se deben completar todas las instrucciones para que la base de datos quede en un estado consistente. A continuación se ofrecen algunos ejemplos de transacciones típicas para la base de datos de ejemplo, junto con la secuencia de instrucciones_ de SQL que comprende cada transacción: • Añadir un pedido. Para aceptar el pedido de un cliente, el programa de introducción 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, añadiendo el importe del pedido a las ventas totales del representante que ha tramitado el pedido y (e) actualizar la tabla OFICINAS, añadiendo 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
r
- !SELECT
¡ ¡ ¡
Transacción (
=
'-.
~
Estado de la base de datos antes de la transacción
!SELECT
¡ ¡ ¡
UPDATE
UPDATE
UPDATE
UPDATE
DELETE
DELETE
¡ Estado de la base
Figura 12.1.'
COMMIT
.,
l
!
l
! SELECT
¡ ¡
UPDATE
El SGBD deshace todas las modificaciones
INSERT
de datos después de la transacción
~
El SGBD deshace todas las modificaciones
El concepto de transacción de SOL
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: La instrucción COMMIT señala la conclusión con éxito de una transacción. Indica al SGBO que la transacción se ha completado; se han ejecutado todas las instrucciones que confonnan la transacción, y la base de datos es autoconsistente. ROLLBACK. La instrucción ROLLBACK señala el -fracaso de una transacción. Indica al SOBO que el usuario no desea completar la transacción; en lugar de ello, el SGBD debe volverse atrás de las modificaciones realizadas en la base de datos durante la transacción. En efecto, el SGBD devuelve la base de datos a su estado previo al comienzo de la transacción.
• COMMIT.
•
Las instrucciones COMMIT y ROLLBACK son instrucciones de SQL ejecutables, igual que SELECT, INSERT Y UPDATE. A continuación se ofrece un ejemplo de una transacción de actualización con éxito que modifica la cantidad y el importe de un
] 318
SOL. Manual de referencia
'-
COMMIT - - - - -
f----
Figura 12.2.
Capítulo 12: Procesamiento de transacciones
319
I
Lwo.. -.J Lwo.. -.J
ROLLBACK - - - -
I •
I
Modificar la cantidad del pedido número J13051 de 4 a /0, lo que incrementa su imporle desde 1458 € a 3550 €. El pedido es de reducloras QAS-XK47 y lo tramitó León Freire (empleado número /08), que trabaja en León (oficina número 21).
II
UPDATE PEDIDOS 10. IMPORTE SET CANTIDAD WHERE NUM_PEDIDO ~ 113051
••
UPDATE REPRESENTANTES SET VENTAS ~ VENTAS - 1458.00 WHERE NOM_EMPL = 108
3550.00
+
3550.00
UPDATE OFICINAS SET VENTAS ~ VENTAS - 1458.00 + 3550.00 WHERE OFICINA ~ 21
Diagramas de sintaxis de las instrucciones COMMIT y ROLLBACK.
UPDATE SET WHERE ANO
pedido y ajusta los totales del producto, del representante y de la oficina asociados con el pedi~o. U~a modific~ción como ésta la manejaría normalmente un programa de modlficacI6n de pedidos basado en formularios, que ulilizaría SQL para programación para ejecutar las instrucciones que se muestran.
... ¡Vaya! El fabricante es «QSA», no «QAS»... .Modificar La cantidad del pedido número 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 Fre¡re (empleado Ilúmero 108), que Irabaja ell Le61l (oficilla Ilúmero 21).
ROLLBACK WORK
UPDATE
El modelo de transacciones ANSI/ISO
PEDIDOS
SET CANTIDAD = 10, IMPORTE WHERE NUM_PEDIDO = 113051
3550.00
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
... confirmar por última vez la modificación con el cliente... COMMIT WORK
A. continuación se ofrece la misma transacción, pero esta vez supóngase que el usuano comete un error al i~~ucir el número de producto. Para corregir el error, se hace retroce~er la transacclOn, de modo que pueda volver a introducirse de manera correcta:
--
El estándar 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 transacción, que se basa en el soporte de las transacciones de las primeras versiones de DB2. El estándar especifica que cada transacción de SQL comienza de manera automática con la primera instrucción de SQL que ejecuta un usuario o un programa. La transacción continúa con las instrucciones de SQL siguientes hasta que concluye de una de las cuatro maneras siguientes: La instrucción COMMIT concluye las transacciones con éxito, haciendo permanentes las modificaciones de la base de datos. Tras la instruc· ción COMMIT comienza de manera inmediata una nueva transacción. • ROLLBACK. La instrucción ROLLBACK aborta la transacción, volviéndose atrás de las modificaciones en la base de datos. Tras la instrucción ROLLBACK comienza de manera inmediata una nueva transacción. • Terminación con éxito del programa. Para el lenguaje SQL para programación, la terminación con éxito de un programa conlleva que concluya también con éxito la transacción, igual que si se hubiera ejecutado la instrucción COMMIT. Como ha concluido el programa, no hay ninguna transacción más que comenzar.
• COMMIT.
320
I
SOL. Manual de referencia
• Terminación anormal del programa. Para el lenguaje SQL para programación la terminación anormal de un programa hace que aborte la transacción, igual que si se hubiera ejecutado la instrucción ROLLBACK. Como ha concluido el programa, no hay ninguna transacción más que Comenzar. La Figura 12.3 muestra transacciones típicas que ilustran estas cuatro condiciones. Obsérvese que el usuario o el programa se hallan siempre en una transacción según el modelo de transacción ANSI/ISO. No se necesita ninguna acción explícita para comenzar una transacción; comienza de manera automática con la primera instrucción de SQL o inmediatamente después de que acabe la transacción anterior. Recuérdese que el estándar ANSIIISO para SQL está pensado sobre todo parn el lenguaje SQL para programación con el fin de emplearlo en programas de aplicación. Las transacciones desempeñan un papel importante en SQL para programación. ya que incluso los programas de aplicación sencillos necesitan a menudo
~
-
!
UPDATE
"'1
! - !
- !INSERT
Transacción
l.
! !
DELETE
!
-
UPDATE
COMMIT
Base de datos consistente - .
COMMIT
!
-
el n
-
INSERT
.ROLLx
-! i
-!
UPDATE
UPDA~E
COHMIT
COMMIT
! !
! -!
uñOSCüantos 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á diseñado para aplicaciones de procesamiento en línea de transacciones, es un ejemplo. SQL Server, que se creó a partir del producto de Sybase, también utiliza el modelo de transacciones de Sybase. El dialecto Transact-SQL empleado por Sybase incluye cuatro instrucciones para el procesamiento de transacciones:
(-!
INSERT
! DELETE I
INSERT
\Ci
•
programa aborta •
!
consistente
Figura 12.3.
321
ejecutar secuencias de dos o tres instrucciones de SQL para desempeñar su tarea. Como los usuarios -pueden cambiar de opinión y pueden darse otras condiciones (como la falta de existencias de un producto que desee encargar un cliente), los programas de aplicación 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 también pueden utilizarse en SQL interactivo, pero, en la práctica, 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 anotación de las instrucciones en una instalación para SQL interactivo. En consecuencia, las transacciones suelen constituir una preocupación de orden menor en SQL interactivo. De hecho, muchos productos de SQL interactivo toman como valor predeterminado un modo de compromiso automático, en el que se ejecuta de manera automática una instrucción COMMIT tras cada instrucción de SQL escrita por el usuario. Esto transforma de hecho cada instrucción de SQL interactivo en su propia transacción.
• BEGIN TRANSACTION. La instrucción BEGIN TRAN8ACTION
COMMIT
Basededat~
Capítulo 72: Procesamiento de transacciones
Otros modelos de transacciones
Base de dato..!.,..
consistente
Transacción (
"--
Transacciones comprometidas y que se han hecho retroceder.
•
señala el comienzo de una transacción. A diferencia del modelo de transacciones ANSI/ISO, que da comienzo de forma explícita a una transacción nueva cuando concluye la anterior, Sybase exige una instrucción explícita para iniciar una transacción. COMMIT TRANSACTION. Señala la finalización con éxito de una transacción. Al igual que en el modelo ANSI/ISO, todas las modificaciones de la base de datos realizadas durante la transacción se vuelven permanentes. No obstante, no se inicia de manera automática una transacción nueva. SAVE TRANSACTION. Establece un punto de revisión en mitad de una transacción. Sybase guarda el estado de la base de datos en ese momento de la transacción y asigna al estado guardado un nombre de punto de revisión, que se especifica en la instrucción. ROLLBACK TRANSACTION. Tiene dos cometidos. Si en la instrucción ROLLBACK se asigna un nombre a un punto de revisión, Sybase se vuelve atrás de las modificaciones de la base de datos realizadas desde el punto de revisión, lo que de hech9 hace retroceder la transacción hasta el punto en .que se ejecutó la instrucción 8AVE TRANSACTION. Si no se asigna nombre a ningún
322
SOL. Manual de referencia
Capítulo 12: Procesamiento de transacciones
punto de revisión, la instrucción ROLLBACK se vuelve atrás de rodas las mo-
dificaciones en la base de datos desde la instrucción
BEGIN TRANSACTION.
El mecanismo de puntos de revisión 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 aplicación de la figura guarda de manera perió-
Estado de la base
de datos aotes---+ de la transacción
+ + INSERT + DELETE + TRANSACTION A ---------+ +
BEGIN TRANSACTIQN
SAVE
Punto de revisión A
->
UPDATE
DELETE
+ + UPDATE + INSERT +
SAVE TRANSACTION B - - - -
Punto de revisión B
->1.
ROLLBACK 70 B
UPDATE
OELETE COMMIT TRANSACTION
.¡. Estado de la base
323
~
dica su estado a medida que la transacción avanza, estableciendo dos puntos de revisi6n con nombre. Si surgen problemas en un momento posterior de la transacción, el programa de aplicación 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 revisión siguen vigentes; la operación de retroceso deshace las ejecutadas a partir del punto de revisión. Obsérvese que toda la transacción sigue siendo la unidad lógica 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 transacción, por ejemplo, la base de datos deshace toda la transacción. Por tanto, los puntos de revisión son una comodidad para el programa de aplicación, pero no suponen una modificación fundamental del modelo de transacciones ANSIIISO. El empleo explícito de una instrucción BEGIN TRANSACTION supone, sin embargo, una desviación 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 automático. Cada instrucción se compromete en cuanto se ejecuta; no hay manera de hacer que la instrucción retroceda una vez que ha tenido éxito. Algunas marcas de SOBD que utilizan un modelo de transacciones del estilo de Sybase prohíben 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 Capítulo 13, o GRANT y REVOKE, que se estudian en el Capítulo 15) aparezcan dentro de las transacciones. Estas instrucciones deben ejecutarse fuera de las transacciones. Esta restricción hace más sencillo de implementar el modelo de transacciones, ya que asegura que la estructura de la base de datos no se modifique durante la transacción. Por el contrario, en una implementación completa del modelo de transacciones del estilo ANSI/ISO, la estructura de la base de datos puede modificarse de manera significativa durante una transacción. (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 transacción retroceda. En la práctica esto puede resultar difícil de implementar, y muchos productos de SGBD populares introducen restricciones simplificadoras. Una restricción 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 transacción. Otra restricción habitual es que las transacciones que modifican la estructura de la base de datos sólo puedan contener una única i.ostrucción de SQL (como la instrucción CREATE TABLE o DROP TABLE).
de datós después-----+ de la transacción
Transacciones: entre bastidores* Figura 12.4. . Un modelo alternativo (explícito) de transacciones utilizado por Sybase. .
El compromiso de todo o nada que el SGBD realiza con cada transacción parece casi mágico para los usuarios nuevos de SQL. ¿Cómo puede el SGBD echarse
324
,----
SOL. Manual de referencia
atrás de las modificaciones realizadas en la base de datos si se produce un fallo del sistema en el transcurso de la transacción? Las técnicas concretas empleadas por las diferentes marcas de SOBO varían, pero casi todas se basan en un registro de transacciones, como puede verse en la Figura 12.5. 'Así es como funciona el registro histórico de transacciones: de una manera simplificada y conceptual. Cuando el usuario ejecuta una instrucción de SQL que modifica la base de datos, el SOBO escribe de manera automática un registro en el registro histórico de transacciones, en el que muestra dos copias de cada fila afectada por la instrucción. Una copia muestra la fila antes de la modificación y la otra muestra la fila tras la modificación. Sólo después de haber escrito el registro histórico, el SOBD modifica realmente la fila en el disco. Si el usuario ejecuta posteriormente una instrucción COMMIT, el fi~al de la transacción se anota en el registro de transacciones. Si el usuario ejecuta una instrucción ROLL-
.L.VI .
UPDATE OFICINAS
12:04
f---+
• •
·
DELETE FROM CLIENTES
~
·•• SGBD
• • •
Ubicación de la fila:_ Antes:-,-,-,--,....I--'_ Después:_,...............:"'_,_ Ubicación de la fila:_ Antes:.......I....I_ Después: (Vacía) Ubicación de·la fila:_ Antes:--,--,-,_ Después: (Vacía)
Transacciones y procesamiento multiusuario
12:05 INSERT INTO PRODUCTOS
12:06
I Figura 12.5.
COMMIT
·• ·
Cuando dos o más usuarios tienen acceso, de manera simultánea, a la base de datos, el procesamiento de las transacciones adopta una dimensión nueva. Ahora el SGBD no sólo debe recuperarse de manera adecuada de los fallos o de los errores del· sistema, sino que también debe asegurar que las acciones de los usuarios no interfieran entre sí. Idealmente, cada usuario debería 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 aíslen 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.
Ubicación de la fila:_ Antes: (Vada) Después:...--'.........._
·· ·
I
•
325
BACK, el SOBO examina el registro.histórico para hallar las imágenes «previas» de las filas que se hayan modificado desde el comienzo de la transacción. Mediante estas imágenes el SOBO devuelve las filas a su estado anterior, deshaciendo todas las modificaciones de la base de da lOS realizadas durante la transacción: Si se produce un falJo del sistema, el operador del sistema suele recuperar la b.ase de datos ejecutando una utilidad de recuperación especial proporcionada con el SOBO. La utilidad de recuperación examina el final del registro histórico de transacciones, buscando las transacciones no comprometidas antes del fallo. La utilidad deshace cada una de las transacciones incompletas, de modo que sólo 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 histórico de transacciones impone obviamente una sobrecarga a las actualizaciones de la base de datos. En la práctica, los principales productos comerciales de SOBD utilizan técnicas de registro histórico mucho más sofisticados que el esquema sencillo a<)uí descritó para minimizar esa sobrecarga. Además, el registro de transacciones suele 'almacenarse en una unidad rápida 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 histórico 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é, también pueden utilizar esta arquitectura sin registro histórico., También puede suponer una alternativa aceptable para las bases de datos especializadas para producción; por ejem· plo, en las que el contenido de la base de datos se halla reproducido en un sistema informático duplicado. En las bases de datos de producción más frecuentes, sin embargo, el esquema de registro histórico y su sobrecarga constituyen parte iote· gral de la operación de la base de datos.
Registro histórico de transacciones
.Secuencia de instrucciones SOL
Capítulo 12: Procesamiento de transacciones
Transacción comprometida
• • •
El registro histórico de transacciones.
1
326
SOL. Manual de referencia
Capítulo 12: Procesamiento de transacciones
El problema de la actualización perdida
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. Además, la base de datos ~uestra que sigue habiendo todavía catorce cables para la venta. Este ejemplo ¡Justra el problema de la actualización perdida que puede darse siempre que dos programas lean de la base de datos los mismos datos, utilicen esos datos como base para un cálculo y traten de actualizar los datos.
La Figura] 2.6 muestra una aplicación sencilla en la que dos usuarios aceptan. pe-
didos telefónicos de los clientes. El programa de introducción 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. María comienza a introducir el pedido de su cliente de ciento veinticinco cables ACI-41004. Cada programa de introducción de pedidos realiza una consulta del archivo PRODUCTOS, y los dos encuentran que hay 139 cables en stock -más que suficiente para cubrir la solicitud del cliente-o José pide a su cliente que confirme el pedido. y su copia del programa de introducción 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 más tarde, María pide a su cliente que confirme el pedido. Su copia del programa de introducción de pedidos actualiza el archivo PRODUCTOS para que muestre (139 - 125) ;:;: 14 cables todavía en stock. e inserta un pedido nuevo de ciento veinticinco cables en la tabla PEDIDOS.
327
I El problema de los datos no comprometidos L~ Figura 12.7 muestra la misma aplicación 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é
Programa de Maria
Tabla PRODUCTOS 12: 00
Programa de José
Programa de Maria
Tabla PRODUCTOS
IO_FAB
ID_PRODUCTO
ACl
41004
STOCK
12: ...... ID FA!!
ID PRODUCTO
ACI
41004
STOCK
1J9
:
e',:'::' O",'~-;::=:-::=., / SELtcT STOCX FROM ~
SELECT STOCK FROM PRODUCTOS
"-r'~'='o~'=-==:-::=--, '---+ SELECT STOCK FROM
PRODUCTOS
Respuesta: 139
PRODUCTOS
1
Respuesta: 139
Respuesta: 139
12 :04
(AcePtar pedido de 100
ID_P"AB
( Aceptar pedido de 100)
/
12 :04
I
ACl
UPDATE PRODUC'1'OS SET STOCK = 39
ID PRQOUCTO
41004
:
I
: OS ID FAB
STOCK
12: 04
r
" 12: 05
I ID PRODUCTO
STOCK
: ACl
1
Aceptar pedido de 125
12 :04 IDJAS
41004
14
'"
12 01
UPDATE PRODUCTOS SET STOCK = 14
ID_PRODUCTO
STOCK
: ACl
UPDATE PRODUCTOS SET STOCK e 39
I
41004
12: 05
39
SELEC'T STOCK FROM PRODUCTOS
:
"-. 12: 06
I
IDJAS
"
1
ID PRODUCTO
STOCK
Respuesta: 139
1
(Recaha~ar pedido de 125)
06 ROLLB1l.CK
1/
ACl
41004
'"
1 ( Nota: ¡Comprar mlls1 ")
Figura 12.6~
El problema de la actualización perdida.
Figura 12.7.
El problema de los datos no comprometidos.
328
---
SOL. Manual de referencia
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 cüente las ventajas relativas de los cables ACI-41004 y ACI-4100S. Entretanto, el cliente de María intenta encargar ciento veinticinco cables ACI41004. La copia de María del programa de procesamiento de pedidos consulta la tabla PRODUCTOS; s610 halla 39 cables disponibles y rechaza el pedido. También genera un aviso que indica al jefe de compras de que debe comprar más 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 transacción. Como se permitió al programa de procesamiento de pedidos de María que viera la actualización no comprometida del programa de José, se rechazó el pedido del cliente de María, y. el jefe de compras encargará más cables, aunque todavía queden 139 en stock. La situación hubiera sido todavía peor si el cliente de María hubiera decidido conformarse con los 39 cables. En ese caso, el programa de Ma-. ría hubiera actualizado la tabla PRODUCTOS para que mostrara cero unidades dis· ponibles. Pero cuando se hubiera producido el RQLLBACK de la lransacción de José, el SGBD hubiera situado las existencias disponibles de nuevo en 139 cables, aunque 39 de ellos estuvieran comprometidos con el cliente de María. . El problema de este ejemplo es que se ha autorizado al programa de María a ver las actualizaciones no comprometidas del programa de José y ha actuado sobre ellas, lo que ha generado el resultado erróneo. El estándar SQL2 hace referencia a este problema como Pi, también denominado problema de la lectllra desfasada. En la jerga del estándar, los datos que ha visto el programa de María están desfasados porque el programa de José no los ha comprometido.
Capítulo 12: Procesamiento de transacciones
Tabla PRC?OUCTOS
Programa de José
Programa de Maria
12: OQ
ID_FAS
AC>
ID PRODUCTO
41004
STOCK
'"
~
./
12:01
329
SELECT STOCK PROM PRODUCTOS Respuesta, 139
SELECT STOCK FROH PRODUCTOS. ID • 41004 Respuesta: 139
12:03
( Aceptar pedido de 100
SELEe'I' STOCK FROH PRODUCTOS ID '" 41005
12,05
12:04
I
,
~
UPOATe PRODUCTOS SET STOCK'" 39
12:04 ID FAB
AC>
ID PROOt./CTO
41004
SELECT STOCK FROl'l PRODUCTOS ID " 41004 l'lespuestll: 39 STOCK
39
El problema de los datos inconsistentes Fi9l:'ra 12.8.
La Figura 12.8 muestra una vez más la aplicación de procesamiento de pedidos. Nuevamente, José comienza aceptando un pedido de su cliente de' cien cables ACI41004. Poco después, María también 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 María pregunta por los cables ACI41005 como alternativa, y el programa de María 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 María decide encargar los cables ACI-41004 que María propuso inicialmente. Su programa realiza otra consulta de una soja fila para obtener nuevamente la información de los cables ACI-41004. Pero, en vez de hallar los 139 cables que había en stock sólo 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 situación del. mundo real. S610
El problema de los .datos inconsistentes.
quedan 39 cables ACI-41004 porque el cliente de José ha adquirido cien. No hay ningún problema con que María 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 María, la base de datos no se mantuvo consistente durante su transacción. Al comienzo de la transacción una fila contenía unos datos determinados, y más adelante, en la misma transacción, contenía 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 María no intente nunca actualizar la base de datos basándose en los resultados de la primera consulta. Por ejemplo, si el programa está acumulando totales O calculando estadísticas, no puede estar seguro de que las estadísticas reflejen una vista estable y consistente de los datos. El problema en este caso es que se ha permitido al programa de
L
330
Capítulo 12: Procesamiento de transacciones
SOL. Manual de referencia
María que vea unas actualizaciones no comprometidas del programa de José que afectan a filas que ya ha examinado. El estándar SQL2 se refiere a este problema como P2, también denominado problema de la lectura no repetible. El nombre se deriva del hecho de que el programa de María no puede repetir el mismo acceso de lectura a la base de datos y obtener los mismos resultados.
El problema de la inserción fantasma La Figura 12.9 muestra nuevamente una aplicación de procesamiento de pedidos. Esta vez, el jefe de ventas ejecuta un programa de informes que explora la tabla
Programa de actualización
Tabla PEDIDOS
12:00 NUM_PEDlDO IMPORTE 112961 31.S00,OO€ 113012
Programa de informes
12:00
SELECT
FROM
PEDIDOS
J. 745, OO€
331
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 transacción. Poco después el programa del jefe de ventas (que sigue operando dentro de su transacción 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 situación del mundo real y su integridad está intacta, pero la misma consulta realizada dos veces durante la misma transacción 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 instrucción UPDATE. En el ejemplo de la Figura 12.9 el problema lo causa una instrucción 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 inserción fantasma pueden ser cálculos inconsistentes e incorrectos. El estándar SQL2 se refiere a esto como P3, y también utiliza el término fantasma para describirlo.
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 corrupción de la base de datos. SQL utiliza su mecanismo de transacciones para eliminar esta fuente de corrupción de la base de datos. Además del compromiso de todo o nada para las instrucciones de cada transacción, los SGBD basados en SQL realizan este compromiso para las transacciones:
Durante una transacción 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 afectarán a los datos vistos por el usuario durante la transacción.
Respuesta: 118102,5.00üE 12:13
Respuesta: 111312,3.745€
Figura 12.9.
El problema de la inserción fantasma.
Las transacciones son, por tanto, la clave de la recuperación y del control de la simultaneidad en las bases de datos de SQL. El compromiso anterior puede reformularse de manera explícita en términos de la ejecución de transacciones concurrentes:
Si dos transacciones, A y B, se ejecutan de manera simultánea, el SGBD asegura que el resultado será el mismo que si (a) la transacción A se ejecutara primero y la transacción B después o (b) la transacción B se ejecutara primero y la transacción A después.
332
I!
I
1
11
:1
~
SOL. Manual de referencia
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 ningún otro usuario tuviera acceso a la base de datos de manera concurrente. En la práctica, se pueden estar ejecutando docenas o centenares de transacciones-de manera simultánea dentro de las grandes bases de datos de producción. El concepto de secuenciabilidad puede ampliarse directamente para abarcar esta situación. La secuenciabilidad garantiza que, si se está ejecutando un número N de transacciones simultáneas, 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, sólo que el resultado debe coincidir con el de alguna secuencia. El hecho de que el SGBD aísle al usuario de las acciones de otros usuarios concurrentes no significa que se pueda olvidar totalmente de ellos. De hecho, la situación 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 más cortas y sencillas posible, para maximizar la cantidad de procesamiento en paralelo que se pueda realizar. Supóngase, por ejemplo, que se ejecuta un programa que lleva a cabo una secuencia de tres consultas de gran tamaño. 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 instrucción COMMIT después de cada consulta. ¿El motivo? Recuérdese que SQL comienza de manera automática una Jransacción con la primera instrucción SQL de cada programa. Sin una instrucción COMMIT, la rransacción continúa hasta que el programa concluye. Además, SQL garantiza que los datos recuperados durante una transacción 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, ningún otro usuario puede modificar esa fila hasta que concluya la transacción, ya que pudiera intentarse volver a recuperar la fila más adelante en la transacción, 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 m·ayores de la base de datos. La moraleja de este ejemplo es sencilla: al escribir programas para bases de datos de SQL de producción hay que preocuparse siempre de las transacciones. Las transacciones deben ser siempre todo lo breves que sea posible. «COMMIT rápido y COMMIT a menudo» es un buen consejo cuando se emplea SQL para programación. En la práctica, la implementación de un modelo estricto de transacciones multiusuario puede suponer una sobrecarga considerable en la operación de una base de datos con docenas, centenares o millares de usuarios concurrentes. Además, puede que las particularidades de la aplicación no exijan el aislamiento absoluto entre los programas de usuario que implica el modelo de transacciones de SQL. Por ejemplo; puede que el diseñador de la aplicación sepa que se ha diseñado el programa de búsqueda de pedidos de modo que nunca intente leer y volver a leer una fila de la base de datos durante cada transacción. En este caso, el problema de
Capítulo 12: Procesamiento de transacciones
333
los datos inconsistentes no puede darse, debido a la estructura del programa. De manera alternativa, puede que el diseñador de la aplicación sepa que todos los accesos de un programa a tablas concretas de la base de datos son de sólo lectura. Si el programador puede transmitir infonnación de este tipo al SGBD, se puede eliminar parte de la sobrecarga de las. transacciones de SQL. El estándar SQLl no abordaba este problema del rendimiento de las báses de datos, y la mayor parte de las marcas de SGBD implementaban esquemas propietarios para mejorar el rendimiento de las transacciones de SQL. El estándar SQL2 especificó una nueva instrucción SET TRANSACTION cuya función es especificar el nivel de soporte del modelo de transacciones de SQL que necesita cada aplicación. No hace falta utilizar la instwcción 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 operación, resulta útil comprender los cierres y otras técnicas empleadas por los productos de SGBD comerciales para implementar transacciones de SQL multiusuario. El resto de este capítulo estudia los bloqueos, las posibilidades de optimización de rendimiento·de SQL2 y las diferentes IÚarcas de SGBD que dependen de ello.
Bloqueo
I
!
*
La mayor parte de los principales productos de SGBD utilizan técnicas de bloqueo sofisticadas para manejar las transacciones de SQL simultáneas para muchos usuarios concurrentes. No obstante, los conceptos básicos 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 simultáneas. Cuando la transacción A de la figura tiene acceso a la base de datos, el SGBD bloquea de manera automática cada parte de la base de datos que la transacción recupera. o modifica. La transacción B sigue adelante en paralelo, y el SGBD bloquea también las partes de la base de datos a las que tiene acceso. Si la transacción B intenta tener acceso a la parte de la base de datos que ha bloqueado la transacción A, el SGBD bloquea la transacción B, lo que hace que espere a que se desbloqueen los datos. El SGBD sólo libera los bloqueos establecidos por la transacción A cuando concluye con una operación COMMIT o ROLLBACK. El SGBD desbloquea entonces la transacción B, lo que le permite seguir adelante. La transacción B puede bloquear ahora esa parte de la base de datos por sí misma, protegiéndola de los efectos de otras transacciones. Como muestra la figura, la técnica de los bloqueos concede de manera temporal a una transacción 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 transacción espere un tiempo muy largo mientras los fragmentos de la base de datos a los. que desea. tener acceso están bloqueados por otras transacciones.
334
SGBD
Transacción A
12,01
I
Capítulo 12: Procesamiento de transacciones
SOL. Manual de referencia
~ ~
j
UPDATE PEDIroS
Transacción B PRQJ){ICTOS
desbloqueada desbloqueada desbloqueada I I I , I I T
I
Bloq"..d.
I
I~ Proced~~ra A
~
.:12::'O::2:.....~.,--...,...,.,
Bloqueada para B P
12:03 SELECT.
T
FOH OFICINAS....-------
cooo "
Bloqueada
~ Pro--d.,
~UPDATE
d
12'"
PRODUCTOSI
1
para A
.....
Esperar.......-i SELECT... 12:05
I
UPDATE PEDIDOS
I~
Proceder
12:06
1UPDATE OFlCINASI~ Proceder
12:07
+
:'::::""'CO=MM"'=T:---'--+
desbloqueada desbloqueada _:.....:.:::=:.....--J~ Proceder I I I
:I I I •
I
FOH OFICINAS ,
•1----'-=--,
12:07
Figura 12.10.
--tof
I I I I I I I I I I I
Proceder
Bloqueada para B
+
12:08
desbloqueada desbloqueada Proceder,_..... ::J'--_..:C..:OMM=':.:T_--J1 1 I T
I I •
I
Bloqueo con dos transacciones concurrentes.
Niveles de bloqueo Los bloqueos pueden implementarse en varios niveles de la base de dalos. En su forma más básica. el SGBD podria bloquear toda la base de datos para cada transacción. Esta estrategia de bloqueo sería sencilla de implementar, pero sólo pemiitiría el procesamiento de las transacciones una a una. Si la transacción incluye algún tiempo muerto (como puede ser tiempo para discutir un pedido con un cliente), todos los demás accesos a la base de datos se bloquearían durante ese tiempo, lo que llevaría a un rendimiento inaceptablemente bajo. No obstante, el bloqueo en
335
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 tamaño. En esos casos puede resultar más eficiente realizar rápidamente una única operación de bloqueo, ejecutar rápidamente la operación 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 sólo bloquea las tablas a las que tiene acceso una transacción. Otras transacciones pueden tener acceso de manera concurrente a otras tablas. Esta técnica permite más procesamiento paralelo, pero todavía puede llevar a un rendimiento inaceptablemente bajo en aplicaciones como la introducción 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 páginas. En este esquema el SGBD bloquea bloques de datos (páginas) desde el disco a medida que una transacción tiene acceso a ellas. Se evita que otras transacciones tengan acceso a las páginas bloqueadas, pero pueden tener acceso (y bloquear para ellas mismas) otras páginas de datos. Se utilizan frecuentemente tamaños de páginas de 2KB, de 4KB y de 16KB. Dado que las tablas de gran tamaño se extienden a Jo largo de cientos o de millares de páginas, dos transacciones que intenten tener acceso a dos fiJas diferentes de una tabla tendrán normalmente acceso a dos páginas diferentes, lo que permite que dos transacciones sigan adelante en paralelo. En los últimos años la mayor parte de los SaBD comerciales han ido más allá del bloqueo en el nivel de página: 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 pequeño tamaño que contienen registros pequeños, como la tabla OFICINAS de la base de datos de ejemplo. Los bloqueos en el nivel de filas ofrecen un grado elevado de ejecución 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 páginas de tamaño fijo, resulta una tarea mucho más compleja, por lo que el mayor paralelismo llega a costa de una lógica de bloqueos más 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 más operaciones en paralelo dentro de la base de datos. Algunos productos de SGBD abordan esta situación promoviendo de manera automática muchos bloqueos en el nivel de tablas a bloqueos en el nivel de páginas, o de tablas cuando el número de bloqueos en el nivel de filas de una transacción dada superan cierto límite. Como muestra este ejemplo, no ocurre siempre que un nivel de implementación de bloqueos más granular (menor) sea mejor; el mejor esquema depende enormemente de las transacciones concretas y de las operaciones de SQL que puedan contener. Resulta posible teóricamente ir más allá de los bloqueos en el nivel de filas, hasta los bloqueos en el nivel de los elementos de datos. En teoría, esto ofrecería todavía más paralelismo que los bloqueos en el nivel de filas, ya que permitiría el acceso si-
~
336
Obsérvese que una transacción sólo puede adquirir un bloqueo exclusivo si ninguna otra transacción tiene en ese momento un bloqueo ni compartido ni exclusivo sobre esos datos. Si una transacción intema adquirir un bloqueo no permitido por las reglas de la Figura 12.11, se bloquea hasta que las demás 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 simultáneo a la base de datos. Los productos de SGBD maduros y complejos, como DB2, tienen más de dos tipos de bloqueos y utilizan diferentes técnicas 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
rnultáneo 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. Ningún 'SGBD comercial de SQL utiliza bloqueos en el nivel de los elementos de
datos. De hecho, los bloqueos constituyen un área de investigación considerable en la tecnología de las bases de d'J-tos. y los esquemas de bloqueo utilizados ·en los productos de SGBD comerciales son mucho' más sofisticados que el esquema fundamental aquí descrito. El más 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 simultáneo a las bases de datos, la mayor parte de los productos de SGBD comerciales utilizan un esquema de bloqueo con más de un tipo de bloqueo. Los esquemas que utilizan bloqueos compartidos y bloqueos exclusivos resultan bastante frecuentes:
Desbloqueada
• Bloqueo compartido. Utilizado por el SGBD cuando una transacción desea leer datos de la base de datos. Otra transacción concurrente puede adquirir también un bloqueo compartido sobre los mismos datos, lo que permite que la otra transacción lea también los datos. • Bloqueo exclusivo. Utilizado por el SGBD cuando una transacción desea actualizar los datos de la base de datos. Cuando una transacción tiene un bloqueo exclusivo sobre algunos datos, las demás transacciones no pueden adquirir ningún tipo de bloqueo (ni compartido ni exclusivo) sobre esos datos.
12:01
1
UPOATE PEDIDOS
12:03 S';(..ECT. FROM OFICINAS
La Figura 12.11 muestra las reglas de este esquema de bloqueo y las combinaciones de bloqueos permitidas que pueden tener dos transacciones concurrentes.
OK
Bloqueo compartido
Bloqueo excusivo
OK
OK
I
..
Bloqueo exclusivo para A Proceder •
I~
~Iproceder
Bloqueo exclusivo
Figura 12.11.
OK OK
OK NO
I
I I I I I I
~
I
I I I I
~
Bloqueo exclusivo para B Proceder
UPOATE PEDIDOS
I","
I~I
OFICINAS·I~
Proceder
I
Proceder
NO
12:07
I
NO
""'UT
1-1
I I
o...,;,'"''
+-- Proceder
1
I
• Figura 12.12.
Reglas para los bloqueos compartidos y exclusivos. I
I
L
12:02
~
UPDATE PlI.ooucros
Bloqueo compar1ido para A
!
Transacción1 Bloqueo compartido
,
PRODUCTOS Desbloqueada
~
UPOATE
A
~ Desbloqueada
12:04
Bloqueo companido para A. B
12:05
Sin bloqueo
Transacción B
SGBO
Trans.acción A
fEllIOQO
Sin bloqueo
337
Capítulo 12: Procesamiento de transacciones
SOL. Manual de referencia
Bloqueo companido para A
!
Bloqueo exclusivo pareA
".,J,~." I I
•
Proceder
~12:05
i
DesblOq~eada I I I I I I I
I I
I I I
,.,
Bloqueos compartidos y exclusivos.
~
1
SELECT .•• FROM OFICINAS
P/oceder
COXMIT
I
338
SOL. Manual de referencia
Capítulo 12: Procesamiento de transacciones
deseadas entre las transacciones, al tiempo que ofrecer el mayor acceso simultáneo posible a la hase de datos. todo ello con la sobrecarga de bloqueos mínima.
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 situación 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
SGBO
Transacción A ~
Desbl~ueada
Transacción B
PROpUqpS Desblo~ueada
I I I I I
•
12;01
1
1-
UPDATE PEDIDOS
Proceder
Bloqueo exclusivo para B
12:03
IUPDATE
Bloqueo exclusivo para A
PRODUCTOS
12:02 Proceder
--aJ UPDATE
PRODUCTOS
1
~ Esperar
12:04 Esperar ~ UPDATE PEDIDOS -)
,
I I I I I I I I I I
• Figura 12.13:
Un interbloqueo de transacciones.
339
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 página, en funci6n del tipo de bloqueo implementado). Sin intervención exterior cada programa esperará de manera indefinida a que el otro programa comprometa su transacción y desbloquee los datos. La situación de la figura es un interbloqueo sencillo entre dos programas, pero se pueden dar situaciones más complejas en las que tres, cuatro o más programas se hallen en un ciclo de bloqueos y cada uno de ellos espere datos que estén bloqueados por alguno de los otros programas. Para tratar con los interbloqueos, los SGBD suelen incluir lógica que comprueba de manera periódica (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 transacción perdedora, lo que permite continuar a la vencedora del interbloqueo. El programa perdedor recibe un código de error que infonna de que ha perdido un interbloqueo y de que se ha hecho retroceder a su transacción. Este esquema de rotura de interbloqueos significa que cualquier instrucción de SQL puede devolver un código de error de pérdida de interbloqueo, aunque no haya nada erróneo en la instrucción 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 instrucción INSERT. por ejemplo. o incluso una instrucción SELECT- resulten perdedoras de un interbloqueo. Se hace retroceder a la transacción que intenta realizar la instrucción sin que haya cometido ningún error. sólo debido al resto de la actividad concurrente de la base de datos. Puede que esto parezca injusto. pero. en la práctica. resulta mucho mejor que las otras dos alternativas -interbloqueos eternos o corrupción de la base de datos. Si se produce un error de pérdida de interbloqueo en SQL interactivo, el usuario puede, sencillamente. volver a escribir las instrucciones de SQL. En SQL para programación el programa de aplicación debe estar preparado para manejar el código de error de pérdida de interbloqueo. Generalmente, el programa responderá advirtiendo al usuario o volviendo a intentar la transacción de manera automática. 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 transacción 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. Además. algunas de las características de bloqueo avanzadas que se describen en apartados posteriores de este capítulo pueden utilizarse para reducir aún más el número de interbloqueos que se producen.
Técnicas avanzadas de bloqueo
*
Muchos productos comerciales de bases de datos ofrecen características avanzadas de bloqueo que superan ampliamente las proporcionadas por las transacciones estándar de SQL. Se incluyen:
340
SOL. Manual de referencia·
• Bloqueos explícitos. Un programa puede bloquear de manera explícita 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. transacción, lo que permite al SGBO liberar los bloqueos antes de que concluya la transacción. • Parámetros de bloqueo. El administrador de la base de datos puede ajustar de manera manual el tamaño del fragmento bloqueable de la base de datos y olros parámetros de bl<:,queo para ajustar el rendimiento de los bloqueos.
Estas características no suelen ser estándar y dependen de cada producto. No obstante, varias de ellas, especialmente las introducidas inicialmente en las versiones de DB2 para grandes sistemas hace años, se han implementado en varios productos comerciales de SQL y han conseguido generalizarse, aunque no sean estándar. De hecho, las características de los niveles de aislamiento introducidas en DB2 han logrado incorporarse al estándar SQL2.
Bloqueos explícitos
*
Si una transacción tiene acceso a una tabla repetidas veces, la sobrecarga de la adquisición de pequeños bloqueos sobre muchas partes de la tabla puede ser importante. Un programa de actualización masiva que recorra cada fila de la tabla, por ejemplo, bloqueará toda la tabla, fragmento a fragmento. según avance. ·Para este tipo de transacción el programa debería bloquear de manera explícita 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 página a página). • Elimina la posibilidad de que otra transacción bloquee parte ·de la tabla y obligue a la transacción de actualización masiva a esperar. • Elimina la posibilidad de que otra transacción bloquee parte de la tabla e interbloquee la transacción de actualización masiva, lo que la obligaría a reiniciarse. Por supuesto, el bloqueo de la tabla tiene el inconveniente de que· todas las demás transacciones que intenten tener acceso a la tabla deberán esperar mientras se realiza la actualización. Sin embargo, como la transacción de actualización masiva puede avanzar mucho más rápidamente, el flujo global del SGBD puede incremen·tarse bloqueando la tabla de manera explícita. En las bases de datos de IBM se emplea la instrucción LOCK TABLE, que puede verse en la Figura 12.14, para bloquear de manera explícita toda una tabla. Ofrece dos modos de bloqueo: • El mod.o EXCLUSIVE adquiere un bloqueo exclusivo sobre toda la tabla. Ninguna otra transacción puede tener acceso a ninguna parte de la tabla por nin-
---
t- LOCK
Capítulo 12: Procesamiento de transacciones
TABLE nombre-tabla IN
---r--
SHARE
.-J
341
MODE ----..
L- EXCLUSIVE Figura"12.14.
Diagrama sintáctico de la instrucción LOCK TABLE.
gún motivo mientras se mantenga el bloqu~o. Es el modo que se suele solicitar para transacciones de actualización masiva. • El modo SHARE adquiere un bloqueo compartido sobre toda la tabla. Otras transacciones pueden leer partes de la tabla (es decir, también pueden adquirir bloqueos compartidos), pero no pueden actualizar ninguna parte de la tabla. Por supuesto, si la transacción que emite la instrucción 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 instantánea de la tabla, exacta en un momento dado. Oracle también alberga una instrucción LQCK TABLE de tipo DB2. Se puede lograr el mismo efecto en Ingres con una instrucción diferente. Otr.os sistemas de gestión de bases de datos no admiten en absoluto los bloqueos explícitos, y prefieren, en su lugar, optimizar sus técnicas de bloqueo implícito.
Niveles de aislamiento * Bajo la estricta definición de las transacciones de SQL no se permite que ninguna acción de una transacción que se ejecute de- manera simultánea afecte a los datos visibles en el curso de la transacción. Si el programa lleva a cabo una consulta de la base de datos durante una transacción. 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 serán idénticos (a ·menos que la transacción 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 transacción es el nivel de aislamiento más elevado que el programa puede tener respecto de otros programas y usuarios. El nivel de aislamiento se denomina nivel de aislamiento de la transacción. Este aislamiento absoluto de la transacción respecto de todas las demás transacciones que se ejecutan de manera simultánea resulta muy costoso en términos de bloqueos de la base de datos y de pérdida 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 simultáneas modifiquen ésta. Estos bloqueos deben mantenerse hasta el final de la transacción, por si acaso el programa volviera a realizar la consulta. En mu-
342
~
SOL Manual de referencia
chos casos, el SGBD puede reducir de manera significativa la sobrecarga de bloqueos si conoce con anticipación 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 añadieron 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 especificación 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 capítulo. A medida que disminuye el nivel de aislamiento (según se baja por las filas de la tabla), el SGBD aísla al usuario de menos problemas de las actualizaciones multiusuario. El nivel de aislamiento SERIALIZABLE es el nivel más elevado que se ofrece. En este nivel, el SGBD garantiza que los efectos de la ejecución simultánea de transacciones son exactamente los mismos que si se ejecutaran una después de otra. Se trata del nivel de aislamiento predeterminado especificado en el estándar 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 transacción y que se le garantice que los resultados serán idénticos independientemente del resto de actividades de la base de datos, se debe utilizar el nivel de aislamiento SERIAL!ZABLE.
Problema de las actualizaciones multiusuario
Datos no comprometidos
Datos inconsistentes
Inserción fantasma
Enviado por el
Enviado por el
Enviado por el
SGBD
SGBD
SGBD
Enviado por el
Enviado por el
Enviado por el
Enviado por el
SGBD
SGBD
SGBD
Puede producirse
Enviado por el
Enviado por el
SGBD
SGBD
Puede producirse
Puede producirse
Enviado por el
Puede producirse
Puede producirse
Puede producirse
Nivel de aislamiento
Actualización perdida
SERIALIZABLE
REPEATABLE READ
READ COMMITED
READ UNCOMMITED
SGBD
Figura 12.15.
SGBD
Niveles de aislamiento y actualizaciones multiusuario.
Capítulo 12: Procesamiento de transacciones
343
El nivel de aislamiento REPEATABLE READ es el segundo nivel más elevado. En este nivel no se permite a la transacción ver actualizaciones de otras transacciones ni comprometidas ni sin comprometer, y no se pueden producir problemas por l~ modificación de los datos. No obstante, puede que una fila insertada en la base de datos por otra transacción concurrente se haga visible durante la transacción. En consecuencia, puede que una consulta de varias filas ejecutada previamente en la transacción dé r~sultados diferentes que la misma consulta ejecutada posteriormente en la misma transacción (problema de la inserción fantasma). Si el programa no depende de la posibilidad de repetir una consulta de varias filas durante una transacción, 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 más elevado. En este modo no se permite que la transacción vea actualizaciones no comprometidas de otras transacciones, por lo que los problemas de la actualización 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 transacción. El programa podría, por ejemplo, llevar a cabo una instrucción SELECT de una sola fila dos veces a lo largo de la transacción 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 transacción y no acumula valores totales ni realiza otro tipo de cálculos que se basen en un conjunto de datos autoconsistente, puede utilizar tranquilamente el nivel de aislamiento READ COMMITTED. Obsérvese que si el programa intenta actualizar una fila que ya haya actualizado otro usuario, se hará que la transacción retroceda inmediatamente, para evitar que se produzca el problema de la actualización perdida. El nivel de aislamiento READ UNCOMMITTED es el nivel más bajo especificado en el estándar SQL. En este modo, la transacción 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 inserción fantasma. El SGBD sigue evitando el problema de la actualización perdida. Generalmente, el nivel READ UNCOMMITTED sólo 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 sólo contenga información que, de hecho, se ha comprometido con la base de datos, el programa no debería utilizar este modo. El estándar SQL2 especifica la instrucción SET TRANSACTION, que puede verse en la Figura 12.16, que se emplea para establecer el nivel de aislamiento de cada instrucción. La instrucción SET TRANSACTION también permite especificar si la transacción es READ ONLY (es decir, si sólo realizará consultas a la base de datos) OREAD WRITE (puede consultar o actualizar la base de datos). El SGBD puede emplear esta información, junto con el nivel de aislamiento, para optimizar
344
~Capítulo 12:
SOL. Manual de referencia
~
t-SET TRANSACTION
ISQLATIQN
LEVELlSERIALIZAB~E
REPEATABLE READ READ COMMITTED
READ WRITE READ ONLY
j.
READ UNCOMMITTED
Figura 12.16.
Diagrama sintáctico de la instrucción SET TRANSACTION.
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 máxima 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. Obsérvese que la instrucción SET TRANSACTION especificada en el estándar SQL2 es una instrucción de SQL ejecutable. Resulta posible y, en ocasiones, muy deseable hacer que una instrucción 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 transacción. El estándar exige, de hecho, que la instrucción 5ET TRAN5ACTION sea la primera ins· trucción de cada transacción. Esto significa que debe ejecutarse como la primera instrucción tras COMMIT o ROLLBACK, o como la primera instrucción de un programa, antes de ninguna otra instrucción que afecte al contenido o a la estructura de la base de datos. Como ya se indicó antes en el apartado «Técnicas avanzadas de bloqueo», muchos de los productos comerciales de SGBD implementaron sus esquemas de bloqueo y de mejora del rendimiento mucho antes de' la publicación del estándar SQL2, y esas estrategias de bloqueo afectan al núcleo de la arquitectura y de la lógica internas de la base de datos. No resulta sorprendente que la adopción en este terreno de estándar SQL2 haya resultado relativamente lenta en comparación con algunas otras áreas en que la implementación era mucho más sencilla. Por ejemplo, las bases de datos de IBM para grandes sistemas (DB2 y SQUDS) ofrecían históricamente la opción entre dos niveles de aislamiento -REPEATAELE READ Y READ COMMITTED (denominado CURSOR STAEILITY en la termino~ logía de 1BM). En las implementaciones de IBM se realiza la opción 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 elección del modo afecta mucho a la menera en que se comporta la aplicación y a la manera en que puede utilizar los datos recuperados.
Procesamiento de transacciones
345
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 instrucción SET LOCKMODE los programas de aplicación 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:
• 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 inslrucción 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. Obsérvese, no obstante, que los modos de bloqueo de lngres los define una instrucción ejecutable de SQL. A diferencia de los modos de lBM, que deben escogerse en el momento de la compilación, los modos de logres pueden escogerse c.uando se ejecuta el programa e, incluso, cambiarse de una consulta a otra. Parámetros de bloqueo
*
Un SGBD maduro, como DB2, SQUDS, Orade, Inforrnix, Sybase o SQL Server, emplea técnicas de bloqueo mucho más complejas que las aquí descritas. El administrador de la base de datos puede mejorar el rendimiento de estos sistemas definiendo manualmente los parámetros de bloqueo. Entre los parámetros que pueden ajustarse normalmente se encuentran: • Tamaño de los bloqueos. Algunos productos de SGBD ofrecen la posibilidad de elegir el nivel de tablas, el nivel de páginas, el nivel de filas y otros tamaños de bloqueo. En función de cada aplicación concreta puede resultar adecuado un tamaño de bloqueo diferente. • Número de bloqueos. El SGBD suele permitir que cada transacción tenga un número finito de bloqueos. El administrador de la base de datos suele poder definir este limite, elevándolo para permitir transacciones más complejas o disminuyéndolo 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 automática, sustituyendo muchos bloqueos de pequeño tamaño por un solo bloqueo de mayor tamaño (por ejemplo, sustituyendo muchos bloqueos en el nivel de página por un bloqueo en el nivel de tabla). Puede que el administrador de la base de datos tenga algún control sobre este proceso de escalada. • Caducidad de los bloqueos. Aunque una transacción no esté interbloqueada con otra, puede que espere mucho tiempo a que la otra transacción libere sus bloqueos. Algunas marcas de SGBD implementan una característica de
346
SOL. Manual de referencia
caducidad, en la que la instrucción de SQL falla con un código 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.
Capitulo 12: Procesamiento de transacciones
Transacciones
Las técnicas de bloqueo descritas en los apartados anteriores son las más 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 implícita que es probable que las transacciones simultáneas interfieran entre sr. En los últimos años 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 implícita que las transacciones simultáneas no interferirán entre sí. Con una arquitectura de bloqueo (pesimista) el SOBD mantiene internamente una y sólo 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 (más exactamente, entre las transacciones concurrentes). Sin embargo, con una arquitectura de versiones (optimista), el SOBO creará dos o más copias de los datos de cada fila de fa base de datos cuando algún usuario intente actualizarlas. Una copia de la fila contendrá los datos viejos, previos a la actualización; las otras copias de la fila contendrán los nuevos datos de la fila, tras la actualización. El SOBO realiza un seguimiento interno de las transacciones que deben ver cada versión de la fila, en función de sus niveles de aislamiento.
Transacciones
Valores de la base de datos Una copia
t ACI
Versiones *
347
Leer CANTIDAD
o
139
14100411391
;- Una copia 1 ACI 1 4100411391 ActualizarCANTIDA0=39
)
®
j
!--
I
í
~-
I
Antes
I ACI 14100411391 ¡ ;-
!
Después
1ACI 1410041 39 I Leer CANTIDAD
(c
;-
Antes
ACII 410041 139
¡
I
139 ®erCANTIDAD
Antes ;ACI 1 41004\ 1391
139
,
+
Después
1ACI 1410041
3.
I
COMMIT
, i
;-
Leer CANTIDAD I
(E
ACI
Una copia
410041 39 1
39 COMMIT COMMIT
Funcionamiento de las versiones * La Figura 12.17 muestra en funcionamiento una sencilla arquitectura de versiones. La transacción A inicia la acción, leyendo una fila de la tabla PRODUCTOS, y halla 139 unidades de cables ACI-41004 serie 4 disponibles. La lransacción B llega a continuación 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 transacción B vuelve a leer el contenido de la fila, ese contenido procederá de esta segunda copia, ya que refleja el stock actualizado por la transacción B (39 unidades). A continuación, la transacción e llega e intenta leer la misma fila. Como todavía no se ha comprometido la actualización de la transacción B, el SOBO ofrece a la transacción C los datos de la copia antigua de la fila, que muestran 139 unidades disponibles. Lo mismo ocurre pocos segundos más tarde con la transacción D; también verá disponibles 139 unidades. Ahora la transacción B lleva a cabo una operación CQMMIT, ha-
COMMIT
I
••• Figura 12.17.
• Las transacciones concurrentes en una arquitectura de versiones.
ciendo permanente la actualización de la fila. Poco después, la transac~ión E intenta leer la fila. Con la actualización de la transacción B ya comprometida, el SOBO ofrecerá a la transacción 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 operación 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
.--6apítulo 72: Procesamiento de transacciones
SOL. Manual de referencia
A-C-D-B-E produciría el mismo resultado que se muestra en la Figura. (De hecho, la serie A-D-C-B-E también produciría este resultado.) Además, la implementación de las versiones proporciona el funcionamiento correcto sin hacer que espere ninguna de las transacciones. No se puede decir lo mismo de la implementación típica de los bloqueos. como puede verse en la Figura 12.18. En la Figura 12.18 la transacción A vuelve a iniciar la acción, hallando 139 unidades de cables ACI-41004 disponibles. Internamente, el SGBD mantiene un
Transacciones
T,
Valores de /a base de dar. '"
1ACl I 4I0041
I AeI I 41004 ¡ 139 I ~
B/oqueo compartido J
@ LeerCANTlDAD
AeI
I 41004 I
Actuafi.
39
, ,
I bloqueo
'T' I
1ACl 1 ~
39
39
I
39
I
COMMIT
, T
LeerCANTIDAD 1
®
Bloqueo exclusivo
Esperar
.¡,
3.
=39
bloqueo Esperar
. @eerCANTIDAI
I
T
LeerCANTIDAD
139
139
's
(E
3.
1ACl I 410041
COMHIT COMHIT COMMIT
I
T T T
T
Figura 12.18.
T
Transacciones concurrentes en una arquitectura.de bloqueos.
349
bloqueo compartido sobre la fila. A continuación, la transacción B intenta actu·alizarla, reduciendo el stock a 39 unidades. Si la transacción A está operando en un nivel de aislamiento estricto (como REPEATABLE READ), la transacción B se verá retenida en este punto, ya que no puede adquirir el bloqueo exclusivo nece~ sario. Si la transacción A está operando en un nivel de aislamiento menos estricto, el SGBD puede pettniLir que la transacción B siga adelante, concediéndole un bloqueo exclusivo sobre la fila y actualizando realmente los datos. La fila interna de la base de datos (recuérdese que sólo hay una copia de cada de cada fila en esta arquitectur.a de bloqueo) muestra ahora 39 unidades disponibles. Cuando llega la transacción C, debe esperar a que la transacción B libere su bloqueo, a menos que la transacción e esté operando en un nivel de aislamiento muy bajo (READ UNCOMMITTED). Puede decirse lo mismo de la transacción D. Sólo después de que se hayan comprometido los cambios de, la transacción 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 más 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 más transacciones esperen que otras se completen y liberen sus bloqueos. La segunda, y más sutil, diferencia, es que el orden efectivo de la ejecución 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. Obsérvese que ninguna de ellas es correcta; el principio de la secuenciabilidad sólo afirma que el resultado producido por el SGBD debe coincidir con alguna secuencia de transacciones en serie. El ejemplo de la Figura 12.17 sólo incluye una transacción de actualización, por lo que sólo son necesarias dos copias de la fila actualizada (previa y posterior a la actualización). La arquitectura de versiones se amplía con facilidad para acoger más actualizaciones concurrentes. Por cada intento de actualizar la fila, el SGBD puede crear otra fila nueva, que refleje la actualización. Con este enfoque de varias versiones la tarea de realización del-seguimiento de las_transacciones que deben ver cada versión de la fila; evidentemente, se vuelve más compleja. En la práctica, la decisión sobre la versión de la fila que debe ser visible para cada transacción concurrente no sólo depende de la secuencia de las operaciones de la base de datos, sino también de los niveles de aislamiento solicitados para cada transacción. 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, seguirán 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
SOL. Manual de referencia
Ventajas e inconvenientes de las versiones *
.1
I
La ventaja de la arquitectura de versiones es que, en las circunstancias adecuadas, puede incrementar de manera significativa el número de transacciones simultáneas que pueden ejecutarse en paralelo. La ejecución simultánea se está haciendo cada vez más importante en las instalaciones de SGBD de gran tamaño, especialmente en las que soportan sitios web que pueden tener millares o decenas de millares de usuarios concurrentes. Las versiones también se están volviendo más útiles a medida que el número de procesadores en los sistemas informáticos servidores típicos de SGBD aumenta. Los servidores que contienen dieciséis O más procesadores se están haciendo cada vez más frecuentes, y los servidores de SGBD de gran tamaño pueden admitir sesenta y cuatro o más procesadores en una configuración de multiprocesamiento simétrico (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 añadido de memoria del almacenamiento de dos o más copias de las filas que se están actualizando. En la práctica, una sobrecarga más seria es la gestión 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 implícita, la arquitectura de versiones se basa en la asunción implícita de que la mayor parte de las transacciones simultáneas tiende a no interferir entre sí. Si esta asunción resulta exacta (por ejemplo, si las transacciones que se ejecutan de manera simultánea actualizan y tienen acceso sobre todo a filas diferentes, o si la carga de trabajo de la transacción está dominada por operaciones READ en vez de por operaciones UPDATE). entonces la sobrecarga añadida 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 asunción 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 técnica de las versiones tenderá a hacerse muy elevada, sobrepasando las ventajas de la simultaneidad.
Resumen Este capítulo describe el mecanismo de las transacciones ofrecido por el lenguaje SQL: • Una transacción es una unidad lógica 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 instrucción COMMIT señala la finalización con éxito de una transacción, haciendo permanentes todas las modificaciones de la base de datos.
Capítulo 12: Procesamiento de transacciones
351
• La instrucción ROLLBACK pide al SGBD que aborte una transacción, haciendo retroceder todas las modificaciones de la base de datos. • Las transacciones son la clave de la recuperación de las bases de datos tras los falios del sistema; sólo las transacciones comprometidas en el momento del fallo permanecen en la base de datos recuperada. • Las transacciones son la clave del acceso simultáneo en las bases de datos multiusuario. Se garantiza al usuario o programa que su transacción no se verá interferida por otras transacciones concurrentes. • Ocasionalmente, puede que un conflicto con otra transacción que se ejecuta de manera simultánea haga que el SGBD obligue a retroceder una transacción sin que ésta tenga ninguna culpa. Los programas de aplicación que utilizan SQL deben estar preparados para tratar esta situación si se llega a producir. • Las sutilezas de la gestión de las transacciones y su consecuencia en el rendimiento de los SGBD son una de las áreas más complejas del empleo y la operación de bases de datos de producción de gran tamaño. También es un área en la que las principales marcas de SGBD divergen en sus posibilidades y opciones de ajuste. • Muchas marcas de SGBD utilizan técnicas de bloqueo para manejar las tran· sacciones simultáneas. Para estos productos los ajustes de los parámetros de bloqueo y las instrucciones de bloqueo explícito permiten ajustar el rendimiento del procesamiento de transacciones. • Una técnica alternativa de versiones para el manejo de las transacciones simultáneas 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.
~ ~ Parte N
ESTRUCTURA DE LA BASE DE DATOS 1"
~
I ..
P
,E
í 'i
lt
Un papel importante de SQL es definir la estructura y organización de una base de datos. Los Capítulos 13 al 16 describen ¡as características de SQL que dan soporte a es.te papel. El Capítulo 13 explica cómo crear una base de datos y sus tablas. El Capítulo 14 analiza las vistas, una característica importante de SQL que permite a los usuarios ver organizaciones alternativas de los datos de la base de datos. Las características de seguridad de SQL que protegen los datos almacenados se describen en el Capítulo 15. Finalmente, el Capítulo 16 estudia el catálogo del sistema, una colección de tablas del sistema que describen la estructura de una base de datos.
CAPíTULO
13
Creación de bases de datos Muchos usuarios de SQL no tienen que preocuparse de crear llna base de datos; utilizan SQL interactivo o para programación para tener acceso a una base de da· tos de información corporativa o a alguna otra base de datos que haya sido creada por olra persona. En las bases de datos corporativas típicas, por ejemplo, el administrador de la base de datos puede conceder permiso para recuperar y, quizás, 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 más cómodo con SQL desee comenzar a crear tablas propias para almacenar datos personales como los resultados de las pruebas de ingeniería 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 compartirán con otros usuarios. Si se utiliza una base de datos en una computadora personal, es seguro que se desearán crear tablas y bases de datos propias para dar soporte a las aplicaciones personales. Este capítulo describe las características del lenguaje SQL que permiten crear bases de datos y tablas y definir su estructura.
El lenguaje de definición de datos Las instrucciones SELECT, INSERT, DELETE, UPDATE, COMMIT y ROLLBACK descritas en las Partes TI y ID de este libro están relacionadas con la manipulación de los datos de las bases de datos. Estas instrucciones se denominan colectivamente Lenguaje de manipulación 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 definición de datos (LDD) de SQL. Con las instrucciones LDD se puede: 355
~
356
SOL. Manual de referencia
• Definir y crear nuevas tablas. • Eliminar tablas que ya no sean necesarias. • Modificar la definición 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 más rápido el acceso a las tablas. • Controlar. el almacenamiento físico. de los ~alos por el SGBD. En su mayor parte, las instrucciones LDD aíslan al usuado de los detalles de bajo nivel del modo ~n Rue se almacenan físicamente 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 físico, y. necesariamente, las instrucciones y cláusulas LDD que controlan el almacenamiento físico varían de un SGBD a Olro. El núcleo del lenguaje de definición de datos se basa en tres verbos de SQL:
Capítulo 13: Creación de bases de datos
357
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 estándar en línea con la implementación actual de productos populares de SQL al exigir que las instrucciones LDD se ejecuten de manera interactiva y mediante un programa. El estándar SQL2 sólo especifica las partes LDD que son relativamente independientes de las estructuras de almacenamiento físico, de dependencias del sistema operativo y de otras posibilidades propias de cada marca de SOBO. En la práctica, todas las marcas de SGBD incluyen ampliaciones significativas LDD estándar para tratar estos problemas y otras posibilidades mejoradas de las bases de datos. Las diferencias entre el estándar ANSUISO y la implementación LDD de los productos populares de SQL se describen para cada instrucción de SQL durante este capítulo.
• CREATE. Define y • DROP. Elimina un
Creación de bases de datos
• ALTER.
En la instalación de un SGBD en un gran sistema informático (maifljrame) o en un nivel empresarial, el administrador corporativo de la base de datos es el único responsable de la creación de bases de datos nuevas. En las instalaciones de SOBD para grupos de trabajo más reducidos puede que se permita a cada usuario crear sus propias bases de datos personales, pero resulta mucho más 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 más 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 estándar 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 había adoptado un enfoque ligeramente diferente. Estas diferencias persisten en los productos habituales de SGBD de hoy en día. Las técnicas utilizadas por estos productos de SQL ilustran las diferencias:
crea un objeto de la base de daros. objeto ya existente de la base de datos. Modi.fi~a la definición de un objeto de la base de dalas.
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 dinámica. El SGBD puede crear, eliminar o modificar, por ejemplo, la definición de las tablas de la base de datos mientras ofrece de manera simultánea 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 había 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 fácilmente a lo largo del tiempo. El empleo para producción de las bases de datos puede continuar mientras se añaden 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 separación sólo 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 programación 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 estándar SQLl no lo exigra, De hecho, el estándar SQLl implica una estricta separación entre LMD y LDD, lo que permite a los fabricantes conseguir el cumplimiento con la parte de LMD del estándar mediante una capa de SQL ubicada por encima de una base de datos subyacente que no es de SQL. El estándar SQL2 sigue diferenciando entre distintos
• DB2 de IBM tiene una estructura de base de datos predeterminada sencilla. Las bases de datos de DB2 se asocian con una copia en ejecución del software de servidor de DB2 y los usuarios tienen acceso a ellas conectándose al servidor de DB2. Por tanto, las «bases de datos» se definen de hecho mediante la instalación del software de DB2 en un sistema informático concreto. • Oracle crea, de manera predeterminada. una base de dl;ltos como parte del proceso de instalación 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 según un archivo de configuración de Oracle y se asocia con esa copia concreta del software de servidor de Oracle. Las versiones de Orade más recientes se han ampliado con una instrucción CREATE DATABA5E para la definición de los nombres de las bases de datos.
358
Capítulo 13: Creación de bases de datos
SOL. Manual de referencia
• SQL Server de Microsoft y Sybase incluye una instrucción
CREATE DATA-
359
Creación de tablas (CREATE TABLE)
BASE como parte de su lenguaje de definición de datos. La instrucción anexa DROP DATABASE destruye anteriormenre las bases de datos ya creadas. Estas
instrucciones pueden utilizarse con SQL interactivo o de programación. Los nombres de estas bases de datos se siguen en una base de datos maestra especial que está asociada con una sola instalación de SQL Server. Los nombres de las bases de datos deben ser únicos en cada instalación de SQL Server. Las opciones de la instrucción CREATE DATABAS E especifican el dispositivo de E/S en el que hay que ubicar la base de datos. • Informix Universal Server alberga también las instrucciones de SQL CREATE
y DROP DATABASE. Una opción de la instrucción 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 opción controla el tipo de registro histórico 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 estándar SQL2 evita de manera específica la concreción del término base de datos por 10 sobrecargado que se halla de significados contradictorios procedentes de los productos SGBD. SQL2 utiliza el término catálogo para describir un conjunto con nombre de tablas que la mayor parte de las marcas populares de SOBD denomina base de datos. (Más adelante se ofrece información adicional sobre la estructura de la base de datos especificada por el estándar SQL2, en el apartado «Estructura de la base de datos y el estándar ANSI/ISO»). El estándar no especifica la forma de crear o destruir catálogos, y dice específicamente que depende de la implementación. También indica el número de catálogos que hay y si cada instrucción de SQL que puede tener acceso a los datos desde diferentes catálogos viene definida por la implementación. En la práctica, 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.
Definiciones de tablas La estructura más importante de las bases de datos relacionales es la tabla. En las bases de datos multiusuario de producción, las principales tablas suele crearlas una sola vez el administrador de la base de datos, y se utilizan día tras día. A medida que se utiliza la base de datos, se suele considerar adecuado definir tablas propias para almacenar datos personales o datos extraídos de otras tablas. Estas tablas pueden ser temporales, y sólo durar una sesión de SQL interactivo, o más permanentes y durar semanas o meses. En las bases de datos de computadoras personales, la estructura de tablas resulta todavía más 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.
La instrucción 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 cláusulas de la instrucción especifican los elementos de la definición de la tabla. El diagrama sintáctico de la instrucción parece complicado porque hay muchas partes de la definición que especificar y muchas opciones para cada elemento. Además, algunas de las opciones están disponibles en algunas marcas de SGBD o en el estándar SQL2, pero no en otras marcas. En la práctica, la creación de tablas nuevas resulta relativamente sencilla. Cuando se ejecuta una instrucción CREATE TABLE, uno se transforma en el propietario de la tabla recién creada, a la que se le otorga el nombre especificado en la instrucción. 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 recién creada está vacía, pero el SGBD la prepara para que acepte los datos añadidos con la instrucción INSERT. Definición de columnas
Las columnas de la tabla recién creada se definen en el cuerpo de la instrucción Las definiciones de las columnas aparecen en una lista separada por comas encerrada entre paréntesis. 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 definición de columna especifica lo siguiente: CREATE TABLE.
• 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 Capítulo 5. Algunos tipos de datos, como VARCHAR y DECIMAL, exigen información adicional, como la longitud o el número de posiciones decimales de los datos. Esta información adicional se encierra entre paréntesis a continuación 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 instrucción INSERT para la tabla no especifica ningún valor. El estándar SQL2 permite varias partes adicionales a la definición 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
~
SOL. Manual de referencia
~ CREATE TABLE
nombre-de-tabla
Capítulo 13: Creación de bases de datos
361
siones de una sola columna de capacidades proporcionadas por otras cláusulas de la instrucción CREATE TABLE, y se describen corno parte de esa instrucción en los apartados siguientes. A continuació!1 se ofrecen algunas inslrucciones CREATE TABLE sencillas para las tablas de la base de datos de ejemplo:
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)
La instrucción 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. Además, el estándar SQL2 permile especificar un dominio en lugar de un tipo de datos dentro de la definición de una columna. (Los dominios se describieron en el Capítulo 11.) Un dominio es un conjunto concreto de valores de datos válidos que se define dentro de"la base de datos y al que se le asigna un nombre. La definición 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 definición de dominio apareciera en una base de datos bajo el estándar SQL2:
----r
PARTIAL ;r
L
PEDIDOS
INITIALLY DEFERRED
restricción-de-cl3ve-primaria:
- - - PRlMARY KEY
OFICINAS INTEGER NOT NULL, VARCHAR(15) NOT NULL, VARCHAR(10} NOT NULL, INTEGER, MONEY, MONEY NOT NULL)
CREATE DOMAIN ID_OFICINA_VALIDA INTEGER CHECK (VALUE BETWEEN 11 ANO 99)
entonces la definición de la tabla OFICINAS podría modificarse para que fuera: restricción-de-comprobaci6n: - - CHECK
(condición-de-bUsqueda)
...
Figura 13.1. "Diagrama sintáctico básico de CREATE TABLE.
Definir la tabla OFICINAS y sus columnas. CREATE TABLE OFICINAS (OFF ICE ID_OFICINA_VALIDA NOT NULL, CIUDAD VARCHAR(15) NOT NULL,
362
Capítulo 13: Creación de bases de datos
SOL. Manual de referencia REGlON VARCHAR{lO) NOT NULL, JEF INTEGER, OBJETIVO MONEY.
VENTAS MONEY NOT NULL)
y el SGBD comprobaría de manera automática cualquier fila ,recién insertada 'p~a asegurarse de que su número de oficina se hall~ en el ran~o deslgna~o ..Los dommlOs resultan especialmente efectivos cuando se aplican las mIsmas restriCCIOneS de valores válidos a muchas columnas diferentes de la base de datos. En la base de datos de ejemplo, los números 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
La definición de cada columna dentro de la tabla indica al SGBD si se permite que los datos de la columna estén 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 estándar 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 definición debe incluir la cláusula 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 explícita como NULL, O el modo de autorización de valores NULL predetermmado se define para que permita de manera predeterminada valores NULL. El estándar 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 definición de la columna. Por ejemplo, a continuación se ofrece una instrucción 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 definición de tabla sólo hace falta especificar el número 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 número 106); el valor predeterminado de las ventas es cero, y el valor predeterminado del objetivo es NULL. Obsérvese que el valor predeterminado del objetivo sería NULL aunque no existiera la especificación DEFAULT NULL.
363
Definición de clave primaria y de clave externa
Además de definir las columnas de cada tabla, la instrucción CREATE TABLE idenli. fica la clave primaria y las relaciones de la tabla con otras tablas de la base de datos. Las cláusulas PRlMARY KEY Y FOREIGN KEY tratan estas funciones. SQL de IBM admite estas cláusulas desde hace algún tiempo y se han añadido a la especificación ANSI/ISO. La mayor parte de los principales productos de SQL las admiten. La cláusula PRIMARY KEY especifica las columnas que forman la clave prima· ria de la tabla. Recuérdese del Capítulo 4 que esta columna (o combinación de columnas) sirve de identificado·r único de cada fila de la tabla. El SGBD exige de manera automática que el valor de la clave primaria sea único en cada fila de la tabla. Además, la definición. de las columnas de cada columna de la clave primaria debe especificar que la columna es NOT NULL. La cláusula FOREIGN KEY especifica una clave externa de la tabla y la relación que crea con otra tabla de la base de datos (la tabla padre). La cláusula 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 relación. El nombre no se utiliza en las instrucciones de manipulación de datos de SQL, pero puede aparecer en mensajes de error y es necesario si se desea poder eliminar la clave externa más adelante. • El modo en que el SGBD debe tratar los valores NULL en una o más columnas de la clave externa al compararla con las filas de la tabla padre. • Una regla opcional de eliminación de la relación (CASCADE, SET NULL, SET DEFAULT o NO ACTION, como se describe en el Capítulo 11), que determina la acción que hay que emprender cuando se elimina una fila padre. • Una regla opcional de actualizaci6n de la relación como se describe en el Capítulo 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 comprobación, que restringe los datos de la tabla de modo que sus filas cumplan una condici6n de búsqueda especificada. A continuaci6n se ofrece un instrucci6n CREATE TABLE expandida para la tabla PEDIDOS. que incluye una definición de su clave primaria y de las tres claves externas que contiene:
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
'-
SOL. Manual de referencia
Capítulo 13:· Creación de bases de datos
365
CLIENTE INTEGER NOT NULL. REP INTEGER, FAB CHAR(31 NOT NULL. PRODUCTO CHAR(5) NOT NULL.
CANTIDAD IMPORTE PRlMARY KEY CONSTRAINT FOREIGN KEY REFERENCES ON DELETE CONSTRAINT FOREIGN KEY REFERENCES ON DELETE CQNSTRAINT FOREIGN KEY
Tabla CLIENTES
INTEGER NOT NULL, MDNEY NOT NULL. (NUM_PEDIDO). FORMULADO (CLIENTE) CLIENTES CASCADE, TRAMITADO (REP) REPRESENTANTES SET NULL, DE (FAB, PRODUCTO)
NOM_CLIENTE FORMULADO
1 21 ,03
I EMPRESA
I
ACME
U
Tabla REPRESENTANTES NUM EMPL TRAMITADO
NOMBRE Bruno Arteaga
lOS
REFERENCES PRODUCTOS ON DELETE RESTRICT)
Tabla PRODUCTOS
La Figura 13.2 muestra las tres relaciones creadas por esta instrucción y los nombres que les asigna. En general, conviene asignar un nombre de relación, ya que ayuda a clarificar la relación creada por la clave externa. Por ejemplo, cada pedido lo formuló el cliente cuyo número aparece en la columna CLIENTE de la tabla PEDIDOS. La relación creada por esta columna ha recibido el nombre de FORMULADO. Cuando el SGBD procesa la instrucción CREATE TABLE, contrasta cada defi· nición de clave externa con la definición 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 número 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 comprobación tenga éxito. Obsérvese que la cláusula FOREIGN KEY también especifica las reglas de elimi· nación y actualización que hay que hacer cumplir para la relación entre tabla padre y tabla hija que crea. Las reglas de eliminación y de actualización, y las acciones que pueden desencadenarlas, se describen en el Capítulo 11. El SGBD hace que se cumplan las reglas predeterminadas (NO ACTION) si no se especifica ninguna regla de manera explícita. Si se desea crear dos o más tablas en un ciclo referencial (como las tablas OFICINAS y REPRESENTANTES de la base de datos de ejemplo), no se puede incluir la definición de clave externa en la primera instrucción CREATE TABLE, por. que la tabla referenciada no existe aún. El SGBD rechazará la instrucción CREATE TABLE con un error diciendo que la definición de tabla se refiere a una tabla no definida. En su lugar, se debe crear la primera tabla sin la definición de clave externa y añadir la clave externa más tarde usando la instrucción ALTER TABLE. (El estándar SQL2 y varios de los principales productos SGBD ofrecen una solución diferente a este problema con la instrucción CREATE SCHEMA, que crea un conjunto completo de tablas de una vez, Esta instrucción y los otros objetos de la base de datos que se incluyen dentro de un esquema SQL2 se describen más tarde en la sección «Esquemas SQL2».)
ID_FAB
ID_PRODUCTO
ACI
41004
\
HUM PEDIDO 112963
J
--
~
I~
FECHA...PEDIDO CLIENTE RE'
FAB
PRODUCTO
17-DIC-89
'Cl
41004
-Figura 13.2.
Serie 4, cable
v
I
lbla PEDIDOS
DESCRIPCION
2103
lOS
CANTIDAD 28
IMPORTE 3.276.00 €
-
Nombres de las relaciones de la instrucción CREATE TABLE.
Restricciones de unicidad El estándar SQL2 especifica que las restricciones de unicidad también se definen en la instrucción CREATE TABLE mediante la cláusula UNIQUE, que puede verse en la Figura 13.1. A continuación se ofrece una instrucción CREATE TABLE para la tabla OFICINAS, modificada para exigir valores únicos de CIUDAD: Definir la tabla OFICINAS con una restricción de unicidad. CREATE TABLE (OFICINA CIUDAD REGION JEF I
I1,
_1
OFICINAS INTEGER NOT NULL, VARCHAR(15) NOT NULL, VARCHAR(lO) NOT NULL, INTEGER,
366
Capítulo 1;J: Creación de bases de datos
SOL Manual de referencia OBJETIVO VENTAS PRIMARY KEY CONSTRAINT FOREIGN KEY REFERENCES ON DELETE CHECK
OBJETIVO MONEY,
VENTAS MONEY NOT NULL, PRIMARY KEY
(OFICINA),
CONSTRAINT FOREIGN KEY REFERENCES ON DELETE UNIQUE
JEFEVENTAS (JEF) REPRESENTANTES SET NULL. (CIUDAD))
CREATE TABLE (OFICINA CIUDAD REGION JEF INTEGER OBJETIVO VENTAS
OFICINAS con
una restricción de unicidad (sintaxis ANSI/ISOJ.
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)
CONSTRAINT FOREIGN KEY REFERENCES ON DELETE CONSTRAINT
Varias de las principales marcas de SGBD, incluidas SQL Server, Informix, Sybase y DB2, admiten esta forma abreviada. Restricciones de comprobación
CREATE TABLE (OFICINA CIUDAD REGlaN JEF
OFICINAS
TRABAJAEN (OFICINA_REP) OFICINAS SET NULL TOPE_CUOTA CHECK
((FECHA_CONTRATO < "Ol-JAN-SS") OR (CUOTA <= 300000)))
Esta posibilidad de las restricciones de comprobación la admiten muchas de las principales marcas de SGBD.
Otra característica de integridad de datos de SQL2, la restricción de comprobación (que se describe en el Capítulo 11), también se especifica en la instrucción CREATE TABLE. Las restricciones de comprobación especifican una condición de comprobación (idéntica en su forma a las condiciones de búsqueda de las consultas de SQL) que se efectúa cada vez que se realiza un intento de modificación del contenido de la tabla (con una instrucción INSERT, UPDATE o DELETE). Si la condición de comprobación sigue siendo TRUE tras la modificación, se autoriza; en caso contrario, el SGBD frustra el intento de modificar los datos y devuelve un código de error. A continuación puede verse una instrucción CREATE TABLE para la tabla OFICINAS, con una condición de comprobación sencilla para asegurarse de que el OBJETIVO para la oficina sea mayor de 0,00 €. Definir la tabla
MONEY, MaNEY NOT NULL, (OFICINA), JEFEVENTAS (JEF) REPRESENTANTES SET NULL, (OBJETIVO >= 0.00))
Se puede especificar de manera opcional un nombre para la restricción de comprobación, que será utilizada por el SGBD cuando comunique .un error si se viola la restricción. A continuación puede verse una restricción de comprobación ligeramente más compleja para que la tabla REPRESENTANTES haga que se cumpla la regla «A los representantes cuya fecha de contratación sea posterior al 1 de enero de 1988 no se les asignarán cuotas superiores a 300.000 En. La instrucción CREATE TABLE denomina a esta restricción TOPE_CUOTA:
Si la clave primaria, la clave externa, la restricción de unicidad o la restricción de comprobación afecta a una sola columna, el estándar ANSI/lSO permite una forma abreviada de la definición. Sencillameme, se añade la clave primaria, la clave externa, la restricción de unicidad o la restricción de comprobación al final de la definición de la columna, como se puede ver en este ejemplo:
Definir la tabla
367
Definición del almacenamiento físico
*
La instrucción CREATE TABLE suele incluir una o varias cláusulas opcionales que
especifican las características del almacenamiento físico de la tabla. Generalmente, estas cláusulas sólo las utiliza el administrador de la base de datos para optimizar el rendimiento de las bases de datos de producción. Por su propia naturaleza, estas cláusulas son muy específicas de cada SGBD en concreto. Aunque resultan de poco interés práctico para la mayor parte de los usuarios de SQL, las diferentes estructuras de almacenamiento físico ofrecidas por los diferentes SGBD ilustran las diferentes aplicaciones para las que están diseñados y sus niveles de sofisticación. La mayor parte de las bases de datos de las computadoras personales ofrecen mecanismos de almacenamiento físico 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 también necesiten que toda la tabla o toda la base de datos se almacenen en un solo volumen de disco físico. Las bases
con una restricción de unicidad.
OFICINAS INTEGER NOT NULL, VARCHAR(15) NaT NULL, VARCHAR(lO) NOT NULL, INTEGER,
J
368
-----
SOL. Manual de referencia
Capítulo 13: Creación de bases de datos
369
de datos multiusuario suelen ofrecer esquemas de almacenamiento físico más 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 físicos en los que pueden almacenarse los datos de la base de dalOs. Las ubicaciones pueden repartirse entre varios volúmenes 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 instrucción de logres CREATE TABLE:
ello es que estas instrucciones incluyen especificaciones dependientes del sistema operativo de nombres de archivos y de directorios, que varían de un sistema operativo admitido por DB2 a otro. Otras cláusulas especifican el grupo de búfer que hay que usar, la sobrecarga y la tasa de transferencia del medio de almacenamiento y otras características íntimamente relacionadas con el medio de almacenamiento físico. DB2 utiliza esta información en sus algoritmos de optimización del rendimiento.
CREATE TABLE OFICINAS (definición-de-tabla) WITH LOCATIQN ~ {AREA1, AREA2, AREA3)
Eliminación de una tabla (DROP TABLE)
Al especificar varias ubicaciones, se puede dividir el contenido de cada tabla entre varios volúmenes 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 lógicos de La base de datos con nombre que se utilizan para almacenar los datos. La correspondencia entre los dispositivos lógicos de Sybase y los discos físicos reales del sistema informático la maneja un programa de utilidad de Sybase, y no el lenguaje SQL. La instrucción de Sybase CREATE DATABASE puede especificar que se almacene la base de datos en uno o varios dispositivos de la base de datos:
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 instrucción DROP TABLE, que puede verse en la Figura 13.3. El nombre de tabla de la instrucción 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 también de tablas poseídas por otros usuarios especificando un nombre de tabla calificado. A continuación se ofrecen unos ejemplos de la instrucción DROP TABLE:
CREATE DATABASE DATOSOP ON ARCHIVOBDl, ARCHIVOBD2, ARCHIVOBD3
INFO_CUENTA, )'
La tabla CLIENTES ha sido sustituida por dos tablas nuevas, INFO_CLIENTE e
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 lógicos, utilizando uno de los procedimientos almacenados proporcionados por el sistema de Sybase. Finalmente, la instrucción de Sybase CREATE TABLE puede especificar el segmento en que hay que almacenar los datos de cada tabla:
DROP TABLE CLIENTES
CREATE TABLE OFICINAS ON SEGMENT SEGIA
Cuando la instrucción DROP TABLE elimina una tabla de la base de datos, se pierden su definición y todo su contenido. No hay manera de recuperar los datos, y habría que utilizar una nueva instrucción CREATE TABLE para volver a crear la definición de la tabla. Debido a sus graves consecuencias se debe utilizar la instrucción DROP TABLE con cuidado. El estándar SQL2 exige que la instrucción DROP TABLE incluya CASCADE o RESTRICT, que especifican el efecto de la eliminación de una tabla en los demás
(definición-de-tabla)
DB2 ofrece un esquema general parecido para la administración del almacena~ miento físico, basado en los conceptos de espacios de tablas y de grupos nodales. Los espacios de tablas son contenedores de almacenamiento de nivel lógico, mientras que los grupos nodales se definen más específicamente en términos de almacenamiento físico. 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
A diferencia de Sybase, DB2 pone la mayor parte de la administración de estas entidades de almacenamiento en manos del propio lenguaje SQL, mediante las instrucciones CREATE TABLESPACE y CREATE NODEGROUP. Una consecuencia de
Samuel concede permiso para prescindir de su tabla, denominada
CUMPLEAÑOS.
DROP TABLE SAMUEL.CUMPLEA&OS
r Figura 13.3.
DROP TABLE nombre-de-tabfa
r===r" CASCADE RESTRICT
Diagrama sintáctico de la instrucción DROP TABLE.
370
Capítulo 13: ·Creación de bases de datos
SOL. Manual de referencia
objetos de la base de datos (como las vistas, que se describen en el Capítulo ]4) que dependen de esa labia. Si se especifica CASCADE. la instrucción 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 instrucción DROP TABLE sin especificar ninguna opción.
~ ALTER TABLE nombre-de-tabla
definicián-de-co/umna ------~. •
ADD
ALTER nombre-de-
columna
1
DROP
Cambio de la definición de una tabla (ALTER TABLE) AnD
Una vez que una tabla ha estado en uso durante algún tiempo; los usuarios suelen descubrir que desean almacenar información adicional sobre las entidades representadas en la tabla. Así, en la base de datos de ejemplo, puede que se desee:
nombre-decolumna
Cada uno de estos cambios, y algunos otros, pueden llevarse a cabo con la instrucción ALTER TABLE, que puede verse en la Figura 13.4. Al igual que con la instrucción DROP TABLE, normalmente se utilizará la instrucción 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 instrucción ALTER TABLE puede: • • • • • • •
Añadir la definición de una columna a la tabla. Eliminar una columna de la tabla. Modificar el valor predeterminado de una columna. Añadir o eliminar la clave primaria de la tabla. Añadir o eliminar una clave externa de la tabla. Añadir o eliminar una restricción de unicidad de la tabla. Añadir o eliminar una restricción de comprobación de la tabla.
Las cláusulas de la Figura 13.4 se especifican en el estándar SQL. Muchas marcas de SGBD. no admiten algunas de estas cláusulas u ofrecen cláusulas exclusivas de cada SGBD. que alteran otras características de la tabla. El estándar SQL2 res-
• Añadir el nombre y el número de teléfono 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. • Añadir una columna de nivel mínimo de inventario a la tabla PRODUCTOS, de modo que la base de datos pueda alertar de manera automática 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 recién creada. cuya clave principal es el nombre de la región. • Prescindir de la definición de clave externa que vincula la columna CLIENTE de la tabla PEDIDOS con la tabla CLIENTES, sustituyéndola por dos definiciones de clave externa que vinculen la columna CLIENTE a las tablas INFO_CLIENTE e INFO_CUENTA recién creadas.
371
nombre.cfe- [CASCADE columna RESTRICT
Figura 13.4. Diagrama sintáctico de la instrucción
f
ALTER TABLE.
tringe cada instrucción ALTER TABLE a una única modificación de la tabla. Añadir una columna y definir una nueva clave externa, por ejemplo, exige dos instrucciones ALTER TABLE diferentes. Varias marcas de SGBD relajan esta restricción y permiten varias cláusulas de acci6n en cada instrucción ALTER TABLE.
Adición de columnas El empleo más frecuente de la instrucción ALTER TABLE es la adición de una columna a una tabla ya existente. La cláusula de definición de columnas de la instrucción ALTER TABLE es exactamente igual que la de la instrucción CREATE TABLE, y funciona de la misma manera. La nueva columna se añade 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 recién añadidas 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. Obsérvese 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 violaría la restricción de manera inmediata. (Cuando se añade una columna nueva el SGBD, no recorre realmente todas las filas de la tabla ya existentes añadiendo 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 amplía 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 añaden columnas nuevas a las tablas:
372
~
SOL. Manual de referencia
Añadir un nombre y un número de teléfollo de contacto a la tabla CLIENTES. ALTER ADD ALTER ADD
Añadir una columna de nivel de inventario mínimo a la tabla ALTER TABLE PRODUCTOS ADD CANTIDAD_MINlMA INTEGER NOT NULL WITH DEFAULT
PRODUCTOS.
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 instrucción 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 cláu. sula ADD. Desde entonces, las tablas han crecido para incluir definiciones de cia. ves primarias y externas y restricciones, y las cláusulas ADD para estos tipos de objetos especifican el tipo de objeto que se está añadiendo. Por consistencia; con estas otras cláusulas ADD/DROP, el estándar SQL2 incluye la palabra clave opcio. nal COLUMN tras la palabra clave ADD. Con este añadido, el ejemplo anterior se convierte en: PRODUCTS.
ALTER TABLE PRODUCTOS ADD COLUMN CANTIDAD_HINlMA INTEGER NOT NULL WITH DEFAULT O
Eliminación de columnas
La instrucción ALTER TABLE puede utilizarse para eliminar una o varias columnas de una tabla ya existente cuando ya no se necesitan. A continuación se ofrece un ejemplo que elimina la columna FECHA_CONTRATO de la tabla REPRESENTANTES:
Eliminar una columna de la tabla
373
que sea la clave primaria de alguna relación, las columnas de la clave externa que hagan referencia a la columna eliminada dejan de ser válidas. Un problema parecido puede surgir si se elimina una columna a la que se hace referencia en una res~ (ficción de comprobación: la columna que ofrece el valor de los datos para la comprobación de la restricción ha desaparecido. Se crea un problema parecido en las vistas que se definen con base en la columna eliminada. El estándar SQL2 trala estos problemas del mismo modo que trala los pro-
blemas potenciales de integridad de los datos planteados por las instrucciones y UPDATE: con una regla de eliminación (llamada realmente comportamiento de eliminación en el estándar) que opera igual que las reglas de eliminación y de actualizaci6n. Se puede especificar una de estas dos reglas de eliminación: DELETE
o
Aiiadir una colulJlna de nivel de inventario mínimo a la tabla
Capítulo 13: Creación de bases de datos
REPRESENTANTES.
ALTER TABLE REPRESENTANTES DROP FECHA_CONTRATO
El estándar de SQL2 obliga a formular otra instrucción ALTER TABLE diferente si se desean eliminar varias columnas, pero varias de las principales marcas de SGBD permiten eliminar varias columnas con una sola instrucción. Obsérvese que la eliminación de columnas plantea el mismo tipo de problemas de integridad d~ los datos que se describieron en el Capítulo 11 para las operacio. nes de actualización de las bases de datos. Por ejemplo, si se elimina una columna
Si algún otro objeto de la base de datos (clave externa, restricci6n, etc.) depende de la columna que se va a eliminar, la instrucción 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 también como efecto de cascada de la instrucción ALTER TABLE.
• RESTRICT.
•
El efecto CASCADE puede generar modificaciones de la base de datos muy espectaculares; por tanto, se debe utilizar con precaución. Suele ser mejor idea utilizar el modo RESTRICT (eliminar de manera explícita las claves externas y las restricciones dependientes, empleando las instrucciones ALTER o DROP correspondientes) antes de eliminar la columna. Modificación de las claves primarias y externas
El otro empleo común de la instrucción ALTER TABLE es modificar o añadir 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 instrucción 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 explícita anteriormente. A diferencia de las definiciones de las columnas, las definiciones de claves primarias y externas pueden añadirse y eliminarse de las tablas con la instrucci6n ALTER TABLE. Las cláusulas que añaden 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 cláusulas que eliminan las claves primarias o externas son directas, como puede verse en los ejemplos siguientes. Obsérvese que s610 se puede eliminar una clave externa si se asignó originalmente un nombre a la relaci6n que crea. Si la relaci6n carecía 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
SOL. Manual de referencia
Capítulo 13: Creación de bases de datos
A continuación se ofrece un ejemplo que añade una definición de clave externa
375
Asertos
a una tabla ya existente: 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 comprobación, los asertos se especifican como condiciones de búsqueda. Pero, a diferencia de las restricciones de comprobación, la condición de búsqueda 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 definición global de la base de datos, mediante la instrucción CREATE ASSERTION de SQL2. Supóngase que se desea restringir el contenido de la base de datos de modo que los pedidos totales de cualquier cliente no puedan superar el límite de crédito de ese cliente. Se puede implementar esa restricción con la instrucción:
Hacer de la columna REGION de la tabla OFICINA una clave externa de la tabla REGIONES recién creada, cuya clave primaria es el nombre de la región. ALTER TABLE OFICINAS ADD CQNSTRAINT FOREIGN KEY REFERENCES
ENREGION (REGlON) REGIONES
A continuación se ofrece un ejemplo de una instrucción ALTER TABLE que modifica una clave primaria. Obsérvese 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:
Con el aserto denominado LIMITECRED como parte de la definición de la base de datos, se exige que el SGBD compruebe que el aserto sigue siendo cierto cada vez que una instrucción 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 instrucción DROP ASSERTION:
ALTER TABLE REPRESENTANTES
DROP CONSTRAINT TRABAJAEN FOREIGN KEY (OFICINA_REP) REFERENCES OFICINAS ALTER TABLE OFICINAS DROP PRIMARY KEY
(CIUDAD) DROP ASSERTION LIMITECRED
Definición de restricciones
En SQL2 no hay ninguna instrucción ALTER ASSERTION. Para modificar la definición de un aserto hay que descartar la definición antigua y especificar una nueva con otra instrucción CREATE ASSERTION.
Las tablas de las bases de datos definen su estructura básica, y en los primitivos productos comerciales de SQL, las definiciones de las tablas eran la única especificación de la estructura de las bases de datos. Con el advenimiento del soporte de las claves primarias y externas en DB2 y en el estándar SQL2, la definición de la estructura de las bases de datos se amplió para incluir las relaciones entre las tablas de cada base de datos. Más recientemente, mediante el estándar SQL2 y la evolución de los productos comerciales, la definición 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 desempeñan en el mantenimiento de la integridad de la base de datos se describen en el Capítulo lI. Hay cuatro tipos de restricciones de las bases de datos (restricciones de unicidad, restricciones de claves primarias y externas, y restricciones de comprobación) estrechamente asociadas con una sola tabla de la base de datos. Se especifican como parte de la instrucción CREATE TABLE y pueden modificarse o eliminarse mediante la instrucción 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 definición de una tabla concreta.
Dominios El estándar SQL2 implementa el concepto formal de dominio como parte de la definición de las bases de datos. Como se describe en el Capítulo 11, un dominio es una colección con nombre de valores de datos que actúa 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 continuación se puede ver el empleo de una instrucción CREATE DOMAIN para la definición de un dominio denominado IDS_EMPL_VALIDOS, que consiste en los números de identificación de empleado válidos de la base de datos de ejemplo. Estos números son enteros de tres cifras del rango 101 a 999, ambos incluidos: CREATE DOMAIN IDS_EMPL_VALIDOS INTEGER CHECK {VALUE BETWEEN 101 AND 199}
L
~
376
SOL. Manual de referencia
Si se deja de necesitar un dominio, se puede eliminar empleando una de las modalidades de la instrucción DROP DOMAIN de SQL2:
377
Base de datos Tablas de Samuel
Tablas de Jorge
OROP DOMAIN IDS_EMPL_VALIDOS CASCADE
;'-
OROP DQMAIN IDS_EMPL_VALID RESTRICT
- -- "
I
\ I 11
1
:D] 1 \
\
Figura 13,5.
(CREATE/DROP ALIAS)
Las bases de datos de producción 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 Capítulo 15. Recuérdese, no obstante, que hay que utilizar nombres de tabla calificados para hacer referencia a las tablas de otros usuarios. En la práctica, 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:
11
"
rn!![]JJ I \
n
Tablas del ABD
;'----------------'I ( PRODUCTOS
/-
:EEEI " ITJJ .J
Las reglas de eliminación CASCADE y RESTRICT operan igual que para la eliminación de columnas. Si se especifica CASCADE, cualquier columna definida en términos del dominio eliminado se elimina a su vez de manera automática. Si se especifica RESTRICT, el intento de eliminación del dominio fallará si se basa en él alguna definición 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 eliminación accidental de columnas (y, sobre todo, de los datos que contienen).
Alias y sinónimos
Capítulo 13: Creación de bases de datos
I I OFICINAS I I FFFf=Ff=I I I l' 1 REPRESENTANTES I 1 PEDIDOS CLIENTES
LLLL.L...LJ
FFffR11
1 I I I I I
:¡ []TI] WillU " ~- []JI: 11
'1 /
-
I
... _---------------_ ....
'
Organización típica de una base de datos de producción.
Crear sinónimos 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 sinónimo 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:
Hacer U1lQ lista del nombre, ventas, oficina y ventas de la oficina de todos los empleados.
SELECT NOMBRE, REPRESENTANTES.VENTAS, FROM REPRESENTANTES, OFICINAS
SELECT NOMBRE, OP_ADMIN.REPRESENTANTES.VENTAS, OFICINA, OP_ADMIN.OFICINAS.VENTAS FROM OP_ADMIN.REPRESENTANTES, OP_ADMIN.OFICINAS
OFICINA.
OFICINAS.VENTAS
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 sinónimos simplifican las instrucciones de SQL que se utilizan y hacen que parezca que las tablas son propias. Si, más adelante, se decide que ya no se desea utilizar los sinónimos, pueden eliminarse con la instrucción DROP ALIAS:
Para abordar este problema, muchos productos de SOBD de SQL ofrecen la posibilidad de utilizar un alias o sinónimo. Un sinónimo es un nombre que se define para sustituir el nombre de una tabla. En DB2 los alias se crean utilizando la instrucción CREATE ALIAS. (Las versiones más antiguas de DB2 utilizaban en realidad la instrucción CREATE SYNONYM, y Gracle sigue utilizando esta modalidad de la instrucción, pero tiene el mismo efecto que la instrucción CREATE ALIAS.) Si se fuera el usuario. denominado Jorge, por ejemplo, de la Figura 13.5, se podría utilizar este par de instrucciones CREATE ALIAS:
Eliminar los sinónimos creados a11leriormente. DROP ALIAS REPRESENTANTES DROP ALIAS OFICINAS
l
378
SOL. Manual de referencia
Capítulo 13: Creación de bases de datos
DB2, Oracle e Inforrnix admiten los sinónimos dos en el estándar ANSI/ISO para SQL.
índices
O
alias. No vienen especifica-
(CREATE/DROP INDEX)
Una de las estructuras de almacenamiento físico que proporciona la mayor parte de los sistemas de gestión de bases de datos basados en SQL son los índices, que son una estructura que ofrece un acceso rápido 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 cón base en la clave primaria de la tabla, que es una combinación de las columnas ID_FAB e ID_PRODUCTO.
El SOBD utiliza el índice igual que se podría 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 rápidamente 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, considérese esta instrucción SELECT:
Buscar la cantidad y el precio de los cables de la serie cuatro. SELECT STOCK, PRECIO FROM PRODUCTOS
WHERE DESCRIPTION
Tabla PRODUCTOS
ID FAB
r-;::¡..
ID PRODUCTO
779c
lMM 'Cl 'Cl
41003 41004
DESCRIPCION
r=:
ÍNDICE
PRECIO
90-kg brazo
1.875,OO€
Serie 3, cable Serie 4, cable
9 207
107,OO€ 117,OO€
139
ÍNDICE
I 90-kg brazo
'Cl 41003 'Cl 41004
I ,
, , IMM 779C
STOCK
Serie 3. cable
I
Serie 4, cable
,
. Figura
13.6.
Dos
índices para la tabla PRODUCTOS.
379
~
'Serie 4,
cable'
La instrucción 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 vería obligado a procesar la consulta explorando secuencialmente la tabla PRODUCTOS, fila por fila, examinando la columna DESCRIPCION de cada fila. Para asegurarse de que había encontrado todas las filas que satisfacen la condición de búsqueda, tendría que examinar todas las fijas de la tabla. En tablas de gran tamaño, 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 (<
~ 380
SOL. Manual de referencia
para cerciorarse de que su valor no duplica un valor ya contenido en la tabla. Sin un índice de esas columnas, el SGBD tendría que examinar de manera secuencial cada fila de la tabla para comprobar la restricción. Con un índice, el SOBD puede usar sencillamente el índice para hallar la fila (si es que existe) con el valor en cuestión, lo que supone una operación mucho más rápida que una búsqueda secuencial. En la base de datos de ejemplo estas columnas son buenas candidatas para índices adicionales:
f-- CREATE
I
Crear un índice de la tabla PEDIDOS. CREATE UNIQUE INDEX IND_PROD_PED ON PEDIDOS (FAS, PRODUCTO)
=-r
L
381
INDEX nomb,.-indice ON nomb,.-de-tab/a
UNIQUE
• La columna EMPRESA de la tabla CLIENTES debería 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 según 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 según el producto encargado.
El estándar SQL2 no menciona los índices ni la manera de crearlos. Trata los índices de las bases de datos como un detalle de implementación, que es ajeno al lenguaje SQL básico 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 tamaño. En la práctica, 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 instrucción CREATE INDEX, que puede verse en la Figura 13.7. La instrucción asigna un nombre al índice y especifica la tabla para la que se ha creado. La instrucción también especifica las columnas que hay que indexar y si deben indexarse en orden ascendente o descendente. La versión de DB2 de la instrucción CREATE INDEX, que puede verse en la Figura 13.7, es la más directa. Su única opción es la palabra clave UNIQUE, que se utiliza para especificar que la combinación de columnas que se está indexando debe contener un valor único para cada fila de la tabla. A continuación se ofrece un ejemplo de una instrucción 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.
Capítulo 13: Creación de bases de datos
T
••
nomb,.-de-co/vmna ~ )
~ Figura
i
13.7.
Diagrama
sintáctico básico de la instrucción
CREATE INDEX.
En la mayor parte de los productos de SGBD la cláusula CREATE INDEX incluye cláusulas adicionales específicas del SGBD que detallan la ubicación de disco del índice y parámetros de ajuste del rendimiento. Los parámetros de rendimiento habituales incluyen el tamaño de las páginas 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 disposición que ubica las filas de datos físicas en el medio del disco en el mismo orden que el índice), etc. Estas opciones hacen de la instrucción CREATE INDEX bastante dependiente del SOBD en su uso real. Algunos productos de SOBD incluyen dos o más tipos diferentes de índices, que están 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 búsqueda eficiente de un solo valor o de un rango de valores, como la búsqueda exigida por el operador de comparación de desigualdad o una operación de comprobación de rango (SETWEEN). Un tipo de índice diferente, los índices asociativos, utilizan una técnica aleatoria para ubicar todos los valores posibles de los datos en un número 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 cajón, el SOBD puede hallar ese valor con sólo ubicar el cajón correspondiente y buscar en él. Con quinientos cajones el número de elementos que hay que buscar se reduce. en promedio por un factor de quinientos. Esto hace que los índices asociativos sean muy rápidos al buscar la coincidencia exacta con un valor de los datos. Pero la asignación de los valores a los cajones no conserva el orden de los valores de los datos,
382
por lo que no se pueden utilizar los índices asociativos para búsquedas de desigualdades ni de rangos. Otros tipos de índices resultan adecuados para otras situaciones específicas de los SOBD. Por ejemplo, una variación 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 número de valores de datos posibles relativamente pequeño. Cuando un SGBD incluye varios tipos de índices, la instrucción CREATE INDEX no s6lo define y crea el índice, sino que también define su tipo.
Si se crea un índice para una tabla y más adelante se decide que no es necesario, la instrucción DROP INDEX elimina el índice de la base de dmos. Esta instrucción elimina el índice creado en el ejemplo anterior:
Eliminar el índice creado anteriormente.
383
Capítulo 13: Creación de bases de datos
SOL Manual de referencia
La Tabla 13.1 muestra el modo en que algunos de los productos más populares de SQL utilizan los verbos CREATE, DROP y ALTER en su LDD ampliado. El estándar SQL2 adopta este mismo acuerdo para ocuparse de la creación, destrucción y
modificación de todos los objelos de las bases de dalos de SQL2. Tabla 13.1.
Instrucciones LDD de los productos basados en SOL más populares
Instrucciones LDD de SQL
Objeto gestionado
Incluidas en casi todas las marcas de SGBD
CREATE/DROP/ALTER TABLE
Tabla
CREATE/DROP/ALTER VIEW
Vista
CREATE/DROP/ALTER INDEX
Índice
Incluida:; en DB2 CREATE/DROP ALIAS
Gestión de otros objetos de la base de datos Los verbos CREATE, DROP y ALTER forman la piedra angular del lenguaje de definición 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 Capítulo 14). La mayor parte de los productos de SGBD populares basados en SQL utilizan también 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.
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 añadió 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 caracteríslicas se popularizaron, otros productos de SGBD añadieron 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 instrucción 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. Más allá de las tres primeras palabras las instrucciones se vuelven muy dependientes de cada SGBD y no siguen ningún estándar. Pese a todo, esta parte común da una sensación uniforme a los diferentes dialectos de SQL. Por lo menos, indica al usuario el lugar del manual de referencia en que debe buscar la descripción de la nueva posibilidad. Si se encuentra un nuevo SGBD basado ~n SQL y se sabe que alberga un objeto conocido como BLOB, lo más probable es que utilice las instrucciones CREATE BLOB, DROP BL08 Y ALTER 8L08.
Alias para una tabla o visla
CREATE/DROP/ALTER BUFFERPOOL Conjunto de búferes de E/S utilizados por DB2 Tipo de datos distinto definido por el usuario CREATE/DROP DISTINCT TYPE CREATE/DROP FUNCTION
Función definida por el usuario
CREATE/DROP/ALTER NODEGROUP
Grupo de particiones o nodos de la base de datos
DROP PACKAGE
Módulo de acceso a programas de DB2
CREATE/DROP PROCEDURE
Procedimiento almacenado de DB2 definido por el usuario
CREATE/DROP SCHEMA
Esquema de la base de datos
CREATE/DROP/ALTER TABLESPACE Espacio de tablas (área de almacenamiento para datos de DB2) CREATE/DROP TRIGGER
Disparador de la base de datos
Incluidas en Infonnix CREATE/DROP CAST
Molde para la conversión de tipos de datos
CREATE/DROP DATABASE
Base de datos de Informix con nombre
CREATE/DROP DISTINCT TYPE
Tipo de datos diferente deflOido por el usuario
CREATE/DROP FUNCTION
Función definida por el usuario
CREATE/DROP OPAQUE TYPE
Tipo de datos opaco definido por el usuario
CREATE/DROP OPCLASS
Método de acceso al almacenamiento de disco definido por el usuario
CREATE/DROP PROCEDURE
Procedimiento almacenado de Informix definido por el usuario
(comilllÍa)
/ 384
Capítulo 13: Creación de bases de datos
SOL. Manual de referencia
Tabla 13.1.
Instrucciones LDD de los productos basados en SOL más populares (Continuación)
Tabla 13.1.
385
Instrucciones LDD de los productos basados en SOL más populares (Continuación)
Instrucciones LDD de SQL
Objeto gestionado
Papel del usuario en la base de datos
CREATE SCHEMA
Esquema de la base de datos
CREATE/OROP ROUTINE
Procedimiento almacenado de lnforrnix definido por el usuario
CREATE/DROP/ ALTER SÉQUENSE
Secuencia de valores definida por el usuario
CREATE/DROP/ALTER SNAPSHOT
CREATE/DROP ROW TYPE
Tipo de fila con nombre
Tabla de resultados de consultas sólo para lectura
CREATE SCHEMA
Esquema de la base de datos
CREATE/DROP SYNONYM
CREATE/DROP SYNONYM
Sinónimo (alias) para una tabla o vista
CREATE/DROP/ALTER TABLESPACE
CREATE/DROP TRIGGER
Disparador de la base de dalOS
Espacio de tablas (área de almacenamiento para datos de Oracle)
CREATE/ OROP / ALTER TRIGGER
Disparador de la base de datos
Base de datos
CREATE/DROP TYPE
Tipo de datos abstfaClO definido por el usuario
CREATE/DROP TYPE BODY
Métodos para un tipo de datoS abstracto
CREATE/DROP/ALTER USER
ID de usuario de aracle
Instrucciones LDD de SQL
Objeto gestionado
CREATE/DROP ROLE
(~xtensión
de objeto)
Incluidas en Microsoft SQL Server CREATE/ OROP / ALTER DATABASE CREATE!DROP DEFAULT
Valor predeterminado de la columna
CREATE/DROP/ALTER PROCEDURE
Procedimiento almacenado de SQL Server
CREATE/OROP RULE
Regla de integridad de la columna
CREATE SCHEMA
Esquema de la base de datos
CREATE/DROP/ALTER TRIGGER
Disparador almacenado
Incluidas en Sybase
Incluidas en Oracle CREATE/DROP CLUSTER
Sinónimo (alias) para una tabla o una vista
Agrupación de tablas para ajuste del rendimiento
CREATE/OROP!ALTER DATABASE
Base de datos
CREATE/DROP DEFAULT
Valor predeterminado de la columna
CREATE EXISTING TABLE
Copia local de una tabla remota ya existente
CREATE/DROP PROCEDURE
Procedimiento almacenado de Sybase
CREATE/DROP/ALTER ROLE
Papel del usuario en la base de datos
CREATE DATABASE
Base de datos de aracle con nombre
CREATE/DROP DATABASE LINK
Enlace de red para acceso remoto a las tablas
CREATE/DROP RULE
Regla de integridad de la columna
CREATE/DROP DIRECTORY
Directorios del sistema operativo para almacenamiento de objetos de gran tamaño
CREATE SCHEMA
Esquema de la base de datos
CREATE/DROP/ALTER FUNCTION
Función definida por el usuario
CREATE/DROP TRIGGER
Disparador almacenado
CREATE/DROP LIBRARY
Funciones externas que pueden llamarse desde PUSQL
ANSI/ISO de SQL
Especificadas por el estándar
CREATE/DROP/ALTER PACKAGE
Grupo de procedimientos de PUSQL que pueden compartirse
CREATE/DROP ASSERTION
Restricción de comprobación para todo el esquema
CREATE/DROP/ALTER PROCEDURE
Procedimiento almacenado de aracIe definido por el usuario
CREATE/DROP CHARACTER SET
Conjunto de caracteres ampliado
CREATE/DROP/ALTER PROFILE
Límites del uso de recursos por la base de datos
CREATE/DROP COLLATION
Secuencia de ordenamiento del conjunto de caracteres
CREATE!OROP/ALTER ROLE
Papel del usuario en la base de datos
CREATE/DROP/ALTER ROLLBACK SEGMENT
Área de almacenamiento para la recuperación de la base de datos
Especificación de los valores válidos de los datos Esquema de la base de datos Conversión entre conjuntos de caracteres
386
SOL. Manual de referencia
387
Capítufo 13: Creación de bases de datos
Estructura de la base de datos
ejemplo para albergar una aplicación de nómina y una aplicaci6n de contabilidad, además de las tareas de procesamiento de pedidos que ahora alberga.
El estándar 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. Prácticamente 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 gestión 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 informático. 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. También 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, supóngase que se amplía la base de datos de
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 informáticos y de las minicomputadoras (como la versión 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 nóminas se almacenan en tablas de la base de datos. Las tablas principales de cada aplicaci6n se reúnen y son propiedad de un solo usuario, que probablemente sea la persona encargada de esa aplicación 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 nóminas, por ejemplo, puede contener una clave externa que haga referencia a la tabla OFICINAS, y las aplicaciones pueden utilizar esa relación 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 añaden más aplicaciones. Son frecuentes las bases de datos de DB2 o de Oracle con varios centenares de tablas. Los problemas de la gestión de una base de datos de ese tamaño -realización de copias de seguridad, recuperación de datos, análisis del rendimiento, etc.- suelen exigir un administrador de la base de datos a tiempo completo.
Base de datos Tablas de José ;"-
f I
I I I I I I I \
ELE! PERSONAS
ITl-- -
/-
\ I I I I
MASCOTAS
....
Tablas de María
---,
I 1 I I I
/
AMIGOS I 1 I I I MASCOTAS I I 1
I I 1 I I I 1• • 11 I I 1 I I I I I 1
ITIJ
\
CIIIJ
Base de datos única del sistema
Tablas de Samuel
- - -,
I
-------------- .... OFICINAS
EEEEEE1 PEDIDOS
[I]],
\
....
m PRODUCTOS
m
I I 1 I I I I 1 1 1 I
CUMPLE1illOS
_-------------
Figura 13.8. Organización de las bases de datos en SOLl.
\
/
Tablas de Jorge Tablas de María ,---------, ,---------,
Tablas de José
,---------, I OFICINAS
I
I
1
¡::::¡::¡::¡:::
:
I~I I I :
: rnmBOLETIN I I
,==
mi ¡
I PRODUCTOS 1 I I
:
1 I I I
.. , J
[]]CUENrASI
::
mFICHAJES!
I .
I I I I I I
I
LlJTISALARIOS:
==-=_ . .
Figura 13.9. Arquitectura de base de datos única.
: 1
I I I I J
omPEDIDOS
,--------_ ....
¡ I I I
: I I
I
/ 388
SOL. Manual de referencia
Capítulo 13: Creación de bases de datos
En la arquitectura de base de daros única, la obtención del acceso es muy sencilla: sólo hay una base de datos, por lo que no hace falta realizar ninguna elección. Por ejemplo, la instrucción de SQL para programación que conecta al usuario con una base de datos de Ofucle es
CONNECT, y
Jos usuarios tienden a hablar en
términos de conexión con Oracle, más que de conexión con una base de datos concreta. (De hecho, en esta arquitectura, la base de datos suele estar asociada con una sola copia en ejecución 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 producción y otra para pruebas. Fundamentalmente, no obstante, todos los datos de producción se hallan reunidos en una sola base de datos.
/ _ _ _TablasdeJo' _ se OFICINA: - - ~
I 1
- - - - .....
[[J]J m
I LLLLLLJI 1 I PRODUCTO S
I 1 1 \
-
Arquitectura de múltiples bases de datos
I
[TI]
I 1 1 I I
1 1I -- , I I ""1
PEDIDOS
II
... _ - - - - - -
La Figura 13.10 muestra una arquitectura de múltiples 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 aplicación concreta. Cuando se añade una aplicación nueva, probablemente se crea una nueva base de dalOs. La principal ventaja de esta arquitectura de múltiples bases de dalOs respecto de la arquitectura de base de datos única es que divide las tareas de gestión de los dalOs en fragmentos de menor tamaño, más manejables. Cada persona responsable de una aplicación puede ser ahora el administrador de su propia base de datos, con menores preocupaciones respecto de la coordinación global. Cuando llega el momento de agregar una aplicación nueva, puede desarrollarse en su propia base de datos, sin afectar a las bases de datos ya existentes. Es más probable también que los usuarios y los programadores recuerden la estructura global de sus propias bases de datos. El principal inconveniente de la arquitectura de múltiples bases de datos es que cada base de datos puede transformarse en una isla de información, desconectada de las demás. 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 adquisición al fabricante del SGBD de software distribuido adicional del SGBD. Si Un SGBD utiliza una arquitectura de múltiples bases de datos y admite las consultas entre bases de datos, debe ampliar los Convenios de denominación de tablas y columnas de SQL. Los nombres calificados de tabla no sólo deben especificar al propietario de la tabla, sino también la base de datos que contiene a esa tabla. Generalmente, el SGBD amplía la notación con puntos de los nombres de las tablas anteponiendo el nombre de la base de datos al del propietario, separados
, ¡'-
\
1 I I 1 1 \ ,
-
rn
1 I I I 1 1 1
• ••
I
Base de datos PEDIDOS Tablas de Maria ------------..... (CUENTAS ,
11 1 1 1 I I
I
I
\
,
",,-
,
[J]' m rtm:, [TI] , I
1
:1 1 1
I 1 1
1 1
BOLETíN
1 1 I I
I
1 I
... _-----------"" '
\
• ••
I
....
I
-
Base de datos CONTABILIDAD Tablas de Jorge
/------------.... :
mFICHAJES
I
",,-
:
~
1 1
1
1 1
I
1 1
1
:
[]J]SALl\RIOS
: : 1
I
~
1 1
1, \
... ~--_...:~---""
----, 1
m ITITl ... - - --
1 1 1 1 I 1 1 I
Base de datos NOMINAS
Figura 13.10. Arquitectura de múltiples bases de datos.
• ••
389
390
Capítulo 13: Creación de bases de datos
SOL. Manual de referencia
por un punto (.). Por ejemplo, en una base esta referencia a una tabla:
~e
391
datos de Sybase o de SQL Server, Directorio de nivel superior
PEDIDOS.JOSE.OFICINAS
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 nóminas con la tabla
Directorio DESARROLLO
OFICINAS: SELECT
PEDIDOS .JOSE .OFICINAS. CIUDAD,
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 excepción y no la norma, y se pueden utilizar generalmente los nombres predeterminados de bases de datos y de usuarios. Con la arquitectura de múltiples bases de datos, el acceso a las bases de datos se hace algo más 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 contraseña para obtener acceso. Para el acceso mediante programación, el SGBD suele ampliar el lenguaje SQL incorporado con una instrucción que conecta al programa con una base de datos concreta. La modalidad de lngres para la conexión con la base de datos denominada PEDIDOS es: CONNECT
Figura 13.11.
Arquitectura de ubicación múltiple.
'PEDIDOS'
Para Sybase y Microsoft SQL Server, la instrucción equivalente es:
utilizar varias bases de datos para estructurar su propia información. Los inconvenientes de la arquitectura de ubicación múltiple son los mismos que los de la ar quitectura de múltiples bases de datos. Además, el SGBD no suele tener toda la información 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 difícil la administración centralizada de la base de datos. La arquitectura de ubicación múltiple vuelve a hacer más complejo el acceso a las bases de datos, ya que hay que especificar tanto el nombre de la base de datos como su ubicación en la jerarquía de directorios. La sintaxis de SQL de VAX para el acceso a las bases de datos de RdbNMS es la instrucción DECLARE DATABASE. Por ejemplo, esta instrucción DECLARE DATABAS E establece una conexión c.on la base de datos, denominada PEDIDOS, del directorio de VAXNMS, denommado M
USE
'PEDIDOS'
Arquitectura de ubicación múltiple La Figura 13.11 muestra una arquitectura de ubicación múltiple que admite varias bases de datos y utiliza la estructura de directorios del sistema informático 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 múltiples bases de datos, cada aplicación 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 ubicación múltiple es su flexibilidad. Resulta especi.almente adecuada en aplicaciones como la ingeniería y el diseño, en las que puede que muchos usuarios sofisticados· del sistema informático deseen
Si la base de datos se halla en el directorio en curso del usuario (lo que suele ocurrir), la instrucción se reduce a: DECLARE
Estructura de la base de datos y el estándar ANSI/ISO El estándar ANSIIISO SQLJ realizaba una distinción tajante entre el lenguaje de manipulación de datos y el lenguaje de definición de datos de SQL, y los definía de hecho como dos lenguajes diferentes. El estándar no exigía que las instrucciones del LDD fueran aceptadas por el SGBD durante su operación nor.:~:.t:. Una de las ventajas de esta separación de LMD y LDD era que el estándar permitía una estructura estática de la base de datos como la utilizada por Jos productos de SGBD antiguos jerárquicos y de red, como puede verse en la Figura 13.12. La estructura de la base de datos especificada por el estándar SQLI era bastante directa. Se definían 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 terminología habitual es es propiedad de) un usuario llamado José, y el otro es propiedad de María. El esquema de José contiene dos tablas, denominadas PERSONAS y LUGARES. El esquema de María también 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 estándar SQL2 amplió de manera significativa el concepto de SQLl de definición de base de datos y de esquema de la base de datos. Como se indicó anteriormente, el estándar SQL2 exige que las instrucciones de definición 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 sólo al crear la base de datos. Además, el concepto de SQLl de esquemas y usuarios (denominado oficialmente IDs de autorización en el estándar) se amplió de manera significativa. La Figura 13.13 muestra la estructura de alto nivel de la base de datos especificada por el estándar SQL2. La estructura de la base de datos de nivel superior descrita por el estándar SQL2 es el entorno de SQL. Se trata de un conjunto conceptual de entidades de la base de datos asociado con una implementación del SGBD que sigue el estándar de SQL2. El estándar no especifica el modo en que se créan entornos de SQL; eso depende de cada implementación concreta del SOBO. El estándar define estos componentes de los entornos de SQL:
DATABA5E
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 más, la técnica utilizada con más 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, también es necesario introducir un alias de la base de dalos para eliminar toda ambigüedad. 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
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 discusión, 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 también hacen imposible pasar de manera transparente los programas desarrollados para un SGBD a otro, aunque el proceso de conversión suele resultar más tedioso que complicado.
Bases de datos en múltiples servidores
• Software de SGBD que cumpla el estándar SQL2. • Usuarios con nombre (denominados IDs de autorización en el estándar) que tienen los privilegios para llevar a cabo acciones concretas sobre los datos y las estructuras de la base de datos. • Módulos de programas que se utilizan para tener acceso a la base de datos. El estándar SQL2 especifica la ejecución real de las instrucciones de SQL en términos de un lenguaje de módulos, que en la práctica 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 estándar indica que, conceptualmente, el entorno de SQL incluye el código del programa para acceso a la base de datos. • Catálogos que describen la estructura de la base de datos. Los esquemas de las bases de datos de estilo SQLl están contenidos en estos catálogos.
Con el aumento de los servidores de bases de datos y de las redes de área local, el concepto de ubicación de la base de datos incluida en la arquitectura de ubicación múltiple se amplió al concepto de servidor físico de la base de datos. En la práctica, parece que la mayoría de los productos de SGBD de hoy en día convergen en una arquitectura de múltiples bases de datos implementada en un servidor (ísico. En su nivel más 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 relación entre los nombres de los servidores y las ubicaciones de los servidores físicos la maneja el software de red. La relación entre los nombres de las bases de datos y los archivos físicos o los sistemas de archivos de un servidor la maneja el software del SGBD.
, ..L
394
Capítulo 73: Creación de bases de datos
SOL. Manual de referencia
395
Fase 11: Utilizar la base de datos
Fase 1: Crear [a base de datos
Esquema de la base de datos
Programa de aplicación
I
t
\ Instrucciones' ;LDD
=_1"-
I,,_====-,'
Programa creador de bases de datos
Tablas de José
Tablas de María
/----, /----, s
I I I I I I I I I I I I
Programa ¡: de aPliCaCjó:J~
"""'"""'"
I I
LElTI BJjj
I
I
, I
I
LUGARES
II
LUGARES
I I 11
.
,---_/ ,---_/
I I
".....""..¡j
~
. - Instrucciones de LMD
SGBD
Tablas de José Tablas de Maria
Figura 13.13.
¡ :/[]]P~R;ON~S~I '( Wf -'¡ I I I
LUGARES
I I
LUGARES
Estructura de una base de datos según SQL2.
Catálogos en SQL2
' :: w : : ITID:: BJjj : ,----/ ,----/ I
Base de datos
Figura 13.12.
I
Programa de aplicación J:
[[ID ![ m ! -r: I
¡=='---,
En los entornos de SQL, la estructura de la base de datos se-define mediante uno o varios catálogos con nombre. La palabra «catálogo» en este caso se utiliza del mismo modo que se ha utilizado históricamente en los grandes sistemas informáticos: para describir un conjunto de objetos (generalmente archivos). En los sistemas de minicomputadoras y de computadoras personales, el concepto es análogo, grosso modo, a un directorio. En el caso de las bases de datos de SQL2, el catálogo es un conjunto de esquemas de la base de datos con nombre. El catálogo también contiene un conjunto de tablas del sistema (denominado a menudo, de manera que induce a error, catálogo del sistema) que describe la estructura de la base de datos. El catálogo es, por tanto, una entidad que se describe a sí misma dentro de la base de datos. Esta característica de los catálogos de SQL2 (que ofrecen todos los principales productos de SQL) se describe con detalle en el Capítulo 16. El estándar SQL2 describe el papel del catálogo y especifica que cada entorno de SQL puede contener uno o varios (realmente, cero o más) catálogos, cada uno de los cuales debe tener un nombre diferente. Indica explícitamente que el mecanismo para la creación y la destrucción de los catálogos viene definido por la im-
I
Base de datos
Un SGSD con LDD estático.
• 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 catálogos. Aunque el estándar describe conceptualmente los datos como externos a la estructura de los catálogos, es frecuente creer que los datos se contienen en una tabla, que está en un esquema, que está en un catálogo.
.J
/ 396
SOL. Manual de referencia
Capítulo 13: Creación de bases de datos
397
Los esquemas se crean con la instrucción CREATE SCHEMA, que puede verse en la Figura 13.14. A continuación se ofrece la definición 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:
plementación. El estándar indica también que el grado en que el SGBD permite el acceso a otros catálogos viene definido por la implementación. Específicamente, si una sola instrucción de SQL puede tener acceso a los datos desde varios catálogos, si una sola transacción de SQL puede abarcar varios catálogos o, incluso, si una sola sesión de usuario con el SGBD puede cruzar las fronteras entre los catálogos )ion, todas ellas, características definidas por la implementación. El estándar indica que cuando un usuario o programa establece contacto por primera vez con un entorno de SQL. uno de sus catálogos se identifica como catálogo predeterminado de la sesión. (Una vez más, la manera en que se selecciona este catálogo viene definida por la implementación.) Durante el curso de una sesión, el catálogo predeterminado puede cambiarse utilizando la instrucción SET
CREATE SCHEMA CREATE TABLE (NOMBRE EDAD CREATE TABLE (CIUDAD ESTADO GRANT ON TO GRANT ON TO
CATALOG.
Esquemas en SQL2
ESQUEMAJOSE AUTORIZACION JOSE PERSONAS VARCHAR(30). INTEGER) LUGARES VARCHAR(30j. VARCHAR(30jj ALL PRIVILEGES PERSONAS PUSLIC SELECT LUGARES MARIA
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 básicos 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 Capítulo 14. • Dominios. Funcionan como tipos ampliados de datos para la definición de columnas en las tablas del esquema, como se describe en el Capítulo 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 actualización 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 Capítulo 14. • Conjuntos de caracteres. Las bases de datos soportan diferentes idiomas y gestionan la representación de caracteres no románicos de esos idiomas (por ejemplo. la tilde diacrítica empleada por muchos idiomas europeos o las representaciones de dos bytes de los ideogramas utilizados en muchos idiomas asiáticos) mediante conjuntos de caracteres definidos por el esquema. • Ordenaciones. Trabajan mano a mano con los conjuntos de caracteres, definiendo la secuencia de ordenación 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
~
.-1
AUTHORIZATION
nombre·usuario AUTHORIZATION
nombre-usuario
I
L
DEFAULT CHARACTER SET
nombre-eonjunto-caracteres
j
I -
••. resto de la definición de la Ubllt
CREATE TABLE
... resto de lit definición de lit V;$tlt
CREATE VIEW CREATE DOMAIN
- - - ... re$to de lit definición del dominio
CREATE ASSERTION
- - ... resto de lit definición de/ltSfJno ." re$to de lit definición del conjumo de C4rltCfe/'fJ$ -
CREATE CHARACTER SET CREATE COLLATION CREATE TRANSLATION GRANT privilegios
Figura 13.14.
~
... resto de la definición de lit SfJCUencilt de orOenación-
-
... resto de lit definición de lit lraducción
- - - - ... reslO de /11 definición dI! los privilegios
Diagrama sintáctico de la instrucción CREATE SCHEMA.
•
398
SOL Manual de referencia
Capítulo 13: Creación de bases de datos
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. Obsérvese que las instrucciones CREATE TABLE de la instrucción CREATE SCHEMA son instrucciones legítimas 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 sesión interactiva de SQL, de acuerdo con el estándar. Obsérvese 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 estándar SQLl, el estándar SQL2 permite crear esquemas con:
399
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 implícita a este esquema. Además, se supone que todas las tablas con nombre de las instrucciones de manipulación de datos de SQL2 son tablas definidas en este esquema predeterminado. El nombre del esquema califica de manera implícita los nombres de todas las tablas utilizadas en las instrucciones de SQL. Como se indicaba en el Capítulo 5, se puede utilizar un nombre de tabla calificado para hacer referencia a las tablas de otros esquemas. De acuerdo con el estándar 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 sería:
• 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 instrucción CREATE SCHEMA se transforma de manera automática en propietario del esquema. • Sólo una ID de usuario. En este caso, el nombre del esquema se transforma en la ID de usuario. Esto cumple el estándar SQL1, y la práctica de muchos productos comerciales de SGBD en los que conceptualmente hay un esquema por usuario.
VENTAS. OFICINAS
Los esquemas de SQL2 que ya no son necesarios pueden eliminarse utilizando la instrucción DROP SCHEMA, que puede verse en la Figura 13.15. La instrucción exige que se especifique una de las reglas de eliminación para eliminar columnas que ya se han descrito: bien CASCADE, bien RESTRICT. Si se especifica CASCADE, todas las estructuras dentro de la definición del esquema (tablas, vistas, asertos, etc.) se eliminan· de manera automática. Si se especifica RESTRICT, la instrucción no tendrá éxito si permanece dentro del esquema alguna de estas estructuras. De hecho, la regla RESTRICT obliga a eliminar las tablas, vistas y demás estructuras incluidas en el esquema antes de eliminar el propio esquema. Se trata de una protección contra eliminaciones accidentales de esquemas que contengan datos o definiciones de bases de datos aún de valor. El estándar SQL2 no especifica ninguna tabla ALTER SCHEMA. En vez de eso, se puede alterar cada definición de las estructuras incluidas en el esquema, mediante instrucciones como
Si s~ crea un esquema de SQL2 con sólo un ID de usuario como nombre del esquema, el esquema de calificación de las tablas se convierte exactamente en el esquema sencillo que se describe en el Capítulo 5. El nombre del esquema es el nombre de usuario, y el nombre de tabla calificado especifica ese nombre antes del punto. La instrucción CREATE SCHENA de SQL2 tiene otra ventaja no tan evidente. Se recordará de la discusión anterior sobre la instrucción CREATE TABLE que no se podía crear con facilidad un ciclo referencial (dos o más tablas que se hacen referencia entre sí empleando relaciones de claves externas y primarias). En lugar de eso, había que crear antes una de las tablas sin su definición de la clave externa, y luego había que añadir la definición de la clave externa (con la instrucción ALTER TABLE), una vez creadas las otras tablas. La instrucción 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 práctica, la instrucción CREATE seHEMA se utiliza generalmente para crear por primera vez un nuevo conjunto de tablas interrelacionadas. Posteriormente, cada tabla se añade, elimina o modifica empleando las posibilidades de CREATEf
ALTER TABLE.
DROP!ALTER TABLE.
f-
DROP SCHEMA
Figura 13.15.
nombre·de·esquema
Diagrama
L
RESTRICT
~------_ ••
CASCADE
--.J
sintáctico de la instrucción
Muchas de las principales marcas de SGBD han pasado a adoptar alguna modalidad de la instrucción CREATE SCHENA, aunque hay variaciones significativas entre unas marcas y otras. La instrucción de Gracle CREATE SCHEMA permite crear tablas, vistas y privilegios, pero no las demás 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 amplía los objetos incluidos en el esquema para abarcar los índices, los disparadores y los sinónimos. Sybase ofrece posibilidades parecidas. En cada caso, las posibilidades ofrecidas cumplen los requisitos de la implementación de nivel Inicial de SQL2. .
DROP SCHEMA.
1
/ 400
SOL. Manual de referencia
Resumen Este capítulo ha descrito las características del lenguaje de. definición de datos de SQL que definen y modifican la estructuras de las bases de datos:
CAPíTULO
• La instrucción CREATE TABLE crea tablas y define sus columnas, sus claves primarias y sus claves externas. • La instrucción DROP TABLE elimina de la base de datos tablas creadas anteriormente. • La instrucción ALTER TABLE puede utilizarse para añadir 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 añaden 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 específicos de cada SGBD. • El estándar SQL2 especifica un esquema de base de datos que contiene un conjunto de tablas, que se manipula con las instrucciones CREATE SCHEMA y
14
Vistas
Las táblas de las bases de datos definen la estructura y organización de los datos. No obstante, SQL también 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 perriüte el acceso al resultado de esta consulta como si fuera, de hecho, una tabla auténtica de la base de datos. Las vistas constituyen una parte importante de SQL por varios motivos:
DROP SCHEMA.
• Las diversas marcas de SGBD utilizan enfoques muy diferentes para la organización 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 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 sólo 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 más natural para cada usuario. Este capítulo 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 ilusión de la vista concediendo a las vistas nombres,
401
1
402
Capítulo 14: Vistas
SOL. Manual de referencia
,
T bl a REPRESENTANTES NUM EMPL
'" >O, '" >O. '" no >O,
Vista DATOSREP
NOMBRE
María Jiménez Sarnuel Clavel
.~
/
~~ I <
Bruno Arteaga Susana Santos León Fl:."eire Neus Azcárate
22 Daimiel 13 Navarra 12 Castellón 13 Almeria n León
REGIÓN
Oeste Este Este Este Oeste
'" >O,
>O, >O. NULL >O,
/
I~
Vista típica 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 típica. 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
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 obtendría 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:
.OSO,DOE
299 912,OO€ 594,OO€ 305 15 865.00€
//
~ Figura 14.1.
CUOTA
DCO,DOE DOO,DOE DCO,DOE
EDAD
NOMBRE
'OS Brullo Arteaga
403
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 información por cada representante, ampliada con el nombre de la ciudad y de la región en
Listar los representantes que han superado su cuota, mostrando el nombre, la ciudad y la región de cada uno. SELECT NOMBRE, CIUDAD, FROM DATOSREP WHERE VENTAS > CUOTA
REGlaN
NOMBRE
CIUDAD
REGlaN
María Jiménez Samuel Clavel Daniel Ruidrobo Pablo Cruz Bruno Arteaga Susana Santos León Freire
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 instrucción SELECT igual que a las columnas de las tablas verdaderas. Para algunas vistas también 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 prácticos, 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 instrucción de SQL, busca la definición 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 ilusión 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 más 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.
404
Capítulo 14: Vistas
SOL. Manual de referencia
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 producción las bases de datos desempeñan un papel fundamental en la definición de la estructura de la base de datos para los usuarios y en el mantenimiento de la seguridad. Las vistas ofrecen estas ventajas principales:
• Seguridad. Se puede conceder permiso a cada usuario para que sólo 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 automática para asegurarse de que cumplen las restricciones de integridad especificadas.
405
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.
Creación de vistas
(CREA TE VIEW)
La instrucción CREATE VIEW, que puede verse en la Figura 14.2, se emplea para crear vistas. La instrucción 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 instrucción CREATE VIEW puede asignar, de manera opcional, un nombre a cada columna de la vista recién creada. Si se especifica una lista de nombres de columna, debe tener el mismo número de elementos que el número de columnas generado por la consulta. Obsérvese que sólo se especifican los nombres de las columnas; el tipo de datos, su longitud y otras características de cada columna se obtienen de la definición de las columnas en las tablas fuente. Si se omite la lista de nombres de columna en la instrucción 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 idénticos. Aunque todas las vistas se crean de la misma manera, en la práctica se utilizan normalmente distintos tipos de vista para finalidades diferentes. -Los-apartados siguientes examinan estos tipos de vistas y ofrecen ejemplos de la instrucción CREATE VIEW.
Vistas horizontales Inconvenientes de las vistas Aunque las vistas ofrecen ventajas importantes, también '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 todavía 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 reunión compleja y puede tardar mucho tiempo en completarse. • Restricciones de actualización. Cuando un usuario intenta actualizar las filas de una vista, el SGBD debe traducir la solicitud en una actualización de las filas de las tablas fuente subyacentes. Esto es posible para las vistas sencillas,_ pero las vistas más complejas no pueden actualizarse; son sólo 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 sólo se desee permitir a un jefe de ventas ver las filas de la tabla REPRESENTANTES de los representantes de la misma región que el jefe de
l- CREATE
VIEW
J
nombre-de-visrsl
AS
consufts-+.
_(nombre-de-columnaL
t..-, ..-.J
Figura 14.2.
Diagrama sintáctico de la instrucción CREATE VIEW.
406
SOL. Manual de referencia
Capítulo 14: Vistas
ventas. Para conseguirlo, se pueden definir dos vistas, como se muestra a continuación:
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)
407
zontalmente las tablas para crear cada vista. Todas las columnas de la tabla fuente forman parte de la vista, pero sólo 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 continuación se ofrecen algunos ejemplos más de vistas horizontales: Definir una vista que sólo contenga las oficinas de la región Este.
Crear una vista que muestre los representantes de la región Oeste. CREATE VIEW OFICINASESTE AS SELECT FROM OFICINAS WHERE REGION ~ 'Este'
CREATE VIEW RE POESTE AS SELECT PROM REPRESENTANTES WHERE OFICINA_REP IN {21, 22}
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 sólo muestra los representantes de la región 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 número 102) que sólo 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 más de 30.000 € en pedidos actualmente en los libros. V'15 t a REPE S TE
DA
NUM_EMPL NOMBRE
105 109 106 104 101 103
Bruno Arteaga María Jiménez Samuel Clavel Bernardo Sánchez Daniel Ruidrobo Pablo Cruz
CREATE VIEW GRANDESCLIENTES AS SELECT PROM CLIENTES WHERE 30000.00 < (SELECT SUM(IMPORTE) FROM PEDIDOS WHERE CLIENTE: NUM_CLI)
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 cláusula WHERE determina las filas de la tabla fuente que son visibles en la vista.
Vistas verticales Otro uso frecuente de las vistas es la limitación del acceso de los usuarios sólo 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 número de empleado, el nombre y la asignación de oficina de cada representante, ya que esa información puede ser necesaria para procesar correctamente los pedidos. Sin
408
Capítulo 14: Vistas
SOL Manual de referencia
409
embargo, no hace falta que el personal de procesamiento de pedidos vea las ventas del año corriente de cada representante ni su cuota. Esta vista selectiva de la tabla REPRESENTANTES puede construirse con la vista siguiente:
Ofrecen una tabla privada para cada usuario, compuesta únicamente de las columnas que ese usuario necesita. A continuación se muestran algunos ejemplos de vistas verticales:
Crear una vista que muestre información seleccionada de cada representante.
Definir una vista de la tabla OFICINAS para el personal de procesamiento de pedidos que incluya la ciudad. el número de oficina y la región de cada oficina.
CREATE VIEW INFOREP AS SELECT NUM_EMPL, NOMBRE, OFICINA_REP FROM REPRESENTANTES
CREATE VIEW INFOOFICINAS AS SELECT OFICINA, CIUDAD, FROM OFICINAS
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.
REGION
Definir una visla de la labla CLIENTES que sólo incluya los nombres de los. clientes y su asignación 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 selección en la definición de la vista determina las columnas de la tabla Tabla INFO NU!'LDtPL
>OS
". ", '" ". no '" >OS
'" '" T
NUH.-EMPL NOMBRE Bruno Arteaoa l'Iada JiDénez Sllsana Sotntos $aII:lJ.el Clavel Ilen>ardo Sánchez Daniel Ruidrobo
", ". '" ". '" 11. '" """ ~, '" '" >OS
P'reirlr Pablo Crut NeU5 A%c6rate
LeÓD
m~
. " " "n ""
11
""....,"
OFICIWJ\EP
Bruno Arteaga !'laria Jilrinez sus...... San&os S"",uel Clavel Bernardo Sánchez D
Tomás Su
OFICINA.-REP 13 11 21 11 12 :L2
21 12 22
13 11
"
11 13 13
Vistas de subconjuntos de filas y columnas
""""
León Freire Pahl0 Cruz Neus Azcárll&e
. 13
fuente visibles en la vista. Como se trata de vistas verticales, todas las filas de la tabla fuente están representadas en la vista, y la definición de la vista no incluye ninguna cláusula WHERE.
~,
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 información de las tablas fuente. Resulta bastante frecuente definir vistas que fragmentan las tablas fue'nte tanto en la dimensión horizontal como en la vertical, como en este ejemplo:
FECH1\...CONTADO U-FES-88 U-OCT-89 lO-OIC-86 14-Jt./lI-88 19-KAY-81 20-OCT·86 13-D
m
".
COO>"A
Definir una vista que contenga el número de cliente, el nombre de la empresa y el lfmite de crédIto de todos los clientes asignados a Bruno Arteaga (empleado número 105).
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 selección de la vista y las columnas que cumplen la condición de selección.
Tabla REPRESENTANTES
Figura 14.4.
CLIBRUNO AS NUM_CLI, EMPRESA, LIMIT&_CREDITO CLIENTES REP_CLI = 105
Vista vertical de la tabla REPRESENTANTES.
1
410
SOL. Manual de referencia
Capítulo 74: Vistas María Jiménez Pablo Cruz
Vistas de agrupación La consulta especificada en la definición de una vista puede incluir una cláusula Este tipo de vista se denomina vista de agrupación, porq.ue los dat.os visibles mediante la vista son el resultado de una consulta de agrupacIón. Las VIStas de agrupación desempeñan la misma función que las consultas de agrupación; agrupan filas de datos relacionadas y generan una fila de resultados de la consulta
GROUP BY.
para cada grupo, que resume los datos de ese grupo. Las vistas d~ agrupación muestran el resultado de estas consultas de agrupaCión en una tabla virtual, Jo que permite llevar a cabo consultas posteriores sobre esos datos.. A continuación se ofrece un ejemplo de vista de agrupación: 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
Como muestra este ejemplo, la definición de una vista de agrupación incluye siempre una lista de nombres de columnas. La lista asigna nombres a las columnas de la vista de agrupación, que se obtienen mediante funciones de columna como SUM () y MIN ( ). Puede que también especifique un nombre modificado para una columna de agrupación. 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 agrupación, puede utilizarse para simplificar las consultas. Por ejemplo, esta consulta genera un informe sencillo que resume los pedidos de cada representante:
Mostrar el nombre, el número de pedidos, el importe total de los pedidos y el tamaño medio de los pedidos de cada representante. SELECT FROM WHERE aRDER
NAME, CUANTOS, TOTAL, PROMEDIO REPRESENTANTES, PEDIDOS_POR_REPRESENTANTE QUIEN : NUM_EMPL BY TOTAL DESC
A diferencia de las vistas horizontales o verticales, las filas de las vistas de agrupación no tienen una correspondencia de uno a uno con las filas de la tabla fuente. La vista de agrupación no es s610 un filtro de su tabla fuente que excluye ciertas filas y columnas, sino también un resumen de su tabla fuenre; por tanto, se necesita una cantidad considerable de procesamiento del SOBD para mantener la ilusión de la tabla virtual para las vistas de agrupación. Las vistas de agrupación pueden utilizarse en consultas igual que Olras vistas más sencillas. Sin embargo, las vistas de agrupación no pueden actualizarse. El motivo debería ser evidente a partir del ejemplo. ¿Qué significaría actualizar el tamaño medio de los pedidos del representante número lOS? Como cada fila de una vista de reunión corresponde a un grupo de filas de las tablas fuente, y las columnas de las vistas de agrupación suelen contener datos calculados, no hay manera de traducir la solicitud de actualización a las filas de las tablas fuenle. Las vistas de agrupación, por tanto, actúan como vistas sólo de lectura, que pueden participar en consultas pero no en actualizaciones. Las vistas de agrupación también están sometidas a las restricciones de SQL respecto a las funciones de columna anidadas. Recuérdese del Capítulo 8 que las funciones de columna anidadas, corno: MIN (HIN (A))
no son legales en las expresiones de SQL. Aunque las vistas de agrupación ocultan del usuario las funciones de columna en su lista de selecci6n, el SGBD sigue teniendo información sobre ellas y hace que se cumpla ]a restricción. Considérese este ejemplo:
Para cada oficina de ventas muéstrese el rango de tamaños promedio de los pedidos de todos los representantes que trabajan en esa oficina. SELECT FROH WHERE GROUP
OFICINA_REP, MIN(PROMEDIO) , MAX(PROMEDIO) REPRESENTANTES. PEDIDos_paR_REPRESENTANTE NUM_EMPL : QUIEN BY OFICINA_REP
Error:
Funciones de columna anidadas
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 función de columna. La consulta «verdadera» que se solicita a SQL es: SELECT OFICINA_REP, MIN(AVG(IMPORTE»), FROM REPRESENTANTES, PEDIDOS
MAX{AVG(IMPORTE))
412
SOL. Manual de referencia
Capítulo 14: Vistas
413
GROUP BY NOMBRE_REP, EMPRESA
WHERE NUM_EMPL = REP GROUP BY REP
GROUP BY OFICINA_REP
Esta consulta es ilegal debido a !as dos cláusulas GROUP BY y las funciones de columna anidadas. Por desgracia. como muestra este ejemplo, una instrucción SELECT agrupada perfectamente razonable puede, de hecho, provocar un error si una de las tablas fuente resulta ser una vista de agrupación. No hay m'UJcra de prever
esta situación; sólo hay que comprender el motivo del error cuando SQL]o comunique.
NOMBRE_REP
EMPRESA
Bruno Arteaga Bruno Arteaga Daniel Ruidrobo Daniel Ruidrobo Daniel Ruidrobo León Freire León Freire León Freire
Vistas de reunión Uno de los motivos más frecuentes de empleo de las vistas es la simplificación de las consultas a varias tablas. Al especificar una consulta a dos o tres tablas en la definición de la vista. se puede crear una vista de reunión 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, exigirían una reunión de dos o tres tablas cada una. Por ejemplo. supóngase 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 números de cliente ni de empleado. En vez de eso, le gustaría poder utilizar una versión de la tabla PEDIDOS que tuviera nombres en lugar de números. A continuación se ofrece una vista que satisface las necesidades de Samuel:
Obsérvese que esta consulta es una instrucción SELEeT de una sola tabla, que es considerablemente más sencilla que la instrucción 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 fácil generar un informe de los pedidos de mayor tamaño, que muestra quiénes los formularon y quiénes los tramitaron, con esta consulta a la vista:
Mostrar los pedidos actuales de mayor tamaño, ordenados por impone. SELECT FROM WHERE aRDER
EMPRESA, IMPORTE, NOMBRE_REP INFO_PEDIDOS IMPORTE> 20000.00 BY IMPORTE DESC
EMPRESA
Esta vista viene definida por una reunión de tres tablas. Al igual que con las vistas de agrupación, el procesamiento necesario para crear la ilusión de una tabla virtual para esta vista es considerable. Cada fila de la vista se obtiene de una combinación de una fila de la tabla PEDIDOS. una fila de la tabla CLIENTES y una fila de la tabla REPRESENTANTES. Aunque tiene una definición relativamente compleja, esta vista puede ofrecer algunas ventajas reales. A continuación se ofrece una consulta a la vista que genera un infonne de los pedidos. agrupados por representantes:
Mostrar los pedidos totales actuales de cada empresa por representante. SELECT NOMBRE_REP, EMPRESA, FROM INFO_PEDIDOS
León Freire Samuel Clavel Neus AzcArate Bruno Arteaga Tomás Saz Daniel Ruidrobo
La vista hace más facd comprobar lo que ocurre en la consulta que si se expresara en la reunión 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 más de trabajo para tratar la consulta a la vista. Sin embargo, para el usuario humano de la base de datos. resulta mu-
414
SOL. Manual de referencia
Capítulo 14: Vistas
eho más sencillo escribir y comprender la consulta a una sola tabla que hace referencia a la vista.
415
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
Actualización 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, considérese nuevamente la vista RE PESTE, definida anteriormente en este capítulo:
No existe una correspondencia biunívoca 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 sólo lectura. Las vistas RE PESTE y PEDIDos_paR_REPRESENTANTE son dos ejemplos extremos en cuanto a la complejidad de sus definiciones. Hay vistas más 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 investigación sobre las bases de datos relacionales a lo largo de los años.
Crear una vista que muestre los representantes de la región 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 inserción de una fila en esta vista; significa que la fila nueva debe insertarse en la tabla REPRESENTANTES subyacente de la que se deriva. También tiene sentido eliminar una fila de la vista REPESTE; eliminaría la fila correspondiente de la tabla REPRESENTANTES. Finalmente, tiene sentido la actualización de una fila de la vista REPESTE; actualizaría la fila correspondiente de la tabla REPRESENTANTES. En cada caso, la acción 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, considérese la vista de agrupación PEDIDOS_POR_REPRESENTANTE, tal y como se definió anteriormente en el apartado «Vistas de agrupación»:
Ista REPRESENTANTES NUM EMPL NOMBRE Vista REPESTE NUM
UPDATE DELETE INSERT
Figura 14.5.
EMPL NOMBRE 105 109 106 104 101 103
Bruno Arteaga Mana JlInenez _ Samuel Clavel Bernardo Sanchez Damel RUldrobo Pablo Cruz -
UPDATE
~INSERT
105 109 102 106
ID' 101 110 108 103 107
Bruno Arteaga María Jiménez Susana Santos Samuel Clavel Bernardo sánchez Daniel Ruidrobo Tomás Saz León Freire Pablo Cruz Neus Azcárate
Actualizaciones de vistas y el estándar ANSI/ISO
ba~
El estándar ANSI/ISO de SQLI especifica las vistas de las de datos que proclaman su cumplimiento del estándar que deben ser actualizables. Según el estándar, 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 cláusula FROM sólo 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 selección debe ser una referencia de columna sencilla; la lista se selección no puede contener expresiones, columnas calculadas ni funciones de columna. • La cláusula WHERE no debe incluir ninguna subconsulta; sólo pueden aparecer condiciones de búsqueda sencillas fila a fila. • La consulta no debe incluir ninguna cláusula GROUP BY ni HAVING.
EDAD 37 31 46 52 33
45 41 62 29 49
I(
If
El concepto fundamental tras estas restricciones es más 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-
Actualización de datos mediante una vista.
1
416
Capítulo 14: Vistas
SOL. Manual de referencia
Comprobación de las actualizaciones en las vistas
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 términos de la tabla fuente.
(CHECK OPTION) Si se define una vista mediante una consulta que incluye una cláusula WHERE, sólo las filas que cumplan la condición de búsqueda son visibles en la vista. Puede que otras filas estén 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 capítulo, sólo 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 estándar SQLl sobre las actualizaciones de las vistas son muy restrictivas. Muchas vistas se pueden actualizar en teoría, pero no satisfacen todas las restricciones. Además, algunas vistas pueden admitir algunas de las operaciones de actualización, 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 actualización de las vistas que resultan considerablemente más permisivas que el estándar de SQL1. Por ejemplo, considérese esta vista:
Crear una vista que muestre los representantes de la región Este. CREATE VIEW REPESTE AS SELECT FROM REPRESENTANTES WHERE OFICINA_REP IN (11,
SELECT NUM_EMPL, VENTAS, FROM REPRESENTANTES
CUOTA,
(NUM_EMPL, VENTAS, DIFERENCIA) AS (VENTAS - CUOTA)
12, 13)·
Se trata de una vista actualizable para la mayor parte de las implementaciones comerciales de SQL Se puede añadir un nuevo representante con esta instrucción IHEH:
Crear una vista que muestre las ventas, la cuota y la diferencia entre las dos para cada representante. CREATE VIEW RENDIMIENTO_REPRESENTANTES
417
(
INSERT INTO RE PESTE (NUM_EMPL, NOMBRE, OFICINA_REP, VALUES (113, 'Jacobo Rent', 11, 43, 0.00)
EDAD,
VENTAS)
CUOTA,
El SGBD añadirá la fila nueva a la tabla REPRESENTANTES subyacente, y la fila será visible mediante la vista REPESTE. Pero considérese lo que ocurre cuando se añade un representante nuevo con la instrucción INSERT:
El estándar SQL1 prohíbe las actualizaciones de esta vista, ya que su cuarta columna es una columna calculada. No obstante, obsérvese 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. Además, DB2 permite las operaciones UPDATE de las columnas NUM_EMPL, VENTAS Y CUOTA porque se obtienen directamente a partir de la tabla fuente. Sólo la columna DIFERENCIA no se puede actualizar. DB2 no permite la instrucción INSERT para la vista porque la inserción de valores en la columna DIFERENCIA no tendría ningún sentido. Las reglas concretas que determinan si una vista puede actualizarse varían de una marca de SGBD a otra, y suelen ser bastante detalladas. Algunas vistas, como las basadas en consultas de agrupación, no pueden actualizarse en ningún SGBD porque las operaciones de actualización, 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 estándar SQL2 reconoció esto e incluye una definición más amplia de las vistas actualizables junto con una gran posibilidad de variación entre las marcas de SGBD. La mejor manera de aprender sobre la posibilidad qe actualización en cada SGBD es consultar el manual de usuario o experimentar con diferentes tipos de vistas.
Se trata de una instrucción 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 recién insertada no cumple la condición de búsqueda de la vista. El valor (21) de su columna OFICINA_REP especifica la oficina de León, que está en la región Oeste. En consecuencia, si se ejecuta esta consulta inmediatamente después de la instrucción INSERT: SELECT NUM_EMPL, FROM RE PESTE
NOMBRE,
OFICINA_REP
NUM_EMPL NOMBRE 105 109 106 104 101 103
1
Bruno Arteaga María Jiménez Samuel Clavel Bernardo Sánchez Daniel Ruidrobo Pablo Cruz
OFICINA_REP 13
11 11 12 12 12
418
SOL. Manual de referencia
Capítulo 14: Vistas
la fila recién añadida no aparece en la vista. Lo mismo ocurre si se modifica la asignación de oficina de alguno de los representantes que se hallan en la vista. Esta instrucción UPDATE:
ción. Esta opción se aplica cuando se crea la vista, y su definición no se basa en una tabla subyacente, sino en una o más vistas. Las definiciones de estas vistas subyacentes podrían, a su vez, basarse en otras vistas, etc. Cada una de las vistas subyacentes podrían tener especificada la opción de comprobación. Si se crea la nueva vista WITH CASCADED CHECK OPTION, cualquier intento de actualizarla hace que el SGBD descienda por toda la jerarquía de definiciones de vistas en la que se basa y procese la opción de comprobación para cada vista en la que esté especificada. Si se crea la nueva vista WITH LOCAL CHECK OPTION, el SOBD sólo verifica esa vista; las vistas subyacentes no se verifican. El estándar SQL2 especifica CASCADED como valor predeterminado, si se emplea la cláusula WITH CHECK OPTION sin especificar LOCAL ni CASCADEO. Probablemente quede claro de esta discusión que la opción de comprobación puede añadir una sobrecarga . . i~nificativa a las operacionéSIÑsERT y UPDATE, especialmente si se actualizan \ islas definidas con base en varias capas de definiciones de vistas subyacentes. No obstante, la opción de comprobación desempeña un papel importante en la garantía de la integridad de la base de datos. Después de todo, si se pretendía aplicar la actualización a datos no visibles mediante la vista o intercambiar de hecho una fila de datos entre dos vistas, lógicamente, la actualización 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 opción de comprobación. Evita que las modificaciones hechas a través de la vista afecten a datos que, para empezar, no están accesibles para el usuario.
UPDATE RE PESTE
SET OFICINA_REP = 21 WHERE NUM_EMPL = 104
modifica una de las columnas de la fila de Bernardo Sánchez 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
OFICINA_REP
NUM_EMPL NOMBRE 105 Bruno Arteaga
13
María Jiménez Susana Santos Samuel Clavel
11 21 11 21 12
109 102 106 104 101 110 108 103 107 114
Bernardo Sánchez Daniel Ruidrobo Tomás Saz León Freire Pablo Cruz Neus Azcárate Francisco Ruiz
NULL
21 12 22 21
Eliminación de vistas
El hecho de que las filas desaparezcan de la vista como consecuencia de una instrucción INSERT o UPDATE resulta desconcertante, como mínimo. 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 verificación de integridad para las vistas creando la vista con una opción de comprobación (Check option). La opción de comprobación se especifica en la instrucción CREATE VIEW, como puede verse en esta redefinición de la vista REPESTE: CREATE VIEW SELECT FROM WHERE WITH CHECK
(11,
12,
(DROP VIEW)
Recuérdese que el estándar SQLI trataba al lenguaje de definición de datos de SQL como una especificación estática de la estructura de las bases de datos, incluidas sus tablas y sus vistas. Por este motivo, el estándar SQLl no ofrecía la posibilidad de descartar las vistas cuando ya no se necesitaban. No obstante, todas las marcas principales de SGBD ofrecen esta posibilidad desde hace algún 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 también utilizaban la instrucción DROP TABLE para descartar vistas. Otras implementaciones de SQL ofrecían una instrucción OROP VIEW independiente. El estándar SQL2 fonnalizó el soporte del descarte de las vistas mediante la instrucción OROP VIEW. También ofrece el control detallado de lo que sucede cuando los usuarios intentan descartar una vista y la definición de otra vista depende de ella. Por ejemplo, supóngase que se han creado dos vistas de la tabla REPRESENTANTES mediante estas dos instrucciones CREATE VIEW:
REPESTE AS REPRESENTANTES OFICINA_REP IN OPTION
419
13)
Cuando se solicita la opción de comprobación para una vista, SQL comprueba de manera automática cada operación INSERT y UPDATE de la vista para asegurarse de que las filas resultantes cumplen el criterio de búsqueda de la definición de la vista. Si una fila insertada o modificada no cumpliera la condición de búsqueda, la ... y la operación no se llevaría a cabo. instrucción INSERT o UPDATE fa El estándar SQL2 especifica un perfeccionamiento más para la opción de comprobación: la opción de aplicación CASCAOED o LOCAL de la opción de comproba-
CREATE VIEW RE PESTE AS SELECT PROM REPRESENTANTES WHERE OFICINA_REP IN
j
(11,
12, 13)
420
Capítulo 14: Vistas
SOL. Manual de referencia
CREATE VIEW REPNAVARRA AS SELECT FROM REPESTE
WHERE OFICINA_REP :
11
A modo de ejemplo, se define la vista REPNAVARRA e~ términos de la vista aunque también se podría haber definido en términos de la tabla subyacente. Según el estándar SQL2, la siguiente instrucción DROP VIEW elimina de la base de datos las dos vistas: RE PESTE,
DROP VIEW RE PESTE CASCADE
La opción CASCADE indica al SGBD que no sólo debe eliminar la vista citada, sino también todas las vistas que dependan de su definición. Por el contrario, esta instrucción OROP VIEW: DROP VIEW EASTREPS RESTRICT
falla con un mensaje de error, ya que la opción RESTRICT indica al SOBD que s610 debe eliminar la vista si ninguna otra depende de ella. Esto ofrece una precaución añadida contra los efectos secundarios no deseados de las instrucciones DROP VIEW. El estándar SQL2 exige que se especifique RESTRICT o CASCADE. Pero muchos productos comerciales· de SQL admiten una versión de la instrucción DROP VIEW, sin necesidad de que se especifique una opción de manera explícita, en aras de la compatibilidad con versiones anteriores de sus productos distribuidas antes de la publicación del estándar SQL2. El comportamiento concreto de las vistas dependientes depende, en este caso, de cada marca de SGBD.
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 físicamente en la base de datos: se obtienen de datos reales de las tablas fuente subyacentes. Si la definición 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 reunión sencilla basada en relaciones de claves externas), resulta bastante sencillo para el SGBD la traducción de las operaciones de la base de datos sobre la vista en operaciones sobre las tablas subyacentes. En esta situación, el SGBD llevará a cabo la traducción sobre la marcha, operación a operación, como procesa las consultas o actualizaciones de la base de datos. En general, las operaciones que actualizan la base de datos a través de una vista (operaciones INSERT, UPDATE o DELETE) se ejecutan siempre de esta manera -traduciendo la operación en una o varias operaciones sobre las tablas fuente. Si la definición de la vista es más 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
421
SGBD lleva a cabo la consulta solicitada contra la tabla temporal para obteñer 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 materialización. Evidentemente, la materialización del contenido de las vislas puede ser una operación que suponga una elevada sobrecarga. Si la carga de trabajo habitual de una base de dalaS contiene muchas consultas que exigen la materialización 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 automática\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 operación 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
SELEC" FROH vista
L
~
P".',una tabla lemporal Crear que contenga los datos
!'i¡F~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.
\
Materialización de vistas para el procesamiento de consultas.
422
SOL. Manual de referencia
Capítulo 14: Vistas
• 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 más tablas (vistas de reunión). • Se puede hacer referencia a las vistas en las instrucciones SELECT, INSERT, DELETE o UPDATE igual que a las tablas auténticas. Sin embargo, las vistas más complejas no pueden actualizarse; se trata de vistas de sólo 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 rélativamente reducida.
SGBD Tabla base UPDATE
e'
SELECT FROM
¿\o~
Vista
vista
materializada
'3\í\''3 \,,0\\.'0
Actualizacione
1
INSERT
UPDATE
ActualizaCio nes
Paso 1: Resultados de la consulta
Figura 14.7.
423
Responder a la consulta
a partir de Jos datos de la vista materializada
Operación 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 definición 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 más útiles cuando el volumen de actualizaciones de los datos subyacentes es relativamente pequeño 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:
I
i
J
CAPíTULO
15
Seguridad en SOL
d~ases
segurj~
Cuando se confían los datos a un sistema de gestión de datos, la dad de los datos almacenados es una preocupación 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 producción típicas 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 permitírseles 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 permitírseles el empleo de programas de aplicación que actualicen esas tablas. El esquema de seguridad de SQL descrito en este capítulo ofrece estos tipos de protección para los datos de las bases de datos relacionales.
Conceptos de seguridad en SOL La implementación 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 algún usuario. El SGBD autoriza o prohíbe cada acción en función del usuario que realiza la solicitud.
425
426
SOL. Manual de referencia
Capítulo 15: Seguridad en SOL
• Objetos de la base de datos. Elementos a los que se puede aplicar la protección de la seguridad de SQL. La seguridad suele aplicarse a las tablas y a las vistas, pero también se pueden proteger otros objetos, como los formularios, los programas de aplicación 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.
427
Al establecer el esquema de seguridad de una base de datos se utiliza la instrucción GRANT de SQL para especificar los usuarios que tienen cada privilegio sobre cada objeto de la base de datos. Por ejemplo, a continuación se muestra una instrucción 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
OFICINAS.
GRANT SELECT, INSERT ON OFICINAS TD SAMUEL
(
I
La instrucción GRANT especifica una combinación de identificador de usuario objeto (la tabla OFICINAS) y privilegios (SELECT e INSERT). Una vez concedidos, los privilegios pueden cancelarse posteriormente con la instrucción (SAMUEL),
REVOKE:
Departamento de procesamiento
~i~
SELECT,
UPDATE
Retirar los privilegios concedidos anteriormente a Samuel Clavel. Departamento de cuentas
~~
INSERT,
\. algunas \columnas
aJg~n/ fila¿
LEW
SE~
Tabla OFICINAS
t!
Acceso completo \ a todos los dalas ' \ (
Samuel Clavel VP ventas
Figura 15.1.
algUnaS~
'-J'-_-"--_-' filas
Acceso
comPleto~i~
a todos los datos
Las instrucciones GRANT y REVOKE se describen con detalle más adelante en este capítulo, en los apartados «Concesión de privilegios» y «Retirada de privilegios».
h
ANTES .~. SELECT
[]lITID Disponible para todos los usuarios
León Freire, jefe de la oficina de León
Tra~b~la=RE=p~RE=S=ENT~ 1-
Tabla CLIENTES
INSERT
ON OFICINAS FROM SAMUEL
SELECT
Acceso; \. algunas SELECT/ completo \columnas I Tabla PEDIOOS
REVOKE SELECT,
Bernardo Sánchez, jefe de la oficina de Castellón
~
Gonzalo Walker VP marketing
Esquema de seguridad para la base de datos de ejemplo.
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 corazón de la seguridad de SQL. Cada instrucción 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 ejecución de la instrucción o la prohibe. En las bases de datos de producción, 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 propósito especial (por ejemplo, las diseñadas para incrustarse dentro de las aplicaciones o de los sistemas de propósito 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 práctica, las restricciones a los nombres que pueden escogerse como identificadores de usuario varían de implementación a implementación. El estándar SQLl permitía identificadores de usuario de hasta dieciocho caracteres y exigía que fueran nombres de SQL válidos. En algunos sistemas SGBD de centrales de
428
Capítulo 15: Seguridad en SOL
SOL Manual de referencia
rio. No obstante, la práctica más habitual es asignar un identificador de usuario diferente a cada persona, y la mayor parte de los SGBD basados en SQL utilizan el término identificador en su documentación.
computación, los identificadores de usuario no pueden tener más 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 típicos. Obsérvese que a todos los usuarios del departamento de procesamiento de pedidos puede asignárseles el mismo identificador de usuario, ya que han de tener los mismos privilegios en la base de datos. El estándar ANSI/ISO de SQL utiliza el término identificador de autorización en lugar de identificador de usuario, y este término se encontrará ocasionalmente en otra documentación sobre SQL. Técnicamente, identificador de autorización es un término más 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 producción, los identificadores de autorización pueden asociarse con programas y grupos de programas, más que con usuarios humanos. En cada una de estas situaciones, identificador de autorización es un término más exacto y que lleva a menos confusión que identificador de usua-
Departamento de procesamiento de pedidos
Departamento de cuentas
[~~~J
[JI]
Identificador de usuario: USUARIOPP
Identificador de usuario: USUARIOCU
Directores de oficina
Vicepresidentes
~
~
~
Bernardo Sánchez
Samuel Clavel VP ventas
Gonzalo Walker VP marketing
Identificador de usuario: LEÓN
Identificador de usuario: BERNARDO
Identificador de usuario: SAMUEL
Identificador de usuario: GONZALO
Figura 15.2.
Autenticación de usuarios
El estándar SQL especifica que los identificadores de usuario proporcionan la seguridad de la base de datos; no obstante, el mecanismo concreto para la asociación entre Jos identificadores de usuario y las instrucciones de SQL es ajeno al ámbito del estándar, 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 instrucción. 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 generación de informes para que se ejecute cada tarde a una hora predeterminada, para lo cual hay que establecer el identificador de usuario, situación en la)que no hay ningún usuario humano. Finalmente, hay que establecer cómo 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 sesión de la base de datos. En SQL interactivo la sesión comienza cuando se inicia el programa de SQL interactivo, y dura hasta que se sale del programa. En los programas de aplicación que utilizan SQL para programación, la sesión comienza cuando el programa de aplicación conecta con el SGBD, y concluye cuando termina el programa de aplicación. Todas las instrucciones de SQL utilizadas durante la sesión se asocian con el identificador de usuario especificado para la sesión. Generalmente hay que proporcionar tanto un identificador de usuario como la contraseña asociada al comienzo de cada sesión. El SGBD comprueba la contraseña 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 contraseñas son frecuentes en la mayor parte de los productos de SQL, las técnicas concretas empleadas. para especificar el identificador de usuario y la contraseña varían de un producto a otro. Algunas marcas de SGBD, especialmente las que están disponibles en muchas plataformas de sistemas operativos diferentes, implementan su propia seguridad de identificador de usuario y contraseña. Por ejemplo, cuando se utiliza el programa de SQL interactivo de Oracle, denominado SQLPLUS, hay que especificar un nombre de usuario y la contraseña asociada en el comando que inicia el programa, como puede verse a continuación:
~
León Freire
429
Asignación de identificadores de usuario para la base de datos de
ejemplo.
SQLPLUS SANTI/TIGRE
--L
430
SOL. Manual de referencia
El programa interactivo de SQL de Sybase. denominado ISQL. también acepta un nombre de usuario y una contraseña, con este formato de comando: ISQL IUSER=SANTI /PASSWORD=TIGRE
En cada caso el SGBD valida el identificador de usuario (SANTI) y la contraseña (TIGRE) antes de comenzar la sesión 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 sesión en un sistema informático basado en UNIX, hay que proporcionar un nombre de usuario y una contraseña válidos 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 automática el nombre de usuario de UNIX y lo convierte en el identificador de usuario de lngres para esa sesión. Por tanto, no hace falta especificar un identificador de usuario y una contraseña diferentes. El SQL interactivo de DB2, que se ejecuta bajo MVSrrSO, utiliza una técnica parecida. El nombre de inicio de sesión de TSO se transforma automáticamente en el identificador de usuario de DB2 para la sesión de SQL interactivo. La seguridad de SQL también se aplica al acceso mediante programación a las bases de datos, por lo que el SGBD debe determinar y autentificar el identificador de usuario de cada programa de aplicación que intente tener acceso a la base de datos. Una vez más, las técnicas y reglas para el establecimiento del identificador de usuario varían de una marca de SGBD a otra. Para los programas de utilidades más utilizados, como los de introducción de datos o los de consulta, resulta frecuente que el programa pida al usuario el identificador de usuario y la contraseña al comienzo de la sesión, mediante un cuadro de diálogo en la pantalla. Para los programas más especializados o escritos a medida, el identificador de usuario puede resultar evidente a partir de la aplicación que hay que ejecutar y venir indicado en el programa. El estándar SQL2 también permite que los programas utilicen identificadores de autorización asociados con conjuntos específicos de instrucciones de SQL (denominados módulos), 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á abriéndose camino en las principales implementaciones de SQL. Las características concretas de la seguridad de SQL para los programas de acceso a la base de datos se describen en el Capítulo 17, que trata el SQL para programación.
Capítulo 15: Seguridad en SOL
431
Grupos de usuarios Las grandes bases de dalos de producción 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 idénticas de acceso a los datos y deben tener idénticos 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 administración 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 administración de la seguridad tediosa y susceptible de errores.
1
El esquema que se escoja depende de los equilibrios entre la base de datos concreta y la aplicación. 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 administración de los privilegios concedidos a los grupos de usuarios. No obstante, no forman parte del estándar y puede que los diseños de bases de datos que los utilicen no sean portables a otras marcas de SGBD. DB2 también 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 conexión a DB2 y se proporcione el identificador de usuario (conocido como identificador de autorización primario), DB2 busque de manera automática un conjunto de identificadores de usuario adicionales (conocidos como identificadores de autorización secundarios) que se puedan utilizar. Cuando DB2 comprueba posteriormente los privilegios, verifica los de todos los identificadores de autorización, tanto primarios como secundarios. En los grandes sistemas de lBM, los administradores de bases de datos de DB2 suelen configurar
432
SOL. Manual de referencia
los identificadores de autorización 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 añadirlos al mecanismo de identificadores de usuario.
Objetos de seguridad Las protecciones de la seguridad de SQL se aplican a objetos concretos contenidos en las bases de datos. El estándar 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 estándar SQL2 amplió las protecciones de seguridad para incluir otros objetos, incluidos los dominios y los conjuntos de caracteres definidos por el usuario, y añadió un nuevo tipo de protección 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 físicos 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 denegárselo 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 estándar SQLI especifica cuatro privilegios básicos 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 cláusula FROM de una instrucción 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 cláusula INTO de una instrucción INSERT.
Capítulo 15: Seguridad en SOL
433
• El privilegio DELETE permite eliminar filas de una tabla o vista. Con este privilegio se puede especificar la tabla o vista de la cláusula FROM d~ una instrucción 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 instrucción UPDATE. El privilegio UPDATE puede restringirse a columnas concretas de la tabla o vista, permitiendo actualizaciones de esas columnas pero impidiéndolas en el resto. Prácticamente todos los productos comerciales de SQL albergan estos cuatro privilegios. Privifegios ampliados de SQL2
El estándar SQL2 amplió los privilegios básicos de SQLl en varias dimensiones. Añadió nuevas posibilidades a los privilegios INSERT y UPDATE de SQLl. Añadió 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. También añadió 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 ordenación 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. Supóngase 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 contratación. El director de recursos humanos debe proporcionar el número de empleado, el nombre y demás información. Pero debería 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 demás columnas (como VENTAS y CUOTA) de los empleados recién insertados tendrán inicialmente el valor NULL. Con el privilegio UPDATE sobre las demás columnas, el VP de ventas puede definir la cuota correspondiente. Sin la posibilidad de especificar estos privilegios sobre columnas concretas habría que relajar las restricciones de acceso a las columnas o definir vistas extrañas de la tabla simplemente para restringir el acceso. El estándar SQL2 no permite que se aplique el privilegio SELECT a columnas concretas, como las nuevas posibilidades INSERT y UPDATE; hay que seguir especificándolo para toda la tabla. Teóricamente, 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
Capítulo 15: Seguridad en SOL
SOL. Manual de referencia
cretas puede ser un enfoque mucho más directo. Conserva más sencilla la estructura de la base de datos (menos definiciones de vistas) y concentra el esquema de seguridad más 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 estándar SQL2 incluye una nota que indica que se pretende considerar también esta posibilidad para futuras actualizaciones del estándar. El nuevo privilegio REFERENCES de SQL2 trata con un problema de seguridad de SQL más sutil planteado por las posibilidades de las claves externas y las restricciones de comprobación de SQL2. Empleando la base de datos de ejemplo como modelo, supóngase que un empleado tiene la posibilidad de crear una tabla nueva en la base de datos (por ejemplo, una tabla que contenga información sobre los productos nuevos) pero no tiene acceso a la información sobre empleados de la tabla REPRESENTANTES. Podría suponerse que, dado este esquema de seguridad, no hay manera· de que determine los números de empleado utilizados ni si se ha contratado a algún 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. (Recuérdese que esto significa que los únicos valores legales para esta columna son los valores de la clave primaria de la tabla REPRESENTANTES --es decir, números de empleado válidos-.) 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 indicarán al empleado que ha descubierto un número de empleado válido; las que fallen, representarán números de empleado no válidos. Una tabla nueva definida con una restricción de comprobación en una columna puede crear problemas todavía más serios. Por ejemplo, supóngase que el empleado intenta ejecutar esta instrucción CREATE TABLE: CREATE TABLE XYZ (PROBAR DINERO, CHECK ((5ELECT CUOTA FROM REPRESENTANTES WHERE TITLE = 'VP Ventas') BETWEEN 400000 AND 500000))
Debido a la restricción de la columna vinculada con un valor de la tabla REsi esta instrucción 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 estándar 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 sólo 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 restricción de comprobación, como en los ejemplos anteriores) si
435
tiene el privilegio REFERENCES para esa columna. En las bases de datos que todavía no implementan el privilegio REFERENCES pero admiten claves externas o restricciones de comprobac~ón, se utiliza a ve_ces con esta función el privilegio SELECT. Finalmente, el estándar 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 ordenación 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 definición de columna de ese tipo. Estos privilegios están dirigidos, sobre todo, a la simplificación de la administración 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 instrucción 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 demás usuarios no tienen inicialmente ningún privilegio sobre la tabla recién creada. Si hay que concederles acceso a la tabla, hay que otorgarles privilegios de manera explícita, empleando la instrucción GRANT. Cuando se crea una vista con la instrucción 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 automática. Para cada uno de los demás privilegios (INSERT, DELETE y UPDATE), el SOBO sólo otorga el privilegio sobre la vista si ya se tiene ese mismo privilegio sobre todas las tablas fuente de la vista. Otros privilegios
PRESENTANTES,
Muchos productos comerciales de SOBO ofrecen privilegios adicionales sobre tablas y vistas, además de los privilegios básicos 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 instrucción ALTER TABLE para modificar la definición de esa tabla; los usuarios con el privilegio INDEX pueden crear un índice para esa tabla con la instrucción CREATE INDEX. En las marcas de SOBO que no admiten los privilegios ALTER e INDEX, sólo el propietario puede utilizar las instrucciones ALTER TABLE Y CREATE INDEX.
436
SOL. Manual de referencia
Capítulo 15: Seguridad en SOL
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.
~ 1J O
SELECT Vista INFOREP
Además de las restricciones al acceso a las tablas proporcionadas por los privilegios de SQL, las vistas también desempeñan un papel fundamental en la seguridad de SQL. Mediante una definición 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, supóngase que se desea hacer cumplir esta regla de seguridad en la base de datos de ejemplo:
N!Jl'l DlP¡'
'" ". '" '" lO' ",,1'
/
",,/"
El personal del departamento de cuentas debe poder recuperar los números de empleado, los nombres y los números de oficina de la tabla REPRESENTANTES, pero no deben tener disponibles los datos de ventas ni de cuotas.
OFICINA_REP
y·concediendo 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 también son efectivas para hacer que se cumplan las reglas de seguridad, como la siguiente:
RIOCU,
Los jefes de ventas de cada región deben rener acceso completo a los dalOs de de los representantes asignados a esa región.
REPRESENTANTES
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 más 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 agrupación, se puede conceder a los REPOESTE,
/,/'" //'
NUlLEMPL
lO'
Bernardo
".
106
sa:md eh".}
'" '" '"
Bernardo Sbehz oa..~iel llui4robo
su
LeOa Freire
Pabl
~nche:¡;
NOLL
Pablo Cruz Neus Azcáute
/~'
",',/,;'
///
H
",//
/"',"" /",/
PUESTO
Representante Representanta
21 Representllnta 11
VI'
ventn
12 Jefe vntas 12 12 21 ~C
22
Sin acceso
,,/,....
, 13 11
x
/'
,;/"
",;"';"/ ,;"",,,,,/.
" "'"33 "n .,""
22
-
...-,,//
I,~ OnCIlIA RE P
NOMBRE
102
102 lO'
110
Daniel Ruidrobo Tom!S Su León Freíre
",,'
~/
Aneaga l\./lria Ji..onn SUsana santo.
Toais
Susana santOS samu"l Clavel
,.",'"
Bruno
110
liada Jl_M:l
,,,//
/",'"
./,,'
,,/"
13
11 21 11 12 12 12 21
lOO
/,/'
/
OFICINA...REP
~,
Bruno Arteaga
102 106
'"
/
,,/'/
CREATE VIEW INFOREP AS SELECT NUM_EMPL. NOMBRE, FROM REPRESENTANTES
\
USUARlOOCU
Las vistas y la seguridad en SOL
Esta regla de seguridad se puede implementar definiendo una vista de la manera siguiente:
Empleo de vistas para restringir el acceso a columnas.
usuarios acceso a datos resumidos, pero no a las fijas detalladas de la tabla subyacente. Las vistas también pueden combinar datos de dos o más tablas, proporcionando exactamente los datos que necesita un usuario concreto y negándole el acceso al resto de los datos. La utilidad de las vistas para la implementación de la seguridad de SQL queda limitada por las dos restricciones fundamentales ya descritas en el Capítulo 14: • Restricciones de actualización. El privilegio SELECT puede utilizarse con vistas de sólo lectura para limitar la recuperación de datos, pero los privilegios
438
SOL. Manual de referencia
Capítulo 15: Seguridad en SOL
V·IS t a R EPESTE
105 Bruno Arteaga
SELECT
lO' Karía Jiménez lO' Samuel Clavel
INSERT DELETE
104 Bernardo Sánchez 101 Daniel Ruidrobo 103 Pablo Cruz
ALL PRIVILEGES - - - - - - - - - - - - ' USAGE O N ¡ D O M A I N nombre-dominio CHARACTER SET no~~~~rt~e~O' COLLATION nombre-secuencia TRANSLATION nombre-traducción
')
lO' María Jiménez
102 Susana Santos lO' samuel Clavel 104 Bernardo SAnchez 101 Daniel Ruidrobo ~ 110 TaDás Saz 108 León Freire 103 Pablo Cruz 107 Neus Azcárate
/ I
,
'-------, -------'
I
1>
l'
// /{ / / 1 11 1 11 11 11
TO
J
---nno~~"-"'~'¡°ITT L.=.::BLI:..=.J
,
5/
Figura 15.5. Figura 15.4.
ON nombre-fabla
UPDATE---I---'-_.inombre-eO!Umnar-I
'y"v.,
IS
SELECT----¡
DELETE~
;>-. \\ ' Tabla REPRESENTANTES \ \ \\ NmLEMPL NOMBRE , ' \ \ \ 105 Bruno Arteaga
Sin acceso
.---r----------...
1-- GRANT
,,
NUM EMPL NOMBRE
439
-
•
WrTH GRANT OPTION
Diagrama sintáctico de la instrucción GRANT.
Empleo de vistas para restringir el acceso a las filas.
Y UPDATE carecen de sentido para estas vistas. Si un usuario tiene que actualizar los datos visibles en una vista de sólo 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 añadir 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
Concesión de privilegios (GRANT) La instrucción GRANT básica, 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 instrucción 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 instrucción GRANT incluye una lista específica 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.
La instrucción GRANT que puede verse en el diagrama sintáctico cumple el estándar ANSIIISO de SQL. Muchas marcas de SGBD siguen la sintaxis de DB2 para la instrucción GRANT, que es más flexible. La sintaxis de DB2 permite especificar una lista de identificadores de usuario y una lista de talas, lo que hace más sencilla la concesión simultánea de muchos privilegios. A continuación 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
Los usuarios de cuentas deben poder recuperar los datos de los clientes y añadir clientes nuevos a la tabla CLIENTES, pero los usuarios de procesamiento de pedidos sólo deben tener acceso de lectura. GRANT SELECT, INSERT ON CLIENTES TO USUARIOCU
440 GRANT
SOL. Manual de referencia
Capítulo 15: Seguridad en SOL
SELECT
Los usuarios de procesamiento de pedidos deben poder modificar el nombre de las empresas y las asignaciones de representantes.
ON CLIENTES TO USUARIOPP
GRANT UPDATE (EMPRESA, ON CLIENTES TO USUARIOPP
Permitir que Samuel Clavel inserte o elimine oficinas. GRANT INSERT, DELETE ON OFICINAS Tü SAMUEL
REP_CLI)
Si se omite la lista de columnas, el privilegio se aplica a todas las columnas de la tabla o vista, como en este ejemplo:
Por comodidad, la instrucción GRANT ofrece dos atajos que se pueden utilizar al conceder muchos privilegios o al concedérselos 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 instrucción GRANT concede a Sarnuel Clavel, vicepresidente de ventas, acceso completo a la tabla REPRESENTANTES:
Conceder todos los privilegios sobre la tabla Clavel.
441
REPRESENTANTES
Los usuarios de cuentas deben poder modificar cualquier información sobre ..-........ los clientes. GRANT UPDATE ON CLIENTES TO USUARIOCU
a Samuel
GRANT ALL PRIVlLEGES ON REPRESENTANTES TO 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 instrucción 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
Obsérvese que esta instrucción GRANT concede acceso a todos los usuarios autorizados presentes y futuros; comúnmente, no sólo a los identificadores de usuario conocidos por el SGBD. Esto elimina la necesidad de conceder privilegios de manera explícita a los usuarios nuevos a medida que son autorizados.
Privilegios sobre columnas El estándar SQLI permite conceder el privilegio UPDATE para columnas individuales de una tabla o vista, y el estándar SQL2 permite también una lista de columnas para los privilegios IN8ERT y REFERENCE8. Las columnas se relacionan tras la palabra UPDATE, INSERT o REFERENCES, y encerradas entre paréntesis. A continuación puede verse una instrucción GRANT que permite al departamento de procesamiento de pedidos actualizar sólo las columnas del nombre de la empresa y del representante asignado de la columna CLIENTES: .
El estándar 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 práctica, esto no supone una restricción seria. Para conceder acceso a columnas concretas, primero hay que definir una vista de la tabla que sólo incluya esas columnas, y luego conceder el privilegio SELECT sólo 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 demás sencillas. Por este motivo, algunas marcas de SGBD permiten una lista de columnas para el privilegio SELECT. Por ejemplo, la siguiente instrucción GRANT es legal para las marcas de SGBD Sybase, SQL Server e Informix: LECT;
Conceder a los usuarios de cuentas acceso de sólo lectura a las columnas del número de empleado, nombre y ventas de la tabla REPRESENTANTES. GRANT SELECT (NUM_EMPL, ON REPRESENTANTES TO USUARlOCU
NOMBRE, OFICINA_REP)
"
La instrucción GRANT elimina la necesidad de la vista INFOREP definida en la Figura 15.3 y, en la práctica, puede eliminar la necesidad de muchas vistas de las bases de datos de producción. 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 estándar ANSIIlSO ni por los productos SQL de IBM.
Transmisión 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
SOL. Manual de referencia
Capítulo 15: Seguridad en SOL
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~dérense 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 León, León Frelre, permiso para utilIzar la vista REPOESTE con esta instrucción GRANT:
@GRANT WITH GRANT DPTION
SAMUEL
LEÓN
GAANT SELOCT ON RE PO ESTE TO LEON
Se desea averiguar lo que ocurre si León 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 instrucción GRANT anterior no puede concederle el prIVilegIO necesarIo. Sólo Samuel Clavel puede conceder ese privilegio, ya que es el propietario de la vista. Si Samuel desea concederle a León discreción sobre los usuarios que pueden utilizar la vista REPOESTE, puede utilizar esta variación de la instrucción GRANT anterior:
443
SUSANA
Figura 15.6.
Empleo de
GRANT
OPTION.
De manera alternativa, León podría crear una vista para Susana que sólo incluyera a los representantes de la oficina de León y concederles acceso a esa vista: CREATE VIEW REPLEON AS
GRANT ON TO WITH
SELECT REPOESTE LEON GRANT OPTION
Debido a la cláusula WITH GRANT OPTION, esta instrucción GRANT conlleva, junto con los privilegios especificados, el derecho a conceder esos privilegios a otros usuarios. León puede ahora escribir esta instrucción GRANT: GRANT SELECT ON REPOESTE TO SUSANA
que permite a Susana Santos recuperar datos de la vista REPOESTE. La Figura 15.6 ilustra oráficamente el flujo de privilegios, en primer lugar desde SamlJel a León, y lueg; de León a Susana. Debido a que la instrucción GRAN: escrita por León no incluía la cláusula 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.
SELECT FROM RE POESTE WHERE OFICINA = 21 GRANT ALL PRIVILEGES ON RE PLEON TO SUSANA
León 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 León no sólo 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 sólo se aplica a los privilegios concretos mencionados en la instrucción GRANT. Si se desea conceder ciertos privilegios con GRANT OPTION y otros sin esa opción, hay que utilizar dos instrucciones GRANT diferentes, como en el ejemplo siguiente:
León Freire debe poder recuperar, insertar, actualizar y eliminar datos de la tabla REPOESTE, y conceder permiso de recuperación para otros usuarios.
444
SOL. Manual de referencia
Capítulo 15: Seguridad en SOL
GRANT SELECT
Conceder y luego retirar algunos privilegios sobre la tabla
üN RE POESTE TO LEON WITH GRANT OPTION GRANT INSERT,
DELETE,
GRANT SELECT. INSERT, UPDATE ON REPRESENTANTES TO USUARIOCU, USUARIOPP
UPDATE
ON REPOESTE
Retirada de privilegios (REVOKE)
Primero se conceden los privilegios
En la mayor parte de las bases de datos basadas en SQL, los privilegios que se han concedido con la instrucción GRANT pueden retirarse con la instrucción REVOKE, que puede verse en la Figura 15.7. La instrucción REVOKE tiene una estructura que se asemeja bastante a la de la instrucción 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 instrucción REVOKE puede retirar todos o parte de los privilegios que se hayan concedido previamente a un identificador de usuario. Por ejemplo, considérese esta secuencia de instrucciones:
f- REVORE
-,-----:-~;::~;;-;;;~j¡. ~I GRANT OPTION FQR
I
INSERT
~fnomb"H'OI"mn8T 1
UPDATE T~
REFERE_~N_C_E_S
¡
I
FRQM
f
nombre·tabla OOMAIN nombre-dominio CHARACTER SET nomc~~~~~~ntoCOLLATION nombre-secuencia TRANSLATlQN nombre-traducción
"'"?Tl 3 ,
l!;0mb" PUBLlC
CASCADE
RESTRlCT
Figura 15.7.
Diagrama sintáctico de la instrucción REVOKE.
sobre la tabla
REPRE-
privilegio SELECT se conserva para los dos identificadores de usuario. A continuación se ofrecen otros ejemplos de la instrucción REVOKE:
Retirar todos los privilegios concedidos anteriormente sobre la tabla
OFI-
CINAS.
REVOKE ALL PRIVILEGES ON OFICINAS FROM USUARIOCU UPDATE
y
DELETE
de dos identificadores de usuario.
REVOKE UPDATE, DELETE ON OFICINAS FROM USUARIOCU. USUARIOPP
,
Retirar todos los privilegios sobre la tabla teriormente a todos los usuarios.
,
_
USAGE
ON
INSERT y UPDATE
SENTANTES a los dos usuarios y luego se le retiran a uno de ellos. No obstante, el
Retirar los privilegios SELECT DELETE
REPRESENTANTES.
'\
REVOKE INSERT, UPDATE ON REPRESENTANTES FROM USUARIOPP
TO LEON
445
I
•
OFICINAS
que se concedieron an-
REVOKE ALL PRIVILEGES ON OFICINAS FROM PUBLlC
Cuando un usuario escribe una instrucción REVOKE, sólo se pueden retirar los privilegios que ese usuario concedió anteriormente a otros usuarios. Puede que esos usuarios tengan también privilegios concedidos por otros usuarios; esos privilegios no se ven afectados por esta instrucción REVOKE. Obsérvese espeCíficamente que si dos usuarios diferentes conceden el mismo privilegio sobre el mismo objeto a un usuario, y uno de ellos lo retira posterionnente, la concesión
446
Capítulo 15: Seguridad en SOL
SOL. Manual de referencia
447
TO LEDN
GRANT SELECT, UPDATE ON PEDIDOS TO LEON
Pocos días más tarde Gonzalo Walker, el vicepresidente de marketing, concede a León Jos privilegios
SELECT
y
DELETE
sobre la tabla PEDIDOS y el privilegio
SELECT sobre la tabla CLIENTES, empleando estas instrucciones: GRANT SELECT, DELETE ON PEDIDOS TO LEON
GONZALO
GRANT SELECT ON CLIENTES TO LEDN
G)GRANT LEÓN
Obsérvese que León 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 días más tarde. Samuel le retira a León los privilegios que le había concedido anterionnente sobre la tabla PEDIDOS: REVOKE SELECT, UPDATE ON PEDIDOS FROM LEON
Una vez que el SGBD procesa la instrucción REVOKE, León 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.
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 automática todos los privilegios derivados de la concesión original. Considérese nuevamente la cadena de privilegios de la Figura 15.6, desde Samuel Clavel, el vicepresidente de ventas, a León Freire, el jefe de la oficina de León, y luego a Susana Santos. Si Samuel retira los privilegios de León sobre la vista REPOESTE, también se retira automáticamente el privilegio de Susana. La situación se complica aún más si dos o más usuarios han concedido privile-. gios y uno de ellos los retira posteriormente. Considérese la Figura 15.8, una pequeña variación sobre el último ejemplo. En este caso, León 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 León, la concesión de privilegios por parte
SUSANA
Figura 15.8.
Retirada de los privilegios concedidos por dos usuarios.
de Gonzalo permanece. Además, los privilegios de Susana también permanecen, ya que pueden proceder de la concesión de Gonzalo. No obstante, considérese otra variación de la cadena de privilegios, con los eventos ligeramente reordenados, como puede verse en la Figura 15.9. En este caso, León recibe de Samuel el privilegio con GRANT OPTION, concede el privilegio a Susana, y luego recibe la concesión, con GRANT OPTION, de Gonzalo. Esta vez, cuando Samuel retira los privilegios de León, los resultados son ligeramente diferentes, y pueden variar de un SGBD a otro. Como en la Figura 15.8, León conserva el privilegio SELECT sobre la vista REPOESTE porque la concesión de Gonzalo sigue intacta. Pero en las bases de datos de DB2 o de SQUDS, Susana pierde de manera automática su privilegio SELECT sobre la tabla. El motivo es que la concesión de León a Susana procedía claramente de la concesión de Samuel a León, que acaba de retirarse. No podía proceder de la concesión de Gonzalo a León, ya que e~a concesión no había tenido lugar todavía cuando se realizó la concesión de León a Susana. En una marca diferente de SGBD los privilegios de Susana podrían permanecer intactos, ya que la concesión de Gonzalo a León sigue intacta. Por tanto, la
448
SOL. Manual de referencia
rn~ ~ h
r.\GRANT WITH
0
Capítulo 15: Seguridad en SOL
OPTION
~::w
GAANT
IJ'GAANT RANT OPTION
GONZALO
~
G)GAANT
LEÓN
~ SUSANA
Figura 15.9.
Retirada de los privilegios en una secuencia diferente.
secuencia temporal de las instrucciones GRANT y REVOKE, más que los propios privilegios, puede determinar la trascendencia de una instrucción REVOKE. La concesión 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 estándar ANSI/ISO
El estándar SQLl especificaba la instrucción GRANT como parte del lenguaje de definición de datos de SQL (Data Definition Language, DDL). Recuérdese del Capítulo 13 que el estándar SQLl trataba el DDL como una definición estática e independiente de las bases de datos y no exigía que el SGBD permitiera modificaciones dinámicas en la estructura de las bases de datos. Este enfoque también se aplica a la seguridad de las bases de datos. Según el estándar 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 ningún mecanismo para la modificación del esquema de seguridad una vez definida la
449
estructura de la base de datos. La instrucción REVOKE, por tanto, no se halla incluida en el estándar SQLl, como sucede con la instrucción DROP TABLE. Pese a su ausencia del estándar SQLl. casi todos los productos comerciales de SOBD basados en SQL proporcionaban la instrucción REVORE desde las primeras versiones. Al igual que con las instrucciones DROP y ALTER, el dialecto DB2 de SQL ha definido de hecho el estándar para la instrucción REVOKE. El estándar SQL2 incluye una especificación para la instrucción REVOKE basada en la instrucción de DB2, con algunas ampliaciones. Una de las ampliaciones concede al usuario un control más explícito sobre el modo en que se retiran los privilegios cuando, a su vez, se han concedido a otros usuarios. La otra ampliación 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 estándar SQL2 exige que se especifique la opción CASCADE o RESTRICT en cada instrucción REVOKE. (En el estándar SQL2 se aplica un requisito parecido a muchas de las instrucciones DROP, como se describe en el Capítulo ]3.) Supóngase que los privilegios SELECT y UPDATE sobre la tabla PEDIDOS se han concedido anteriormente a León, con GRANT OPTION, y que León, a su vez, ha concedido estas opciones a Bruno. Entonces, esta instrucción REVOKE: REVOKE SELECT, UPDATE ON PEDIDOS FROM LEON CASCADE
no s610' retira los privilegios de León, sino también los de Bruno. El efecto de la instrucción REVOKE, por tanto, repercute en todos los demás usuarios cuyos privilegios procedan de la instrucción GRANT original. Abora, sup6nganse las mismas circunstancias y esta instrucción REVOKE: REVOKE SELECT. UPDATE ON PEDIDOS FROM LEON RESTRICT
En este caso, la instrucción REVOKE falla. La opción RESTRICT indica al SGBD que no debe ejecutar la instrucción si afecta a cualesquiera otros privilegios de la base de datos. El mensaje de error resultante llama la atención del usuario sobre el hecho de que hay efectos secundarios (posiblemente no buscarlos) de la instrucción REVOKE y permite que el usuario vuelva a considerar la acción. Si el usuario desea seguir adelante y retirar los privilegios, se puede especificar la opción CASCADE. La versión de SQL2 de la instrucción REVOKE también concede al usuario un control independiente, más explícito, sobre los privilegios, y GRANT QPTION para esos privilegios. Supóngase nuevamente que se han concedido a León privilegios sobre la tabla PEDIDOS, con GRANT OPTION para esos privilegios. La instrucción REVOKE habitual para esos privilegios: REVOKE SELECT. UPDATE ON PEDIDOS FROM LEaN
450
SOL. Manual de referencia
retira tanto los privilegios como la posibilidad de concedérselos a otros usuarios. El estándar SQL2 permite esta versión de la instrucción REVOKE: REVOKE GRANT OPTION FOR SELECT, UPDATE ON PEDIDOS FROM LEON CASCADE
Si la instrucción tiene éxito, León perderá su capacidad para conceder estos privilegios a otros usuarios, pero no los propios privilegios. ~omo antes, el estándar SQL2 exige la opción CASCADE o RESTRICT para especlfi~ar el modo en que el SGBD debe tratar la instrucción si León, a su vez, ha concedIdo GRANT OPTION a otros usuarios.
CAPíTULO
16
CatáloflO 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 también desempeñan 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 instrucción 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 instrucción REVOKE se utiliza para retirar los privilegios concedidos anteriormente con la instrucción GRANT.
Los sistemas de gestión de bases de datos deben realizar el seguimiento de gran cantidad de información sobre la estructura de las bases de datos para llevar a cabo sus funciones de gestión de datos. En las bases de datos relacionales esta información suele almacenarse en el catálogo del sistema, un conjunto de tablas que el SGBD conserva para su propio uso. La información del catálogo del sistema describe las tablas, las vistas, las columnas, los privilegios y otras características estructurales de las bases de datos. Aunque el SGBD conserva el catálogo del sistema principalmente para sus propias finalidades internas, las tablas del sistema o las vistas basadas en ellas suelen ser accesibles también para los usuarios de la base de datos, mediante consultas SQL estándar. 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 autodescripción para generar listas de tablas y de columnas para su selección por el usuario que simplifican el acceso a la base de datos. Este capítulo describe los catálogos del sistema proporcionados por varios productos de SGBD populares basados en SQL y la información que contienen esos catálogos. También describe las posibilidades del catálogo del sistema especifICadas por el estándar ANSI/ISO de SQL2.
El concepto de catálogo del sistema El catálogo 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 catálogo del sistema se crean de manera automática al crear la base de datos. Suelen reunirse bajo 451
452
SOL. Manual de referencia
Capítulo 16: Catálogo del sistema
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 catálogo del sistema mientras procesa las instrucciones de SQL. Por ejemplo, para procesar una instrucción SELECT de dos tablas, el SGBD debe: • • • • •
ArchIVO
Base de datos
Consulta
Busqueda
Actuahzaclon
Salir
453
!lOO EJI
Seleccione una tabla: CUENTES
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.
OfJ~NAS
PEDIDOS
Seleccione las columnas
NÚMERO DEL PEDIDO
PRODUCTOS
)
FECHA DEL PEDIOO
REPRESENTANTES
CUENTE REPRESENTANTE FABRICANTE
Al almacenar la información estructural en las tablas del sistema, el SGBD puede utilizar sus propios métodos y lógica de acceso para recuperar de manera rápida y eficiente la información que necesita para llevar a cabo estas tareas. Si las tablas del sistema se utilizaran sólo internamente al SGBD, resultarían de poco interés para los usuarios de la base de datos. No obstante, el SGBD suele poner también las tablas del sistema a disposición de los usuarios. Si las tablas del sistema en sí mismas no están disponibles, el SGBD suele ofrecer vistas basadas en esas tablas que ofrecen un conjunto de informaciones del catálogo 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 catálogos del sistema o a las vistas. Los productos para grandes sistemas y para SGBD de empresa también admiten estas consultas, pero el administrador de la base de datos puede restringir el acceso al catálogo del sistema para proporcionar medidas adicionales de seguridad de la base de datos. Al consultar los catálogos del sistema se puede hallar información sobre la estructura de la base de datos, aunque no se haya utilizado nunca antes. El acceso de los usuarios al catálogo del sistema es sólo de lectura. El SGBD evita que los usuarios actualicen o modifiquen directamente las tablas del sist~ma porque esas modificaciones destruirían 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 definición 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 número de filas de cada tabla.
PRODUCTO CANTIDAD IMPORTE TOTAL
• NÚMERO DEL PEDIDO
1129B1 113012 112989
J.P. Soloca JCP S. A.
REPflESENTANTE 1 Samu!IClav!1 Bruno M!aga ~
Jarandilla lId.
SlrlClavijo
CLIENTE
I
.¿
fÍ'
'~
Figura 16.1.
Herramienta de consulta fácil 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 catálogo y las herramientas de consulta Una de las principales ventajas del catálogo del sistema es que hace posible que las herramientas de consulta sean fáciles de usar por el usuario, como puede verse en la Figura 16.1. El objetivo de estas herramientas es permitir a ,los usuarios que
El usuario da un nombre y una contraseña 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 según 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 condición de búsqueda. La herramienta de consulta recupera los datos solicitados y los muestra en la pantalla del usuario.
Las herramienlas de consulta de propósito 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
I
~
454
SOL. Manual de referencia
Capítulo 16: Catálogo del sistema
cer con antelación la estructura de la base de datos a la que tendrá acceso durante cada sesión. Por tanto, debe poder aprender de manera dinámica sobre las tablas y las columnas de las bases de datos. Las herramientas utilizan con este fin las consultas al catálogo del sistema.
El catálogo y el estándar ANSI/ISO El estándar ANSI/ISO de SQLl no especificaba la estructura ni el contenido del catálogo del sistema. De hecho, el estándar SQL 1 no exige que haya catálogo del sistema. Sin embargo, todos los productos principales de SGBD basados en SQL ofrecen un catálogo del sistema de una forma o de otra. La estructura del catálogo y las tablas que contiene varían de una marca de SGBD a otra. Debido a la creciente importancia de las herramientas de bases de datos de propósito general que deben tener acceso al catálogo del sistema el estándar, SQL2 incluye la especificación de un conjunto de vistas que ofrecen un acceso normalizado a la información que suele hallarse en el catálogo del sistema. Los SGBD que cumplen el estándar SQL2 incluyen estas vistas, que se denominan colectivamente INFDRMATIDN_SCHEMA (esquema de la información). Dado que este esquema resulta más complejo que los auténticos catálogos del sistema utilizados por los productos comerciales de SGBD y su aceptación crece lentamente, se describe en un apartado diferente titulado «El esquema de la infonnación de SQL2», cerca del final de este capítulo.
• Privilegios. El ca.tálogo 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 InfOrmaCIón en cada~uno de lo~ principales productos SGBD basados en SQL. ~l .resto de este ~apItulo descnbe con más detalle algunas tablas del sistema tlplcas y ofrece ejemplos de acceso al catálogo del sistema. Debido a las amplias variaciones en los calálogos del sistema entre las diferentes marcas de . SGBD, tanto la descripción completa de los catálogos del sistema como la exhaustividad en los ejemplos de todas lás marcas principales de SGBD qued~an fuera del objetivo de este hbro. Con la información aquí ofrecida se debena poder consultar la docum~ntación del sistema de cada marca de SGBD y crear las consultas correspondlemes al catálogo del sistema.
Contenido del catálogo Cada tabla del catálogo del sistema contiene información sobre un solo tipo de elemento estructural de la base de datos. Aunque los detalles varían, casi todos los productos comerciales de SQL incluyen las tablas del sistema que describen cada una de estas cinco entidades: • Tablas. El catálogo describe cada tabla de la base de datos. identificando su nombre de tabla, su propietario, el número de columnas que contiene, su tamaño, etc. • Columnas. El catálogo 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 tamaño, si se permiten los valores NULL, etc. • Usuarios. El catálogo describe a cada usuario autorizado de la base de datos, incluyendo el nombre de usuario, una forma codificada de la contraseña del usuario y otros datos. • Vistas. El catálogo describe cada vista definida en la base de datos. incluyendo.su nombre, el nombre de su propietario, la consulta que define la vista, etc.
Las tablas de DB2 tienen el calificador SYSCAT (por ejemplo. SYSCATTABLES).
456
SOL. Manual de referencia
Capítulo 16: Catálogo del sistema
457
Información de tablas
Tabla 16.2.
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
Nombre de la columna
Tipo de datos
Información
OVERFLOW
infaonación la ofrece una vista del catálogo del sistema denominada SYSCAT. TABLES. (Todas las vistas del catálogo del sistema de DB2 forman parte de un esquema de-
INTEGER
Número de registros de desbordamiento de la tabla.
TBSPACE
VARCHAR(lB)
Espacio de tablas primario para el almacenamiemo de los datos de la tabla.
INDEX_TBSPACE
VARCHAR (18)
Espacio de rabias para el almacenamiento de los índices de la tabla.
LONG_TBSPACE
VARCHAR(18)
Espacio de tabla para el almacenamiento de objetos de ~atos de gran tamaño.
PARENTS
SMALLINT
Número de tablas padre de la tabla.
CHILDREN
SMALLINT
Número de tablas hijo de la tabla.
SELFREFS
SMALLINT
Número de autorreferencias de la tabla.
KEYCOLUMNS
SMALLINT
Número de columnas de la clave primaria de la tabla.
KEYINDEXID
SMALLINT
Identificador interno para el índice de la clave primaria.
KEYUNIQUE
SMALLINT
Número de restricciones de unicidad de la tabla.
CHECKCOUNT
SMALLINT
Número de restricciones de comprobación de la tabla.
DATACAPTURE
CHAR(l)
Indica si la tabla se ha reproducido (YIN, sí o no).
CONST_CHECKED
CHAR(32)
Banderas de comprobación de resrricciones.
PMAP_ID
SMALLINT
Identificador interno del mapa de particiones de la tabla.
PARTITION_HODE
CHAR(l)
Modo de las tablas de la base de datos divididas en particiones.
nominado 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 típica de las ofrecidas por las vistas correspondientes
en otros productos de SGBD importantes. Tabla 16.2.
.
Vista SYSCAT. TABLES (082)
Nombre de la columna
Tipo de datos
Vista SYSCAT.TABLES (082) (continuación)
Información
TABSCHEMA
CHAR(B)
Esquema que contiene la tabla, vista o alias.
TABNAME
VARCHAR (18)
Nombre de la tabla, vista o alias.
DEFINER
CHAR(B)
Identificador de usuario del creador de la tabla, vista o alias.
TYPE
CHAR{l)
T = tabla, V = vista, A
STATUS
CHAR{l)
Estado del objeto (para uso por el sistema).
BASE_TABSCHEMA
CHAR{S)
Esquema de la tabla base para el alias.
BASE_TABNAME
VARCHAR(18)
Nombre de la tabla base para el alias.
CREATE_TIME
TIMESTAMP
Momento de creación del objeto.
STATS_TIME
TIMESTAMP
Momento en que se ha calculado la última estadística.
COLCOUNT
SMALLINT
Número de columnas de la tabla.
TABLEID
SHALLINT
Número de identificación interna de la tabla.
LOG_ATTRIBUTE
CHARll)
Indica si inicialmente se habilitó el registro histórico para la tabla.
TBSPACEID
SHALLINT
Identificador del espacio de tablas primario de la tabla.
PCTFREE
SMALLINT
Porcentaje de páginas que hay que reservar para datos futuros.
CARD
INTEGER
Número de filas de la tabla (cardinalidad).
REMARK5
VARCHAR(254)
Comentarios del usuario sobre la tabla.
NPAGES
INTEGER
Número de páginas del disco que contienen datos de la tabla.
FPAGES
INTEGER
Número total de páginas de disco de la tabla.
=alias.
(colltinlía)
Las consultas pueden utilizarse como indican los ejemplos siguientes para obtener información 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 información de otras marcas de SGBD.
458
CapItulo 16: Catálogo del sistema
SOL. Manual de referencia
Hacer una relación del nombre y propietario de todas las tablas de la base de datos. 5ELECT DEFINER, TABNAME FROM SYSCAT.TABLES WHERE TYPE = • T'
Hacer una relación del nombre de todas las tablas, vistas y alias de la base de datos. SELECT TABNAME
Tabla 16.3. Columnas seleccionadas de la tabla SYSOBJECTS (SQl Serverl
Nombre de la columna
Tipo de datos
Información
Name
SYSNAME
Nombre del objeto.
Id
INT
Número de identificador interno del objeto.
Vid
SMALLINT
Identificador de usuario del propietario del objeto.
Type
CHAR(2)
Código de tipo del objeto!.
Crdate
DATETIME
Fechalhora en que se creó el objeto
Deltrig
INT
Identificador del procedimiento del DELETE disparador.
instrig
INT
Identificador del procedimiento del INSERT disparador.
updtrig
INT
FROM SYSCAT.TABLES
Hacer una relación del nombre y del momento de creación de las tablas del usuario que introduce la orden. SELECT TABNAME. CREATE_TIME FROM SYSCAT.TABLES WHERE TYPE = • T' ANO DEFINER = USER
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 mínimo, uno de los privilegios de acceso al usuario en curso. A continuación puede verse una consulta típica a una de estas vistas del catálogo del sistema de Oracle:
USER_TABLES y ALL_TABLES llevan a cabo una labor parecida a SYSCAT. TABLES de DB2. La vista USE~TABLES contiene una fila
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
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 información sobre las tablas y vistas de SQL Server y sobre otros objetos de SQL Server, como los procedimientos almacenados, las reglas y los disparadores. Obsérvese también que la tabla SYSOBJECTS utiliza un número 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 información sobre las tablas se denomina SYSTABLES. Al igual que el catálogo de DB2, sólo contiene información sobre las tablas, las vistas y los alias; los demás objetos de la
459
Identificador del procedimiento del disparador.
UPDATE
1 S = tabla del sistema, U = tabla del usuario. V = vista. L = registro histórico. P = procedimiento almacenado. TR = disparador. etc.
base de datos se describen en otras tablas del sistema. A continuación puede verse una consulta típica a la tabla del sistema de Informix: Hacer una relación del nombre, propietario y momento de creación de todas las tablas de la base de datos. SELECT TABNAME, OWNER, FROM SYSTABLES WHERE TABTYPE = 'T'
CREATED
Como muestran estos ejemplos, las consultas para obtener información 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 información, así como las columnas importantes, varían considerablemente de una marca a otra.
Información 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 básica del sistema, pero ofrecen al usuario infonnación de las columnas mediante una vista que s610 muestra las columnas de
460
SOL. Manual de referencia
las tablas propiedad del usuario en curso o que le resultan accesibles. En las bases de datos de OracIe esta información la ofrecen dos vistas del catálogo 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 información de la tabla o vista de columnas del sistema almacena la definición de las columnas -su nombre, su tipo de datos, su longitud, si puede aceptar valores NULL, ete.-, Además, la tabla incluye a veces información sobre la distribución de los valores de los datos de cada columna. Esta información estadística ayuda al SGBD a decidir el modo de llevar a cabo las consultas de manera óptima. A continuación puede verse una consulta típica que puede utilizarse para obtener información sobre las columnas de una base de datos de Oracle:
Hacer una re(ación 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'
Al igual que la información de las tablas del catálogo del sistema, la información de las columnas varía de una marca de SGBD a otra. La Tabla 16.4 muestra el contenido de la tabla del sistema SYSCAT. CQLUMNS, que contiene información de las columnas en el catálogo de DB2. A continuación se ofrecen varios ejemplos de consultas que se aplican a esta marca de SGBD:
Capítulo 16: Catálogo del sistema
Tabla 16.4.
Vista SYSCAT.COLUMNS (OB2)
Nombre de la columna
Tipo de datos
Hacer una relación del propietario, nombre de la vista, nombre de la columna, tipo de datos y longitud de todas las columnas de texto de más de diez caracteres de longitud definidas en las vistas. SELECT FROM WHERE ANO ANO ANO ANO
Hay una variación considerable en el modo en que los catálogos del sistema de las diferentes marcas de SGBD ofrecen las definiciones de las columnas. Para su comparación, la Tabla 16.5 muestra la definición de la tabla SYSCOLUMNS de Uni-
Información
TABSCHEMA
CHAR(B)
Esquema de la tabla que contiene la columna.
TABNAME
VARCHAR (lB)
Nombre de la tabla que contiene la columna. Nombre de la columna. Posición de la columna en la tabla (primera columna = O).
COLNAME
VARCHAR (18)
COLNO
SMALLINT
TYPESCHEMA
CHAR(B)
Esquema del dominio de la columna (o SYSIBM).
TYPENAME
VARCHAR(lB¡
Nombre del tipo de datos o del dominio de la columna.
LENGTH
INTEGER
Longitud máxima de los datos para los tipos de datos de longitud variable.
SCALE
SMALLINT
Escala para los tipos de datos DECIMAL.
DEFAULT
VARCHAR(254)
Valor predeterminado de la columna.
NULLS
CHAR(l)
Indica si se permiten valores NULL (Y/N. Sí/No).
CODEPAGE
SMALLINT
Página de código para los tipos de caracteres ampliados.
LOGGED
CHAR(l)
COMPACT
CHAR(l)
COLCARD
INTEGER
Indica si se ha activado el registro histórico (Y/N, SílNo) para las columnas de objetos de gran tamaño. Indica si se han compactado las columnas de objetos de gran tamaño (YIN, SílNo). Número de valores diferentes de los datos (cardinalidad).
HIGH2KEY
VARCHAR(33)
Segundo valor más elevado de las columnas de la tabla.
LOW2KEY
VARCHAR (33 )
AVGCOLLEN
INTEGER
Segundo valor más reducido de las columnas de la tabla. Longitud promedio de los datos para los tipos de datos de longitud variable.
KEYSEQ
SMALLINT
Posición de la columna en la clave primaria (o O).
PARTKEYSEQ
SMALLINT
Posición de la columna dentro de la clave de partición (o O).
NQUANTILES
SMALLINT
Número de cuantiles en las estadísticas de las columnas.
NMOSTFREQ
SMALLINT
Número de valores frecuentes en las· estadísticas de las columnas.
REMARKS
VARCHAR(254)
Comentarios del usuario para la columna.
Hallar todas las columnas de la base de datos con el tipo de datos DATE. SELECT TABSCHEMA, TABNAME, COLNAME FROM SYSCAT.COLUMNS WHERE TYPESCHEMA = 'SYSIBMO' ANO fYPENAME = 'DATE'
461
Capítulo 16: Catálogo del sistema
SOL Manual de referencia
462
Tabla 16.5. Tabla
SYSCOLUMNS
Información de vistas
(In1ormixl
Nombre de la columna
Tipo de datos
Información
COLNAME
CHAR (18)
Nombre de la columna.
TABIO
INTEGER
Identificador de tabla interno de la tabla que contiene la columna.
Las definiciones de las vistas de una base de datos suele almacenarlas el SGBD en el catálogo del sistema. El catálogo de DB2 contiene dos tablas del sistema que
SMALLINT
Posición de la columna en la tabla.
COLTYPE
SMALLINT
Tipo de datos de la columna y si se penniten los valores NULL.
CQLLENGTH
5MALLINT
Longitud de la columna.
COLMIN
INTEGER
Segundo valor más reducido de los datos de la columna.
COLMAX
INTEGER
Segundo valor más elevado de los datos de la columna.
MINLEN
INTEGER
¡..ongitud mínima de los datos.
MAXLEN
INTEGER
Longitud máxima de los datos.
EXTENDED_ID
INTEGER
Identificador interno de los tipos de datos ampliados.
COLNO
versal Server de Informix. Algunas de las diferencias en la información 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 catálogo de DB2 utiliza una combinación del nombre del esquema y del nombre de la tabla para identificar la tabla que contiene una columna dada; el catálogo de Informix utiliza un número interno de identificador de la tabla, que es una clave externa de su tabla SYSTABLES.
• DB2 especifica los tipos de datos en fonua de texto (por ejemplo,
CHARAC-
realizan un seguimiento de las vistas. La tabla SYSCAT. VIEWS. descrita en la Tabla
16.6, contiene la definición de SQL en texto de cada vista. Si la definición supera los 3600, se almacena en varias filas, con los números 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 demás 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 rápidamente las tablas de la base de datos que actúan como tablas fuente de cada vista. Al igual que con muchos productos de SOBD implantados, la información sobre las vistas está estrechamente relacionada con la información so~ bre las tablas en el catálogo de DB2. Esto significa que suele haber más de una manera de hallar la respuesta a las búsquedas en el catálogo. Por ejemplo, a continuación 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:
Hacer una relación de las vistas definidas en la base de datos. SELECT DISTINCT VIEWSCHAME. VIEWNAME. FROM SYSCAT.VIEWS
Tabla 16.6.
Otras diferencias reflejan las diferentes posibilidades ofrecidas por las dos
Nombre de la columna
TIpo de datos
Información
VIEWSCHEMA
CHAR(8)
Esquema que contiene la vista.
VIEWNAME
VARCHAR (18)
Nombre de la vista.
DEFINER
CHAR(8)
Identificador de usuario de la persona que creó la vista.
SEQNO
SMALLINT
Número de secuencia de la fila de texto
de SQL. VIEWCHECK
CHAR(l)
Tipo de comprobación de la vista.
READONLY
CHAR(l)
Indica si la vista es sólo de lectura (YIN, sí/no).
VALID
CHAR (l)
Indica si la definición de la vista es válida (YIN, sí/no).
VARCHAR(254)
Camino para la resolución de las llamadas a funciones de la vista.
marcas de SGBD: • DB2 permite especificar hasta 254 caracteres de comentarios sobre cada co~ lumna; Informix no ofrece esta característica. • El sistema de Informi~ realiza un seguimiento de la IQngitud máxima y mínima de los valores de los datos almacenados en una columna de longitud variable; esta información no está disponible directamente a partir del catálogo
DEFINER
Vista SYSCAT. VIEWS (082)
TER); el catálogo de Informix utiliza códigos enteros de tipos de datos.
del sistema de DB2.
463
TEXT
VARCHAR (3600) Texto de SQL de la definición de la vista (<
464
SOL. Manual de referencia
Tabla 16.7.
Capítulo 16: Catálogo del sistema
Vista SYSCAT. VIEWDEP (OB2)
Nombre de la columna
Tipo de datos
Información
VIEWSCHEMA
CHAR(8)
Esquema que contiene la vista.
VI EWNAME
VARCHAR(18)
Nombre de la vista.
DEFINER
CHAR{B)
Identificador de usuario de la persona que creó la vista.
BTYPE
CHAR(l)
Tipo de objeto del que depende la vista (T = tabla, V = vista, A = alias, etc.).
BSCHEMA
CHAR(a)
Esquema que contiene el objeto del que depende la vista.
TABAUTH
SMALLINT
Banderas que indican los privilegios sobre el objeto del que depende la vista.
Obsérvese el empleo de DISTINCT para eliminar las filas duplicadas que aparecerían para las vistas con definiciones de texto de gran longitud. Quizás una manera más sencilla de obtener la misma información sea consultar directamente la tabla del sistema TABLES de DB2. seleccionando sólo las filas que representan vistas, como indica el valor de TYPE:
Hacer una relación 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 catálogo 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 instrucción SELECT de SQL que define una vista. Las definiciones de vistas que abarcan varias filas se manejan mediante números de secuencia, como en DB2. La tabla SYSVIEWS de Informix sólo 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 información entre las tablas SYSTABLES y SYSVIEWS, pero el usuario debe reunir las tablas de manera explícita para las solicitudes de· información a la vista más 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 información de tablas y columnas, hay dos vistas del sistema que resultan interesantes: USER_VIEWS, que contiene infonnación sobre todas las vistas creadas por el usuario y que son propiedad suya, y ALL_VIEWS, que también incluye información sobre las vistas accesibles para el usuario en curso pero creadas por otros usuarios.
465
A diferencia de los enfoques de DB2 y de Informix, que dividen el texto de SQL que define la vista en varias filas con números de secuencia si es muy largo, las vistas del sistema de Orade sólo contienen una fila por vista. El texto de SQL que define la vista se guarda en una columna LONG (objeto de gran tamaño) 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 definición de la vista. A continuación se ofrece una consulta para obtener la información sobre las vistas de Oracle:
Hacer una relación de las vistas del usuario actual y de sus definiciones. SELECT VIEW_NAME, TEXT_LENGTH, TEXT FROM USER_VIEWS
Obsérvese que la mayor parte de los productos de SQL interactivo (incluidos los de Oracle) truncan el texto que contiene la definición de las vistas si es demasiado largo para mostrarlo. El texto real almacenado en la base de datos está completo.
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 descripción de las tablas o de los elementos de datos en el catálogo del sistema. Los comentarios se almacenan en las tablas del sistema 5YSCAT. TABLES y SY5CAT. COLUMNS del catálogo del sistema. A diferencia de los demás elementos de las definiciones de las tablas y de las columnas, los comentarios y las etiquetas no se especifican en la instrucción CREATE TABLE. En vez de eso, se emplea la instrucción COMMENT. SU sintaxis se puede ver en la Figura 16.2. A continuación se ofrecen algunos ejemplos:
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
OBJETIVO y VENTAS
de la tabla
OFICINAS.
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 también alberga la· instrucción COMMENT ON para "ad-
466
SOL. Manual de referencia
Capítulo 16: Catálogo del sistema
Tabla 16.8. r-COMMENT O N r T A B L E
nOmbfe-COIUmna--r 15 texto-comentario
~ombre
Vista SYSCAT. REFERENCES (082)
de la columna
Tipo de datos
Información
CONSTNAME
VARCHAR(18)
Nombre de la restricción descrita por la fila.
TABSCHEMA
CHAR(8l
Esquema que contiene la restricción.
TABNAME
VARCHAR (18)
DEFINER
CHAR(B)
Creador de la tabla a la que se aplica la restricción.
REFKEYNAME
COLUMN nombre-cualificado-co/umnaJ
nombre-rabia (fOmbre-eOlumna I~ texto-eomemari))
f-LABEL ON
TABLE nombre·columna
15 texto-etiqueta
COLUMN nomb,e-oual""BdNOlumnaJ
.
L, Figura 16.2.
Diagramas sintácticos de la instrucción
COMMENT
de D82.
juntar comentarios a las tablas y a las columnas. Los comentarios, sin embargo, no se almacenan igual que el resto de información 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 años 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 estándar de SQL y no ha sido adoptada de manera generalizada por otros productos importantes de SGBD.
Información de relaciones Con la inlroducción de la integridad referencial en los principales productos de SGBD empresariales, a mediados de los años noventa del siglo pasado. los catálogos 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 descripción la ofrece la tabla del catálogo del sistema SYSCAT. REFERENCES, que se describe en la Tabla 16.8. Cada relación 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
467
~
Tabla a la que se aplica la restricción.
VARCHAR (18)
Nombre de la clave padre.
REFTABSCHEMA
CHAR(8)
Esquema que contiene la tabla padre.
REFTABNAME
VARCHAR(18)
Nombre de la tabla padre.
COLCOUNT
SMALLINT
Número de columnas de la 'c1ave externa.
DELETERULE
CHAR(l)
Regla de eliminación de la clave externa (A = sin acción, e = cascada, R = restringida, etc.).
UPDATERULE
CHAR(ll
Regla de actualización de la restricción de la clave externa (A = sin acción, R = restringida).
CREATE_TIME
TIMESTAMP
Momento de creación de la restricción.
FK_COLNAMES
VARCHAR(320)
Nombre de las columnas de la clave externa.
PK_COLNAMES
VARCHAR (320)
Nombre de las columnas de la clave primaria.
hijo, el nombre de la relación y las reglas de eliminación y de actualización de la relación. Se puede consultar para obtener datos sobre las relaciones de la base de datos:
Hacer una relació';de todas las relaciones padre/hijo entre las tablas del usuario actual, que muestre el nombre de la relación, el nombre de la tabla padre, el de la tabla hijo y la regla de eliminación de cada una de ellas. SELECT CONSTNAME, REFTABNAME, TABNAME, DELETERULE FROM SYSCAT.REFERENCES WHERE DEFINER = USER
Hacer una relación de las tablas relacionadas con la tabla REPRESENTANTES como madres o como hijas. SELECT REFTABNAME FROM SYSCAT.REFERENCES
Hacer una relación 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 más útil de esta información. En esta tabla del sistema hay una tabla por cada columna de cada clave externa, de cada clave primaria o de cada restricción de unicidad definida en la base de datos. Un número 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
Nombre de la columna
Tipo de datos
Información
El soporte del catálogo 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 información que la tabla del sistema SYSCAT. REFERENCES de DB2. La información 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 análoga a la tablas del sistema de DB2 SYSCAT. KEYCOLUSE. Microsoft SQL Server tiene una estructura del catálogo del sistema parecida, con la información sobre las claves externas dividida entre las tablas del sistema SYSFOREIGNKEYS y SYSREFERENCES. Universal Server de Informix. adopta un enfoque parecido al del catálogo de DB2, pero con el mismo tipo de diferencias mostradas anteriormente en su soporte de la información 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 compróbaci6n, clave primaria, referencial, etc.). Esta tabla del sistema asigna un 'número interno de identificador de la restricción para identificar la restricción en el catálogo. La tabla a la que se aplica la restricción también se identifica mediante un identificador de tabla (que sirve de clave externa a la tabla del sistema SYSTABLES). La información adicional sobre las restricciones referenciales (claves externas) se encuentra en la tabla del sistema SYSREFERENCES. En esta tabla, nuevamente, la restricción, la clave primaria y la tabla padre se identifican mediante identificadores internos que vinculan la información sobre la clave externa a las tablas del sistema SYSCONSTRAINTS y SYSTABLES. La tabla SYSREFERENCES contiene información sobre las reglas de eliminaci6n y de actualización que se aplican a la relación de clave externa, y otra información parecida.
CON8TNAME
VARCHAR ( 18)
Nombre de la restricción (de unicidad, clave principal o clave externa) descrita por la fila.
Información de usuarios
Hacer una relación de las columnas que vinculan en la relación denominada ESPARA. SELECT FROM WHERE aRDER
PEDIDOS
con
PRODUCTOS
COLNAME, COLSEQ SYSCAT.KEYCOLUSE CONSTNAME = 'ESPARA' BY COLSEQ
La clave primaria de cada tabla y las relaciones padre/hijo en las que participa también 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 número de columnas que componen su clave primaria (uno para las claves simples, dos o más 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 posición (1, 2, etc.) de la columna de la clave primaria dentro de la clave primaria. Tabla 16.9. Vista SYSCAT.KEYCOLUSE (D82)
TAB8CHEMA
CHAR (8)
Esquema que contiene la restricción.
TABNAME
VARCHAR ( 18)
Tabla a la que se le aplica la restricción.
COLNAME
VARCHAR (18 )
Nombre de la columna en la restricción.
COLSEQ
SMALLINT
Posición de la columna en la restricción.
El catálogo del sistema suele contener una tabla que identifica a los usuarios que están 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 contraseña cuando los usuarios intentan conectarse por primera vez a la base de datos. La tabla puede almacenar también otros datos de los usuarios.
Capítulo 16: Catálogo del sistema
SOL. Manual de referencia
470
. ación 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 . dae seguridad de SQL Server. Informix adopta un 'os del esquema . gropo d e usua,n tabla del sistema que también 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
Hacer una relación de todos los identificadores de usuario conocidos para SQL Serv" SELECT NAME FRDM SYSUSERS WHERE UID <> GIO
Hacer una relación de todos los identificadores de usuario conocidos para OracIe. SELECT USERNAME
471
Información de privilegios Además de almacenar la información sobre la estructura de la base de datos, el catálogo del sistema suele almacenar la información que necesita el SaBD para hacer que se cumpla la seguridad de la base de datos. Como se describió en el Capítulo 15, los diferentes productos de SaBD ofrecen variaciones del esquema de privilegios básico de SQL. Estas variaciones se reflejan en la estructura de los catálogos del sistema de las diferentes marcas de SORD. DB2 tiene uno de los esquemas más generales para los privilegios de los usuarios, que detalla hasta cada una de las columnas de las tablas. La Tabla 16.11 muestra los catálogos del sistema de DB2 que almacenan la información sobre los privilegios y describe brevemente el papel de cada uno. El esquema de autorizaciones utilizado por SQL Server resulta más básico 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 instrucción GRA1'lT o REVQKE formulada.
FROM ALL_USERS
La tabla del catálogo del sistema de DB2 que contiene lo~ ~om~res de los usuarios también contiene la información 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 catálogo de DB2:
Tabla 16.11.
¡rabia del sistema
Papel
TABAUTH
Implementa los privilegios en el nivel de tablas indicando los usuarios que tienen permiso para el acceso a cada tabla y para cada operación (SELECT, INSERT, OELETE, UPDATE, ALTER e
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.
DBAUTH
Detenruna los usuarios que tienen permiso para conectarse con la base de datos, para crear tablas y para llevar a cabo diferentes labores de administración de la base de datos.
SCHEMAAUTH
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.
INDEXAUTH
Implementa los privilegios en el nivel de índices indicanao los usuarios que tienen privilegios de control sobre diferentes índices.
PACKAGEAUTH
Implementa los privilegios de acceso mediante programación indicando los usuarios que tienen la capacidad de controlar, enlazar (crear) y ejecutar diferentes programas de acceso a la base de datos (<
INDEX).
Hacer una relación de todos los identificadores de usuario conocidos para DB2. SELECT OISTINCT GRANTEE FROM SYSCAT.OBAUTH WHERE GRANTEETYPE ; 'u'
Tabla 16.10.
Columnas seleccionadas de la tabla SYSUSERS (SQL Serverl
Nombre de la columna
Tipo de datos
Información
uid
SMALLINT
Número interno de identificador de usuario en la base de datos.
gid
SMALLINT
Número interno de identificador de grupo de usuarios en la base de datos.
name
SYSNAME
Nombre del usuario o del grupo de usuarios.
Vistas del catálogo del sistema de DB2 que implementan los permisos
472
SOL. Manual de referencia
Capítulo 16: Catálogo del sistema
Nombre de la columna
Tipo de datos
Información
¡.laDla
id
INT
Identificador interno de los objetos protegidos.
USERS
uid
SMALLINT
Identificador interno de los usuarios o grupos con privilegios.
actino
TINYINT
Código numérico del privilegio.
protecttype
TINl;"INT
Código numérico de concesión O retirada.
columns
oel sistema
SCHEMATA DATA_TYPE_DESCRIPTOR
VARBINARY (32) Mapa de bits de los privilegios de actualización en el nivel de columnas.
Una fila por dominio.
El esquema de la información de SQL2
VIEW_TABLE_USAGE
El estándar SQL2 no especifica de manera directa la estructura del catálogo del sistema que deben albergar las implementaciones del SOBD. En la práctica. dadas las características tan diferentes admitidas por las distintas marcas de SGBD y las grandes diferencias entre los catálogos del sistema que ya estaban utilizando los
VI EW_COLUMN_USAGE
Tabla 16.\3. El estándar SQL2 no exige que el SGBD admita realmente las tablas del catálogo del sistema de la Tabla 16.13, ni ningún catálogo del sistema. En vez de eso, define una serie de vistas de esas tablas del catálogo que identifican los objetos de la base de datos "que son accesibles para el usuario actual. (Estas vistas del catálogo se denominan en el estándar esquema de la información.) Cualquier SGBD que proclame el nivel de cumplimiento intermedio o completo del estándar SQL2 debe admitir esas vistas. Esto da, de hecho, al usuario una manera normalizada de obtener ioformación sobre los objetos de la base de datos que tiene disponibles utilizando SQL estándar con las vistas del catálogo. Obsérvese que el soporte de las vistas del catálogo 'no se exige para el nivel de cumplimiento inicial del estándar SQL2. En la práctica, las principales implementaciones comerciales de SQL han ido admitiendo poco a poco el esquema de la información de SQL2, generalmente definiendo las vistas correspondientes de las tablas de sus propios catálogos del sistema. En la mayor parte de los casos, la información en los propios catálogos del sistema de los SGBD es lo bastante parecida a la exigida por el estándar como para que el primer noventa por ciento de la conformidad con el estándar SQL2 resulte relativamente sencillo. El último diez por ciento se ha mostrado mucho más difícil, dadas las variaciones entre las marcas de SGBD y el. grado en que,
Una fila por columna de cada definición de tabla o vista. Una fila por tabla a la que se haga referencia en cada definición 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.
TABLE_CONSTRAINTS
Una fila por restricción de tabla especificada en una definición de tabla.
KEY_COLUMN_USAGE
Una fila por columna especificada en cada clave principal, clave externa o restricción de unicidad (si se especifican varias columnas en la definición de una clave o de restricción de unicidad, habrá varias filas que representen esa restricción).
REFERENTIAL_CONSTRAINTS
Una fila por definición de clave externa especificada en una definición de tabla.
CHECK_CONSTRAINTS
Una fila por restricción de comprobación especificada en una definición de tabla. Una fila por tabla a la que se haga referencia en cada restricción de comprobación, restricción de dominio o aserto. Una fila por colUmna a la que se haga referencia en cada restricción de comprobación, restricción 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 fLIa por dominio o columna definidos con un tipo de datos. Una fila por restricción de dominio. Una fila por tabla o vista. Una fila por tabla o vista.
VIEWS
imposible alcanzar un acuerdo sobre una definición estándar de catálogo. En vez de eso, los redactores del estándar SQL2 definieron un catálogo del sistema idealizado que los fabricantes de SGBD podrían diseñar si estuvieran creando un SGBD para albergar el estándar SQL2 desde cero. Las tablas de este catálogo idealizado del sistema (denominado esquema de definición en el estándar) se resumen en la
Una fila por usuario (<
DOMAINS
COLUMNS
productos comerciales de SQL cuando se adoptó el estándar SQL2, habría sido
Contenido
DOMAIN_CONSTRAINTS -TABLES
473
Una fila por conjunto de caracteres definido. Una fila por secuencia de ordenación definida. Una fila por traducción definida. Una fila por lenguaje (por ejemplo, COBOL, admitido por esa marca de SGBD.
e, etc.)
474
Capítulo 76: Catalogo del sistema
SOL. Manual de referencia
incluso las vistas del catálogo de SQL2, muestran las características y posibilidades concretas del SGBD subyacente. En consecuencia, el soporte completo de las vistas del catálogo de SQL2 se ha implementado generalmente junto con ,cada nueva versión importante del producto de SOBD, acompañado por modificaciones subyacentes en el núcleo del software del SGBD. Las vistas de los catálogos exigidas por,el estándar SQL2 se resumen en la Tabla 16.14, junto con una breve descripción de la información contenida
Tabla 16.14.
Tabla 16.14.
V¡st~~
INFORMATION_SCHEMA_ CATALOG_NAME
SCHEMATA
DOMAINS
'Vista del catálogo del sistema
TABLE_CONSTRAINTS
REFERENTIAL_CONSTRAINTS
Contenido Una sola fila que especifica el nombre de la base de datos para cada usuario (<
CHECK_CQNSTRAINTS
ASSERTIONS
DOMAIN_CONSTRAINTS
Una fila por restricción de dominio que especifica el nombre de la restricción y sus características de diferibilidad.
CHARACTER_SETS
TABLES
Una fila por tabla o vista accesible para el usuario en curso que especifica el nombre y el tipo (tabla o vista).
COLLATIONS
VIEWS
COLUMNS
del catálogo que el estándar SQL2 hace obligatorias (con ti-
nuaclon)
Vistas del catálogo que el estándar SQL2 hace obligatorias
Vista del catálogo del sistema
Una fila por vista accesible para el usuario en curso que especifica el nombre, la upción de comprobación y la posibilidad de actualización. 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 precisión, 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. (continúa)
475
TRANSLATIONS
Contenido Una fila por uso concedido por el usuario actual o que le haya sido otorgado. Una fila por .re~tricción de tabla (clave primaria, clave externa, restriCCIones de unicidad o restricción de comp~bación) especifica~a sobre una tabla propiedad del usuano en curso que especifica el nombre de la restricci6n ' la tabla, el tipo de restricción y su diferibilidad. Una fila por restricción 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 restricción de comprobación 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 posición 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 definición de conjunto de caracteres accesible para el usuario en curso. Una fila por definici6n de secuencia de ordenación accesible para el usuario en curso. Una fila por definición de traducci6n accesible al usuario en curso. Una fila por tabla, a la que se haga referencia en cada defini.ción 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 restricción de comprobaci6n, restricción de unicidad definición de clave externa o aserto propiedad del usuari¿ actual. Una fila por columna a la que se haga referencia en cada restricción de comprobación, restricción de unicidad, definición 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 estándar SQL2, el tipo de SQL soportado, etc.
476
SOL. Manual de referencia
en cada vista. A continuación se ofrecen algunas consultas de ejemplo que pueden utilizarse para extraer información sobre la estructura de la base de dalOs a partir de las vistas del catálogo del sistema definidas por SQL2: Hacer una relación de Jos nombres de las tablas y vistas propiedad del usuario actual. SELECT TABLE_NAHE FROM TABLES
Hacer una relación de/nombre, posición y tipo de datos de todas las columnas de todas las vistas.
Capítulo 16: Catálogo del sistema
477
Otra información del catálogo El catálogo del sistema es un reflejo de las posibilidades y características del SGBD que lo utiliza. Debido a las muchas ampliaciones de SQL y características adicionales ofrecidas por los productos de SGBn populares, los catálogos del sistema siempre contienen varias tablas exclusivas de cada SGBD. A continuación se ofrecen unos cuantos ejemplos: • DB2 Y Oracle incluyen alias y sinónimos (nombres alternativos de las tablas). DB2 almacena la información sobre los alias con otra información sobre las tablas en la tabla del sistema SYSCAT. TABLES. Orade deja la información sobre los sinónimos disponible mediante la vista del sistema OSER_SYNONYMS.
SELECT TABLE_NAME, C.CQLUMN_NAME, QRDINAL_POSITION, DATA_TYPE FROM COLUMNS WHERE (COLUMNS.TABLE_NAME IN (SELECT TABLE_NAME FROM VIEWS))
Determinar el número de columnas de la tabla denominada OFICINAS. 5ELECT COUNT (*)
FRDM COLUMNS WHERE (TABLE_NAME = 'OFICINAS')
El estándar define también tres dominios que utilizan las vistas del catálogo y que también están disponibles para los usuarios. Estos dominios se resumen en la rabIa 16.15. El Apéndice E contiene un resumen completo de las principales vistas del catálogo de SQL2 y de su contenido.
Tabla 16.15.
Dominios definidos por el estándar SQL2
,Dominio del sistema
Valores
SQL_IDENTIFIER
Dominio de todas las cadenas de caracteres de longitud variable que son identificadores legales de SQL según el estándar SQL2. Los valores extraídos de este dominio son nombres de tabla o de columna, etc. legales.
CHARACTER_DATA
Dominio de todas las cadenas de caracteres de longitud variable con una longitud entre cero y la longitud máxima admitida por el SOBD. Los valores extraídos de este dominio son cadenas de caracteres legales.
CARDINAL_NUMBER
Dominio de todos los números no negativos, de cero hasta el valor máximo representado por INTEGER para el SGBD. Los valores extraídos de este dominio son cero o un número positivo legal.
• 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 catálogo contiene una o varias tablas que los describen. Sybase almacena la información sobre los procedimientos almacenados en la tabla del sistema SYSPROCEDURES. • lngres incluye las tablas distribuidas entre varios volúmenes de disco. La tabla del sistema lIMULTI_LOCATIONS realiza el seguimiento de las ubicaciones de las tablas multivolumen.
Resumen El catálogo 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, actualizándolos a medida que se modifica la estructura de la base de datos. • Los usuarios pueden consultar las tablas del sistema para hallar información 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 organización de las tablas del sistema varían 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 estándar SQL2 no exige que el SGBD tenga realmente un conjunto de tablas del sistema, pero define un conjunto de vistas estándar del catálogo para los productos que proclaman niveles superiores de conformidad con SQL2.
Parte V
PROGRAMACiÓN CON Sal
Además de su papel como lenguaje de acceso a datos, SQL admite el acceso a bases de datos mediante programas de aplicación. Los capítulos 17 al 19 describen las características especiales de SQL y las técnicas que se usan para programar con SQL. El Capítulo 17 describe SQL incorporado. la técnica de programación más antigua, y aún admitida por muchos productos. usa para SQL dinámico, una forma avanzada de SQL incorporado que construir herramientas de bases de datos de propósito general, se describe en el Capítulo 18. El Capítulo 19 describe una alternativa a SQL incorporado -la interfaz de llamada a funciones proporcionada por muchos productos SGBD populares, con creciente popularidad.
se
i
CAPíTULO
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 programación 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 idéntico 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 también están disponibles de manera automática 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 capítulo resume los tipos de SQL para programación 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.
",
Técnicas de programación en SOL
}I
.:,
SQL es un lenguaje y puede utilizarse para programación, pero sería incorrecto llamar a SQL lenguaje de programación. SQL carece incluso de las características más primitivas de los verdaderos lenguajes de programación. No tiene ningún modo de declarar las variables, ninguna instrucci6n GOTO, ninguna instrucción IF para comprobar las condiciones, ninguna instrucci6n FOR, DO ni WHILE para crear bu-
481
~
482
Capítulo 17: SOL incorporado
SOL Manual de referencia
eles, ninguna estructura de bloques, elc. SQL es un sub,lenguaje d~ bases de d~t~s que maneja tareas de gestión 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 programación, como COBOL, PUl, FORTRAN, Pascal o C. y luego añadir SQL al programa. . El eSlándar SQL de ANSUISO inicial se ocupaba excluSIvamente de esle empleo de SQL para la programación. De hecho. ni siquiera incluía la io.strucción SELECT interactiva que se describe en los capítulos 6 a 9. S6lo especlficaba la instrucción SELECT para programación que se describe más adelante en el ap~ tado «Recuperación de datos con SQL incorporado». El eSlándar SQL2, pubh-. cado en 1992, amplió su ámbito para incluir el SQL mteractIvo (denommado l/amada directa a SQL en el estándar) y formas más avanzadas del SQL para programación (las posibilidades dinámicas de SQL que se describen en el Capítulo 20). . Los fabricantes de bases de datos comerciales de SQL ofrecen dos téCnIcas básicas para el empleo de SQL en los programas de las aplicaciones:
• SQL incorporado. En este enfoque las instrucciones de SQL se incorporan directamente al código fuente del programa, entremezclado con las demás instrucciones del lenguaje de programación. Se utilizan instrucciones especiales de SQL incorporado para recuperar datos para el programa. Un precompilador especial de SQL acepta el código fuente combinado Y. junto con otras herramientas de programación, lo convierte en un programa ejecutable. • Interfaz para la programación de aplicaciones. En este enfoque el pro· grama se comunica con el SGBD mediante un conjunto de llamadas a funciones denominado interfaz para la programación 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 ningún precompilador especial.
483
S~rver, Microsoft introdujo la conectividad abierta de bases de datos (O D .. ODBC) , otra . pen arabase eonneCtlVlty, 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 añadidos de ser mdependlente de las bases de datos y de permitir el acceso concurrente a dos o más marcas de SGBD mediante una API común. Más 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 incorporación se hallan hoy en día en uso. En general. los programadores. que utilizan l~nguajes de programación antiguos, como COBOL y ensamblador, tienden a prefenr el enfoque del SQL incorporado. Los programadores que utilizan lenguajes más 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 programación ofrecidas por algunos de los principales prnductos de SGBD basados en SQL:
DBMS
API a la que se pueden realizar llamadas
Soporte de lenguajes de SQL incorporado
DB2
ODBC, IDBC
APL, ensamblador, BASIC, COBOL, FORTRAN, Java, PUl
Informix
ODBC, IDBC
C,COBOL
Microsoft SQL Server
DB Library (dblib), ODBC
C
MySQL
(propietaria), ODBC. IDBC, Perl, PHP, Te!. .. Interfaz de llamadas de Orade (Orade eaIl Interface, OC!) ODBC,
Ninguno
Orade
C~api
C, COBOL, FORTRAN, Pascal, PUl, Java
IDBC
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 también en los años ochenta del siglo pasado. El estándar ANSI/ISO onglOal para SQL sólo especificaba un módulo de lenguaje para el SQL para programación muy poco práctico, pero los productos comerciales de SQL siguieron utilizando el estándar de facto de IBM. En 1989, el estándar ANSUISO se amplió para incluir una definición del modo de incorporar las instrucciones de SQL en los lenguajes de programación Ada, C, COBOL, FORTRAN, Pascal y PUl, siguiendo esta vez el enfoque de IBM. El estándar SQL2 continuó esta especificación. En paralelo con esta evolución del SQL incorporado, varios fabricantes de SGBD que se centraron en los sistemas de minicomputadoras introdujeron en los años ochenta API para las bases de datos a las que se podía realizar llamadas. Cuando se introdujo el SGBD Sybase, sólo ",~ •..;cía una API al que se podían realizar llama· das. SQL Server de Microsofl, que procede del SGBD Sybase, también utilizaba de manera exclusiva el enfoque de las APIs. Poco después del lanzamiento de SQL
Sybase
DB Library (dblib), ODBC, IDBC
C, COBOL
Las técnicas básicas de SQL incorporado, denominado SQL estático. se describen en este capítulo. Algunas características avanzadas de SQL incorporado, denominado SQL dinámico, se estudian en el Capílulo 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 Capítulo 21.
Procesamiento de instrucciones en el SGBD Para comprender cualquiera de las técnicas del SQL para programación resulta útil entender un poco mejor el modo en que el SGBD procesa las instrucciones de
484
Capitulo 17: SOL incorporado
SOL. Manual de referencia
SQL. Para procesar una instrucción de SQL, el SOBO recorre cinco etapas, que pueden verse en la Figura 17.1: 1.
2.
El SGBD comienza analizando la instrucción de SQL. Divide la instrucción en las palabras que la componen, se asegura de que tiene un verbo válido. cláusulas legales, etcétera. Los errores de sintaxis y los de escritura pueden detectarse en esta etapa. El SGBD valida la instrucción. Compara la instrucción con el catálogo del sistema. Comprueba si existen en la base de datos todas las tablas mencio-
3.
4.
5.
Introducción a SOL
5ELECT A,B,C FROM X,Y WHERE A<5000 AND c::::'ABC'
t Análisis de la instrucción
t Validación de la instrucción
t Optimización de la instrucción
+
....
-
t Generación del plan de aplicación
Plan
t
Forma binaria de la instrucción de Sal
485
nadas en la instrucción, 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 semánticos se detectan en esta etapa. El SOBD optimiza la instrucción. Explora varias maneras de ejecutar la instrucción. Comprueba si se puede utilizar algún índice para acelerar una búsqueda, si el SOBD debe aplicar antes una condición de búsqueda a la Tabla A y luego reunirla con la Tabla B o comenzar con la reunión y utilizar la condición de búsqueda más tarde, o si se puede evitar una búsqueda 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 aplicación de la instrucción. El plan de aplicación es una representación binaria de los pasos necesarios para ejecutar la instrucción; es el equivalente para el SGBD del código ejecutable. Finalmente, el SGBD lleva a cabo la instrucción ejecutando el plan de aplicación.
Obsérvese que las etapas de la Figura 17.1 varían en el grado de acceso a la base de datos que necesitan y en la cantidad de tiempo de CPU que emplean. El análisis de las instrucciones de SQL no necesita el acceso a la base de datos y suele poder hacerse muy rápidamente. La optimización, por su parte, es un proceso muy intensivo en CPU y necesita el acceso al catálogo del sistema de la base de datos. Para consultas complejas a varias tablas puede que el optimizador explore más 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 errónea suele ser tan alto en comparación con el coste de realizarla de manera correcta (o, como mínimo, de una manera mejor) que el tiempo empleado en la optimización se recupera con creces con la mayor velocidad de ejecución de la consulta. Cuando se escribe una instrucción 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 ningún fragmento del procesamiento-. En el SQL para programación, sin embargo, la situación es bastante diferente. Parte de las primeras etapas pueden realizarse en el momento de la compilación, mientras el programador desarrolla el programa. Esto deja únicamente las últimas etapas para realizarlas en el momento de la compilación, mientras el usuario ejecuta el programa. Al utilizar SQL para programación, todos los productos de SGBO intentan pasar todo el procesamiento posible al momento de la compilación, ya que, una vez desarrollada la versión definitiva del programa, los usuarios pueden ejecutarla millares de veces en una aplicación de producción. En concreto, el objetivo es pasar la optimización al momento de la compilación siempre que resulte posible.
t Ejecución del plan de aplicación
Figura 17.1.
Procesamiento de una instrucción de SOL por el SGBD.
Conceptos de SOL incorporado La idea central del SQL incorporado es entremezclar las instrucciones de SQL en los programas escritos en lenguajes de programación anfitriones, como C, Pascal,
486
SOL. Manual de referencia
COBOL, FORTRAN, PUl o ensamblador. SQL incorporado utiliza las técnicas siguientes para incluir las instrucciones de SQL: • Las instrucciones de SQL se entremezclan con las instrucciones del lenguaje anfitrión 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 programación 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 también 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 recuperación de valores NULL de la base de datos. • Varias instrucciones nuevas de SQL, que son exclusivas del SQL incorporado, se añaden 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 técnicas de SQL incorporado, pero no todas. El programa pide al usuario el número de una oficina. recupera la ciudad, la región, las ventas y el objetivo de la oficina y los muestra en ]a pantalla. No hay que preocuparse si el programa parece extraño, ni si no se pueden comprender todas las instrucciones que contiene antes de leer el resto del capítulo. Uno de los inconvenientes del enfoque del SQL incorporado es que el código fuente de los programas se convierte en una mezcla impura de dos lenguajes diferentes, lo que hace que el programa sea difícil de comprender sin formación tanto en SQL corno en el lenguaje de programación. Otro inconveniente es que el lenguaje SQL incorporado utiliza estructuras de SQL que no se utilizan en el SQL interactivo, como la instrucción WHENEVER y la cláusula INTO de la instrucción SELECT -que se utilizan en este programa.
Capítulo 17: SOL incorporado
main() {
exec sql include sqlca; exec sq1 begin declare section; int numoficina; /* número de la oficina (obtenido del usuario) */ char nombreciudad(16]; /* nombre de la ciudad recuperado ./ char
nombreregion[~l);
/- nombre oe la región recuperaoo
/* Configuración del procesamiento de errores */ exec sq1 whenever sq1error goto query_error; exec sq1 whenever not found goto bad-number; /* pide al usuario el número de oficina */ printf(-Introduzca el número 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(-Región: %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("Número de oficina no válido.\n"); exit{) ;
Los programas de SQL incorporado contienen una mezcla de instrucciones de SQL y del lenguaje de programación, por lo que no pueden remitirse directamente al compilador del lenguaje de programación. 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:
Figura 17.2.
El programa fuente de SQL incorporado se remite al precompilador de SQL, una herramienta de programación. El precompilador explora el prograina, busca las instrucciones de SQL incorporado y las procesa. Se ne-
~I
float valobjetivo; /~ objetivo y ventas recuperados */ float valventas; /. objetivo y ventas recuperados ./ exec sq1 end declare section;
Desarrollo de un programa SOL incorporado
1.
487
2.
Programa típico de SOL incorporado.
cesita un precompilador diferente para cada lenguaje de programación 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
3.
4.
5.
SOL. Manual de referencia
Capítulo 17: SOL incorporado
incorporado. En su lugar el precompilador coloca llamadas a las rutinas privadas del SOBD que ofrecen el enlace en tiempo de ejecución entre el programa y el SOBD. Generalmente, los nombres y las secuencias de llamada de estas rutinas sólo los conoce el precompilador y el SOBD; no se trata de una interfaz pública 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 estándar para el lenguaje de programación anfitrión (el compilador de e o de COBOL). El compilador procesa el código fuente y genera como resultado código objeto. Obsérvese que esta etapa no tiene nada que ver con el SOBD ni con SQL. El enLazador (linker) acepta los módulos 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 están las rutinas privadas del SGBD que se describen en la Etapa 2. El módulo 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 aplicación para cada instrucción. El resultado es un plan de aplicación combinado para todo el programa, que representa una versión ejecutable por el SGBD de las instrucciones de SQL. El programa BIND almacena el plan en la base de datos, normalmente asignándole el nombre del programa de aplicación que lo creó.
Programa fuente de SQl incorporado
----- ------
El ciclo de desarrollo del SQL incorporado puede parecer engorroso, y es más incómodo 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-
e
..
1
Precompilador
Programa fuente despojado
1
Módulo de solicitud a la base de datos
.. ..
.. ..
Compilador
BIND
Código objeto
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 análisis de las instrucciones (el primer paso) y la utilidad BIND trata la comprobación, la optimización y la generación 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 compilación. Sólo la quinta etapa, la ejecución real del plan de ejecución, sigue haciéndose en el momento de la ejecución. 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 aplicación ejecutable. Almacenado en la base de datos con el formato esperado por el SOBD
489
ibliote,
SGSD
..
Plan aplicad
..
Enlazador
..
'rogram 'ecutabl,
Figura 17.3.
Proceso de desarrollo del SOL incorporado.
ta invisible para el programador de la aplicación. El proceso tiene varias ventajas importantes desde el punto de vista del SGBD, que se muestran a continuación.
• La mezcla de instrucciones de SQL y del lenguaje de programación en el programa fuente del lenguaje SQL incorporado es una manera efectiva de
490
SOL. Manual de referencia
combinar los dos lenguajes. El lenguaje de programación anfitrión 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 demás estructuras. • El empleo del precompilador implica que el trabajo intensivo en cálculo del análisis y de la optimización puede realizarse durante el ciclo de desarrollo. El programa ejecutable resultante es muy eficiente en el empleo de los recursos de la CPU. • El módulo 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 aplicación 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 aplicación y lo instala en la base de datos, el programa de aplicación puede utilizarlo sin que haya que volver a compilarlo. • La verdadera interfaz de tiempo de ejecución del programa con las rutinas privadas del SGBD quedan completamente ocultas al programador de la aplicación. El programador trabaja con SQL incorporado en el nivel del código fuente y no necesita preocuparse de otras interfaces más complejas.
Ejecución 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 aplicación 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 aplicación: l.
2. 3.
4.
Cuando se pide al sistema informático 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 aplicación del programa. Para cada instrucción de SQL incorporado, el programa llama a una o varias rutinas del SGBD y solicita la ejecución de la instrucción correspondiente en el plan de aplicación. El SGBD busca la instrucci6n, ejecuta esa parte del plan y devuelve el control al programa. La ejecuci6n continúa de esta manera, con el ejecutable y el SGBD cooperando para llevar a cabo la tarea definida por el programa original de SQL incorporado.
Capítulo 17: SOL incorporado
491
S9~ in~eractivo. ~e pue~e es~ribir cualquier instrucción 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, más 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 aplicación correspondiente. Puede parecer extraño que se considere el identificador de usuario de la persona que ejecutó el programa BIND (o, más en general, la persona que desarrolló el programa de aplicación o lo instal6 en el sistema informático), 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 aplicación 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 ejecución 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. Obsérvese que el plan puede actualizar las tablas aunque JaSE no tenga los privilegios necesarios. No obstante, las actualizaciones que pueden llevarse a cabo sólo son las que se han codificado de manera explícita 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 protección de seguridad para los planes de aplicación. Para los que no lo hacen, Jos privilegios del usuario que ejecuta el programa de SQL incorporado determinan los privilegios del plan de aplicación 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.
Seguridad en el momento de la ejecución
Reenlace automático
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
Obsérvese que el plan de aplicación 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
SOL. Manual de referencia
base de datos. Si la estructura se modifica más adelante (por ejemplo. si se descarta algún índice o se elimina una columna de una tabla), puede que los planes de aplicación que hagan referencia a las estructuras modificadas no sigan siendo válidos. Para tratar esta situación, el SOBO suele almacenar, junto con el plan de aplicación, una copia de las instrucciones de SQL originales que lo generaron. El SGBD también realiza un seguimiento de todos los objetos de la base de datos de los que depende cada plan de aplicación. Si una instrucción del LDD modifica alguno de estos objetos, el SGBD puede buscar los planes que dependen
de ese objeto y marcarlos de manera automática como no válidos. La siguiente ocasi6n en que el programa intente utilizar el plan, el SGBD puede detectar la situación y, en la mayor parte de los casos, volverá a enlazar las instrucciones de manera automática para generar una nueva imagen enlazada. Corno el SOSD ha conservado una gran cantidad de información sobre el plan de aplicación, puede hacer este nuevo enJace automático de manera completamente transparente para el programa de aplicación. No obstante, puede que las instrucciones de SQL tarden mucho más en ejecutarse mientras se vuelve a enlazar el plan que cuando sólo hay que ejecutarlo. Aunque el SGSD puede volver a enlazar de manera automática un plan cuando se modifica aJguna de las estructuras de las que depende, no suele detectar de manera automática Jas modificaciones de la base de datos que pueden hacer posible un plan mejor. Por ejemplo, supóngase que un plan utiliza la exploración secuencial de una tabJa para buscar filas concretas porque no existía ningún índice adecuado cuando se enlazó el plan. Es posible que una instrucción CREATE INDEX posterior cree un índice adecuado. Para aprovechar la nueva estructura hay que ejecutar de manera explícita el programa BIND con el fin de volver a enlazar el plan.
Instrucciones simples de SOL incorporado Las instrucciones más 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, considérese esta instrucción 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 instrucción 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 características más básicas del SQL incorporado: • Las instrucciones de SQL incorporado aparecen en mitad de las instrucciones det" lenguaje de programación anfitrión. No suele impo~ar si las instruc-
Capítulo 17: SOL incorporado
493
maine } (
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"Eliminación de representantes con cuotas bajas.\n");
/*Ejecuta la instrucción de SQL */ exec sq1 de1ete from representantes where ventas < 150000.00; Muestra otro mensaje ~/ printf("Eliminación concluida.\n"); exit(): /~
Figura 17.4,
Programa de SOL incorporado escrito en C.
ciones de SQL están escritas en mayúsculas o en minúsculas; hi práctica más habitual es seguir el estilo del lenguaje anfitrión. . • Cada instrucción de SQL incorporado comienza con un introductor que la marca como instrucción de SQL. Los productos de SQL de IBM utilizan el introductor EXEC SQL para la mayor parte de los lenguajes anfitriones, y el estándar SQL de ANSIIIS02 también lo especifica. Algunos productos de SQL incorporado siguen adirnitiendo otros introductores en aras de -la compatibilidad con versiones anteriores. • Si una instrucción de SQL incorporado se extiende por varias líneas, se utiliza la estrategia del lenguaje anfitrión para la continuación de las instrucciones. Para los programas de COBOL, PUl YC no se necesita ·ningún carácter especial de continuación. Para los programas de FORTRAN la segunda línea de la instrucción y las posteriores deben tener un carácter de continuación en la columna 6. • Cada instrucción de SQL incorporado concluye con un terminador que señala el final de la instrucción de SQL. El terminador varía con el estilo del lenguaje anfitrión. En COBOL el terminador es la cadena de caracteres END-EXEC., que concluye con un punto, al igual que otras instruccio-
494
Capítulo 17: SOL incorporado
SOL. Manuaf de referencia
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,
JEFE INTEGER. CUOTA MONEY,
VENTAS MONEY NOT NULL) END-EXEC. PROCEDURE
DIVISION.
MUESTRA UN HENSAJE PARA EL USUARIO DISPLAY "Eliminación de representantes con cuotas bajas,-, EJECUTA LA INSTRUCCIÓN SQL EXEC SQL DELETE FROM REPRESENTANTES WHERE CUOTA < 150000
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
495
TABLE INTEGER NOT NULL, VARCHAR(15) NOT NULL, INTEGER, INTEGER, VARCHAR(lO) , DATE NOT NULL, INTEGER. MONEY, MONEY NOT NULL)
MUESTRA UN MENSAJE PARA EL USUARIO WRITE (6,100) 'Eliminación de representantes con cuotas bajas .. EJECUTA LA INSTRUCCIÓN DE SQL EXEC SQL DELETE FROM REPRESENTANTESS WHERE CUOTA < 150000 e MUESTRA OTRO MENSAJE WRITE (6,100) 'Eliminación concluida.' RETURN ENO
END EXEC.
MUESTRA OTRO MENSAJE DISPLAY -Eliminación concluida.",
Figura 17.5.
Programa de Sal incorporado escrito en COBOL.
nes de COBOL. Para PUl y C el terminador es un punto y coma (;l, que también es el carácter de terminación de las instrucciones de estos lenguajes. En FORTRAN las instrucciones de SQL incorporado concluyen cuando ya no se indica ninguna línea de continuación. La técnica de incorporación mostrada en las tres figuras funciona para cualquier instrucción de SQL que (al no dependa del valor de las variables del lenguaje anfitrión para su ejecución 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 características de SQL incorporado que el programa de la Figura 17.4. Por coherencia, todos los demás ejemplos de programas de este libro utilizarán el lenguaje de programación e, excepto cuando se ilustre una característica de algún lenguaje anfitrión concreto.
Figura 17.6.
Programa de SOL incorporado escrito en FORTRAN.
Declaración de tablas En los productos SQL de IBM la instrucción incorporada DECLARE TABLE, que puede verse en la Figura 17.8, declara una tabla a la que harán referencia una o varias instrucciones de SQL incorporado del programa. Se trata de una instrucción opcional que ayuda al precompilador en su tarea de análisis y validación de las instrucciones de SQL incorporado. Utilizando la instrucción DECLARE TABLE el programa especifica de manera explicita sus suposiciones sobre las columnas de la tabla y el tipo y tamaño 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 declaración de la tabla. Los programas de las Figuras 17.4, 17.5 Y 17.6 utilizan la instrucción DECLARE TABLE. Es importante destacar que la instrucción sólo aparece con fines de documentación y para su empleo por el precompilador. No se trata de ninguna instrucción ejecutable y no hace falta declarar las tablas de manera explícita antes de referirse a ellas en las instrucciones de DML o de DDL incorporado. No obstante. el empleo de la instrucción DECLARE TABLE hace que los programas tengan más
496
SOL. Manual de referencia
Capítulo 17: SOL incorporado
documentación interna y sean más sencillos de mantener. Todos los productos de SQL desarrollados por IBM admiten la instrucción DECLARE TABLE, pero la mayor parle de los demás productos de SQL no, y sus precompiladores generarán un mensaje de error si se utiliza.
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,
*' Manejo de errores Cuando se escribe una instrucción de SQL que genera un error, el programa interactivo de SQL muestra un mensaje de error, cancela la instrucción y pide al usuario que escriba otra instrucción. En SQL incorporado, el manejo de los errores pasa a ser responsabilidad del programa de aplicación. Realmente, las instruccio~ nes de SQL incorporado pueden producir dos tipos de errores diferentes:
• Errores en el momento de la compilación. 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 aplicación. • Errores en el momento de la ejecución. Los intentos de inserción de datos no válidos o la carencia de permiso para la actualización de una tabla sólo puede detectarse en el momento de la ejecución. Los errores de este tipo debe detectarlos y manejarlos el programa de aplicación.
/* Inserta dos filas; una por cada región */ exec sql iosert into regioos values ('Este'. 'Navarra', 106. 0.00. 0.00); exec sgl iosert ioto regiones values ('Oeste', 'León', 108, 0.00, 0.00); printf(-Tabla rellena.\n");
exit ();
Figura 17.7.
Empleo de SOL incorporado para crear tablas.
En los programas de SQL incorporado, el SOBn comunica los errores en el momento de la ejecución al programa de aplicación mediante la devolución de un código de error. Si se detecta algún error, se dispone de una descripción más amplia del error y de otra información sobre la instrucción recién ejecutada mediante información adicional de diagnóstico. Las primeras implementaciones de SQL incorporado de IBM definían un mecanismo de comunicación 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- también estaba definida en el estándar ANSIIISO original para SQL. El estándar SQL2, publicado en 1992, definió un mecanismo de comunicación 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.
r-- DECLARE ¡nOmbre-tabla, TABLE Lnombreovista ~
4(lnombre.co,umna tipo-datos l
:~ NOT NULL
I
WITH DEFAULT
----------f Figura 17.8.
497
Diagrama sintáctico de la instrucción DECLARE TABLE.
~
I I
-----.e
Manejo de errores con SQLCODE
Con este esquema, avanzado por los primeros productos de IBM, el SGBD comunica la información 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
Capítulo 17: SOL incorporado
SOL. Manual de referencia
aplicación puede determinar el éxito o el fallo de las instrucciones de SQL incorporado y actuar en consecuencia. Obsérvese en las figuras 17.4, 17.5, 17.6 Y 17.7 que la primera instrucción de SQL incorporado del programa es INCLUDE SQLeA. E~ta i~strucción indica al pre. . . compilador de SQL que debe incluir el área de comUnICaCIOnes de SQL en el programa. El contenido concreto de SQLCA varía ~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 definición de SQLeA utilizada por las bases de datos de IBM. La parte más 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.
struct sqlca { unsigned char long long short unsigned char
sqlcaid[8]; /* la cadena de caracteres "SQLCA " */ sqlcabc; /* longitud de SQLCA, en bytes */ sqlcode; /* código 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]; /* información de diagnóstico */ long sqlerrd[6]; /* varias cuentas y código de error */ unsigned char sqlwarn[8]; /* array de banderas de advertencia */ unsigned char sqlext[8]; /* ampliación del array sqlwarn */
499
Cuando el SGBD ejecuta cada instrucción de SQL incorporado, define el valor de la variable SQLCODE en SQLCA para indicar el estado de realización de la instrucción: • Un SQLCODE de cero indica el cumplimiento con éxito de la instrucción, sin ningún error ni advertencia. • Un valor negativo de SQLCODE indica un error grave que evitó que se ejecutara la instrucción de manera correcta. Por ejemplo, un intento de actualización de una vista sólo de lectura generaría un valor negativo de SQLCODE. Se asigna un valor negativo diferente para cada error del momento de la ejecución que pueda producirse. • Un valor positivo de SQLCODE indica una condición de advertencia. Por ejemplo, el truncado o el redondeo de un elemento de datos recuperado por el programa generaría una advertencia. Se asigna un valor positivo diferente para cada advertencia del momento de la ejecución que pueda producirse. La advertencia más frecuente, con un valor de + 100 en la mayor parte de las implementaciones y en el estándar 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 más filas que recuperar. Como cada instrucción ejecutable de SQL incorporado puede, en teoría, generar un error, los programas bien escritos comprueban el valor de SQLCODE tras cada instrucción 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.
#define SQLCODE sqlca.sqlcode /* código de estado de SQL */ /* Una
'W' en cualquiera de los campos de SQLWARN indica una condición de advertencia; en caso contrario, cada uno de estos campos contiene un espacio en blanco */
/ ' bandera de advertencia principal ' / / ' cadena de caracteres truncada ,/
/' NULLs eliminados de la función de la columna ' / / ' demasiadas variables del anfitrión o demasiado pocas ,/ / ' preparadas UPDATE/DELETE sin WHERE ' / /' incompatibilidad de SQL/DS con DB' ' / /' fecha no válida en una expresión aritmética ' / /' reservada ' /
El área de comunicaciones de SOL [SOL Communications Area "(SQLCA)] de las bases de datos de IBM.
exec sql dele te from representantes where cuota < 150000; if (sqlca.sqlcode < O) gato rutina_error;
error printf("ErrOr de SQL: %ld\n, exit ();
rut~na
Figura 17.10.
Fragmento de un programa de res en SQLCODE.
e
sqlca.sqlcode);
con comprobación de los erro-
SOO
Capítulo 17:
SOL. Manual de referencia
saL
incorporado
S01
SQLSTATE, y el código de error asignado a cada error. Para cumplir el estándar 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
siguen funcionando y pueden escribirse programas nuevos SQLSTATE.
PRINT-CODE Pie SZ (91 .
EXEC SQL DELETE FROM REPRESENTANTES WHERE CUOTA < 150000 END EXEC. IF SQLCODE NOT = ZERO GOTO ERRDR-ROUTINE.
ERROR-ROUTINE. MOVE SQLCODE TO PRINT-CODE. DISPLAY PRINT_MESSAGE.
Figura 17.'1.
SQLCODE
que utilicen los códigos de error normalizados de La variable SQLSTATE consta de dos panes:
Fragmento de un programa de COSOL con comprobaeión de errores de SQLCODE.
Manejo de errores con SQLSTATE
Para cuando se estaba escribiendo el estándar SQL2, prácticamente 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 había ninguna normalización de los números de error utilizados por los diferentes productos para comunicar condiciones de error idénticas o parecidas. Además, debido a las diferencias significativas entre las implementaciones de SQL permitidas por el estándar SQLI, podían darse diferencias considerables en los errores de una implementación a otra. Finalmente, la definición de SQLeA variaba de manera significativa de una marca de SGBD a otra, y todas las marcas principales tenían una gran base instalada de aplicaciones que fallarían 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 algún estándar, los redactores del estándar SQL2 adoptaron un enfoque diferente. Incluyeron el valor de error de SQLCODE, pero lo identificaron con una característica censurada, lo que significa que se consideraba obsoleta y se eliminaría del estándar en algún momento posterior. Para ocupar su puesto introdujeron una nueva variab!e de error, denominada SQLSTATE. El estándar también especifica, con detalle, las condiciones de error que pueden comunicarse mediante la variable
• Una clase de error de dos caracteres que identifica la clasificación general del error (por ejemplo, error de conexión, error de datos no válidos 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 válidos, la subclase de error puede identificar un error de división por cero, un error de valor numérico no válido o datos de fecha no válidos. Los errores especificados en el estándar SQL2 tienen un código 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 violación de una restricción de integridad (como la definición de una clave externa) se indica mediante la clase de error 23. El retroceso de una transacción se indica mediante la clase de error 40. Dentro de cada clase de error los códigos estándar de las subclases también siguen las mismas restricciones de números O letras iniciales. Por ejemplo, dentro de la clase de error 40 (retroceso de las transacciones), los códigos de subclase son 001 para los fallos en la serialización (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 instrucción de SQL (por ejemplo, cuando se interrumpe la conexión de red o un servidor falla antes de que se complete la instrucción). La Figura 17.12 muestra el mismo programa de de la Figura 17.10. pero utiliza para la comprobación de los errores la variable SQLSTATE, en lugar de
e
SQLCODE.
P
El estándar reserva de manera específica los códigos 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 específicos de cada implementación que no están estandarizados. Aunque esto permite que siga habiendo diferencias entre las marcas de SGBD. todos los errores más frecuentes provocados por las instrucciones de SQL se incluyen en los códigos 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.:más problemáticas se va eliminando poco a poco. El estándar SQLZ proporciona información adicional sobre errores y diagnóstico mediante la nueva instrucción GET DIAGNOSTICS, que puede verse en la Figura 17.13. La instrucción permite que los programas de SQL incorporado recuperen uno O varios elementos de información sobre la instrucción de SQL recién ejecutada o sobre una condición de error recién generada. El soporte de la instrucción GET DIAGNOSTICS es obligatorio para el cumplimiento intermedio O completo del
502
SOL. Manual de referencia
Capítulo 17: SOL incorporado
503
Para recuperar la información del nivel de las instrucciones y determinar el número de errores de diagn6stco:
exec sql delete from representantes where cuota < 150000; if (strcmp(sqlca.sqlstate. ·00000-') goto error_routine;
1- GET
DIAGNOSTICS
variable
anlí triÓn =
1NUMBER-------1 -------¡¡,-,-.. MORE
COMMAND_FUNCTION -
DYNAMIC_FUNCTION -
ROW_COUNT
error_routine: printf("Error de SQL: %s\n",sqlca.sqlstate); exit () ; Para recuperar la información sobre un error de diagnóstico concreto; GET DIAGNOSTICS EXCEPTION
'---.,,-
Figura 17.12.
Fragmento de un programa de
número_error] variable : - - CONDITION_NUHBER
anfitrión
e con comprobación de errores de
SQLSTATE.
estándar, 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 instrucción GET DIAGNOSTICS.
Para los programadores se vuelve rápidamente tedioso escribir programas que comprueben de manera explícita el valor de SQLCODE tras cada instrucción de SQL incorporado. Para simplificar el manejo de los errores, SQL incorporado cuenta con la instrucción WHENEVER, que puede verse en la Figura 17.15. La instrucción WHENEVER es una directriz para el precompilador de SQL. no una instrucción ejecutable. Indica al precompilador que debe generar de manera automática código de manejo de errores a continuación de cada instrucción ejecutable de SQL incorporado, y especifica lo que debe hacer el código generado. La instrucción WHENEVER se puede utilizar para indicar al precompilador el modo de manejar tres condiciones de excepción diferentes: Figura 17.13.
indica al precompilador que genere código para manejar los errores (valores negativos de SQLCODE). WHENEVER SQLWARNING indica al precompilador que genere código para manejar las advertencias (valores positivos de SQLCODE). WHENEVER NOT FOUND indica al precompilador que genere código para manejar una advertencia concreta -la advertencia generada por el SGBD cuando el programa recupera resultados de consultas y ya no quedan más. Este empleo de hi instrucción WHENEVER es privativo de las instrucciones SELECT y
Diagrama sintáctico de la instrucción GET DIAGNOSTICS.
• WHENEVER SQLERROR • •
FETCH que devuelven una sola fila, y se describe en el apartado «Consultas sobre una sola fila».
Obsérvese que el estándar SQL2 no especifica la fonna SQLWARNING de la instrucción WHENEVER. pero la mayor parte de los productos comerciales de SQL la incluyen.
504
Capítulo 17: SOL incorporado
SOL. Manual de referencia
r-WHENEVER1SQLERROR3L[ I~
ejecuta la instrucción DELETE Y comprueba si hay errores */ exec sql delete froID representantes where cuota < 150000; i i (strcmp{sqlca.sqlstate, "00000")) goto error_routine:
Figura 17.15.
/* DELETE con éxito; comprueba el número de filas eliminadas */ exec sql get diagnostics :numrows : ROW_COUNT; printf("%ld filas eliminadas\n",nurnrows);
505
CONTINUE~.
SQLWARNING
GOTa ----.---
NOT FOUNO
GO TO-l
Diagrama sintáctico de la instrucción
etiqueta
J
WHENEVER.
errores de la instrucción INSERT incorporada dan lugar a una bifurcación hacia error2. Como muestra este ejemplo. el empleo principal de la forma WHENEVER/CONTlNUE de la instrucción es cancelar el efecto de una instrucción WHENEVER anterior.
error_routine: /* Determina el número de errores comunicados */ exec sql get diagnostics :count ~ NUMBER; for (i=1; i
exec sql whenever sqlerror goto error1; exec sql delete from representantes where cuota < 150000;
}
exit ();
exec sql delete from clientes where l~m~te_credito < 20000; exec sql whenever sqlerror continue;
Figura 17.14.
Fragmento de programa de
e
exec sql update representantes set cuota: cuota * 1.05;
Para cualquiera de estas tres condiciones se puede indicar al precompilador que genere código que realice una de estas dos acciones: • WHENEVER/GOTO
indica al precompilador que genere una bifurcación en la
'1
etiqueta especificada, que debe ser la etiqueta de-una instrucción o el núme-
errorl; printf ("Error de SQL en DELETE; tdl \n", exit l) ;
ro de una instrucción del programa. indica al precompilador que permita que continúe el flujo de control del programa hasta la siguiente instrucción del lenguaje anfitrión.
• WHENEVER/CONTlNUE
sqlca. sqIcodel ;'
error2; printf(~Error
La instrucción WHENEVER es una directriz para el precompilador, y su efecto puede anularse con otra instrucción 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 bifurcación hacia error1 debido a la primera instrucción WHENEVER. Los errores de la instrucción UPDATE incorporada fluyen directamente hacia las siguientes instrucciones del programa. Los
de SOL en INSERT; tId\n",
exit ();
Figura 17.16.
1
Uso de la instrucción
WHENEVER.
sqlca.sqlcodel;
506
SOL. Manual de referencia
La instrucción
WHENEVER
Capítulo 17: SOL incorporado
507
hace mucho más sencillo el manejo de los errores del
SQL incorporado. y es más frecuente que la utilicen los programas de aplicación que main ()
el que comprueben directamente SQLCQDE o SQLSTATE. Hay que recordar, no obstante, que tras la aparición de una instrucción WHENEVER/GOTO el precompilador genera una prueba y una bifurcación hacia la etiqueta especificada para cada in~trucción de SQL incorporado que aparece a continuación. Hay que disponer el programa de modo
t exec sQl include sqlca; exec sql begin declare section; float importe;
que la etiqueta especificada sea un objetivo válido para las bifurcaciones a partir de
/* importe
usuario)
(obtenido del */
exec sql end declare section;
esas instrucciones de SQL incorporado. O utilizar otra instrucción WHENEVER para especificar un destino diferente o cancelar Jos efectos de WHENEVER/GOTD.
Pide al usuario el importe del incremento o disminución de las cuotas */ printf("Aumentar o disminuir las cuotas en:-}; scanf("'f", &importe); /*
Uso de variables del anfitrión
/* Actualiza la columna CUOTA de la tabla REPRESENTANTES */ exec sql update representantes set cuota: cuota + :importe;
Los programas de SQL incorporado de las figuras anteriores no ofrecen ninguna interacción real entre las instrucciones de programación 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, supóngase 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 instrucción UPDATE incorporada para modificar la columna CUOTA de la tabla REPRESENTANTES. El SQL incorporado admite esta posibilidad mediante el uso de variables del anfitrión. Las variables del anfitrión son variables del programa declaradas en el lenguaje anfitrión (por ejemplo, variables de COBOL o de C) a las que hacen referencia las instrucciones de SQL incorporado. Para identificar las variables del anfitrión 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 anfitrión 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 aplicación de ajuste de las cuotas utilizando una variable del anfitrión. El programa pide al usua-. rio el importe del ajuste y almacena el valor introducido en la variable denominada importe. A esta variable del anfitrión se hace referencia en la instrucción UPDATE incorporada. Conceptualmente, cuando se ejecuta la instrucción UPDATE. se obtiene el valor de la vatiable importe y se sustituye ese valor por la vatiable del anfitrión en la instrucción de SQL. Por ejemplo, si se introduce el importe 500 en respuesta a la petición, el SGBD ejecuta de hecho esta instrucción UPDATE:
/t Comprueba el resultado de la ejecución de la instrucción */ if {sqlqa.sqlcode != Ol printf("Error durante la actualización.\n*l; else printf("Actualización realizada con éxito.\n"};
exit{) ;
Figura 17.17.
Empleo de las variables del anfitrión.
Las variables del anfitrión pueden aparecer en las condiciones de búsqueda: exec sql delete from representantes where cuota < ;irnporte;
Las variables del anfitrión también pueden utilizarse en la cláusula VALUES de las instrucciones INSERT: exec sql insert into representantes (nurn_empl. nombre. cuota) values {116. 'Benito Rienda', :importeJ;
En cada caso, obsérvese que la variable del anfitrión es parte del aporte de datos del programa al SGBD; forma parte de la instrucción de SQL remitida al SGBD para su ejecución. Posteriormente. en el apartado «Recuperación de datos con SQL incorporado», se verá el modo en que las variables del anfitrión se utilizan también para recibir resultados del SGBD; reciben los resultados de las consultas proporcionados al programa por el SGBD. Obsérvese que las variables del anfitrión no pueden utilizarse en lugar de los identificadores de SQL. Este intento de uso de la variable del anfitrión nombrecol es ilegal:
exec sql update representantes set cuota = cuota + 500;
Las variables del anfitrión pueden aparecer en las instrucciones de SQL incorporado donde pueda aparecer una constante. En concreto, las variables del anfitrión pueden utilizarse en las expresiones de asignación: exec sql update representantes set cuota = cuota + : importe;
Cuando se utilizan variables del anfitrión en las instrucciones de SQL incorporado, hay que declararlas utilizando el método normal de declaración de variables del lenguaje de programación anfitrión. Por ejemplo, en la Figura 17.17, la variable del anfitrión importe se declara utilizando la sintaxis normal del lenguaje e (float importe;). Cuando el precompilador procesa el código fuente del programa LOma nota del nombre de cada variable que halla, junto con su tipo de datos y su tamaño. El precompilador utiliza esta información para generar más adelante el código correcto cuando descubre el empleo de la variable como variable del servidor en una instrucción de SQL. Las dos instrucciones de SQL incorporado BEGIN DECLARE SECTION y END DECLARE SECTION rodean las declaraciones de las variables del anfitrión, 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 atención 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 anfitrión en una sola sección de declaraciones. Generalmente, sin embargo, hay que declarar las variables del anfitrión en varios puntos del programa, especialmente en los lenguajes estructurados en bloques como C, Pascal y PUI. En este caso, cada descripción de una variable del anfitrión debe encerrarse entre un par de instrucciones BEGIN DECLARE SECTION/ END DECLARE SECTION.
Las instrucciones BEGIN DECLARE SECTION y END DECLARE SECTION son relativamente recientes para el lenguaje SQL incorporado. Se especifican en el estándar SQL de ANSI/ISO, y DB2 las exige en sus implementaciones de SQL incorporado más recientes. Sin embargo, DB2 y otras muchas marcas de SOBD no exigían históricamente las secciones de declaraciones, y algunos precompiladores de SQL no incluyen todavía las instrucciones BEGIN DECLARE SECTION y END DECLARE SECTION. En ese caso, el precompilador busca y procesa todas las declaraciones de variables del programa anfitrión. Cuando se utilice variables del anfitrión puede que el precompilador limite la flexibilidad e·n la declaración de las variables en el lenguaje de programación anfitrión. Por ejemplo, considérese el siguiente código fuente en lenguaje C: 'define TALLAGRANDEBUFFER 256
exec sql begin declare section; char buf~ergrande[BIGBUFSIZE+ll; exec sql end declare section;
509
Se trata de una declaración válida en C de la variable buffergrande. Sin embargo, si se intenta utilizar buffergrande como variable del anfitrión en instrucciones de SQL incorporado como la siguiente: exec sql update representantes set cuota = 300000
where nombre = :buffergrande;
muchos precompiladores generarán un mensaje de error, quejándose de la declaración ilegal de buffergrande. El problema es que algunos precompiladores no reconocen las constantes simbólicas, como TALLAGRANDEBUFFER. Sólo 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 están mejorando de manera continua, y el número de problemas por casos especiales como éste va disminuyendo. Las variables del anfitrión y los tipos de datos
Los tipos de datos admitidos por los SGBD basados en SQL y los admitidos por o FORTRAN suelen ser bastante diferentes. lenguajes de programación como Estas diferencias afectan a las variables del anfitrión porque desempeñan un papel dual. Por un lado, las variables del anfitrión son variables del programa, que se declaran utilizando los tipos de datos del lenguaje de programación y son manipuladas por las instrucciones del lenguaje de programación. Por otro lado, las variables del anfitrión se utilizan en las instrucciones de SQL incorporado para contener datos de la base de dalOs. Considérense las cuatro instrucciones UPDATE incorp<;>radas de la Figu'(3. 17..,...18. En la primera instrucción UPDATE, la columna JEFE tiene el tipo de.,datos INTEGER, por lo que varanfil debe declararse como variable entera de C. En la segunda instrucción, la columna NOMBRE tiene el tipo de datos VARCHAR, por lo que varanfí2 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 carácter null (O). En la tercera instrucción UPDATE la columna CUOTA tiene el tipo de datos MONEY. No hay un tipo de datos equivalente en C, y no admite ningún 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 automática el valor en coma flotante al formato MONEY del SGBD. Finalmente, en la cuarta instrucción 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 varanfí4 como array de datos de carácter 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 anfitrión debe escogerse con cuidado para que coincida con el uso que se les pretende dar
e
e
510
SOL. Manual de referencia
Capítulo 17: Sal incorporado
511
Tabla 17.1. Tipos de datos de SOL Tipo de
... .
exec sql begin declare seetion; 106; varanfil int "José Sánchez· ; char *varanfi2 150000.00; flaat varanfi3 ·Ol-JUN-1990"; char *varanfi4 exec sql end declare section;
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;
Figura 17.18.
Tipo de SQL Tipo de C
Tipo de COBOL FORTRAN
Tipo de PL/I
5MALLINT
short
PIe 59 (4) CQHP INTEGER*2
FIXED BIN(15l
INTEGER
long
PIe s9 (9)COMP
INTEGER*4
FIXED SIN()1)
REAL
float
COMP-l
REAL·4
BIN FLOAT(21)
DOUBLE PRECISION
double
COMP-2
REAL * 8
SIN FLOAT(53)
NUMERIC (p,S) DECIMAL (P,S)
double 1
PIe 59 (p- s)
REAL*SI
FIXED DEC(p,s)
CHAR(n)
char x[ n+1]2
PIe x (n)
CHARACTER"n
CHAR(n)
V9 (s) COMP-3
•
VARCHAR(n)
char x( n+1]2
Conv.nec. •
Conv.nec.
BIT(n)
char x[l]3
PIC X (1)
CHARACTER*L3
BIT(n)
BIT VARYING(n)
char x(lP
Conv. nec.
Conv. nec. •
BIT(n) VAR
DATE
Conv. nec.
Conv.
Conv. nec.
,
Conv. nec.
TIME
Conv.
Conv.
TlMESTAMP
Conv.
INTERVAL
Conv.
:varanfi4
, , nec. , nec. , nec.
Conv.
• , nec. , nec. , nec.
Conv. nec.
,
Conv. Conv.
, nec.
, nec.
Conv. nec.
,
CHAR(n) VAR
Conv. Conv.
, , nec. , nec.
Conv. nec.
,
NOlas: 1 El lenguaje anfitrión no admite los datos decimales empaquetados; la conversión con los datos de coma flotante pueden causar errores de truncamiento o de redondeo. 1 El estándar SQL especifica una cadena de caracteres de e con un terminador null; las implementaciones más antiguas de los SGBD devolvían un valor diferente de longitud en la estructura de datos. J La longitud de la cadena de caracteres del anfitrión (1) es el número de bits (n), dividido por los bits por carácter del lenguaje anfitrión (generalmente 8), redondeado. • El lenguaje anfitrión 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 conversión (conversión necesaria, Conv. nec.) a1desde los tipos de datos de cadenas de caracteres del lenguaje anfitrión con representaciones de texto de la fecha, la hora y los intervalos.
Variables del anfitrión y tipos de dato.
en las instrucciones de SQL incorporado. La Tabla 17.1 muestra los tipos de datos de SQL especificados en el estándar SQL de ANSIIIS02 y los tipos de datos correspondientes empleados ·en cuatro de los lenguajes de programación de SQL incorporado más populares, tal y como se especifican en el estándar.· El estándar especifica las correspondencias entre tipos de datos y las reglas de SQL incorporado para los lenguajes Ada. C. COBOL. FORTRAN. MUMPS. Pascal y PUl. Obsérvese, no obstante. que, en muchos casos, no hay una correspondencia biunívoca entre los tipos de datos. Además, cada marca de SGBD tiene sus propias idiosincrasias en los tipos de datos y sus propias reglas para la conversión de tipos de datos al emplear las variables del anfitrión. Antes de contar con un comportamiento concreto en la conversión de datos, consúltese la documentación de la marca específica de SGBD y léase con cuidado la descripción de cada lenguaje de programación ·que se vaya a utilizar.
Las variables del anfitrión y los valores NULL
La ~ayor parte de los lenguajes de programación 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 programación. SQL incorporado resuelve este problema permitiendo que cada variable del anfitrión tenga una variable indicadora del anfitrión acompañante. En
1
512
Capítulo 17: SOL incorporado
SOL. Manual de referencia
las instrucciones de SQL incorporado la variable del anfitrión 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 anfitrión contiene un valor válido y que hay que utilizar ese valor. • Un valor negativo del indicador significa que debe suponerse que la variable del anfitrión tiene un valor NULL; el valor real de la variable del anfitrión es irrelevante y no debe tenerse en cuenta. • Un valor positivo del indicador indica que la variable del anfitrión contiene un valor válido, que se puede haber redondeado o truncado. Esta situación sólo se produce cuando se recuperan datos de la base de datos, y se describe más adelante en el apartado «Recuperación de valores NULL». Cuando se especifican variables del anfitrión en instrucciones de SQL incorporado, se puede ubicar a continuación el nombre de la variable indicadora correspondiente. Los dos nombres de variable van precedidos por dos puntos. A continuación se puede ver una instrucción UPDATE que utiliza la variable del anfitrión importe con la variable indicadora acompañante importe_ind: exec sql update representantes set cuota ~ :importe :importe_ind. ventas where cuota < 20000.00;
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 «Recuperación de valores NULL».
Recuperación de datos con SOL incorporado
Si importe_ind tiene un valor no negativo cuando se ejecuta la instrucción el SGBD trata la instrucción como si fuera: :importe2
Si importe_ind tiene un valor negativo cuando se ejecuta la instrucción upel SGBD trata la instrucción como si fuera:
DATE,
exec sql update representantes set cuota = NULL, ventas where cuota < 20000.00;
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 explícita 1S NULL. Este par de instrucciones de SQL incorporado lleva a término la tarea intentada por la instrucción ilegal anterior:
:importe2
UPDATE,
exec sql update representantes set cuota ~ : importe, ventas where cuota < 20000.00:
513
:importe2
El par de variables fonnado por la variable del anfitrión y la variable indicadora pueden aparecer en la cláusula de asignación de una instrucción UPDATE incrustada (como se puede ver a continuación) o en la cláusula de valores de una instrucción INSERT incorporada. No se pueden utilizar variables indicadoras en las condiciones de búsqueda, por lo que la siguiente instrucción de SQL incorporado es ilegal: exec sql de1ete from representantes where cuota ~ :importe :importe_ind;
Esta prohibición existe por el mismo motivo por el que no se permite la palabra clave NULL en las condiciones de búsqueda -no tiene ningún se~tido comprobar
Hasta ahora, utilizando las características del SQL incorporado, se puede incluir en los programas de aplicación cualquier instrucción de SQL interactivo, salvo la instrucción SELECT. La recuperación de los datos con programas de SQL incorporado exige algunas ampliaciones especiales de la instrucción SELECT. El motivo de estas ampliaciones es que hay un desajuste fundamental entre el lenguaje SQL y lenguajes de programación 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 programación sólo pueden manipular elementos de datos o registros individuales (filas) de datos. SQL incorporado debe tender un puente entre la lógica en el nivel de las tablas de la instrucción de SQL SELECT y el procesamiento fila a fila de C, COBOL y otros lenguajes de programación 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 búsqueda del límite de crédito de un cliente o la recuperación de las ventas y de la cuota de un representante dadoson 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 relación de los pedidos coil importes superiores a 20.000 € o la recuperación 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 instrucción SELECT interactiva maneja los dos tipos. En SQL incorporado, sin embar-
514
Capítulo 17: SOL incorporado
SOL. Manual de referencia
go, los dos tipos de consultas se manejan de manera muy diferente. Las consultas de una única fila resultan más 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 número 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 instrucción SELECT única, que puede verse en la Figura 17.19. La instrucción SELECT única tiene una sintaxis muy parecida a la de la instrucción SELECT interactiva. Tiene una cláusula SELECT, una cláusula PROM y una cláusula opcional WHERE. Como la instrucción SELECT única devuelve una sola fila de datos, no hace falta ninguna
cláusula GROUP BY, HAVING ni ORDER BY. La cláusula INTO especifica las variables del anfitrión que deben recibir los datos recuperados por la instrucción. La Figura 17.20 muestra un programa sencillo con una SELECT única. El programa pide al usuario un número 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 anfitrión nombrerep, cuotarep y ventasrep, respectivamente. Recuérdese que las variables del anfitrión utilizadas en las instrucciones INSERT, DELETE y UPDATE de los ejemplos anteriores eran variables del anfitrión de entrada. Por el contrario, las variables del anfitrión especificadas en la cláusula INTO de la instrucción SELECT única son variables del anfitrión de salida. Cada
main{ I {
exec sql begin declare section; int nurnrep; char
[L;t
efemento·qu~
ar ..........- - - - - - ,
nombrerep[16];
float cuotarep; float ventasrep; exec sql end declare section;
'*
número de empleado (obtenido del usuario) nombre del representante. recuperado */ '* cuota, recuperada */ /* ventas, recuperadas */
*'
'*
'* pide al usuario el número de empleado */ printf(-Introduzca el número del representante: scanf(-'d", &numrep);
INTO
.f
/* Ejecuta la consulta de SQL */ exec sql select nombre, cuota, ventas from representantes where num_empl = :numrep into :nombrerep, :cuotarep,
Varjable-d~-anfitri6n
"¡;
:ventasrep;
/* Muestra los datos recuperados */ if (sqlca.sqlcode == '= O) { printf("Nombre: ts\n", nombrerep); printf("Cuota: 'f\n·, cuotarep); printf("Ventas: tf\n", ventasrep); }
L....,... WHERE
condici6n-de-búsqueda
------------------+.-1
el se if (sqlca.sqlcode == == 100) printf("NO hay ningún representante con ese número de empleado.\n·); else printf("Error de SQL: tld\n", sqlca.sqlcode); exit();
• Figura 17.19.
Diagrama sintáctico de la instrucción SELECT.
515
Figura 17.20.
Empleo de la instrucción SELECT única.
516
Capítulo 17; SaL incorporado
SOL. Manual de referencia
variable del anfitrión citada en la cláusula INTO recibe una sola columna de la fila de resultados de la consulta. Los elementos de la lista de selección y las variables del anfitrión correspondientes se emparejan en orden, tal y como aparecen en sus cláusulas respectivas, y el número de columnas de resullados de la consulta debe ser el mismo que el de variables del anfitrión. Además, el tipo de datos de cada variable del anfitrión 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 automática las conversiones razonables entre los tipos de datos del SGBD y los tipos de dalOs admitidos por el lenguaje de programación. 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 anfitrión para manejar correctamente la conversión. Los datQs de texto de longitud variable también deben convertirse antes de almacenarlos en una variable del anfitrión. Generalmente, el SOBO convierte los datos VARCHAR en cadenas de caracteres con terminación 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 anfitrión 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 anfitrión. Otros convierten los datos de fecha y hora a formato de texto y los devuelven en una variable de cadena de caracteres del anfitrión. La Tabla 17.1 resume las conversiones de tipos de datos que suelen ofrecer los productos de SGBD, pero conviene consultar la documentación del SQL incorporado para cada marca concreta de SOBO con el fin de lograr información más específica. La condición NO'!' FOUND
Al igual que todas las instrucciones de SQL incorporado, la instrucción 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 anfitrión citadas en la cláusula 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 anfitrión no contienen ningún valor recuperado.
517
• 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 más de una fila de resultados de la consulta, se trata como un error y se devuelve un valor negativo de SQLCODE. El estándar SQLI especifica la condición de advertencia NOT FOUND, pero no especifica un valor concreto que deba devolver. DB2 utiliza el valor +100, y la mayor parte de los demás productos de SQL siguen esta convención, incluidos los demás productos de SQL de IBM, Ingres y SQLBase. Este valor se especifica también en el estándar 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. Recuperación de los valores NULL
Si los datos que hay que recuperar de la base de datos pueden contener valores la instrucción SELECT única debe proporcionar un modo de que el SGBD comunique los valores NULL al programa de aplicación. Para manejar los valores NULL el SQL incorporado utiliza variables indicadoras en la cláusula INTO, igual que se utilizan en la cláusula VALUES de la instrucción INSERT y en la cláusula SET de la instrucción UPDATE. Cuando se especifica una variable del anfitrión en la cláusula INTO se puede hacer que la siga de manera inmediata el nombre de una variable indicadora del anfitrión acompañante. La Figura 17.21 muestra una versión revisada del programa de la Figura 17.20 que utiliza la variable indicadora cuotarep_ind con la variable del anfitrión cuotarep. Como las columnas NOMBRE y VENTAS están declaradas como NOT NULL en la definición 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 instrucción SELECT, el valor de la variable indicadora indica al programa el modo en que debe interpretar los datos obtenidos: NULL,
• Un valor de la variable indicadora de cero significa que se ha asignado a la variable del anfitrión un valor recuperado por el SGBD. El programa de aplicación 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 anfitrión resulta irrelevante y el programa de aplicación no debe utilizarlo. • Un valor positivo de la variable indicadora señala una condición de advertencia de algún tipo, como los errores de redondeo o los truncamientos de cadenas de caracteres. Como no se puede predecir cuándo se recuperará un valor NULL, conviene especificar siempre una variable indicadora en la cláusula INTQ de cualquier columna de los resultados de la consulta que pueda contener valores NULL. Si la instruc-
518
Capítulo 17: SOL incorporado
SOL. Manual de referencia
tencia. Por ejemplo, si un desbordamiento aritmético o una división por cero hace que una de las columnas de los resultados de la consulta no ·resulte válida, DB2 devuelve un SQLCODE de advertencia de +802 y define la variable indicadora de la columna afectada como - 2. El programa de aplicación puede responder a SQLCODE y examinar las variables indicadoras para determinar la columna que contiene los datos no válidos. DB2 también utiliza las variables indicadoras para señalar 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 anfitrión correspondienle, DB2 copia la primera parte de la cadena de caracteres en la variable del anfitrión y define la variable indicadora correspondiente como la longitud completa de la cadena de caracteres. El programa de aplicación puede examinar la variable indicadora y puede que desee volver a probar la instrucción SELECT con una variable del anfitrión diferente que pueda albergar una cadena de caracteres de mayor tamaño. Estos usos adicionales de las variables indicadoras resultan bastante frecuentes en los productos comerciales de SQL, pero los valores concretos de los códigos de advertencia varían de un producto a otro, No se especifican en el estándar SQL de ANSI/ISO. En lugar de eso, el eSlándar SQL2 especifica las clases y subclases estándar de los errores para indicar eslas condiciones y otras parecidas, y el programa debe utilizar la instrucción GET DIAGNQSTICS para determinar información más concreta sobre la variable del anfitrión que genera el error.
main ()
1 exec sql include sqlca; exec sql begin declare section; nurorep; int
/* número de empleado
(obtenido
*/ /* nombre del representante, del usuario)
char
nombrerep[16] ;
float cuotarep; float ventasrep¡ short cuotarep_ind; exec sql end declare section;
'*
/* pide al usuario el número de empleado */ printf(-Introduzca el número del representante: scanf (·'d".
/* Ejecuta la consulta de SQL */ exec sql select nombre, cuota, ventas froro representantes where nUffi_empl = :numrep into :nombrerep, :cuotarep.
:cuotarep_ind.
:ventasrep;
/* 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); printf¡·Ventas: 'f\n", ventasrep):
Recuperación mediante estructuras de datos Algunos lenguajes de programación 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 anfitrión compuesta en la cláusula INTO. En lugar de especificar una variable del anfitrión 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 cláusula 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 número 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 cláusula INTO es, de hecho, un atajo. No modifica de manera fundamental el modo en que funciona la cláusula INTO. " El' soporte del empleo de las estructuras de datos como variables del anfitrión varía ampliamente entre las marcas de SOBD. También se halla limitado a determinados lenguajes de programación. 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 ningún representante con ese número de empleado. \n"): else printf("ErrOr de SQL: %ld\n", sqlca.sqlcode); exitO·;
Figura 11.21.
519
Empleo de la instrucción SELECT única con variables indicadoras.
ción SELECT genera una columna que contiene un valor NULL y no se ha especificado ninguna variable indicadora para esa columna, el SGBD tratará la instrucción 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 también las utiliza para señalar las condiciones de adver-
J
520
SOL. Manual de referencia
Capítulo 17: SOL incorporado
521
variables del anfitrión numrep y nombrerep ilustran los dos papeles diferentes representados por las variables del anfitrión:
main () (
• La variable del anfitrión nurnrep es una variable del anfitrión de entrada, que se utiliza para pasar datos del programa al SGBD. El programa asigna un valor a la variable antes de ejecutar la instrucción incorporada, y ese valor pasa a ser parte de la instrucción SELECT que el SOBO va a ejecutar. El SGBO no hace nada para modificar el valor de esta variable. • La variable del anfitrión nombrerep es una variable del anfitrión de salida, que se utiliza para devolver datos del SGBD al programa. El SGBD asigna un valor a esta variable cuando ejecuta la instrucción SELECT incorporada. Una vez ejecUlada la instrucción, el programa puede utilizar el valor resultante.
exec sql include sqlcd: exec sql begin declare section; /* numero de empleado (proporcionado int numrep;
por el
usuario) */
struct (
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 número de empleado */ printf("Introduzca el número del representante: scanf('%d", &numrep};
Las variables del anfitri6n de entrada y de salida se declaran del mismo modo y se especifican utilizando la misma notación de coma dentro de las instrucciones
"J;
de SQL incorporado. No obstante, suele resultar útil pensar en términos de variables del anfitrión de entrada y de salida cuando se está llevando a cabo la codificación del programa de SQL incorporado. Las variables del anfitrión de entrada pueden utilizarse en cualquier instrucción de SQL en la que pueda aparecer una constante. Las variables del anfitrión de salida s6lo se utilizan con la instrucción SELECT única y con la instrucción FETCH, que se describe en el apartado siguiente de este capítulo.
Ejecuta la consulta de SQL */ exec sql select nombre. cuota, ventas /*
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);
Consultas de múltiples filas Cuando una consulta genera toda una tabla de resultados, el SQL incorporado debe proporcionar una manera de que el programa de aplicación los procese fila a fila. SQL incorporado admite esta posibilidad mediante la definición de un nuevo concepto de SQL, denominado cursor, y añadiendo varias instrucciones al lenguaje SQL interactivo. A continuación se ofrece una visión general de las técnicas de SQL incorporado para el procesamiento de consultas de múltiples filas y las instrucciones nuevas que exige:
} else if (sqlca.sqlcode ::: ::: 100) printf("No hay ningún representante con ese número de empleado.\n"); else printf("Error de SQL: %ld\n", sqlca.sqlcode); exit ();
1. 2.
Figura 17.22.
Empleo de una estructura de datos como variable del an·
fitrión. 3. Variables del anfitrión de entrada y de salida
Las variables gel anfitrión proporcionan una comunicación en dos sentidos entre el programa y el SOBO. En el programa que puede verse en la Figura 17.21, las
-
La instrucción DECLARE CURSOR especifica la consulta que se va a llevar a cabo y le asocia el nombre de un cursor. La instrucción 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 instrucción FETCH desplaza el cursor hasta la primera fila de los resul· tados de la consulta y recupera los datos en variables del anfitrión para su empleo por el programa de aplicación. 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 anfitrión.
522 4.
SOL. Manual de referencia
Capítulo 17: SQL incorporado
La instrucción CLOSE concluye el acceso a los resultados de la consulta y rompe la asociación entre el cursor y los resultados de la consulta. exec sql fetch repcurs ilI into :nombrerep, ventasrep;
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 números de las etapas que se acaban de explicar. El programa recupera y muestra, en orden alfabético, el nombre, la cuota y las ventas del año en curso de cada representante cuyas ventas superan su cuota. La consulta de SQL interactivo que imprime esa información es:
523
0 :cuotarep,
:cuotarep_ind,
/* 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;
5ELECT NOMBRE, CUOTA, VENTAS FROM REPRESENTANTES WHERE VENTAS > CUOTA
error pr ex
ORDER BY NOMBRE
ntf(~Error
de SQL: %ld\n*, sqlca.sqlcode);
t{);
done: /* Consulta completa; cierra el cursor */ exec sql close repcurs; .4~-------------------------------1G) exit ();
main () (
exec sql include sqlca; exec sql begin declare section; char nombrerep[16]; float cuotarep; float ventasrep; short cuotarep_ind;
/* nombre del representante, recuperado */
/* cuota, recuperado */ /* ventas, recuperado */ /* indicador de valores null de la cuota */
Figura 17.23.
exec sql end declare section; /* Declara el cursor de la consulta */
exec sql declare select from where order
repcurs cursor for ~ nombre, cuota, ventas representantes ventas > cuota by nombre;
Obsérvese que esta consulta aparece, palabra por palabra, en la instrucción incorporada DECLARE CURSOR de la Figura 17.23. La instrucción también asocia el nombre de cursor repcurs con la consulta. Este nombre de cursor se utiliza posteriormente en la instrucción OPEN CURSOR para iniciar la consulta y colocar el cursor antes de la primera fila de resultados de la consulta. La instrucción FETCH dentro del bucle for captura la siguiente fila de resultados de la consulta cada vez que se ejecuta ese bucle. La cláusula INTO de la instrucción FETCH funciona igual que la cláusula INTO de la instrucción SELECT única. Especifica las variables del anfitrión que van a recibir los elementos de datos capturados -una variable del anfitrión por cada columna de resultados de la consulta. Como en los ejemplos anteriores, se utiliza una variable indicadora del anfitrión (cuotarep_ind) cuando algún elemento de datos capturado puede contener valores NULL. Cuando no hay que capturar más filas de resultados de la consulta, el SGBD devuelve la advertencia NOT FOUND en respuesta a la instrucción FETCH. Se trata exactamente del mismo código de advertencia que se devuelve cuando la instrucción SELECT única no puede recuperar una fila de datos. En este programa la instrucción WHENEVER NOT FOUND hace que el precompilador genere código que comprueba el valor de SQLCODE después de la instrucción FETCH. Este código generado se bifurca hasta la etiqueta final cuando surge la condición NOT FOUND, y a la etiqueta error si se produce alguno. Al final del programa, la instrucción CLOSE
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; ,.
0
/* Itera el bucle para cada fila de resultados de la consulta */
for (;;)
Procesamiento de consultas de varias filas. (Continuación.)
(
/* Captura la siguiente fila de resultados de la consulta */
Figura 17.23.. Procesamiento de consultas de varias filas. (Continúa.)
J
_
524
SOL. Manual de referencia
Capítulo 17: SOL incorporado
concluye la consulta y finaliza el acceso del programa a los resultados de la consulta.
r--
DECLARE nombre-cursor CURSOR FOR instrucc;ón-SELECT
Cursores Figura 17.24.
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 programación 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 posición actual del programa en los archivos abiertos, los cursores realizan un seguimiento de la posición 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. Además, los cursores de SQL sólo 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 analogía 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 declaración 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 petición de un usuario de datos más 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.
Diagrama sintáctico de la instrucción
525
..
DEC.
En concreto, la instrucción SELECT debe incluir una cláusula FROM y puede incluir de manera opcional las cláusulas WHERE, GROUP BY, HAVING Y ORDER BY. La instrucción SELECT también puede incluir el operador UNION, tal y como se describe en el Capítulo 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 instrucción DECLARE CURSOR también puede incluir variables de entrada del anfitrión. Estas variables del anfitrión llevan a cabo exactamente la misma función que en las instrucciones INSERT, DELETE y UPDATE incorporadas y en la instrucción SELECT única. Las variables de entrada del anfitrión pueden aparecer dentro de la consulta en cualquier lugar en que pueda aparecer una constante. Obsérvese que las variables de salida del anfitrión no pueden aparecer en la consulta. A diferencia de la instrucción SELECT única, la instrucción SELECT del interior de la instrucción DECLARE CURSOR no tiene ninguna cláusula INTO y no recupera ningún dato. La cláusula INTO aparece como parte de la instrucción FETCH, que se describe brevemente, Como su nombre indica, la instrucción DECLARE CURSOR es una declaración del cursor. En la mayor parte de las implementaciones de SQL, incluidos los productos de SQL de IBM, esta instrucción es una directriz para el precompilador de SQL; no se trata de una instrucción ejecutable, y el precompilador no genera ningún código para ella. Al igual que todas las declaraciones, la instrucción DECLARE CURSOR debe aparecer físicamente en el programa antes de ninguna instrucción 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, función O subrutina que aparezca tras la instrucción DECLARE CURSOR. Merece la pena destacar que no todas las implementaciones de SQL tratan la instrucción DECLARE CURSOR estrictamente como una instrucción declarativa, y esto puede crear problemas sutiles. Algunos precompiladores de SQL generan realmente código para la instrucción DECLARE CURSOR (declaraciones del lenguaje anfitrión, llamadas al SGBD o ambas cosas), lo que le da algunas de las cualidades de las instrucciones ejecutables. Para esos precompiladores, la instrucción DECLARE CURSOR no sólo debe anteceder físicamente a las instrucciones OPEN, FETCH Y CLaSE que hacen referencia a ese cursor, sino que, a veces, también debe precederlas en el flujo de ejecución o hallarse situada en el mismo bloque que las demás instrucciones. En general, se pueden evitar problemas con la instrucción DECLARE CURSOR siguiendo estas directrices:
La instrucción DECLARE CURS0R
La instrucción DECLARE CURSOR, que puede verse en la Figura 17.24, define la consulta que hay que llevar a cabo. La instrucción también asocia con la consulta el nombre de un cursor. El nombre del cursor debe ser un identificador válido 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 anfitrión; se declara mediante la instrucción DECLARE CURSOR, no en una declaración del lenguaje anfitrión. La instrucción SELECT de la instrucción DECLARE CURSOR define la consulta asociada con e:l cursor, La instrucción SELECT puede ser cualquier instrucción SELECT válida de SQL interactivo, tal y como se describe en los capítulos 6 a 9.
1
526
Capítulo 17: SOL incorporado
SOL. Manual de referencia
• Ubicar la instrucción DECLARE CURSOR justo antes de la instrucción QPEN del cursor. Esta ubicación asegura la secuencia física 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 instrucción DECLARE CURSOR, si fuera necesario. También ayuda a documentar la consulta que solicita
1-- FETCH
exactamente la instrucción OPEN. • Asegurarse de que las instrucciones FETCH Y CLOSE del cursor siguen físicamente a la instrucción OPEN, así como en el flujo de control. La instrucción OPEN
cursor
mencion~do
• La instrucción OPEN coloca el cursor antes de la primera línea de resultados de la consulta. En ese estado, el cursor no tiene fila actual.
OP~
La instrucción FETCH, que puede verse en la Figura 17.26, recupera la siguiente
H¡ PETC H+ FETeH+ FETeH¡
fila de resultados de la consulta para que la utilice el programa de aplicación. El
1
,
Figura 17.27.
OPEN.
I
I 2
ID PRODUCTO
DESCRIPCIÓN
1
•
-
1 1
tVariSble-del.anfilriÓn
Resul tado de la consul ta (tres filasl ID FAB
FETC
~OPEN nombre-cursor-,----------------..,,---+-e
Diagrama sintáctico de la instrucción
FETCH.
consul~a
La instrucción FETCH
Figura 17.25',
Diagrama sintactico de la instrucción
en la instrucción FETCH especifica la fila de resultados de la que h~y que capturar. Debe identificar un cursor ya abierto anteriormente por la Instrucción OPEN. La instrucción FETCH captura la fila de elementos de datos en una lista de variables del.anfitrión, que se especifica en la cláusula INTO de la instrucción. Se puede asocl~r una variable indicadora con cada variable del anfitrión para manejar la recuperacIón de datos NULL. El comportamiento de la variable indicadora y los valores qu~ p.uede adoptar SO? idénti~os a los ya descritos en el apartado «Consultas de una umca fila» para la lOstrucclón SELECT única. El número de variables del anfitrión de la lista debe ser igual que el de columnas del resultado de la consulta y los tipos de datos de las variables del anfitrión deben ser compatibles, columna ~ columna, con las columnas de resultados de la consulta. Corno puede verse en la Figura 17.27, la instrucción FETCH desplaza el cursor por los resultados de la consulta, fila a fila, de acuerdo con las reglas siguientes:
La instrucción 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 aplicación. En la práctica, la instrucción OPEN hace que el SGBD procese la consulta o, al menos, que comience a hacerlo. La instrucción OPEN, por lo tanto, hace que el SGBD lleve a cabo la misma labor que la instrucción SELECT interactiva, a falta sólo de la generación de la primera fila de resultados. El único parámetro de la instrucción OPEN es el nombre del cursor que hay que abrir. Este cursor debe haberse declarado anteriormente mediante una instrucción DECLARE CURSOR. Si la consulta asociada con el cursor contiene un error, la instrucción 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 instrucción OPEN. En la práctica, 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 instrucción CLOSE. El SGBD también cierra de manera automática todos los cursores abiertos al final de cada transacción (es decir. cuando el SGBD ejecuta una instrucción COMMIT o ROLLBACK). Una vez cerrado el CUISor, puede volver a abrirse ejecutando la instrucción OPEN por segunda vez. Téngase en cuenta que el SGBD vuelve a inici~ la consulta desde el principio cada vez que ejecuta la instrucción OPEN.
USING
••
nombre*cursor INTO - - - -tvana . b¡e-d;¡-anfitriÓnj
Figura 17.26.
527
I~
(
I~
(NOT FOUND)
Colocación del cursor con las instrucciones
OPEN, FETCH
Y CLOSE.
528
SOL. Manual de referencia
• La instrucción 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 instrucción FETCH desplaza el cursor más allá de la última fila de resultados de la consulta, la instrucción FETCH devuelve una advertencia NQT FOUNO. En ese estado, el cursor no tiene fila actual. • La instrucción 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 instrucción OPEN sigue colocando el cursor antes del resultado (vacío) de la consulta y lo devuelve con éxito. El programa no puede detectar que la instrucción OPEN ha generado un conjunto vacío 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 (vacío) de la consulta.
La instrucción
CLOSE
La instrucción CLOSE, que puede verse en la Figura 17.28, cierra conceptualmente la tabla de resultados de la consulta creada por la instrucción OPEN, lo que concluye el acceso a ella del programa de aplicación. Su único parámetro es el nombre del cursor asociado con el resultado de la consulta, que debe ser un cursor abierto anteriormente por una instrucción OPEN. La instrucción 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 más frecuente. Todos los cursores se cierran de manera automática al final de cada transacción. Una vez cerrado un cursor, los resultados de su consulta dejan de estar disponibles para el programa de aplicación.
Cursores de desplazamiento El estándar SQLI especifica que los cursores sólo pueden desplazarse hacia delante por los resultados de la consulta. Hasta hace pocos años la mayor parte de los productos comerciales de SQL también disponían ú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~pués hay que ejecutar FETCH sobre las filas hasta alcanzar la fila deseada. A principios de los años noventa, unos cuantos productos comerciales de SQL ampliaron el concepto de cursor con el de cursor de desplazamiento. A diferencia de los cursores estándar, 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 ampliación de la instrucción FETCH, que puede vese en la Figura 19.28: recupera la primera fila de resultados de la consulta. recupera la última fila de resultados de la consulta.
• FETCH .FIRST • FETCH LA8T
Capítulo 17: SOL incorporado
~
Figura 17.28.
CLOSE
nombre-cursor
Diagrama sintáctico de
la
instrucción
529
~.
CLOSE.
• FETC~ PRIOR •
• •
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 ningún movimiento, y se corresponde con el movimiento de los cursores estándar. FETCH ABSOLUTE recupera una fila concreta a partir de su número de fila. FETCH RELATIVE desplaza el cursor hacia delante O hacia atrás un número concreto de filas respecto a su posi~ión presente.
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 atrás 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 también son mucho más difíciles 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 también debe asegurarse de que ninguna otra transacción 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 instrucción FETCH ampliada para volver a recuperar esa fila, aunque el cursor se haya desplazado más 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 más tiempo ·de lo normal si se solicita una operación FETCH NEXT cuando el cursor se halla ubicado en la primera fila de resultados de la consulta. Es conveniente comprender las características 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 producción. Debido a la utilidad de estos cursores, y dado que unos cuantos fabricantes de SGBD habían comenzado a distribuir implementaciones de los cursores de desplazamiento que eran ligeramente diferentes entre sí, el estándar SQL2 se amplió para incluir el soporte de los cursores de desplazamiento. El nivel inicial del ,estándar
530
SOL. Manual de referencia
L
_-,
Capítulo 17: SOL incorporado
••
.FETCH
variable·def-
FROM nombre-cursorINTO
-FlRST--------1 -LAST - - - - - - - - - j
número-fila-
-RELATIVE
BnúmeW-fiI"-
Figura 17.29.
Instrucción
FETCH
ampliada para los cursores de desplazamiento.
SQL sólo 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 estándar también especifica que, si se utiliza algún movimiento aparte de FETCH NEXT (el valor predeterminado) en el cursor, su instrucción DECLARE CURSOR debe identificarlo de manera explícita como cursor de desplazamiento. Empleando la sintaxis de SQL2, la declaración de cursor de la Figura 17.22 aparecería como: exec sql declare select from where arder
~ DELETE FROM nombre-cursor WHERE CURRENT OF nombre-cursor
.~.
'& an",itrión ,...... L - =-.J
-PRIOR--------j -NEXT _ ABSOLUTE
531
repcurs scroll cursor for nombre, cuota, ventas representantes ventas > cuota by nombre;
Figura 17.30.
sea incorrecta, o que el cliente desee eliminar uno de los pedidos. En esta situación el usuario desea actualizar o eliminar ese pedido. La fila no viene identificada por la condición de búsqueda habitual de SQL; más 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 instrucción 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 instrucción, 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 vacío a la izquierda de la fila eliminada, esperando a que una instrucción FETCH posterior lo desplace a la fila siguiente. La instrucción 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 instrucción, 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 cláusula SET. Una vez actualizada la fila, sigue siendo la fila presente del cursor. La Figura 17.32 muestra un programa de exploración de pedidos que utiliza las instrucciones UPDATE y DELETE posicionadas: l.
Eliminaciones y actualizaciones con cursores Los programas de aplicación 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 señal del usuario para pasar a la fila siguiente. La exploración continúa 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 implícita 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
Diagrama sintáctico de la instrucción DELETE posicionada.
El programa pide primero al usuario el número de un cliente y luego consulta la tabla PEDIDOS para buscar todos los pedidos realizados por ese cliente.
1- UPDATE
nombre-tabla SET
T
nombre-columna
=
expresión
,
-l
WHERE CURRENT OF nombre-cursor,--------------~~.
Figura 17.31.
Diagrama sintáctico de la instrucción
UPDATE
posicionada.
532
SQL. Manual de referencia
Capítulo 17: SOL incorporado
2. main () (
exec sql include sqlca; exec sql begin declare section; nurncli; /' número de cliente, int proporcionado por el usuario ~I numped; / ' número 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] /* carácter 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 número de cliente */ printf{"Introduzca número de cliente: "); scanf{-'d-, &numcli);
(1
/* Configura el procesamiento de los errores */ whenever $Qlerror gato error; whenever not found gota final;
/* 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("NÚmerO 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.
I
3. 4. 5.
6.
533
Cuando recupera cada fila de resultados de la consulta, muestra la información de los pedidos en la pantalla' y pregunta al usuario lo que debe hacer a continuación. 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 instrucción 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 instrucción UPDATE posicionada. Si el usuario escribe X, el programa detiene la consulta y concluye.
Aunque resulte primitivo en comparación con los programas de aplicación reales, el ejemplo de la Figura 17.32 muestra toda la lógica y las instrucciones de SQL incorporado necesarias para implementar una aplicación de exploración con aClUalizaciones de la base de datos basadas en cursores. El estándar SQLI especifica que las instrucciones DELETE y UPDATE posicionadas sólo 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, sólo debe mencionarse una tabla en la cláusula FROM de la consulta especificada en la instrucción DECLARE CURSOR. • La consulta no puede especificar ninguna cláusula 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 cláusula GROUP BY ni HAVING. • El usuario debe tener el privilegio UPDATE o DELETE (lo que corresponda) sobre la tabla base.
Las bases de datos de IBM (DB2, SQUDS) ampliaron las restricciones de SQLl un paso más allá. Exigen que el cursor se declare de manera explícita como cursor actualizable en la instrucción DECLARE CURSOR. La forma ampliada de IBM de la instrucción DECLARE CURSOR se puede ver en la Figura 17.33. Además de declarar un cursor actualizable, la cláusula 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 sólo pueden actualizar esas columnas. En la práctica, 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 antelación si el cursor se utilizará para actualizaciones o si sus datos son sólo de lectura, ya que el procesamiento sólo de lectura es más sencillo. La cláusula FOR UPDATE proporciona este aviso previo y puede considerarse un eslándar de tacto del lenguaje SQL incorporado. Debido a su empleo generalizado, el estándar SQL2 incluye la cláusula estilo mM FOR UPDATE como opción de la instrucción DECLARE CURSOR. No obstante, a
534
SOL. Manual de referencia
~ DELETE CURSOR nombre-eursor FOR intrucción·SELECT---------,
FOR UPDATE
Figura 17.33.
La instrucción DECLARE CURSOR con la cláusula FOR UPDATE.
diferencia de Jos productos de IBM, el estándar SQL2 da por supuesto de manera automática que los cursores se abren para actualización, a menos que sea un cursor deslizante o se declare de manera explícita FOR READ ONLY. La especificación FOR READ ONLY de la instrucción SQL2 DECLARE CURSOR aparece exactamente en la misma posición que la cláusula FOR UPDATE e indica de manera explícita al SGBD que el programa no intentará ninguna operación 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 actualización de los cursores y las cláusulas o instrucciones que pueden utillzarse para anularlas. Además, los programas que declaran de manera explícita si su intención es permitir las actualizaciones mediante un cursor abierto son más fáciles 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. Recuérdese del Capítulo 12 que el modelo de transacciones de SQL garantiza la consistencia de los datos durante las transacciones. En términos 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 garantía de que los resultados de la consulta serán idénticos en ambas ocasiones-. El programa también puede capturar la misma fila mediante dos cursores diferentes y tener la garantía de que el resultado será idéntico. De hecho, se tiene la garantía de que los datos seguirán siendo consistentes hasta que el programa genere una ins~ucción COMMIT o RQLLBACK para finalizar la transacción. Como la consistencia no está garantizada de unas transacciones a otras.. tanto la ins-
Capítulo 17: SOL incorporado
535
trucción COMMIT como la instrucción ROLLBACK cierran de manera automática lodos los cursores abiertos. El SGBD proporciona entre bastidores esta garantía 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. Además, 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 transacción y bloquear a los demás usuarios durante una hora o más. 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 instrucción COMMIT inmediatamente después de cada consulta y en cuanto sea posible una vez que el programa haya completado una actualización. • Evitar los programas que exijan gran cantidad de interacción 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 después 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 Capítulo 12. Esto permite que el SGBD desbloquee una fila en cuanto se genera la siguiente instrucción 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 explícita los cursores como READ ONLY, si es posible.
Resumen Además de su papel como lenguaje interactivo de bases de datos, SQL se utiliza para el acceso mediante programación a las bases de datos relacionales: • La técnica más frecuente para el empleo en programación de SQL es el SQL incorporado, en el que las instrucciones de SQL se incorporan al programa de aplicación, entremezcladas con las instrucciones de un lenguaje de programación anfitrión 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 varía de un lenguaje anfitrión a otro. • Las variables del programa de aplicación, denominadas variables del anfitrión, pueden utilizarse en las instrucciones de SQL incorporado siempre que
536
• • •
•
SOL. Manual de referencia
pueda aparecer una constante. Estas variables de entrada del anfitrión adoptan la instrucción de SQL incorporado a cada situación concreta. Las variables del anfitrión se utilizan también para recibir el resultado de las consultas a la base de datos. El valor de estas variables de salida del anfitrión puede ser procesado por el programa de aplicación. Las consultas que generan una sola fila de datos las maneja la instrucción SELECT única de SQL incorporado, que especifica tanto la consulta como las variables del anfitrión 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 instrucción DECLARE CURSOR define la consulta; la instrucción OPEN comienza el procesamiento de la consulta; la instrucción FETCH recupera filas sucesivas de resultados de la consulta, y la instrucción 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.
CAPíTULO
18
SOL dinámico*
Las características de programación de SQL incorporado descritas en el Capítulo 17 se conocen en conjunto como SQL estdtico. SQL estático resulta adecuado para escribir los programas que suelen necesitarse en las aplicaciones de proceso de datos. Por ejemplo, en la aplicación de proceso de datos de la aplicación de ejemplo se puede utilizar SQL estático para escribir los programas que manejan la admisión de pedidos, las actualizaciones de los pedidos, las búsquedas de pedidos, las búsquedas 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 código 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 antelación. Las herramientas de consulta gráfica o los redactores de informes, por ejemplo, deben poder decidir en el momento de la ejecución las instrucciones de SQL que van a emplear para tener acceso a la base de datos. Las hojas de cálculo de las computadoras personales que admiten el acceso a las bases de datos del anfitrión también deben poder enviar consultas al SGBD del anfitrión para su ejecución sobre la marcha. Estos programas y otras partes visibles de las bases de datos de finalidad general no pueden escribirse empleando técnicas de SQL estático. Necesitan una forma avanzada de SQL incorporado, denominada SQL dindmico, que se describe en este capítulo.
Límites de SOL estático Como el nombre SQL estático indica, los programas creados empleando las características de SQL incorporado, descritas en el Capítulo 17 (las variables del anfitrión, 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 instrucción de SQL incorporado del programa, el programador detennina con an-
537
538
SOL Manual de referencia
Capítulo 18: SOL dinámico*
telación las tablas y columnas a las que esa instrucción hace referencia y las fija en el código de la instrucción de SQL incorporada. Las variables de entrada del anfitrión ofrecen cierta flexibilidad en SQL estático, pero no modifican de manera esencial su naturaleza estática. Recuérdese que las variables del anfitrión pue.den aparecer en cualquier lugar en que se permita una constante dentro de las instrucciones de SQL. Se pueden utilizar variables del anfitrión para modificar las condiciones de búsqueda: exec sql select nombre, cuota, ventas fraro representantes where cuota> : importe_corte;
También se pueden utilizar las variables del anfitrión para modificar los datos insertados o actualizados en la base de datos: exec sql update representantes set cuota ~ cuota + :incremento where cuota >:importe_corte;
No obstante, no se pueden utilizar variables del anfitrión en lugar de los nombres de las tablas ni de las referencias a las columnas. El intento de empleo de las variables del anfitrión que_tabla y que_columna en estas instrucciones es ilegal: exec sql update :que_tabla set :que_columna
~
o;
exec sql declare cursor cursor? for select from :que_tabla;
Aunque se pudieran utilizar las variables del anfitrión de esta manera (y no se puede), surgiría inevitablemente otro problema. El número de columnas generado por la consulta de la segunda instrucción variaría, en función de la tabla especificada por la variable del anfitrión. Para la tabla OFICINAS, el resultado de la consulta tendría seis columnas; para la tabla REPRESENTANTES, tendría nueve. Además, los tipos de datos de las columnas serían diferentes para las dos tablas. Pero para escribir una instrucción FETCH para la consulta hace falta conocer con antelación el número de columnas del resultado de la consulta y sus tipos de datos, ya que hay que especificar una variable del anfitrión que reciba cada columna: exec sql fetch cursor? into :varl, :var2,
:var3;
Corno ilustra esta discusión, si el programa debe poder determinar en el momento de la ejecución las instrucciones de SQL que utilizará, o las tablas y columnas a las que hará referencia, SQL estático resulta inadecuado para la tarea. SQL dinámico supéra estas limitaciones.
539
Los productos de SQL de IBM han admitido SQL dinámico desde su introducción, igual que han hecho los productos comerciales de SGBDR basados en minicomputadoras y en UNIX. Sin embargo, el estándar SQL de ANSI/ISO 1 original no especificaba SQL dinámico; el estándar sólo definía SQL estático. La ausencia de SQL dinámico en el estándar SQLI resulta irónica, dada la idea popular de que el estándar permitía crear herramientas del frontal de la base de datos que podían portarse a muchas marcas diferentes de SOBD. De hecho, esas herramientas del frontal deben crearse casi siempre empleando SQL dinámico. En ausencia de un estándar ANSI/ISO, DB2 definió el estándar de facto para SQL dinámico. Las otras bases de datos de IBM de aquel tiempo (SQLIDS y OS/2 Extended Edition) eran casi idénticas a DB2 en su soporte de SQL dinámico, y la mayor parte de los demás productos de SQL también siguieron el estándar de DB2. En 1992 el estándar SQL2 añadió el soporte oficial al SQL dinámico, siguiendo sobre todo el camino marcado por lBM. El estándar SQL2 no exige el soporte de SQL dinámico en el nivel más bajo de cumplimiento (entrada), pero sí lo exige para los productos que proclaman el cumplimiento de los niveles intermedio o completo del estándar SQL.
Conceptos de SOL dinámico El concepto fundamental de SQL dinámico es sencillo: no incluir las instrucciones de SQL incorporado en el código fuente del programa. En lugar de eso, dejar que el programa cree el texto de la instrucción SQL en una de las áreas de datos en el momento de la ejecución. El programa pasa entonces el texto de la instrucción al SGBD para su ejecución sobre la marcha. Aunque los detalles resulten bastante complejos, todo SQL dinámico se crea alrededor de este concepto sencillo, y resulta conveniente tenerlo presente. Para comprender SQL dinámico y sus semejanzas y diferencias con SQL estático, resulta útil considerar nuevamente el proceso que sigue el SGBD para ejecutar las instrucción de SQL, que puede verse originalmente en la Figura 17.1 Y se repite aquí en la Figura 18.1. Recuérdese del Capítulo 17 que las instrucciones de SQL estático siguen los cuatro primeros pasos del proceso en el momento de la compilación. La utilidad BIND (o la parte equivalente del sistema de tiempo de ejecución del SGBD) analiza la instrucción de SQL, detennina la mejor manera de ejecutarla y guarda en la base de datos el plan de aplicación de esa instrucción como parte del proceso de desarrollo del programa. Cuando la instrucción de SQL estático se ejecuta en el momento de la ejecución, el SOBD simplemente ejecuta el plan de aplicación almacenado. En SQL dinámico, la situación es bastante diferente. La instrucción de SQL que hay que ejecutar no se conoce hasta el momento de la ejecución, por lo que el SGBD no puede prepararse con antelación para esa instrucción. Cuando se ejecuta realmente el programa, el SGBD recibe el texto de la instrucción que hay que ejecutar de manera dinámica (denominada cadena de caracteres de la instrucción) y recorre las cinco etapas que pueden verse en la Figura 18.1 en el momento de la ejecución.
540
SOL. Manual de referencia
-----r-
5ELECT A. B, e FROM x, y WHERE A < SOOO ANO e "" 'ABe'
Análisis de la
PrecompiJador
instrucció~
,-Validación de la instrucción
~ (OPtimización de la instrucción
~
Generación del plan
de aplicación
,
de la instrucción de Sal
(
TIempo de ejecución
Figura 18.1.
"::::0
, o
.. ~
-
~
-e o
~
Instrucción PREPARE
E ¡::
•
Instrucción EXECUTE IMMEDIATE
Ejecución de instrucciones dinámicas
-.----
Forma binaria
!
!1 1
e
-o -¡¡
)
~
Plan
1
j
!
541
intermedia) y la ejecución de la lógica de las bases de datos en otro sistema (parle oculta)- ha añadido nueva importancia a las posibilidades surgidas con SQL dinámico. En la mayor parte de estos entornos de tres capas, la lógica de las aplicaciones que se ejecuta en la capa interme,dia es bastante dinámica. 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 estático. 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 Capítulo 19) para enlazar la capa intermedia con las bases de datos de la parte oculta. Estas API toman prestados de manera explícita conceptos fundamentales de SQL dinámico (por ejemplo, las etapas independientes PREPARE y EXECUTE y la posibilidad EXECUTE IMMEDI ATE) para proporcionar acceso a las bases de datos. Una buena comprensión de los conceptos de SQL dinámico 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 comprensión puede significar la diferencia entre un diseño de la aplicación que ofrezca buen rendimiento y buenos tiempos de respuesta y uno que no lo haga.
SQl dinámico
SOL estático
Instrucción de Sal
~
Capítulo 18: SOL dinámico.
(EXECUTE IMMEDIATE)
• e -e -o o --
,
E13
_o
-~
'=.t
Ejecución
I
L_
t ____ ~ __ J _
La modalidad más sencilla de SQL dinámico la ofrece la instrucción EXECUTE IMMEDIATE, que puede verse en la Figura 18.2. Esta instrucción pasa el texto de una instrucción de SQL dinámico al SGBD y le pide que la ejecute de manera inmediata. Para utilizar esta instrucción el programa recorre las etapas siguientes:
Instrucción EXECUTE
1.
Procesamiento de las instrucciones de SOL por el SGBD.
Como cabría esperar, SQL dinámico es menos eficiente que SQL estático. Por este motivo, SQL estático se utiliza siempre que es posible, y muchos programadores de aplicaciones no necesitan aprender nunca nada de SQL dinámico. Sin embargo, SQL dinámico 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 años. El acceso a las bases de datos desde el interior de aplicaciones de las computadoras personales como las hojas de cálculo y los pro~ cesadores de texto se ha incrementado espectacularmente, y ha surgido un conjunto completo de herramientas del frontal de introducción de datos y de acceso a los datos basadas en las computadoras personales. Todas estas aplicaciones necesitan las características de SQL dinámico. Más recie~ltemente, la aparición de las arquitecturas de tres capas basadas ~n Internet -con la ejecución de la lógica de las aplicaciones en u~ sistema (capa
2.
El programa crea una instrucción de SQL en forma de cadena de caracteres de texto en·-una de las áreas de datos (generalmente denominadas búferes). La instrucción puede ser cualquier instrucción de SQL que no recupere datos. El programa pasa la instrucción de SQL al SGBD con la instrucción EXECUTE IMMEDIATE.
3.
El SGBD ejecuta la instrucción y define el valor de SQLCODE/SQLSTATE para indicar el estado de finalización, exactamente igual que si la instrucción se hubiera aplicado utilizando SQL estático.
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 condición de búsqueda de SQL. y crea el texto de una instrucción DELETE con base en las respuesta del usua-
:io. El p.rograma utiliza luego la instrucción EXECUTE IMMEDIATE para ejecutar la instrucción DELETE. Este programa no puede utilizar una instrucción DELETE está. tica de SQL incorporado, ya que no se conocen ni el nombre de la tabla ni la condición de búsqueda hasta que el usuario los introduce en el momento de la ejecución. Debe utilizar SQL dinámico. Si se ejecuta el programa de la Figura 18.3 con estos parámetros:
main ()
Introduzca el nombre de una tabla: personal Introduzca una condición de búsqueda: cuota Eliminado de personal con éxito.
(
/*
Este programa elimina filas de la tabla especificada por el usuario según una condición de búsqueda especificada por el usuario.
exec sql include sqlca; exec sql begin declare seetion; char stmtbuf(301);
<
20000
el pr.ograma pasa al SOBD este texto para la instrucción: delete from plantilla where cuota < 20000
Introduzca el nombre de una tabla: pedidos Introduzca una condición de búsqueda: cliente Eliminado de pedidos con éxito
1* nombre de tabla introducido por el usuario 'O/ /* condición de búsqueda
introducida por el usuario 'O/
2105
el programa pasa al SOBD este texto para la instrucción:
1* Comienza a crear la instrucción DELETE en scmtbuf */
delete froro pedidos where cliente = 2105
strcpy(strntbuf, "delete from "); /* Pide al usuario el nombre de una tabla;
la instrucción DELETE */ printf I ~ Introduzca el nombre de una tabla: getslnombretbl); strcat(stmtbuf, nombretbl);
lo aaade al texto de
Por tanto, la instrucción EXECUTE IMMEDIATE concede al programa gran flexibilidad en cuanto al tipo de instrucción DELETE que puede ejecutar. La instrucción EXECUTE IMMEDIATE utiliza exactamente una variable del anfitrión -la variable que contiene toda la cadena de caracteres de la instrucción de SQL-. La cadena de caracteres de la instrucción en sí misma no puede incluir referencias a las variables del anfitrión, pero no hacen falta: En lugar de utilizar una instrucción de SQL estático con una variable del anfitrión como ésta:
");
/* pide al usuario la condición de búsqueda; la añade al texto */ printf("Introduzca la condición de búsqueda:"); gets(cond_busq); if Istrlenlcond_busq) > O) { strcat I stmtbuf, - where -); strcat(stmtbuf, cond_busq);
exec sql delete from pedidos where cliente = :num_cli;
/* Ahora pide al SGBD que ejecute la instrucción */ 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 dinámico consigue el mismo efecto creando toda la instrucción en un búfer y ejecutándola: sprintf(buffer, "delete from pedidos where cliente exec sql execute immediate :buffer;
exit ();
Figura
18.3.
La instrucción EXECUTE IMMEDIATE es la modalidad más sencilla de SQL dinámico, pero resulta muy versátil. Se puede utilizar para ejecutar de manera dinámica la mayor parte de las instrucciones del LMD, incluidas INSERT, DELETE, UPDATE, COMMIT y RQLLBACK. También se puede utilizar EXECUTE IMMEDIATE
Empleo de la instrucción EXECUTE IHHEDIATE.
l
544
Capítulo 18: SOL dinámico*
SOL. Manual de referencia
para ejecutar de manera dinámica la mayor parte de las instrucciones del LDD, incluidas las instrucciones CREATE, DROP, GRANT y REVOKE. No obstante, la instrucción EXECUTE IMMEDIATE tiene una limitación significativa. No se puede utilizar para ejecutar de manera dinámica instrucciones SELECT, ya que no proporcionan ningún mecanismo para procesar el resultado de la consulta. Al igual que SQL estático necesita los cursores y las instrucciones de finalidad especial (DECLARE CURSOR, OPEN, FETCH Y CLOSE) para las consultas mediante programación, SQL dinámico utiliza cursores y algunas instrucciones de propósito especial nuevas para manejar las consultas. Las características de SQL dinámico que admiten consultas dinámicas se estudian más adelante en el apartado «Consultas dinámicas».
Ejecución dinámica en dos pasos La instrucción EXECUTE IMMEDIATE proporciona soporte en una etapa para la ejecución dinámica de las instrucciones. Como ya se ha descrito, el SGBn recorre las cinco etapas de la Figura 18.1 para cada instrucción ejecutada de manera dinámica. La sobrecarga de este proceso puede resultar muy significativa si el programa ejecuta muchas instrucciones dinámicas, y resulta un derroche si las instrucciones que hay que ejecutar son idénticas o muy parecidas. En la práctica, la instrucción EXECUTE IMMEDIATE sólo 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 dinámico ofrece un método alternativo de dos etapas para la ejecución dinámica de instrucciones de SQL. En la práctica, este enfoque de dos etapas, que separa la preparación de las instrucciones de su ejecución, se utiliza para todas las instrucciones de SQL de los programas que se ejecutan más de una vez y, especialmente, para aquellas que se ejecutan de manera repetida, centenares o millares de veces, en respuesta a la interacción con el usuario. A continuación puede verse una introducción a la técnica de dos etapas: 1.
2.
3.
El programa crea la cadena de caracteres de una instrucción de SQL en un . búfer, igual que para la instrucción EXECUTE IMMEDIATE. Los signos de interrogación (?) pueden sustituir a las constantes en cualquier parte del texto de la instrucción para indicar que el valor de la constante se proporcionará más adelante. El signo de interrogación se denomina indicador de parámetro. La instrucción PREPARE pide al SGBD que analice, valide y optimice la instrucción y que genere el plan de aplicación correspondiente. Se trata de la Etapa 1 de la interacción con el SGBD. El SGBD define el valor de SQLCODE/ SQLSTATE para indicar los errores hallados en la instrucción y retiene el plan de aplicación para su ejecución posterior. Obsérvese que el SGBD 110 ejecuta el plan en respuesta a la instrucción PREPARE. Cuando el programa desea ejecutar la instrucción preparada previamente, utiliza la instrucción EXECUTE y pasa al SGBD un valor por cada marca-
4.
545
dor de parámetro. Se trata de la Etapa 2 de la interacción con el SGBD. El SGBD sustituye el valor de los parámetros, ejecuta el plan de aplicación generado previamente y define el valor de SQLCODE/SQLSTATE para indicar su estado de finalización. El programa puede utilizar repetidamente la instrucción EXECUTE, proporcionando valores diferentes de los parámetros cada vez que se ejecute la instrucción dinámica. El SGBD puede repetir simplemente la Etapa 2 de la interacción, pues el trabajo de la Etapa I ya se ha concluido, y el resultado de ese trabajo (el plan de aplicación para la ejecución) seguirá siendo válido.
La.Figura 1804 muestra un programa en C que utiliza estas etapas, que están etiquetadas en la figura mediante llamadas. Se trata de un programa de actualización de tablas de finalidad generaL Pide al usuario el nombre de una tabla y el nombre de dos columnas, y crea una instrucción UPDATE para la tabla, que tiene el aspecto siguiente: update nombre-tabla set nombre-segunda-columna = ? where nombre-primera-columna = ?
main{ 1 {
/* Programa de actualización de propósito general.
Puede utilizarse para cualquier actualización en que haya que actualizar todas las filas de una columna numérica en las que una segunda columna numérica tenga un valor determinado. Por ejemplo, se puede utilizar para actualizar las cuotas de los representantes que se desee o para actualizar el límite de crédito de los clientes seleccionados.
/0
exec sql include sqlca; exec sql begin declare section; char stmtbuf[301] float valor_busca; float valor_nuevo;
/0 Texto de SQL que hay que ejecutar 0/ /+ valor del parámetro para la búsqueda 0/
/' valor del parámetro para la actualización ,/
exec sql end declare section; char nombretbl(31J; char colbusca[3l};
Figura· 18.4.
/* tabla que hay que actualizar */ /+ nombre de la columna de búsqueda */
Empleo de las instrucciones PREPA.RE y EXECUTE. (Continúa.)
546
SOL. Manual de referencia
char colactualiza[31j; char si_llo[31];
Capítulo 18: SOL dinámico*
Por tanto, los datos que introduce el usuario determinan la tabla que se va- a actualizar, la columna que hay que actualizar y la condición de búsqueda que hay que emplear. El valor de comparación de la búsqueda y el valor actualizado de los datos se especifican como parámetros, que se proporcionan más tarde cuando se ejecuta realmente la instrucción UPDATE. Tras crear el texto de la instrucción UPDATE en su búfer, el programa pide al SGBD que lo compile con la instrucción PREPARE. El programa enlra entonces en un bucle, en el que pide al usuario que introduzca pares de valores de los parámetros para llevar a cabo una serie de actualizaciones de la tabla. Este diálogo 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:
¡' nombre de la columna de actualización '¡ ¡, 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);
");
printf("Introduzca el nombre de la columna que hay que actualizar: "); gets(colactualiza) ;
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
/* Crea en el búfer la instrucción 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) ;
547
Introduzca el valor de búsqueda para num_emp1: 106 Introduzca el nuevo valor de cuota: 150000.00 ¿Otra (s/n)? s
0
Introduzca el valor de búsqueda para num_empl: 102 Introduzca el nuevo valor de cuota: 225000.00 ¿Otra (s/n)? s
exit (); }
/* Itera la petición al usuario de parámetros y la realización de las actualizaciones */ for ( ; ; ) ( printf{'\nlntroduzca el valor de búsqueda para %s: colbusca) : scanf("%f", &valor_busca); printf("Introduzca el nuevo valor de %s: colactualiza); scanf("%f", &valor_nuevo):
Introduzca el valor de búsqueda para num_emp1: 107 Introduzca el nuevo valor de cuota: 215000.00 ¿Otra (s/n)? n Actualizaciones completadas.
Este programa es un buen ejemplo de una situación en la que resulta adecuada la ejecución dinámica en dos etapas. El SGBD compila la instrucción dinámica UPDATE sólo una vez, pero la ejecuta tres veces, una por cada conjunto de valores de los parámetros introducido por el usuario. Si el programa se hubiera escrito empleando EXECUTE IMMEDIATE, la instrucción dinámica UPDATE se habría compilado tres veces y ejecutado otras tres. Por tanto, la ejecución dinámica en dos etapas de PREPARE y EXECUTE ayuda a eliminar parte de la desventaja en rendimiento de SQL dinámico. 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 Capítulo 19.
/* Pide al SGSD que ejecute la instrucción 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 más actualizaciones */ printf ("¿Otra (s/n)? "); +-------------{4 gets {si_no}; if (si_no[O] == 'n') break;
La instrucción
printf("\nActualizaciones completadas.\n·};
La instrucción PREPARE, que puede verse en la Figura 18.5, es exclusiva de SQL dinámico. Acepta una variable del anfitrión que contiene la cadena de caracteres de una instrucción de SQL y pasa la instrucción al SGBD. El SGBD compila el texto de la instrucción y la prepara para la ejecución mediante la generación del plan de aplicación. El SGBD define las variables SQLCODEI SQLSTATE para indi-
exit ();
Figura 18.4.
PREPARE
Empleo de las instruccione::. :::-:-.BPARE y EXECUTE. (Continuación.)
1
548
SOL. Manual de referencia
I Figura 18.5.
Capitulo 18: SOL d;námíco·.
PREPARE nombre·instrucciÓn FROM variable-del-anfitrión
Diagrama sintáctico de la instrucción
...
EXECUTE nomb,e·instrucC;Ón U S I N G n - Variab/..
EXECU'l'E
La instrucción EXECUTE, que puede verse en la Figura 18.6, es exclusiva de SQL dinámico. Pide al SGBD que ejecute una instrucción preparada anteriormente con la instrucción PREPARE. Se puede ejecutar cualquier instrucción que pueda prepararse. con una sola excepci6n. Al igual que la instrucción EXECUTE IMMEorATE, la instrucción EXECUTE no puede utilizarse para ejecutar las instrucciones SELECT. ya que carece de un mecanismo para manejar el resultado de la consulta. Si la lnstrucción dinámica que hay que ejecutar contiene uno o varios marcadores de pará~etro, la instrucci6n EXECUTE debe proporcionar un valor para cada uno de sus parámetros. Los valores pueden proporcionarse de dos maneras dife-
~e/.anfitrión~
L==-:o:=:J
PREPARE.
car los errores detectados en el texto de la instrucción. Como ya se ha descrito, la cadena de caracteres de la instrucción puede contener un marcador de parámetro. indicado por un signo de interrogación, en cualquier lugar en que pueda aparecer una constante. El marcador de parámetro indica al SOBD que se proporcionará más adelante, cuando la instrucción se ejecute realmente. Como consecuencia de la instrucción PREPARE, el SOBD asigna el nombre de instrucción especificado a la instrucción preparada. El nombre de instrucción es un identificador de SQL, como el nombre de los cursores. El nombre de instrucción se especifica en las instrucciones EXECUTE posteriores cuando se desea ejecutar la instrucción. Las marcas de SGBD se diferencian en el tiempo que conservan la instrucción preparada y el nombre de instrucción asociado. Para algunas marcas, la instrucción preparada sólo puede volver a ejecutarse hasta el final de la transacción actual (es decir, hasta la siguiente instrucción COMMIT o ROLLBACK). Si se desea ejecutar la misma instrucción dinámica más adelante durante otra transacción, hay que volver a prepararla. Otras marcas relajan esta restricción y conservan la instrucción preparada a lo largo de la sesión en curso con el SGBD. El estándar SQL2 de ANSInSO reconoce estas diferencias e indica de manera explícita que la validez de la instrucci6n preparada fuera de la transacción en curso depende de la implementaci6n. La instrucción PREPARE puede utilizarse para preparar casi cualquier instrucción ejecutable del LMD O del LDD, incluida la instrucción 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.
La instrucción
f-
549
Figura 18.6.
Diagrama sintáctico de la instrucción EXECUTE.
rentes, que se describen en los dos aparrados siguientes. El estándar SQL2 de ANSI! ISO incluye los dos métodos. EXECUTE
con variables del anfitrión
La manera más sencilla de pasar los valores de los parámetros a la instrucción EXECUTE es especificar una lista de variables del anfitrión en la cláusula USING. La instrucción EXECUTE sustituye, por orden, el valor de las variables del anfitrión por los marcadores de parámetro del texto de la instrucción preparada. Las variables del anfitri6n sirven, por tanto, como variables de entrada del anfitrión para la instrucción del anfitrión ejecutada de manera dinámica. Esta técnica 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 dinámico, y se incluye en el estándar SQL2 de ANSIIISO para SQL dinámico. El número de variables del anfitri6n de la cláusula USING debe coincidir con el número de marcadores de pará.me~o de la instrucclón dinámica, y el tipo de datos de cada variable del anfitri6n debe ser compatible con el tipo de datos necesario para el parámetro correspondiente. Cada variable del anfitrión de la lista puede tener también una variable del anfitrión indicadora acompañante. Si la variable indicadora contiene un valor negativo cuando se procesa la instrucci6n EXECUTE, al marcador de parámetro correspondiente se le asigna el valor NULL. RXECUTE
con
SQLDA
La segunda manera de pasar los parámetros a la instrucción EXECUTE es mediante una estructura dinámica de datos de SQL denominada área de datos de SQL (SQL Data Area), o SQLDA. Hay que utilizar un SQLDA para pasar los parámetros cuando no se conoce el número de parámetros que hay que pasar ni sus tipos de datos en el momento de escribir el programa. Por ejemplo, supóngase que se desea modificar el programa de actualización de finalidad general de la Figura 18.4 de modo que el usuario pueda seleccionar más de una columna para actualizarla. Se puede modificar el programa con facilidad para generar una instrucción UPOATE con un número variable de asignaciones, pero la lista de variables del anfitrión de Ja instru~ción EX~CUTE p]antea un problema; debe sustituirse por una lista de longitud variable. El SQLDA proporciona una manera de especificar una lista de parámetros de longitud variable de este tipo.
550
SOL. Manual de referencia
1
• El campo SQLTYPE contiene un código de tipo de datos entero que especifica el tipo de datos del parámetro que se pasa. Por ejemplo, el código 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 parámetros, SQLLEN contiene el número 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 parámetro. El SGBD utiliza este puntero para hallar el valor de los datos cuando ejecuta la instrucción de SQL dinámico. Los campos SQLTYPE Y SQLI:.EN indican al SGBD el tipo de datos al que se señala y su longitud. • El campo SQLIND es un puntero a un entero de dos bytes que se utiliza como variable indicadora del parámetro. El SGBD comprueba la variable indicadora para determinar si se está pasando un valor NULL. Si no se utiliza ninguna variable indicadora para un parámetro concreto, el campo SQLIND debe definirse como cero.
• La parte fija se halla al comienzo del SQLDA. Sus campos identifican la estructura de datos como SQLDA y especifican el tamaño 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 parámetros a una instrucción EXECUTE, debe haber una estructura SQLVAR por cada parámetro.
1
Los otros campos de las estructuras SQLVAR y SQLDA no se utilizan para pasar los valores de los parámetros a la instrucción EXECUTE. Se emplean cuando se utiliza un SQLDA para recuperar datos de la base de datos, como se describe más adelante en el apartado «Consultas dinámicas». La Figura 18.8 muestra un programa de SQL dinámico que utiliza un SQLDA para especificar los parámetros 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 número 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 petición de valores, el programa asigna a la columna correspondiente un valor NULL.
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 número 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.
551
Los campos de la estructura SQLVAR describen los datos que se pasan a la instrucción EXECUTE como valores de parámetros:
La Figura 18.7 muestra la disposición del SQLDA utilizada por las bases de datos de IBM, incluida DB2, que define el estándar de faclo para SQL dinámico. Casi todos los demás productos de SOBD utilizan también este formato de SQLDA de IBM, o uno muy parecido. El estándar SQL2 de ANSI/ISO proporciona una estructura parecida, denominada área de descriptores de SQL. El tipo de información contenido en el área de descriptores de SQL de ANSI/ISO y el SQLDA estilo DB2 son iguales, y ambas estructuras desempeñan el mismo papel en el procesamiento de SQL dinámico. No obstante, los detalles de empleo -el modo en el que las ubicaciones de los programas se asocian con los parámetros de las instrucciones de SQL, la manera en que la información se ubica y se recupera del área de descriptores, etc.- son bastante diferentes. En la práctica, el SQLDA estilo DB2 es la más importante, ya que el soporte de SQL dinámico apareció en la mayor parte de las principales marcas de SGBD, modeladas según la implementación de DB2, mucho antes de que se redactara el estándar SQL2. El SQLDA es una estructura de datos de tamaño variable con dos partes diferenciadas:
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] ;
Capítulo 18: SOL dinámico.
I I
Figura 18.8.
Empleo de EXECUTE con un SQLDA. (Continúa.)
552
SOL. Manual de referencia
Capítulo 18: SOL dinámico"
/* seis columnas de la tabla
'define COLCNT 6
REPRESENTANTES exec sql include sqlca: exec sql include sglda; exec sql begin declare section; char stmtbuf[2001]:
/*
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 parámetros */ parmda:= malloc(16:= (44 * parmcnt))¡ >lII strcpy(parmda -> sqldaid, "SQLDA "}; parmda->sqldabc:= (16:= (44 * parmcnt»; parmda->sqln = parmcnt;
exec sql end declare section;
char *malloc () struct { char pregunta[31];
char nombre(31); short codtipo; short longbuf; char seleccionada;
columns () '" {
struct sqlda
/* pregunta sobre esta columna */ /* nombre de esta columna */ /* el código de su tipo de datos */ /* longitud de su búfer *1 /* bandera "seleccionada" (sIn) */
/* Comienza a crear la instrucción UPDATE en el büfer 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 - - - - - - - - - - -
'n° , 'n' ,
'n' , 'n' , 'n' ,
.,
CD
/* Salta las columnas no seleccionadas */ if (columns[i] .selected :== 'n') continue;
'n') ;
/* Aftade una asignación a la instrucción dinámica UPDATE */ if (parmcnt> O) strcat(stmtbuf," ")¡ strcat(stmtbuf, columns[i] .nombre); strcat(stmtbuf, " = ?");
/* SQLDA para los valores de los parámetros SQLVAR para el valor actual de parm */ /* parámetro de recuento de ejecuciones número de empleado introducido por el usuario indice del array de columnas[] índice del array sqlvar en sqlda ¡. datos introducidos por el usuario .¡
,.
0
/* Asigna espacio para los datos y la variable indicadora, y
} /* Rellena la última SQLVAR para el parámetro de la cláusula WHERE */ strcat(stmbuf, where nurn_empl : ?"); parrnvar = parmda + parrncnt; parmvar->sqltype = 496; parmvar->sqllen := 4; parrnvar->sqldata : &empl_nurn; parmvar->sqlind : O;
/* pide al usuario que seleccione las columnas que hay que actuali.zar */ printf(-*** Programa de actualización de representantes ***\n\n"} ; parmcnt := 1; for (i := O; i < COLCNT¡ i++) /* Pregunta sobre esta columna */
Figura 18.8.
Figura 18.8.
Empleo "de EXECUTE con un SQLDA. (Continuación.)
~
Empleo·de EXECUTE con un SQLDA. (Continuación.)
5
554
SOL. Manual de referencia
Capítulo 18: SOL dinámico*
.-------------------------------(2)
parrnda->sqld = parrncnt¡><• /*
break;
pide al SGSD que compile toda la instrucción UPDATE dinámica */
case 501: /* Convierte los datos introducidos en valores enteros de cuatro bytes */
exec sql prepare updatestrnt fraro :stmtbuf; if {sqlca.sqlcode < Ol { ·printf("PREPARE error: %ld\n-, sqlca.sqlcodel; exit ( l ;
/* Ahora itera, for ( ; ; ) (
sscanf(inbuf,
-%ld",
parmvar->sqldatal;
break;
pidiendo los parámetros y haciendo UPDATEs */ /* Ejecuta la instrucción */ exec sql execute updatestmt using :parmda:<• if (sqlca.sqlcode < O) { printf("Error de EXECUTE: %ld\n", sqlca.sqlcode); exit ():
.--------------(2)
pide al usuario el número de empleado del representante que hay que actualizar *1 printf{"\nlntroduzca el número de empleado del representante: '); scanf("%ld", &num_empl); /*
if
555
(num_eropl == O)
break;
/* 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");
/* 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;
0
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. (Continuación.)
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 parámetros a la instrucción EXECUTE. El programa ilustra la técnica general para el empleo de las SQLDA, indicada por las llamadas de la Fignra 18.8: 1. 2. 3. 4.
El programa asigna un SQLDA de tamaño suficiente como para guardar la estructura SQLVAR para cada parámetro que se pasa. Define el campo SQLN para indicar el número de SQLVARS que pueden albergarse. Por cada parámetro que hay que pasar, el programa rellena una de las estructuras SQLVAR con información que describe ese parámetro. El programa determina el tipo de datos de los parámetros y ubica el código correcto de tipo de datos en el campo SQLTYPE. El programa determina la longitud del parámetro y la ubica en el campo BQLLEN.
Figura 18.8.
Empleo de EXECUTE con un SQLDA. (Continuación.)
5.
El programa asigna memoria para guardar el valor del parámetro y pone la dirección de la memoria asignada en el campo SQLDATA.
556 6.
7.
SOL Manual de referencia
El programa asigna memoria para guardar el valor de una variable indicadora del parámetro y pone la dirección de esa variable indicadora en el campo SQLIND. El programa define el campo SQLO en el encabezado SQLDA para indicar el número de parámetros que se pasan. Esto indica al SGBD el número de estructuras SQLVAR dentro del SQLDA que contienen datos vá-
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 instrucción EXECUTE con la cláusula USING DESCRIPTOR para pasar el valor de los parámetros mediante el SQLDA.
Capítulo 18: SOL dinámico.
nistra el primer conjunto de valores de los parámetros la instrucción ca pasa a ser:
UPDATE
557 dinámi-
update representantes set nombre = 'Sonia Javierre', oficina = 22, cuota = 175000.00 where num_empl = 106
y con el segundo conjunto de valores de los parámetros se transforma en: update representantes set nombre = 'Javier Sanchis', oficina where num_empl = 104
=
NULL, cuota = 275000.00
Obsérvese que este programa concreto copia la cadena de caracteres de petición para cada valor del parámetro en la estructura SQLNAME. El programa sólo hace esto por su propio interés; el SGBD ignora la estructura SQLNAME cuando se utiliza el SQLDA para pasar parámetros. A continuación puede verse un ejemplo de diálogo con el programa de la Figura J8.8:
Este programa es algo complejo, pero resulta sencillo comparado con la verdadera utilidad de actualización de propósito general de la base de datos. También ilustra todas las características de SQL dinámico necesarias para ejecutar de ma. nera dinámica las instrucciones con número variable de parámetros.
Nombre (sIn)? 8 Oficina (sIn)? 8 Jefe (sIn)? n Fecha_contrato (sIn)? n Cuota (sIn)? s Ventas (sIn)? n
Introduzca Introduzca Introduzca Introduzca
el el el el
número de empleado del representante: 106 nuevo valor de Nombre: Sonia Javierre nuevo valor de Oficina: 22 nuevo valor de Cuota: 175000.00
Introduzca Introduzca Introduzca Introduzca
el el el el
número de empleado del representante: 10' nuevo valor de Nombre: Javier Sanchis nuevo valor de Oficina: * nuevo valor de Cuota: 275000.00
Las instrucciones EXECUTE IMMEDIATE, PREPARE Y EXECUTE, tal y como se han descrito hasta ahora, admiten la ejecución dinámica de la mayor parte de las instrucciones de SQL. Sin embargo, no pueden admitir las consultás dinámicas, ya que carecen de un mecanismo para la recuperación del resultado de las consultas. Para admitir las consultas dinámicas, SQL combina las características de SQL di· nárnico de las instrucciones PREPARE y EXECUTE con las ampliaciones de las instrucciones de procesamiento de consultas de SQL estático, y añade una instrucción nueva. A continuación puede verse una aproximación a la fonna en que los programas llevan a cabo las consultas dinámicas: 1.
Introduzca el número 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 instrucción UPDATE dinámica y la prepara: 3. update representantes set nombre ~ ?, oficina where num_empl = ?
?, cuota = ?
4. La instrucción especifica cuatro parámetros, y el programa asigna un SQLDA de tamaño suficiente para manejar cuatro estructuras SQLVAR. Cuando el usuario sumi-
Una versión dinámica de la instrucción DECLARE CURSOR declara un cur· sor para la consulta. A diferencia de la instrucción estática DECLARE CURSOR, que incluye una instrucción SELECT. la forma dinámica de la instrucción DECLARE CURSOR especifica el nombre de la instrucción asociada con la instrucción SELECT. El programa crea una instrucción SELECT válida en un búfer, igual que si creara una instrucción UPDATE o DELETE dinámica. La instrucción SELECT puede contener marcadores de parámetro como los empleados en otras instrucciones de SQL dinámico. El programa utiliza la instrucción PREPARE para pasar la cadena de caracteres de la instrucción al SGBD. que analiza, valida y optimiza la instrucción y genera un plan de aplicación. Esto es idéntico al procesamiento de PREPARE utilizado para otras instrucciones de SQL dinámico. El programa utiliza la instrucción DESCRIBE para solicitar una descripción del resultado de la consulta que genera la consulta. El SOBO devuelve una descripción, columna por columna, del resultado de la consulta en
558
SOL Manual de referencia
Capítulo 18: SOL dinámico*
un área de dalos de SQL (SQL Data Area, SQLDA) proporcionada por el programa, indicando al programa el número de columnas de resultados de la consulta que hay y el nombre. tipo de datos y longitud de cada columna. La instrucción DESCRIBE se utiliza exclusivamente para las consultas dinámicas.
5.
6.
7.
8.
El programa utiliza las descripciones de las columnas del
SQLDA
para asignar
un bloque de memoria con el fin de recibir cada columna de resultados de la consulta. El programa puede asignar también espacio para una variable indicadora de la columna. El programa ubica la dirección del área de datos y la dirección de la variable indicadora en el SQLDA para indicar al SGBD el lugar al que debe llevar el resultado de la consulta. Una versión dinámica de la instrucción OPEN pide al SOBD que comience a ejecutar la consulta y pasa valores para los parámetros especificados en la instrucción SELECT dinámica. La instrucción QPEN coloca el cursor antes de la primera fila de los resultados de la consulta. Una versión dinámica de la instrucción 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 instrucción FETCH estática. que especifica una lista de variables del anfitrión para que reciban los datos. la instrucción FETCH dinámica 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 instrucción CLOSE concluye el acceso a los resultados de la consulta y rompe la asociación entre el cursor y los resultados de la consulta. Esta instrucción CLOSE es idéntica a la instrucción CLOSE de SQL estático; no hace falta ninguna ampliación para las consultas dinámicas.
La programación necesaria para llevar a cabo una consulta dinámica es más amplia que la necesaria para cualquier otra instrucción de SQL incorporado. Sin embargo, la programación suele resultar más tediosa que compleja. La Figura 18.9 muestra un pequeño programa de consultas que utiliza SQL dinámico 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.
559
consulta. Una vez completada la selecci6n del usuario. el programa ejecuta la consulta solicitada y muestra el resultado. "/
exec sql include sqlca; exec sql include sqlda; exec sql begin declare section; char stmtbuf[2001J; char tblconsul[32); char colconsul[32);
/* texto de SQL que hay que ejecutar */ /* tabla especificada por el usuario */ /* columna especificada por el usuario */
exec sql end declare section; /* Cursor para la consulta del catálogo 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)
/" Estructuras de datos del programa "/ cuentacol = O, /" número 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 búfer */ 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
Figura 18.9.
Recuperación de datos con SQl dinámico. (Continúa.)
/* Configura el procesamiento de los errores "/ exec sql whenever sqlerror goto handle_error; exec sql whenever not found gota no_mas_columnas; /* Consulta el catálogo del sistema para obtener los nombres de
las columnas de la tabla */
Figura 18.9.
Recuperación de datos con SQl dinámico. (Continuación.)
560
SOL. Manual de referencia
Capítulo 18: SOL dinámico.
/* Itera imprimiendo los datos de cada columna de la fila *1 for (i == O; i < eolcount; i++) {
exec sql apeo tblcurs; for
(;
)
{
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 añade a la lista de selección "/ iE (colcount++ > O) strcat (strntbuL· ",; strcat(stmtbuf, colconsul);'"
561
'*
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 búsqueda de la indicación de valores NULL */ if (*(qry_var -> sqlind») !: O) ( puts("jEs NULL!\n"); continue;
0
/* Obtenidos los datos reales; maneja cada tipo por separado */
switch (qry_var -> sqltype)
no_mas_columnas. exec sql close tblcurs:
case 448: case 449: /* Datos VARCHAR - simplemente los muestra */ puts(qry_var -> sqldata); break;
/* Finaliza la instrucción SELECT con una cláusula FROM */
strcat(stmtbuf, strcat(stmtbuf,
-from "); tblconsul):
/* Asigna SQLDA para la consulta dinámica */ 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;
case 496: case 497: /* Datos enteros de cuatro bytes - los convierte y los muestra */ printf{-'ld", *({int *) (qry_var->sqldata»); break;
~
3 4
/* 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»;
case 500: case 501: /* Datos enteros de dos bytes - los convierte y los muestra */ printf{"'d", *«(short *) (qry_var->sqldata)); break;
/* 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 (¡ ) {
case 480: case 481: /* Datos de coma flotante - los convierte y los muestra */ printf("'lf", -{(double *) (qry_var->sqldat)); break:
/- Captura la fila de datos en los búferes */ exec sql fetch sqlcurs using descriptor qry_da¡4I printf¡-\n-);
Figura 18.9.
Recuperación de datos con Sal dinámico. (Continuación.)
@
(2)
}
no_mas_datos. printf(-\nFin de los datos.\n-);
Figura 18.9.
Recuperación de datos con Sal dinámico. (Continuación.)
562
Capitulo 18: SOL dinámico·
SOL. Manual de referencia
/* Limpia el almacenamiento asignado */ (i =: O: i < colcount; i++) { qry_var =: qry_da->sqlvar + i;
ción de almacenamiento para los datos recuperados y para el SQLDA. El programa también 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 características del programa de ejemplo son típicas de las aplicaciones de producción que utilizan consultas dinámicas. Pese a su complejidad, la programación no resulta muy difícil en lenguajes como C, C++, Pascal, PUlo Java. Los lenguajes como COBOL y FORTRAN, que carecen de la posibilidad de asignar almacenamiento de manera dinámica y de trabajar con estructuras de dalOs de longitud variable, no pueden utilizarse para el procesamiento de consultas dinámicas. Los apartados siguientes estudian la instrucción DESCRIBE y las versiones dinámicas de las instrucciones DECLARE CURSOR, OPEN Y FETCH.
Recuperación de datos con SQl dinámico. (Continuación.)
La instrucción DESCRIBE El programa de la figura comienza preguntando al usuario el nombre de la tabla y luego consulta el catálogo 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 instrucción SELECT dinámica con base en las respuestas del usuario. La construcción mecánica paso a paso de una lista de selección en este ejemplo es muy típica de los programas del frontal de las bases de datos que generan SQL dinámico. En las aplicaciones reales, la lista de selección generada podría incluir expresiones o funciones agregadas, y pudiera haber lógica adicional del programa para generar las cláusulas GRQUP BY, HAVING y ORDER BY. También se utilizaría una interfaz gráfica de usuario en lugar de las primitivas peticiones al usuario del programa de ejemplo. No obstante, las etapas y los conceptos de programación siguen siendo los mismos. Obsérvese que la instrucción SELECT generada es idéntica a la instrucción SELECT interactiva que se utilizaría para llevar a cabo la consulta solicitada. El manejo de las instrucciones PREPARE y DESCRIBE Y el método de asignación de almacenamiento para los datos recuperados en este programa son también típicos de los programas de consultas dinámicas. Obsérvese 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 tamaño adecuado para cada columna. Este programa asigna también espacio para una variable indicadora para cada columna. El programa vuelve a colocar la dirección del bloque de datos y de la variable indicadora en la estructura SQLVAR. Las instrucciones OPEN, FETCH Y CLaSE desempeñan el mismo papel para las consultas dinámicas que para las estáticas, como ilustra este programa. Obsérvese que la instrucción FETCH especifica el SQLDA en lugar de una lista de variables del anfitrión. 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 programación necesaria para las consultas dinámicas está relacionada con la configuración del SQLDA y la asigna-
La instrucción DESCR-IBE, que puede verse en la Figura 18.10, es exclusiva de las consultas dinámicas. Se emplea para solicitar al SGBD una descripción de la consulta dinámica. La instrucción DESCRIBE se utiliza una vez compilada la consulta dinámica con la instrucci6n PREPARE, pero antes de ejecutarla con la instrucción OPEN. La consulta que se va a describir se identifica mediante su nombre de instrucción. El SGBD devuelve la descripción 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 instrucción DESCRIBE, el programa debe rellenar el campo SQLN del encabezado del SQLDA. que indica al SGBD el tamaño 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 número de columnas del resultado dela consulta. Si el tamaño del array SQLVAR (tal y como se ha especificado en el campo SQLN) es demasiado pequeño 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
Figura 18.10.
nombre-instrucción
INTO
nombre·descriptor------i.....
Diagrama sintáctico de la instrucción
DESCRIBE.
564
SOL. Manual de referencia
Capítulo 18: SOL dinámico"
la columna se obtiene a partir de una expresión, no se utiliza el campo SQLNAME.
• El campo SQLTYPE especifica un código de tipo de datos entero para la co· lumna. Los códigos de tipos de datos utilizados por las diferentes marcas de SGBD varían. Para los productos de SQL de IBM el código 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 máxima 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 tamaño del número decimal (en su byte superior) como la escala del número (en su byte inferior). • Los campos SQLDATA Y SQLINO no los rellena el SGBD. El programa de aplicación rellena estos campos con las direcciones del búfer de datos y de la variable indicadora de la columna antes de utilizar el SQLDA más adelante en una instrucción FETCH.
Umi complicación del empleo de la instrucción DESCRIBE es que el programa n~ puede conocer con antelación el número de columnas de resultados de la consulta que se producirá y. por tanto, no puede saber el tamaño de SQLDA que debe asignarse para recibir la descripción. Nonnalmente se utiliza una de estas tres estrategias para asegurarse de que el SQLDA tiene espacio suficiente para las descripciones obtenidas.
Tabla 18.1.
,
Códigos de tipos de datos I f SQLDA para DB2
permitido
fFipo de datos
NtrLL
CHAR
452
453
VAR0HAR
448
449
LONG VARCHAR
456
457
50'1' NtJLL
SMALLINT
500
501
INTEGER FLOAT
496 480
497 481
DECIMAL
484
485
DATE
384
385
TIME
388
389
TIMESTAMP
392
GRAPHIC
468
393 469
VARGRAPHIC
464
465
565
• Si el programa ha generado la lista de selección 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 número 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 número de elementos de la lisLa de selección, puede aplicar DESCRIBE al principio a la consulta dinámica en un SQLDA mínima con un array SQLVAR de un solo elemento. Cuando la instrucción DESCRIBE vuelve, el valor SQLD indica al programa el tamaño que debe tener el SQLDA. El programa puede asignar entonces un SQLDA del tamaño correcto y volver a ejecutar la instrucción DESCRIBE, especificando la nueva SQLDA. No hay ningún límite en cuanto al número de veces que se puede describir una instrucción preparada. • De manera alternativa, el programa puede asignar un SQLDA con un array SQLVAR lo bastante grande como para albergar una consulLa típica. Una instrucción DESCRIBE que emplee esta SQLDA tendrá éxito la mayor parte de las veces. Si el SQLDA resulta demasiado pequeña para la consulta, el valor SQLD indica al programa el tamaño que debe tener el SQLDA, y puede asignar una mayor y volver a aplicar la instrucción DESCRIBE a la instrucción en esa SQLDA.
La instrucción DESCRIBE suele emplearse para las consultas dinámicas, pero puede solicitar al SGBD que aplique DESCRIBE a cualquier instrucción preparada previamente. Esta característica resulta útil, por ejemplo, si un programa necesita procesar una instrucción de SQL desconocida escrita por el usuario. El programa puede aplicar PREPARE y DESCRIBE a la instrucción y examinar el campo SQLO del SQLDA. Si el campo SQLD es cero, el texto de la instrucción no era una consulta y se puede utilizar la instrucción EXECUTE para ejecutarla. Si el campo SQLD es positivo, el texto de la instrucción era una consulta, y la secuencia de instrucciones OPEN!FETCH!CLOSE debe utilizarse para ejecutarla.
La instrucción
DECLARE CURSOR
La instrucción dinámica
DECLARE CURSOR, que puede verse en la Figura 18.11, es una variación de la instrucción estática DECLARE CURSOR. Recuérdese del Capítulo 17 que la instrucción estática DECLARE CURSOR especificaba literalmente una consulta al incluir la instrucción SELECT como una de las cláusulas. Por el contra-
1------- DECLARE nombre-cursor CURSOR Figura 18.11.
FOR nombre-instrucción
11 •
Diagrama sintáctico de la instrucción dinámica DECLARE CURSOR.
566
SOL Manual de referencia
Capítulo 18: SOL dinámico*
rio la instrucción dinámica DECLARE CURSOR especifica la consulta de manera indirecta, especificando el nombre de la instrucción asociada con la consulta por la instrucción PREPARE. Al igual que la instrucción estática DECLARE CURSOR, la instrucción dinámica DECLARE CURSOR es una directiva para el precompilador de SQL, más que una instrucción 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 dinámica.
La instrucción dinámica
se puede especificar una variable indicadora para cada variable del anfitrión, si se considera necesario. La Figura 18.13 muestra el fragmento de un programa en el que la consulta dinámica tiene tres parámetros cuyos valores se especifican mediante variables del anfitrión. Si el número de parámetros no se conoce hasta el momento de la ejecución, el programa debe pasar el valor de los parámetros mediante una estructura SQLDA. Esta técnica de pase del valor de los parámetros ya se describió para la instrucción EXECUTE en el apartado «EXECUTE con SQLDA». Se emplea la misma técnica para la instrucción 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 parámetros. Obsérvese detenidamente que el SQLDA utilizada en la instrucción OPEN no tiene absolutamente nada que ver con el SQLDA utilizada en las instrucciones DESCRIBE Y FETCH:
OPEN
La instrucción dinámica OPEN, que puede verse en la Figura 18.12, es una variación de la instrucción estática ü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 instrucción OPEN se completa con éxito, el cursor se halla en un estado abierto y está listo para que lo emplee la instrucción FETCH. El papel de la instrucción OPEN para las consultas dinámicas recuerda el papel de la instrucción EXECUTE para otras instrucciones de SQL dinámico. Tanto la instrucción EXECUTE como la instrucción OPEN hacen que el SGBD ejecute una instrucción compilada previamente por la instrucción PREPARE. Si el texto de la consulta dinámica incluye uno o varios marcadores de parámetro, la instrucción OPEN, al igual que la instrucción EXECUTE, debe proporcionar el valor de esos parámetros. La cláusula USING se emplea para especificar el valor de los parámetros, y tiene un fonnato idéntico tanto en la instrucción EXECUTE como en la instrucción OPEN. Si el número de parámetros que van a aparecer en la co~sulta dinámica se conoce con antelación, el programa puede pasar el valor de los parámetros al SGBD mediante una lista dé variables del anfitrión en la cláusula USING de la instrucción OPEN. Como en la instrucción EXECUTE, el número de variables del anfitrión debe coincidir con el número de parámetros, el tipo de datos de cada variable del anfitrión debe ser compatible con el tipo exigido por el parámetro correspondiente, y
~ OPEN
nombre-cursor _ ,
567
• El SQLDA de la instrucción OPEN se utiliza para pasar el valor de los parámetros al SGBD para la ejecución de la consulta dinámica. Los elementos de su
/* El programa ha generado y preparado previamente una instrucción
SELECT como la siguiente: SELECT A, 8, C ... FROM REPRESENTANTES WHERE VENTAS BETWEEN ? AND ?
,;
con dos parámetros por especificar
pide al usuario los valores máximo y mínimo y lleva a cabo la consulta */ printf("Introduzca el valor mínimo del rango de ventas; "); scanf ( "% f", &valor_minimo); printf (~Introduzca el valor máximo del rango de ventas; "); scanf ("%f", &valor_maximo); /*
~¡_. . .
/* Abre el cursor para iniciar la consulta, pasando parámetros */ exec sql open qrycursor using :valor_minimo, :valor_maximo;
USING ~~/-anfitrión
L Figura 18.12.
=:::nombre-deSCriPtor Figura 18.13.
Diagrama sintáctico de la instrucción dinámica OPEN.
,, L
Instrucción OPEN con pase de parámetros mediante variables del anfitrión.
568
SOL Manual de referencia
Capítulo 18: SOL dinámico*
569
elementos de su array SQLVAR se corresponden con las columnas de los resultados de la consulta generados por la consulta dinámica.
/*
El programa ha generado y preparado previamente una instrucción SELECT como la siguiente: SELECT A, B, e FRQM REPRESENTANTES WHERE NUM EMPL IN ( ? , ?
.
...?)
Con un número variable de parámetros por especificar. El número de parámetros para esta ejecución 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 parámetros */ parmda = (SQLDA *)malloc(sizeof(SQLDA) + parmcnt * sizeof(SQLVAR)); parmda->sqln = parmcnt; /*pide al usuario el valor de los parámetros */ tor (i = O; i < parmcnt; i++) { printf (" Introduzca el número 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;
/* Abre el cursor para iniciar la consulta, pasando los parámetros */ exec sql apeo qrycursor using descriptor :parmda;
Figura 18.14.
Instrucción OPEN con SQLDA pase de parámetros.
array SQLVAR se corresponden con los marcadores de parámetro del texto de la instrucción dinámica. • 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
La instrucción dinámica
FETCH
La instrucción dinámica FETCH, que puede verse en la Figura 18.15, es una variaci6n de la instrucción estática 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. Recuérdese del Capítulo 17 que la instrucción estática FETCH incluye una cláusula INTQ con una lista de variables del anfitrión que reciben los valores de las columnas recuperadas. En la instrucción dinámica FETCH la lista de variables del anfitrión se sustituye por un SQLDA . Antes de utilizar la instrucción dinámica FETCH, es responsabilidad del programa de aplicación proporcionar las áreas de datos para recibir los datos·y la variable indicadora recuperados para cada columna. El programa de aplicación también 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 más 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 aplicación asigna un SQLDA, utiliza la instrucción DESCRIBE para obtener una descripción 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 instrucción FETCH. No obstante, no se exige que se utilice la misma SQLDA ni que el SQLDA especifique las mismas áreas ·de datos para cada instrucción FETCH. Resulta perfectamente aceptable que el programa de aplicación cambie los punteros SQLDATA y SQLIND entre instrucciones FETCH, recuperando dos filas sucesivas en ubicaciones diferentes.
Diagrama sintáctico de la instrucción dinámica FETCH.
.~.
570
La instrucción dinámica CLOSE La forma dinámica de la instrucción CLOSE es idéntica en sintaxis y funciones a la instrucción estática CLOSE que puede verse en la Figura 17.25. En ambos casos, la instrucción CLOSE finaliza el acceso a los resultados de la consulta. Cuando un programa cierra un cursor para una consulta dinámica, el programa suele desasignar también los recursos asociados con la consulta dinámica, incluidos:
• El
Capítulo 18: SaL dinámico.
SOL. Manual de referencia
asignada para la consulta dinámica y utilizada en las instrucciones DESCRIBE y FETCH. • Una segunda SQLDA posible, utilizada para pasar el valor de los parámetros a la instrucción üPEN. • Las áreas de datos asignadas para recibir cada columna de resultados de la consulta recuperados por una instrucción 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 después de la instrucción CLOSE.
571
L~ d~scripci6n detallada de las características de SQL dinámico admitido por las pnnclpales ~arcas d.e SGBD. se halla más allá del ámbito de este libro. No obstante, resulta InstructIvo exam~nar el soporte de SQL dinámico proporcionado por SQUDS y por Gracle como ejemplo del tipo de diferencias y ampliaciones de SQL dinámico que pueden hallarse en cada SGBD concreto.
SOL dinámico en Oracle
*
El SOBD de Oracle precedió a DB2 en el mercado y basó su soporte de SQL dinámico en el prototipo de IBM SystemIR. Por este motivo, el soporte de Oracle de SQL dinámico se diferencia algo del proporcionado por el estándar 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 parámetro, su empleo del SQLDA, el formato de su SQLDA y su soporte de la conversión 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 dinámico y los puntos de diferencia con DB2.
Parámetros con nombre
Dialectos de SOL dinámico Al igual que las demás panes del lenguaje SQL, SQL dinámico varía de una marca de SGBD a otra. De hecho, las diferencias en el soporte de SQL dinámico son más importantes que para SQL estático, ya que SQL dinámico deja al descubierto una parte mayor de los entresijos del SGBD subyacente -los tipos de datos, los formatos de datos, etc.-. En la práctica, estas diferencias hacen imposible escribir una única parte visible de propósito general de la base de datos que sea ponable de unas marcas de SGBD a otras empleando SQL dinámico. En lugar de eso, los programas del frontal de la base de datos deben incluir una capa de traducción. a menudo denominada controlador. para cada marca de SGBD con que cuentan para adaptarse a las diferencias. Los primeros productos del frontal solían distribuirse con un controlador diferente para cada marca popular de SOBD. La introducción de ODRe como capa API uniforme de SQL facilitó esta tarea, ya que se podía escribir una sola vez un controlador ODBC para cada marca de SOBD, y el frontal podía escribirse para que utilizara únicamente la interfaz ODBe. En la práctica, no obstante, el enfoque de mínimo común denominador de ODBe significaba que los programas del frontal no podían aprovechar las posibilidades exclusivas de los diferentes sistemas de SGBD admitidos, lo que limitaba el rendimiento de la aplicación. En consecuencia, los programas y herramientas del frontal más modernos siguen incluyendo un controlador diferente, explícito, para cada una de las marcas populares de SGBD. Se suele incl1,lir un controlador ODBe para proporcionar el acceso a las demás marcas.
Recuérdese que DB2 no permite referencias a las variables del anfitrión en las instrucciones preparadas de manera dinámica. En vez de eso, los parámetros de la instrucción se identifican mediante signos de interrogación (marcadores de parámetro) y el valor de esos parámetros se especifica en las instrucciones EXEeUTE u OPEN. Gracle permite especificar los parámetros en las instrucciones preparadas de manera dinámica empleando la sintaxis para las variables del anfitrión. Por ejemplo, esta secuencia de instrucciones de SQL incorporado es legal para Gracle: exec sql begin declare section;
char
strntbuf(lOOl);
numero_empleado; exec sql end declare seetion; int
strcpy (strntbuf,
"delete fram representantes where num_empl ~ :numero_rep;-); exec sql prepare delstmt from :stmtbuf; exec sql execute delstmt using : numero_empleado;
Aunque parece que numero_rep es una variable del anfitrión en la instrucción dinámica DELETE, en realidad es un parámetro con nombre. Como puede verse en el ejemplo, el parámetro con nombre se comporta exactamente. igual que los marcadores de parámetro de DB2. El valor del parámetro se obtiene de una variable real del anfitrión de la instrucción EXECUTE. Los parámetros con nombre suponen
572
SOL. Manual de referencia
Capítulo 78: SOL dinámico.
573
una verdadera comodidad cuando se utilizan instrucciones dinámicas con un número variable de parámetros. struct sqlda { int N; char *"V;
La instrucción DESCRIBE
La instrucción de Orade DESCRIBE se utiliza, al igual que la instrucción DESCRIBE de DB2, para describir los resultados de la consulta de una consulta dinámica. Al igual que DB2, Gracle envía las descripciones a un SQLDA. La instrucción D;ESCRIBE de Grade también puede utilizarse para solicitar una descripción de los parámetros con nombre en instrucciones preparadas de manera dinámica. Oraele también devuelve estas descripciones de los parámetros en un SQLDA. Esta instrucción DESCRIBE de Oracle solicita una descripción de las columnas de resultados de la consulta a partir de consultas dinámicas preparadas previamente: exec sql describe select list for qrystrnt into qry_sqlda;
int short short
*L; *T; **1;
int char
F; _"S;
short
"M;
short
·C;
char
Se corresponde con la instrucci6n de DB2:
-*x;
short
*y;
short
"Z;
exec sql describe qrystrnt into qry_sqlda;
Esta instrucción DESCRIBE de OracJe solicita una descripción de los paráme· tras con nombre de instrucciones dinámicas preparadas previamente. Las instrucciones pueden ser consultas u otras instrucciones de SQL: Figura 18.16.
exec sql describe bind list for thestmt into the_sqlda¡
Esta instrucción de Oracle no tiene equivalente en DB2. Con esta instrucción el programa normalmente examina la información del SQLDA, rellena los punteros del SQLDA para que apunten a los valores de los parámetros que el programa desea proporcionar y luego ejecuta la instrucción utilizando la forma SQLDA de las instrucciones OPEN o EXECUTE: DESCRIBE,
exec sql execute thestmt using descriptor the_sqlda; exec sql open qrycursor using descriptor the_sqlda;
La información devuelta por las dos formas de la instrucción 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 tamaño de los arrays utilizados para guardar las definiciones de las columnas. Se corresponde con el campo SQLN del SQLDA de DB2.
/ .. número de entradas de las arrays del SQLDA */ array de punteros para las áreas de
/* puntero al datos */ /* puntero al /* puntero al /* puntero al
array de longitudes de los búferes */ array de códigos de tipos de datos */ array de punteros para las variables
indicadoras */ /- número de entradas activas en los arrays de SQLDA */ /- puntero al array de punteros para los nombres de columnas/parámetros */ /* puntero al array de longitudes de los nombres de los búferes */ /" puntero al array de longitudes actuales de los nombres */ /" puntero al array de punteros para los nombres de los parámetros -/ /" puntero al array de longitudes de los búferes de los nombres de los indicadores */ /0 puntero al array de longitudes actuales de los ~ nombres de los indicadores */
SQLDA de Oracle.
• El campo F del SQLDA de Oracle indica el número 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 parámetro 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 búfer para cada columna de resultados de la consulta o cada valor de parámetro pasado. .Los punteros de este array se corresponden con el campo SQLDATA de cada estructura SQLVAR de DB2. • El ca·mpo L apunta a un array de enteros que especifica la longitud de,cada búfer 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 parámetro con
574
•
•
•
•
• •
Capitulo 78: SQL dinámico*
SOL. Manual de referencia
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 búferes a los que Oracle debe devolver el nombre de cada columna de resultados de la consulta o parámetro con nombre. Los búferes 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 tamaño de cada búfee al que apunta el array s. Para DB2, la estructura SQLNAME tiene un búfee 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 parámetros define los enteros de este array para que indiquen sus longitudes reales. Para DB2 la estructura SQLNAME tiene un búfer 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 búferes en los que Gracle debe devolver el nombre de cada parámetro indicador con nombre. Estos búferes sólo los utiliza la instrucción de Grac1e DESCRIBE BLIND LIST; no tienen ningún equivalente en DB2. El campo y apunta a un array de enteros que especifican el tamaño de cada búfer al que apunta el array x. No hay ningún equivalente en DB2. El campo z apunta a un array de enteros que especifican las longitudes reales de los nombres de los parámetros indicadores a los que apunta el array x. Cuando Gracle devuelve el nombre de los parámetros indicadores, define los enteros de este'array para indicar sus longitudes reales. No hay ningún equivalente en DB2.
Conversiones entre tipos de datos El formato de los tipos de datos que utiliza DB2 para recibir el valor de los parámetros 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 automática la conversión entre sus formatos internos de datos y los del sistema informático en el que se está ejecutando siempre que recibe valores de los parámetros del programa o le devuelve resultados de las consultas. El programa puede utilizar el SQLDA de Gracle para controlar la conversión de tipos de datos llevada a cabo por Grade. Por ejemplo, supóngase que el programa utiliza la instrucción DESCRIBE para describir los resultados de las consultas dinámicas y descubre (a partir del código de tipo de datos del SOLDA) que la primera columna contiene datos numéricos. El programa puede solicitar la conversión de los datos numéricos modificando el código del tipo de datos en el SQLDA antes de que capture los datos. Si el programa ubica el código 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.
575
La característica de conversión de tipos de datos del SOLDA de Orac1e proporciona una excelente portabilidad, tanto entre diferentes sistemas informáticos como entre diferentes lenguajes de programación. Otras marcas de SGBn poseen una característica parecida, pero entre ellas no están los productos de SQL de lBM.
SOL dinámico y el estándar SOL2 El estándar SQLl no abordaba SQL dinámico, por 10 que el estándar de facto para el SQL, tal y como se describe en los apartados anteriores, lo definió la implementación de IBM en DB2. El estándar SQL2 incluía de manera explícita un estándar para SQL dinámico, especificado en un capítulo aparte del estándar que tiene casi cincuenta páginas. En las áreas más sencillas de SQL dinámico el nuevo estándar SQL2 sigue estrechamente SQL dinámico utilizado actualmente por los productos de SGBD comerciales. Pero en otras áreas, incluidas hasta las consultas dinámicas de SQL más elementales, el nuevo estándar introduce incompatibilidades con los productos de SGBD ya existentes, 10 que exigirá la reescritura de las aplicaciones. Los próximos apartados describen con detalle el estándar SQL2 para SQL dinámico, con un énfasis especial en las diferencias con SQL dinámico estilo DB2 descrito en los apartados anteriores. En la práctica, el soporte de SQL dinámico estilo SQL2 va apareciendo poco a poco entre los productos de SGBD comerciales, y la mayor parte de la programación de SQL dinámico sigue exigiendo el empleo del antiguo SQL dinámico estilo DB2. Incluso cuando una versión nueva de un producto de SGBD admite las nuevas instrucciones de SQL2, el fabricante del SGBD proporciona siempre una opción del precompilador que acepta la antigua estructura de SQL dinámico utilizada por ese SGBD concreto. A menudo se trata de la opción 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 migración a las partes de SQL2 que presentan incompatibilidades con la práctica actual será lenta y evolutiva.
Instrucciones básicas de SOL2 dinámico Las instrucciones de SQL2 que implementan la ejecución de las instrucciones de SQL dinámico básico (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 métodos de ejecución de las instrucciones de SQL dinámico de una sola etapa y de dos etapas. La instrucción de SQL2 EXECUTE IMMEDIATE tiene una sintaxis y una operativa idénticas a las de su contrapartida de DB2. Ejecuta de manera inmediata la instrucción de SQL pasada al SGBD en forma de cadena de caracteres. Por tanto, la instrucción EXECUTE IMMEDIATE de la Figura 18.3 se ajusta al estándar SQL2.
576
r-
Capítulo 18: SOL dinámico"
SOL. Manual de referencia
EXECUTE IHMEOIATE variable-deJ-anfitrión
••
f-- PREPARE nombre-instrucción FROM variable-del·anfitrión
r-
EXECUTE
••
nombre-inst, ·ucción (
variable-del-
1- USING L n f i t f i ó n
,
USING SQL DESCRIPTOR nombre-descripror
I
f-1NTO----r
so
•
variable-delanfi,riñn
mbre-descripror
r-OEALLOCATE PREPARE nombre·instrucciÓn
Figura 18.17.
••
Instrucciones de SOL dinámico de SOL2.
Las instrucciones de SQL2 PREPARE y EXECUTE también operan de manera idéntica a sus contrapartida de estilo DBZ. La instrucción PREPARE pasa al SGBD una cadena de caracteres de texto que contiene una instrucción de SQL y hace que el SGBD la analice, la optimice y cree un plan de aplicación para ella. La instrucción EXECUTE hace que el SGBD ejecute realmente una instrucción preparada anteriormente. Al igual que la versión de DBZ, la instrucción de SQL2 EXECUTE acepta de manera opcional variables del anfitrión que pasan los valores concretos que hay que utilizar al ejecutar la instrucción de SQL. Las instrucciones PREPARE y EXECUTE de la Figura l8.4 (marcadas como elemento 2), por tanto, se ajustan al estándar SQLZ. DOS ampliaciones útiles de la estructura PREPARElEXECUTE forman parte de la especificación del nivel de cumplimiento completo del estándar SQL2 (ninguna de ellas forma parte de los niveles de cumplimiento iriicial ni intennedio). La primera es una útil acompañante de la instrucción PREPARE que deshace la preparación de una instrucción de SQL dinámico compilada previamente. La instrucción DEALLOCATE PREPARE ofrece esta posibilidad. Cuando el SGBD procesa esta instrucción, puede liberar los recursos asociados con la instrucción compilada, que suelen incluir alguna representación interna del plan de aplicación de la instrucción. La instrucción mencionada en la instrucción DEALLOCATE PREPARE debe coincidir con el nombre especificado en alguna instrucción PREPARE ya ejecutada.
577
En ausencia de una posibilidad como la ofrecida por DEALLOCATE PREPARE, el SOBD no tiene manera de saber si se volverá a ejecutar una instrucción preparada anteriormente y, por tanto, si debe conservar toda la información asociada con ella. En la práctica, algunas marcas de SOBD sólo conservan la versión compilada de la instrucción hasta el final de la transacción; en esos sistemas, hay que volver a preparar cada instrucción para cada transacción posterior en que se vaya a utilizar. Debido a la sobrecarga implicada en este proceso. otras marcas de SGBD conservan de manera indefinida la información relativa a la instrucción compilada. La instrucción DEALLQCATE PREPARE puede desempeñar un papel más importante en estos sistemas, en los que las sesiones de las bases de datos pueden durar varias horas. Obsérvese, no obstante, que el estándar SQLZ indica de manera explícita que el hecho de que una instrucción preparada sea válida fuera de la transacción en la que se prepara depende de la implementación. La ampliación de SQLZ a la instrucción de estilo DBZ EXECUTE puede resultar, en la práctica, todavía más importante. Pennite utilizar la instrucción EXECUTE para procesar instrucciones SELECT que devuelven una sola fila de resultados de la consulta. Al igual que la instrucción EXECUTE de DB2, la instrucción de SQL2 incluye una cláusula USING que menciona las variables del anfitrión que proporcionan el valor de los parámetros de la instrucción que se está ejecutando. Pero la instrucción de SQLZ también permite una cláusula INTO opcional que menciona las variables del anfitrión que reciben Jos valores devueltos por las consultas en una sola fila. Supóngase que se ha escrito un programa que genera de manera dinámica -una instrucción de consulta que recupera el nombre y la cuota de los representantes, con el núftlero de empleado de cada representante como parámetro de entrada. Utilizando SQL dinámico del estilo DBZ, incluso esta consulta sencilla implica la utilización de un SQLDA, de cursores, de un bucle con la instrucción FETCH, etc. Empleando SQL dinámico de SQLZ, la instrucción 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 instrucción preparada, esta consulta en una sola.fila puede ejecutarse de manera repetida después de haberla preparado una vez. Sigue adoleciendo de la restricción de que el número de columnas devueltas, y sus tipos de datos, deben conocerse al escribir el programa, ya que deben coincidir exactamente con el número y los tipos de datos de las variables del anfitrión de la cláusula INTO. Esta restricción se elimina permitiendo el empleo de un área de descriptores estilo SQLDA en lugar de una lista de variables del anfitrión, 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 dinámico de OBZ, el estándar SQL2 diverge sustancialmente del estilo
578
SOL. Manual de referencia
DB2 en el área del procesamiento de las consultas dinámicas. En concreto, el estándar SQL2 incluye cambios importantes en el área de datos de SQL de DB2 (SQL Data Area, SQLDA), que se halla en el corazón de las consultas dinámicas en varias filas. Recuérdese que el área de datos de SQL (SQL Data Area, SQLDA) proporciona dos funciones importantes: • Una manera flexible de pasar los parámetros que se van a utilizar en la ejecución de las instrucciones de SQL dinámico (pasando los datos del programa anfitrión al SOBD), como ya se ha descrito en el apartado «EXECUTE con SQLDA».
• La manera de que el resultado de la consulta se pase al programa en la ejecución de una consulta de SQL dinámico (enviando los datos del SOBD al programa anfitrión), como ya se ha descrito en el apartado «La instrucción 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 específica de cada lenguaje de programación. Por ejemplo, la estructura de longitud variable de las SQLDA estilo DB2 la hace muy difícil de representar en el lenguaje FORTRAN. La estructura SQLDA también hace suposiciones de manera implícita sobre la memoria del sistema informático en el que se está ejecutando el programa de SQL dinámico, el modo en que los elementos de datos de una estructura se alinean en ese sistema, etc. Para los redactores del estándar 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 manipulación de una estructura más abstracta denominada descriptor de SQL dinámico. 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 desempeñan exactamente el mismo papel. La parte fija de los descriptores de SQL2 especifica un recuento del número de elementos de la parte variable de cada descriptor. Cada elemento de la parte variable contiene información sobre un único parámetro 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 anfitrión. En vez de eso, son un conjunto de elementos de datos propiedad del software del SOBD. El programa anfitrión manipula los descriptores de SQL2 ---creándolos, destruyéndolos, ubicando elementos de datos en su interior, extrayendo datos de ellos- mediante un conjunto nuevo de instrucciones de SQL dinámico diseñado especialmente para esa finalidad. La Figura 18.19 resume estas instrucciones de gestión de descriptores de SQL2. Para comprender el modo en que funcionan las instrucciones de gestión de los descriptores, resulta instructivo volver a examinar el programa de actualizaciones de SQL, dinámico 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
Capítulo 18: SOL dinámico*
579
Parte fija
COUNT
número de elementos descritos
Parte variable -una aparición por elemento (parametro o columna de resultados de la consulta): TYPE
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)
PRECISION
precisión del elemento de datos
SCALE
escala del elemento de datos
DATETIME_INTERVAL_CODE
tipo de datos del intervalo de fecha/hora
OATETIME_INTERVAL_PRECISION
precisión de los datos del intervalo de fecha/hora
NULLABLE
indica si el elemento puede ser NULL
INDICATOR
indica si el elemento de datos es NULL (valor del indicador)
DATA
el propio elemento de datos
NAME
nombre del elemento de datos
UNNAMED
indica si el elemento de datos carece de nombre
Figura 18.18.
Estructura del descriptor de SQL2.
r---ALLOCATE DESCRIPTOR
J
nombre.descriPtor-L WITH MAX
r---DEALLOCATE DESCRIPTOR
••
númercrde·elementos
n o m b r e · d e s c r i p t o r - - - - - - - - - - - - - - - - 1 ,...
Instrucciones de gestión de los descriptores de SQL2.
580
Capítulo 18: SOL dinámico.
SOL. Manual de referencia
siendo idéntico 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 instrucción: ALLOCATE DESCRIPTOR parmdesc WITH MAX :parrncnt;
Esta instrucción sustituye la asignación 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. Obsérvese que el programa de la Figura 18.8 tenía que calcular la cantidad de almacenamiento que sería necesaria para la estructura parmda antes de asignarla. Con los descriptores de SQL2 ese cálculo se elimina, y el programa anfitrión se limita a indicar al SGBD el número de elementos que debe poder guardar la parle variable del descriptor. La siguiente etapa del programa es la definición del descriptor orientada a indicar los parámetros 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 parámetro se especifican con una modalidad de la instrucción SET DESCRIPTOR, con este fragmento de código: typecode = columnsliJ .typecode; length = columnsli].buflen; SET DESCRIPTOR parmdesc VALUE (:i + 1) TYPE = :typecode SET DESCRIPTOR parmdesc VALUE (:i + 1) LENGTH = ,length;
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 instrucción SET DESCRIPTOR, empleando variables del anfitrión. En este ejemplo concreto, se utilizan las variables sencillas typecode y length. Además, los códigos de tipos de datos de la Figura 18.8 eran privativos de DB2. El hecho de que cada fabricante de SGBD utilice códigos diferentes para representar los diferentes tipos de datos de SQL fue una causa importante de problemas de portabilidad en SQL dinámico. El estándar SQL2 especifica los códigos enteros de los tipos de datos para todos los tipos de datos especificados en el estándar, lo que elimina este problema. Los códigos de tipos de datos de SQL2 se resumen en la Tabla 18.2. Por tanto, además de las otras modificaciones. habría que modificar los códigos de tipos de datos de la estructura de columnas de la Figura 18.8 para utilizar estos códigos de tipos de datos del estándar SQL2. Las instrucciones de las llamadas 5 y 6 de la Figura 18.8 se utilizaron para enlazar la estructura SQLDA con los búferes del programa utilizados para contener los datos de los parámetros y de las variables indicadoras correspondientes. Efec~ tivamente, ponen punteros a esos búferes 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 específica el valor de los datos y del indicador como variables del anfitrión, más adelante en el programa. Por tanto, habría que eliminar las "instrucciones de las llamadas 5 y 6 durante la conversión a SQL2.
Tabla 18.2.
Códigos de tipos de datos de SQL2
il'ipo de datos
Código
Códigos de tipos de datos (TYPE) INTEGER
4
SMALLINT
S
NUMERIC
2
DECIHAL
3
FLOAT
ó
REAL
7
DOUBLE PRECISION
8
CHARACTER CHARACTER VARYING
12
BIT
14
BIT VARYING
tS
DATE/TIME/TIMESTAMP
9
INTERVAL
10
Subcódigos de fecha/hora (In terval_Code) DATE
t
TIME
2
TIME WITH TIME ZONE
4
TIMESTAMP
3
TIMESTAMP WITH TIME ZONE
S
Subcódigos de fecha/hora (Interval_precision) YEAR
1
MONTH
2
OAY
3
HOUR
4
MINUTE
5
SECaNO
6
YEAR - MONTH
7
OAY - HOUR
8
OAY - MINUTE
9
OAY - SECONO
10
581
582
SOL. Manual de referencia
Capitulo 18: SOL dinámico·
La instrucción de la llamada 7 de la Figura 18.8 define el SQLDA para que indi· que el número de valores de los parámetros que se pasan realmente al SGBD. De manera parecida, hay que definir los descriptores de SQL2 para que indiquen el número de parámetros que se pasan. Esto se hace con una modalidad de la instrucción SET DESCRIPTOR: SET DESCRIPTOR parrndesc COUNT :
:parmcnt;
De manera estricta, esta instrucción SET DESCRIPTOR debería, probablemente, colocarse antes en el programa y ejecutarse antes de las de los elementos indivi· duales. El estándar SQL2 especifica un conjunto completo de reglas que describen el modo en que la definición 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 jerarquía natural de la información. Por ejemplo, si se define el tipo de datos de un elemento concreto para que indique un entero, el estándar indica que se volverá a definir la información correspondiente del descriptor que indica la longitud del mismo elemento como algún valor dependiente de la implementación. Normalmente esto no afecta a la programación, pero significa que no se puede dar por supuesto que, porque se haya definido anteriormente algún valor dentro del descriptor, conservará ese mismo valor. Es mejor rellenar el descriptor de manera jerárquica, comenzando con la información de nivel superior (por ejemplo, el número de elementos y sus tipos de datos) y pasando luego a la información 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 instrucción PREPARE compila la instrucción dinámica UPDATE y su modalidad no cambia para SQL2. El programa entra ahora en el bucle for, pidiendo los parámetros al usuario. Una vez más, los conceptos son los mismos, pero los detalles de la manipulación 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 petición), el programa de la Figura 18.8 define de manera adecuada el búfer de los indicadores de parámetro con la instrucción: * (parmvar->sQ1ind) ;
-1;
y si el valor no es NULL, el programa vuelve a definir el búfer de los indicadores con la instrucción: * (parmvar->sQlind) :
583
Obsérvese 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 búferes en la estructura del SQLDA. Finalmente, el programa de la Figura 18.8 pasa al SGBD el valor real del parámetro 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 búferes de datos a los que apunta el SQLDA. Una vez más, la conversión a SQL2 implica la sustitución de estos punteros y la manipulación directa del SQLDA con una instrucción 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 especificación de longitud, el pase de los datos es incluso más sencillo, ya que sólo es necesaria la forma DATA de la instrucción SET DESCRIPTOR. También resulta útil darse cuenta de que SQL2 especifica las conversiones implícitas de tipos de datos entre las variables del anfitrión (como inbuf) y los tipos de datos de SQL. De acuerdo con el estándar SQL sería 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 conversión automática y la detección de errores. Con el SQLDA definida finalmente corno es necesario, el programa de la Figura 18.8 ejecuta la instrucción dinámica UPDATE con los parámetros pasados en la llamada 9, empleando una instrucción EXECUTE que especifica un SQLDA. La conversión de esta instrucción en un descriptor de SQL2 es directa; se transforma en: EXECUTE updatestmt USING SQL DESCRIPTOR parrndesc;
Las palabras clave de la instrucción 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 continuación para indicar al SGBD que debe desasignar el descriptor de SQL2. La instrucción que lo lleva a cabo es:
o; DEALLOCATE DESCRIPTOR parrndesc;
Para los descriptores de SQL2 estas instrucciones se volverían 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;
En prooramas sencillos corno éste, la instrucción DEALLOCATE no resulta muy necesaria, ~ero en los programas más complejos del día a día, con varios descrip~ tares, resulta muy conveniente desasignarlos cuando el programa deja de necesi~ tarlos.
584
SOL. Manual de referencia
Capítulo 18: SOL dinámico.
SOL2 y consultas de SOL dinámico En las instrucciones de SQL dinámico de los apartados anteriores los descriptores de SQL2, al igual que las SQLDA a las que sustituyen, se utilizan para pasar información de los parámetros desde el programa anfitrión al SGBD, para su empleo en la ejecución de instrucciones dinámicas. El estándar SQL2 también utiliza los descriptores de SQL en las instrucciones para consultas dinámicas, donde, dado que las SQLDA las sustituyen, controlan el pase de los resultados de las consultas desde el SGBD al programa anfitrión. La Figura 18.9 muestra el listado de un programa de consultas de SQL dinámico del estilo DB2. Resulta útil examinar el modo en que el programa de la Figura 18.9 cambiaría para adaptarse al estándar SQL2. Una vez más, el flujo del programa permanece idéntico bajo SQL2, pero los detalles cambian mucho. Las modalidades de las instrucciones de procesamiento de consultas de SQL dinámico ~e pueden ver en la Figura 18.20.
r--
DESCRIBE
T;T
nombre-instrucción USING SQL DESCRIPTOR nombre·descriptor----...
OUT"'"
r--
IN"'" DECLARE
~ CURSOR FOR
nombre-cursor [ INSENSITlVE
~ ALLQCATE nombre-eursor
T L
r--
OPEN
nombre·cursor
J L
SCROLL
J
rr=T
INSESITIVE
nombrtt-jnstrucx:ión---+e
;¡
••
variab/e.de/-
1- USING L..:nfi;ió~
r--
FETCH
nombre-cursor
USlNG SQL DESCRIPTOR
nombre-descriptor
¡
~ mro ~nr;ri~
r--
I
&
variable""lie/-
LUSING SQL DESCRIPTOR
ALLOCATE DESCRIPTOR qrydesc WITH MAX :colcount; DESCRIBE querystrnt USING SQL DESCRIPTOR qrydesc;
La modalidad de SQL2 de la instrucción 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 anfitrión debe recuperar la información del descriptor, fragmento a fragmento, cuando la necesita. La instrucción GET DESCRIPTOR lleva a cabo esta función, igual que la función SET DESCRIPTOR desempeña la función opuesta de poner la información 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 sustituirían por la instrucción:
nombre·descriptor
:length
LENGTH;
nombre-instrucción - . .
SCROLL
I
L
La declaración del cursor para la consulta dinámica, en la llamada 1 de la Figura 18.9. sigue igual bajo SQL2. La construcción de la instrucción dinámica SE~ LECT en la llamada 2 también sigue sin cambios. igual que la instrucción PREPARE de la llamada 3. Las modificaciones del programa comienzan en la llamada 4, en la que el programa utiliza la instrucción DESCRIBE para obtener una descripción de los resultados de la consulta, que se devuelve en un SQLDA denominaaa qry_da. Para SQL2 esta instrucción 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 serían:
GET DESCRIPTOR qrydesc VALUE (:i + 1) qry_var -> sqldat z malloc{length); CURSOR FOR
585
I
, •
La instrucción de la llamada 5 que asigna los búferes para cada elemento de resultados de la consulta sigue siendo necesaria, pero el método para indicar al SGBD el lugar en que debe colocar los resultados cambia para SQL2. En lugar de ubicar la dirección de destino del programa para cada elemento en el SQLDA, el programa debe ubicar estas direcciones en el descriptor de SQL2, empleando la instrucción SET DESCRIPTOR. Los búferes de las variables indicadoras no son necesarios con el descriptor de SQL2. En su lugar, la información sobre si las columnas contienen valores NULL puede obtenerse del descriptor para cada fila a medida que las captura, como puede verse más adelante en el programa de ejemplQ. En este ejemplo concreto, el número de columnas de los resultados de la consulta 10 calcula el programa a medida que crea la consulta. El programa también podría obtener el número de columnas del descriptor de SQL2 con esta modalidad ,¡ I de la instrucción GET DESCRIPTOR:
!
GET DESCRIPTOR qrydesc :colcount = COUNT; CLaSE
nomórlH:ursor
Figura 18.2'0.
, •
Instrucciones de procesamiento de consultas de SQL2 dinámico.
Habiendo obtenido la descripción de los resultados de la consulta, el programa la lleva a cabo abriendo el cursor de la llamada 6_ La fonna sencilla de la instrucción QPEN, sin ningún parámetro de entrada, se ajusta al estándar SQL2. Si la consulta
586
SOL. Manual de referencia
Capítulo 18: SOL dinámico"
587
dinámica especificaba algún parámetro, puede pasarse al SGBD como una serie de variables del anfitrión o mediante un descriptor de SQL2. La instrucción OPEN de SQL2
especifica en la estructura del descriptor. El programa debe seguir utilizando el descriptor para determinar la información sobre cada columna de resultados de-
que utiliza variables del anfitrión es idéntica a la del estilo DB2, que puede verse en el programa de la Figura 18.13. La instrucción OPEN de SQL2 que utiliza descriptores es paralela a la instrucción de SQL2 EXECUTE que utiliza descriptores, y se diferencia de
vueltos, como su longitud o si contiene valores
la de estilo DB2. Por ejemplo, la instrucción
OPEN
NULL.
Por ejemplo, para determi-
nar la longitud devuelta de una columna de datos de caracteres, el programa puede utilizar la instrucción:
de la Figura 18.14: GET DESCRIPTOR qrydesc VALUE(:i + 1)
:1ength = RETURNED_LENGTH;
OPEN qrycursor USING DESCRIPTOR :parmda;
se transforma para SQL2 en esta instrucción
OPEN:
Para determinar si el valor de la columna era la instrucción:
el programa puede utilizar
QPEN qrycursor USING SQL DESCRIPTOR parmdesc;
GET DESCRIPTOR qrydesc VALUE{:i
La técnica para pasar los parámetros de entrada a la instrucción OPEN mediante los descriptores de SQL2 es exactamente la misma que ya se describió anteriormente para la instrucción EXECUTE. Al igual que la implementación de Gracle de SQL dinámico, el estándar SQL2 ofrece una manera de que el programa anfitrión obtenga una descripción de los parámetros de la consulta dinámica, así como una descripción de los resultados de la consulta. Para el fragmento de programa de la Figura 18.14, la siguiente instrucción DESCRIBE:
y, de manera parecida, para determinar el tipo de datos de la columna, el programa puede utilizar la instrucción:
DESCRIBE INPUT querystmt USING SQL DESCRIPTOR parmdesc;
devolverá, en el descriptor de SQL2 denominado parmdesc, una descripción de cada uno de los parámetros que aparecen en la consulta dinámica. El número de parámetros puede obtenerse con la instrucción GET DESCRI PTOR, recuperando el elemento COUNT del descriptor. Al igual que con la implementación de Oracle, el estándar SQL2 puede tener dos descriptores asociados con cada consulta dinámica. El descriptor de entrada, obtenido con la instrucción DESCRIBE INPUT, contiene descripciones de los parámetros. El descriptor de salida contiene descripciones de las columnas de resultados de la consulta. El estándar permite pedir, de manera explícita, la descripción del resultado: DESCRIBE OUTPUT querystmt USING SQL DESCRIPTOR qrydesc;
pero la modalidad DESCRIBE OUTPUT de la instrucción es la predeterminada, y lo más habitual es omitir la palabra clave OUTPUT. Volviendo al ejemplo de consulta dinámica 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 más, la modalidad de SQL2 de la instrucción 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 búferes del programa, tal y como se
+
1)
NULL,
GET DESCRIPTOR qrydesc VALUE{:i + 1)
;indbuf = INDICATOR;
:type = TYPE;
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 instrucción CLOSE sigue sin cambios bajo SQL2. Después 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 dinámico de las Figuras 18.8, 18.9 Y 18.14 para hacer que se ajusten al estándar SQL2 ilustran, con detalle, las nuevas características especificadas por el estándar y el grado en el que se diferencian del uso normal de SQL dinámico de hoy en día. En resumen, las modificaciones respecto de SQL dinámico 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 asignación y desasignación de las estructuras de datos SQLDA del programa anfitrión. • En lugar de manipular directamente los elementos del SQLDA, el programa especifica los valores y la información de los parámetros mediante la instrucción SET DESCRIPTOR. • En lugar de manipular directamente los elementos del SQLDA, el programa obtiene la información sobre los resultados de la consulta, y los propios resultados de la consulta mediante la instrucción GET DESCRIPTOR. • La instrucción DESCRIBE se utiliza tanto para obtener las descripciones de los resultados de la consulta (DESCRIBE OUTPUT) como para obtener las descripciones de los parámetros (DESCRIBE INPUT). • Las instrucciones EXECUTE, OPEN y FETCH están ligeramente modificadas para especificar el descriptor de SQL2 por su nombre, en lugar del SQLDA.
588
SOL. Manual de referencia
Resumen
t
Este capítulo describe SQL dinámico, una forma avanzada de SQL incorporado. SQL dinámico se necesita pocas veces para escribir aplicaciones sencillas de procesamiento de datos, pero resulta crucial para la creación de partes visibles de finalidad general de las bases de datos. SQL estático y SQL dinámico presentan un equilibrio clásico entre la eficiencia y la flexibilidad, que puede resumirse de la manera siguiente: • Sencillez. SQL estático resulta relativamente sencillo; incluso su característica más compleja, los cursores, puede comprenderse fácilmente en términos de los conceptos familiares de entrada y salida de archivos. SQL dinámico es complejo, exige la generación dinámica de instrucciones, estructuras de datos de longitud variable y la gestión de la memoria, con asignación y desasignación de la memoria, alineación de tipos de datos, gestión de punteros y los problemas asociados. • Rendimiento. SQL estático se compila dentro de un plan de aplicación en el momento de la compilación; SQL dinámico debe compilarse en el momento de la ejecución. En consecuencia, el rendimiento de SQL estático suele ser mucho mejor que el de SQL dinámico. El rendimiento de SQL dinámico se ve enormemente afectado por la calidad del diseño de las aplicaciones; un diseño que minimice la cantidad de sobrecarga de compilación puede aproximarse al rendimiento de SQL estático. • Flexibilidad. SQL dinámico permite que los programas decidan en el momento de la ejecución las instrucciones concretas de SQL que van a ejecutar. SQL estático exige que todas las instrucciones de SQL se codifiquen con antelación, al escribir los programas, 10 que limita la flexibilidad de los programas. SQL dinámico utiliza un conjunto de instrucciones de SQL incorporado ampliadas para soportar sus características dinámicas: • La instrucción EXECUTE IMMEDIATE pasa al SGBD el texto de una instrucción de SQL dinámico, que lo ejecuta de manera inmediata. • La instrucción PREPARE pasa al SGBD el texto de una instrucción de SQL dinámico, que la compila en un plan de aplicación, pero no la ejecuta. La instrucción dinámica puede incluir marcadores de parámetro cuyos valores se especifican al ejecutar la instrucción. • La instrucción EXECUTE pide al SGBD que ejecute una instrucción dinámica compilada previamente por una instrucción PREPARE. También proporciona el valor de los parámetros para la instrucción que se va a ejecutar. • La instrucción DESCRIBE devuelve una descripción de una instrucción dinámica preparada previamente dentro de un SQLDA. Si la instrucción dinámica es una consulta, la descripción incluye una descripción de cada columna de resultados de la consulta.
Capftulo 78: SOL dinámico.
589
• La instrucción DECLARE CURSOR para consultas dinámicas especifica la consulta mediante el nombre de instrucción que se le asignó cuando la compiló la instrucción PREPARE. • La instrucción OPEN para consultas dinámicas pasa el valor de los parámetros para la instrucción dinámica SELECT y solicita la ejecución de la consulta. • La instrucción FETCH para consultas dinámicas captura una fila de resultados de la consulta en áreas de datos del programa especificadas por la estructura SQLDA. • La instrucción CLOSE para consultas dinámicas concluye el acceso a los resultados de la consulta.
CAPíTULO
19
Las API de SOL
I
I 1
j
La técnica de SQL incorporado para el acceso mediante programación 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 implementación de SQL Server de Sybase, adoptaron un enfoque diferente. En lugar de intentar mezclar SQL con otro lenguaje de programación. esos productos proporcionan una biblioteca de llamadas a funciones en forma de interfaz de programación de aplicaciones (Application Programming Interface, APl) para el SGBD. Para pasar las instrucciones de SQL al SGBD, los programas de aplicación llaman a las funciones de la API, que llama a otras funciones para recuperar del SGBn los resultados de la consulta y la información 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 manipulación de cadenas de caracteres, las funciones matemáticas, la entrada y salida de archivos y la gestión 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 básicas proporcionadas por el propio sistema operativo. La API de SQL, por tanto, no es más que otra biblioteca que debe conocer el programador. En los últimos años, 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 capítulo describe los conceptos generales utilizados por todas las interfaces API de SQL. También describe características propias de algunas de las API propietarias empleadas por sistemas de SGBD populares basados en SQL, así como el estándar ANSIIISO de la interfaz del nivel de llamadas de SQL (SQL Call·Level Interface, CU) y el estándar de conectividad abierta de bases de datos (Open Database Connectivity, ODBe) de Microsoft en el que se basa. Finalmente, describe JDBe, que es el estándar 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
SQL. Manual de referencia
Capítulo 79: Las API de SOL
Conceptos de las API Cuando un SOBO alberga una interfaz de llamadas a funciones, los programas de aplicación se comunican con el SGBO exclusivamente mediante un conjunto de llamadas que se conoce colectivamente como interfaz de programación de aplicaciones (Application Programming interface) o API. La operación básica de las API típicas 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.
llamadas a fa API usuario,
CONNECT
contrasei\.. , SEND
(" upda te
pedidos set ... ")
EXECUTE () STATUS_CHECK ()
) OK S&LECT
Programa de aplicación
• Para enviar una instrucción de SQL al SGBD, el programa crea la instrucción en forma de cadena de caracteres de texto en un búfer y luego hace una llamada a la API para pasar el contenido de ese búfer 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 búfer 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 aplicación 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 configuración, el código para las funciones API se halla en el sistema cliente, donde se ejecuta el programa de aplicación. El software del SOBD se halla en el sistema servidor, donde reside la base de datos. Las llamadas desde el programa de aplicación a la API tienen lugar de manera local dentro del sistema cliente, y el código 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 tráfico 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. Además, las API de SQL tienden a dejar a la vista las posibilidades subya· centes del SGBD más que el enfoque de SQL incorporado, lo que produce todavía más diferencias. No obstante, todas las APl de SQL disponibles en los productos
("select * from oficinas ... ·)
EXECUTE ()
SGBD
Cliente
GETROW ()
Cliente
(101, Navarra, ... )
-
-
GETROW ()
(12, Castellón,... )
• • • DISCONNECT
1 Programa I
I ()
API ~
- _.
Servidor
1 Programa 1
SGBD
-
-
I
I
I
-
API
Ba~datos
U
I
~
/ Figura 19.1.
Empleo de un API de SQL para el acceso al SGBD.
593
Figura 19.2.
La API de SQl en una arquitectura cliente/servidor.
594
SOL. Manual de referencia
Capítulo 19: Las API de SOL
595
comerciales de SQL se basan en los mismos conceptos fundamentales que se ilustran en las figuras 19.1 y 19.2. Estos conceptos también se aplican a la API de ODBC y a los estándares ANSI/ISO más recientes que se basan en ella.
Tabla 19.1,
Funciones básicas de la API dblib {continuación}
La API dblib (SaL Server)
dbmsghandle ()
Establece un procedimiento de manejo de mensajes escrito por el usuario.
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 años, 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 añadido API a las que se puede hacer llamadas más 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 también proporcionó el modelo para gran parte de la API para ODBC de Microsoft. SQL Server y su API también son un ejemplo excelente de SGBD diseñado desde el comienzo alrededor de una arquitectura cliente/servidor. Por todos estos motivos, resulta útil comenzar la exploración de las API de SQL examinando la API básica 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 aplicación. 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 demás llamadas proporcionan características avanzadas, métodos alternativos de interacción con el SGBD o versiones de llamada única de características que, de otro modo, necesitarían varias llamadas.
dberrhandle()
Establece un procedimiento de un manejo de errores escrito por el usuario.
Función
Descripción
Tratamiento de errores
Tabla 19.1.
Procesamiento del resultado de las COllsultas Dbbind( )
Enlaza una columna de resultados de la consulta con una variable del programa.
dbnextrow ( )
Captura la siguiente fila de resultados de la consulta.
dbnumcols ()
Obtiene el número de columnas de resultados de la consulta.
dbcolname ( )
Obtiene el nombre de una columna de resultados de la consuha.
dbcol t.ype ()
Obtiene el tipo de datos de una columna de resultados de la consulta.
dbcollen()
Obtiene la longitud máxima de una columna de resultados de la consulta.
Dbdata( l
Obtiene un puntero a un valor de datos recuperado.
dbdatlen( )
Obtiene la longitud real de un valor de datos recuperado.
dbcanquery ( )
Cancela una consulta antes de que se capturen todas las filas.
Funciones básicas de la API dblib
Función
Descripción
Técnicas básicas de SaL Server
Conexi6n y desconexi6n de la base de datos dblogin ()
Proporciona una estructura de datos para la información de inicio de sesión.
Dbopen ()
Abre una conexión con SQL Server.
dbuse( )
Establece la base de datos predeterminada.
Dbexit()
Cierra la conexión con SQL Server.
Procesamiento bdsico de instrucciones
Un programa sencillo de SQL Server que actualice una base de datos puede utilizar un conjunto muy pequeño de llamadas a dblib para realizar su trabajo. El programa de la Figura 19.3 implementa una aplicación sencilla para la actualización de cuotas de la tabla REPRESENTANTES de la base de datos de ejemplo. Resulta idéntico al programa de la Figura 17.17, pero utiliza la API de SQL Server API en lugar de SQL incorporado. La figura ilustra la interacción básica entre los programas y SQL Server: l.
dbcmd()
Pasa el texto de la instrucción de SQL a dblib.
dbsqlexec ( )
Solicita la ejecución de un lote de instrucciones.
dbresults()
Obtiene el resultado de la siguiente instrucción de SQL del lote.
dbcancel ()
Cancela el resto del lote de instrucciones.
2. 3. (continúa)
El programa prepara un registro de inicios de sesión, rellenando el nombre de usuario, la contraseña y cualquier otra infonnación necesaria para conectarse con el SOBD. El programa llama a dbopen () para establecer conexión con el SOBD. Debe haber una conexión para que el programa pueda enviar instrucciones de SQL a SQL Server. El programa crea una instrucción de SQL en un búfer y llama a dbcmd () para que pase el texto de SQL a dblib. Las sucesivas llamadas a dbcmd ()
596
SOL Manual de referencia
Capitulo 79: Las API de SOL
main (l {
LQGINREC
"'loginrec;
/" estructura de datos para
4.
,.
información de inicio de sesión "/ OBPROCESS *dbproc;
char
amount_str[31]:
int
status;
/" estructura de datos para la conexión */
/" importe introducido por el usuario (en forma de cadena de caracteres) "/ /" estado de devolución de l . llamada a dblib */
5.
6.
597
se suman al texto pasado anteriormente; no se exige que se envíe una instrucción completa de SQL en cada llamada a dbcmd ( ) . El programa llama a dbsqlexec (), que da instrucciones a SQL Server para que ejecute la instrucción pasada anteriormente con dbcrod ( ) . El programa llama a dbresul ts () para determinar el éxito o el fracaso de la instrucción. El programa llama a dbexi t () para cerrar la conexión 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 implícita con la única base /* Obtiene una estructura de inicio de sesión y define un nombre de usuario y una contraseña */
/* Se conecta con SQL Server */ dbproc '" dbopen(loginrec. "-); ~
(!)
0
pide al usuario el importe del aumento o la disminución de la cuota */ printf("Aumentar o disminuir en: -J; gets{amount_str); /*
/* Pasa la instrucción de SQL a dblib */ dbcmd(dbproc, ·update representantes set cuota = cuota + ~ dbcmd(dbproc. amount_str); .44------------------------------' /* pide a SQL Server que ejecute la instrucción */ dbsqlexec (dbprocJ; ~
/* Obtiene el resultado de la ejecución de la instrucción */ status", dbresultsldbproc); 4 if (status ! '" SUCCEED) printf(*Error durante la actualización.\n-); else printf("Actualización concluida con éxito.\n");
/* Interrumpe la conexión con SQL Server */ dbexit (dbprocl; ~ exit () ;
0 ~
0
de datos disponible (como en DB2), o incluye una instrucción de SQL incorporado para la conexión (como la instrucción CONNECT especificada por el estándar SQL2). El programa dblib se conecta con un servidor concreto de SQL Server con la llamada dbopen ( ) . • La instrucción de SQL UPDATE que procesa realmente el SGBD es idéntica en los dos programas. Con SQL incorporado, la instrucción forma parte del código fuente del programa. Con dblib, la instrucción se pasa a la API en forma de secuencia de una o varias cadenas de caracteres. De hecho, el enfoque de dblib recuerda más a la instrucción de SQL dinámico EXECUTE IMMEDIATE que a SQL estático. • En el programa de SQL incorporado, las variables del anfitrión proporcionan el vínculo 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 instrucción de SQL. En general, el programa de SQL incorporado de la Figura 17.17 es más corto y, probablemente, más 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 anfitrión implica que las modalidades interactiva e incorporada de las instrucciones de SQL son diferentes. Además, el programa de SQL incorporado deben procesarlo tanto el precompiladar de SQL corno el compilador de C, lo que prolonga el ciclo de compilación. 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 técnicas especiales de codificación.
Lotes de instrucciones Figura 19.3:
Programa sencillo que utiliza dblib.
El programa de la Figura 19.3 en'lÍa a SQL Server una sola instrucción y comprueba su estado. Si un programa de aplicación debe ejecutar varias instrucciones de
598
SQL. Manual de referencia
Capitulo 79: Las AP/ de SOL
SQL, puede repetir el ciclo dbcmd() I dbsqlexec () I dbresults () para cada instrucción. 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
/* estructura de datos para la
~loginrec:
/*
DBPROCESS *dbproc;
información de inicio de sesión */ estructura de datos para la conexión
*'
/* Elimina los representantes con pocas ventas */ dbcmd{dbproc, -delete from representantes where ventas 10000.00") ;
<
599
Obsérvese que es responsabilidad del programa incluir los espacios o los signos de puntuación 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 después de otra. Cada llamada a dbresul ts () desplaza la API hasta el resultado de la siguiente instrucción del lote e indica al programa si la instrucción ha tenido éxito o ha fallado. En el programa que puede verse en la Figura 19.4 el programador conoce con antelación que hay tres instrucciones en el lote. y puede codificar las tres llamadas correspondientes a dbresul ts (). Si el número de instrucciones del lote no se conoce con antelación. el programa puede llamar a dbresul ts () repetidamente hasta que reciba el código de error NO_MORE_RESULTS. El fragmento de programa de la Figura 19.5 ilustra esta técnica. Manejo de errores
El valor devuelto por la función dbresul ts () indica al programa si la instrucción correspondiente del lote tuvo éxito o falló. Para obtener una información más detallada sobre Jos fallos, el programa debe proporcionar su propia función de manejo de mensajes. El software de dbl ib llama de manera automática a la función 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
I1'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·};
/* pide a SQL Server que ejecute el lote de instrucciones */ dbsqlexec(dbproc) ;
/* Ejecuta instrucciones anteriormente con llamadas a dbcmd-() dbsqlexec(dbproc};
/* Itera para comprobar el resultado de cada instrucción del lote */ while (status: dbresu1ts(dbproc) != NO_MORE_RESULTS { if (status == FAIL) goto handle_error; else printf("Instrucción ejecutada con éxito.\n");
/* Comprueba el resultado de cada una de las tres
instrucciones */ if (dbresults(dbproc) if (dbresults(dbproc) if (dbresults{dbproc)
/* Acabado el bucle; lote completado con éxito */ printf ( "Lote completado. \n·) ; exit (1;
Figura 19.5.
Procesamiento del resultado de un lote de dblib.
600
SOL Manual de referencia
nes de SQL. Obsérvese que dbl ib llama a la función 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 función de retrollamada, a la que llama el software de SQL Server). Esto permite a la función 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 función de manejo de mensajes denominada msg_rtn (). Cuando comienza el programa, activa la función de manejo de mensajes llamando a rnsghandIe (). Supóngase que posteriormente se produce un error, mientras SQL Server está procesando la instrucción 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 parámetros: • dbproc. La conexión en la que se produjo el error. • msgno. El número de error de SQL Server que identifica el error. • msgstate. Un parámetro que proporciona información sobre el contexto del
error.
Capítulo 19: Las API de SaL
/* Variables externas para guardar la información sobre los errores */ int errcode; /* código de error guardado */ char errmsg(256]; /* mensaje de error guardado */ /* Define nuestra propia función 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;
• severity. Un número que indica la gravedad del error. • msgtext. Un mensaje de error correspondiente a msgno.
La función msg_rtn () de este programa maneja el mensaje imprimiéndolo y guardando el número de error en una variable del programa para utilizarlo más adelante en el programa. Cuando la función 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 más 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. Además de los errores de las instrucciones de SQL detectados por SQL Server, también pueden producirse errores dentro de la propia API de dblib. Por ejemplo, si se pierde la conexión 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 función de manejo de errores diferente. que opera de manera muy parecida a la función de manejo de errores que se ha descrito aquí. Una comparación de la Figura 19.6 con las figuras 17.10 y 17.13 ilustra las diferencias entre las técnicas 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 aplicación y devolviendo un estado de fallo de la función de la API que encontró el error. • En SQL incorporado el procesamiento de errores es sincrónico. La instrucción 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 asíncrono. Cuando una llamada a la API falla, SQL Server llama a
601
/* Imprime el número y el mensaje de error */ printf("*** Error: %d Message: %s\n", msgno, msgtext)¡
/* Guarda la información del error para el programa de aplicación */ 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 conexión */
/* Instala nuestra propia función de manejo de errores */ dberrhandle(rnsg_rtn)
/* Ejecuta una instrucción 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
SOL. Manual de referencia
la función de manejo de errores o de mensajes del programa de aplicación durante la llamada a la API. Vuelve más adelante al programa de aplicación con un estado de error. • SQL incorporado sólo 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 aplicación sólo puede dar un número limitado de respuestas cuando se produce un error. Los programas de SQL Server tienen más flexibilidad para el manejo de los errores. No obstante, el esquema de llamadas utilizado por dblib es más sofisticado, y aunque resulta familiar para los programadores de sistemas, puede que no lo sea para los programadores de aplicaciones.
Capítulo 19: Las API de SOL
603
main (J (
LOGINREC
*loginrec;
OBPROCESS *dbproc; char
repname(16] ;
short
repquota:
float
repsales;
/, estructura de datos para la información de inicio de sesión */ /, estructura de datos para la conexión */ / ' ciudad para la oficina, recuperado */ /' número de empleado del jefe, recuperado */ / ' ventas de la oficina, recuperado */
/* Abre una conexión con SQL Server */ loginrec = dblogin(): DBSETLUSER (loginrec,
La técnica de SQL Server para manejar las consultas mediante programación es muy parecida a su técnica para manejar otras instrucciones de SQL. Para llevar a cabo las consultas. los programas envían a SQL Server una instrucción SELECT y utilizan dblib para recuperar el resultado de la consulta fila a fila. El programa de la Figura 19.7 ilustra la técnica de procesamiento de consultas de SQL Server.
/* 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
1. 2.
3.
El programa utiliza las llamadas dbcmd () y dbsqlexec () para pasar a SQL Server una instrucción SELECT y solicitar su ejecución. Cuando el programa llama a dbresults () para la instrucción SELECT, dbl ib devuelve el estado de finalización de la consulta y también 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-
dos de la consulta, para indicar a dblib dónde debe llevar los datos de
4.
5.
cada columna. Los argumentos de dbbind () indican el número de columna, el búfer que va a recibir sus datos, el tamaño del búfer 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.
Cuando no quedan disponibles más filas de resultados, la llamada a dbdevuelve el valor NO_MORE_ROWS. Si hubiera más instrllccio· nes en el lote a continuación de la instrucción SELECT, el programa podría llamar a dbresul ts () para desplazarse a la siguiente instrucción.
DBSETLPWD
"'---0
/* Obtiene la primera instrucción del lote */ dbresults(dbproc); ~
/* 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
/* Itera para recuperar las filas de resultados de la consulta */ while (status = dbnextrow(dbproc) SUCCEED) {~
G)
/* Imprime los printf("NOmbre: printf("Cuota: printf{"Venta5:
datos de este representante */ %5\n", nombrerepl; %f\n\n", cuotarepl; %f\n", ventasrepl;
nextrow ()
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 biunívoca 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-
1* Busca errores y cierra la conexión */ if (status == FAIL) (
.4t---------~@
printf(-Error de SQL.\n"); dbexit (dbproc); exit ();
Figura 19.7.
Recuperación del resultado de la consulta empleando dblib.
604
SOL. Manual de referencia
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 carácter NULL. La segunda y la tercera columnas, CUOTA y VENTAS, están enlazadas con números 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 más, 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:
• SQL incorporado tiene dos técnicas 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 técnica. independientemente del número de filas del resultado de la consulta. • Para especificar la consulta, SQL incorporado sustituye la instrucción SELECT por la instrucción SELECT única o por la instrucción DECLARE CURSOR. Con SQL Server, la instrucción SELECT enviada por el programa es idéntica a la instrucción SELECT interactiva de la consulta. • Con SQL incorporado. ¡as variables del anfitrión qne reciben el resultado de la consulta se mencionan en la cláusula 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 función dblib (dbresults () y dbnextrow(»), que conservan el propio lenguaje SQL más racionalizado. Debido a su relativa simplicidad y a su parecido con la interfaz de SQL interactivo, muchos programadores encuentran la interfaz de SQL Server más sencilla de utilizar para el procesamiento de las consultas que la interfaz de SQL incorporado. Recuperación de valores NULL
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 sustitución de los valores NULL. De manera predeterminada, SQL Server utiliza cero corno valor de sustitución de los tipos de datos numéricos, una cadena de caracteres de espacios en blanco para las cadenas de caracteres de longitud fija y una cadena de caracteres vacía para las cadenas de caracteres de longitud variable. El programa de aplicación puede modificar el valor predeterminado para cualquier tipo de datos mediante una llamada a la función 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-
Capítulo 19: Las API de SOL
605
peTaría un valor cero en la variable quota_value. Obsérvese 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 sustitución resulta aceptable, pero en otras resulta importante poder detectar los valores NULL. Estas últimas aplicaciones deben utilizar un esquema alternativo para la recuperación del resultado de las consultas, que se describe en el apartado siguiente. Recuperación mediante punteros
Con la técnica básica de recuperación 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. Además, la llamada dbnextrow () careceoe un mecanismo para la entrega de los valores NULL al programa. Para resolver estos dos problemas, dbl ib ofrece un método alternativo de recuperación 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 método alternativo:
main( ) (
LOGINREC
*loginrec;
OBPROCESS -dbproc; char
"namep;
int
citylen;
float
*quotap;
float
"salesp;
/ ' estructura de datos para la información de inicio de sesión -1 / ' estructura de datos para la conexión ' / / ' 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 ' /
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.
Recuperación mediante la función dbdata{). (Continúa.)
606
SOL. Manual de referencia
Capítulo 19: Las API de SOL
4. dbcmd(dbproc, "select nombre, cuota, ventas fraro representantes "); dbcmd(dbproc, ·where ventas> cuota arder by nombre "j; dbsqlexec(dbproc); /* Llega a la primera instrucción del lote */
5.
'4~--------------~
dbresults(dbproc); /* Recupera la única fila de resultados de la consulta */ while (status = dbnextrow(dbproc) SUCCEED) ('4~----------~~
==
/* consigue fila * I nombrep cuotap ventasp lonnombre
/* Copia el valor de NOMBRE en nuestro propio búfer 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);
0
/* Comprueba la terminación con éxito */ if (status ~= FAIL) printf("ErrOr de SQL.\n"); dbexit(dbproc) ; exitO;
Figura 19.8.
1.
2. 3.
Recuperación mediante la función dbdata ¡). (Continuación.)
El programa envía la consulta a SQL Server y utiliza dbresul ts () para tener acceso al resultado, como hace para cualquier instrucción 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 señala a una ubicación de los búferes internos de dbl ib.
607
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 función dbdata () devuelve un puntero para valores null (O), y dbdatlen () devuelve O como longitud del elemento. Estos valores de devolución proporcionan al programa una manera de detectar y responder a los valores NULL en los resultados de las consultas.
El programa de la Figura 19.8 es más enrevesado que el de la Figura 19.7. En general, resulta más sencillo utilizar la función dbbind () que el enfoque dbdata ( ) • a menos que el programa necesite manejar valores NULL o un gran volumen de resultados de la consulta. Recuperación aleatoria de filas
Los programas procesan generalmente los resultados de las consultas de SQL Server desplazándose por ellos secuencialmente mediante la llamada a dbnextrow ( ) . Para la exploración de aplicaciones. dbl ib también proporciona un acceso aleatorio limitado a las filas de resultados de la consulta. Los programas deben permitir de manera explícita el acceso aleatorio a las filas de resultados de las consultas activando una opción de dblib. La llamada a dbgetrow () puede utilizarse entonces para recuperar una fila a partir de su número de fila. Para incorporar la recuperación aleatoria de filas, dbl ib almacena las filas de resultados de las consultas en un búfer interno. Si los resultados de la consulta caben totalmente dentro del búfer de dblib, dbgetrow () admite la recuperación aleatoria de cualquier fila. Si los resultados de la consulta superan el tamaño del búfer, sólo 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 más allá del final del búfer devolverá la condición especial de error BUF_FULL. El programa debe descartar entonces;algunas de las filas guardadas del búfer. 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 función dbgetrow (). Por tanto, dblib admite la recuperación aleatoria de resultados de la consulta dentro de una ventana limitada, dictada por el tamaño del búfer de filas, como puede verse en la Figura 19.9. El programa puede especificar el tamaño del búfer 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 estándar de SQL2. En ambos casos se admite la recuperación aleatoria mediante el número de fila. No obstante, los cursores de desplazamiento son punteros auténticos 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 función dbgetrow () sólo proporciona el acceso aleatorio dentro de una ventana limitada. Esto resulta adecuado para las apli-
60S
Capítulo 79: Las API de SaL.
SOL. Manual de referencia
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) añadieron el soporte completo de los cursores estándar 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 acción de la instrucción FETCH es capturar los datos de la base de datos en los procedimientos almacenados para su procesamiento, no recuperarlos realmente en el programa de aplicación 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 Capítulo 20.
Resultados
de la consulta
Ya procesados
Búfer de fijas dblib_---
>El el búfer dbgetrow ( dbnextrow
I
)
I(
)
dbnextrow ( ) ~
• • •
dbgetrow ( ) dbnextrow I( )
dbnexcrow ( ) I
Figura 19.9.
.
I
,,
,/ ,/
¡ Desplazados por dbnextrow ()
Consultas dinámicas
Todavía fuera del búfer
i
Recuperación aleatoria de filas con dblib.
609
.'
caciones limitadas de exploración, pero no puede ampliarse fácilmente a las consultas de gran tamaño.
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 instrucción 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 asíncrona mucho más independiente entre el programa y el SGBD. En respuesta a los lotes de instrucciones que contienen una o más instrucciones SELECT SQL Server envía el resultado de la consulta al software de dblib, que las maneja. La recuperación 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 podían albergar las· actualizaciones posicionadas, ya que su concepto de fila en curso se
En los ejemplos de programas que hemos visto hasta ahora en este capítulo, las consultas que había que realizar se conocían con antelación. Las columnas de resultados de la consulta podían enlazarse con variables del programa mediante llamadas explícitas a dbbind () incluidas en el programa. La mayor parte de los programas que utilizan SQL Server pueden escribirse empleando esta técnica. (Este enlace estático con las columnas se corresponde con la lista fija de variables del anfitrión empleada en la instrucción FETCH de SQL estático de SQL incorporado estándar, que se describe en el Capítulo 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 descripción 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 ejecución. (Este enlace dinámico de las columnas se corresponde con el uso de la instrucción DBNUMCOLS ( ) de SQL dinámico y de SQLDA, de SQL dinámico incorporado, tal y como se describe en el Capítulo 18). La Figura 19.10 muestra un programa interactivo de consultas que ilustra la técnica de dblib para el manejo de las consultas dinámicas. El programa acepta un nombre de tábla 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 instrucción SELECT y luego utiliza estas etapas para ejecutar la instrucción SELECT y mostrar los datos de las columnas seleccionadas: 1.
2.
El programa pasa la instrucción SELECT generada a SQL Server mediante la llamada a dbcmd (), solicita su ejecución 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 número de columnas de los resultados de la consulta generadas por la instrucci6n SELECT.
610
SOL. Manual de referencia
Capítulo 19: Las API de SOL
/* 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) ;
main( ) (
/* Se trata de un programa sencillo de consultas de propósito 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.
'"
*loginreci
DBPROCESS *dbproc; char
stmbuf(2001];
char
querytbl[32):
char
querycol [32] ;
int int
status; f~rst col
int
colcount;
int char
i; inbuf[lOl];
O,
char
*ítem_name[lOOl:
char
*item_data[lOO) ;
int
char int
item _type[lOO];
*address; length;
'" '"
'" '" '"'" '" '"'" '"
'" '" '"
'"
/* consulta el catálogo 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);
estructura de datos para la información del inicio de sesión */ estructura de datos para la conexión "" texto de SQL que hay que ejecutar */ tabla especificada por el usuario */ columna especificada por el usuario */ estado de devolución de dblib */ ¿es ésta la primera columna escogida? * / número 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 búferes de columnas */ array para realizar el seguimiento de los tipos de datos de las columnas */ dirección del búfer de la columna actual */ longitud del búfer de la columna actual */
/* 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 añadirla a la lista de selección */ if (first_col++ > O) strcat(stmbuf, -); strcat(stmbuf, querycol};
/* Concluye la instrucción SELECT con una cláusula FRDM */ strcat(stmbuf, -from -¡; strcat(stmbuf, querytb1);
/- Ejecuta la consulta y se desplaza al resultado de la consulta */
tmbuf:i'=~4~~~=~~~==~==~;;;;;~;== _ _0 •
dbcmd (dbproc, s dbsqlexec (dbproc); dbresults(dbproc);
/* Abre una conexión con SQL Server */ loginrec == dblogin(); DBSETLUSER{loginrec, ·santi-); DBSETLPWD (loginrec, -tigre"); dbproc '" dbopen(loginrec, "-¡;
Figura 19.10.
"J;
/* Inicia la instrucción SELECT en el búfer */ strcpy(stmbuf, ·select -);
"' LOGINREC
611
•
/- pide a dblib que describa cada columna, le asigne memoria y la enlace */ colcount == dbnumcols(dbproc); 4 ~
Empleo de dblib para consultas dinámicas. (Continúa.)
Figura 19.10.
j
Empleo de dblib para consultas dinámicas. (Continuación.)
612
for
SOL. Manual de referencia
Capítulo 19: Las API de SOL
(i '" o; i < colcount; i++) ( item_nameli] '" dbcolname(dbproc.
type '" dbcoltype(dbproc. swi tch (type I (
i);
i);
case NTBSTRINGBIND: /" Datos de texto -- simplemente los muestra *1 puts(item_data[i)) ; break;
CV
..
•
case INTBIND: /" Datos enteros de cuatro bytes -- los convierte y los muestra "/ printf(-Uf-, "«double *) (iteIn.-data[illl); 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;
-0
addreSS};~
case FLT8BIND: /* Datos de coma flotante -- los convierte y los muestra "/ printf(-Uf", *({double *l (item_data[ij))); break;
dbexi t (dbproc) ; exit (); Captura y muestra las filas de los resultados de la consulta */ while (status: dbnextrow(dbproc) SUCCEED) ( 4 /*
==
~
/* Itera para imprimir los datos de cada columna de la fila */ printf(-\n-); for (i = O; i < colcount; i++) (
Halla SQLVAR de esta columna; imprime la etiqueta de la columna */ printf("Columna número 'ld (%s): ", i+l, item_name(i); /*
Figura 19.10.
3.
4.
5. /* Maneja cada tipo de datos por separado */
switch(item_type[ij)
Figura 19.10.
Empleo de dblib para consultas dinámicas. (Continuación.)
~ara
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 máxima. El programa asigna un búfer para que reciba cada columna de resultados de la consulta y llama a dbbind () para que enlace cada columna con su búfer. Cuando se han enlazado todas las columnas, el programa llama a dbnextrow () repetidamente para recuperar cada fila de resultados de la consulta.
(
Empleo de dblib para consultas dinámicas. (Continuación,)
El programa basado en dblib de la Figura 19.10 desempeña exactamente la misma función que el programa de SQL dinámico incorporado de la Figura 18.9. Resulta instructivo comparar los dos programas y las técnicas que utilizan:
614
SOL. Manual de referencia
• Tanto para SQL incorporado como para dblib el programa crea una instrucción SELECT en sus búferes y la remite al SGBD para su procesamiento. Con SQL dinámico, la instrucción especial PREPARE maneja esta tarea; con la API de SQL Server se utilizan las funciones estándar dbcmd () y dbsqlexec ().
• Para ¡as dos interfaces el programa debe solicitar al SGBD una descripción de las columnas de resultados de la consulta. Con SQL dinámico esta tarea la maneja la instrucción especial DBNUMCOLS ( ) • y la descripción se devuelve en una estructura de datos de SQLDA. Con dblib la descripción se obtiene llamando a las funciones de la API. Obsérvese que el programa de la Figura 19.10 conserva sus propios arrays para realizar el seguimiento de la información de las columnas. • Para las dos interfaces el programa debe recibir el resultado de la consulta y enlazar cada columna con esas ubicaciones del búfer. Con SQL dinámico, el programa enlaza las columnas ubicando las direcciones del búfer en las estructuras SQLVAR de SQLDA. Con SQL Server, el programa utiliza la función dbbind () para enlazar las columnas. • Para las dos interfaces los resultados de la consulta se devuelven fila a fila en los búferes del programa. Con SQL dinámico, el programa recupera las filas de los resultados de la consulta mediante una versión especial de la instrucción 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 dinámicas es muy parecida para las dos interfaces. La técnica de SQL dinámico utiliza instrucciones especiales y estructuras de datos que son privativas de SQL dinámico; son bastante diferentes 'de las técnicas empleadas para las consultas de SQL estático. Por el contrario, las técnicas de dblib para las consultas dinámicas son básicamente las mismas que las empleadas para las demás consultas. Las únicas características añadidas son las funciones dblib que devuelven la información sobre las columnas de los resultados de las consultas. Esto tiende a hacer el enfoque de la API llamable más sencillo de comprender por los programadores de SQL menos experimentados.
ODBC y el estándar 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 desempeña 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 más fácil para los desarrolladores de aplicaciones para Windows la incorporación del acceso a las bases de datos. Pero las grandes diferencias entre los diferentes sistemas de bases de datos y sus API lo hacían muy"difíciL Si Jos desarrolladores de aplicaciones deseaban que los progra-
Capítulo 19: Las API de SOL
615
m:1s se ejecutaran con varias marcas de SGBD, tenían que proporcionar un módulo de interfaz de la base de datos (generalmente denominado controlador) diferente escrito especialmente para cada una. Cada programa de aplicación que quisier~ ofrecer acceso a varias bases de datos tenía que proporcionar un conjunto de controladores. • La solución de Microsoft .a este problema fue la creación 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 más amplio de programas de aplicación.
La estandarización de la interfaz en el nivel de llamadas (CLI) ODBC ya hubiera sido importante sólo como estándar de Microsoft. Sin embargo, Microsoft trabajó para hacerla también un estándar independiente del fabricante. Una asociación de fabricantes de bases de datos denominada Grupo de Acceso a SQL (SQL Access Group) trabajaba en la normalización 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 estándar para el acceso a las bases de datos independiente de los fabricantes. La dirección del grupo de acceso a SQL acabó transfiriéndose al consorcio europeo X/Open, otra organización de normalización, como parte de sus estándares globales para un entorno común 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 atención en la normalización de este aspecto de SQL. El estándar XlOpen (basado en los primeros trabajos en ODBC de Microsoft) se tornó como punto de partida y se modificó ligeramente para crear un estándar oficial ANSI/ISO. El estándar 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 estándar SQL:1999. Microsoft ha modificado ODBC para que se adapte al estándar oficial SQU CL!. El estándar CL! forma, más o menos, el nivel central de la revisión ODBC 3 de Microsoft. Otras posibilidades de nivel superior de ODBC 3 superan la especificación de CL! para ofrecer más funcionalidad API y tratar con los problemas específicos de la gestión de ODBC corno parte del sistema operativo Windows. En la práctica, las posibilidades del nivel central de üDBC y la especificación SQU CL! forman el estándar 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 estándar muy incorporado. Prácticamente todos los sistemas de bases de datos
616
SOL. Manual de referencia
Capítulo 19: Las AP/ de SOL
basados en SQL ofrecen una interfaz ODBe/eLI entre las interfaces que incorporan. Algunas marcas de SGBD han adoptado incluso üDBe/eLI como API estándar de la base de datos. Millares de programas de aplicación incorporan ODBCI eLI, incluidos todos los principales paquetes de herramientas de programación, herramientas de procesamiento de consultas y de formularios y redactores de informes. así como el software de productividad popular, como las hojas de cálculo y los programas de gráficos. El estándar 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 ejecución de instrucciones de SQL, la recuperación 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 estándar, incluidas las posibilidades de SQL estático y de SQL dinámico.
Tabla 19.2.
617
Fvnciones de la API SQljCLI (continuación)
Función
Descripción
Gestión de transacciones SQLEndTran ( )
Concluye una transacción de SQL.
SQLCancel ()
Cancela la ejecución de una instrucción de SQL.
Manejo de parámetros SQLBindParam ()
Enlaza la ubicación del programa con el valor de un parámetro.
SQLPararnData ()
Procesa valores diferidos de parámetros.
SQLPutData ()
Proporciona valores diferidos de parámetros 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()
Define el nombre de un cursor.
SQLGetCursorName()
Obtiene el nombre de un cursor.
Gestión de recursos y de conexiones
SQLFetch ()
Captura una fila de resultados de la consulta.
SQLAllocHandle ()
Asigna los recursos para el entorno, la conexión, los descriptores o la instrucción.
SQLFetchScroll ()
Captura una fila de resultados de la consulta con desplazamiento.
SQLFreeHandle()
Libera los recursos asignados previamente.
SQLCloseCursor()
Cierra un cursor abierto.
SQLAllocEnv( )
Asigna recursos para un entorno de SQL.
SQLGetData()
Obtiene el valor de una columna de resultados de la consulta.
SQLFree¡::nv ( )
Libera los recursos para un entorno SQL.
Descripción del resultado de la consulta
SQLAllocConnect()
Asigna recursos para una conexión a la base de datos.
SQLNumResultCols()
Determina el número de columnas del resultado de la consulta.
SQLFreeConnect ()
Libera los recursos para una conexión a la base de datos.
sQLDescribeCol()
D~scribe una sola columna de resultados de la consulta.
SQLAllocStmt ()
Asigna recursos para una instrucción de SQL.
SQLColAttribute()
Obtiene los atributos de una columna de resultados de la consulta.
SQLFreeStmt ()
Libera los recursos p'ara una instrucción de SQL.
SQLGetDescField()
Obtiene el valor de un campo descriptor.
SQLConnect ()
Establece una conexión con la base de datos.
SQLSetDescField()
Define el valor de un campo descriptor.
SQLDisconnect ()
Concluye una conexión con la base de datos ya establecida.
SQLGetDescRec ( )
Obtiene valores de un registro descriptor.
sQLSetDescRec()
Define los valores de un registro descriptor..
SQLcopyDesc()
Copia los valores del área descriptora.
Función
Descripción
Ejecución de instrucciones SQLExeCDirect ()
Ejecuta directamente una instrucción de SQL.
SQLPrepare ( )
Prepara una instrucción de SQL para su ejecución posterior.
Manejo de errores
SQLExecute ()
Ejecuta'una instrucción de SQL preparada anteriormente.
SQLError ()
SQLRowCount ()
Consigue el número de filas afectadas por la última instrucción de SQL.
SQLGetDiagField()
Obtiene el valor de un campo de registros de diagnóstico.
SQLGetDiagRec ()
Obtiene el valor del registro de diagnóstico.
(continúa)
Obtiene la información sobre los errores.
(continúa)
618
SQL. Manual de referencia
Tabla 19.2.
Capítulo 19: Las API de SOL
619
Funciones de la API SOl/eU (continuación)
Descripción
Función
"nombre_usuario
"jase" ;
¡' nombre de usuario para la
char
"contra_usuario
·xyz" ;
¡- contraseña del usuario para la conexión "1 ¡' importe introducido por el usuario '*1 ¡- búfer para la instrucción
conexión "1
Gesti6n de atributos SQLSetEnvAtt.r( )
Define el valor de los atributos de un entorno de SQL.
sQLGetEnvAttr ()
Recupera el valor de los atributos de un entorno de SQL.
SQLSetStrntAttr()
Define el área descriptora que hay que utilizar para una instrucción de SQL.
SQLGetStrntAttr()
char
Obtiene el área descriptora para una instrucción de SQL.
Gesti6n de controladores
char
cadena_importe[31);
char
buf_instruc[128) ;
SQL *1
1" Asigna controladores para el entorno SQL, la conexión y la instrucción *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;
SQLDataSources()
Obtiene una lista de los servidores de SQL disponibles.
sQLGetFunctions{)
Obtiene la información sobre las características incorporadas por la implementación de SQL.
1'* Conecta con la base de datos, pasando el nombre del servidor, el usuario y la contraseña '*1 1'* SQL_NTS indica una cadena de caracteres terminada en un
SQLGetlnfo()
Obtiene información sobre las características incorporadas por la implementación de SQL.
carácter NULL en lugar de pasar su longitud "1 SQLConnect(conn_hdl, nombre_serv, SQL_NTS, Nombre_usuario. SQL_NTS, Contra_usuario, SQL_NTS);
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.
¡' Programa para aumentar las cuotas en un importe especificado por el usuario ,¡ ¡' archivo de cabecera con linclude las definiciones de la CLl ,¡ main () [
SQLHENV
env_hdl;
SQLHD8C
conn_hdl;
SQLHSTMT
stmt_hdl;
SQLRETURN
status;
char
Figura 19.11.
"nombre serv
"demo" ;
¡' controlador del entorno SQL ,¡ ¡' controlador de la conexión ,¡ ¡, controlador de instrucciones '¡ ¡, estado de retorno de la rutina CLl ,¡ ¡, nombre del servidor '¡
Programa sencillo que emplea SOljClI. (Continú_a.)
1* Pregunta al usuario el importe del incremento o la disminución
de la cuota "1 printf("¿En cuánto se aumenta o disminuye la cuota?: gets(cadena_importe);
");
1'* Monta la instrucción 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 actualización\n~); else printf(~Actualización 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);
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. (Continuación.)
620 2. 3. 4. 5. 6.
SOL. Manual de referencia
Se conecta con un servidor de bases de datos concreto. El programa crea las instrucciones de SQL en sus búferes de memoria. Realiza las llamadas a eL! para solicitar la ejecución de l,!s instrucciones y comprobar su estado. Tras su finalización con éxito hace una llamada a eL! para comprometer la transacción 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 código de estado que indica la finalización con éxilo de la rutina, o algún tipo de error o de advertencia sobre su ejecución. El valor de los códigos de estado de devolución de eLI se resumen en la Tabla 19.3. Algunos de los ejemplos de programas de este Libro omiten la comprobación de los códigos de estado de devolución para abreviar el ejemplo y centrarse en las características concretas que se ilustran. No obstante, los programas de pro~ ducción que llaman a las funciones CLI deben comprobar siempre el valor de devolución para asegurarse de que la función se completó con éxito. Los nombres de las constantes simbólicas de los códigos de estado de devolución y otros muchos valores, como los códigos de tipos de datos y los códigos de identificación de las instrucciones, suelen definirse en archivos de encabezado que se incluyen al comienzo de los programas que utilizan la CL!.
Estructuras
eL/
La CL! gestiona las interacciones entre los programas de aplicación y las bases de datos incorporadas mediante una jerarquía de conceptos, que se refleja en una jerarquía de estructuras de datos de CLL • Entorno de SQL. Entorno de máximo nivel dentro del que tiene lugar el acceso a las bases de datos. La CL! emplea la estructura de datos asociada Tabla 19.3.
Códigos de estado de devolución de CL!
Valor de devolución de. eLI
Significado
o
Instrucción completada con éxito.
1
Finalización con éxito, pero con advertencias.
100
No se han hallado datos (al recuperar el resultado de la consulta).
99
Hacen falta datos (falta un parámetro dinámico necesario).
-1
Error durante la ejecución de la instrucción de SQL.
-2
Error -se ha proporcionado un controlador no válido en la llamada.
Capítulo 19: Las AP/ de SOL
621
con el entorno SQL para realizar un seguimiento de los diferentes programas de aplicación que lo utilizan. • Conexión con SQL. Conexión lógica con un servidor de bases de datos Concreto. Conceptualmente, la CLI permite que se conecte un solo programa de aplicación con varios servidores de bases de datos diferentes de manera simultánea. Cada conexión tiene su propia estructura de datos, que la CLl utiliza para realizar un seguimiento del estado de conexión. • Instrucción SQL. Instrucción de SQL que el servidor de bases de datos debe procesar. La instrucción 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 aplicación. Conceptualmente, el programa de aplicación puede tener varias instrucciones de SQL que se desplacen en paralelo por estas etapas de procesamiento. Cada instrucción tiene su propia estructura de datos, que la CLI utiliza para seguir su progreso. La CLI utiliza una técnica utilizada frecuentemente por los sistemas operativos modernos y los paquetes de bibliotecas para gestionar estas entidades conceptuales. Se asocia un puntero simbólico, denominado controlador. con el entorno global SQL, con una conexión de SQL con un servidor de bases de datos concreto y con la ejecución de una instrucción de SQL. El controlador identifica un área de almacenamieolo gestionada por la propia CL!. En cada llamada CL! se pasa algún tipo de controlador como uno de los parámetros. 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 parámetros de la rutina indica a la CLI el tipo de controlador que hay que asignar. Otro parámetro devuelve el valor del parámetro al programa de aplicación. 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 ejecución dentro del programa o los diferentes programas que se ejecutan de manera simultánea (los procesos) pueden establecer sus propias conexiones con la eLI y mantener sus propios contextos, independientes entre sí. Los controladores también permiten que un solo programa tenga varias conexiones CLI con servidores de bases de datos diferentes, y que se procese en paralelo más de una instrucción de SQL. Cuando ya no se necesita un controlador, la aplicación llama a SQLFreeHandle (> para indicárselo a la CL!. Además de las rutinas de gestión de controladores de propósito general, SQLA110cHandle () y SQLFreeHandle (), la especificación 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 incluyéndose en las implementaciones actuales de üDBC en aras de la compatibilidad con versiones anteriores. No obstante, Microsoft ha indicado que las rutinas generales para gestión de controladores son ahora las funciones ODBC preferidas, y puede que las rutinas específicas se descarten en futuras versiones de üDBC. De cara a una portabilidad máxima entre plataformas es mejor utilizar las rutinas de propósito generaL
622
SOL. Manual de referencia
Capítulo 19: Las AP/ de SaL
623
Entorno SOL /* Asigna un controlador para emplearlo en llamadas posteriores a eL! */
short SQLAllocHandle short HdI Type. long
inHdl,
long "rtnHól)
/* IN: código de tipo entero de controlador .. / 1* IN: controlador de entorno o de conexión */ 1* OUT: controlador devuelto */
/* Libera un controlador asignado anteriormente por
SQLAllocHandle() */ short SQLFreeHandle ( short HdI Type, long
inHdl)
'*
IN: código 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 conexión 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 gestión de controladores de SOl/elL
la
El entorno de SQL es el contexto de nivel superior utilizado por los programas de aplicación 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, según la arquitectura del programa. La CL! permite, en teoría, varias conexiones, incluso con diferentes servidores de bases de datos, desde un mismo entorno de SQL. Puede que la implementación concreta de la CL! para un SGBD concreto no albergue realmente las conexiones múll.iples. Conexiones de SOL
Un programa de aplicación puede establecer dentro de un entorno SQL una o más 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 práctica, las conexiones de SQL suelen ser realmente conexiones de red virtuales con los servidores de bases de datos ubicados en otros sistemas informáticos. No obstante, las conexiones de SQL pueden ser también conexiones lógicas entre el programa y un SGBD ubicado en el mismo sistema informático. La Figura 19.13 muestra las rutinas de CLI que se utilizan para gestionar las conexiones de SQL. Para establecer una conexión, el programa de aplicación 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 conexión. El controlador de conexiones se pasa como parámetro a todas las llamadas de procesamiento de instrucciones para indicar la conexión que se está utilizando. Cuando ya no se necesita la conexión, una llamada a SQLDisconnect () la termina, y otra llamada a SQLFreeHandle () libera al controlador de conexiones asociado en la CL!. Normalmente, los programas de aplicación conocen el nombre del servidor de bases de datos concreto (en términos del estándar, el «servidor de SQL») al que desean tener acceso. En algunas aplicaciones (como las consultas de propósito general o las herramientas de introducción 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 orígenes de datos que pueden especificarse legalmente corno nombres de servidor en las llamadas SQLConnect ()-. Para obtener la lista de nombres de los servidores, la aplicación llama repetidamente a SQLDataSources (). Cada llamada devuelve la descripción de un solo servidor, hasta que devuelve un mensaje de error que indica que no quedan más datos. Se puede utilizar de manera opcional un parámetro de la llamada para modificar esta recuperación secuencial de nombres de servidores.
624
Capítulo 19: Las API de SOL
SOL. Manual de referencia
/* Inicia una conexión con un servidor de SOL */ short SQLConnect( /* IN: controlador de la conexión */ 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, conexión */ short usrnamlen, /* IN: longitud del nombre de usuario */ /. IN: contraseña de la conexión */ char *passwd, short pswlenJ /* IN: longitud de la conexión */
/* Se desconecta del servidor de SOL ./ short SQLDisconnect( long connHdl) /* IN: controlador de la conexión
*'
/* Obtiene el nombre de los servidores de SQL con los que es posible conectarse */
short SQLDataSources long
envHdl,
short direction,
¡" IN: controlador del entorno "¡ ¡" IN: indica la primera solicitud o la siguiente */
char *svrname , short buflen, short *namlen, char *descrip, short buf21en, short *dsclen)
Figura 19.13.
¡" OUT: búfer para el nombre del servidor "¡ ¡" IN: longitud del búfer para el nombre del servidor "¡ ¡" OUT: longitud real del nombre del servidor "¡ ¡" OUT: búfer para la descripción */ ¡" IN: longitud del búfer de la descripción "¡ ¡" OUT: longitud real de la descripción "¡
Rutinas de gestión de conexiones de SOL/CL!.
Procesamiento de instrucciones eLI La eLI procesa las instrucciones de SQL empleando una técnica muy parecida a la
descrita para SQL dinámico incorporado en el Capítulo 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 básicas de procesamiento de instrucciones de SQL. Los programas de aplicación deben llamar primero a SQLAllocHandle ( ) para obtener un controlador de instrucciones, que identifica la instrucción ante el programa y la eLI. Todas las llamadas posteriores a SQLExecDirect ( ), SQLPrepare ( )
625
/* Ejecuta directamente una instrucción de SQL */ short SQLExecDirect ( long stmtHdl, /* IN: controlador de instrucciones ~/ char *stmttext, /* IN: texto de la instrucción de SQL */ /* IN: longitud del texto de la short textlen) instrucción */ /* Prepara una instrucción de SQL ~/ short SQLPrepare ( long stmtHdl, /* IN: controlador de instrucciones */ /* IN: texto de la instrucción de SQL */ char *stmttext, /* IN: longitud del texto de la short textlen) instrucción ~/ /* Ejecuta una instrucción de SQL preparada con anterioridad */ short SQLExecute ( long stmtHdl) /* IN: controlador de instrucciones */ /* Enlaza el parámetro de una instrucción de SQL con el área de datos del programa */ short SQLBindParam ( long stmtHdl, /* IN: controlador de instrucciones */ short parmnr, /* IN: número del parámetro (1,2,3 ... l */ short val type, /* IN: tipo de datos del valor proporcionado */ /IN: tipo de datos del parámetro */ parmtype, short /* IN: tamaño de la columna */ short colsize, /* IN: número de cifras decimales */ short decdigits, /* IN: puntero al búfer de valores de los void *value, parámetros */ /* IN: puntero al búfer de longitudes o long *lenind) indicadores */ /* Obtiene la etiqueta del parámetro para el siguiente parámetro dinámico necesario */ short SQLParamData ( ./* IN: controlador de instrucciones con long stmtHdl, parámetros dinámicos */ /* OUT: valor devuelto de la etiqueta del void *prmtag) parámetro */ /* Obtiene información detallada sobre un elemento descrito por un descriptor de la eLI */ short SQLPutData ( /* IN: controlador de instrucciones con long stmtHdl, parámetros dinámicos */ /* IN: búfer con datos para los void *prmdata, parámetros */ /* IN: longitud del parámetro o indicador short prmlenind) de valores NULL */
Figura 19.14.
Rutinas de procesamiento de instrucciones de CLI.
626
SOL. Manual de referencia
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 ejecución en un solo paso, el programa de aplicación llama a SQLExecDirect () de SQL y le pasa a la llamada el texto de la instrucción de SQL como uno de los parámetros. El SGBD procesa la instrucción como consecuencia de la llamada y devuelve el estado de finalización de la instrucción. Este proceso de una sola etapa se utilizaba en el programa sencillo de ejemplo de la Figura 19.11. Se corresponde con la instrucción de una etapa EXECUTE IMMEDIATE de SQL dinámico incorporado, que se describe en el Capítulo 18. Para la ejecución en dos etapas, el programa de aplicación llama a SQLPrepare () y le pasa el texto de la instrucción de SQL a la llamada como uno de los parámetros. El SGBD analiza la instrucción, determina la manera de ejecutarla y conserva esa información. No ejecuta la instrucción de manera inmediata. En vez de eso, las llamadas posteriores a la rutina SQLExecu te () hacen que la instrucción se ejecute realmente. Este proceso de dos etapas se corresponde exactamente con las instrucciones PREPARE y EXECUTE de SQL dinámico incorporado, descritos ·en el Capítulo 18. Conviene utilizarlo siempre para cualquier operación ·de SQL que haya que ejecutar de manera repetida, ya que hace que el SGBD sólo pase una vez por la sobrec~ga del análisis de las instrucciones y la optimización, en respuesta a la llamada SQLPrepare ( ). Se pueden pasar los parámetros mediante la CLI para personalizar la operación de las llamadas a SQLExecu te () que siguen.
Ejecución de instrucciones con parámetros
l'
En muchos casos la instrucción de SQL debe ejecutarse de manera repetida sólo con cambios en algunos de los valores que especifica. Por ejemplo, la instrucción INSERT que añade un pedido a la base de datos de ejemplo es idéntica para cada pedido, salvo por la información específica sobre el número de cliente, el producto y el fabricante y la cantidad encargada. Como se describió en el Capítulo 18, para SQL dinámico incorporado esas instrucciones pueden procesarse de manera eficiente especificando las partes variables de la instrucción como parámetros de entrada. El texto de la instrucción pasado a la llamada a SQLPrepare () tiene un marcador de parámetro -un signo de interrogación (?)- en el texto en cada posición en la que hay que insertar el valor de un parámetro. Cuando la instrucción se ejecute más adelante, habrá que proporcionar valores para cada uno de los parámetros de entrada. La manera más sencilla de proporcionar los valores de los parámetros de entrada es utilizar la llamada a SQLBindPararn (). Cada llamada a SQLBindPararn () establece un enlace entre uno de los marcadores de parámetro de la instrucción de SQL (identificado por su número) y una variable del programa de aplicación (identificada por su dirección de memoria). Además, se establece opcionalmente una asociación con una segunda variable del programa de aplicación (un entero) que proporciona la longitud de los parámetros de longitud variable. Si el parámetro 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 código, definido en el archivo de encabezados como la constante simbólica SQL_NTS, para indicar que
Capítulo 19: Las API de SOL
627
la longitud de la cadena de caracteres pueden obtenerla las rutinas de la eLI de los propios datos. De manera parecida, se utiliza un código negativo para indicar un valor NULL de los parámetros de entrada. Si en la instrucción hay tres marcadores de parámetro de entrada, habrá tres llamadas a SQLBindPararn ( ), una por cada parámetro. Una vez establecida la relación entre las variables del programa de aplicación (más exactamente, ubicaciones de almacenamiento del programa) y los parámetros de la instrucción, se puede ejecutar la instrucción real con una llamada a SQLExecute ( ). Para modificar los valores de los parámetros para instrucciones posteriores sólo hace falta colocar valores nuevos en las áreas de búferes del programa de aplicación antes de la siguiente llamada a SQLExecu te ( ). De manera alternativa, se pueden volver a enlazar los parámetros con diferentes áreas de datos del programa de aplicación mediante llamadas posteriores a SQLBindParam( l. La Figura 19.15 muestra un programa que incluye una instrucción de SQL con dos parámetros de entrada. El programa pide repetidamente al usuario un número de cliente y un nuevo límite de crédito para ese cliente. Los valores proporcionados por el usuario se transforman en los parámetros de entrada de una instrucción UPDATE de la tabla CLIENTES.
/* Programa para elevar el límite de crédito de los clientes especificados por el usuario */ /* archivo de encabezados iinclude con definiciones de CLI */ main( ) (
controlador del entorno de SQL * / controlador de la conexión */ controlador de instrucciones */ estado de devolución de la rutina CLI */ nombre del servidor */ nombre de usuario para la conexión */ contras efta del usuario para la conexión */ importe introducido por el usuario */ indicador del importe (cadena de caracteres acabada en NULL) */ número de cliente introducido por el usuario * /
Programa de eL! que utiliza parámetros de entrada. (Continúa.)
628
SOL. Manual de referencia
iot
cust
char
buf_instru(128J:
~nd
SQL_NTS;
1\
Capitulo 19: Las API de SOL
I~
indicador de cliente (cadena de caracteres acabada en NULL) */ /* búfer para la instrucción de SQL */
Asigna controladores para el entorno de SQL, la conexión y la instrucción */ 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);
629
I * Ejecuta la instrucción con los parámetros */ status = SQLExecute(strnt_hdll; if (status) printf("Error durante la actualización\n"); else printf("Modificaci6n del límite de crédito concluida con éxito.\n"):
/*
Figura 19.15.
* Enlaza los parámetros con los búferes del programa */ SQLBindParamlstmt_hdl,1,SQL_C_CHAR.SQL_DEClMAL.9.2.&buf_importe. &amt_ind);
* Itera para procesar cada modificación del límite de crédito */ for ( ; ) (
1"
!I
/* Pide al usuario el cliente y el nuevo limite de crédito */ printf (" Introduzca el número de cliente; -); gets (buf_clil ; if (strlen(buf_cli) ::~ O) break; printf{"Introduzca el nuevo límite de crédito; -); gets(buf_importe);
1,
Figura 19.15.
l'
SQL_COMMIT);
/* Prepara una instrucción UPOATE con marcadores de parámetro */ strcpy(buf_instru, ·update clientes set limite_credito :: ? -); strcat (buf_instru, "where num_cli :: ?-l; SQLPrepare{stmt_hdl, stmt_buf, SQL_NTSl;
/
1'1
env_hdl,
/ * 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();
1,
I
SQLEndTran(SQL_HANDLE_ENV,
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}; /*
'r 1
/* Compromete la actualización */
Programa de eL! que utiliza parámetros de entrada. (Continuación)
Program~
sale */
de eL! que utiliza parám·etros de entrada. (Continuación.)
Las llamadas a SQLParamData () ya SQLPutData () de la Figura 19.15 proporcionan un método alternativo para pasar parámetros en el momento de la ejecución, denominado paso diferido de parámetros. La selección de esta técnica para un parámetro concreto de la instrucción se indica en la llamada correspondiente a SQLBindParam (). En lugar de proporcionar realmente una ubicación de datos del programa a la que esté ligado el parámetro, la llamada a SQLBindParam () indica que se utilizará el paso diferido de parámetros y proporciona un valor que se utilizará más tarde para identificar al parámetro concreto que se procesa de esta manera. Una vez solicitada la ejecución de la instrucción (mediante una llamada a SQLExecute () O a SQLExecDirect (», el programa llama a SQLParamOata () para determinar si la instrucción necesita datos de parámetros diferidos. En caso afIrmativo, la eLI devuelve un código de estado (SQL_NEED_DATA) junto con un indicador del parámetro que necesita valores. El programa llama entonces a SQLPutData () para proporcionar realmente el valor del parámetro. Generalmente, el programa llama entonces nuevamente a SQLParamDa ta () para determinar si algún otro parámetro necesita datos dinámicos. El ciclo se repite hasta que se hayan proporcionado todos los datos dinámicos necesarios. y la ejecución de la instrucción de SQL continúa entonces normalmente. Este método alternativo de paso de parámetros es considerablemente más complejo que el sencillo proceso de enlace de los parámetros con las ubicaciones del programa de aplicación. Tiene dos ventajas. La primera es que el paso real de Jos valores de los datos (y la asignación de almacenamiento para contenerlos) puede
630
SQL. Manual de referencia
retrasarse hasta el último momento, cuando los datos se necesiten realmente. La segunda ventaja es que la técnica puede utilizarse para pasar valores de parámetros muy largos trozo a trozo. Para los tipos de datos largos escogidos la eLI permite llamadas repetidas a SQLPutData (l para el mismo parámetro, donde cada llamada pasa la siguiente parte de los datos. Por ejemplo, el texto de un documento que se proporcione como parámetro para la cláusula VALUES de una instrucción 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 búfer de memoria de tamaño muy grande dentro del programa de aplicación para guardar todo el valor del parámetro.
Capítulo 19: Las API de SOL
631
-el apartado anterior. Si el programa determina que debe cancelar la ejecución de la instrucción en lugar de proporcionar un valor para el parámetro diferido, puede llamar a SQLCancel () para lograr ese resultado. La llamada a SQLCancel () también puede utilizarse en aplicaciones multihebra para cancelar el efecto de una llamada a SQLExecu te () Oa SQLExecDirect ( ) que no se haya completado todavía. En esta situación, la hebra que realiza la llamada original para la ejecuci6n seguirá esperando que se complete la' llamada, pero las demás hebras que se ejecuten de manera simultánea pueden llamar a SQLCancel () empleando el mismo controlador de instrucciones. Los detalles de esta técnica y el grado de interrupción de las llamadas CLI suelen depender mucho de la implementación.
Gestión de transacciones con CL/ Las funciones COMMIT y ROLLBACK para el procesamiento de las transacciones de SQL se aplican también a la operativa de SQL mediante la CL!. No obstante, como la propia CLl debe tener conocimiento de que se está completando una transacción, 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 operación concreta que se va a Bevar a cabo se especifica mediante el parámetro de tipo de finalización de la llamada. La llamada CL! a SQLCancel (l. que también puede verse en la Figura 19.16 no proporciona realmente una función de gestión de transacciones, pero, en la práctica, se utiliza casi siempre junto con las operaciones ROLLBACK. Se emplea para cancelar la ejecución de una instrucción de SQL que inició anteriormente una llamada a SQLExecDirect () o a SQLExecute (). Esto resulta adecuado en programas que utilizan el procesamiento diferido de parámetros, como se ha descrito en
/- Compromete (COMMIT) o hace retroceder (ROLLBACK) una transacción de SQL -/ short SQLEndTran ( /~ IN: tipo de controlador -/ short hdltype, /. IN: controlador de entorno, de long txnHdl, conexiones o de instrucciones ./ /. IN: tipo de transacción (COMMIT/ short compltype) ROLLBACK) ./
/- cancela una instrucción de SQL que se esté ejecutando -/ short SQLCancel ( short stmtHdll 1- IN: controlador de instrucciones -/
Procesamiento de resultados de consultas con CL/ Las rutinas CLl descritas hasta ahora pueden utilizarse para procesar instrucciones de definición de datos de SQL o instrucciones de manipulación 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 más 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 aplicación recorre las etapas siguientes (suponiendo que ya se ha establecido conexión): 1.
2. 3.
El programa asigna un controlador de instrucciones empleando SQLAllocHandle (). El programa lláma a SQLPrepare () y le pasa el texto de la instrucción SELECT de SQL para la consulta. El programa llama a SQLExecute () para que realice la consulta.
/. 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: número 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 búfer del programa -/ long lenind) /- IN: puntero al búfer de longitudes e indicadores -/
Figura 19.17. Figura 19.16.·
Rutinas de gestión de transacciones de CLI.
Rutinas de procesamiento de los resultados de las consulta de CLI. (ConUnúa.)
632
SOL. Manual de referencia
Capitulo 19: Las API de SOL
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.
short
fetchdir,
long
offset}
6.
/* IN: controlador de instrucciones */ /* IN: dirección (primera/siguientel anterior) .. I / .. IN: resul cado (número de filas) .. I
7.
·value.
long
buflen,
long
*lenind)
/* IN: puntero al búfer de datos de la columna */ /* IN: longitud del búfer del programa */ /* OUT: longitud real o indicador de valores NULL * /
/* Programa para mostrar un informe de los representantes Que han superado su cuota */ iinclude /~ archivo de encabezados con las definiciones CLI ~/ main ()
/* Cierra un cursor para concluir e~ acceso a los resultados de la consulta */ short SQLCloseCursor long stmtHdl) /* IN: controlador de instrucciones */
(
/* Establece un nombre de cursor para un cursor abierto */ short SQLSetCursorName 1
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: búfer para el nombre devuelto */ short huflen, /* IN: longitud del búfer */ short *namlen) /* OUT: longitud real del nombre devuelto */
Figura 19.17.
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 búferes 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 recién capturada se coloca en el búfer 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 más 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.
El fragmento de programa de la Figura 19.18 muestra una consulta sencilla ejecutada empleando esta técnica. El programa es idéntico 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 parámetros son- bastante diferentes, pero el flujo de los programas y la secuencia 16gica de las llamadas que realizan son idénticos.
/* Obtiene los datos de una sola columna de resultados de la consulta */ short SQLGetData ( long s tmtHdl, /* IN: controlador de instrucciones */ /* IN: número de la columna que hay que short color, recuperar */ /* IN: tipo de datos que hay que devolver short tgttype, al programa */
void
633
Rutinas de procesamiento de los resultados de las consulta de ell. (Continuación.)
1- controlador del entorno SQL *1 1- controlador de conexiones */ 1- controlador de instrucciones *1 1- estado de devolución de la rutina CLI */ 1* nombre del servidor */ /* nombre de usuario para la conexión */ 1* contraseBa del usuario para la conexión *1 1* nombre del representante, recuperado *1 1* cuota, recuperado */ /* ventas, recuperado */
Recuperación de los resultados de la consulta con
ell. (Continúa.)
634
Capítulo 19: Las API de SOL
SOL. Manual de referencia
short
repquota_ind;
char
buf_instrul128l;
¡, indicador de valor NULL en la cuota ,¡ ¡' búfer para la instrucción de SQL '¡
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
I~ Solicita la ejecución 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 búferes del programa ·1 SQLBindCol (stmt_hdl,l,SQL_C_CHAR,nombrerep, lS.NULL); SQLBindCol (stmt_hdl.2,SQL_C_FLOAT,&cuotarep, O,"a_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 () ;
Figura 19.18.
Recuperación de los resultados de la consulta con
eLl. (Continuación.)
635
Cada llamada a SQLBindCol () establece una asociación entre una columna de resultados de la consulta (identificada por su número de columna) y un búfer del programa de aplicación (identificado por su dirección). 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 búferes del programa. En el momento adecuado se especifica una segunda área de datos del programa como búfer 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 devolución 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 también pueden utilizarse para implementar un método alternativo de procesamiento de los resultados de la consulta. En esta técnica las columnas de resultados de la consulta no se enlazan de antemano con ubicaciones del programa de aplicación. En vez de eso, cada llamada a SQLFetch () sólo 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 anfitrión. En su lugar se realiza una llamada a SQLGetData () para que recupere realmente los datos. Uno de los parámetros de SQLGetData () especifica la columna de resultados de la consulta que hay que recuperar. Los demás parámetros especifican el tipo de datos que hay que recuperar y la ubicación del búfer que debe recibir los datos y el valor de la variable indicadora asociada. En el nivel básico la llamada a SQLGetData () es simplemente una alternativa al enfoque de enlace de las variables del anfitrión proporcionado por SQLBindCol (), pero SQLGetData () proporciona una ventaja importante al procesar elementos de datos de tamaño 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 práctico asignar un búfer del programa para que albergue todos los datos de esas columnas. Con el empleo de SQLGetData () el programa puede asignar un búfer de tamaño 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 instrucción. 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 explícita a SQLGetDa ta () para procesar las demás columnas. Esta técnica puede resultar especialmente adecuada si una consulta recupera varias columnas de datos típicos de SQL (nombres, fechas, cantidades de dinero) y una o dos columnas de datos largos, como el texto de un contrato. Obsérvese 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 ().
636
SOL. Manual de referencia
Capítulo 19: Las API de SOL
.637
Cursores de desplazamiento
Procesamiento de consultas dinámicas con CL!
El estándar 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 estándar SQLZ para SQL incorporado. La llamada a SQLFetchScroll (l. que puede verse en la Figura 19.17, proporciona las fun-
Si las columnas que tiene que recuperar la consulta de SQL no se conocen con antelación cuando se desarrolla el programa, éste puede utilizar las llamadas de procesamiento de consultas de la Figura 19.19 para determinar las características de los resultados de la consulta en el mamen lO de la ejecución. Estas llamadas implementan el mismo tipo de posibilidad de procesamiento de consultas de SQL dinámico incorporado del Capítulo 18. A continuación pueden verse las etapas para el procesamiento dinámico de las consultas empleando CL!:
ciones ampliadas FETCH necesarias para la recuperación hacia delante y hacia atrás y aleatoria de los resultados de las consultas. Uno de sus parámetros especifica el controlador de instrucciones de la consulta, igual que para la llamada SQLFetch () sencilla. Los otros dos parámetros especifican la dirección del movimiento de FETCH (PREVIDUS, NEXT, etcétera) y el resultado de los movimientos de FETCH que 10 necesitan (recuperación de las filas aleatoria absoluta y relativa). La operativa de SQLBindCol () y de SQLGetData () para el procesamiento de los valores devueltos es idéntica a la descrita para la llamada a
l.
El programa asigna un controlador de instrucciones empleando SQLAllocHandle ().
SQLFet.ch ().
Cursores con nombre Obsérvese que la CL] no incluye una llamada explícita a la declaración del cursor para igualar la instrucción DECLARE CURSOR de SQL incorporado. En lugar de eso, el texto de las consultas de SQL (es decir, una instrucción SELECT) se pasa a la eL! para su ejecución del mismo modo que cualquier otra instrucción 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 Capítulo 17, se puede utilizar una instrucción UPDATE posicionada o una instrucción DELETE (UPDATE ... WHERE CURRENT OF o DELETE ... WHERE CURRENT OF) para modificar o eliminar la fila en curso (es decir, recién 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 aplicación puede tener abierto más de un cursor a la vez para procesar más 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 parámetros, 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 ejecución 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 número de columnas de resultados de la columna -/ short SQLNumResultCols ( long stmtHdl, 1* IN: controlador de instrucciones */ short *colcount) 1* OUT: número de columnas devuelto */ /* Determina las características de una columna de resultados de la consulta */ short SQLDescribeCol long stmtHdl, 1* IN: controlador de instrucciones *1 short. numcol, /* IN: número 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 búfer del nombre de la columna */ short *lonnoro, 1* OUT: longitud real del nombre de la columna */ short *tipocol, /* OUT: código de tipo de datos de la columna devuelta */ short *tamacol, /* OUT: longitud de los datos de la columna devuelta *1 short *cifrasdec, /* OUT: número devuelto de cifras de la columna */ short *nullable) /* OUT: indica si la columna puede tener valores NULL */ /* Obtiene información detallada sobre una columna de resultados de la columna *1 short SQLColAttribute long stmtHdl, /* IN: controlador de instrucciones */ short numcol, /* IN: nÚmero de la columna que hay que describir *1 short codiatri, /* IN: código del atributo que hay que recuperar *1
Figura 19.19.
Llamadas eLl para el procesamiento dinámico de consultas. (Continúa.)
638
SOL. Manual de referencia
char
short
~infoatri.
lonbu f,
short *lonreal, iot
*atrinum)
Capítulo 19: Las API de SOL
short
/* OUT:
búfer para la información de los atributos de la cadena de caracteres ... / /* IN: longitud del búfer de atributos de la columna */ /* OUT: longitud real de la información de los atributos */ /* OUT: información entera devuelta de los atributos */
void
short
subtipo,
short short
longitud, precis,
Figura 19.1~.
lonbuf,
short
""bufind)
,.
CLI ""/
tipodatos,
short
/* Define el valor de un elemento descrito por un descriptor CL! */ short SQLSetDescField long descHdl. controlador de /' IN: descriptores -/ short numreg, /- IN: número del registro del descriptor -/ short codiatri, /- IN: código del atributo que se va a describir ' / void ""infoatri, /- IN: búfer con el valor del atributo -/ short lonbuf) /- IN: longitud de información sobre los atributos ' /
/* Define la información utilizada frecuentemente en un descriptor
short
*bufdatos,
/* IN: escala del elemento, si es numérico '"/ /* IN: dirección del búfer de datos del elemento */ /'" IN: longitud del búfer de datos *( /'" IN: dirección del búfer de indicadores del elemento '"/
/* Obtiene información detallada sobre un elemento descrito por un descriptor CLI */ short SQLGetDescField long descHdl. /'" IN: controlador de descriptores ""/ short numreg, /* IN: número del registro del descriptor ""/ short codiatri, /'" IN: código del atributo que hay que describir ""/ void ""infoatri, /* IN: búfer para la información sobre los atributos */ short lonbuf, /* IN: longitud de la información sobre los atributos */ short ""lonreal) /* OUT: longitud real de la información devuelta '"/
/* Recupera la información utilizada frecuentemente de un descriptor eL! ,o/ short SQLGetDescRec long descHdl, controlador de descriptores ' / / ' IN: short numreg. número del registro del / ' IN: descriptor ,/ char ,. nombre. / ' OUT: nombre del elemento que se está describiendo ' / short lonbuf, longitud del búfer de /' IN: nombres -/ short *lonnom, /- OUT: longitud real del nombre devuelto ' / short *tipodatos, /- OUT: código del tipo de datos del elemento -/ short *subtipo, /' OUT: subcódigo del tipo de datos del elemento ' / short *longitud, /- OUT: longitud del elemento -/ /- OUT: precisión del elemento, si es short *precis, numérico -/ short ""escala, /- OUT: escala del elemento, si es numérico -¡ short ""nullablel /- OUT: indica si el elemento puede tener valores NULL -/
short SQLSetDescRec long descHdl, short numreg,
escala,
639
/- IN: controlador de descriptores -/ /- IN: descriptor del número de .c~ registro -/ /- IN: código del tipo de datos del elemento -/ /- IN: subc6digo del tipo de datos del elemento -/ /- IN: longitud del elemento -/ /- IN: precisión del elemento, si es numérico ' /
/"" 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 -/
-
Llamadas CL! para el procesamiento dinámico de consultas. (Continuación.)
Figura 19.19.
1
Llamadas CLI para el procesamiento dinámico de consultas. (Continuación.)
640 2. 3. 4. 5.
6. 7.
8.
9.
SaL. Manual de referencia
El programa llama a Prepare () para que pase el texto de la instrucción SELECT de la consulta. El programa llama a SQLExecute () para que ejecute la consulta. El programa llama a SQLNurnResultCols () para que determine el número 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 tamaño, 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 aplicación, 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 más 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.
La Figura 19.20 muestra un programa que utiliza estas técnicas para procesar una consulta dinámica. El programa es idéntico en su concepto y propósito al programa de consultas de SQL dinámico incorporado de la Figura 18.9 y al programa de consultas de SQL dinámico basado en dblib de la Figura 19.10. Una vez más, resulta instructivo comparar los ejemplos de programas para mejorar la comprensión del procesamiento dinámico 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 idénticas. La secuencia de llamadas a dbcmd () I dbsqlexec () I dbresults (l se sustituye por SQLExecDirect (). (En este caso, la consulta sólo 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 demás 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 dinámico 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 descripción 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
Capítulo 19: Las API de SOL
641
main () (
/* Se trata de un programa sencillo de consultas de propósito
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
env_hdl;
/*
SQLHDEC
conn_hdl;
/*
SQLHSTMT
stmtl_hdl;
/*
SQLHSTMT
stmt2_hdl;
/*
SQLRETURN
status;
f"
char
·nombre_servidor = "demo" ;
f"
char
·nombre_usuario = "jose";
f"
char
*contra_usuario = "xyz" ;
f"
char
bufinstru(2001];
f"
char
hufinstru2[2001];
f"
char
tablacon(32);
f"
char
columcon[32] ;
f"
int
pri_col = O;
f"
short
cuentacol;
f"
*punnombre;
f"
char
Figura 19.20.
Empleo de
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 devolución de la rutina eL! */ nombre del servidor */ nombre de usuario para la conexión */ contraseBa del usuario para la conexión */ 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 */ número de columnas del resultado de la consulta */ dirección para que eL! devuelva el nombre de la columna */
eL! para consultas dinamicas. (Continúa.)
642
SOL. Manual de referencia
Capítulo 19: Las API de SaL
short
lonnombre;
"
short
tipo;
short
tama;
" "
short
cifras;
"
short
nullable;
short
i,
char
bufen(lOl] ;
" " " "
char
-nombre_elemllOO];
char
*datos_elem{lOO};
"
ioe
indi_elem[lOOl;
short
tipo_elemllOOl;
"
char
"'pundatos;
"
"
longitud del nombre de la columna devuelto por eL! " código eL! para el tipo de datos de la columna " tamaño de la columna devuelto por eL! " número 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 búferes de las columnas " array de variables indicadoras " array para seguir los tipos de datos de las columnas " dirección del búfer para la columna actual "
'" Abre una conexión con la base de datos de demostración 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};
/* 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 instrucción SELECT en el búfer */
Figura 19.20.
. Empleo de eL! para consultas dinámicas. (Continuación.)
strcpy(bufinstru,
"select
643
"J;
/* Consulta al esquema de la información 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 añadirla a la lista de selección */ if (first_col++ > O) strcat (bufinstru, ", "); strcat(bufinstru, colurncon);
/* Concluye la instrucción SELECT con una cláusula FROM */ strcat(bufinstru, "froro "}; strcat (bufinstru, tablaconJ;
/. 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)
case SQL_CHAR: case SQL_VARCHAR: /* Asigna el búfer para la cadena de caracteres y le enlaza la columna ./ datos_elern(il : pundatos ~ malloc(size+l);
Figura 19.20.
Empleo de eLl para consultas dinamicas. (Continuación.)
644
SOL Manual de referencia
tipo_elem{i] : SQL_C_CHAR; SQLBindCol(strntl_hdl. i, SQL_e_CHAR, indptr}; break;
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:
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 precisión 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 dinámicas. (Continuación.)
1* Maneja cada tipo de datos devuelto (acaso convertido) por
Figura 19.20.
Empleo de
eL!
para consultas dinámicas. (Continuación.)
646
SOL. Manual de referencia
Capítulo 19: Las API de SOL
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");
/* Limpia el almacenamiento asignado */ (i '" O; i < cuentacol; i++ I {
ran atributos de esa instrucción 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 gestión de atributos, que se describen más adelante en el apartado «Atributos de Cll». Se utilizan dos llamadas para recuperar la información de los descriptores, dado su controlador. La llamada a SQLGetDescField (l recupera un campo concreto del descriptor, que se identifica mediante un valor del código. 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 información en una sola llamada, incluidos el nombre de la columna o del parámetro, el tipo y el subtipo de datos, su longitud, su precisión y su escala, y si pueden contener valores NULL. Se utiliza el conjunto de llamadas correspondiente para colocar la información en un descriptor. La llamada a SQLSetDescField () define el valor de un solo fragmento de información 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 precisión 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.
conn_hdl); env_hdll;
Errores e información de diagnóstico en eL/ exit () ;
Figura 19.20.
Empleo de
eL! para consultas dinámicas. (Continuación.)
eLI más sencilla de utilizar y de comprender. No obstante, la eLI proporciona un método alternativo de nivel inferior que ofrece posibilidades como las proporcionadas por la SQLDA incorporada. El método eLI alternativo para el procesamiento dinámico de las consultas implica a los descriptores CL!. Los descriptores CLI contienen información de bajo nivel sobre los parámetros de una instrucción (los descriptores de los parámetros) o las columnas de resultados de las consultas (los descriptores de las filas): La información del descriptor es igual que la contenida en el área de variables de la SQLDA -el nombre del parámetro o de la columna, el tipo y subtipo de los datos, su longitud, la ubicación del búfer de datos, la ubicación del indicador de valores NULL, etc. Los descriptores de los parámetros 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 dinámico incorporado. Los descriptores eLI se identifican mediante los controladores de descriptores. La CLI proporciona un conjunto predeterminado de descriptores para parámetros 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 instrucción se conside-
Cada función CLI devuelve el valor de un entero corto que indica su estado de finalización. Si el estado de finalización indica un error, se pueden utilizar las llamadas eLI de manejo de errores, mostradas en la Figura 19.21, para obtener más información sobre el error y diagnosticarlo. La llamada de manejo de errores más básica es SQLError ( ) . El programa de aplicación pasa Jos controladores de entorno, de conexión y de instrucciones y se devuelve en código de resultado de SQL2 SQLSTATE, el código de error nativo del subsistema que produce el error, y un mensaje en forma de texto.
/* Recupera la información 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: código de error nativo devuelto "¡ ¡" OUT: búfer para el texto del mensaje char *bufmensa. de error "¡
Figura 19.21.
Rutinas
eu de manejo de errores.
(Continúa.)
648
Capítulo 19: Las API de SOL
SOL. Manual de referencia
La rutina SQLError () recupera realmente información concreta utilizada frecuentemente del área de diagnóstico de la CLl. Las otras rutinas de manejo de errores proporcionan información más completa mediante el acceso directo a los registros de diagnóstico creados y mantenidos por la CL!. En general, las llamadas CLI pueden producir varios errores, que dan lugar a varios registros de diagnóstico. La llamada SQLGetDiagRec () recupera un solo registro de diagnostico a partir de su número de registro. Mediante llamadas repetidas el programa de aplicación puede recuperar la información completa sobre lodos los registros de error producidos por una llamada CL!. Se puede incluso obtener información más completa interrogando los campos de diagnóstico del registro. Esta posibilidad la proporciona la llamada SQLGeCDiagField (). Aunque no estrictamente una función de procesamiento de errores, se llama a la función SQLRowCount (), como a las funciones de manejo de errores, después de una llamada CLI anterior a SQLExecute (). Se utiliza para determinar el im~ pacto de la instrucción previa cuando ha tenido éxito. El valor devuelto indica el número de filas de datos afectadas por la instrucción ejecutada previamente. (Por ejemplo, se devuelve el valor 4 para una instrucción UPDATE de búsqueda que ac· tualice cuatro filas).
IN: longitud del búfer del texto del mensaje de error */ /* OUT: longitud real del mensaje devuelto */ /*
short lonbuf,
short ·lonmensal
Determina el número de filas afectadas por la instrucción SQL anterior */ short SQLRowCount ( /* IN: controlador de long stmtHdl. instrucciones */ 1* OUT: número de filas long ·cuentafila) /*
*'
1* Recupera la información de uno de los registros de diagnóstico de errores de la eL! short SQLGetDiagRec ( short hdltype, long
ioRdl,
short
numreg.
*'
char
*estadosql,
long
*errornativo,
char
*bufmensa,
short
lonbuf.
short *lonmensa}
" "
" " " " " "
código del t.ipo de IN: cont.rolador */ controlador eLI " IN: número de registro del error IN: solicit.ado " OUT: código SQLSTATE devuelto de cinco caracteres " OUT: código de error nat.ivo devuelt.o */ OUT: búfer para el t.ext.o del mensaje de error " longitud del búfer del texto del IN: mensaje de error " OUT: longitud real del mensaje devuelto */
Atributos de
'*
Recupera un campo de uno de los registros de diagnóstico de errores de la eL! */ short SQLGetDiagField /* IN: código del tipo de short hdl type. controlador */ /* IN: controlador eLI * / long ioRdl, /* IN: número de registro del error short nurnreg I solicitado */ /* IN: Identificador del campo de short iddiag, diagnóstico */ /* OUT: información de diagnóstico void *infodiag, devuelta */ /* IN: longitud del búfer de short lonbuf, información de diagnóstico */ /* OUT: longitud real de la información short *lonreall devuelta */
Figura 19.21.'
Rutinas eL! de manejo de errores. (Continuación.)
649
.,
eL/
La CLI proporciona varias opciones que controlan algunos detalles del procesamiento. Algunas de ellas controlan detalles relativamente menores pero críticos, como si la eLI debiera dar por supuesto de manera automática que los parámetros pasados como valores de cadenas de caracteres terminan en valores NULL. Otras controlan aspectos más amplios de la operativa de la CLI, como la posibilidad de desplazamiento de los cursores. La CLI concede a los programas de aplicación la posibilidad de controlar estas opciones de procesamiento mediante un conjunto de atributos CL!. Los atributos se estructuran en una jerarquía, igual que la jerarquía entorno/conexión! instrucciones de la estructura de controladores de la eL!. Los atributos de entorno controlan las opciones operativas globales. Las opciones de conexión se aplican a cada conexión concreta creada por la llamada SQLConnect {>, pero pueden variar de una conexión a otra. Los atributos de instrucciones se aplican al procesamiento de cada instrucción, identificada mediante un controlador CLI de instrucciones. Los programas de aplicación 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 código. Aunque el estándar eLI proporciona esta compleja estructura de atributos, realmente especifica relativamente pocos atributos. El único atributo de entorno espe-
a
650
Capítulo 19: Las API de SOL
SOL. Manual de referencia
/* Obtiene el valor de un atributo del entorno SQL short SQLGetEnvAttr{
long
envHdl.
long
codiatri,
void long
*valdevu. lonbuf.
long
"'¡oocade)
/* /* /* /*
IN:
*'
controlador del entorno "/
IN: código entero del atributo */ OUT: valor devuelto */ IN:
longitud del búfer de
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 */ código entero del atributo "'/ nuevo valor del atributo "'/ longitud de los datos "'/
1* Obtiene el valor del atributo de una conexión SQL */ short SQLGetConneccAttr( controlador de conexiones */ /* IN: long connHdl. código entero del atributo */ /* IN: long codiatri, /* OUT: valor devuelto */ void ·valdevu, longitud del búfer valdevu "'/ 1* IN: long lonbuf, 1* OUT: longitud de los datos reales */ long *loocade)
/* Define el valor del atributo short SQLSetConnectAttrl /* long connHdl. /'" long codiatri. /* void "'valatri. /* long *loncade}
de una conexión de SQL */ IN: IN: IN: IN:
controlador de conexiones */ código entero del atributo */ nuevo valor del atributo */ longitud de los datos */
/* Obtiene el valor del atributo de una instrucción de SQL */ short SQLGetStmtAttr ( controlador de instrucciones IN: long stmtHdl. código entero del atributo IN: long codiatri. OUT: valor devuelto void *valdevu. longitud del búfer de IN: long lonbuf. valdevu OUT: longitud de lo, datos reales long *loncade)
'"'" '"'" '"
"'
"'
"' "'-' "'
/* Define el valor del atributo de una instrucción de SQL */ short SQLSetStmtAttr( controlador de instrucciones */ /* IN: long stmtHdl. código 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 gestión de atributos.
651
cificado es NULL TERMINATION; controla las cadenas de caracteres terminadas en valores nul!. El único atributo de conexión especificado controla si la eLI llena automáticamente los descriptores de parámetros cuando se prepara o ejecuta la instrucción correspondiente. Los atributos del nivel de las instrucciones controlan la posibilidad de desplazamiento y la sensibilidad de los cursores. Quizás los más importantes de los atributos especificados por la eLI sean los controladores de los cuatro descriptores eLI que pueden asociarse con instrucciones (dos descriptores de parámetros 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 estándar SQUCL!, incluye muchos más atributos. Por ejemplo, los atributos de conexión de ODBC pueden utilizarse para especificar conexiones sólo de lectura, para activar el procesamiento asíncrono de instrucciones, para especificar el tiempo límite para las soliciludes de conexión, etc. Los atributos de entorno de OnBC controlan la traducción automática de las llamadas ODBC de versiones anteriores del estándar ü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 número de filas de resultados de las consultas que pueden generar las consultas.
L/amadas de información a CL/ La eLI incluye tres llamadas específicas que pueden utilizarse para obtener información sobre la implementación eL!. En general, estas llamadas no las utilizan los programas de aplicación escritos para una finalidad concreta. Son necesarias para los programas de finalidad general (como los· programas de consultas o de elaboración de informes) que necesitan determinar las características concretas de la CL! que están utilizando. Las llamadas pueden verse en la Figura 19.23. La llamada a SQLGetFunctions () se utiliza para determinar si una implementación dada admite las llamadas a una función eLI concreta. Se llama con el valor del código de función correspondiente a una de las funciones eLI y devuelve un parámetro que indica si se admite la función. La llamada a SQLGetlnfo () se utiliza para obtener información mucho más detallada sobre la implementación eLI, como las longitudes máximas 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 mayúsculas y minúsculas. La llamada a sQLGetTypelnfo () se utiliza para obtener información 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 catálogo del sistema de información de tipos de datos. Genera un conjunto de filas de resultados de la consulta en el que cada fila contiene información sobre un tipo de datos admitido concreto. La información proporcionada indica el nombre del tipo de datos, su tamaño, si admite valores nuU, si se puede buscar, etc.
652
SOL. Manual de referencia
Capítulo 19: Las API de SOL
/* Recupera información detallada sobre las posibilidades de la implementación de la eLI .. / short SQLGetlnfo ( /* IN: controlador de conexiones */ long connHdl, /* IN: tipo de información solicitada */ short tipoinfo, 1* OUT: búfer para la información voíd "valinfo, recuperada */ /* IN: longitud del búfer de short lonbuf, información */ /'* OUT: longitud real de la información short *10ninfo) devuelta .,
/* Determina el número de filas afectadas por la instrucción anterior de SQL */ short SQLGetFunctions /* IN: controlador de conexiones */ long connHdl, /* IN: código de identificación de la short idfunci •. función ,o/ /* OUT: indica si se admite la short "admitida) función */
*'
,. Determina la información sobre los tipos de datos admitidos short SQLGetTypeInfo ( ,. IN: controlador de instrucciones ., long strntHdl, ,. IN: TODOS LOS TIPOS o el tipo short tipodatosl solicitado .,
653
ODBe. También 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 gestión 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 básicas 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
Programa interactivo de consultas
Programa de análisis de datos
J.
~
I
I
Programa de hoja de cálculo
Programa escrito por el usuario
-¡
+
I
Programa de
I elaboración I de informes I
¡
API OOBC lIamable
I
Gestor de controladores OBOC
Figura 19.23.
Rutinas
eL!
de información sobre la implementación.
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 estándar SQUCLI, que es ahora el estándar 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 normalización para crear la especificación SQUCLI. Con la introducción de la versión 3.0 de OOBC, Microsoft adaptó OOBC a! cumplimiento del estándar SQUCLI. Con esta revisión, ODBe se transformó en un superconjunto de la especificación SQUCLI. OOBC va más allá de las posibilidades de SQLlCLI en varias áreas, en parte porque el objetivo de Microsoft para ODBe era más amplio que la mera creación de una API normalizada para el acceso a las bases de datos. Microsoft también quería permitir, que un solo programa de aplicación de Windows pudiera tener acceso de manera simultánea a varias bases de datos diferentes empleando la API
Controlador
Controlador
Controlador
Controlador
OBOe
OBoe
OBoe
OBoe
(incluidas las capas de SOL y de consultas)
Cliente SGBD
1 SGBO
1
r
IOC:J
'=¡
Servidor
SGBO
l'
Base de datos local
Archivos locales
.
.
~
Base de datos del servidor
Figura 19.24.
Arquitectura de ODBe.
~
Servidor SGBO
I
. l'
Base de datos del servidor
I
•••
654
SOL Manual de referencia
de aplicación. La API se empaqueta en forma de biblioteca de vínculos dinámicos (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 informático 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 código 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 conexión cliente/servidor, o manejar la conexión 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 petición de los programas de aplicación. El gestor de controladores también es responsable del enrutamiento de las llamadas a la API realizadas por los programas de aplicación al controlador correspondiente para su ejecución. Cuando un programa de aplicación desea tener acceso a una base de datos mediante ODBC, sigue la misma secuencia de inicio especificada por el estándar 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 información sobre la conexión proporcionada y determina el controlador ODBC necesario. El gestor de controladorescarga el controlador en la memoria si no lo está utilizando todavía otro programa de aplicación. Las llamadas posteriores del programa de aplicación por esa conexión CLIJ ODBC concreta se encaminan a ese controlador. El programa de aplicación puede, si es conveniente, realizar más llamadas a SQLConnect () para otros oógenes de datos que harán que el gestor de controladores cargue de manera simultánea otros controladores para otras marcas de SGBD. El programa de aplicación puede utilizar ODBC para comunicarse con dos o más bases de datos diferentes, de marcas diferentes, empleando una API uniforme.
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-
Capitulo 19: Las API de SOL
655
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 fácIlmente diferencias Id·' . , · 1 d SQL . PI y conjuntos A ,pero as herenCIas mas sust COsm '1 tlcas en sus dla ectos e . ·bl es d O ' ancla es. son d1·f'lCt·1 es o tropOSI e enmascarar. DBC proporCIOna una solución 1 . d . . I d·f d parcJa a bl est~ pro ema proporcIOnan o vanos OIve es 1 erentes e capacidad ODBC haCiendo que cada controlador ODBC se describa a sí mismo mediante las llam ~ d~s ODBC/~Ll que dev~elven información,sobre la funcionalidad general, las fU~ ClOnes a?m¡Udas 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 aplicación, que deben tratar con esta falta de uniformi~ dad de los :on~rloladlores O~BC. En la práctica,. la inmensa mayoría de los progral mas de aphcaclOn solo conflan en el nucleo báSICO central de funcionalidad ODBC y no se preocupan de características o perfiles más avanzados. '
Funciones del catálogo de OOBC Una de las áreas en las que ODBC ofrece posibilidades que superan el estándar SQUCLI es la recuperación de información del catálogo del sistema sobre la estructura de las bases de, datos, Como parte del estándar 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 información de SQL2 (SQL2 lnfon:zatio~ Schema), tal y como se describe en él Capítulo 16, ODBC no da por supuesta la presencIa de un esquema de la mformaclón. En vez de eso, proporciona un conjunto de funciones especializadas, que pueden verse en la Tabla 19.4, que aportan la información sobre la estructura de los oógenes de datos. Llamando a esas funciones y procesando sus resultados, los programas de aplicación pueden determinar en el momento de la ejecución, la información 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 oógenes de datos. Tabla 19.4.
Funciones de catálogo de DDBC
iValor devuelto por la eLI
Significado
o
Instrucción completada con éxito.
I
Finalización con éxito y con advertencia.
100
No se han encontrado datos (al recuperar el resultado de la consulta).
99
Hacen falta datos (falta un parámetro dinámico necesario).
-1
Error durante la ejecución de una instrucción de SQL.
-2
Error -proporcionado controlador no válido durante la llamada.
656
SOL. Manual de referencia
Capítulo 19: las API de Sal
Las funciones de catálogo ODBC no suelen ser necesarias para los programas de aplicación que se escriben para un propósito concreto. Sin embargo, resultan fundamentales para los programas de propósito general, como los programas de consulta, los generadores de informes o las herramientas de análisis de datos. Se puede llamar a las funciones de catálogo en cualquier momento una vez establecida la conexión con el origen de datos. Por ejemplo, los programas generadores de informes pueden llamar a $QLConnect () y llamar inmediatamente después a SQLTables () para determinar las tablas que están 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 catálogo devuelven su información como si fuera un conjunto de resultados de llna consulta. El programa de aplicación utiliza las téc· nicas ya descritas para el procesamiento de los resultados de las consultas CLI, con el fin de enlazar las columnas de información devuelta con las áreas de las variables del programa. El programa llama luego a SQLFetch () para que trabaje con la información devuelta. Por ejemplo, en los resultados devueltos por la llamada a SQLTables (), cada llamada a SQLFetch () recupera información sobre una tabla del origen de datos.
I I
• I!
Tabla 19.5.
ODBe proporciona un conjunto de capacidades ampliadas respecto a las especificadas en el estándar SQUCLI. Muchas de estas capacidades están diseñadas para mejorar el rendimiento de las aplicaciones basadas en ODBC minimizan.do el número de llamadas·a funciones de ODRe que deben hacer los programas de aplicación o la cantidad de tráfico generada por las llamadas ODRC. Otras capacidades proporcionan características útiles para el mantenimiento de la independencia respecto de las bases de datos o ayudan a los programas de aplicación en el proceso de conexión 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 revisión 3.0 de ODRC y no las incluyen todavía la mayor parte de los controladores ODRe ni las aplicaciones basadas en ODRC.
Descripción
SQLBrowseConnect()
Proporciona información sobre los orígenes de datos ODBC disponibles y los atributos necesarios para conectar con cada uno de ellos.
SQLDrivers()
Devuelve una lista de los controladores disponibles y de los nombres de los atributos de los controladores.
SQLDriverConnect()
Funciona como una forma ampliada de la llamada SQLConnect () para el paso de información adicional sobre las conexiones.
SQLNumParams ()
Devuelve el número de parámetros de una instrucción de SQL preparada anteriormente. Proporciona funcionalidad ampliada respecto de la llamada SQUCLI SQLBindParam ( ) .
SQLDescribeParam()
Devuelve información sobre un parámetro.
SQLBulkOperations{l
Realiza operaciones masivas de inserción y de marcadores.
SQLMoreResults(l
Determina si hay disponibles más resultados para una instrucción. Define la posición del cursor dentro de un conjunto recuperado de resultados de la consulta para operaciones posicionadas.
SQLNativeSQL()
Devuelve la traducción a SQL nativo del texto de una instrucción proporcionada de SQL que cumple ODBC.
mero a la función con información básica sobre el origen de datos de destino y la función devuelve más atributos de conexión necesarios (corno el nombre de usuario o la contraseña). Los programas de aplicación pueden obtener esta información (por ejemplo, pidiéndosela al usuario) y luego volver a llamar a SQLBrowseConnect () con la información adicional. El ciclo continúa hasta que la aplicación baya determinado toda la información necesaria para una llamada con éxito a SQLConnect (l.
La capacidad de agrupación de conexiones está diseñada para mejorar la eficiencia del proceso de conexión y desconexión de ODBC en entornos cliente/servidor. Cuando se activa la agrupación 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 algún tiempo y se vuelven a utilizar si se realiza alguna llamada a SQLConnect (l para el mismo origen de datos. Esta reutilización de las conexiones puede reducir notablemente la sobrecarga de la red y de los inicios y finales de sesión en las aplicaciones cliente/servidor que implican cortas transacciones y elevadas tasas de transacciones.
Dos de las características extendidas de ODRC se centran en el proceso de conexión.. La exploración de conexiones está diseñada para simplificar el proceso de conexión con los orígenes de datos y hacerlo más independiente de las bases de datos. SQI:-BrowseConnect () incluye un estilo de conexión iterativo para el acceso a los orígenes de datos ODRC. Los programas de aplicación llaman pri-
I I
Función
SQLSetPos()
Capacidades de conexión extendidas
i
Otras funciones ODSe
SQLBindParameter()
Capacidades ampliadas de OD8C
657
1
658
SOL. Manual de referencia
Traducción de los dialectos de SOL ODBe no sólo especifica un conjunto de llamadas a la API, sino también un dialecto estándar del lenguaje SQL que es un subconjunto del estándar SQL2. Es responsabilidad de los controladores DDBC la traducción 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 aplicación ver el efecto de esta traducción. ODBe admite también las secuencias de escape que permiten que los programas de aplicación dirijan de manera más explícita la traducción de las características de SQL que tienden a ser menos consistentes de unos dialectos SQL a otros, como las reuniones externas y los criterios de búsqueda de estructuras. Ejecución asíncrona
Los controladores ODBC pueden admitir la ejecución asíncrona de las funciones ODBe. Cuando un programa de aplicación realiza una llamada ODBe en modo asíncrono, ODBC inicia el procesamiento necesario (generalmente, la preparación o la ejecución de la instrucción) y luego, inmediatamente, devuelve el control al programa de aplicación. El programa de aplicación puede seguir adelante con otro trabajo y volver a sincronizarse más adelante con la función ODBC para determinar su estado de finalización. La ejecución asíncrona puede solicitarse conexión por conexión o instrucción por instrucción. En algunos casos, la ejecución asÍncrona de funciones puede terminarse con una llamada a sQLCancel ( ), lo que concede al programa de aplicación un método para la interrupción de las operaciones ODBC de larga duración. Eficiencia en el procesamiento de instrucciones
Cada llamada a ODBC para que ejecute una instrucción SQL puede implicar un'! cantidad significativa de sobrecarga, especialmente si el origen de datos implica una conexión de red cliente/servidor. Para reducir esta sobrecarga,. los controladores ODBC pueden albergar los lotes de instrucciones. Con esta capacidad los programas de aplicación pueden pasar una secuencia de dos o más 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 tráfico de red en un entorno cliente/servidor, pero complica la detección y la recuperación de los errores, que tienden a volverse específicos 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 lógica asociada de control del flujo, y permiten que se invoquen las instrucciones con una sola llamada al procedimiento. ODBC
Capítulo 79: Las API de SOL
659
proporciona un conjunto de posibilidades que permiten que los programas de aplicación 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 parámetros de los procedimientos, ODBC pennite que los parámetros se enlacen por el nombre en lugar de por la posición. Para los orígenes de datos que proporcionan información de metadatos sobre los parámetros de los procedimientos almacenados,la llamada a SQLDescribeParam () permite que los programas de aplicación determinen, en el momento de la ejecución, el tipo de datos del parámetro exigido. Los parámelros de salida de los procedimientos almacenados se admiten mediante SQLBindParam () (en cuyo caso se modifica el búfer de datos del programa de aplicación al volver de la llamada a SQLExecute (loa SQLExecDirect ()) o mediante SQLGetData (), lo que permite la recuperación de los datos devueltos de gran longitud. Otras dos capacidades extendidas de ODBC proporcionan eficiencia cuando hay que ejecutar de manera repetida una sola instrucción de SQL (como las instrucciones INSERT o UPDATE). Las dos abordan el enlace de parámetros para esta situación. Con la característica de compensación de enlaces, una vez que se ha enlazado un parámetro de la instrucción y se ha ejecutado la instrucción, ODBC permite que el programa de aplicación modifique su enlace para la siguiente ejecución de la instrucción especificando una nueva ubicación de memoria como compensación de la ubicación original. Se trata de una manera efectiva de enlazar los parámetros con elementos individuales de un array para la ejecución repetida de instrucciones. En general, la modificación de los valores compensados es mucho más eficiente que volver a enlazar el parámetro con llamadas repetidas a SQLBindParam( l. Las arrays de parámetros de ODBC proporcionan un mecanismo alternativo para que los programas de aplicación pasen varios conjuntos de valores de los parámetros en una sola llamada. Por ejemplo, si un programa de aplicación necesita insertar varias filas en una tabla, puede solicitar la ejecución de una instrucción INSERT parametrizada y enlazar los parámetros 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 parámetros-o ODBC admite tanto las arrays de parámetros por filas (cada elemento del array guarda un conjuto de valores de los parámetros) como los arrays de parámetros por columnas (cada valor de los parámetros 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 aplicación 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
SQL. Manual de referencia
utilizando las mismas técnicas que se emplean para las arrays de parámetros. Además, se puede utilizar la función SQLSetPos () para establecer una de las filas del conjunto de filas como fila en curso para las operaciones de actualización o de eliminación posicionadas. Los marcadores de OnBC proporcionan un impulso diferente de eficiencia para los programas de aplicación 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 métodos para soportar los marcadores, pero es transparente para el programa de aplicación). 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. Además, pueden utilizarse para llevar a cabo actualizaciones o eliminaciones posicionadas con base en un marcador. Los marcadores también 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 más eficientes algunas operaciones (por ejemplo, la realización de actualizaciones posicionadas mediante un marcador en lugar de volver a especificar un criterio de búsqueda 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 información 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 característica relacionada con la eficiencia. La llamada a SQLBulkOperations () permite que los programas de aplicación actualicen, inserten, eliminen o vuelvan a capturar varias filas de manera eficiente en función de sus marcadores. Opera junto con los cursores de bloques y trabaja sobre las filas del conjunto de filas actual. Los programas de aplicación 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 código de funci6n que indica si las filas identificadas se van a actualizar, eliminar o volver a capturar, o si hay que añadir 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 inserción, la eliminaci6n o la actualizaci6n masivas de datos.
Capítulo 19: Las API de SOL
661
introducción de OracleS, OCI sufrió una importante revisión, y muchas de las llamadas OCI originales se sustituyeron por versiones nuevas mejoradas. Junto con Oracle9 y versiones posteriores esta «nueva OCI» (la versión de OracleS) es de hecho la interfaz de llamadas de Oracle para los nuevos programas. La «antigua OCl» (de Oracle7 y versiones anteriores) sólo es importante por los programas heredados que se desarrollaron originalmente empleándola. Para referencia, las rutina,s de la «antigua OC!» se resumen en la Tabla 19.6, de modo
Tabla 19.6.
Función
Funciones antiguas de la interfaz de llamadas de Oracle (Oracle7 y anteriores)
Descripción
Conexión y desconexión de bases de datos
olon (l oopen () ocIase () oIogof ()
Inicia la sesión en una base de datos de Oraele. Abre un cursor (conexión) para el procesamiento de inslrucciones de SQL. Cierra un cursor abierto (conexión). Cierra la sesión en una base de datos de Graele.
Procesamiento básico de instrucciones osq13 ()
oexee () oexn( ) obreak () oermsg ()
Prepara (compila) una cadena de caracteres de SQL. Ejecuta una instrucción ya compilada. Se ejecuta con un array de variables de enlace. Aborta la función actual de la interfaz de llamadas de Orade. Obtiene el texto del mensaje de error.
Parámetros de las instrucciones obndrv () obndrn ()
Enlaza un parámetro con una variable del programa (por su nombre). Enlaza un parámetro con una variable del programa (por su número).
Procesamiento de transacciorles
ocom() oroI () ocon () oeof ()
Compromete la transacción actual. Retrocede la transacción actuaL Activa el modo de compromiso automático. Desactiva el modo de compromiso automático.
Procesamiento de resultados de las consultas
La interfaz de llamadas de Oraele (OCI)
odse ( ) oname ( ) odefin ()
La ¡ntenaz de programación más popular de Orade es SQL incorporado. No obstante, Oracle proporciona también una API alternativa llamable, conocida como interfaz de llamadas de Oraele (Oraele Call Interface) u OC!. OC! lleva muchos años disponible y ha permanecido bastante estable a través de varios ciclos importantes de actualización de Orade, incluidas todas las versiones de OracIe7. Con la
ofeteh () ofen () ocan ( )
Obtiene una descripción 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.
662
SOL. Manual de referencia
que se puedan reconocer los programas que puedan estar utilizando esta versión antigua. Conceptualmente, la rutinas son muy parecidas a la interfaz de SQL dinámico ¡ncaporado. que se describen en el Capítulo 18. La nueva OCI utiliza muchos de los conceptos del estándar 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 descripción completa queda fuera del objetivo de este libro. Los apartados siguientes identifican las principales rutinas que emplea la mayor parte de los programas de aplicación y sus funciones.
Controladores OCI La nueva OCI utiliza una jerarquía de controladores para gestionar la interacción con las bases de dalas de Orade, al igual que la jerarquía 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 conexión 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 multisesión). • Controlador de sesiones. Identifica una sesión activa de usuario (para aplicaciones multisesión). • Controlador de instrucciones. Identifica una instrucción de Oracle-SQL que se está procesando. • Controlador de enlaces. Identifica UD parámetro de entrada de una instrucción de Orade. • Controlador de definiciones. Identifica una columna de resultados de una consulta de Orade. • Controlador de transacciones. Identifica una transacción de SQL en evolución. • Controlador de objetos completos. Recupera los datos de un objeto de Orade. • Controlador de errores. Informa y procesa los errores OCI. Los programas de aplicación gestionan los controladores OCI empleando las rutinas que pueden verse en la Tabla 19.7. Las rutinas de asignación 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 conexión y de instrucciones. Los controladores de errores se utilizan para devolver información de OCI a la aplicación. Los controladores de errores que hay que utilizar para la comunicación de errores suelen pasarse como parámetros para las llamadas OCL Si el estado de devolución indi.ca un error, se puede recuperar del controlador de errores la información sobre el error empleando OCIErrorGet ( ).
Capítulo 19: Las API de SOL
Tabla 19.7.
663
Rutinas OCI de gestión de controladores
Rutina
Funci6n
OCIHandleAlloc()
Asigna un controlador para su empleo.
OCIHandleFree()
Libera un controlador asignado previamente.
OCIAttrGet ()
Recupera un atributo concreto del controlador.
OCIAttrSet(}
Define el valor de un atributo concreto del controlador.
Conexión a un servidor de Oraele La secuencia de inicialización y de conexión para OCI es igual que las ya ilustradas para CLUODBC y para dbl ib. Las rutinas OCI asociadas con la gestión de conexiones se pueden ver en la Tabla 19.8. Los programas de aplicación llaman primero a OCllni tialize () para inicializar la interfaz de llamadas de Drade. Esta llamada también indica si se va a utilizar OCI en modo multihebra, si el programa de aplicación va a utilizar las funciones del modo de objetos de OCI y otras opciones. Tras la inicialización los programas de aplicación 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 inicialización y de gestión de conexiones Rutina
Función
OCIInitialize()
Inicializa la interfaz de llamadas de Draele para utilizarla.
OCIEnvlnit ()
Establece un controlador de entorno para la interacción con la OC!.
OC lLagan ()
Se conecta con un servidor de bases de datos de Drade para una sesión OCL
oCILagoff ()
Termina una conexión previa de inicio de sesión.
oCIServerAttach()
Se conecta a un servidor de Graele para operaciones multisesión.
OCIServerDetach()
Se desconecta de un servidor de Oraele.
OCIServerVersian()
Devuelve la información sobre la versión del servidor.
OCISessionBegin()
Comienza una sesión de usuario en un servidor conectado previamente.
OCIPasswordChange()
Cambia la contraseña de un usuario en el servidor.
OCISessionEnd()
Finaliza una sesión de usuario iniciada previamente.
664
Capítulo 19: Las API de SOL
SOL. Manual de referencia
Tras estos pasos iniciales la mayor parte de las aplicaciones llaman a OCILogon () para establecer una sesión con un servidor de bases de datos de Orade. Las llamadas OCI posteriores tienen lugar en el contexto de esa sesión 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 sesión. Las otras llamadas proporcionan una gestión de la sesión más avanzada para las aplicaciones multihebra y multiconexión. Las llamadas a OCIServerVersion () pue~ den utilizarse para determinar la versión del software del servidor de Oracle. Las llamadas a oCIChangePassword () se pueden utilizar para modificar las contraseñas caducadas.
Ejecución de instrucciones Las funciones OCI que pueden verse en la Tabla 19.9 implementan la ejecución de instrucciones de SQL. OCIStmtPrepare () y OCIStmtExecute () admiten el pro-
Tabla 19.9.
Rutinas OCI de procesamiento de instrucciones y de manejo de parámetros
Prepara una instrucción para ejecutarla. Ejecuta una instrucción ya preparada. Aborta la operación OCI en curso en el servidor. Enlaza un parámetro con base en su posición. Enlaza un parámetro 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 parámetros. Registra una rutina de rellamada para un parámetro ya enlazado que va a utilizar el enlace en el momento de la ejecución. Proporciona información adicional de un parámetro ya enlazado con un tipo de datos de objeto complejo. Obtiene información sobre el valor de un parámetro dinámico fragmentario necesario en el momento de la ejecución para la OCI (o una columna de resultados fragmentarios de la consulta en proceso de devolución). Define la información (búfer, valor, indicador, etc.) del valor de un parámelfo dinámico fragmentario que se le proporciona a la OCI en el momento de la ejecución (o una columna de resultados fragmentarios de la consulta que se acepta en el momento de la ejecución).
ceso de dos etapas de preparación y ejecución. La función OCIStmtExecute () también puede utilizarse para describir los resultados de las consultas (de manera parecida a la instrucción de SQL incorporado DESCRIBE), sin ejecutar realmente la consulta, pasando una bandera específica. OCl proporciona de manera automática una descripción de los resultados de la consulta cuando se llama a OCIStmtExecute () en el modo de ejecución normal de las instrucciones. La descripción 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 aplicación con los parámetros de las instrucciones, bien sea empleando las posiciones de los parámetros, bien los nombres de los parámetros. Estas llamadas asignan de manera automática controladores de enlaces para Jos parámetros cuando se los llama, o pueden llamarse con controladores de enlaces asignados de manera explícita. Las otras llamadas implementan técnicas de enlace más avanzadas, incluidos el enlace de varios valores de los parámetros (arrays) y el enlace de tipos de datos de objetos complejos. También proporcionan el procesamiento de los parámetros (y de los resultados de las consultas) en el momento de la ejecución, lo que se corresponde con el modo de parámetros diferidos soportado por CLIIODBC y ya descrito en el apartado «Procesamiento de instrucciones CLl». Las llamadas de infonnaci6n sobre fragmentos admiten este modo de información.
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 función OCIDefineBypos () se utiliza para enlazar una columna de resultados de la co~sulta (identificada por su número de columna)
Tabla 19.10.
,
Rutinas OCI de procesamiento de resultados de consultas
Rutina
Función
OCIStrntFetch()
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 recuperación de varias filas de resultados. Registra una rutina de retrollamada para el procesamiento dinámico de una columna de resultados de la consulta. Proporciona información adicional de una columna de resultados de la consulta ya enlazada con un tipo de datos de objeto complejo.
con una ubicación de almacenamiento del programa. (La terminología OCI se refiere a esto como proceso de definición; el término enlace queda reservado para los parámetros de entrada.) Las otras llamadas de definición admiten enlaces dinámicos (en el momento de la ejecución). 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 instrucción de SQL FETCH.
Manejo de descriptores
Capítulo 19: Las API de SOL
Tabla 19.12.
667
Rutinas OCI de gestión de transacciones
Rutina
Function
OCITransComrnit()
Compromete una transacción.
OCITransRollback()
Hace retroceder una transacción.
OCITransStart()
Inicia o reconecta una transacción especial.
OCITransPrepare()
Se prepara para 90mprometer una transacción distribuida.
OCITransForget()
Olvida una transacción preparada anteriormenle.
OCITransDetach()
Desconecta una transacción distribuida.
OCI utiliza los descriptores para proporcionar información sobre los parámetros, los objetos de las bases de datos de Oracle (tablas, vistas, procedimientos almacenados, etc.), los objetos de gran tamaño, los identificadores de las filas y otros
objetos OCI. Los descriptores proporcionan información al programa de aplicación 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.
Gestión de transacciones Los programas de aplicación utilizan las funciones que pueden verse en la Tabla 19.12 para implementar la gestión de transacciones de SQL. Las llamadas a OCITransConuni t () y a OCITransRollback () ofrecen la posibilidad básica de comprometer y de hacer retroceder las transacciones, y se corresponden con las instrucciones normales de SQL COMMIT y ROLLBACK. Las demás funciones proporcionan un esquema de transacciones muy rico y complejo, incluida la especificación ¡: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 conexión en activo como parámetro de entrada,
Manejo de errores
Las funciones OCI devuelven un código de estado que indica si se han completado con éxito. Además, la mayor parte de las funciones OCI aceptan los controladores de errores como parámetros de entrada. Si se produce un error durante el procesamiento, la información del error se asocia con el controlador. A la vuelta de la función, el programa de aplicación puede llamar a OC;IErrorGet () para el controlador de errores con el fin de obtener más información sobre el error, incluido el número y el mensaje de error. Información del catálogo
La llamada a OCIDescribeAAY () proporciona acceso a la información del catálogo del sistema de Orade. Los programas de aplicación llaman a esta rutina con el nombre de una tabla, vista, sinónimo, procedimiento almacenado, tipo de datos u otro objeto del esquema de Orade. La rutina rellena un descriptor (identificado mediante un controlador de descriptores) con información 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 ejecución. Manipulación de objetos de gran tamaño
Tabla 19.11.
Rutinas OCI de gestión de descriptores
Rutina
Función
OCIDescriptorAlloc()
Asigna un descriptor o un localizador LOB.
OCIDescriptorFree()
Libera un descriptor asignado anteriormente.
OCIParamGet ()
Consigue un descriptor para un parámetro.
OCIParamSet (l
Define un descriptor de parámetros en un controlador complejo de recuperación 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 tamaño de OracIe (Large Object, LOB) y los objetos de gran tamaño almacenados en archivos a los que hacen referencia las columnas de Orade. Como los objetos de gran tamaño pueden tener longitudes de decenas de millares o millones de bytes. no se suelen poder enlazar directamente con los búferes de los programas de aplicación 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 parámetros de entrada para los datos LOB que se insertan o actualizan. Las rutinas de manejo
668
Capítulo 19: Las API de SOL
SOL. Manual de referenc;a
Tabla 19.13.
Rutinas OCI para el procesamiento de objetos de gran tamaño
Rutina
Función
OCILobRead ()
Lee un fragmento de un LOB para el área de datos del programa de aplicación.
OCILobWrite()
Escribe los datos del área de datos del programa de aplicación en un LOB.
OCILobAppend ()
Añade datos al final de un LOB.
OCILohErase (l
Borra
dato~
de un LOB.
OCILobTrim ()
Trunca los datos del final de un LOB.
OCILobGetLength()
Obtiene la longitud de un LOB.
OCILobLocatorIslnit()
Comprueba si es válido el localizador de un
OCILobCopy ()
Copia los datos de un
OCILobAssign ()
Asigna el localizador de un
OCILobIsEqual ()
Compara dos localizadores de
OCILobFileOpen ()
Abre un archivo que contiene datos
LOS
OCILobFileClose()
Cierra un archivo
OCILobFileCloseAll()
Cierra todos los archivos
LOS
LOS.
a otro. a otro.
LOS
LOS. LOB.
abierto anteriormente. LOE
abiertos anteriormente.
OCILobFileIsOpen()
Comprueba si está abierto un archivo
OCILobFileGetName()
Obtiene el nombre de un archivo localizador LOB.
OCILobFileSetName()
Define el nombre de un archivo
LOS,
LOS
LOE.
dado un
en un localizador
LOE.
OCILobFileExists()
Comprueba si existe un archivo
OCILobLoadFromFile()
Carga un
LOE
de un archivo
LOB.
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 aplicación. Las rutinas aceptan uno o varios IDealizadores LOS como parámetros.
Conectividad con bases de datos Java (JDBC¡ JDBC es una API llamable de SQL para el lenguaje de programación Java. JDBC es, a la vez, el estándar oficial y el estándar de facto para el acceso a las bases de datos de SQL desde Java. Para el lenguaje de programación 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
669
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 versión. IDBC 1.0 proporcionaba el núcleo básico de la funcionalidad de acceso a datos, incluido un gestor de controladores para arbitrar las conexiones con varios SGBD, la gestión de las conexiones para el acceso a cada base de datos, la gestión de las instrucciones para el envío de comandos de SQL al SGBD y la gestión 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 versión 2.0 añadió: • 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 permitía el movimiento hacia delante y hacia atrás por los resultados de las consultas. • Conjuntos de resultados actualiza;les. Los programas de Java pueden actualizar la base de datos mediante la actualización de una fila concreta de resultados de la consulta o la inserción en el resultado de una nueva fila. • Agrupación 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 amplían los límites de las bases de datos. • Orígenes 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. Abstracción 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 resincronización. • 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 versión relativamente nueva de JDBC. Sun la finalizó y la anunció formalmente en febrero de 2002, y se distribuye como parte de Java2
670
SOL. Manual de referencia
Capítulo 19: Las API de SaL
671
Standard Edition (J2SE) 1.4. Entre las nuevas posibilidades introducidas en la versión 3.0, figuran:
• Extensiones SQL para objetos relacionales. La API añade el soporte para los tipos de datos abstractos y las posibilidades asociadas que se agregaron en el estándar SQL:1999. • Puntos de revisión. La API permite el retroceso parcial a un punto de revisión marcado de manera específica a mitad de cada transacción.
Programa de aplicación Java
-
J,.
Implementaciones de JDBC y tipos de controladores JDBC da por supuesta una arquitectura de controladores como la proporcionada por el estándar ü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 petición 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 especificación JDBC no entra en los detalles concretos del modo en_ que se implementa cada controlador IDBC. No obstante, desde la introducción de JDBC, los desarrolladores han tendido a caracterizar los controladores JDBC en cuatro tipos. Las descripciones de los tipos dan por supuesta una conexión cliente/servidor entre la API JDBC (en el sistema cliente) y un servidor de bases de datos. Aunque se trata de una arquitectura de implantación empresarial frecuente, merece la pena observar que JDBC se utiliza para tener acceso a las bases de datos locales en sistemas tan pequeños 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 método) en acciones concretas contra el SGBD. Los controladores de tipo 1 se denominan también 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 práctica siempre es OnBC. La solicitud pasa a un controlador ODBC específico 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-
Programa de aplicación
Java
Java
J,.
~
J,.
•••
-
API JDBC
• Conservación 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 información sobre las instrucciones preparadas, como el número y tipo de datos de los parámetros y de las columnas de los resultados de las consultas.
Programa de aplicación
Gestor de controladores JDBC Controlador JDBC 1
Controlador JDBC 2
J SGSD local
T
•
I
•••
1 SGSD del servidor
..
1
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 código 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 envía 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 fáciles de encontrar, incluido uno distribuido por Sun. Los controladores de tipo 1 también 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 también la funcionalidad proporcionada por los controladores -puede que median-
672
Capítulo 19: Las API de SOL
SOL. Manual de referencia
Programa
I
de aplicación Java !
.¡. API JD8C
Gestor de controladores JOBC
!
Controlador JDBe (Tipo 1) ~
T
Los controladores de lipo 2 también 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 código 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 instalación de código binario en el sistema cliente, por lo que los controladores de tipo 2
APIOOSe Gestor de controladores
oose Programa de aplicación Java
Controlador DDBe para
I
SGBD xYZ
+
/"'API XVZ
SGBD local XVZ
Ciente SGBD
l
I I
API JDBC
APIXVZ
Gestor de controladores JDB Controlador JOBC (npo 2)
XVZ ~
"'Servidor
SGSO XVZ
API XYZ
API XYZ
SGBO local XVZ
Cliente SGBO XVZ
.
-l
..
.1
Servidor SGBO XVZ
Figura 19.26.
.
Controlador JOBC de tipo 1.
te ODBC no sean accesibles caracteósticas del SGBD subyacente que podóan 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 específicos del hardware y del sistema operativo de cada computadora cliente y carecen de la portabilidad de Java.
673
-l
Figura 19.27.
Controlador JDBC de tipo 2.
674
SOL. Manual de referencia
Capítulo 19: Las API de SOL
siguen siendo específicos de la arquitectura del hardware y del sistema operativo. A diferencia de los controladores de tipo 1, los controladores de tipo 2 también son específicos de la marca del SGBD. Si se desea establecer comunicación con varios SOBD, harán falta varios controladores. Finalmente, merece la pena observar que la distinción 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 envía 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.
675
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 código del lado del cliente puede escribirse en Java, empleando las interfaces de red proporcionadas por otras API de Java. Obsérvese también que el código del lado del cliente es neutral respecto al SGBD; realiza la misma función independientemente del SGBD de destino en el servidor. Esto significa que el código del lado del cliente es muy portable y puede ejecutarse en cualquier sistema que incorpore una máquina 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 través de la capa intermedia. La arquitectura de tipo 3 también implica una traducción 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 informático a otro y de unos sistemas operativos a otros. Sin embargo, a diferencia de los controladores del tipo 3, son específicos de cada SGBD, por lo que se necesita diferente código 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 práctica, la sobrecarga de la mensajería 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 neutrál respecto a los fabricantes (columna izquierda) o de la traducción directa de la API JDBC a una interfaz propietaria del SGBD. Las dos filas dividen los tipos de controlador según la traducción 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
SOL. Manual de referencia
Capítulo 19: Las API de SOL
Programa de aplicación
-----.----..•..~ •...--... Acceso a la base de datos -.----..---...•.-------I
Java
Mediante API neutral respecto Directo a la API propietario al fabricante (ODSC) del fabricante
.L
e
API JOBC
lD
lO
Gestor de controladores JDBC
I
(f)
O; "O
¡;:
Controlador JDBC
<:
!!!
•
(Tipo 4)
"O
1
o .¡¡
APIXYZ
:¡; :>
red
yz
prop'
XYZ
"O O;
Controlador de tipo 1
Controlador de tipo 2
Controlador de tipo 3
Controlador de tipo 4
"O
o
"C
e
~
<; "O
-~
"O
°e
"O ~
~ Pro'o
SelVidor SGBD
~
••
""~ O;••
Cliente XVZ
I
...I
Figura 19.29.
677
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 métodos que proporcionan:
Figura 19.30.
Tipos de controladores JDBC y compromisos.
• 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 excepción. Representan errores en la ejecución de las sentencias de SQL. Estos objetos tienen la relación lógica que puede verse en la Figura 19.31, basada en los objetos que proporcionan métodos para crear otros objetos. Los apartados siguientes describen cada uno de estos objetos y el modo en que se emplean sus métodos para conectar con las bases de datos, ejecutar instrucciones de SQL y procesar los resultados de las consultas. La explicación 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 documentación que se entrega con el paquete. El objeto DriverManager es la interfaz principal con el paquete IDBe. Algunos de los métodos más importantes que proporciona se muestran en la Tabla 19.14. Tras cargar la clase de controladores IDBe que se desea utilizar (generalmente empleando el método Class. forName ()), el programa pide al objeto DriverManager que conecte con el controlador y la base de datos concretas con el método getConnection ( ) :
• Objeto gestor de controladores. El punto de entrada a IDEC.
II Crea una conexi6n con el controlador JDBC de Oracle
• Objetos conexión. Representan conexiones activas con las bases de datos de destino. • Objetos instrucción. Representan instrucciones de SQL que hay que ejecutar.
String url : - .. varia en función del SO, etc," String usuario: "Santi"; String contra: "Tigre-; Connection dbconn ~ DriverManager.getConnection(url, usuario, contra);
678
Capítulo 19: Las API de SOL
SOL Manual de referencia
.-
El método getConnection () devuelve un objeto, el objeto Connection, que e'lcarna la conexión que se acaba de crear y la base de daro~del otro lado de esa conexión. Otros métodos DriverManager proporcionan control mediante programación de los tiempos límites de conexión, activan el registro histórico de llamadas de JDBC para la depuración y otras funciones de utilidad. Si halla un error mientras intenta establecer la conexión, el objeto DriverManager genera una excepción. El manejo de errores se describe más adelante en este capítulo en el apar· tado «Manejo de errores en IDBC».
Objeto conexión Objeto meladalos de la base de dalos
createStatement() prepareStatement() ~
I
~
Procesamiento básico de instrucciones en JDBC Las principales funciones del objeto de IDBC Connection son la gestión de la conexión con la base de datos, la creación de instrucciones de SQL para su procesamiento por esa base de datos y la gestión de las transacciones a través de la conexión. La tabla 19.15 muestra los métodos del objeto Connection que proporcionan esas funciones. En los programas de IDBC más sencillos, el paso siguiente al establecimiento de una conexión es llamar al método createStatement (l del objeto Connection para crear un objeto Statement. La principal función de los objetos Statement es ejecutar realmente las instrucciones de SQL. La Tabla 19.16 muestra los métodos dé! objeto Statement. que se utilizan para controlar la ejecución de las instrucciones. Hay varios métodos execute () diferentes, en función del tipo concreto de instrucción de SQL. Las instrucciones sencillas que no generan resultados de consultas (por ejemplo, UPDATE, DELETE, INSERT. CREATE TABLE) pueden utilizar el método execu teUp-
preparecall ()
~--'''---" /-~'---"
/-
Objeto instrucción lIamable
Objeto instrucción
getParameterMetaData() Objeto conjunto de resultados
Objeto meladatos de parámetros
Objeto roeladalos del conjunto de
resultados
Objeto excepción
Figura 19.31.
Tabla 19,14.
679
Tabla 19.15. Métodos JDBC del objeto Connection
Objetos principales empleados por la API JDBC.
Método
Descripción
Close ()
Cierra la conexión con el origen de datos.
createStatement()
Crea un objeto Statement para la conexión.
prepareStaternent()
Prepara para su ejecución una instrucción de SQL parametrizada en un objeto PreparedStatement.
prepareCall()
Prepara para su ejecución una llamada parametrizada a un procedimiento almacenado o a una función en un objeto callableStatement. Compromete la transacción en curso en la conexión.
Métodos del objeto DriverManager
Método
Descripción
getConnection ()
Crea y devuelve un objeto de conexión de la base de datos, dado un URL para el origen de datos y. opcionalmente, un nombre de
commit ()
usuario y una contraseña, y las propiedades de la conexión.
rollback( )
Hace retroceder la transacción en curso en la conexión.
registerDriver()
Registra un controlador ante el gestor de controladores JDBC.
setAutoCommit()
setLoginTimeout()
Define el tiempo límite para el inicio de sesión de cada conexión.
Define y reinicia el modo de compromiso automático de la conexión.
getWarnings (J
Recupera advertencias de SQL asociadas con una conexión.
getLoginTimeout()
Obtiene el valor del tiempo límite para el inicio de sesión.
GetMetaData
setLogWriter ()
Activa el seguimiento de las llamadas JDBC.
Devuelve un objeto DatabaseMetadata con información sobre la base de datos.
I 1\
680
SOL. Manual de referencia
Tabla 19.16.
Capítulo 19: Las API de SOL
Métodos JDBC del objeto Statement
Método
Connection dbconn; 11 La conexión de la base de datos String strl = ·UPDATE OFICINAS SET OBJETIVO = O"; String str2 = "DELETE FROM REPRESENTANTES WHERE NUM_EMPL = 106";
Descripción
Ejecución de instrucciones
básica.~
executeUpdate()
Ejecuta una instrucción de SQL que no es una consulta y devuelve el número de filas afectadas.
executeQuery ()
Ejecuta una sola consulta de SQL y devuelve un conjunto de resultados.
execute ()
Ejecución de propósito general de una o varias instrucciones de SQL.
/1 Crea un objeto statement para ejecutar SQL Statement stmt = dbconn.createStatement();
11 Actualiza la tabla OFICINAS con el objeto instrucción stmt.executeUpdate{strl);
Ejecución de instrucciones por lotes addBatch ()
executeBatch (1
681
Almacena los valores de los parámetros proporcionados anteriormente como parte de un lote de valores para su ejecución.
// Actualiza la tabla REPRESENTANTES con el objeto instrucción stmt.executeUpdate(str2);
Ejecuta una secuencia de instrucciones de SQL; devuelve un arfay de enteros que indican el número de filas afectado por cada una de eUas.
1/ Compromete las modificaciones de la base de datos dbconn.commit():
Limitación de los resultados de la consulta setMaxRows ()
Limita el número de filas recuperadas por una consulta.
getMaxRows ()
Recupera el
va~or
1/ Actualiza la tabla REPRESENTANTES empleando el mismo objeto instrucción strnt.executeUpdate(str2);
actual del límite máximo de filas.
setMaxFieldSize()
Limita el tamaño máximo de cualquier columna recuperada.
getMaxFieldSize{)
Recupera el límite actual del tamaño máximo del campo.
setQueryTimeout()
Limita el tiempo máximo de ejecución de las consultas.
getQueryTimeout()
Recupera el límite actual del tiempo máximo para las consultas.
1/ Finalmente, cierra la conexión dbconn. close () ;
Corno muestra el ejemplo. las operaciones de procesamiento de transacciones de SQL (comprometer y hacer retroceder) se manejan mediante llamadas de los métodos al objeto Connection, en lugar de mediante la ejecución de instrucciones COMMIT y ROLLBACK. Esto permite al controlador JDBC conocer el estado de las transacciones que está procesando sin necesidad de examinar el código de SQL concreto que se está ejecutando. IDBC también incorpora un modo de compromiso automático, en el que cada instrucción se trata corno si fuera una transacción. Un método del objeto Connection también controla esta opción. Obsérvese que los métodos Connection y Stat.ement a los que se llama en este fragmento de programa pueden provocar errores, y el fragmento no muestra ningún código para el manejo de errores. Si se produce algún error, el controlador JDBC generará una excepción 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 técnicas de manejo de errores se describen más adelante en este capítulo en el apartado «Manejo de errores en JDBe» .
Manejo de errores getWarnings ()
Recupera las advertencias de SQL asociadas con la ejecución de las instrucciones.
Las consultas utilizan el método executeQuery (l, ya que proporciona un mecanismo para devolver los resultados. Otros métodos execute incorporan las instrucciones preparadas de SQL, los parámetros de las instrucciones y los procedimientos almacenados. Para ilustrar el empleo básico de los objetos Connection y Staternent, se ofrece a continuación el fragmento de un programa de Java sencillo que crea una conexión con una base de datos. lleva a cabo dos actualizaciones de la base dé datos, compromete los cambios y cierra la conexión. date.
1/ El objeto de conexión y las cadenas de caracteres que se emplearán
.-L-
682
SOL. Manual de referencia'
Capítulo 79: Las API de SOL
Procesamiento de consultas sencillas
Tabla 19.17.
Al igual que con las demás 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 método execut.eQuery () de algún objeto Statement, pasando el texto de la consulta en la llamada al método. El método executeQuery () devuelve un objeto ResultSet que contiene los resultados de la consulta. El programa de Java invoca luego los métodos de este obj~to ResultSet para tener acceso a los resultados de la consulta, fila a fila y columna por columna.
Método
La Tabla 19.17 muestra los métodos proporcionados por el objeto ResultSet. A continuación se ofrece el fragmento de un programa de Java muy sencillo que muestra el modo en que los objetos y los métodos que se han visto hasta ahora se combinan para llevar a cabo el procesamiento de una consulta sencilla. Recupera e imprime el número de la oficina, la ciudad y la región de cada oficina de la tabla OFICINAS: // El objeto conexión, las cadenas de caracteres y las variables Connection dbconn; // la conexión de la base de datos Int num; // número de oficina devuelto String ciudad; // ciudad devuelta String reg; // región devuelta String strl = ·SELECT OFICINA, CIUDAD, REGION FROM OFICINAS·;
>
// Crea un objeto instrucción para ejecutar la consulta Statement stmt = dbconn.createSta~ement{); // Lleva a cabo la consulta - el método 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
683
Métodos JDBC del objeto ResultSet
Descripción
Desplazamiento de los cursores next ( )
Desplaza el cursor a la siguiente fila de resultados de la consulta.
clase ()
Finaliza el procesamiento de la consulta; cierra el cursor.
Recuperación básica de valores de las columnas getlnt ()
Recupera un valor entero de la columna especificada.
getShort ()
Recupera un valor entero corto de la columna especificada.
getLong ( )
Recupera un valor entero largo de la columna especificada.
getFloat ()
Recupera un valor numérico de coma flotante de la columna especificada.
getDouble ()
Recupera un valor de coma flolante de doble precisión de la columna especificada.
getString()
Recupera el valor de una cadena de caracteres de la columna especificada.
getBaolean ()
Recupera un valor verdadero/falso de la columna especificada.
getDate ()
Recupera un valor de fecha de la columna especificada.
getTime ()
Recupera un valor de tiempo de la columna especificada.
getTimestamp ()
Recupera un valor de marca temporal de la columna especificada.
getByte ()
Recupera un valor de bYle de la columna especificada.
getBytes ()
Recupera datos BINARY de longitud fija o variable de la columna especificada.
getObj ect ()
Recupera cualquier tipo de datos de la columna especificada.
Recuperaci6n de objetos de gran tamaño
+
~
•
+
getAsciiStream()
Obtiene un objeto de corriente de entrada para el procesamiento de una columna de objetos de carácter de gran tamaño (Character Large Object. CLOB).
GetBinaryStream()
Obtiene un objeto de corriente de entrada para el procesamiento de una columna de objetos binarios de gran tamaño (Binary Large Object, BLOB).
reg);
arras funciones // Cierra de manera explicita el cursor y la conexión answer. clase () ; dbconn.close·() ;
getMetaData()
Devuelve un objeto ResultSetMetaData con metadatos para una consulta.
getWarnings()
Recupera advertencias de SQL asociadas con ResultSet.
684
Capítulo 19: Las API de SOL
SOL. Manual de referencia
Los métodos 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 posición en curso en los resultados de la consulta. Su método next desplaza el cursor hacia delante, fila a fila, por los resultados. Hay una llamada explícita al método IDBC get para recuperar cada columna de datos de cada fila. Los estrictos esquemas de escritura y de protección de la memoria de Java hacen imprescindible este enfoque, pero supone una sobrecarga significativamente más 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 automática cuando se captura la fila siguiente. Finalmente, la llamada al método close concluye el procesamiento de la consulta. El ejemplo también muestra los dos métodos alternativos para la especificación del valor que debe recuperar de una columna cada llamada al método get. Se puede especificar el nombre de la columna que hay que recuperar (que se emplea para las columnas OFICINAS y CIUDAD) o su posición ordinal entre las columnas de resultados (que se utiliza para la columna REGlON). JDBC ofrece esta posibilidad sobrecargando cada método get -una versión toma un argumento de cadena de caracteres (el nombre de la columna); la otra toma un argumento entero (el número de la columna). Empleo de instrucciones preparadas en JDBC Los métodos executeQuery () y executeUpdate () del objeto Staternent proporcionan una posibilidad de SQL dinámico. Remedan la llamada a SQLExecDirect () del estándar CL!. La base de datos del otro extremo de la conexión JDBC no conoce con antelación el texto de SQL que aparecerá cuando se llame al método execute. Debe analizar la instrucción sobre la marcha y determinar el modo de ejecutarla. El enfoque de SQL dinámico 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 más 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 dinámico incorporado y las llamadas SQLPrepare () y SQLExecute () del estándar CL!. La instrucción de SQL que hay que ejecutar de manera repetida (como puede ser una instrucción 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 pasándola al SGBD para su análisis. Luego se puede ejecutar la instrucción de manera repetida con muy poca sobrecarga. Se pueden variar los valores concretos empleados por la instrucción durante cada ejecución pasándole valores de parámetros para su ejecución. Por ejemplo, se pueden modificar los valores que hay que utilizar para cada operación UPDATE o modificar el valor que debe coincidir en la cláusula WHERE de una consulta empleando parámetros. Para utilizar instrucciones preparadas con JDBe, los programas invocan el método prepa'reStatement () para una conexión, en lugar del método create-
685
Staternent (). A diferencia de createStatement (), el método prepareStaternent () toma un argumento -una cadena de caracteres que contiene la instruc-
ción de SQL que hay que preparar-o En la cadena de caracteres de la instrucción se indican los parámetros que hay que proporcionar mediante un signo de interrogación (?), que sirve como marcador de par6metro. Los parámetros pueden utilizarse en la instrucción en cualquier lugar en que pueda aparecer legalmente una constante. El método prepareStatement (') devuelve un objeto preparedStatement, que incluye algunos métodos adicionales además de los proporcionados por los objetos Statement. La Tabla 19.18 muestra algunos de esos métodos adicionales, casi todos los cuales son para el procesamiento de parámetros. Los métodos set () adicionales del objeto preparedStatement necesitan dos parámetros. Uno indica el número del parámetro para el que se proporciona el valor. El otro proporciona el propio valor del parámetro. Con estos métodos la
Tabla 19.18. Métodos adicionales del objeto JDBC PreparedStatement Método
Descripción
setInt ()
Define el valor de un parámetro entero.
setShort ()
Define el valor de un parámetro entero corto.
setLong ()
Define el valor de un parámetro entero largo.
setFloat ()
Define el valor de un parámetro de coma flotante.
setDouble ()
Define el valor de un parámetro de coma flotante de doble precisión.
setString ()
Define el valor de un parámetro de cadena de caracteres.
setBoolean ()
Define el valor de un parámetro BOOLEAN.
setDate ()
Define el valor de un parámetro DATE.
setTime ()
Define el valor de un parámetro TIME.
setTimeStamp (l
Define el valor de un parámetro TIMESTAMP.
setByte (l
Define el valor de un parámetro BYTE.
setBytes ()
Define el valor de un parámetro BINARY o VARBINARY.
setBigDecimal()
Define el valor de un parámetro DECIMAL o NUMERIC.
setNull ()
Define un valor NULL para un parámetro.
setObject ()
Define el valor de un parámetro arbittario.
ClearParameters
Borra el valor de todos los parámetros.
getParameterMetaData()
Devuelve el objeto ParameterMetaOata para una instrucción preparada (sólo JDBe 3.0).
686
SOL. Manual de referencia
CapItulo 19: Las API de SOL
secuencia típica 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 método prepareStaternent () con el texto de la instrucción que hay que preparar, incluidos los marcadores de parámetro. El SGBD analiza la instrucción y crea una representación interna optimizada de la instrucción que se va a ejecutar. Más adelante, cuando llega el momento de ejecutar la instrucción con parámetros, el programa llama a uno de los métodos set de la Figura 19.18 para cada parámetro, para proporcionar un valor para los parámetros. Cuando se han proporcionado todos los valores de los parámetros, el programa llama a executeQuery o a executeUpdate para que ejecuten la instrucción. El programa repite las etapas 3 y 4 una y otra vez (generalmente, docenas o centenares de veces, o más), variando el valor de los parámetros. Si el valor de un parámetro concreto no se modifica de una ejecución a la siguiente, no hace falta volver a llamar al método seto
687
pstrntl.executeUpdate(); dbconn.commit{) 1
// Define un parámetro 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 "
+
ciudad);
l answer.close() ;
// Define un parámetro diferente para la consulta y la ejecuta pstmt2.setString(l, "Este"); ResultSet answer : pstmt2.executeQuery();
A continuación se ofrece el fragmento de un programa que ilustra esta técnica: // El objeto conexión, las cadenas de caracteres y las variables Connection dbconn; // La conexión 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);
1/ Imprime la fila de resultados
"SELECT CIUDAD FROM OFICINAS WHERE REGION
system.out.println("La ciudad del este es " + ciudad); }
answer. close () ; >
1/ Prepara la instrucción UPDATE PreparedStatement pstmtl : dbconn.prepareStatement(strl);
// Prepara la consulta PreparedStatement pstmt2
Empleo de instrucciones l/amables en JD8C dbconn.prepareStatement(str2);
// Define los parámetros para la instrucción UPDATE y la ejecuta pstmtl.setString{l,-Central"); pstmtl.setInt(2,108) ; pstmtl.executeUpdate();
Reinicia uno de los parámetros y vuelve a ejecutar la instrucc~ón. y luego compromete la transacción pstmtl.setlnt(2,104); /1
// Acabado - cierra la conexión dbconn.close();
Los últimos apartados describían el modo en que JDBC admite la ejecución de instrucciones de SQL dinámico (mediante el objeto Statement. creado por el método createStatement (») y las instrucciones preparadas de SQL (mediante el objeto PreparedStatement. creado por el método prepareStaternent (»). JDBC también admite la ejecución de procedimientos almacenados y funciones almacenadas mediante un tercer tipo de objeto de instrucción, el objeto CallableStatement, creado por el método prepareCall (). A continuación puede verse el modo en que los programas de Java invocan las funciones almacenadas o los procedimientos almacenados empleando JDBC:
688 1.
2. 3.
4.
5.
6.
SOL. Manual de referencia
Capítulo 19: Las API de SOL
Tabla 19.19.
El programa de Java invoca al método prepareCall (), pasándole una instrucción de SQL que invoca la rutina almacenada. Los parámetros de la llamada se indican mediante marcadores de parámetro en la cadena de caracteres de la instrucción, igual que para las instrucciones preparadas. El método devuelve un objeto CallableStatement. El programa de Java utiliza los métodos set (l del objeto CallableStatement para especificar el valor de los parámetros de la llamada al procedimiento o a la función. El programa de Java utiliza otro método del objeto CallableStatement para especificar los tipos de datos de los valores devueltos por el procedimiento almacenado o la función. El programa de Java invoca uno de los métodos execute () del objeto CallableStatement para realizar realmente la llamada al procedimiento almacenado. Finalmente, el programa de Java invoca uno O varios de los métodos get () del objeto CallableStatement para recuperar los valores devueltos por el procedimiento almacenado (si es que hay alguno) o el valor devuelto de la función almacenada.
689
Otros métodos del objeto CallableStatement (continuación)
Función
Descripción
getBoolean ()
Recupera un valor verdadero/falso de la columna especificada.
getDate ()
Recupera un solo valor de datos de la columna especificada.
getTime ()
Recupera un solo valor de hora de la columna especificada.
getTiroestamp ()
Recupera un solo valor de marca temporal de la columna especificada.
getByte ()
Recupera un solo valor de byte de la columna especificada.
getBytes ()
Recupera datos BINARY de longitud fija o variable.
getBigDecimal ()
Recupera datos DECIMAL o NUMERIC.
getObject ()
Recupera cualquier tipo de datos.
El objelO CallableStatement proporclona todos los métodos del objeto PreparedStatement, que pueden verse en las Tablas 19.16 y 19.18. Los métodos adicionales que proporciona para el registro de los tipos de datos de los parámetros de salida o de entrada y salida y para recibir los valores devueltos de los parámetros tras la llamada se muestran en la Tabla 19.19.
Un ejemplo breve es la mejor manera de ilustrar la técnica de llamada a procedimientos almacenados y funciones almacenadas. Supóngase que la base de datos de ejemplo contiene un procedimiento almacenado definido de esta manera:
Tabla 19.19.
CREATE (IN OUT IN
Otros métodos del objeto CallableStatement
Función
Descripción
registerOutPararneter()
Registra el tipo de datos del parámetro de salida (o de enlfada y salida).
getInt ()
Recupera un valor entero devuelto.
getShort (1
Recupera un valor entero corto de la columna especificada.
getLong( )
Recupera un valor enlero largo de la columna especificada.
getFloat ()
Recupera un valor numérico de coma flotante de la columna especificada.
getDouble ()
Recupera un valor de coma flotante de doble -precisión de la columna especificada.
que cambia la región de una oficina, de la manera solicitada por los dos parámetros de entrada, y devuelve la región antigua como parámetro de salida y una función almacenada, definida de esta manera: CREATE FUNCTION OBTENER_REGION {IN OFICINA INTEGER) RETURNS VARCHAR(lO¡
que devuelve la región de la oficina dado su número de oficina. Este fragmento de un programa de Java muestra el modo de invocar el procedimiento almacenado y la función almacenada mediante JDBC: 11 El objeto conexión. las cadenas de caracteres y las variables Connection dbconn; 1/ la conexión de la base de datos String strl :: "{CALL CAMBIAR_REGION(?, ? ?)}-; String str2 :: "(? :: CALL OBTENER_REGlON(?))"; string regvieja; // región antigua devuelta String regnueva; // región actual devuelta
Recupera un valor de cadena de caracteres de la columna especificada. (continúa)
'-'--
690
691
Capítulo 19: Las API de SOL
SOL. Manual de referencia >
JI Prepara las dos instrucciones CallableStatement cstmtl dbconn prepareCall(strl); CallableStatement cstmt2 : dbconn prepareCall(str2); JI Especifica los valores de los parámetros y el tipo de datos de los datos devueltos para la llamada al procedimiento almacenado cstrntl.setlnt(1.12); 11 llama con el número de oficina 12 (Castellón) cstmtl.setString(3,"Centra1"); 11 y nueva región de la central cstmtl.registerOutParameter(2,Types.VARCHAR); 11 devuelve un parámetro varchar
11 Sigue adelante y ejecuta la llamada al procedimiento almacenado cstmtl.executeUpdate(}; regvieja = cstmt.getString(2); 11 el (segundo) parámetro devuelto es una cadena de caracteres
11 Especifica el valor de los parámetros y el tipo de los datos devueltos para la llamada a la función almacenada cstmt2.setlnt(1,12}; 11 llama con el número de oficina 12 (Castel1ón) cstmt2. registerOutParameter (1, Types. VARCHAR); 11 la función devuelve un varchar
11 Sigue adelante y ejecuta la llamada a la función almacenada cstmt2.executeUpdate() ; ansreg == cstmt. getString (1); 11 el valor devuelto (primer parámetro) es una cadena de caracteres 11 Acabado - cierra la conexión dbconn. clase () ;
Obsérvese que las invocaciones a las llamadas del procedimiento almacenado o de la función almacenada en las cadenas de caracteres de las instrucciones van encerradas entre llaves. Los parámetros de entrada pasados a un procedimiento almacenado o a una función almacenada se manejan exactamente igual que los parámetros para las instrucciones preparadas. Los parámetros de salida de los pro'cedimientos almacenados necesitan algún artilugio nuevo: la llamada al método registerOutParameter (J para especificar los tipos de datos y las llamadas a los métodos get (J para recuperar su valor tras concluir la llamada. Se resumen en la Tabla 19.19. Los parámetros de entrada y salida para los procedimientos almacenados necesitan tanto que los valores se pasen en la llamada al procedimiento, empleando los métodos set (J, como que el tipo de datos de la salida se especifiquen con registerOutParameter (), y que los datos devueltos se recuperen con los métodos get ( ) .
Para las funciones almacenadas sólo hay parámetros de entrada y se vuelven a utilizar una vez más los métodos set ( ) . El valor devuelto de la función se especifica con un marcador de parámetro en la cadena de caracteres de la instrucción preparada. Se registra su tipo de datos y se recupera su valor, igual que si fuera un parámetro normal de salida. Manejo de errores en JDBC
Cuando se produce un error durante una operación de JDBC, la interfaz de JDBC genera una excepción de Java. La mayor parte de los errores de ejecución de SQL generan una SQLException. El error puede manejarse mediante el mecanismo estándar de Java try I catch. Cuando se produce un error SQLException, se llama al método catch () con un objeto SQLException, parte de cuyos métodos se resumen en la Tabla 19.20. Los métodos SQLException permiten recuperar el mensaje de error, el código de error SQLSTATE y el código de error específico del SGBD asociado con el error. Es posible que una operación de JDBe cree más de un error. En este caso, los errores se ponen a disposición del programa en orden. La llamada a getNextException () en el primer error comunicado devuelve una SQLException para la segunda excepción, y así hasta que no haya más excepciones que manejar. . Cursores con desplazamiento y actualizables en JDBC
Igual que se han añadido los cursores con desplazamiento al estándar SQL de ANSI! ISO, los cursores con desplazamiento se han añadido a los conjuntos de resultados de JDBC en versiones posteriores de la especificación. Se indica al método executeQuery que se desea que una consulta genere resultados con posibilidad de desplazamiento mediante un parámetro. Si se especifica desplazamiento, el ResultSet devuelto por la llamada a executeQuery ofrece algunos métodos adicionales para el control de los cursores. Los métodos importantes se relacionan en la Tabla 19.21. Además de los conjuntos de resultados con desplazamiento, las versiones posteriores de la especificación JDBC añadieron soporte para los conjuntos de resultados
Tabla 19.20.
Métodos JDBC de SQLException
Método
Descripción
getMessage()
Recupera el mensaje de error que describe la excepción.
getSQLState()
Recupera el valor de SQLSTATE (cadena de caracteres de cinco caracteres, como se describe en el Capítulo 17).
getErrorCode{J
Recupera un código de error específico del controlador o del
SGBD. getNextException()
Se desplaza a
la siguiente excepción
de SQL de
una
serie.
692
SOL. Manual de referencia
Tabla 19.21.
Capítulo 19: Las API de SOL
Métodos JOSe de cursor ampliados del objeto ResultSet
Función
Tabla 19.21.
693
Métodos JDBC de cursor ampliados del objeto ResultSet (continuación)
Descripción Función
Descripción
updateTime()
Actualiza el valor de una columna de horas.
updateTimeStamp{)
Actualiza el valor de una columna de marcas temporales.
DespLazamiento de Jos cursores de desplazamiento
previous ()
Desplaza el cursor a la fila anterior de resultados de la consulta.
beforeFirst ()
Desplaza el cursor antes del inicio de los resultados.
updateByte (1
Actualiza el valor de una columna de bytes.
first ()
Desplaza el cursor a la primera fila de resullados de la consulta.
upda teBytes ( )
Actualiza el valor de una columna de longitud fija o variable.
updateBigDecimal()
Actualiza el valor de una columna DECIMAL o NUMERIC.
updateNull ()
Actualiza una columna con un valor NULL.
updateObject ()
Actualiza un valor arbilrario de una columna.
last()
Desplaza el cursor a la última fila de resultados de la
cansulla. afterLast()
Desplaza el cursor más allá del final de los resultados.
absol u te ( )
Desplaza el cursor al número de fila absoluto indicado.
relative ()
Desplaza el cursor al número de fila relativo indicado.
ldencificación de la posición de los cursores
isFirst()
Determina si la fila en curso es la primera fila del conjunto de resultados.
isLast ()
Determina si la fila en curso es la última fila del conjunto de resultados.
isBeforeFirst{)
Determina si el cursor se ubica antes del comienzo del conjunto de resullados.
isAfterLast ()
Determina si el cursor se ubica más allá del final del conjunto de resultados.
moveToInsertRow()
Desplaza el cursor a una fila «vacía» para la inserción de datos nuevos.
moveToCurrentRowl)
Vuelve a desplazar el cursor a la fila en curso antes de una inserción. .
Actualización de columnas de lafila actual (mediante cursores)
updateInt ()
Actualiza el valor de una columna entera.
updateShort(1
Actualiza el valor de una columna entera corta.
updateLong ()
Actualiza el valor de una columna entera larga.
updateFloat ()
Actualiza el valor de una columna de coma flotante.
updateDouble {l
Actualiza el valor de una columna de coma flotante de doble precisión.
updateString 11
Actualiza el valor de una columna de cadenas de caracteres.
updateBoolean (1
Actualiza el valor de una columna verdadera/falsa..
updateDate()
Actualiza el valor de una columna de fechas. (continúa)
actualizables. Esta posibilidad se corresponde con la posibilidad UPDATE...WHERE CURRENT QF de SQL incorporado. Permite la actualización de columnas concretas de "a fila, que viene indicada por la posición actual del cursor. Los conjuntos de resultados actualizables permiten también que se inserten nuevas filas de datos en la tabla mediante un conjunto de resultados. Recuperación de metadatos con JDBC La interfaz de JDBC proporciona objetos y métodos para la recuperación 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 método getMetaData (), devuelve un objeto DatabaseMetaData, que se describe en la Tabla 19.22. Cada método relacionado en la tabla devuelve un conjunto de resultados, que contiene información 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 métodos de acceso a los metadatos proporcionan información sobre el nombre del producto de base de datos incorporado en esa conexión, su número de versión y otra información parecida. La información de los metadatos sobre los resultados de las consultas puede resultar también muy útil. Los objetos ResultSet proporcionan un método getMetaData que puede invocarse para obtener una descripción de los resultados de -sus consultas. El método devuelve un objeto ResultSetMetaData, que se describe en la Tabla 19.23. Los métodos permiten determinar el número de columnas que hay en los resultados de las columnas y el nombre y el tipo de datos de cada columna, identificada por su posición ordinal en los resultados de la consulta. Finalmente, la información de los metadatos sobre los parámetros utilizados en las instrucciones de SQL preparadas, o las llamadas preparadas a procedimientos almacenados, también puede resultar útil. Los objetos PreparedStatement y
694
SOL. Manual de referencia
Tabla 19.22. Métodos de DatabaseMetaData para la recuperación de información de la base de datos
Capítulo 19: Las A?I de SOL
Tabla 19.24.
695
Métodos JDBC de ParameterMetaData
Función
Descripción
Función
Descripción
getTables()
Devuelve el conjumo de resultados de la información de las tablas de la base de dalos.
getParameterClassName()
Devuelve el nombre de la clase (tipo de datos) del parámetro especificado.
Devuelve el conjunto de resullados de la información
getParameterCount()
Devuelve el número de parámetros de la instrucción.
getColumns ()
del nombre y tipo de las columnas, dado el nombre de la labia.
getPrimaryKeys{)
Devuelve el conjunto de resultados de la información de clave primaria, dado el nombre de la tabla.
getProcedures(I
Devuelve el conjunto de resultados de la información sobre los procedimientos almacenados.
getProcedureColumns()
Devuelve el conjunto de resultados de la información sobre los parámetros de un procedimienlo almacenado concreto.
eallableStatement proporcionan un método getParameterMetaData () que recupera esa información. El método devuelve un objeto ParameterMetaData,
que se describe en la Tabla 19.24. Acogerse a los métodos de este objeto proporciona infonnación sobre el número de parámetros empleados en la instrucción, sus tipos de datos, si cada parámetro es un parámetro de entrada, de salida o de entrada y salida, y otra infonnación parecida. Posibilidades avanzadas de JDBC
JDBC 2.0 y JDBC 3.0 introdujeron varias posibilidades que ampliaban la funcionalidad básica de acceso a las bases de datos de JDBC. Los orígenes de datos de JDBC, introducidos por primera vez en JDBC 2.0, proporcionan un método de nivel superior para la búsqueda de controladores y bases de datos disponibles y la conexión con ellas. Enmascaran los detalles del establecimiento de conexiones del programador de aplicaciones de Java. Básicamente, los orígenes de datos se iden-
Tabla 19.23.
Métodos de ResultSetMetaData
Función
Descripción
getColumnCount()
Devuelve el número de columnas de los resultados de la columna.
getColumnName()
Recupera el nombre de la columna de resultados especificada.
getColumnType()
Recupera el tipo de datos de la columna de resultados especificada.
getParameterMode()
Devuelve el modo (IN, OUT, INOUT) del parámetro.
getParameterType()
Devuelve el tipo de datos de SQL del parámetro especificado.
getParameterTypeName()
Devuelve el tipo de datos del SGBD del parámetro especificado.
getPrecision()
Devuelve la precisión del parámetro especificado.
getScale ()
Devuel ve la escala del parámetro especificado.
iSNullable ()
Determina si el parámetro especificado puede tener valores oull.
isSigned ()
Determina si el parámetro especificado es un número con signo.
lifican con algún directorio o catálogo externo que es capaz de traducir los nombres lógicos de las entidades a detalles específicos. Empleando orígenes 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 amplían 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 información sobre la base de datos de origen subyacente, la conexión con la base de datos, su nombre de usuario y contraseña, 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 desconexión y pueden emplearse para reestablecer una conexión con la base de datos. Cuando los conjuntos de filas están conectados con las bases de datos, pued~n contener resultados de consultas como los conjuntos de resultados. Los conjuntos de filas tienen otras características y posibilidades. Los conjuntos de filas cumplen los requisitos para los componentes JavaBeans y, cuando están 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 desconexión, queda implícita la resincronización cuando se
696
saL
Capítulo 79: Las API de SOL
Manual de referencia
697
• 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 característica añadida. 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.
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, teóricamente, de cualquier origen de datos tabular, como las hojas de cálculo 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; véase la documentación sobre JDBC en hllp:/ /www.java.sun.com/products/jdbc/paraobtenermás infonnaci6n sobre ésta y otras posibilidades de JDBC.
Resumen Muchos productos de SGBD basados en SQL proporcionan una API Ilamable para el acceso a las bases de datos mediante programación: • En función 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 método principal mediante el cual los programas de aplicación tienen acceso a las bases de datos. • La interfaz llamable pone en la interfaz de llamadas el procesamiento de consultas, el paso de parámetros, la compilación de instrucclones, la ejecución de instrucciones y otras tareas parecidas, conservando el lenguaje SQL de programación idéntico a SQL interactivo. Con SQL incorporado, estas tareas están a cargo de instrucciones especiales de SQL (OPEN, FETCH, CLOSE, PREPARE, EXECUTE, etc.), que son exclusivas de SQL de programación. • La ODBC de Microsoft es una API llamable, ampliamente admitida, que proporciona una manera efectiva para que los programas de aplicación 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 estándar 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 bistórico de ODBC. • Para los programas de Java, la interfaz IDBe es la API llamable estándar industrial de facto, admitida por todos los principales productos de SGBD y definida como la API de gestión de bases de datos en el estándar Edición 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 características básicas, pero 'varían espectacularmente en cuanto a las características ampliadas que ofrecen y a los detalles de las llamadas y las estructuras de datos que emplean.
1
]
i j
¡ I
I
I
Parte VI
-
Sal HOY Y MANANA
1¡
, ,I
,
La influencia de SQL continúa en aumento dado que nuevas capacidades y desarrollos afrontan nuevos tipos de requisitos para gestión de datos. Los capítulos 20 al 25 describen varias de estas nuevas áreas. El Capítulo 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 Capítulo 21 examina el papel de SQL en el auálisis de datos y la tendencia a crear almacenes de datos basados en SQL. El Capítulo 22 describe el papel de SQL en la creación de sitios web interactivos, y especialmente su relación con la tecnología de servidores de aplicaciones. El Capítulo 23 estudia cómo se usa SQL para crear bases de datos distribuidas que explotan la potencia de las redes informáticas. El Capítulo 24 estudia una de las áreas más importantes de la evolución de SQL: la interacción entre SQL y las tecnologías orientadas a objetos y la nueva generación de bases de datos relacionales orientadas a objetos. El Capítulo 25 se enfoca en la relación entre SQL y una de las más importantes de estas tecnologías, XML, y la arquitectura emergente de servicios web en Internet basada en XML. Finalmente, el Capítulo 26 resalta las tendencias clave que dirigirán la evolución de SQL a lo largo de esta década.
J
CAPíTULO
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 básicamente s6lo gestionaban el almacenamiento de los datos y la recuperación; las aplicaciones eran responsables de la navegación por la base de datos, la ordenación y selección de los datos y la gestión de todo el procesamiento de datos. Con la llegada de las bases de datos relacionales y SQL, el SGBD tomó mayores responsabilidades. La búsqueda y ordenación de la base de datos se integraba en las cláusulas del lenguaje SQL y era proporcionado por el SGBD, junto con la capacidad de resumir los datos. La navegación explícita por la base de datos se convirtió en innecesaria. Posteriores mejoras de SQL, tales como las claves principales y externas y las restricciones de comprobación, continuaron la tendencia, tomando la responsabilidad de las funciones de comprobación de los datos y su integridad, que eran responsabilidad de las aplicaciones en implementaciones SQL anteriores. En cada paso, el SaBD adoptó más responsabilidad proporcionada por el control centralizado y se redujo la posibilidad de la corrupción de los datos debido a errores en la programación de la aplicación. En muchos departamentos de tecnologías de la información (IT, lnformation Technology) en grandes compañías y organizaciones, esta tendencia del SGBD siguió una tendencia organizativa. La base de datos corporativa y los datos que contenía tenían que ser vistos como un bien corporativo principal, y en muchos departamentos IT emergió un grupo de administración 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 compañía, podrían desarrollar aplicaciones, informes, consultas u otra lógica 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 características importantes de las bases de datos relacionales a escala empresarial moderna (los procedimientos almacenados y los disparadores) han repre-
701
702
SOL Manual de referencia
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 lógica de la aplicación para que acepte el pedido de un cliente o transferir dinero de una cuenta bancaria a mea. Los disparadores se utilizan para invocar automáticamente el procesamiento de un procedimiento almacenado basado en condiciones que se dan lugar en la base de datos. Por ejemplo, un disparador puede transferir automáticamente fondos de una cuenta de ahorro a una cuenta corriente si ésta está en números rojos. Este capítulo describe los conceptos principales de los procedimientos almacenados y disparadores, y su implememación 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 años noventa y en la presente década. Un tratamiento completo de la programación de los procedimientos almacenados y disparadores excede el alcance de este libro, pero los conceptos y comparaciones proporcionarán una comprensión de las capacidades principales y un fundamenlO para comenzar el uso de capacidades específicas del software SGBD. Los procedimientos almacenados y disparadores básicamente extienden SQL a un lenguaje de programación completo, por lo que en este capítulo se considera que se está familiarizado con los conceptos de programación básicos.
Conceptos de los procedimientos almacenados En su forma inicial, SQL no se consideraba un lenguaje de programación completo. Se diseñó e implementó corno un lenguaje para expresar las operaciones de bases de datos .....:.....creación de estructuras de bases de datos. introducción de datos en la base de datos, actualización de la base de datos- y, especialmente, para ex.p~esar consultas de la base de datos y recuperar las respuestas. SQL se podía 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 también se podía incorporar en otro lenguaje de programación, 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 programación están incorporadas en el lenguaje SQL. Las secuencias de ~ns~rucciones SQL extendidas se agrupan para formar programas SQL o procedImientos. La forma específica varía de una implementación a otra, pero generalmente se proporcionan las siguientes capacidades: •
E~ecución condicional. Una estructura IF...THEN_.ELSE permite un procedimIento. SQL para comprobar una condición y llevar a cabo distintas operaciones dependiendo del resultado.
Capítulo 20: Procesamiento de bases de datos y procedimientos...
703
• Bucles. Un bucle WHILE o FOR o estructura similar permite una secuencia de operaciones SQL a ejecutar repetidamente, hasta que se cumple una condición de terminación. 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 instrucción fuera una única instrucción. • 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 después recuperar el valor almacenado para usarlo en cálculos posteriores. • Procedimientos con nombre. Una secuencia de instrucciones SQL se puede agrupar, dándole un nombre y asignando parámetros formales de entrada y salida, como una subrutina o función en un lenguaje de programación convencionaL Una vez definido el procedimiento de esta forma, se puede llamar por su nombre, pasando los valores apropiados en los parámetros de entrada. Si el procedimiento es una función 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 operación SQL requerida por una aplicación (ejecutándose en el sistema de la computadora cliente) debía enviarse por la red al servidor de la base de datos, y había que esperar el mensaje de respuesta a través de la red. Si una transacción lógica requería seis operaciones SQL, debían realizarse seis viajes por la red. Con los procedimientos almacenados se podía programar la secuencia de seis operaciones SQL en un procedimiento y almacenarlo en la base de datos. 'La aplicación solicita simplement~ la ejecución 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 ejecución 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. Rápidamente 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 más 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·
n 704
SOL. Manual de referencia
lrucluras del SPL en construcciones de lenguaje e o Pascal. Otros han imentado ajustar el estilo del lenguaje de manipulación de datos (LMD) y del lenguaje de definición de datos (LDD). Como resultado, mientras que los conceptos del procedimiento almacenado son muy similares entre dialectos SQL, la sintaxis específica varía considerablemente.
Un ejemplo básico Es más fácil 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 número de cliente, nombre, límite de crédito 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.
Sin la posibilidad de usar procedimientos almacenados, ésta es la secuencia de instrucciones SQL que realiza este trabajo para Empresa XYZ, nuevo número de cliente 2137, con un límite de crédito de 30.000 € Y unos objetivos del primer año de 50.000 € a asignar por Pablo Cruz (empleado número 103), de la oficina de Castellón: INSERT INTO VALUES UPDATE SET WHERE UPDATE SET WHERE COMMIT;
Capitulo 20: Procesamiento de bases de datos y procedimientos...
¡' Procedimiento para agregar un cliente ,¡ create procedure agregar_cliente ¡, nombre del cliente, nombre_c in varchar{201. entrada ,¡ ¡, número del cliente, num_c in integer. entrada *1 ¡, límite de crédito. lim_cred in number(16,2}, entrada '¡ obj_ven in number{16,21, ¡' objetivo de ventas. entrada • ¡ rep_c in integer. ¡' número 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;
1* Actualizar la fila de la tabla OFICINAS ·1 update oficinas set objetivo = objetivo + obj_ven where ciudad = afic_c; l· Comprometer la transacción y terminar ·1 commit; end;
Figura 20.1.
Procedimiento almacenado básico en PLJSQL.
Una vez que se ha creado este procedimiento en la base de datos, una instruc, ción como la siguiente: AGREGAR_CLIENTE('Empresa XYZ'. . Castel16n' )
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 parámetros (nombre del cliente, número, límite de crédito y objetivo de ventas, número de empleado del representante asignado y ciudad donde está ubicada la oficina de" ventas).
705
2137,
30000.00,
50000.00,
103,
llama al procedimiento almacenado y pasa los seis valores especificados como parámetros. El SGBD ejecuta el procedimiento almacenado, llevando a cabo cada instrucción SQL en la definición del procedimiento, una a una. Si el.procedimiente AGREGAR_CLIENTE completa su ejecución satisfactoriamente, se ha realizado una transacción asistida por el SOBD. Si no, el código de error y el mensaje devueltos indican lo que fue mal.
706
SOL. Manual de referencia
Capítulo 20: Procesamiento de bases de datos y procedimientos...
Uso de los procedimientos almacenados El procedimiento definido en la Figura 20.1 ilustra varias estructuras comunes básicas a todos los dialectos SPL. Casi todos los dialectos utilizan una instrucción CREATE PROCEDURE para definir inicialmente un procedimiento almacenado. La instrucción DROP PROCEDURE correspondiente se utiliza para descartar procedi-
mientos que no son necesarios. L{t instrucción guiente:
CREATE PROCEDURE
define lo si-
• El nombre del procedimiento almacenado. • El nombre y tipos de datos de sus parámetros. • 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 ejecución en el cuerpo del procedimiento almacenado.
Creación de un procedimiento almacenado En muchos dialectos comunes SPL se utiliza la instrucción CREATE PROCEDURE para crear un procedimiento almacenado y especificar cómo opera. La instrucción CREATE PROCEDURE asigna un nombre al procedimiento recién 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 más parámetros como argumentos. (Éste tiene seis parámetros: C_NOMBRE, NUM_C, LIM_CREDI, OBJ_VEN, REP _C y OFIe_c.) En todos los dialectos SPL comunes, los valores de los parámetros aparecen en una lista separada por comas, encerradas entre paréntesis; seguidamente, el nombre del procedimiento cuando se llama al procedimiento. La cabecera de la definición del procedimiento almacenado especifica los nombres de los parámetros 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 parámetros. En la Figura 20.1 todos los parámetros son parámetros de entrada (input en inglés, 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 parámetros los valores especificados en la llamada al procedimiento y se comienzan a ejecutar las instrucciones en el cuerpo del procedimiento. Los nombres de los parámetros pueden aparecer en el cuerpo del procedimiento (y particularmente en las instrucciones SQL estándar en el cuerpo del procedimiento) en cualquier lugar en que pueda apárecer una constante. Cuando aparece el nombre de un parámetro, el SGBD utiliza su valor en curso. En la Figura 20.1 se utilizan los parámetros en la instrucción IN5ERT y en la instrucción UPDATE, ambos como valores de datos a utilizar en los cálculos de columna y condiciones de búsqueda.
707
Además de los parámetros de entrada, algunos dialectos SPL incorporan parámetros de salida (output en inglés). Permiten devolver a un procedimiento almacena~ do valores que calcula durante su ejecución. Los parámetros de salida no son útiles para los procedimientos almacenados invocados desde SQL interactivo, pero proporcionan una capacidad importante para devolver información de un procedimiento almacenado a otro procedimiento almacenado que 10 llama. Algunos dialectos SPL albergan parámetros que operan tanto como parámetros de entrada como de salida. En este caso los parámetros pasan un valor al procedimiento almacenado, y cualquier cambio en el valor durante la ejecución del procedimiento se refleja en el procedimiento que lo llama. La Figura 20.2 muestr.a la definición del mismo procedimiento AGREGAR_ CLIENTE expresado en el dialecto Transact-SQL de Sybase {SQL Server de Mi-
/Y Procedimiento para agregar un cliente */ crea te proc agregar_cliente /y nombre del cliente, @nombre_c varchar(20}, entrada */ /* número del cliente, @num_c integer, entrada */ /* límite de crédito, @lim_cred money, entrada */ /* objetivo de ventas, @obj_ven money, entrada */ /* número 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 transacción y finalizar */ commit trans end
Figura 20.2.
Procedimiento AGREGAR_CLIENTE en PL/SQL.
70S
Capítulo 20: Procesamiento de bases de datos y procedimientos...
SOL. Manual de referencia
erosaft también utiliza el dialeclO Transacl-SQL; sus fundamentos han cambiado mucho desde la versión original SQL Server de Sybase, en la cual se basaron las líneas de producto Microsoft y Sybase). Obsérvese las diferencias con el dialecto de Oraele:
709
/~ Procedimiento para agregar un cliente */ crea te procedure agregar_cliente nombre_c varchar(20), /~ nombre del cliente, entrada */ num_c integer, /* número del cliente, entrada */ lim_cred money(16,2}, /* límite de crédito, entrada */ obj_ven money(16,2), /* objetivo de ventas, entrada */ rep_c integer, /* número de empleado del representante, entrada *1 1* ciudad de la oficina, of~c_c varchar(lS)} entrada */
• La palabra clave PROCEDURE se puede abreviar por PROC. • No hay una lista enlre paréntesis de parámetros que sigue al nombre del pro~ cedimiento. En su lugar las declaraciones de los parámetros siguen inmediatamente al nombre del procedimiento almacenado. • Todos los nombres de los parámetros 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 instrucción Transact-SQL. Si se necesita más de una instrucción, se utiliza la estructura de bloques de Transact-SQL para agrupar las instrucciones.
La Figura 20.3 muestra el procedimiento AGREGAR_CLIENTE de nuevo, esta vez expresado en el dialecto de procedimientos almacenado de Informix. La declaración de la cabecera del procedimiento y los parámetros son muy parecidos al dialecto de Oracle. Al contrario que en el ejemplo de Transact-SQL. las variables locales y los parámetros utilizan normalmente identificadores SQL como sus nom~ bres, sin ningún símbolo especial de identificación. La definición del procedimiento se finaliza formalmente con una cláusula END PROCEDURE, que hace que la sintaxis sea menos susceptible de errores. En todos los dialectos en que se utiliza la instrucción CREATE PROCEDURE el procedimiento se puede eliminar, cuando ya no sea necesario, mediante una instrucción DROP PROCEDURE:
/* Actualizar fila de la tabla REPRESENTANTES update representantes set cuota ~ cuota + cuota + obj_ven where num_empl : rep_c;
~I
limite_creditol
~/
/* Actualizar fila en la tabla OFICINAS */ update oficinas set objetiva : objetivo + obj_ven where ciudad : ofic_c;
/* Comprometer la transacci6n y finalizar */ commit transaction; end procedure;
DROP PROCEDURE AGREGAR_CLIENTE
Figura 20.3.
Procedimiento AGREGAFLCLIENTE en SPL de Informix.
Llamada a un procedimiento almacenado Se especifican los valores a utilizar por los parámetros del procedimiento, por orden, en una lista que se encierra entre paréntesis. Cuando se llama desde otro procedimiento O disparador, se puede omitir la instrucción EXECUTE, y la llamada se convierte simplemente:
Una vez definido el procedimiento almacenado mediante una instrucción CREATE PROCEDURE se puede utilizar. Una aplicación puede solicitar la ejecución del procedimiento almacenado utilizando la instrucción SQL adecuada. Otro procedimiento almacenado puede llamarlo para que ejecute una función específica. El procedimiento almacenado también se puede invocar mediante una interfaz SQL interactiva. Los distintos dialectos SQL difieren en la sintaxis específica utilizada para llamar a un procedimiento almacenado. A continuación se muestra una llamada a un procedimiento AGREGAR_CLIENTE en el dialecto PUSQL: EXECUTE AGREGAR_CLIENTE('Empresa XYZ', 2137, . 103, 'Castel16n')
30000.00,
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. 'Castellón'
50000.00,
L
2137,
30000.00. 50000.00,
710
I
No se necesitan los paréntesis, y los valores a utilizar en los parámetros forman de nuevo una lista separada por comas. La palabra clave EXECUTE se puede abreviar a EXEC, y los nombres de los parámetros se pueden especificar explícitamente en la llamada, permitiendo especificar los valores del parámetro en el orden deseado. A continuación se muestra una llamada alternativa equivalente en Transacl-SQL del procedimiento almacenado AGREGAR_CLIENTE: EXEC AGREGAR_CLIENTE @C_NOMBRE @NUM_C
@LIM_CRED @OFIC_C @REP_C @OBJ_VEN
Capitulo 20: Procesamiento de bases de datos y procedimientos...
,
SOL. Manual de referencia
711
/. Comprobar el pedido total de un cliente ./ create proc comprobar_total @num_c integer /* un parámetro de entrada ./ as /* Declarar dos variables locales */ declare @tot_pedido money. @texto_mensaje varchar(30)
'Empresa XYZ',
2137,
begin /. Calcular los pedidos totales de un cliente */ se1ect @tot-pedido : sum(importeJ from pedidos where cliente = @num_c
30000.00, 'Castellón' . 103.
50000.00
La fonna en SPL de Informix de la misma instrucción
EXECUTE
es:
/. 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"
De nuevo, los parámetros están encerrados en una lista entre paréntesis, separados por comas. Esta forma de la instrucción 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 instrucción equivalente:
/* Más procesamiento para el texto del mensaje ./
end
Figura 20.4. CALL AGREGAR_CLIENTE ( 'Empresa XYZ', . Castellón' l
2137,
30000.00,
Uso de variables locales en Transact-SQL.
50000.00.103 •
Variables de los procedimientos almacenados Además de los parámetros pasados a un procedimiento almacenado, suele ser conveniente o necesario definir otras variables que alberguen valores intermedios durante la ejecución de los procedimientos. Todos los dialectos de procedimientos almacenados proporcionan esta capacidad. Normalmente las variables se declaran al comienzo del cuerpo del procedimiento, justo después 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 número de cliente específico y establece un mensaje u otro dependiendo de si la cantidaD del pedido total está por encima o por debajo de 30.000 €. Nótese que los nombres de las variables locales de Transact-SQL, al igual que los nombres de los parámetros, comienzan con un signo arroba (@). La instrucción 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 instrucción SELECT asume la función adicional de asignar valores a las variables. Una forma sencilla de este uso de SELECT es la asignación del mensaje de texto: SELECT @TEXTO_MENSAJE :
"total de los pedidos alto"
Un ejemplo más complejo es la asignación 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 versión SPL de Informix del ffilsmo procedllruento almacenado. Hay varias diferencias con la versión Transact-SQL: • Las variables locales de declaran mediante la instrucción DEFINE. Este ejemplo muestra solamente un subconjunto muy limitado de las opciones que están disponibles. • Los nombres de las variables son identificadores SQL normales; no hay un . ' primer carácter especial. • Se utiliza en SPL una instrucción SELECT INTO especial para aSIgnar el resultado único de una instrucción SELECT a una variable local.
712
SOL Manual de referencia
Capítulo 20: Procesamiento de bases de datos y procedimientos...
/* Comprobar el total de los pedidos de un cliente */ crea te procedure chk_tot (num_c integerl
/* 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);
1* Calcular los pedidos totales para el cliente solicitado */ select sum(importe) into tot._pedido fram pedidos where cliente ~ nuro_e;
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, según el total "¡ i f tot._pedido > 30000.00 let texto_mensaje == "total de los pedidos alto"
/* 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';
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 instrucción variables.
LET
713
Uso de variables locales en Pl/SGL de Oracle.
proporciona asignaciones sencillas de los valores de las
La Figura 20.6 muestra la versión 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 sección DECLARE separada. Esta sección es realmente una parte integral de la estructura de bloque BEGIN ... END; declara las variables locales para su uso en el bloque. • La instrucción 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 asignación utilizan la notación de Pascal (: =) en lugar de una instrucción 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 ejecución de la instrucción. Además, las variables locales pueden ser destino para los datos derivados de expresiones o consultas SQL, como se muestra en los ejemplos anteri"ores.
Bloques de instrucciones
I
Es normalmente necesario en los procedimientos almacenados, excepto en los más sencillos, agrupar una secuencia de instrucciones SQL de forma se traten como si fuera una única instrucción. Por ejemplo, en la estructura IF ... THEN ... ELSE, utilizada normalmente para controlar el flujo de la ejecución de un procedimiento al~ macenado, la mayor parte de dialectos de procedimientos almacenados esperan una única instrucción seguida de la palabra clave THEN. Si tÍn procedimiento requiere ejecutar una secuencia de varias instrucciones SQL cuando la condición de comprobación es verdadera, se deben agrupar las instrucciones como un bloque de instrucción, y este bloque aparecerá después 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 función 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
Capítulo 20: Procesamiento de bases de datos y procedimientos...
SOL. Manual de referencia
La definición del procedimiento Transact-SQL, las construcciones de ejecución 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 continuación se muestra la estructura de un bloque de instrucciones Informix SQL: I~
Bloque de instrucciones SPL de Informix I~ Declaración de variables locales */ define . . .
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 ejecución condicional y los bucles tienen sus propios marcadores de fin de instrucción autodefinidos, por lo que las secuencias de instrucciones en estas estructuras no necesitan una estructura de bloques BEGIN ... END explícita.
Devolución de un valor
~I
/* Declaración de la gestión de excepciones */ on exception
/* Definir la secuencia de instrucciones SQL */ begin.
end
La sección de declaración de variables es opcional; ya hemos visto un ejemplo ) de ello en el cuerpo del procedimiento almacenado lnformix, en la Figura 20.5. La sección de gestión de excepciones también es opcional; su funci6n se describe posteriormente en la sección «Manejo de condiciones de error». La secuencia BEGIN •.. END realiza la misma funci6n en Transact-SQt. Informix también 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 instrucción tan frecuentemente como las otras estructuras Transact-SQt. En el dialecto Informix, las instrucciones de ejecuci6n condicional de bucles incluyen una / terminaci6n explícita (IF ... E~D 1F, WHILE ... END WHILE, FOR ... END FOR). En la estructura puede aparecer una única instrucción 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 excepción mediante el siguiente formato: /* Bloque de instrucciones PL/SQL de Oracle */ /* Declaración de variables locales */
declare /* Secuencia de instrucciones */ begin .
Además de los procedimientos almacenados, la mayor parte de los dialectos SPL incorporan las funciones almacenadas. La diferencia es que una función almacenada devuelve un valor, mientras que un procedimiento almacenado no. Veamos un sencillo ejemplo de función almacenada. Consideremos que se desea definir un procedimiento almacenado que, dado un número de cliente, calcule la cantidad total del pedido en curso para dicho cliente. Si se define el procedimiento como función, se puede devolver la cantidad total. La Figura 20.7 muestra una función almacenada en Gracle que calcula la cantidad total de pedidos en curso para un cliente, dado un número de cliente. N6tese la cláusula RETURNS en la definición del procedimiento, la cual dice el tipo de datos del SOBD del valor a devolver. En la mayoría de los productos SOBD, si se introduce una llamada de funci6n mediante SQL interactivo, se muestra el valor de la función como respuesta. En un procedimiento almacenado, se puede llamar a una función almacenada y utilizar su valor devuelto en los cálculos o almacenarlo en una variable.
/* 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 función */ return tot_pedido; end;
/* Declaración de la gestión de excepciones */ exception
end;
715
Figura 20.7.
Función almacenada de Pl/SQL de Oracle.
716
SOL. Manual de referencia
Capítulo" 20: Procesamiento de bases de datos y procedimientos...
Muchos dialectos SPL también permiten utilizar una función almacenada como una función 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 función definida en la Figura 20.? en una condición de búsqueda es legal. SELECT FROM WHERE AND
EMPRESA, NOMBRE CLIENTES, REPRESENTANTES REP_CLI : NUM_EMPL OBTENER_TOT_PEDIDOS(NUM_CLII
>
10000.00
Puesto que el SGBD evalúa la condición de búsqueda para cada fila de los resultados preliminares de la consulta, utiliza el número de cliente de la fila candidata actual como argumento para la función OBTENER_TOT_PEDIDOS y se comprueba si excede el umbral de 10.000 €. Esta misma consulta se podría expresar como una consulta agrupada. con la tabla PEDIDOS también incluida en la cláusula FROM y los resultados agrupados por cliente y representante. En muchas implementaciones. el SOBD realiza la consulta agrupada más 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 definición SPL de Informix para la misma función almacenada mostrada en la Figura 20.7. Excepto por variaciones de estilo, difiere ) muy poco de la versión 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 explícitamente un código de estado y utilizan una instrucción RETURN para este propósito. Sin embargo, el valor devuelto siempre es un valor de estado entero. Un valor cero indica la terminación satisfactoria del procedimiento almacenado; un
/* Devolver el importe total de los pedidos de un cliente */ create function obtener_tot_pedidos{num_c in integer) returning money(16,2)
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 asignación de la instrucción EXECUTE: declare sts_val int execute sts_val agregar_cliente 'Empresa XYZ'. 50000.00, 103, 'CasteIlón'
2137.
30000.00.
Devolución de valores por parámetros La capacidad de función almacenada proporciona solamente la posibilidad de devolver un único valor de una rutina almacenada. Varios dialectos de procedimientos almacenados proporcionan un método para devolver más de un valor, lo que permite enviar los valores a la rutina que la llama mediante parámelros de salida. Los parámetros de salida se listan en la lista de parámetros del procedimiento almacenado, al igual que los parámetros 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 parámetros 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 número de cliente. El procedimiento tiene cuatro parámetros. El primero, NUM_C. es un parámetro de entrada y proporciona el número de cliente solicitado. Los otros tres parámetros son parámetros de salida. utilizados para pasar los datos al procedimiento que 10 llama. En este sencillo ejemplo, la forma
/* Devuelve el valor recuperado como valor de la función */ 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 información *{ 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:
Figura 20.9.
/* 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;
Una función almacenada SPL de lnformix.
717
Procedimiento almacenado Pl/SQL con parámetros de salida.
718
Capítulo 20: Procesamiento de bases de datos y procedimientos...
SOL. Manual de referencia
SEL"ECT INTO de la consulta ubIca las variables devueltas directamente en los parámetros de salida. En un procedimiento almacenado más complejo, los valores devueltos pueden ser calculados y ubicados en los parámetros de salida con una instrucción de asignación PUSQL. Cuando se llama a un procedimiento almacenado con parámetros de salida, el valor pasado para cada parámetro de salida debe ser un objetivo aceptable que pueda recibir un valor devuelto. El objetivo puede ser una variable local, por ejemplo, o un parámetro de un procedimiento de un nivel superior que llama a un procedimiento de nivel inferior para que realice alguna tarea. A continuación 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 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 información ./ 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;
/. Obtiene la información 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);
Por supuesto, no sería usual llamar a este procedimiento con un número de cliente literal, pero es perfectamente legal, puesto que hay un parámetro de entrada. Los tres parámetros restantes tienen objetivos de asignación 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:
Figura 20.10.
/. Obtiene la información 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
Procedimiento almacenado Transact·SQL con parámetros de salida.
La Figura 20.11 muestra la versión SPL de Informix del mismo ejemplo de procedimiento almacenado. Informix adopta un enfoque diferente para gestionar varios valores de salida. En lugar de parámetros de salida, Informix extiende la definición de una función almacenada y permite varios valores devueltos. Por ello, el procedimiento OBTENER_INFO_CLIENTE se convierte en una función en el dia-"
)
/. Obtiene la información de cliente para el cliente 2111 ./ execute obtener_info_cliente(211l, ~Emp XYZ", el_rep, la_ciudad)
debido a que el segundo parámetro es un parámetro de salida y no puede recibir un valor literaL Además de los parámetros de entrada y salida, Oraele permite especificar parámetros del procedimienlo que sean ambos parámetros de entrada y salida (INOUT). Deben obedecer a las mismas restricciones previamente citadas para los parámetros de salida, pero además, sus valores son utilizados por el procedimiento corno entradas. La Figura 20.10 muestra una versión del procedimiento OBTENER_INFO_CLIENTE definida en el dialecto Transacl-SQL. La fonna en que son identificados los parámetros de salida en la cabecera del procedimiento difiere ligeramente de la versión Oraele, y la instrucción de una única fila SELECT tiene una forma distinta. Por otra parte, la estructura del procedimiento y su operación es idéntica a la del ejemplo de Omele. Cuando un procedimiento Transact-SQL llama a éste, el hecho de que el se· gundo, tercer y cuarto parámetros sean parámetros de salida se "debe indicar en la llamada al procedimiento, así como en su definición. A continuación se muestra la sintaxis Transact-SQL para la llamada al procedimiento en la Figura 20.10:
719
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 información */ 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;
Figura 20.11.
Función almacenada Informix con varios valores devueltos.
720
SOL. Manual de referencia
Capítulo 20: Procesamiento de bases de datos y procedimientos...
leeto Informix. Los diversos valores devueltos se especifican en la cláusula RETURNING de la cabecera del procedimiento y entonces se devuelven realmente mediante la instrucción RETURN. La instrucción de Informix CALL que invoca a la función almacenada utiliza una cláusula especial RETURNING para recibir los valores devueltos: /* Obtiene la información de cliente para el cliente 2111 */ define el_nombre varchar(20); define el_rep varchar(15); define la_ciudad varchar(15);
eall obtener_iofo_cliente
(211l)
returning el_nombre, el_rep,
la_ciudad;
Como en el dialecto Transact-SQL, lnformix también permite una versión de la instrucción CALL que pasa los parámetros por nombre: call obtener_info_cliente (num_c : 2111) returning el_nombre, e1_rep,
'1
la_ciudad:
Ejecución condicional Una de las características más básicas de los procedimientos almacenados es la ) construcción 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 límite en el importe según 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 más de 20.000 €, la cuota se tiene que incrementar solamente en 20.000 €. La Figura 20.12 muestra un procedimiento modificado que
ir 1;
r
~
/ ' Procedimiento para agregar un cliente ' / create procedure agregar_cliente nombre_c in varchar{20), / ' nombre del cliente, entrada tI num_c in integer. / ' número del cliente, entrada ' / lim_cred in number(16,2), / ' límite de crédito, entrada ' / obj_ven in number(16,2), /' objetivo de ventas, entrada ' / rep_c in integer. It número de empleado del representante, entrada ' /
Figura 20.12.
Lógica condicional en un procedimiento almacenado. (Continúa.)
ofl.c_c
in varchar{15))
721
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
It Actualiza la fila de la tabla OFICINAS *1 update oficinas set objetivo : objetivo + obj_ven where ciudad ofic_c: 1* Compromete la transacción *1 cornmit; end¡
Figura 20.12.
Lógica condicional en un procedimiento almacenado. (Continuación.)
implementa esta nueva directriz. La lógica IF ... THEN ... ELSE opera exactamente como lo hace en cualquier lenguaje de programación convencional. Todos los dialectos de procedimientos almacenados permiten instrucciones IF anidadas para una toma de decisiones más compleja. Algunos proporcionan lógica condicional extendida para permitir la bifurcación múltiple. 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 año están por debajo de 20.000 €, entre 20.000 € Y50.000 € o por encima de 50.000 €. En PUSQL de Oraele se puede expresar esta decisión 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 */
722
SOL. Manual de referencia
Capítulo 20: Procesamiento de bases de datos y procedimientos...
723
elsif obj_ven < 50000.00 then /* Aquí se gestionan los clientes con objetivo medio */
if (num_elem = elem_especial) then exit for; end for;
else
La otra forma común de bucle se da cuando una secuencia de instrucciones se ejecuta repetidamente mientras existen ciertas condiciones o hasta que exista alguna condición especificada. A continuación se muestra una construcción de bucle PUSQL de Oracle que repite indefinidamente. Este bucle debe, por supuesto, proporcionar una comprobación en el cuerpo del bucle que detecte la condición de terminación del bucle (en este caso, una coincidencia entre dos variables) y salga explícitamente de éste:
/* Aquí se gestionan los clientes con objetivo alto */ end if;
En el dialecto lnforrnix se permite la misma estructura de bifurcación múltiple. La palabra clave ELSIF se convierte en ELIF, pero el resto permanece iguaL
Ejecución repetida Otra característica común a casi todos los dialectos de procedimientos almacenados es una construcción para la ejecución 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 condición de comprobación ejecutada al comienzo o fin del bucle. En el ejemplo de la base de datos es difícil 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 continuación se muestra un bucle PUSQL de Drade que gestiona esta situación: /* Procesa cada uno de los 10 elementos */ for num_elem in l .. 10 loop /* Procesa este elemento particular */
/* 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 instrucción 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 condición de comprobación incorporada, como en este ejemplo. A continuación 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 */
/* Comprueba si finaliza el bucle */
/* Procesa repetidamente algunos datos */ loop /* Realiza un cierto procesamiento cada vez */
/* Comprueba si salir del bucle anticipadamente */ exit when (valor_test = valor_salida): end loop;
Una construcción de bucle más común es una que incorpora el test en la estructura misma del bucle. El bucle se ejecuta repetidamente siempre que la condición 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 múltiplo de 10.000 €. A continuación 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
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 mayoría de los bucles Transact-SQL WHILE incluyen uno. Transact-SQL repite la única instrucción SQL que sigue a la condición de comprobación, como el cuerpo del bucle WHILE. Si el cuerpo del bucle consiste en más de una instrucción, se debe utilizar un bloque BEGIN ... END para agrupar las instrucciones_ A continuación se muestra la versión PUSQL de Oracle del mismo bucle: /* Decrementa los objetivos hasta que el total sea menor que 2.400.000 € */
select sum(objetivol into total_obj while (total_obj < 2400000.00)
trom oficinas;
724
SOL Manual de referencia
Capítulo 20: Procesamiento de bases de datos y procedimientos...
725
Con etiquetas para las instrucciones y para la instrucción GOTO se proporciona control adicional del flujo de ejecución en los procedimientos almacenados. En la mayoría de los dialectos, la etiqueta de la instrucción es un identificador seguido de dos puntos. La instrucción GOTO llama a la etiqueta a la cual se debería transferir el control. Normalmente se da la limitación de que no se puede transferir el control de un bucle o una instrucción de comprobación condicional, y siempre existe una prohibición de transferir el control en el medio de dicha instrucción. Como en los lenguajes de programación estructurados, el uso de las instrucciones GOTO está desaconsejado, puesto que hace que el código del procedimiento almacenado sea más complicado de comprender y depurar.
loop update oficinas set objetivo = objetivo ~ 10000.00; select sum(objetivo) inta total_obj froro oficinas: end loop;
La versión con subconsulla de la instrucción SELECT de Transacl-SQL se ha reemplazado por la forma SELECT INTO de PUSQL de la instrucción, 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 continuación se muestra el mismo bucle una vez más, expresado utilizando la instrucción WHILE de SPL de Informix:
Repetición con cursores 1- Decrementa los objetivos hasta que el total sea menor que 2.400.000 € -,
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
I
Algunos dialectos de procedimientos almacenados proporcionan instrucciones para controlar el flujo y alterar el flujo de control. En Inforrnix, por ejemplo, la instrucción EXIT interrumpe el flujo normal en un bucle y provoca que la ejecución continúe con la siguiente instrucción que sigue al bucle. La instrucción CONTINUE interrumpe el flujo normal en el bucle, pero hace que la ejecución continúe en la siguiente iteración 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;
En Transact-SQL, la única instrucción BREAK proporciona el equivalente de las variantes de la instrucción lnformix EXIT, y también hay un única forma-de la instrucción CONTINUE. En Oracle, la instrucción EXIT ejecuta la misma función que para lnformix, y no hay una instrucción CONTINUE.
)
Una necesidad común de la repetición 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 mayoría 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 aplicación, 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 aplicación (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, debería contener el nombre del cliente y el tamaño del pedido para cualquier pedido superior a 10.000 €. La otra, PEDIDOSPEQUEÑOS, debería contener el nombre del representante y el tamaño de pedido para cualquier pedido por debajo de 1.000 €. La mejor y más eficiente forma de realizar esto sería mediante dos instrucciones SQL INSERT separadas con subconsultas, pero, dado el propósito didáctico, en su lugar consideraremos este método:
3.
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 PEQUEÑOS. Dependiendo de la cantidad, INSERT la fila apropiada en la tabla PEDI-
4. 5.
Repetir los pasos 2 y 3 hasta que se acaben todos los resultados de la consulta. Realizar las actualizaciones en la base de datos.
1.
2.
DOSGRANDES o PEDIDOS PEQUEÑOS.
La Figura 20.13 muestra un procedimiento almacenado Orac1e que desarrolla este método. El cursor que define la consulta está descrito en la sección de decla-
726
Capítulo 20: Procesamiento de bases de datos y procedimientos...
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;
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 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;
/* importe del pedido */ /* nombre del cliente */
/. nombre del representante */
)
/* comprueba los pedidos pequeffos y los gestiona */ if (cant_ped < 1000.00) then insert into pedidospequeftos values (nombre_r, cant_ped);
/* Comprueba los elif (cant_ped > then insert inta values end if; end; end foreach; end procedure;
Figura 20.14. Figura 20.13.
los resultados de la
/~ 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
/* Variable fila que recibe los resultados de la consulta */
/* Comprueba los pedidos pequeBos y los gestiona */ iE (fila_curs.importe < 1000.00l then insert into pedidospequeftos values (fila_curs.nombre, fila_curs.importel;
727
pedidos grandes y los gestiona */ 10000.00) pedidosgrandes (nombre_c, cant_ped);
Bucle FOREACH basado en cursores en SPL de Informix.
Bucle FOR basado en cursores para PIJSQL.
raciones del procedimiento y asignado al nombre CURSOR_P. La variable FILA_CURS, descrita en la misma sección. 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. Básicamente dice al SGBD que realice la consulta descrita por el cursor (equivalente a la instrucción 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 después ejecutando las instrucciones en el cuerpo del bucle. Cuando no hay más filas de los resultados de la consulta, se cierra el cursor y el procesamiento continúa después del bucle. La Figura 20.14 muestra un procedimiento almacenado equivalente con la estructura FOR del·SPL 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 instrucción FOREACH incorpora varias funciones distintas. Define la consulta a realizar ~ediante la expresión 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 instrucción END FOREACH). Cuando se ejecuta la instrucción 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 mstrucclón. Después de que se encuentra cada fila, se ejecuta el cuerpo del bucle. Cuando no hay más filas en los resultados de la consulta, se cierra automáticamente el cursor y la ejecuci6n continúa con la siguiente instrucción que sigue a FOREACH. Nótese 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 versión Transact-SQL del procedimiento ordenar-pedidos.
728
SOL. Manual de referencia
Capítulo 20: Procesamiento de bases de datos y procedimientos...
729
SQLSTATE. Recibe un valor cero cuando liene éxito una búsqueda, y un valor distinto de cero cuando no hay más filas que buscar.
create proc ordenar-pedidos{)
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 */
Gestión de condiciones de error Cuando una aplicación utiliza SQL incorporado o la API de SQL para el procesamiento de bases de datos, la aplicación es responsable de la gestión de los errores que se dan lugar. Los códigos de estado de error se devuelven a la aplicación y normalmente está disponible más información mediante llamadas API adicionales o acceso a un área de diagnóstico extendida. Cuando tiene lugar el procesamiento de bases de datos en un procedimiento almacenado, el procedimiento mismo debe gestionar los errores. Transact·SQL proporciona gestión de errores mediante un conjunto de variables globales del sistema. Las variables específicas de gestión de errores son solamente unas pocas de más de 100 variables de sistema que proporcionan información sobre el estado del servidor, el estado de la transacción, conexiones abiertas y otra información sobre la configuración y el estado de la base de datos. Las dos variables globales más útiles para la gestión de errores son:
/* 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)
•
1* Bucle por cada fila de los resultados de la consulta */ while (@@sqlstatus = O)
Los valores de terminación 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 gestión 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 sección EXCEPTION dice al SGBD cómo debe gestionar cualquier condición de excepción que ocurra durante la ejecución del procedimiento. Hay alrededor de una docena de condiciones de excepción predefinidas detectadas por Dracle. Además, se pueden definir condiciones de excepción propias. La mayoóa de los ejemplos anteriores en este capítulo no proporcionan ninguna capacidad real de gestión de errores. La Figura 20.16 muestra una versión revisada de la función almacenada de Gracle de la Figura 20.7. La versión mejorada detecta la situación específica en que el número de cliente proporcionado no tiene ningún pedido asociado (esto es, aquella en que la consulta para calcular los pedidos totales devuelve una excepción NO_DATA_FDUND). Responde a esta situación informando a la aplicación de un error en un nivel de aplicación y un mensaje asociado. Cualquier otra condición de excepción que se da lugar es capturada mediante el gestor de excepciones WHEN OTHERS.
begin /* comprueba los pedidos pequeños 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.
Contiene el estado de error del lote de instrucciones más recientemente ejecutado. @.@@.SQLSTATOS. Contiene el estado de la última operación de búsqueda.
• @.@@ERROR.
returo end
Bucle WHILE basado en cursores en Transact·SQL
Nótense las instrucciones separadas DECLARE, OPEN, FETCH Y CLOSE para el cursor. El control del bucle es proporcionado mediante la comprobación de la variable del s"istema @@SQLSTATUS, que es el equivalente Transact-SQL del código
~
730
SOL. Manual de referencia
Capítulo 20: Procesamiento de bases de datos y procedimientos...
"/* Devuelve la cantidad de pedidos totales de un cliente */
731
/* Devuelve la cantidad total de pedidos de un cliente */ create function obtener_tot_pedidos(num_c in integerl returning rooney(16,2)
create function obtener_tot_pedidos(num_c in integer} returo number(16.2)
as /* Declara una variable local
/* Declara una variable local para albergar el total */ define tot-pedido money(16,2);
para albergar el total */
declare toc_pedido number(16.2); /* Define el gestor de excepciones para los número de error -123 y 121 */ on exception in (-121, -123) /* Se realiza lo que sea apropiado */
begin /* Sencilla consulta de una fila para obtener el total */ select sum(IMPORTE) into tot-pedido fram pedidos where cliente = num_e;
end exception; on exception /* Aquí se gestiona cualquier otra excepción */
/* Devuelve el valor recuperado como valor de la función */ returo tot-pedido;
exception Gestiona la 51tuac10n donde no se encuentran pedidos */ when no_data_found then raise_application~error (-20123. • Número de cliente incorrecto') ;
'*
)
/* Gestiona cualquier otra excepción·! when others then raise_application_error (-20199. 'Error desconocido'); end; ,
I
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 función */ return tot_pedido; end function;
,I Figura 20.16.
Función almacenada PUSQL con gestión de errores. Figura 20.17.
El SPL de Informix adopta un enfoque similar para la gestión de excepciones. La Figura 20.17 muestra la versión Informix de la función almacenada, con gestión de excepciones estilo Informix. La instrucción ON EXCEPTION es una instrucción declarativa, y especifica la secuencia de instrucciones SQL que ha de ejecutarse cuando ocurre la excepción. Se puede especificar una lista de números de excepción 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 ejecución. Muchas marcas de SGBD compilan procedimientos almacenados (automáticamente o por solicitud del usuario) en una representación interna que se puede ejecutar muy eficientemente en el SGBD en tiempo de ejecución. La ejecución de un procedimiento alm.ace-
Función almacenada SPL de Informix con gestión de condiciones.
nado precompilado puede ser mucho más rápida que la ejecución de las instrucciones SQL equivalentes mediante el proceso PREPARE/EXECUTE. • Reutilización. Una vez que se ha definido un procedimiento almacenado para una función específica, a dicho procedimiento se puede ll~ar desde muchas aplicaciones distintas que necesitan ejecutar dIcha funCIón, lo que permite una reutilización muy sencilla de la lógica de la aplicación y reduce el riesgo de error del programador de la aplicación. . • Tráfico de red reducido. En una configuración cliente/servidor, al enviar una llamada a un procedimiento almacenado a través de la red y recibi~ los resultados en un mensaje de respuesta, se genera mucho menos tráfico de red que en el caso de un viaje a través de la red para cada in_stI~ucción SQL individual. Esto puede mejorar considerablemente el rendImIento glob~l del sistema en una red con un gran tráfico o que tiene conexiones de baja velocidad. • Seguridad. En la mayoría 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
'''1
j;1
,,, ,
11
I"
~
Capitulo 20: Procesamiento de bases de datos y procedimientos...
SOL. Manual de referencia
733
Rendimiento de los procedimientos almacenados
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 más fuerte sobre los datos subyacentes, mientras que aún proporciona a los usuarios individuales la actualización de datos específicos o la capacidad de acceso a datos que requiere. • Encapsulación. Los procedimientos almacenados son una forma de lograr uno de los objetivos principales de la programación orientada a objetos (la encapsulación de los datos, estructuras y acceso en un conjunto de interfaces externas muy limitadas y bien definidas). En la terminología de los objetos los procedimientos almacenados pueden ser los métodos 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 sólo a los procedimientos almacena'!,9d acceder a la base de datos. En la práctica, pocas bases de datos relacionales de producción operan de esta forma restringida. • Simplicidad de acceso. En una gran base de datos corporativa, una colección 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 mayoría de los programadores es más sencillo comprender una llamada a una función predefinida sencilla que comprueba el saldo de una cuenta dado un número de cliente, o una que agrega un pedido, dado un número de cliente, cantidad, identificador del producto, que las instrucciones SQL correspondientes. • Aplicación 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 podría contener lógica para comprobar el crédito 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 compañía podría tener fácilmente distíntas 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 podría tener su propia aplicación de aceptación de pedidos, normalmente escrito por distintos programadores en momentos diferentes. Pero si todos los programas están forzados a utilizar el mismo procedimiento almacenado para agregar un pedido, la compañía puede asegurar que las reglas del negocio en dicho proc~dimiento se cumplen de forma uniforme, sin importar dónde se originó el pedido.
Las distintas marcas de SOBD vaóan 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 ejecución para procedimientos almacenados complejos. El SGBD debe leer las instrucciones que forman el procedimiento almacenado en tiempo de ejecución, 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 más fácil de interpretar. La compilación puede ser automática cuando se crea el procedimiento almacenado, o el SGBD puede proporcionar al usuario la posibilidad de solicitar la compilación del procedimiento almacenado. La desventajas de los procedimientos almacenados compilados es que la técnica 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 después de que se haya creado la base de datos y después se construyen algunos índices útiles sobre los datos. Las consultas compiladas en el procedimiento almacenado no se aprovecharán de estos índices y, como consecuencia, se podrán ejecutar mucho más lentamente que si fueran recompiladas_ Para tratar con estos procedimientos compilados desde hace tiempo algunas marcas de SGBD anotan automáticamente que cualquier procedimiento compilado que puede estar afectado por posteriores cambios de la base de datos necesita una recompilación. 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 recompilación mientras que mantiene actualizado el procedimiento almacenado). Su desventaja es que puede dar lugar a tiempos de ejecución del procedimiento almacenado impredecibles. Cuando no es necesaria la recompilación, el procedimiento almacenado se puede ejecutar rápidamente; cuando se activa la recompilación, se puede producir un retraso significativo, y en la mayoría de los casos, el retraso de la recompilación es mucho mayor que la desventaja de usar la antigua versión compilada. Para determinar las capacidades de compilación del procedimiento almacenado de un SGBD particular, se pueden examinar las opciones de instrucción CREATE PROCEDURE Y EXECUTE PROCEDURE, o buscar otras instrucciones de gestión 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 gestión.
e-.....
734
1 SOL. Manual de referencia
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 gestión de usuarios, funciones de base de datos, ejecución de trabajos, servidores distribuidos, réplicas. etc. La mayoría de los procedimientos del sistema en Transact-SQL siguen este convenio de nombres: • SP_ADD_algo. Agrega un nu~vo objeLO (usuario, servidor, réplica, etc.). •
SP_DROP _algo.
• SP_HELP_algo.
Elimina un objeto existente. Obtiene información sobre un objeto u objetos.
Por ejemplo. el procedimiento SP_HELPUSER devuelve información sobre los usuarios válidos de la base de datos actual.
Capítulo 20: Procesamiento de bases de datos y procedimientos...
735
enlace dinámico (DLL, Dynamic·Linked Library) y llamarla desde los procedimientos almacenados SQL Server. lnformix proporciona acceso básico a las capacidades subyacentes dei sistema operativo con una instrucción SYSTEM especial. Además, admite procedimientos externos definidos por el usuario mediante su instrucción CREATE PROCEDURE. En el lugar en que pueda aparecer el bloque de instrucciones que contiene el cuerpo de un procedimiento SPL de Informix, un cláusula EXTERNAL especificará el nombre, ubicación 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, también mediante la instrucción CREATE PROCEDURE. La familia de bases de datos DBZ de IBM proporciona el mismo conjunto de capacidades.
Procedimientos almacenados externos
I
I
Aunque los procedimientos almacenados escritos en los dialectos SQL extendIdos de las marcas principales de SGBD pueden ser bastante potentes, tienen sus limitaciones. Una limitación principal es que no proporcionan acceso a características externas al SGBD, tales como las características del sistema operativo u otras aplicaciones que se ejecutan en el mismo sistema informático. Los dialectos SQL extendidos también tienden a ser lenguajes de alto nivel, con capacidad limitada para la programación 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 programación convencional (tal como C o Pascal) y compilado fuera del SGBD. Se da al SGBD una definici.6n del nombre y parámetros del procedimiento, junto con otra información esencial tal como los convenios de llamada uti~iza~ dos por el lenguaje de programación 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 parámetro 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 electrónicos a usuarios, según las condiciones en el SOBD: XP_SENDHAIL liRECIPIENTS = 'Juan'. 'Sarnuel'. iMESSAGE = 'Tabla de clientes casi llena';
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. Además de estos procedimientos externos predefinidos, SQL Server permite almacenar un procedimiento externo escrito por el usuario en una biblioteca de
Disparadores Como se describe al comienzo de este capítulo, un disparador es un conjunto especial de código 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 instrucción CREATE PROCEDURE, un disparador no es activado por una instrucción 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 instrucción 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 también se pueden utilizar para producir actualizaciones automáticas 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 según la cuota del representante. A continuación 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 instrucción CREATE TRIGGER se usa en la mayoría 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 acción o acciones de actuali-
736
Capitulo 20: Procesamiento de bases de datos y procedimientos...
SOL Manual de referencia
Disparadores en Transact·SQL
zación sobre la tabla que producirán 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 debería ejecutar la instrucción 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.
\
Transact-SQL proporciona disparadores mediante la instrucción CREATE TRIGGER en los dialectos SQL Server de Microsoft y Adaptive Server de Sybase. A continuaci6n se muestra la definición de un disparador Transact-SQL para la base de datos ejemplo. que implementa la misma función de disparador que el ejemplo PU SQL, de Orac!e, precedente:
Ventajas e inconvenientes de los disparadores
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;
Los disparadores pueden ser extremadamente útiles como parle integral de la definición de una base de datos, y entre sus funciones podemos destacar las siguientes:
.1
1,
737
• Auditoría de cambios. Un disparador puede detectar y prohibir actualizaciones específicas y cambios que no deberían 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 automátfca~ 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 más 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 comprobación, como las que requiere una secuencia de instrucciones SQL o con IF...THEN...ELSE. • Invocación a procedimientos almacenados. Un disparador puede llamar a uno O más procedimientos almacenados o incluso invocar acciones fuera del SGBD mediante llamadas a procedimientos externos en respuesta a actualizaciones de la base de datos.
end
else raiserror 23456
La primera cláusula da nombre al disparador (ACT_OBJ). Se requiere la segunda cláusula, que identifica la tabla a la cual se aplica el disparador. La tercera cláusula también es necesaria y dice qué operaciones de la base de datos hacen que se active el disparador. En este caso solamente la instrucción INSERT da lugar a esta activación. También se pueden especificar las operaciones UPDATE o DELETE, o una combinación de dos o tres de estas operaciones en una lista separada por comas. Transact-SQL restringe los disparadores de forma que sólo se puede definir un disparador sobre una tabla determinada para cada una de las tres operaciones de modificación. Al cuerpo del disparador le sigue la palabra clave AS. Para comprender el cuerpo del disparador, se necesita entender cómo Transact-SQL trata las filas en la tabla objetivo durante las operaciones de modificación de la base de datos. Para la operación del disparador, Transact-SQL define dos tablas lógicas cuya estructura de columnas es idéntica 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 lógicas se rellenan con filas de la tabla objetivo, depen~ diendo de la instrucción de modificación de los datos que hace que se active el disparador:
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 ubicación sencilla en la base de datos (la definición 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 operación 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, según sea apropiado. .
• DELETE. Cada LETE se ubica • INSERT. Cada SERT
fila de la tabla objetivo que se elimina con la instrucción DEen .la tabla DELETED. La tabla INSERTED permanece vacía. fila de la tabla objetivo que se agrega con la instrucción INtambién se ubica en la tabla INSERTED. La tabla DELETED permanece
vacía. • UPDATE. UPDATE,
1
Por cada fila de la tabla objetivo que se cambia con la instrucción se ubica una copia de la fila antes de las modificaciones en la tabla
738
SOL. Manual de referencia
Una copia de la fila se ubica en la tabla INSERTED después de todas las modificaciones.
DELETED.
Se puede hacer referencia a estas dos tablas lógicas en el cuerpo del disparador. y los datos se pueden combinar con los datos de otras tablas durante la ,operación 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 comprobación de la variable del sistema @@ROWCOUNT. Si esto es cierto, se agrega en la columna CUOTA de la tabla lógica INSERTED la fila apropiada de la tabla OFICINAS. La fila apropiada se determina combinando la tabla lógica a la tabla OFICINAS según los números de oficina coincidentes. A conlinuación 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 todavía tiene pedidos pendientes en la base de datos. Si se detecta esta situación, el disparador deshace automáticamente toda la transacción, inclu) yendo la instrucción DELETE que activó dicho disparador:
Capítulo 20: Procesamiento de bases de datos y procedimientos...
739
Disparadores en SPL de Informix Informix también incorpora los disparadores mediante la instrucción CREATE TRIel dialecto Transact-SQL, el comienzo de la instrucción CREATE el nombre del disparador, la tabla sobre la cual se define el disparador y las acciones de la activación. A continuación se muestran fragmentos de una instrucción que ilustran la sintaxis:
GGER. Como en TRIGGER define
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
crea te trigger comp_eli_cliente (* Borra el disparador para CLIENTES *J on clientes for delete as J* Detecta cualquier pedido para el número 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, aún tiene pedidos· raiserror 31234 end
El último ejemplo es un disparador que se activa solamente cuando se actualizan dos columnas específicas de la tabla REPRESENTANTES. Informix permite especificar que un disparador debería operar tres veces distintas durante el procesamiento de un cambio activado en una tabla objetivo:
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:
La definición de un disparador individual puede especificar acciones que han de adoptarse en uno o más de estos· pasos. Por ejemplo, un disparador podría ejecutar un procedimiento almacenado para calcular la suma de todos los pedidos antes de (BEFDRE) una actualización, supervisar las actualizaciones de de cada fila de PEDIDOS cada vez que ocurren con una segunda acción y después calcular el total de pedidos revisado después de (AFTER) la actualización con una ~larnada a otro procedimiento almacenado. A continuación se muestra la definición de un disparador que realiza todo esto:
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 */
El disparador se activa antes de que tenga lugar cualquier cambio. Todavía no se ha modificado ninguna fila de la tabla objetivo. AFTER. El disparador se activa después 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 ocasión que una fila es afectada por un cambio. Los valores antiguos y nuevos de ia fila están disponibles para el disparador.
• BEFORE. • •
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
Capitulo 20: Procesamiento de bases de datos y procedimientos...
SOL. Manual de referencia
/* 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,
when
*'
En la práctica, la última opción proporciona algo de flexibilidad. El procedimiento llamado puede ejecutar casi cualquier procesamiento que pudiera realizarse en el cuerpo del disparador.
Disparadores en PL/SQL de Oraele
pre. importe. post. importe) ;) (post. importe > pre.importel
Oracle proporciona una capacidad de disparadores más compleja que lnformix o Transact-SQL, descritas en las secciones anteriores. Utiliza la instrucción CREATE TRIGGER para especificar las acciones disparadas. Como en Informix, se puede especificar un disparador para activarlo en ciertas ocasiones durante operaciones de actualización específicas:
/* Escribe los aumentos en la tabla */
{iosert into ped_aum values (pre.cliente, pre.fecha_pedido, pre. importe, post. importe);) /* Después de los cambios, recalcula el total */ after (execute procedure agregar-pedidos() into nuevo_total;)
La cláusula
BEFORE
en este disparador especifica que se va a
procedimiento almacenado denominado
AGREGAR_PEDIDOS
• Disparador para instrucciones. Un disparador para instrucciones se activa una vez por cada instrucción de modificación de datos. Se puede especificar para activarse antes de que se ejecute la instrucción o después de que la instrucción haya completado su acción. • Disparador para filas. Un disparador para filas se activa una vez para por cada fila que es modificada por una instrucción. En la estructura Oracle este tipo de disparador también se activa antes de que se modifique la fila o después de modificarse. • Disparador «en lugar de». Un disparador «en lugar de» toma el lugar de una instrucción de un intento de modificación de datos. Proporciona una forma de detectar el intento de una operación 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 instrucción, o que se debería ejecutar en lugar de cada modificación intentada de una fila.
Ilama~ un
antes de que ocurra
cualquier procesamiento de la instrucción UPDATE. Presumiblemente, este procedimiento calcula los pedidos totales y devuelve el valor total en la variable local TOTAL_ANTERIOR. De igual forma, la cláusula AFTER especifica que se va a llamar a un procedimiento almacenado (en este caso, el mismo) después de que se complete el procesamiento de la instrucción UPDATE. Esta vez, la cantidad total de pedidos se ubica en una variable local distinta, NUEVO_TOTAL. La cláusula FOR EACH ROW especifica la acción a adoptar cada vez que se actualiza cada fila. En este caso la acción solicitada es un INSERT en una de las dos tablas de seguimiento de pedidos, según aumente o disminuya la cantidad del pedido. Estas tablas de seguimiento contienen el número 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 (después del cambio) de cada fila. La cláusula 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 están 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á más limitado que algunas otras marcas de SGBD en las acciones que se pueden especificar en la definición del disparador. Están disponibles las siguientes acciones: • Una instrucción • Una instrucción • Un~ instrucción • Una instrucción
741
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 después 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
INSERT. DELETE. UPDATE. EXECUTE PROCEDURE.
/* Captura los aumentos y disminuciones de los pedidos */ fer each rew when (post.importe !: pre.importel begin
'-
742
SOL. Manual de referencia
if (post. importe
<
Capítulo 20: Procesamiento de bases de datos y procedimientos... pre.importel
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 */
743
si se permite el procesamiento de disparadores en cascada. Finalmente, algunos proporcionan un límite en el número 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 situación. Oracle, por ejemplo, proporciona esta forma de la instrucción ALTER TRIGGER:
insert into ped_aum values (pre.cliente, pre.fecha_pedido, pre.importe,
'1
post. importe); end if;
ALTER TRIGGER ANTES_ACT_PED DISABLE;
Se proporciona una capacidad similar con la instrucción Informix.
CREATE TRIGGER
de
end;
Estas estructuras de disparador y sus opciones proporcionan 14 tipos válidos) de disparadores Orade (12 resultantes de la elección de disparadores INSERT/ DELETE/UPDATE para BEFORE o AFTER para filas o instrucciones (3x2x2) y dos más para los disparadores «en lugar de» para las instrucciones o filas. En la práctica, 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 características orientadas a objetos. El código que se acaba de mostrar es una definición de disparador PUSQL que implementa el mismo procesamiento que en el complejo ejemplo Informix de la sección 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 actualización de fila.
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 instrucción UPDATE para otra tabla. Un disparador en esta tabla produce UPDATE de otra tabla, y así sucesivamente. ¡La situación es incluso peor si uno de los disparadores activado intenta actualizar la tabla objetivo inicial que produjo la activación de la secuencia del disparador en primer lugar! En este caso se podría 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 ejecución 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 parámetro del s~stema que controla
Procedimientos almacenados, disparadores y el estándar 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 dinámica de la industria de bases de datos. La introducción inicial de Sybase de los procedimientos almacenados y disparadores en SQL Server produjo una respuesta competitiva y, a mediados de los años noventa, muchos de los sistemas empresariales habían agregado sus propias extensiones procedimentales propias a SQL. Los procedimientos almacenados no eran centro de atención del estándar SQL2, pero formaron parte de la agenda de estandarización después de la publicación en 1992 del estándar SQL2. El trabajo sobre estándares 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 estándar SQL, publicado en 1996 como el estándar internacional ISO/lEC 9075-4, denominado SQUPersistent Stored Modules (SQUPSM). La forma real de la especificación del estándar es una colección de añadidos, ediciones, nuevos párrafos y reemplazo de párrafos del estándar SQL2 de 1992 (ISO/lEC 9075:1992). Además de ser una modificación del estándar SQL2, SQUPSM fue también un boceto de una parte del estándar futuro planificado, que se llamó SQL3 durante el desarrollo de su boceto. El desarrollo del estándar supuso más tiempo de lo esperado, pero SQLIPSM finalmente salió como Parte 4 del estándar SQL3, oficialmente conocido como SQL: 1999. El estándar SQL Call-Levellnteiface (CLI), descrito en el Capítulo 19, se trató de la misma forma; ahora es la Parte 3 del estándar SQL: 1999. Cuando se publicó el estándar SQL:1999, se trasladaron partes seleccionadas de SQUPSM al núcleo de SQUFoundation specification (Part 1), puesto que también es usado por otras partes del estándar. El estándar SQUPSM publicado en 1996 solamente describía procedimientos almacenados; no proporcionó explícitamente una especificación de los disparado-
744
SOL. Manual de referencia
Capítulo 20: Procesamiento de bases de datos y procedimientos...
res para el estándar SQL de ISO. Se consideró la estandarización de disparadores durante el desarrollo de los estándares SQL2 y SQLlPSM, pero los grupos de estándares determinaron que los disparadores estaban demasiado vinculados a otras extensiones orientadas a objetivos propuestas por SQL3. El estándar SQL: 1999 que resultó del trabajo SQL3 proporcionó finalmente una capacidad ANSIIISO estándar para los disparadores. La publicación de los estándares SQUPSM y SQL: 1999 retrasaron en muchos años la primera implementación comercial de los procedimientos almacenados y disparadores. Cuando se adoptó el estándar, la mayoría de los fabricantes de SOBO habían respondido al entusiasmo de los usuarios y a la presión competitiva introduciendo los procedimientos almacenados y los disparadores en sus productos. A diferencia de algunas extensiones de SQL en las que la implementación DB2 de IBM impuso el estándar de facto, la mayoría de fabricantes de SGBD implementó procedimientos almacenados y disparadores de distintas formas y, en algunos casos, compitieron entre sí en términos de las características únicas de sus implementaciones. Como consecuencia, la estandarización 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 encontrarán, con el tiempo, su camino en la mayoría de los productos SGBD, pero como complemento a las implementaciones propietarias, más que como remplazo de éstas.
'1
!
I
,1
745
aceptan parámetros pasados mediante la instrucción CALL. Los procedimient6s al. macenados SQUPSM también pueden devolver datos mediante los parámetros de salida, de nuevo como en los lenguajes de procedimientos almacenados propietarios. SQUPSM también alberga parámetros combinados de entrada/salida, como algunos de los lenguajes propietarios. Una función SQL devuelve un valor. Se llama de igual forma que una función SQL incorporada en una expresión: 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 función. En las funciones SQL no se permiten los parámetros 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 creación 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. También permite la creación de rutinas en un módulo SQL2, que es el modelo de procedimientos de SQL que se desarrolló a partir del estándar SQLI.
El estándar de los procedimientos almacenados SQL/PSM
Creación de una rutina SOL
Las capacidades· especificadas en el estándar SQL/PSM reflejan las características principales de las capacidades de los procedimientos almacenados propietarios de los sistemas SGBD actuales. Incluyen construcciones del lenguaje SQL para:
Siguiendo la práctica de la mayoría de marcas de SGBD, el estándar 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. Además de las capacidades mostradas en la figura, el estándar proporciona la capacidad de defi'nir procedimientos almacenados externos, especificando el lenguaje en el que están escritos, si pueden o no leer o modificar los datos en la base de datos, los convenios de llamada y otras características.
• Definir y dar nombre a procedimientos y funciones escritos en el lenguaje SQL extendido. . • Invocar (llamar) un procedimiento o función previamente definido. • Pasar parámetros a un procedimiento o función invocada y obtener los resultados de su ejecución. • Declarar y utilizar variables locales en el procedimiento o función. • Agrupar un bloque de instrucciones SQL para su ejecución. • Ejecutar condicionalmente instrucciones SQL (IF ... THEN ... ELSE). • Ejecutar repetidamente un grupo de instrucciones SQL (bucles).
Instrucciones de control de flujo
El estándar SQUPSM especifica las estructuras de programación comunes que se encuentran en la mayoría de los dialectos de procedimientos almacenados para controlar el flujo de la ejecución. La Figura 20.19 muestra la sintaxis de la bifurcación condicional y los bucles. Nótese 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 explícitas para las secuencias sencillas de varias instrucciones que apa· recen en una instrucción IF ... THEN ... ELSE o una instrucción LOOP. Las estructuras de bucle proporcionan mucha flexibilidad para el procesamiento de bucles. Hay formas que ubican la comprobación al comienzo del bucle, y otras al final del bucle, así como una forma que proporciona un bucle infinito y requiere una codi·
El estándar SQUPSM especifica dos·tipos de rutinas SQL. Un procedimiento· SQL es una rutina que no devuelve un valor. Se llama con una instrucción CALL: CALL AGREGAR_CLIENTE{'Empresa XY"Z' , 'Cast.ellón' I
2137,
30000.00,
50000.00,
103,
Como .con los lenguajes de procedimientos almacenados ilustrados en los ejemplos anteriores en todo este capítulo, los procedimientos almacenados SQL!PSM
'-
746
SOL. Manual de referencia
1-- CREATE
-,-
PROCEDURE
L
FUNCTION
3
Capítulo 20: Procesamiento de bases de datos y procedímiemos...
ficaci6n explícita de un test para salir de la ejecución del bucle. Cada una de las estructuras de control del programa termina explícitamente en un indicador-ENO que se corresponde con el tipo de estructura. haciendo más sencilla la depuración del programa.
Operaciones con cursores
1
El estándar SQL/PSM extiende las capacidades de manipulación de cursores especificado en el estándar 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 anfitrión de la aplicación para proporcionar valores de los parámetros y recibir los datos recuperados, se pueden utilizar los parámetros y variables de la rutina SQL para estas funciones. El estándar 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 sección «Repetición con cursores» de este capítulo, combina la definición del cursor y las instrucciones OPEN, FETCH Y CLOSE en una única definición de bucle que también especifica ~l procesamiento a ejecutar por cada fila de los resultados recuperados de la consulta.
L ;n","~;ón;-. _
te. J
..J
END LOOP
-r.
WHITE condición-de búsqueda DO instrucción;
J----+
1 •
L etIqueta:
END WRITE'-------:¡:+_
L etiqueta:J
etIqueta:
~[.
f
REPEAT
etlquete :
Figura 20.19.
T
instrucción
.
;y
UNTIL condición-de-búsqueda
EN[)
REPEAT [ .
j
etIqueta:
Diagrama sintáctico 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 estándar SQUPSM. Es una estructura bastante fácil de entender que proporciona las siguientes capacidades: • Etiqueta el bloque de instrucciones con una etiqueta de instrucción. • Declara variables locales para su uso en el bloque. • Declara condiciones locales de error definidas por el usuario_
748
L.
I
j
749
Capítulo 20: Procesamiento de bases de datos y procedimientos...
SOL. Manual de referencia
~
FOR "'a,iabllHf~l-bucle AS
I1r,queta:
BEGIN
I
L l
ATOMIC..J
NOT
L
nombrc·del-
cursor
L
yCURSOR FOR
J
especificación-de-
~o'"",
INSENSITlVE
00
T
;nsrrvcr:ión;
T
END FOR
-L. et,queta:
Figura 20.20.
J
.~
Diagrama sintáctico de flujo controlado por cursor SQl/PSM.
d"¡""'60·d'·,,,;,.,, -
;
declarllCión-dft
;
declaración-de-eursor _ _ ;
-.J
declaración-de-eontrolador-;
-.J
END
I
,I I
i
11
;~
instrucción
• Declara cursores para la ejecución 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.
=J
L
etiqueta:
••
J
Declaración de variable:
Estas capacidades recuerdan algunas de las descritas anteriormente en la sección «Bloques de instrucciones» de este capítulo 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 instrucción DECLARE. Los valores se asignan mediante el uso de la instrucción SET. Las funciones devuelven un valor mediante el uso de la instrucción RETURN. A continuación se muestra un bloque de instrucciones que puede aparecer en una función almacenada, con ejemplos de estas instrucciones:
- - - - DECLARE
.......---
nombre-de. variable ---r-tIPo-de-datos-r
L.- , ~
valor· LOEFAULT predeterminado
Declaración de condición: -
DECLARE -
:r-
J-
nombre-de-condición CONDITION ~L POR SQLSTATE va/or-sq/sfate
Figura 20.21.
try_again: begin 1- Declara algunas variables locales +1 declare texto_mensaje varchar(40); declare imp_tot decimal(lG.2):
Diagrama sintáctico del bloque de instrucciones SOl/PSM.
Gestión de errores La estructura de bloques especificada por el estándar SQL/PSM proporciona un soporte bastante fácil de entender para la gestión de errores. El estándar especifica condiciones predefinidas que se pueden detectar y gestionar:
/* Obtiene el total de los pedidos */
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
•
SQLWARNING.
Una de las condiciones de aviso especificada en el estándar
SQL2. Condición que normalmente sucede cuando se alcanza el final de un conjunto de una consulta con una instrucción FETCH.
• NOT FaUNO.
-
750
Capitulo 20: Procesamiento de bases de datos y procedimientos...
SOL. Manual de referencia
• Valores SQLSTATE. Un test para códigos de error específicos SQLSTATE. • Condiciones definidas por el usuario. Una condición nombrada por el procedimiento almacenado. Las condiciones se definen normalmente en términos de valores SQLSTATE. En lugar de utilizar códigos SQLSTATE numéricos se puede asignar un nombre simbólico a la condición. Se puede también especificar una condición definida por el usuario: declare err_mal condition for sqlstate '12345', declare mi_err eondition;
Una vez que se ha definido la condición, se puede forzar que ocurra la condi ción mediante la ejecución de una rutina SQL con la instrucción SIGNAL:
)
Para gestionar las condiciones de error que pueden ocurrir, SQUPSM permite declarar un controlador de condiciones. La declaración especifica la lista de condiciones que se van a gestionar y la acción que se ha de adoptar. También especifica el tipo de gestión de la condición. Los tipos se diferencian en lo que sucede al flujo de control después de que el gestor termine con su t~rea: • Tipo CONTrNUE. Después de que el controlador de condiciones finalice su trabajo, se devuelve el control a la siguiente instrucción que sigue a la que ha provocado la condición. Esto es, la ejecución continúa con la siguiente instrucción. • Tipo ExrT. Después de que el controlador de condiciones finalice su trabajo, se devuelve el control al final del bloque de instrucciones que contiene la instrucción que ha provocado la condición. Esto es, la ejecución finaliza el bloque. • Tipo ONDO. Después 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 instrucción que provocó el error. El efecto es el mismo que si la transacción se hubiera iniciado al comienzo del bloque de instrucciones y se hubiera retrocedido'A continuación se muestran algunos ejemplos que ilustran la definición de la estructura del gestor: ,. Gestiona los avisos SQL y después continúa ., declare continue handler for sqlwarning call mi_rutina_avisol); , . Gestiona errores severos deshaciendo los efectos . , declare undo handler for user_disaster
begin ,. Se arregla el desastre ., end;
La gestión de errores puede llegar a ser bastante compleja, y es posible que ocurran errores durante la ejecución de la propia rutina del controlador. Para evitar la repetición infinita en los errores, no se aplica la señal normal de errores durante la ejecución de un controlador de condiciones. El estándar permite omitir esta restricción con la instrucción RE5IGNAL. Opera de igual forma que la instrucción SIGNAL, pero se utiliza exclusivamente con rutinas de controladores de condiciones.
M
signal err_mal;
signal sqlstate '12345';
751
Sobrecarga de rutinas El estándar SQUPSM permite la sobrecarga de nombres de procedimientos y funciones almacenadas. La sobrecarga es un atributo común en sistemas orientados a objetos y es una forma de hacer que las rutinas almacenadas sean más 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 número de parámetros que aceptan o en los tipos de datos de los parámetros. 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
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
el
bl
La primera función COMBO combina dos enteros y devuelve la suma. La segunda función COMBO combina tres enteros de la misma forma. La tercera función COMBO combina dos cadenas de caracteres y las concatena. El estándar permite definir estas funciones COMBO al mismo tiempo en la base de datos. Cuando el SGBD encuentra una referencia a la función COMBO, examina el número de argumentos en la referencia y sus tipos de datos, y determina a qué versión de la función COMBO llamar. La capacidad de sobrecarga permite a un programador SQL
752
SOL. Manual de referencia
Capítulo 20: Procesamiento de bases de datos y procedimientos...
crear una familia de rutinas que ejecutan la misma función lógica y tienen el mismo nombre, incluso si se especifica su uso para distintos tipos de datos. En términos del lenguaje orientado a objetos, la sobrecarga se denomina algunas veces polimorfismo. Jo que significa literalmente que la misma función puede adoptar muchas formas distintas. Para simplificar la gestión de una familia de rutinas que comparten un nombre sobrecargado, el estándar SQUPSM tiene el concepto de un nombre específico: un segundo nombre que se asigna a la rutina que es único en el esquema de la base de datos o módulo. Identifica de forma única una rutina específica. El nombre específico se utiliza para borrar ]a rutina y se refleja en las vistas del esquema de la información que describen las rutinas almacenadas. El nombre específico no se utiliza para llamar a la rutina; esto evitaría el propósito principal del nombre de la rutina sobrecargada. Incorporar nombres específicos o algún mecanismo similar es un requisito práctico para cualquier sistema que permite la sobrecarga o el polimorfismo para los objetos y proporciona la capacidad de gestionarlos mediante la eliminación o el cambio de sus definiciones, puesto que el sistema debe poder determinar qué objeto específico se va a modificar. )
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 estándar SQL/PSM proporciona un método alternativo de búsqueda de la definición de nombres de rutinas sin calificar mediante un nuevo concepto PATH. PATH es la secuencia de nombres de esquema que se deberían buscar para resolver una referencia a una rutina. Un PATH predeterminado se puede especificar como parLe de la cabecera del esquema en la instrucción CREATE SCHEMA. PATH también se puede modificar dinámicamente durante una sesión SQL mediante la instrucción SET PATH. El estándar SQUPSM también permite al autor de un procedimiento o función almacenada dar al SOBO algunos consejos sobre su operación con el fin de mejorar la eficiencia de su ejecución. 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 parámetros. 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 indicación dice al SOBD si un procedimiento o función 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 también puede imponer una restricción de seguridad sobre rutinas externas de otros orígenes. Otras indicaciones determinan si se debe llamar a una función SQL si uno de sus parámetros tiene un valor NULL, y controlan cómo el SOBD selecciona una función o procedimiento específico a ejecutar cuando se utiliza la sobrecarga.
Procedimientos almacenados externos
I
753
La mayor parte del estándar SQUPSM se refiere a las extensiones al lenguaje SQL que se utilizan para definir procedimientos SQL y funciones SQL. Nótese, sin embargo, que el método utilizado para invocar a un procedimiento SQL (la instrucción CALL) o una función SQL (una referencia a la función mediante el nombre en una instrucción SQL) no son específicos de los procedimientos definidos en el lenguaje SQL. En realidad, el estándar SQUPSM proporciona procedimientos almacenados externos y funciones, escritos en algún otro lenguaje de programación, como e o PascaL Para los procedimientos externos las instrucciones CREATE PROCEDURE y CREATE FUNCTION todavía se utilizan para definir el procedimiento en el SGBD, especificando su nombre y parámetros que acepta o devuelve. Una cláusula especial de la instrucción CREATE especifica el lenguaje en el que está escrito el procedimiento almacenado o función, de forma que el SOBn puede ejecutar la conversión apropiada de los tipos de datos y llamar a la rutina de forma apropiada.
Estándares de disparadores en SQL:1999 Los disparadores se tuvieron en cuenta para su estandarización como parte de SQL3, que dio lugar a lá final publicación del estándar ANSIIISO SQL:1999. Por esas fechas, muchos productos comerciales de SGBD ya habían implementado los disparadores y el estándar sintetizó las capacidades específicas que se habían mostrado útiles en la práctica. Al igual que los productos comerciales, los disparadores estándar ANSIflSO se definen para una única tabla específica. El estándar 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 capítulo proporcionan un contexto para examinar el mecanismo estándar ANSIIISO. El estándar no proporciona una separación radical de las capacidades ya descritas para los diversos pro-
Otras capacidades de los procedimientos almacenados
El estándar 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 instrucción DROP para borrar rutinas que no son necesarias, y una variante de la instrucción ALTER para cambiar la definición de una función 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 función. Se gestiona mediante las ,instrucciones GRANT y REVOKE de· la misma forma que otros privilegios de la base de datos.
""'--
754
SOL. Manual de referencia
Capítulo 20: Procesamiento de bases de datos y procedimíentos...
ductos de SGRD. A continuación se muestra cómo se relaciona el estándar con ellos: • Nombres. El estándar trata a los disparadores como objetos con nombre en la base de dalos. • Tipos. El estándar proporciona los disparadores INSERT, DELETE y UPDATE; los disparadores UPDATE se pueden asociar con la actualización de una columna o grupos de columnas específicas. • Temporización. El estándar proporciona los disparadores que operan ames o después de una instrucción de actualización de la base de datos. • Operación en el nivel de las filas o de las instrucciones. El estándar proporciona disparadores en el nivel de las instrucciones (se ejecutan una vez por cada instrucción de actualización 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 «después» en una fila o tabla modificada mediante un mecanismo de alias, como los alias de tábla utilizados en la cláusula FROM. / Para definir un disparador se utiliza la instrucción CREATE TRIGGER de SQL:1999, mostrada en la Figura 20.22. Las cláusulas de la instrucción resultan familiares a partir de los ejemplos de disparadores de las primeras secciones de este capítulo. Una extensión muy útil, proporcionada por el estándar, es la cláusula WHEN que se puede especificar como parte de una acción disparada. La cláusula WHEN es opcional y opera como una cláusula WHERE para determinar si se llevará a cabo una acción disparada_ Cuando el SGBD ejecuta un tipo particular de instrucción especificada en la definición del disparador, evalúa la condición de búsqueda especificada en la cláusula WHEN. La forma de la condición de búsqueda es exactamente igual a la condición de búsqueda en la cláusula WHERE y producirá un resultado TRUE o FALSE. La acción disparada se lleva a cabo solamente si el resultado es TRUE. Para proporcionar seguridad a los disparadores, el estándar SQL:1999 establece un nuevo privilegio TRIGGER que se puede conceder en tablas específicas a usuarios específicos. 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.
r- CREATE TRIGGER
nombre-dedisparador
755
AFTER DELETE BEFORE1INSERT':======3C-l UPDATE nombre-deUPDATE OF ~u~n8
,-----..,.-,----------;r------.j WHEN ( condiciÓn-de·busqueda J
I
I
1 1
I
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.
inslrucci6n·SOL-------------------,,----+ BEGIN
ATOMIC ~cc¡Ón-SOL
Figura 20.22.
Diagrama sintáctico de
t
END-.Jo
CREATE TRIGGER
de 1999.
• 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 básico proporcionan a los procedimientos almacenados las características normalmente encontradas en los lenguajes de programación. Estas características incluyen variables locales, procesamiento condicional, bifurcación 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 ejecución se inicia automáticamente en función de los intentos de modificación de una tabla. Un disparador se puede activar mediante una instrucción INSERT, DELETE o UPDATE.
756
SOL Manual de referencia
• Hay una gran variedad en los dialectos SQL específicos utilizados por la mayoría de marcas de SaBD para incorporar procedimientos almacenados y disparadores. • Actualmente hay un estándar internacional para los procedimientos almacenados (aunque no para los disparadores); al ser uno de los últimos estándares, todavía no ha tenido un gran impacto sobre las implementaciones reales de los principales fabricantes de SGBD.
)
,[
I
¡.¡
'·1
CAPíTULO
21
SOL Y los almacenes de datos
Una de las aplicaciones actuales más importantes de SQL y la tecnología de bases de datos relacionales es el área rápidamente creciente de los ·almacenes de datos y la información de empresa. El punto clave del almacén de datos es utilizar datos acumulados para proporcionar información e intuiciones para la toma de decisiones. Con el aumento de popularidad de World Wide Web y la interacción 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 páginas web) ha explotado literalmente. El almacén de datos fomenta que estos datos sean tratados como un conjunto valioso y que se traduzcan, mediante su análisis, en una ventaja competitiva. El proceso complementario de minería de datos supone un análisis 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 tecnología clave subyacente para aplicaciones de almacén de datos. Las aplicaciones de informaciÓn de empresa han aumentado considerablemente en popularidad en la última década. Los estudios de Corporate IS muestran que la mayoría de las grandes corporaciones tienen algún tipo de análisis de la empresa o proyectos de almacén de datos. En muchas formas, el almacén de datos representa que las bases de datos relacionales vuelven a sus raíces. Cuando las bases de datos relacionales aparecieron por primera vez en escena, las bases de datos establecidas (corno la base de datos lMS jerárquica de lB M) se centraron en las aplicaciones de procesamiento de transacciones de empresa. La tecnología 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 mayoría de los fabricantes de bases de datos relacionales cambiaron su centro de interés para competir por nuevas aplicaciones de procesamiento de transacciones. Con el almacén de datos, la atención ha vuelto a lo que formalmente se llama ayuda a la toma de decisiones, aunque con nueva terminología y herramientas mucho más potentes que las existentes hace 15 años. 757
758
Capítulo 21: SOL y los almacenes de datos
SOL. Manual de referenda
Conceptos de los almacenes de datos Uno de los fundamentos de los almacenes de datos es la noción de que las bases de datos para el procesamiento de transacciones y las bases de datos para el análisis 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 básicas diarias de una organización. En una
compañía manufacturera, las bases de datos üLTP admiten los pedidos de los clientes, las listas de pedidos de materiales, la gestión del inventario, la facturación a clientes y funciones similares. Los usuarios principales son las aplicaciones utilizadas por oficinistas que procesan los pedidos, trabajadores de producción, plantilla de los almacenes, etc. En cambio, el núcleo central de la información de empresa (BI. business incelligence) es ayudar a la toma de decisiones en la empresa mediante el análisis de los datos. Sus usuarios principales son normalmente los gestores del producto, los planificadores de la producción y los profesionales del marketing. La Tabla 21.1 muestra las diferencias más significativas entre los perfiles de las aplicaciones OLTP y la información de empresa, y las cargas de trabajo ep la base de datos que producen. El procesamiento típico de una transacción 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 número del cliente. • Comprobar el límite de crédito para dicho cliente.
Tabla 21.1.
Atributos de las bases de datos OLTP y de los almacenes de datos
Característica de la base de datos
I I
Base de datos OLTP
Base de ,datos de un almacén de datos
Contenidos de los datos Datos acmales. Estructura de los datos Tablas organizadas para adecuarse a la estructura de la transacción. Tamaño de tabla nonual Miles de filas. Patrones de acceso Predeterminados para cada tipo de transacción a procesar. Decenas. Filas a las que se ha accedido por. solicitud
Datos históricos. Tablas organizadas para ser fáciles de comprender y consultar.
Tratamiento de filas por acceso Tasa de acceso
Filas individuales.
Grupos (consultas resumen).
Muchas transacciones de empresa por segundo o minuto. Leer, insertar y actualizar. Productividad de las transacciones.
Muchos minutos u horas por consulta. Casi el 100 por ciento, leer. Tiempo de ejecución de las consultas.
Tipo de acceso Rendimiento
Millones de filas. Ad hoc, dependiendo de la decisión particular a realizar. De miles a millones.
759
• 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 disminución de la cantidad disponible. La carga de trabajo presenta un gran volumen de solicitudes pequeñas y sencillas a la base de datos que normalmente leen, escriben o actualizan filas individuales cuando se realiza una transacción. El mismo tipo de carga de trabajo se presenta en la mayoría 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 dirección de un cliente. Aumentar el límite de crédito de un cliente.
En cambio. una transacción típica de análisis del negocio (que genera un informe de análisis del pedido) puede comprender los siguientes accesos a bases de datos: • Reunir información 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 información 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 cálculo de totales y promedios y el resumen de los datos. Estas características son típicas de casi todas las consultas de análisis de la empresa tales como: • ¿Qué regiones tuvieron el mejor rendimiento el pasado cuatrimestre? • ¿Cómo han sido las ventas por producto el último cuatrimestre en relación con el año pasado? • ¿Cuál es la tendencia para las ventas de un producto? • ¿Qué clientes compran los productos de mayor crecimiento? • ¿Qué características comparten dichos clientes? La diferencia de las cargas de trabajo entre la información de empresa y OLTP es sustancial y hace difícil o imposible a un único SGBD servir a ambos tipos de aplicaciones.
760
Capítufo 21; SaL y fos almacenes de datos
SOL. Manual de referencia
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 almacén de datos. Un grupo distinto de vendedores se ha centrado en el análisis de los datos. Ha habido una cierta consolidación de vendedores en cada una de estas áreas, pero quedan compañías de software independientes, incluidas aquellas cuyos beneficios rondan los 100 millones de dólares. Las bases de datos de los almacenes de datos especializados también fueron el objetivo de varias compañías que se iniciaron en los albores del mercado de los almacenes de datos. Con elliempo, las grandes empresas de SGBD también 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 línea de productos y adquirieron compañías más pequeñas. En la actua· lidad el componente base de datos de la figura es casi siempre un SGBD basado en SQL especializado en almacén de datos proporcionado por alguno de los fabricantes principales de bases de datos.
Componentes de un almacén de datos La Figura 21.1 muestra la arquitectura del entorno de un almacén de datos. Hay tres componentes principales:
• Herramientas de carga del almacén de datos. Normalmente, un conjunto
1:
Operaciones del negocio
__
,.---A-¡
~
"
de programas que extraen datos de los sistemas de procesamiento de transacciones corporativos (bases de datos relacionales, archivos de grandes sistemas informáticos [mainframes] y minicomputadoras, bases de datos heredadas), procesan los datos y los cargan en el almacén de datos. Este proceso comprende. normalmente, una limpieza sustancial de los datos de la transacción, filtrándolos, dándoles nuevo formato y cargándolos de forma masiva en el almacén de datos. • Una base de datos del almacén 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 análisis ) del n e g o c i o . · • Herramientas de análisis del negocio. Normalmente, un conjunto.-de pro· gramas para ejecutar análisis estadístico y de series temporales, que realizan análisis de tipo «qué ocurriría si» y presentan los resultados de forma gráfica.
~
,
Análisis del negocio _ _A-,
r
La evolución de los almacenes de datos El objetivo inicial del almacén de datos fue la creación de enormes colecciones en el ámbito completo de la empresa de todos los datos acumulados de la empresa. Mediante la creación de dicho almacén de datos se podría generar casi cualquier posible pregunta sobre las prácticas del negocio en el pasado. Muchas compañías iniciaron el camino creando almacenes de datos con este enfoque, pero las tasas.de logros fueron pequeñas. Los grandes almacenes de datos en el ámbito completo de la empresa eran, generalmente, demasiado complicados de crear, demasiado grandes y también poco cómodos de usar en la práctica. Los objetivos finalmente se cambiaron a almacenes de datos más pequeños enfocados en áreas específicas que se podían beneficiar de un análisis profundo de los datos. Se acuñó el término puesto de datos (data mart) para describir estos almacenes de datos más pequeños (pero aún grandes). Con la llegada de múltiples puestos de datos en las empresas, un área reciente de interés ha sido la gestión de los puestos de datos distribuidos. En particular hay un gran potencial para la duplicación 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 producción. La respuesta que surge parece ser un enfoque coordinado a la transformación de datos para mercados distribuidos, en lugar de volver a usar enormes almacenes de datos. Los almacenes de datos y más recientemente los puestos de datos, han crecido notablemente en muchas industrias distintas. Se utilizan más ampliamente (y ram· bién más agresivamente) en industrias donde mejor se puede utilizar la información sobre las tendencias del negocio para tomar decisiones que ahorren o generen grandes cantidades de dinero. Por ejemplo:
....
, Almacén de datos
SGBD Herramientas
d. extracción de datos, nuevo formato y carga
i
I
1
Herramientas
d. análisis de datos e informes
'1 ,1
Aplicaciones 11 del negocio ,
,§.
• Alto volumen de fabricación. Los análisis de las tendencias de compra de lC!s clientes, estacionalidad, etc. pueden ayudar a planificar la producción de una empresa y disminuir sus niveles de inventario, ahorrando dinero.
I Figura 21.1.
.761
Componentes de un almacén de datos.
1
762
SOL. Manual de referencia
Capítulo 21: SOL y los almacenes de datos
• Bienes empaquetados. Los análisis de promociones (cupones, campañas de publicidad, correo directo, etc.) y la respuestas de los clientes con demografías diferentes pueden ayudar a determinar la forma más efectiva de alcanzar clientes, ahorrando millones de euros en publicidad y costes de promoción. • Telecomunicación. Los análisis de patrones de llamada de clientes pueden ayudar a crear planes de precios y promociones más atractivas, quizás atrayendo a nuevos clientes de un competidor. • Líneas aéreas. Los análisis de los patrones de viaje de los clientes son críticos para la gestión de campo, el proceso de determinar los pasajes y las restricciones asociadas sobre los asientos disponibles en las líneas aéreas para maximizar el beneficio. • Servicios financieros. Los análisis de los factores de crédito de los clientes y su comparación con los perfiles de cliente históricos pueden ayudar a tomar mejores decisiones sobre los clientes a quienes puede confiarse un crédito.
Arquitectura de las bases de datos para los almacenes de datos
Zapatos Accesorios Mantelerias Ropa
)
Cubos de hechos .,1,
:1 '
I
, I
En la mayoría de los casos los datos almacenados en un almacén de datos se pueden modelar adecuadamente como un cubo N dimensional (N-cubo) de hechos del negocio históricos. 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 dimensión es la región donde se realizaron las ventas. La tercera dimensión es el tipo de producto que se vendió. Cada celda en el cubo representa las ventas según la combinación de estas tres dimensiones. La cantidad de 50.475 € en la celda frontal superior izquierda representa las ventas para enero, en ropa, en la región Este. La Figura 21.2 muestra un sencillo cubo tridimensional, pero en muchas aplicaciones' de almacenes de datos habrá una docena de dimensiones o más. Aunque
ENE
50.475 €
67.463 €
89.475 €
FES
55.607 €
65.345 €
93.143 €
MAR
61.977 €
64.730 €
94.006 €
ASR
55.403 €
63.400 €
97.105 €
MAY
62.673 €
62.478 €
97.847 €
JUN
65.973 €
61.995 €
98.567 €
Oeste
Central
Este
Figura 21.2.
La estructura (esquema) de una base de datos de un almacén de datos se diseña normalmente para hacer que la información 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 categoría del producto y por región para comparar el rendimiento de diferentes productos en distintas áreas del país. El siguiente día algún analista puede desear ver las tendencias de ventas en el tiempo por región, 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 análisis en varias dimensiones distintas.
763
Representación tridimensional de los datos de ventas.
un cubo de doce dimensiones es complicado de visualizar, los principios son los mismos que para el ejemplo del cubo tridimensional. Cada combinación de valores dimensionales tiene un valor de hecho asociado, que es normalmente el resultado histórico del negocio obtenido para esa colección de valores dimensionales. Para ilustrar las estructuras de base de datos empleadas normalmente en aplicaciones de bases de datos utilizaremos un almacén de datos que se podría encontrar en una compañía de distribución. La compañía distribuye diferentes tipos de productos, hechos por diversos proveedores, a varios cientos de clientes ubicados en diversas regiones del país, mediante los esfuerzos de su plantilla de ventas. La . compañía desea analizar los datos de ventas históricas en estas dimensiones para descubrir tendencias y obtener intuiciones que ayuden a comprender mejor el negocio. El modelo subyacente para este análisis será un cubo de hechos de cinco dimensiones: • Categoría. Categoría del producto vendido, con valores tales como ropa, mantelerías, accesorios y calzado. El almacén de datos tiene alrededor de dos docenas de categorías de productos. • Proveedor. Proveedor que fabrica el producto. La compañía puede distribuir productos de 50 proveedores distintos. • Cliente. Cliente que adquirió los produclOs. La compañía 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
SOL. Manual de referencia
Capítulo 21: SOL y los almacenes de datos
• Región. Región del país donde se vendieron los productos. Algunos de los clientes de la compañía operan solamente en una región del país; otros operan en dos o más regiones. • Mes. Mes en el que se vendieron lt;>s productos. Por motivos de comparación, la compañía ha decidido mantener 36 meses (tres años) de datos históricos de ventas en el almacén de datos.
Tabla CATEGORíAS
~
<
I
I"
Esquemas en estrella
)
N
"-
It
X
XX
X
X
XYZ S A.
X
XX
X
X
KRTY S.A.
X
XX
X
X
DIMES S.L.
X
XX
X
X
X
XX
X
Mantelerías
X
XX
Acceso;r-ios
X
XX
X
Zapatos
x
XX
X
. ·
••
¡;; o w
X
.
. "-
Tabla CLIENTES
Tabla VENTAS (hechos) . .
r
•
" ~
En la mayoría de los almacenes de datos, la forma más efectiva de modelar el cubo de hechos N dimensional es con un esquema en estrella. Un esquema en estrella para el almacén de datos del distribuidor del ejemplo anterior ~e muestra en la Figura 21.3. Cada dimensión del cubo está representada por una tabla dimensional. Hay cinco de ellas en la figura, denominadas CATEGORÍAS, PROVEEDORES, CLIENTES. REGIONES Y MESES. Hay una fila en cada tabla dimensional para cada posible valor de esa dimensión. La tabla MESES tiene 36 filas. una por cada mes almacenado. Tres regiones producen la tabla de tres filas RE-
Acme
Ropa
~
Con estas características cada una de las cinco dimensiones es relativamente independiente de las otras. Las ventas a un cliente particular se pueden concentrar en una única región O en varias regiones. Una categoría específica 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 combinación particular de valores de la dimensión. Con los atributos que se acaban de describir, el cubo de hechos contiene 35 millones de celdas (24 categorías x 50 proveedores x 300 clientes x 3 regiones x 36 meses).
Tabla PROVEEDORES
r
r
.!!
765
~
<
Acme
X
XX
X
X
50.475 €
X
X
X
X
X
,
XYZ S A.
X
XX
X
X
64.370 €
X
X
X
X
X
KRTY S.A.
X
XX
X
X
93.143 €
X
X
X
X
X
DIMES S.L.
X
XX
X
X
61.090 €
X
X
X
X
X
57.443 €
x
X
X
61.090 €
X
X
X
X
93.500 €
X
X
X
oo
61. 056 €
X
X
X
=:
,
X ~
o
It
GIONES.
Las tablas dimensionales en un esquema en estrella contienen frecuentemente columnas con información descriptiva u otros atributos asociados con dicha dimensión (como el nombre del comprador para un cliente o la dirección del cliente y número de teléfono, o los términos 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 dimensión. Si los valores de una dimensión son números (como el tamaño de la prenda de vestir) o cadenas de texto cortas (como el nombre de la ciudad) la clave principal puede ser este valor de dimensión. Es más común expresar los valores de la dimensión en algún tipo de código. Los códigos de tres letras para los aeropuertos y los números de cliente son ejemplos típicos. En el almacén 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.), CATEGORíAS (ropa, calzado, etc.) y MESES. Las otras dos dimensiones utilizan valores codificados (CÓDIGO_CLIENTE para CLIENTES, CÓDIGO_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
Tabla MESES
r
.
"ill
~
¡-
ENE
1999
X
XX
FEa
1999
X
XX
MAR
1999
X
XX
ASR
1999
X
XX
"-
Figura 21.3.
· ·
~ Tabla REGIONES
~{
ESTE
X
XX
X
X
OESTE
X
XX
X
X
CENTRAL
X
XX
X
X
Esquema en estrella para el almacén de datos del distribuidor.
N-cubo de la Figura 21.2. Además, 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
SOL. Manual de referencia
Capítulo 21: SOL y los almacenes de datos
externas vinculan la fila a las filas de las tablas dimensionales correspondientes para su posición en el cubo. La tabla de hechos contiene normalmente sólo unas pocas columnas. pero muchas filas (cientos de miles o incluso millones de filas no es inusual en un almacén de datos de producción). La columna de hechos casi siempre contiene valores numéricos, tales como valores monetarios. unidades enviadas o recibidas, o kilogramos procesados. Virtualmente lodos los informes del almacén de datos involucran datos resumidos (totales, promedios, valores mayores o menores, porcentajes) basados en cálculos aritméticos sobre estos valores numéricos. 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 mayoría de las preguntas de análisis del negocio se convierten en consultas que combinan la tabla central de hechos con una o más tablas de dimensiones. Veamos algunos ejemplos.
Mostrar las ventas totales para ropa en enero, por región. 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. CÓDIGO_CLIENTE = CLIENTES. CÓDIGO_CLIENTE VENTAS. CÓDIGO_PROVEEDOR = PROVEEDORES. CÓDIGO_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 práctica 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 región de ventas. • Los datos de ventas se acumulan en meses, pero también puede ser útil mirar los resultados de forma cuatrimestral. Cada mes es parte de un cuatrimestre determinado.
767
• 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 básico, y, en la práctica, hay varias maneras de tratar con ellas: • Datos adicionales en las tablas dimensionales. La tabla dimensional geográfica puede contener información sobre las oficinas individuales, pero también puede incluir columnas que indiquen el distrito y región a la cual pertenece la oficina. Los datos agregados para estos niveles mayores de dimensión geográfica se pueden obtener resumiendo las consultas que combinan la tabla de hechos con la tabla dimensional s'e1eccionada según las columnas de distrito o región. Este enfoque es conceptualmente sencillo, pero significa que todos los datos agregados (resúmenes) 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 geográfica para incluir filas para oficinas, distritos y regiones. Las filas que contienen los datos resumidos (total) para estas dimensiones de más alto nivel se agregan a la tabla de hechos cuando se actualiza. Esto resuelve el problema de rendimiento de la consulta en tiempo de ejecución mediante un cálculo 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 región). 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 estadísticas debe incluir una condición de búsqueda que la limita a filas de solamente un nivel específico. • Resúmenes 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 geográfica). Esto resuelve el problema de hechos duplicados de la solución 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 más 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 según esta base. El patrón 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 ejecución y elimina la posibilidad de
768
SOL. Manual de referencia
datos erróneos de una única tabla de hechos, si bien puede agregar una complejidad significativa al diseño de la base de datos del almacén de datos. haciéndolo más difícil de entender. En la práctica es complicado encontrar el esquema y la arquitectura correcta para un almacén 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 compañías utilizan consultores especializados para ayudar a diseñar los almacenes de datos y tratar estos temas.
I'[
',1
l"
t 1 '
I)
,
"
I
¡' 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 gestión de datos para el análisis del negocio. La capacidad para relacionar libremente información de la base de datos basándose ú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 información de negocios y las capacidades del núcleo dellenguajé SQL. Por ejemplo: • Ordenación de los datos. Muchas consultas sobre información de negocios tratan con ordenación de datos explícita o implícitamente (se realizan preguntas como «¿cuál es ellO por ciento superior?», «¿cuáles son los diez mejores?» o «¿cuál es el peor rendimiento?». Como lenguaje orientado a conjuntos, SQL manipula conjuntos desordenados de filas. El único soporte para ordenar los datos en el estándar SQL es la cláusula ORDER BY en la instrucción SELECT, que se aplica solamente al final del procesamiento orientado a conjuntos. • Series temporales. Muchas consultas sobre información de negocios comparan valores basados en el tiempo (contrastando los resultados de este año con los del año pasado o los resultados de este mes con los del mismo mes del año pasado, o calculando los factores de crecimiento año a año, 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 estándar; esto dependerá de la estructura de . la base de datos subyacente. • Comparación con valores agregados. Muchas consultas sobre información 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 difíciles de expresar en SQL estándar. Es imposible generar directamente un formato de informe que muestre los detalles de artículos, subtotales y totales desde SQL, puesto que todas las filas de resultados deben tener la misma estructura de columna.
Capítulo 21: SOL y los almacenes de datos
769
Para tratar con estos temas los productos SOBO para almacenes de datos han tendido a extender el núcleo del lenguaje SQL. Por ejemplo, SGBD de Red Brick, uno de los pioneros del almacén de datos y ahora parte de la línea de productos Informix (que ha sido adquirida por IBM), disfruta de estas aportaciones como parte de su lenguaje Red Brick lntelligem SQL (RISQL): • Clasificación (Ranking). Admite consultas que piden los diez valores más altos y solicitudes similares. • Traslado de totales y promedios. Admite consultas que suavizan los datos para el análisis de series temporales. • Totales y promedios por periodos. Permite las respuestas a consultas que muestran los resultados individuales de meses más 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. • Decodificación. Simplifica la traducción de códigos de valores dimensionales (como el identificador del proveedor en el ejemplo del almacén de datos) en nombres comprensibles. • Subtotales. Permite la generación 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 análisis 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 específicas difieren sustancialmente.
Rendimiento de los almacenes de datos El rendimiento de un almacén de datos es una de las claves de su utilidad. Si las consultas sobre el análisis del negocio tardan mucho tiempo se tiende a no utilizar el almacén de datos para tomar decisiones. Si se tarda mucho tiempo en cargar los datos en el almacén de dalas, la organización del IS corporativo probablemente se resistirá a actualizaciones frecuentes, y los datos antiguos pueden hacer que el almacén de datos sea menos útil. Lograr un buen equilibrio entre el rendimiento de la carga y el rendimiento en el tiempo de ejecución es una de las claves para una implantación satisfactoria de un almacén de datos.
Rendimiento de la carga El proceso de cargar un almacén de datos puede ser muy costoso en tiempo. Es común que las cargas de datos de un almacén de datos tarden horas o incluso días
770
SOL. Manual de referencia
para almacenes de datos muy grandes. El procesamiento de carga normalmente comprende estas operaciones:
i'
• Extracción de datos. Los datos a cargar en la base de datos del almacén de datos vienen normalmente de varios orígenes 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 números de clientes O nú-" meros de productos incorrectos. El proceso de carga del almacén de datos incluye normalmente integridad de datos y comprobaciones de la sanidad de los datos. • Verificación cruzada de los datos. En muchas compañías se han desarrollado sistemas de procesamiento de datos que admiten varias operaciones del negocio en épocas diferentes y no están integradas. Los cambios proce.sados por un sistema (por ejemplo, agregar nuevos números de productQs/a una aplicación de procesamiento antigua) pueden no estar reflejados auto.máticamente en otros sistemas (por ejemplo, el sistema de control de inventario) o puede haber retrasos en la propagación de los cambios. Cuando los 'datos de estos sistemas no integrados llegan al almacén 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 almacén de datos. Los datos de caracteres pueden necesitar la transformación de una codificación 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. Además 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 almacén de datos. • Inserción/actualización de datos. Después del preprocesamiento, la carga de datos masiva real en una base de datos de un almacén de datos tiende a ser una operación especializada. Los cargadores de datos de grandes volúmenes operan normalmente en un modo orientado a lotes, sin una lógica de transacción y con una recuperación especializada. Se puede necesitar la carga de filas o factores de actualización de cientos de megabytes por hora. • Creación/actualización de índices. Se deben modificar los índices especializados utilizados por el almacén de datos para reflejar los contenidos revisados del almacén de datos. Al igual que en la inserción y actualización real de datos, normalmente se aplica un control especial. En algunos casos es más eficaz volver a crear rápidamente un índice entero que modificarlo incrementalmente cuando las filas de datos se insertan o actualizan. Otras estructuras de índices penniten más actualizaciones incrementales.
Capítulo 21: SaL y Jos almacenes de datos
771
Estas tareas son ejecutadas normalmente por programas de construcción de almacenes de datos especializados basados en procesamiento por lotes. El acceso a consultas ad hoc al almacén de datos está desactivado durante el procesamiento ~e actua.lizaciones. permitiendo que se ejecuten a la máxima velocidad sin compeUr por CIclos del SGBD. A pesar de estas optimizaciones, los tiempos de carga del almacén 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 ejecución 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 ejecución, pero a expensas de tiempos de carga inaceptablemente largos. Las estructuras más sencillas con menos trabajo de carga pueden incrementar el tiempo requerido para consultas ad hoc por encima de un nivel aceptable. En la práctica, el administrador del almacén de datos debe encontrar un buen equilibrio entre la carga y el rendimiento de la consulta en tiempo de ejecución.
Rendimiento de las consultas Los fabricantes de bases de datos centrados en los almacenes de datos han invertido una energía 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 dramáticamente en los últimos años. El crecimiento en tamaño 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 técnicas diferentes para maximizar el rendimiento de las consultas del análisis del negocio en un almacén de datos: • Esquemas de índices especializados. Las consultas de análisis del negocio normales comprenden un subconjunto de datos en el almacén de datos, seleccionados según los valores dimensionales. Por ejemplo, una comparación entre los resultados de este mes y el mes anterior comprende solamente dos de los 36 meses de datos en el ejemplo del almacén de datos. Los esquemas de índices especializados se han desarrollado para permitir una selección muy rápida de las filas adecuadas de la tabla de hechos y combinarlos en tablas dimensionales. Varias comprenden técnicas de mapas de bits, donde cada valor individual posible para una dimensión (o una combinación de dimensiones) se asigna a un único bit en un valor del índice. Las filas que cumplen un criterio de selección se pueden identificar muy rápidamente mediante operaciones lógicas de bits, las cuales se pueden calcular más rápidamente que las comparaciones por valores. • Técnicas de procesamiento en paralelo. Las consultas de análisis 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 reúna cuatro tablas de un almacén de datos, por ejemplo, el SGBD puede aprovecharse de un sistema de dos procesado-
772
SOL. Manual de referencia
res mediame la reunión de dos tablas en un proceso y otras dos en otro. Los resultados de estas reuniones intermedias se combinan después. De forma alternativa, la carga de trabajo del procesamiento de una única tabla en la consulta se podría dividir y llevar a cabo en paralelo (por ejemplo, asignando filas para rangos mensuales específicos para procesos específicos). 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 ejecución en respuesta a una única consulta compleja. • Optimizaciones especializadas. Cuando aparece una consulta de base de datos compleja que comprende criterios de selección 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 suposición de que las relaciones entres claves externas y claves principales se deberían realizar al principio de su procesamiento, puesto que tiende a disminuir drásticamente el número de filas en resultados intermedios. El optimizador1para una base de datos del almacén de datos puede poner en práctica una declsión bastante diferente, basada en la información acumulada durante el p;oceso de carga sobre la distribución de valores de datos en la base de datos" Como con el rendimiento del tiempo de carga, la maximización del rendimiento en tiempo de ejecución de un almacén 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 más procesadores_
Resumen
.!I fll'
,
i¡-
r
El almacén de datos es un apartado rápidamente 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 análisis del negocio típicas, que son bastante diferentes a las cargas de trabajo de OLTP. • Los programas de utilidades especializados proporcionan una carga de alto rendimiento para el almacén de datos y las herramientas de análisis 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 almacén de datos para admitir consultas de análisis del negocio típicas y para optimizar el rendimiento. • L~s extensiones de SQL se utilizan frecuentemente para admitir consultas de análisis del negocio típicas que comprenden series temporales y análisis de
Capítulo 21: SOL y los almacenes de datos
773
tendencias, ordenaciones según clasificaciones y comparaciones basadas en fechas. • Se requiere un diseño cuidadoso de un gran almacén de datos para proporcionar el correcto equilibrio entre el rendimiento de carga y el rendimiento en tiempo de ejecución.
CAPíTULO
22
SOL Y los servidores de aplicaciones
I~ ,
)
Los servidores de aplicaciones son una de las nuevas tecnologías principales originadas por el crecimiento de Internet. Los servidores de aplicaciones forman una capa clave en la mayoría de las arquitecturas de los sitios Web comerciales. Como el nombre indica, los servidores de aplicaciones proporcionan una plataforma para ejecutar la lógica de la aplicación que dirige la interacción del usuario en un sitio Web. Además, Jos servidores de aplicaciones realizan otra función importante: actúan como mediadores entre los componentes de la zona Internet en un sitio Web (los servidores Web y las herramientas de gestión de contenidos) y los componentes IT, tales como las aplicaciones corporativas heredadas y las bases de datos. En esta función los servidores de aplicaciones deben trabajar codo con codo con el software SGBD, y SQL es el lenguaje para esa comunicación. Este capítulo explora la función de SQL en una arquitectura de sitio Web multicapa construida utilizando servidores de aplicaciones.
SOL Y lo sitios Web: las primeras implementaciones
II
Los servidores de aplicaciones no siempre tuvieron una función 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 páginas Web estáticas. El contenido del sitio Web se estructuraba como una serie de páginas Web predefinidas almacenadas en archivos. Un servidor Web aceptaba solicitudes de los exploradores de usuario (en la forma de mensajes HTTP), localizaba ]a página o páginas solicitadas y las enviaba al explorador para su visualización, de nuevo utilizando HTTP. Los contenidos de la página Web se expresaban en HTML, el lenguaje de marcas de hipertexto. El código HTML para una página dada contenía texto y gráficos a mostrar en la página, así como los vínculos que albergaban la navegación desde esta página a otras. No se tardó mucho para que las demandas de información a repartir mediante World Wide Web sobrepasaran las capacidades estáticas de las páginas Web prede775
776
SOL. Manual de referencia
Capítulo 22: SOL y Jos servidores de aplicaciones
de comandos para el procesamiento de sitios Web. La mayoría de los lenguajes de secuencias de comandos son interpretados y la ejecución 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.
Internet
Solicitud
HTIP
I
Resultados HTML
r--'~---..JI---,
Los servidores de aplicaciones y las arquitecturas de tres capas de los sitios Web
Resultados HTML Secuencia
Ide comandos Perl
Figura 22.1.
i
:1
777
Sirviendo contenido Web dinámico sin un servidor de aplig..atíones.
finidas. Las compañías comenzaron a utilizar sitios Web para comunicarse con sus clientes y tenían que admilir capacidades básicas tales como búsquedas de productos específicos o aceptar el pedido de un cliente. El primer paso para proporcionar la capacidad de procesamiento actual en conjunción con mostrar una página Web fue proporcionado por los mismos servidores Web, como se muestra en la Figura 22.1. En lugar de aceptar solamente solicitudes de páginas Web estáticas, los servidores Web también aceptaron solicitudes para ejecutar secuencias de comandos, una serie de instrucciones que determinaban qué información mostrar. Las secuencias de comandos para servidores Web se escribían frecuentemente en lenguajes de secuencias de comandos especializados, tales como Perl. En su forma más simple, una secuencia de comandos podría realizar un cálculo muy sencillo (tal como recuperar la fecha y hora actual del sistema operativo) y mostrar el resultado como parte de una página Web. En un formulario ligeramente más complejo, la secuencia de comandos podría aceptar entradas introducidas por un usuario en una página 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 podía variar de una ejecución a la siguiente, la página Web resultante se convirtió en dinámica: sus contenidos podrían cambiar de una vista a la siguiente, dependiendo de los resultados de la ejecución de la secuencia de comandos. Los lenguajes de secuencias de comandos proporcionaron los primeros vínculos entre los sitios Web y las bases de datos SQL. Una secuencia de comandos podía, por ejemplo, enviar una consulta SQL al SGBn mediante una variación sobre la interfaz interactiva SQL y aceptar los resultados de la consulta para mostrarlos en la página Web. Sin embargo, hubo muchos problemas con las secuencias
La evolución lógica de las secuencias de comandos de los servidores Web fue la definición de una función separada para un servidor de aplicaciones, de lo que resultó una arquitectura en tres capas, según se muestra en la Figura 22.2. El servidor Web mantiene su responsabilidad principal de ubicar y servir páginas Web estáticas y trozos estáticos de páginas Web desde sus archivos. Cuando se requiere el procesamiento de una aplicación para determinar qué información visualizar o para procesar información proporcionada por el usuario, el servidor Web llama a un servidor de aplicaciones separado para ejecutar el procesamiento. En un sitio Web pequeño y de poco volumen el servidor d~ aplicaciones se puede ejecutar como un proceso separado en el mismo sistema físico que el servidor Web. En un caso más general, utilizado por sitios Web grandes, el servidor Web y el servidor de aplicaciones se ejecutarán 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 página. En los primeros días de los servidores de aplicaciones hubo una amplia gama de productos servidores de aplicaciones distintos. Algunos 'servidores requerían que las aplicaciones se escribieran en C o C++. Otros requerían 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 programación a los servicios admitidos, proporcionados por el servidor de aplicaciones a la API para acceso a bases de datos, no estaban estandarizados. La introducción por Sun Microsystem de E11terprise Java Beans (EJE) y Java2 E11terprise Edition (J2EE) inició la estandarización de los servidores de aplicaciones. EJB se construyó sobre la creciente popularidad de Java como lenguaje de programación. La especificación vino desde Sun, uno de los vendedores principales de servidores y una compañía ampliamente reconocida por su liderazgo en las tecnologías Internet. Las especificaciones también contenían una API estandarizada para el acceso a bases de datos, una de las funciones más importantes proporcionadas por un servidor de aplicaciones, en la forma de Java Database C011l1eCtivity (JDBC).
778
SOL. Manual de referencia
Capítulo 22: SaL y los servidores de aplicaciones
Explorador Web
i 1tI 1
Internet
Solicitud
HITP
Capa 1 -
Resultados HTML
Servidor{es) Web
(contenido estático)
)
Servidor{es) Web
Sol icitud Ap pSvr Capa 2 - Servidorles) de aplicaciones (contenido dinámico y lógica)
!
Capa 3 - Servidor(es) de bases de datos (gestión de datos)
'1
,1
1, I
i':! I ,1
Figura 22.2.
Resultados HTML
uno de los vendedores pioneros de servidores de aplicaciones J2EE. BEA Systems, un fabricante líder 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 líderes, rellenó su línea de productos adquiriendo Kiva, otro líder 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 gestión común en Sun, combinándose finalmente en el servidor de aplicaciones Sun iPlanet (cambiando posteriormente la marca del servidor de aplicaciones SunONE). HewlettPackard siguió con su propia adquisición de Bluestone, otro vendedor de servidores de aplicaciones. IBM se apartó de esta línea de adquisiciones construyendo su propio servidor de aplicaciones, con el nombre en el mercado de WebSphere. Oraele también 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 posición. Tras varios años de competencia agresiva, la especificación J2EE continuó evolucionando, e incorporó características 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 cumplía con la especificación 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
Sol icitud
Resultados
Sal
Sal Servidor(es) de bases de datos
779
-
Arquitectura en tres capas mediante el uso de un servidor de aplicaciones.
En poco tiempo los servidores de aplicaciones basados en la especificación 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 después, el mercado de servidores de aplicaciones comenzó a consolidarse. Sun adquirió NetDynamics,
La convergencia del mercado de servidores de aplicaciones alrededor de la especificación J2EE estandarizó la interfaz externa entre el servidor de aplicaciones y SGBn alrededor de JDBC. Conceptualmente, un servidor de aplicaciones puede acceder automáticamente a cualquier producto de bases de datos que ofrezca una API compatible con JDBe, y con ello logra independencia de SOBD. En la práctica existen sutiles diferencias entre los sistemas SGBD en áreas como dialectos SQL y nombres de bases de datos que todavía requieren algún ajuste y test, y manifiestan sutiles diferencias con el código implantado en el servidor de aplicaciones. Sin embargo, estas diferencias tienden a ser menores y su ajuste es relativamente sencillo. El enfoque de la gestión de datos para el código de la aplicación que se ejecuta en el servidor de aplicaciones es una tarea ligeramente más complicada. Aunque el servidor de aplicaciones proporciona servicios uniformes para la gestión de datos, lo hace en varias arquitecturas diferentes, utilizando distintos tipos de EJB en la especificación J2EE. El diseñador de aplicaciones debe elegir entre estos enfoques, y en algunos casos los mezclará y ajustará para lograr los requisitos de la aplicación. Veamos algunas de las decisiones que hay que adoptar:
780
i:·
SOL. Manual de referencia
• ¿Realizará la lógica de la aplicación un acceso directo a la base de datos desde una sessioll bean, o se representarán los contenidos de la base de datos como entidades heao, con la lógica del acceso a la base de datos encapsulada? • Si se utiliza un acceso directo desde sesiones beao, ¿puede la sesión beao permanecer sin estado (lo que simplifica el código de la heao y su gestión
por el servidor de aplicaciones), o requiere la lógica 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 aplicación apoyarse en la persistencia de los contenedores proporcionada por el servidor de aplicaciones, para gestionar la interacción de la base de datos, o la lógica de la aplicación requiere que la entidad bean proporcione su propia lógica 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 biunívoca entre las bean y las tablas de la base de datos subyacente (modelado de grano fino), o es más apropiado que las bean presenten una vista de mayor nivel, orientado a objetos, de los datos~bn los datos de cada bean extraídos de múltiples tablas de la base de datos (modelado de grano grueso)?
,1
r¡ "
Capítulo 22: SOL y los servidores de aplicaciones
781
a bases de datos (mediante JDBC). El contenedor también proporciona servicios de persistencia, preservando el estado de las bean entre diferentes activaciones. Las EJB vienen en dos tipos principales que son de interés desde una perspectiva de gestión de datos. Los tipos de EJB se ilustran gráficamente 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 asociación uno a uno entre cada sesión bean y el usuario en curso. En la Figura, los usuarios María, Juan y Samuel vienen representados cada uno por su propia sesión 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 sesión particular. • Entidades bean. Estas hean.representan objetos del negocio y lógicamente 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 biunívoca entre cada entidad bean y una oficina particular, que también 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 también está representada por los valores de columna en esta fila
Los compromisos representados por estas incertidumbres en el diseño proporcionan una perspectiva excelente sobre el reto de ajUstar SQL y la tecnología 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 programación 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.
Internet Sesiones de usuario
Tipos EJB
't '·1
,'.,11
:I I l
'1.,
[1 '1
En un servidor de aplicaciones compatible con J2EE, el código de las aplicaciones Java.desarrolladas por el usuario que implementan la lógica específica del negocio se empaquetan y ejecúIah como una colección de Effi. Un EJB es un conjunto bien definido de interfaces externas (métodos) que se deben proporcionar, y se escribe con un conjunto explícito de métodos públicos específicos 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 código que dependa de ellas. Las EJB se ejecutan en el servidor de aplicaciones en un contenedor, que proporciona un entorno en tiempo de ejecución para las bean y los servicios para ellos. Éstos van de servicios generales, como gestión de memoria para las bean y programación de su ejecución, a servicios específicos, como acceso a red y acceso
Sesiones bean Entidades bean
Figura 22.3.
·00 Servidor de aplicaciones __
Tipos de EJB,
Tabla de la base de datos
782
SOL. Manual de referencia
de la tabla OFICINAS. Este estado es independiente de cualquier sesión de usuario panicular. Cada tipo de bean puede acceder a una base de datos, pero normalmente 10 harán de forma bastante diferente.
Capítulo 22: SOL y los servidores de aplicaciones
783
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 difíciles o imposibles de implementar sin el uso de las bean con estado.
Acceso a bases de datos con sesiones bean Normalmente, una sesión bean accederá a una base de datos en una serie de una o más llamadas JDBC en nombre de un usuario representado por la bean. Un servidor de aplicaciones clasifica las sesiones bean en dos categorías, dependiendo de cómo gestiona la bean el estado:
• Sesión bean sin estado. Este tipo de bean no mantiene ninguna información del estado entre diferentes llamadas a los métodos. 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 restricción, cada invocación a la bean debe contener (en forma de parámetros pasadosJcon la invocación) toda la información necesaria para llevar a cabo la sorkitud. • Sesión bean con estado. Este tipo de bean mantiene la información del estado entre diferentes llamadas a los métodos. La bean necesita «recordar» la información de invocaciones previas (su estado) para llevar a cabo las tareas solicitadas por invocaciones posteriores. Utiliza variables de ejemplares privadas para albergar la información.
l.'
I I ,1 '1
I
Las siguientes dos sesiones muestran ejemplos de tareas que se implementan muy fácilmente con cada uno de los tipos de sesión bean. Se especifica si una sesión bean está sin o con estado en el descriptor de implantación de la bean, que contiene información proporcionada al servidor de aplicaciones sobre el cual se despliega la bean. Un servidor de aplicaciones en un sitio Web atareado puede fácilmente tener más sesiones bean y otros EJB en uso que los que la memoria puede almacenar. En esta situación el servidor de aplicaciones mantendrá un número limitado de ejemplares de sesiones bean activas en su memoria principal. Si un usuario asociado con una sesión 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 sesión de usuario que necesita la activación). Que una sesión bean esté con o sin estado tiene un impacto significativo en hacerla pasiva o activarla. Puesto que una sesión sin estado no necesita preservar su estado a través de llamadas a los métodos, 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 sesión bean con estado el servidor de aplicaciones necesita co-
Uso de JDBC desde una sesión bean sin estado La Figura 22.4 muestra un ejemplo sencillo de aplicación que se puede gestionar fácilmente con el acceso a una base de datos mediante una sesión bean sin estado. Una página en un sitio Web muestra el precio en curso de los productos de una compañía cuando se muestra la página. La página no puede ser estática, puesto que los precios mostrados cambian minuto a minuto. Por ello cuando el explorador del usuario solicita la página, el servidor Web envía la solicitud a un servidor de aplicaciones, el cual finalmente invoca un método de una sesión bean. La sesión bean puede utilizar JDBC para enviar una instrucción SELECT de SQL a una base de datos con los precios actuales de los productos, y devuelve la respuesta como una línea de resultados de consulta. La sesión bean vuelve a dar formato a la cuota de productos como un fragmento de una página Web y los devuelve al servidor Web para que los muestre al usuario. Las sesiones bean sin estado también pueden ejecutar funciones más complejas. Supongamos que la misma compañía tiene una página en su sitio Web donde un usuario puede solicitar un catálogo de productos rellenando los contenidos de un pequeño formulario. Cuando se rellena el formulario y el usuario pulsa el botón Enviar, el explorador envía los datos desde el formulario al servidor Web, el cual de nuevo envía la solicitud a un servidor de aplicaciones. Esta vez, se invoca un método diferente de la sesión bean y recibe los datos del formulario como parámetros. La sesión bean puede utilizar JDBC para enviar una instrucción SQL INSERT a la tabla de una base de datos que albergue las solicitudes de catálogo pendientes. . En cada uno de estos ejemplos, la información que la sesión bean necesita para realizar su tarea se pasa con la invocación al método. Cuando la bean ha completado su tarea, dicha información no se necesita más. La siguiente invocación recibe de nuevo toda la información necesaria, por lo que no es preciso conservar información de estado. Incluso, más importante, la actividad de la base de datos en cada invocación es completamente independiente del resto de invocaciones. Ninguna transacción de la base de datos implica múltiples llamadas a métodos.
Uso de JDBC desde una sesión bean con estado Muchas interacciones Web no pueden funcionar con las limitaciones impuestas por las sesiones bean sin estado. Consideremos un formulario Web más complejo que abarque cuatro páginas. Cuando el usuario rellena cada página y la envía al
784
SOL. Manual de referencia
Capitulo 22: SOL y los servidores de aplicaciones
f
Otro ejemplo en el cual una sesión bean con estado es adecuada es un sitio Web comercial donde un usuario compra en línea y acumula una lista de elementos a adquirir en una lista de compras en línea. Después 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 botón solicitando mostrar los contenidos actuales de la lista de compra, los contenidos probablemente se mantienen más fácilmente como una sesión bean con estado. En ambos ejemplos la sesión bean requiere la continuidad del acceso a la base de datos para realizar sus tareas. En la Figura 22.5 se muestra el patrón y las dife-
.Pantalla _..._.-
'1
ABe Carpo
Precio: 1 15,75€
Explorador Web
I
.
~
785
1-i Internet
id
Solicitud
HITP
1i
~
Solicitud AppSvr
~
~
Carta de compra
ResultadoS HTMl
Servidor Web
"
.Pantalla ... ..
•
...
Explorador Web
Elementos Pantalones Camisas Zapatos
j
.r
Resultados HTML
ti Internet
Servidor
de aplicaciones
I
Sesión
Se agregan varias llamadas a la carta de compra ___
besn
+'1
1
Servidor Web I
I ¡
I '"
Código
Java :1
Solicitud
1
Resultados Sal
Sal
Servidor de aplicaciones _1
Servidor(es)
1
..
_1 .Variables de ejemplares (conrenidos de fa carta de compra)
Sesión bean con estado
de bases de datos
Código Java
Figura 22.4.
··¡I
I I,
Llamadas a la base de datos desde una sesión bean sin estado.
Solicitud
Resultados
Sal
Sal Servidor(es) de bases de datos
sitio Web, la sesión beao debe acumular la información y retenerla durante las cuatro páginas hasta que todos los datos estén listos para ser enviados a la base de datos. Si es necesario retener infonnaci6n entre llamadas a métodos, entonces es preciso usar una sesión beao con estado.
Figura 22.5.
~'
Llamadas a la base de datos desde una sesión bean con estado.
786
SOL. Manual de referencia
rencias con el patrón de interacciones de la Figura 22.4. Incluso si la beao se puede implementar sin variables de ejemplar (por ejemplo, almacenando toda su información de estado en una base de datos dorsal) necesita una sesión 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 sesión, y la API misma necesitará mantener la información del estado de la sesión entre llamadas a métodos de la sesión beao.
Acceso a entidades con sesiones bean
,
'! I
l'
j
Es posible implementar aplicaciones para sitios Web completas y sofistic.:adas utilizando sesiones beao implantadas en un servidor de aplicaciones J2EE. Sin embargo la programación de una aplicación utilizando sesiones bean tiende a producir más código procedimental y menos orientado a objetos. La filosofía 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 interacción de la base de datos se gestiona directament~or las sesiones bean, la representación de las entidades del mundo real se deja. básicamente en la base de datos; no tiene una contrapartida de objeto. Las entidades bean proporcionan la contrapartida en términos 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 técnicas orientadas a objetos, invocando los métodos de las entidades bean que los representan. Para mantener este modelo orientado a objetos debe haber una cooperación muy fuerte entre las representaciones de entidades bean de las entidades y sus representaciones de base de datos. Si una sesión bean invoca un método de la entidad bean que cambia el límite de crédito de un cliente, dicho cambio se debe reflejar en la base de datos, de forma que una aplicación de procesamiento de pedidos que utilice la base de datos utilizará el nuevo límite. De forma similar, si una aplicación de gestión 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 según 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 tenían antes de que se hiciera pasiva, volviendo a cargar dichos valores de la base de datos. La clase de la entidad bean define los métodos d,e retrollamada que llna entidad bean debe proporcionar para implementar esta sincronización.
Capítulo 22: SOL y los servidores de aplicaciones
787
Hay una fuerte correspondencia entre las acciones llevadas a cabo en entidades bean y las acciones de la base de datos, según se muestra en la Tabla 22.1. La especificación J2EE proporciona dos maneras alternativas de gestionar esta Coordinación. • Persistencia gestionada por la bean. La entidad bean es la responsable de mantener la sincronización con la base de datos. El programador de la aplicación que desarrolla la entidad bean escribe sus métodos de implementación 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 interacción con la base de
datos . • Persistencia gestionada por el contenedor. El contenedor EJB proporcionado por el servidor de aplicaciones es responsable de mantener la sincronización con la base de datos. El contenedor supervisa la interacción con la entidad bean y automáticamente 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 aplicación que desarrolla la entidad bean y codifica sus métodos de implementación se puede centrar en la lógica de negocio de la bean y asume que sus variables de ejemplar representarán de forma precisa el estado de los datos en la base de datos. Tabla 22.1. Actividades de la base de datos y EJB
Instrucción de la base de datos
Método EJB
Acción EJBlbase de datos
INSERT
ejbCreate (), ejbPostCreate ()
Crea un nuevo ejemplar de entidad bean; el estado inicial de la bean se especifica mediante parámetros en la llamada a crea te (). Se debe insertar una nueva fila con estos valores en la base de datos.
SELECT
ejbLoad ()
Carga los valores de variables de ejemplar, leyéndolos de los datos persistentes en la base de datos.
UPDATE
EjbStore ()
Almacena los valores de variable de ejemplar, guardándolos de fonna persistente en la base de dalas.
DELETE
ejbRemove ()
Elimina un ejemplar de una entidad bean; se debe borrar la fila correspondiente en la base de datos.
11
I
788
SOL. Manual de referencia
Capítulo 22: SOL y los servidores de aplicaciones
La carga de la bean se gestiona de forma similar mediante una llamada del contenedor a ej bLoad () y almacenándola 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 interacción de la base de datos de la entidad bean a es(Os métodos ,de retrollamada. Si la bean necesita acceder a la base de datos durante la ejecución de uno de sus métodos, la hean puede hacer lo que necesite la llamada JDBe. Las llamadas JDBe en los métodos de retrollamada se cenlran estrictamente en la gestión de la persistencia de la bean.
Nótese que las entidades bean siempre son con estado (la distinción entre estos dos lipos de bean no es la diferencia entre bean con y sin estado, sino más bien la diferencia entre quién es responsable de mantener el estado adecuado. En las siguientes dos secciones de discutirán temas prácticos asociados con cada tipo de entidad bean y los compromisos entre ellas.
Uso de la persistencia gestionada por el contenedor
,11' '1
'::
El descriptor de implantación de una entidad bean especifica que una entidad bean requiere una persistencia gestionada por el contenedor. El descriptor de implantación también especifica la correspondencia entre las variables de ejemplar de la bean y las columnas en la base de datos subyacente. El descriptor de implantación también 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 sincronización 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 método 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 método ejbLoad () de la bean después 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 método 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 métodos de retrollamada estarán vacíos, puesto que el contenedor gestiona las operaciones reales de la base de datos.
Diferencias entre la gestión por el contenedor y por la bean
Nos podríamos 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 sincronización con la base de datos. La respuesta es que la persistencia geslionada por el contenedor liene algunas limitaciones:
Uso de la persistencia gestionada por la bean
Si el descriptor de implantación de una entidad hean especifica la persistencia gestionada por la bean, el contenedor asume que la entidad bean gestionará su propia interacción con la base de datos. Cuando se crea por primera vez una nueva entidad bean, el conlenedor llama a los métodos ejbCreate () y ejbPostCreate () de la bean. La bean es responsable del procesamiento de la instrucción INSERT correspondieme de la base de datos. De forma similar, cuando se va a eliminar una entidad bean, el contenedor llama al método ejbRernove () de la heao. La bean es responsable de procesar la instrucción DELETE correspondiente de la base de datos, y cuando la bean vuelve del método ejbRernove(), el contenedor es libre de eliminar re'almente la bean y reutilizar su uso.
789
,1
:-..
• Múltiples bases de datos. Para la mayoría 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 sincronización con la base de datos. • Múltiples 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 más 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 código 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 suposición 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 métodos de una entidad bean que implementan la lógica 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 cuándo se requieren las operaciones de la base de datos y cuándo la base de datos está ya actualizada.
790
SQL. Manual de referencia
En la práctica, esLas limitaciones evitan frecuentemente el uso de la persistencia gestionada por el contenedor en implantaciones actuales. Las mejoras en las nuevas versiones de la especificación EJB se diseñan para solventar muchos de estos inconvenientes. Sin embargo, la persistencia gestionada por la beao sigue siendo una técnica muy importante en los servidores de aplicaciones actualmente disponibles.
Mejoras de EJB 2.0
!
I
I
·I!
EJB 2.0 representa una revisión importante de la especificación 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 descripción 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 especificación 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 modelar»bjetos complejos que obtienen sus datos desde múltiples tablas de la base de daí9s o que contienen estructuras no relacionales tales como arrays y datos jerárquicos. Con EJB 1.x se podía 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 tenían que implementar en el código de aplicación dentro de la beao. Ideal· mente, estos detalles internos en el objeto complejo deberían estar ocultos del código de las aplicaciones. De forma alternativa, con EJB 1.x se podía 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 código de la aplicación, 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 métodos 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 explícitamente a un método de acceso get () para recuperar el valor de una variable de ejemplar, y a un método de acceso set () para establecer su valor. De forma similar, hay métodos de acceso abstractos get () y set () para toda relación que vincula las filas en la base de datos que proporcionan datos a la entidad bean. Las relaciones muchos a muchos se gestionan sencillamente haciéndolas corresponder con variables de colección Java. Con estas nuevas características 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 código de las aplicaciones. Sin embargo, ahora.se puede utilizar la
Capítulo 22: SOL y los servidores de aplicaciones
791
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 especificación EJB l.x es que mientras que las interacciones de la base de datos estaban estandarizadas, no lo estaban los métodos del buscador que se utilizaban para buscar las entidades bean activas. Los métodos del buscador implementan capacidades tales como la búsqueda de una entidad bean mediante la clave principal o la búsqueda del conjunto de beao que coinciden con un criterio particular. Sin esta estandarización, la portabilidad a través los servidores de aplicaciones estaba comprometida y las búsquedas de entidades bean requerían frecuentemente la búsqueda en la base de datos subyacente. EJB 2.0 soluciona las limitaciones de búsqueda mediante el uso de métodos de selección abstractos que buscan las entidades bean. Los métodos de selección 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 estándar SQL:1999 y sus tipos de datos abstractos. Admitir estos tipos simplifica en cierta forma la interacción 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 lógica de negocio de la aplicación es aumentado (quizás sustancialmente) por el acceso a la base de datos requerido para mantener la sincronización entre la entidad bean y la base de datos. Si el sitio Web implementa una fuerte personalización de su interacción con el usuario (esto es, un alto porcentaje de sus páginas se generan dinámicamente según 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 podría requerir la recuperación de los datos de perfil del usuario de una base de datos para dirigir la generación de la página. Finalmente, la interacción 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 determinación de si los usuarios perciben el sitio como rápido 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 páginas Web y la ampliación 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 páginas Web y se reduce la cantidad de tráfico de red asociado con dichas páginas. Con la escala horizontal, el contenido del sitio Web se replica en dos o más servidores Web (hasta docenas o incluso cientos de servidores) cuya capacidad para servir páginas es mucho mayor que en solamente un único servidor.
792
Capítulo 22: SQL y los servidores de aplicaciones
SOL. Manual de referencia
Desafortunadamente, el escalado horizontal y la caché tienden a funcionar enfrentándose entre sí cuando tratan con datos con estado, como los almacenados en una entidad bean o base de datos. Sin una lógica de sincronización de caché especial, las actualizaciones realizadas en una bean almacenada en la caché de un ejemplar del servidor no aparecerá automáticamente en las otras cachés, lo que supone una causa potencial de resultados incorrectos. Consideremos, por ejemplo, lo que le sucede al stock si tres o cuatro cachés contienen copias de una entidad bean de un único producto y la lógica del negocio del servidor de aplicaciones actualiza dichos valores. Las cachés contendrán muy rápidamente valores distintos para la cantidad, ninguna de las cuales es buena. La lógica de sincronización de las cachés requerida para detectar y evitar dicha situación supone desafortunadamente una gran cantidad de sobrecarga. Una sincronización absoluta requiere un protocolo de compromiso completo de dos fases (descrito en el Capítulo 23) entre las cachés. Las cachés de la base de datos pueden solventar problemas de varias cachés 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 sincronización 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 cachés 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. Todavía permanece abierta la pregunta de si la caché de bases de datos impactará sustancialmente al mercado de servidores de aplicaciones.
Se utilizan arquitecturas similares de caché y escala horizontal para aumentar la capacidad de los servidores de aplicaciones. La mayoría 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. Además, los servidores de aplicaciones se implantan normalmente en bancos o agrupaciones, con cada servidor de aplicaciones proporcionando idémica lógica 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 simétrico (SMP, Symmetric Multiprocessing). Es típico 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 configuración del servidor de aplicaciones típica con tres servidores con cuatro procesadores cada uno.
-)
LAN con conexión a Internet
Servidor A
Servidor B
793
Servidor C
,
I
I
Resumen 1I
1I §El
En este capítulo se han descrito los servidores de aplicaciones y el papel que desempeñan en el vínculo de World Wide Web con sistemas empresariales dorsales, incluyendo bases de datos empresariales:
§El
• Los servidores de aplicaciones populares implementan la especificación 12EE, que estandariza el acceso a las bases de datos mediante un IDBC API. • La lógica 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 transacción por invocación.
Réplica de caché Servidorlesl de bases de datos
Figura 22.6.
Servidores de aplicaciones y caché EJS.
lL
794
SOL. Manual de referencia
CAPÍTULO
Servidor de bases de datos Servidor de aplicaciones
..
/L -"
"
Base de datos residente en memoria
Redes SOL Y bases de datos distribuidas
SGSD
Internet
o
Perfiles de usuario A
~
<:
'" <
Aplicación Internet A
=>
Base de datos dorsal
v
Datos «calientes) en caché
Intern el
En las dos últimas décadas, las redes informáticas han transformado radicalmente el paisaje de la informática corporativa. En la mayoría de las compañías, 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 informáticas 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 compañías 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 están esparcidos por muchos sistemas diferentes, cada uno con su propio gestor de bases de datos. Frecuentemente, los diversos sistemas informáticos y los sistemas de gestión de bases de datos provienen de diversos fabricantes. Al intentar las compañías interconectar sus ·sistemas de procesamiento de datos mediante Internet, el reto se hace incluso más grande. Incluso si una compañía se las ha arreglado para estandarizar un único SGBD en toda la compañía y sobre estructuras de bases de datos, dichos estándares no se aplicarán a proveedores o clientes cuando se intenten generar vínculos externos para dirigir el negocio de fonna electr6nica. Estas tendencias han generado un fuerte interés en la industria de computadoras y en la comunidad de gestión de datos sobre los problemas de gestión de bases de datos en un entorno de red. Este capítulo 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.
)
'"
,¡ L,.
-
Base de datos residente ~ memoria
<1 Figura 22.7.
Intranet
L,.
~
• • •
23
~
• •• Servidores reproducidos
V Servidor
Web
•••
Servidores de aplicaciones y caché de bases de datos.
• Las sesiones bean con estado admiten transacciones que conllevan invocaciones, pero su lógica 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 automáticamente 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.
El desafio de la gestión de datos distribuidos Cuando se establecieron en la década de los setenta los fundamentos de )a gestión de bases de datos relacionales y el lenguaje SQL, casi todo el procesamiento de
I
1
795
796
Capítulo 23: Redes SOL V bases de datos distribuidas
SOL. Manual de referencia
datos comerciales se daba en grandes sistemas informáticos centralizados. Los programas de negocio que procesaban las transacciones y generaban los informes se ejecutaban en el sistema central y accedían a los datos. Gran parte de la carga de trabajo del sistema central era procesamiento por lotes. Los usuarios en línea accedían al sistema central mediante terminales de computadoras «tontos» que no tenían por sí mismos capacidad de procesamiento. El sistema central daba formato a la información a mostrar al usuario en línea 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 tenía la responsabilidad de aceptar, almacenar y recuperar los datos basados en solicitudes expresadas en el lenguaje SQL. La lógica para el procesamiento del negocio residía fuera de la base de datos y era responsabilidad de los programas de negocio desarrollados y mantenidos por la plantilla de los sistemas de información. 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 tráfico de red o fallos externos al sistema. \ El procesamiento comercial de dalas en una corporación moderna ha eyolucionado mucho desde el entorno centralizado de los años setenta. La Figura 23.1 muestra una parte de una red de computadoras que se puede encontrar en una compañía de fabricación, una empresa de servicios financieros o una compañía de distribución actual. Los datos se almacenan en una serie de sistemas informáticos en la red: • Grandes sistemas (mailJframes). Las aplicaciones de procesamiento de datos principales de la compañía, como la contabilidad y las nóminas, se ejecutan en un gran sistema mM. Las aplicaciones más antiguas, desarrolladas y mantenidas durante los últimos veinte o treinta años, todavía almacenan sus datos en bases de datos IMS jerárquicas. 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 organización de ingeniería del sistema utiliza estaciones de trabajo y servidores basados en UNIX (de Sun Microsystems) para el diseño de ingeniería, tests y soporte. Los resultados de los tests de la ingeniería y las especificaciones se almacenan en una base de datos Gracle. La compañía también utiliza bases de datos Gracle que se ejecutan sobre servidores basados en UNIX, de Hewlett-Packard, ubicados en seis centros de distribución para gestionar el inventario y procesar los pedidos. • Servidores LAN. Todos los departamentos de la compañía tienen LAN de PC para compartir impresoras y archivos. Algunos de los departamentos también tienen bases de datos locales para albergar su trabajo. Por ejemplo, el departamento de personal ha adquirido un paquete de software para la gestión de los recursos humanos y utiliza SQL Server sobre Windows NT para almacenar sus datos. En el departamento de planificación financiera el per-
Gran sistema corporativo
Ingenieria
-IMS - DB2
797
'5~1. Om," 5~1 .SOL S'~"
- MS Access - qBases de datos" Excel
Planificación
15~i .I,'ocm;,
5~1 Voo'" Distribución
Internet
~.
:" •
Internet
~- Sybase
Equipo de ventas
Figura 23.1. /
'e:- ••• e:./
Clientes
Uso de un SGBD en una red corporativa típica.
/
sonal de procesamiento de datos ha desarrollado una aplicación de planificación corporativa personalizada que utiliza Universal Server de Informix. • Computadoras personales de escritorio. Todos los trabajadores de la oficina de la compañía utilizan computadoras personales. Muchos de los asis~ lentes administrativos y algunos de los gestores mantienen bases de datos personales que utilizan hojas de cálculo 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 portátiles, La compañía ha adquirido recientemente un paquete de software para la automatización del equipo de ventas y ha equipado a los vendedores con un PC portátil. El portátil ejecuta presentaciones de ventas, envía y recibe correos electrónicos y también 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 también captura pedidos introducidos por el
1
798
SOL. Manual de referencia
vendedor. De noche, el pe portátil se conecta a una red corporativa mediante una conexión telefónica, transmite los pedidos y recibe información actualizada para su copia local de la base de datos de productos. • Dispositivos manuales. El equipo de gestión de la compañía ha adoptado ampliamente los asistentes digitales personales manuales (PDA). Además de las funciones de calendario personal y libreta de direcciones, las aplicaciones que se ejecutan en el PDA pueden utilizar conexiones a red inalámbricas para verificar Jos precios e introducir pedidos de clientes. La red inalámbrica también 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 compañía tiene un sitio Web de Internet donde los clientes, repartidores y distribuidores pueden encontrar la última información sobre sus productos y servicios. En primer lugar, esto solamente fue un sitio Web de sólo información, pero los competidores han comenzado recientemente a aceptar pedidos de clientes directamente a través de Internet. Una de las prioridades más 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 compañía. Con los datos esparcidos por muchos sistemas diferentes, es fácÜ de imaginar solicitudes que se extiendan más 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 estación de trabajo de ingeniería) con las previsiones de producción (en los grandes sistemas) para elegir entre tres tecnologías alternativas. • Un planificador financiero necesita vincular las previsiones financieras (en una base de datos Informix) a los datos financieros históricos (en el gran sistema). • Un gestor de productos necesita saber cuánto inventario de un producto particular hay en cada centro de distribución (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 distribución y también a todas las computadoras portátiles del equipo de ventas. • Los pedidos se tienen que actualizar diariamente de los sistemas portátiles y parcelarse en los centros de distribución; los datos de pedidos agregados de los centros de distribución se deben actualizar al gran sistema de forma que se pueda ajustar el plan de fabricación. • Los vendedores pueden aceptar pedidos de clientes y realizar estimaciones de las fechas de envío para productos populares según 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 envío proporcionadas a los clientes.
Capítulo 23: Redes SOL y bases de datos distribuidas
799
• Los cambios de ingeniería realizados en las bases de datos de la estación de trabajo pueden afectar a los costes de producción y a los precios. Estos cambios se deben propagar por los grandes sistemas, al sitio Web, los centros de distribución y las computadoras portátiles de los vendedores. • Los gestores de la compañía 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 computación distribuida. Los fabricantes de SGBD líderes están comprometidos en repartir la gestión 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 gestión de los datos distribuidos también ha sido el foco de la investigación en la universidad y de la investigación corporativa, y se han publicado muchos artículos técnicos sobre la teoría de la gestión de los datos distribuidos y los compromisos implicados. Hay un acuerdo general entre los investigadores sobre las características ideales que se deberían proporcionar mediante un esquema para gestionar las bases de datos distribuidas: • Transparencia de la ubicación. El usuario no se debería tener que preocupar sobre dónde están físicamente ubicados los datos. El SGBD debería presentar todos los datos como si fueran locales y ser responsable de mantener dicha ilusión. • Sistemas heterogéneos. El SGBD debería 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 debería funcionar de la misma forma sobre diferentes redes, desde LAN de alta velocidad a vínculos telefónicos de baja velocidad. • Consultas distribuidas. El usuario debería poder reunir los datos de cualquier tabla de la base de datos (distribuida), incluso si las tablas están 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 debería admitir transacciones distribuidas (mediante el uso de COMMIT y ROLLBACK) a través 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 debería proporcionar acceso universal y uniforme a todos los datos de la organización.
I
I
SOO
SOL. Manual de referencia
Ninguno de los productos SOBD distribuidos actuales se acerca a cumplir este ideal, y es poco probable que ningún producto lo haga alguna vez. En la práctica existen grandes obstáculos que hacen complicado proporcionar incluso formas sencillas de gestión distribuida de la base de datos. Estos obstáculos incluyen:
a;
"
!l'
1i
• 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 rápida, las velocidades de acceso se alargan a centésimas o décimas de segundo y los factores de lransferéncia pueden caer hasta 100.000 caracteres por segundo o menos. En un enlace de módem, el acceso a los datos puede tardar segundos o minutos y el máximo efectivo puede ser unos pocos miles de caracteres por segundo. Esta gran diferencia de velocidades puede ralentizar drásticamente el rendimiento del acceso a los datos remoto. • Integridad. Las transacciones distribuidas requieren la cooperación activa entre dos o más copias independientes del software SGBD ejecutándose en diferentes sistemas informáticos 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 tráfico de red y bloquean partes de las bases de datos que participan en la transacción distribuida durante largos periodos de tiempo. • SQL estático. Una instrucción SQL embebida estática se complica y almacena en la base de datos como un plan de la aplicación. Cuando una consulta combina los datos de dos o más bases de datos, ¿dónde se debería almacenar el plan de la aplicación? ¿Debe haber dos o más planes de cooperación? Si hay un cambio en la estructura de una base de datos ¿cómo se notifican los planes de aplicación a las otras bases de datos? Mediante el uso de SQL dinámico para solucionar estos problemas en un entorno de bases de datos en red casi siempre nos lleva a un rendimiento de la aplicación inaceptablemente lento, debido a las sobrecargas y retrasos de la red. • Optimización. Cuando se accede a los datos a través de la red no se aplican las reglas normales de optimización para SQL. Por ejemplo, puede ser más eficiente explorar de forma secuencial una tabla local entera que utilizar una búsqueda indexada en una tabla remota. El software de optimización debe conocer las redes y sus velocidades. De fonna general, la optimización se vuelve más crítica y más difícil. • Compatibilidad en los datos. Distintos sistemas infonnáticos 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 códigos de caracteres EBCDIC mientras que los servidores basados en UNIX y los PC utilizan ASCII. Uo SGBD distribuido debe enmascarar estas diferencias. • Catálogos del sistema. Cuando un SGBD lleva a cabo sus tareas, realiza accesos muy frecuentes a sus catálogos del sistema. ¿Dónde se debe tener el
Capítulo 23: Redes SQL y bases de datos distribuidas
S01
catálogo 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 organización estén 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 cooperación 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 características y tipos de datos, la capacidad de mantener un estándar 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 detección global de interbloqueos para una base de datos distribuida. De nuevo, esto requiere la coordinación del procesamiento a través de una red. y lo más probable es que lleve a un rendimiento de la aplicación inaceptablememe bajo. • Recuperación. Si uno de los sistemas que ejecuta un sistema SGBD distribuido falla, el operador de ese sistema debe poder ejecutar sus procedimientos de recuperación independientemente del resto de sistemas en la red, y el estado de recuperación de la base de datos debe ser coherente con el de los otros sistemas.
Distribución de datos: enfoques prácticos Debido a los formidables obstáculos en la realización 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 específicas de acceso a la base de datos en red, distribución de datos y gestión 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 rápida un subconjunto de datos de una base de datos 'principal y enviarlo a través 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 extracción, y para extraer y transmitir solamente los cambios a la base de datos maestra. Una versión posterior de la herramienta puede automatizar el proceso completo, proporcionando una interfaz de usuario gráfica para especificar los datos a extraer y las secuencias de comandos para automatizar los procesos periódicos de extracción. 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
802
SOL. Manual de referencia
Capitulo 23: Redes SOL y bases de datos distribuidas
la consulta remota como una subconsulta en una consulta que accede a las tablas de la base de datos local. Después, el SGBD puede permitir las consultas distribuidas que mezclan más libremente los datos de las bases de bases de datos locales y remotas.
Acceso a bases de datos remotas Uno de los enfoques más 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 opción de extenderse a través de una red y recuperar la información de una base de datos diferente. En su forma más sencilla, esto puede implicar la realización de una consulta sencilla en la base de datos remota, como se muestra en la Figura 23.2. También puede suponer la ejecución de una instrucción 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 satélite (como una base de datos en una oficina de ventas local o en un centro de distribución) y la base de datos remota es una ba~ae datos central y corporativa. ' Además de la solicitud de acceso a datos remotos, la Figura 23.2 tamhién muestra una solicitud cliente/servidor a la base de datos remota desde un usuario PC (diferente). Obsérvese que, desde el punto de vista de la base de datos remota, hay
Servidor local
"
lPcI l!-0ca:J
Consult, • []GBD SOL
;;:'¡:;-;:=::;¿"~ ·~l:----:--I ~
Servidor remoto
I----.~
[]GBD
Solicitud cliente!
s."'idO"~ Lpc ~
1----...
---
~
Resultados
o
803
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 través 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 través de la red. Sin embargo, la base de datos local en la Figura 23.2 debe realizar algún 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 cómo se puede acceder sobre la red. • Se debe establecer una conexión a la base de datos remota para llevar a cabo las solicitudes remotas. • Se debe determinar cómo se corresponden la autenticación del usuario local y el esquema de privilegios con la base de datos remota. Esto es, ¿simplemente pasa el nombre/contraseña del usuario proporcionada por el acceso de la base de datos local a la base de datos remota, o es un nombre/contraseña de usuario remoto diferente, o se debería realizar alguna clase de correspondencia automática? 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 conexión 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 específica 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 instalación Sybase local, el usuario puede enviar una instrucción 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 instrucción será: CONNECT TO SI5TEMACENTRAL
Base de datos local
Figura 23.2.
Base de datos remota
Solicitud de acceso a un servidor remoto de bases de datos.
Hace del servidor remoto el servidor actual para la sesión. El servidor local introduce un modo de «paso a través», enviando todas las instrucciones SQL al servidor remoto. Ahora se puede procesar la base de datos remota directamente sobre la conexión, con consultas estándar sin modificar e instrucciones de manipulación de datos:
Obtener los nombres y ventas de IOdos los vendedores que ya están por encima de la cuota.
S04
SELECT NOMBRE, CUOTA, VENTAS FROM REPRESENTANTES WHERE VENTAS > CUOTA
Cuando se completa el acceso remoto, una instrucción SQL acompañante: DISCONNECT
,I
finaliza el modo de paso a través y el servidor local se convierte de nuevo en el servidor actual. Ex.cepto por el par CONNECT/DISCONNECT, el mecanismo para la gestión 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 contraseña 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/contraseña 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 más complejas, pero1a capacidad básica tiene la ventaja de la máxima 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 más vínculos con la base de datos con nombre de la base de datos local o bases de datos remotas. Cada vínculo con la base de datos especifica: • • • •
Capítulo 23: Redes SaL y bases de datos distribuidas
SOL. Manual de referencia
La ubicación de la red del sistema informático remoto objetivo. Protocolo de comunicaciones a utilizar. Nombre de la base de datos Oracle en el servidor remoto. Nombre y contraseña de usuario para la base de datos remota.
Todos los accesos a la base de datos remota se producen a través del vínculo con la base de datos y están gobernados por los privilegios del nombre de usuario proporcionado en el sistema remoto. El vínculo a la base de datos incorpora por ello las respuestas a «qué base de datos», «cómo comunicarse» y «qué privilegios» que surgieron previamente en esta sección. El administrador de la base de datos asigna un nombre al vínculo de la base de datos. Los vínculos pueden ser privados (creados para el uso de un usuario específico del sistema local) o públicos (disponibles para varios usuarios del sistema local). Para acceder a una base de datos remota con un vínculo, el usuario del sistema local utiliza instrucciones SQL estándar. El nombre del vínculo 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 informático 10c~1 que está conectado a una copia de la base de datos de ejemplo en un sistema remo-
S05
to con un vínculo de la base de datos denominado SISTEMACENTRAL. Esta instrucción SQL recupera información de la tabla REPRESENTANTES remota:
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
Oracle incorpora casi todas las capacidades de consulta que están disponibles para la base de datos en bases de datos remotas. La única restricción es que toda entidad de la base de datos remota (tabla, vista, etc.) debe estar con el sufijo del vínculo de-la base de datos. Veamos una reunión 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
Oracle también incorpora la definición de datos y las operaciones de actualización llevadas a cabo en la base de datos remota. Veamos un ejemplo:
Crear una nueva tabla remota con información sobre el mayor límite de crédi· 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
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 extensión 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 múltiples 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
Capítulo 23: Redes SOL y bases de datos distribuidas
SOL. Manual de referencia
807
MACENTRAL. Entonces esta consulta es equivalente a los ejemplos anteriores de Ocaele y Sybase:
Con este sinónimo, el nombre de columna calificado anterior se vuelve muy sencillo:
Obtener los nombres y ventas de todos los vendedores que ya Izan superado la cuota.
REPS_REMOTOS.NOMBRE
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 (@) después 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 rápidamente 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 también una calificación de la base de datos). A continuación 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: [email protected]
¡Una única referencia a una columna ha crecido a media línea de texto SQL! Por esta razón se utilizan frecuentemente los alias a tabla en las instrucciones SQL que conllevan un acceso a bases de datos remotas. Los sinónimos y los alias (descritos en el Capítulo 16) también son muy útiles para proporcionar acceso más transparente a las bases de datos remotas. Veamos una definición de sinónimo Informix que se podría establecer por un usuario o administrador de una base de datos: CREATE SYNONYM REPS_REMOTOS FOR [email protected]
La definición equivalente de sinónimo Oracle es:· CREATE SYNONYM REPS_REMOTOS FOR JUAN.REPRESENTANTES@SISTEMACENTRAL
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 práctica la mayoría de las instalaciones de bases de datos accederán frecuentemente a tablas remotas que tendrán un conjunto de sinónimos definidos. La mayoría de las marcas SGBD incorporan sinónimos públicos (disponibles a todos los usuarios) y sinónimos privados que se crean para un usuario específico o grupo de usuarios. Con esta estructura, los sinónimos 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 sinónimos para el acceso a bases de datos transparentes un paso más allá y permiten las vistas en la base de datos local que están definidas en función de las tablas de la base de datos remota. Veamos una definición de vista Gracle que crea una vista denominada REPS_ESTE en la base de datos local. La vista es un subconjunto de información de la base de datos remota de ejemplo: Crear una vista local definida en función 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
Después de que se haya definido esta vista, un usuario puede plantear consultas en función de la vista REPS_ESTE, sin preocuparse por los vínculos con la base de datos o los nombres de las tablas remotas. La vista no solamente proporciona acceso remoto transparente, sino que también oculta al usuario la operación de reunión remota entre las tablas OFICINAS y REPRESENTANTES. El acceso transparente a los datos remotos, proporcionado por las vistas y los sinónimos, se considera usualmente una característica 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 también está oculta. Por consiguiente, aumenta la posibilidad de que un usuario O programador cree inadvertidamente una gran cantidad de tráfico 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 sinónimos y las vistas transparentes remotas. El acceso remoto transparente también 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 reunión cruzar las fronteras del servidor de bases de datos y relacionar información de la base de datos remota y la base de datos local? Se plantean
808
SOL Manual de referencia
Capítulo 23: Redes SOL y bases de datos distribuidas
preguntas incluso más 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 transacción? Puesto que los recursos remotos se han formado para que aparezcan como si fueran locales parece que la respuesta debería ser: «Por supuesto, las bases de datos local y remota deberían 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 transmisión de datos a través 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 práctica. Estas capacidades y sus implicaciones se analizan en detalle en la sección «Acceso a bases de datos distribuidas». La siguiente sección plantea una alternativa práctica -duplicación de datos o réplica de la base de datos- que se utiliza mucho más frecuentemente.
Extractos de tablas
I
Servidor central
Base de datos
EJ ~ B
«maestra»
GBD
Se",¡do, satélite
)
Base de datos «esclava»
El acceso remoto a la base de datos es muy conveniente para consultas remotas pequeñas y un acceso ocasional a la base de datos remota. Si una aplicación 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 más 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 extracción y distribución de datos. En su forma más simple, el proceso extrae el contenido de una tabla en una base de datos principal, lo envía a través de una red a otro sistema y lo carga en una tabla réplica corres~ pondiente en una base de datos esclava, como se muestra en la Figura 23.3. En la práctica, el extracto se ejecuta periódicamente 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. Sería un excelente candidato para la réplica en un centro de distribución o bases de datos para la automatización del equipo de ventas. Una vez que" las tablas reproducidas (locales) iniciales se establecen y rellenan, podría necesitarse actualizarlas solamente una vez por mes, o cuando se abre una nueva oficina de ventas. La tabla PRODUCTOS también es un buen candidato para la réplica. Los cambios en los precios de los productos se dan más frecuentemente que los cambios de oficinas, pero en la mayoría de las compañías suceden en lotes, quizás una
Figura 23.3.
SGBD
o'
L
Inserción! actualización! consulta
Y ""
~;I_EJI
'f'~_"":::::"
---="1 Tablas 1; Base de datos
~ Sólo lectura
809
OD
«esclavall
-
Sólo lectura
Arquitectura básica replicada maestro/esclavo.
vez a la semana o una vez al día. Con este ciclo de procesamiento natural, podría ser muy efectivo extraer una tabla con los datos del precio de los productos justo después de cada lote de actualizaciones y enviarlo a las bases de datos del centro de distribución y la base de datos central de automatización 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 extracción/actualización hará que los datos estén como los actuales, con un procesamiento de carga de trabajo menos sustancial. Es posible implementar este tipo de estrategia de tablas reproducidas sin ningún soporte de SGBD. Se podría escribir una aplicación 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 podría transmitir el archivo a los centros de distribución, donde otra aplicación podría leer sus contenidos y generar las instrucciones apropiadas DROP TABLE, CREATE TABLE e INSERT para rellenar la tabla reproducida.
~
810
SOL. Manual de referencia
Capítulo 23: Redes SOL y bases de datos distribuidas
El primer paso hacia la automatización de esta estrategia fue el desarrollo de programas de extracción de datos y de carga de datos. Estos programas de utilidades, ofrecidos por los fabricantes de SGBD, utilizan normalmente técnicas de acceso a las bases de datos propietarias, de bajo nivel, para extraer y cargar los datos mucho más rápidamente que mediante las instrucciones de SQL SELECT e INSERT. Más recientemente, las compañías de software han encontrado esta área como una oportunidad para paquetes de software autónomos, independientes de los fabricantes de SGBD. Esta categoría de software, denominada software para la integración de aplicaciones de la empresa (Enterprise Applicalion /ntegralion, EAI), se centra en la vinculación de sistemas informáticos dispares, paquetes de software, sistemas de bases de datos y formatos de archivos. La vinculación de diferentes SOSD es una pequeña parte de la solución total ofrecida por estos sistemas, que se personalizan de forma extensiva para cumplir las necesidades individuales de una compañía cuando se instalan. Los sistemas EAI ofrecen normalmente una interfaz de usuario gráfica para especificar la extracción 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, quizás una capacidad de almacenamiento y envío de los datos extraídos por parles antes y después de la transmisión, y utilidades para gestionar y sup~rvjsar el proceso completo.
de datos Gracle establece estos vínculos en la base de datos remota como parte de las capacidades Oracle distribuidas que se requieren para utilizar la instantánea. Finalmente, la instrucción CREATE SNAPSHOT hará que la tabla de instantáneas local PRECIOPROD se rellene con los datos de la tabla remota PRODUCTOS. Con este tipo de instantánea de sólo lectura, no se permite a los usuarios cambiar la tabla de instantáneas 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 (instantánea) mediante Grade. El administrador de la base de datos puede actualizar de forma manual la tabla instantánea cuando lo desee. La instrucción CREATE SNAPSHOT también incluye capacidades muy completas para especificar las actualizaciones automáticas. Veamos algunos ejemplos:
Crear una réplica 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
Crea una réplica local de los precios desde la tabla remota PRODUCTOS. Actualizar los datos una vez al día, enviando solamente los cambios desde la tabla principal.
Réplica de tablas
CREATE SNAPSHOT PRECIOPROD REFRESH FAST START WITH SYSDATE NEXT SYSDATE+l AS SELECT ID_FAS, ID_PRODUCTO, PRECIO FROM PRODUCTOS@VINCULO_REMOTO
Varios fabricantes de SGBD han avanzado más allá de sus programas de extracción y carga para ofrecer soporte para la extracción de tablas en el propio SGBD. Drade, por ejemplo, ofrece una utilidad de instantáneas para crear de forma automática una copia local de una tabla remota. En su forma más sencilla, la tabla local es una réplica de sólo lectura de la tabla remota principal, la cual se actualiza automáticamente y de forma periódica por el SGBD de Oracle. Veamos una instrucción 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:
Crear una réplica local de la informaci6n de precios de la tabla
PRODUCTOS.
CREATE SNAPSHOT PRECIOPRQD AS SELECT ID_FAS, ID_PRODUCTO, PRECIO FROM PRODUCTOS@VINCULO_REMOTO
Esta instrucción crea de forma efectiva una tabla local Oracle denominada PREContiene tres columnas, especificadas por la instrucción SELECT de la base de datos remola (principal). El signo «arroba» y el nombre VINCULO_REMOTO en la instrucción indican a Orade que la tabla PRODUCTOS, de la cual se van a reproducir los datos es una tabla remota, está accesible mediante el vínculo a la base de datos Oracle denominada VINCULO_REMOTO. El administrador de la base
811
CIOPROD.
I
J
En el ejemplo anterior, la instantánea se actualiza transmitiendo solamente los cambios de la tabla remota PRODUCTOS. Orac1e implementa esta capacidad manteniendo un registro histórico de los cambios (un registro histórico instantánea) en el sistema remoto y actualizando el registro histórico cada vez que la actualización de la tabla PRODUCTOS afecte a la réplica instantánea. Cuando llega la hora de una actualización, se utiliza la información del registro histórico instantánea. Para aplicaciones como ésta, en que los cambios en los precios de los productos probablemente afeclan sólo a un pequeño porcentaje de la tabla global, esta estrategia es efectiva. La sobrecarga adicional del mantenimiento del registro histórico para la tabla principal está más que compensada por el tráfico reducido de la red por la transmisión de únicamente los datos cambiados. En otras aplicaciones, donde se modificarán entre actualizaciones un gran porcentaje de las filas en la tabla principal, puede ser más eficaz realizar simplemente una actualización completa y eliminar la sobrecarga derivada de mantener el registro histórico de instantáneas. De forma predeterminada, Gracle identifica las filas (para detenninar si han cambiado) basándose en sus claves principales. Si la clave principal no fonna parte de los datos reproducidos, se puede producir confusión en cuanto a qué filas se han actualizado; en este caso Gracle utiliza un número de identificación de columnas
812
SOL. Manual de referencia
Capítulo 23: Redes SQL y bases de datos distribuidas
813
interno con el fin de identificar las filas modificadas para su actualización en la instantánea. La instrucción SELECT que define la tabla instantánea ofrece una capacidad muy general para la extracción de datos. Puede incluir una cláusula SELECT para extraer solamente las filas de la tabla principal:
sultas día a día sobre los datos de las instantáneas se llevan a cabo localmente y no generan tráfico de red. Para situaciones en que la carga de trabajo de la consulta sea mucho mayor que los costes de mantenimiento de la instantánea, ésta puede ser una forma efectiva de mejorar el rendimiento global de la base de datos.
Crear una réplica 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.
Réplicas actualizables En las implementaciones más sencillas, una tabla y sus réplicas tienen una relación 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 periódicas, 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 están permitidas. Si se intenta, el SOBD devuelve un error. De forma predeterminada, la instrucción de Oracle CREATE SNAPSHOT crea este tipo de réplica esclava de una tabla. La relación maestro/esclavo está implícita en la estructura Microsoft SQL Server para la réplica. 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 configuración predeterminada hay un único publicador (actualizable), y puede haber varios suscriptores (de sólo lectura). La arquitectura SQL Server lleva esta analogía un paso más allá, incorporando la noción de actualizaciones de inserción (el publicador envía de forma activa los datos actualizados a los suscriptores) y actualizaciones de extracción (donde los suscriptores tienen la responsabilidad principal de obtener actualizaciones del publicador). Hay algunas aplicaciones para las cuales la réplica de tablas es una técnica excelente, pero en las que no se aplica la relación maestro/esclavo. Por ejemplo, las aplicaciones que demandan una alta disponibilidad utilizan tablas replicadas para mantener copias idénticas de los datos en diferentes sistemas informáticos. Si un sistema falla, los otros contienen los datos en curso y pueden continuar el procesamiento. Una aplicación 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 informáticos y dividiendo la carga de trabajo entre los sistemas. Una aplicación de automatización del equipo de ventas contendrá probablemente una tabla central CLIENTE y cientos de réplicas en los sistemas informáticos portátiles, y los vendedores deberían poder introducir nuevos clientes o cambiar la información de contacto de un cliente en las réplicas de la computadora portátil. En estas configuraciones (yen otras) el uso más eficiente de los recursos de la computadora se logra si todas las réplicas 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 más réplicas? Cuando el SOBD intenta sincronizar las réplicas, ¿cuál de las de las 40s actualizaciones de las répli-
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
Obsérvese que esto hace que el mantenimiento del registro histórico de instantáneas sea más complejo. Oracle no necesita agregar al registro histórico todas las actualizaciones de la tabla PRODUCTOS; solamente aquellos que modifican la! filas que cumplen el criterio de búsqueda. La instantánea también se puede crear como una tabla de reunión, extrayendo sus datos de dos o más tablas principaÍes en la base de datos remota:
Crear una réplica 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
Añadiendo algo de complejidad, la instantánea se puede definir con una consulta de agrupación:
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 gestión de la instantánea y el proceso de réplica aumenta. Sin considerar lo sencilla o compleja que sea la definición de la instantánea, los principios generales son los mismos. En lugar de tener consultas sobre los datos reproducidos viajando a través de la red hacia la base de datos remota, los datos remotos se toman de la instantánea. Las actualizaciones sobre la instantánea todavía generan tráfico de red, pero las con-
l.
~
814
SOL. Manual de referencia
Capítulo 23: Redes SOL y bases de datos distribuidas
Servidor central
Base de datos central
SGBD
~~l;;~~F:::J actualización! Inserción} =-
consulta
Base de datos en un portátil
o )
Inserciónl actualizaciónl consulta
Figura 23.4.
CLIENTES
-1:::;;=::::;;;;;
Réplica
bidireccional
"jo.,rC"L.:.IENT=.:.E':"?1.L . Inserciónl
L----"'rr~ actualización! consulta
Réplicas con varios sitios actualizados.
cas se debería aplicar?, ¿no se debería aplicar ninguna, o deberían 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 réplicas actualizables, estos temas se solucionan creando un conjunto de reglas de resolución de conflictos que se aplican en el sistema de réplicas. Por ejemplo, cuando la réplica se establece entre una tabla central CLIENTE y versiones portátiles de la tabla, la regla de réplica puede decir que los cambios en la base de datos de clientes central siempre ganan sobre los cambios introducidos en un sistema portátiL De forma alternativa, la regla de la réplica podría decir que las actualizaciones más recientes siempre ganan. Además de las reglas incorporadas proporcionadas por SGBD, la definición de la réplica 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 selección del vencedor y el perdedor de las réplicas.
Compromisos de las réplicas Las estrategias prácticas de las réplicas siempre conllevan un compromiso entre el deseo de mantener los datos lo más actualizados posible y el de mantener el tráfico de red bajo desde el punto de vista práctico y proporcionar así un rendimiento ade~
815
cuado. Este compromiso normalmente conlleva no sólo consideraciones técnicas, sino también prácticas, así como directrices del negocio. Por ejemplo, consideremos una aplicación 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 están geográficamente repartidos alrededor del mundo. Cada centro de llamada tiene su propio sistema informático 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 compañía, en todo el mundo. Supongamos que la directiva de la compañía 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 después 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 diseños para la base de datos en este caso. Podría 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, podría haber una copia imagen completa de la tabla PRODUCTOS en cada uno de Jos cinco sitios. La solución de la imagen completa es, casi seguro, poco práctica, puesto que la actualización de la tabla PRODUCTOS cada vez que se toma un pedido provocará un tráfico de red excesivo para mantener las cinco copias de la tabla con una sincronización perfecta. Por otra parte supongamos que la compañía cree que puede mantener una satisfacción adecuada del cliente con una política 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 solución excelente. Una vez al día se puede actualizar la tabla PRODUCTOS descargando una copia en cada uno de los cinco sitios. Durante el día, los pedidos se verifican en la copia local de la tabla PRODUCTOS, pero solamente se actualiza la tabla PRODUCTOS local. Esto evita que la compañía tome un pedido para el cual no hay un stock adecuado al comienzo de la mañana, 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 comunicación de datos son menores que durante el día, 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 problemáticos, se transmite a cada uno de los cinco sitios para preparar el procesamiento del siguiente día. ¿Cuál es la arquitectura correcta para asumir la operación de este negocio global? Como el ejemplo muestra, no es tanto una cuestión de la arquitectura de la base de datos como una cuestión de la política del negocio. La interdependencia de las arquitecturas de los sistemas informáticos y las operaciones del negocio es una de las razones de que las decisiones sobre la reproducción y la distribución de datos hagan que unos tipos de operaciones del negocio sean más sencillos y otros más complicados.
816
Capítulo 23: Redes SOL y bases de datos distribuidas
SQL. Manual de referencia
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 dónde 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 distribución se reproducen en la base de datos local gestionada por el SGBD del centro. En este caso, la mayoría de las actualizaciones de la tabla PRODUCTOS tienen lugar en el mismo centro de distribución, puesto que, procesa los pedidos. Debi· do a que las réplicas del centro de distribución son mutuamente excluyentes (esto es, una fila de la tabla PRODUCTOS aparece en sólo una réplica del centro de distribución), se evitan los conflictos de actualización. Las réplicas en el centro de distribución pueden transmitir actualizaciones de forma periódica a la base de datos central para mantenerla actualizada.
Arquitecturas normales de réplica En muchos casos es posible estructurar una aplicación que implique a los datos reproducidos de forma que los conflictos entre las actualizaciones de la réplica se eviten o se minimicen en gran medida. Las reglas de resolución de conflictos en el SOBO se aplican entonces como último intento. cuando el conflicto se da 'Iugar a pesar del diseño de la aplicación. Las siguientes secciones describen algunos esce· narios de tablas reproducidas normales y la estructura de aplicaciór que se utiliza frecuentemente en cada escenario con el fin de minimizar los conflictos de réplicas.
/'
Subconjuntos de tablas horizontales Una forma eficiente de reproducir partes de una tabla a través 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 división horizontal de una tabla. En esta aplicación una compañía opera en tres centros de distribución, cada uno con su propio sistema informático y SGBD para gestionar una base de datos inventario y el procesamiento de pedidos. También se mantiene una base de datos central orientada a la planificación de la producción.
Subconjuntos de tablas verticales Otra fonna eficaz de gestionar la réplica 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 división vertical de la tabla. La tabla REPRESENTANTES se ha expandido para incluir nuevas columnas de infannación personal (número de telé-
'.
Sistema de procesamiento de pedidos
Casteflón
Fl3
Sistema personal
---.-1-
I
•
111111111111
Navarra
-r-
I I
I
•
-1:-
I
11I11I 11I11I
Daimiel
•
=E
Tabla REPRESENTANTES
111111111111
Figura 23.5.
Reproducción de trozos horizontales de una tabla.
-, Figura 23.6.
•
I
-1-
11I11I 11I11I
11I11I 11I11I
Tabla PRODUCTOS
817
Réplica de trozos verticales de una tabla.
I
818
SOL. Manual de referencia
Capítulo 23: Redes SOL y bases de datos distribuidas
fono, estado civil, etc.) y su información 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 información personal y las columnas relacionadas con los pedidos. Para acomodar esta aplicación 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 actualización 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 réplica generan tráfico de red y potencialmente requieren una resolución de conflictos.
--
Copias
Sistema A
•
de la tabla X
11I11I 11I11I ~~
819
-Sistema B
•
11I11I 111111
Tablas con espejo
Cuando se utiliza la reproducción 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 más sencilla de implementar esta .configuración 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 actualización 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 informático en espera baj? operación normal. Es necesario pagar y mantener el sistema, pero no agrega runguna capacidad de procesamiento. Por esta razón, los sistemas de alta disponibilidad se diseñan frecuentemente para que también proporcionen equilibrio de carga, como se muestra en la Figura 23.8. En esta configuración, algún software frontal intercepta las solicitudes de a~ceso al ~GBD y las distribuye equitativamente entre los dos (o más) sistemas mformátIcos. En una operación normal. ambos (todos) sistemas contribuye? a la capacid~d de procesamiento de los dat?s; no se malgasta ninguno. Ade. mas, es más fácIl conce~tualmente hacer crecer la capacidad de procesamiento de los datos agregando Simplemente más sistemas informáticos 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 actualización). Si el porcentaje de actuah~ac~on~s es may~r~ el potencial d~. conflictos y sobrecargas para la réplica puede dls~~ulr la efectividad y escalabilIdad de la configuración global. La eficiencia tamblen decr~ce con cada aumento en el número de sistemas reproducidos, puesto que aumenta la sobrecarga para la réplica.
Tabla X
Figura 23.7.
"
Réplica de tabla con espejo.
Una forma común de obtener mayor eficiencia de una configuración de tabla con espejo corno la de la Figura 23.8 es dividir las actualizaciones de la base de datos según 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 envíen a un sistema y las actualizaciones de los nombres de cliente que comienzan entre N y Z se envíen 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 todavía 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 más servidores de bases de datos.
Acceso a bases de datos distribuidas En los últimos años, la investigación de acceso a bases de datos completamente distribuidas ha encontrado de forma lenta, pero segura, su camino en los produc-
820
SOL. Manual de referencia
Capítulo 23: Redes SOL y bases de datos distribuidas Tabla 23.1.
Solicitudes de inserción/actualización! consulta
,..,
Software
Servidor
,
de distribución de carga
frontal
Enfoque de cuatro estados de IBM para acceso a bases de datos distribuidas
Estado
Descripción
Solicilud remola
Cada instrucción SQL accede a una única base de datos remota; cada instrucción es una transacción.
Transacción remota
Cada instrucción SQL accede a una única base de datos remota; se admiten transacciones de múltiples instrucciones para una única base de datos.
Transacción distribuida
Cada instrucción SQL accede a una única base de dalos remola; se admiten las transacciones de múltiples instrucciones p
Solicitud distribuida
Cada instrucción SQL puede acceder a varias bases de datos; se admiten las transacciones de múltiples instrucciones para varias bases de datos.
~~
, I
I \
,
SGBD
¡AV
,,~
A
,
'7
Tabla reproducida
Figura 23.8.
SGBD
c.....:::::!
~
A
:r-
El esquema de IBM proporciona un modelo sencillo para definir el problema del acceso a los datos distribuidos: el usuario de un sistema informático necesita acceder a los datos almacenados en uno o más sistemas informáticos. La sofisticación de los accesos distribuidos aumenta en función del estado alcanzado. Por ello, las capacidades proporcionadas por un SOBD dado se pueden describir en función del estado que ha alcanzado. Además, en cada estado, se puede realizar una distinci6n entre acceso de sólo lectura (con la instrucción 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.
'7 ~
~
• Réplica de N vías ..
821
Tabla
I
reproducida
I
Réplica para el equilibrio de carga.
Solicitudes remotas
tos comerciales. En la actualidad muchos de los productos de bases de datos empresariales principales ofrecen al menos algún nivel transparente de acceso a bases de datos distribuidas. Como se observó anteriormente en la sección «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 volúmenes muy diferentes de tráfico de red. Una única consulta realizada con un método de fuerza bruta o mediante un método optimizado puede crear las mismas diferencias, dependiendo de la calidad de la optimización 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 gestión 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 comprensión de las capacidades de gestión de los datos distribuidos y sus implica. ciones. .
El primer estado de acceso a los datos distribuidos, según definió 1BM, es una solicitud remota, según 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 instrucción SQL individual opera como su propia transacción, 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 múltiples instrucciones. Las solicitudes remotas son muy útiles cuando un usuario de pe necesita consultar datos corporativos. Normalmente, los datos requeridos están ubicados en una única base de datos, como una base de datos con datos para el procesamiento de pedidos o datos para la fabricación. Mediante el uso de una solicitud remota, un programa pe puede recuperar los datos remotos para su procesamiento en una hoja de cálculo, programa gráfico o paquete de edición.
'---
822
1
SOL. Manual de referencia
Sistema remoto
Sistema local
Transacción
Transacción
Transacción
Transacción
{ { { {
Transacción
Instrucción
Transacción
Sistema remoto
{
Instrucción
{
Instrucción
SGSD
Instrucción
Instrucción
iI I
e
l 1,
Sistema remoto
~~ ::a.
Instrucción
Figura 23.10.
Figura 23.9.
Sistema remoto
Sistema local
Instrucción
Instrucción
823
Capítulo 23: Redes SOL y bases de datos distribuidas
SGSD
I l'
1:
II
l
Acceso a datos distribuidos: transacciones remotas.
Acceso a los datos distribuidos: solicitudes remotas.
La capacidad de solicitud remota no es lo suficientemente potente para la mayoría de las aplicaciones de procesamiento de transacciones. Por ejemplo, consideremos una aplicación 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 quizás media docena de instrucciones SQL diferentes. Como se explicó en el Capítulo 11, la integridad de la base de datos puede estar corrompida si estas instrucciones no se ejecutan como una única transacción. Sin embargo, el estado de solicitud remota no admite transacciones de múltiples instrucciones, por lo que no puede admitir esta aplicación.
Transacciones remotas El segundo estado del acceso a los datos distribuidos, según definió IBM, es una transacción 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 múltiples 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 transacción. El SGBD garantiza que toda la transacción 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 instrucción 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 aplicación 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 transacción. 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 lógica 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 opinión sobre si se ha realizado una transaCCIón. 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 mayoría 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 más 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
Capítulo 23: Redes SQL y bases de datos distribuidas
SOL. Manual de referencia
bución 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 simultáneos no interfieran con el acceso remoto de la primera transacción. Las transacciones distribuidas son mucho más difíciles de proporcionar que los primeros dos estados del acceso a datos distribuidos. Es imposible proporcionar transacciones distribuidas sin la cooperación activa de los SGBD individuales involucrados en la transacción. Por esta razón 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 transacción SQL. Los detalles de este protocolo se describen posteriormente en la sección «El protocolo de compromiso de dos fases».
embargo, estas pasarelas no proporcionan (y no pueden, sin soporte del SGBD remoto) la lógica de la transacción subyacente requerida para albergar los estados mayores de acceso distribuido según 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 transacción 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 transacción distribuida (en lenguaje de lB M, una unidad distribuida de trabajo), mostrada en la Figura 23.1 L En este estado, cada instrucción SQL individual todavía consulLa o actualiza una única base de datos en un único sistema informático remoto. Sin embargo, la secuencia de instrucción SQL en una transacción puede acceder a dos o más bases de datos ubicadas en sistemas diferentes. Cuando la transacción se realiza o se deshace, el SOBD garantiza que ladas las partes de la transacción en todos los sistemas involucrados en la transacción se realicen o se deshagan. El SOBD garantiza específicamente que no haya una transacción parcial, en que la transacción 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 aplicación de procesamiento de pedidos basada en pe puede consultar las bases de datos inventario en dos o tres servidores de centros de distri-
Sistema local
Transacción
Transacción
Sistema remoto
{ {
Instrucción
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 instrucción SQL puede hacer referencia a tablas de dos O más bases de datos ubicadas en diferentes sistemas informáticos. El SGBD es responsable de resolver la instrucción automáticamente a través de la red. Una secuencia de instrucciones de solicitud
1
{' I InSUucd6n Transacción
Instrucción
1
Instrucción
Sistema remoto
Sistema local
I
Instrucción
~!,
Sistema remoto
:
Instrucción {
Transacción
~
In","",6n
I
InstruccIón
','
Figura 23.11.
Acceso a datos distribuidos: transacciones distribuidas.
'¡':,
825
Figura 23.12.
Acceso a los datos distribuidos: solicitudes distribuidas.
826
SOL Manual de referencia
distribuida se puede agrupar como una transacción. Como en el estado anterior de transacción distribuida, el SGBD debe garantizar la integridad de la transacción distribuida en todos los sistemas involucrados. El estado de solicitud distribuida no realiza ninguna nueva demanda sobre la lógica 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 transacción distribuida anterior. Sin embargo, las solicitudes distribuidas poseen nuevos reros para la lógica de optimización del SOBD. El optimizador debe ahora considerar la velocidad de la red cuando evalúa métodos alternativos para realizar una instrucción SQL. Si el SOBD local debe acceder repetidamente a parte de una tabla remota (por ejemplo, cuando realiza una reunión), puede ser más rápido copiar parte de la tabla a través de la red en una gran transferencia masiva, en lugar de recuperar de fonna repetida filas individuales a través de la red. Los tamaños relativos de las tablas en el sistema local y remoto también son factores de optimización relevantes, así como la selectividad de cualquier condición de búsqueda en la cláusula SELECT. Para algunas consultas las condiciones de búsqueda 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 deberían aplicar localmente. Para otras consultas que afectan a las mismas tablas, la selectividad relativa puede ser a la inversa y se debería aplicar la condición de búsqueda remota. Para otras consultas, la condición de reunión puede limitar las filas que participan en los sistemas local y remoto y puede ser más 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 también el coste derivado de enviar los resultados intermedios de los pasos de la ejecución de la consulta a través de la red. El optimizador también debe decidir qué copia de SGBD debería gestionar la ejecución de las instrucciones. Si la mayoría de las tablas están en un sistema remoto, puede ser una buena idea que el SGBD remoto en ese sistema ejecute la instrucción. Sin embargo, puede ser una mala elección si el sistema tiene una gran carga. Por ello la tarea del optimizador es más compleja y mucho más 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 tendría acceso completo a cualquier tabla en la base de datos distribuida y podría utilizar transacciones SQL sin conocer nada sobre la ubicación física de los datos. Desafortunadamente, se probaría rápidamente que este escenario es poco práctico en redes reales. En una red de cualquier tamaño, el número de tablas en la base de datos distribuida se haría rápidamente muy grande y a los usuarios les resultaría imposible encontrar los datos de interés. Se tendrían que coordinar todos los identificadores de usuario de todas las bases de datos en la organización para asegurar que un identificador de usuario dado identifica de forma única a un usua· rio en todas las bases de datos. La administración de la base de datos también sería muy complicada. En la práctica, 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 cuáles se mantendrán
Capítulo 23: Redes SOL y bases de datos distribuidas
827
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 autónoma 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 ningún SGBD comercial basado en SQL y pasará un cierto tiempo antes de que esté disponible una buena parte de sus características. Un paso importante hacia el procesamiento distribuido a través de las marcas de base de datos ha sido la estandarización de un protocolo de transacciones distribuido. El protocolo XA, originalmente desarrollado para coordinar varios supervisores de la transacción, también se está aplicando de forma activa a transacciones de bases de datos distribuidas. Una versión Java de la misma capacidad, denominada Java Transaclion ProLOcol (JTP), proporciona una interfaz de transacción distribuida para aplicaciones basadas en Java y servidores de aplicaciones. En la actualidad, la mayoría de los productos SGBD comerciales se han diseñado 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 transacción SQL si va a proporcionar transacciones distribuidas. El usuario de un SGBD distribuido espera que una transacción estará realizada en todos los sistemas en que los datos residan y también que una transacción deshecha estará deshecha en todos los sistemas. Además, los fallos en una conexión de red o en uno de los siste· mas debería provocar que una transacción se aborte y se deshaga, en lugar de dejar la transacción en un estado de realización parcial. Todos los SOBD comerciales que admiten las transacciones distribuidas utilizan una técnica 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 núcleo central del esquema es albergar las transacciones distribuidas sin saberlo. Sin embargo, la comprensión 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 transacción. Supongamos que el software SOBD en el sistema A intentó completar la transacción enviando simplemente un mensaje COMMIT al sistema B y al sistema e y después esperando sus contestaciones afirmativas. Esta estrategia funciona siempre que los sistemas B y e realicen satisfactoriamente su parte de la transacción. Pero ¿qué sucede si un problema como un fallo en un disco o una condición de interbloqueo evita que.el sistema e realice la transacción como se le ha solicitado?
828
saL.
Sistema
Sistema A
Sistema B
UPDATE
UPDATE
COMMIT
COMMIT
C---'
Sistema B
Sistema A
UPDATE
UPDATE GET READY
GET READY OK
OK
(comprometida)
•
• •
• •
•
• • •
INSERT
INSERT
UPDATE
UPDATE
COMMIT
..
(
OK
COMMIT ¡Vaya!
NO
I
e
Figura 23.14.
COMlUT
•
INSERT
IN5ERT
• •
COMMIT
1
GET READY NO
NO
OK
)
¡Vaya! (retrocedida)
(
ROLLBACK OK
lIé )
ROLLBACK
-
El protocolo de compromiso de dos fases.
Problemas en un esquema de compromiso difundido.
3. El sistema B realizará su parte de la transacción y enviará su notificación. El sistema e deshará su parte de la transacción debido al error y enviará un mensaje de error, y el usuario finalizará con una transacción parcialmente realizada, parcialmente deshecha. Nótese que el sistema A no puede cambiar de opinión en este punto y pedir al sistema B que deshaga la transacción. La transacción en el sistema B se ha realizado y otros usuarios pueden ya haber modificado los datos en el sistema B basándose en los cambios realizados por la transacción. 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:
2.
1)
•
en el sistema B pero se ha retrocedido en el
1.
OK
UPDATE
ROLLBACK ROLLBACK
GET READY
• •
... GET READY GET REAOY
1)
COMMIT
(comprometida)
UPDATE
)
(
)
• • •
~ ROLLBACK
I
OK
COMMIT
..... Error: la transacción se ha comprometido
Figura 23.13.
e
COMMIT
sí COMMIT
C
INSERT
SÍ
COMfHT
1)
Sist,
INSERT
INSERT
INSERT
(
829
Capítulo 23: Redes SOL y bases de datos distribuidas
Manual de referencia
4.
El programa en el sistema A envía un COMMIT para la transacción 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 envía un mensaje GET READY a los sistemas B y C y anota el mensaje en su propio registro de transacciones.
S.
...-.J
Cuando el SGBD en el sistema B o C reciba el mensaje GET READY, debe prepararse para realizar o deshacer la transacción 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 histórico 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 envía un mensaje COMMIT a ambos sistemas B y C y anota la decisión en su registro histórico 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 envía un mensaje RQLLBACK a ambos sistemas y anota esa decisión en su registro histórico 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 transacción de forma autónoma cuando se res~ ponde SÍ al mensaje GET READY en el paso 3. El SGBD realiza o deshace su parte de la transacción según se solicita, escribe el mensaje COMMIT o
e
830
SOL Manual de referencia ROLLBACK en su registro histórico de transacciones y devuelve un men-
6.
saje OK al sistema A. "Cuando el sistema A haya recibido lOdos los mensajes OR, sabraque la transacción se habrá realizado o deshecho y devolverá el valor SQLCODE adecuado al programa.
Este protocolo protege la transacción distribuida de cualquier fallo en el sistema B, el sistema e o en la red de comunicaciones. Estos dos ejemplos ilustran cómo el protocolo permite la recuperación 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 transacción. El programa de recuperación en el sistema e no encontrará el mensaje sí o un mensaje COMMIT en el registro histórico de transacciones local y deshará la transacción en el sistema e como parte del proceso de recuperación. Todas las partes de la transacción se habrán deshecho en este punto. • Supongamos que ocurre un fallo en el sistema e antes de que envíe un mensaje sí en el paso 3. El sistema A decidirá si realizar o deshacer la transacción distribuida basándose en la respuesta del sistema B. El programa de recuperación en el sistema C encontrará un mensaje sí en el registro histórico de transacciones local, pero no encontrará un mensaje COMMIT o ROLLBACK para marcar el final de la transacción. El programa de recuperación pregunta entonces al coordinador (sistema A) cuál fue la disposición final de la transacción y actúa en consecuencia. Nótese que el sistema A debe mantener un registro de su decisión para realizar o deshacer la transacción hasta que reciba el OK final de todos los participantes, de forma que puede responder al programa de recuperación en caso de fallo.
El protocolo de compromiso de dos fases garantiza la integridad de las transacciones distribuidas, pero genera una gran cantidad de tráfico de red. Si hay n sistemas implicados en la transacción, el coordinador debe enviar un total de 4 * n mensajes para realizar satisfactoriamente la transacción. Nótese 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 tráfico de mensajes si una transacción distribuida va a proporcionar integridad de la base de datos en el caso de fanos del sistema. Debido a la gran carga de tráfico de red, las transacciones distribuidas pueden tener un efecto seriamente negativo en el rendimiento de la base de datos. Por esta razón se deben diseñar cuidadosamente las bases de datos distribuidas de forma que los datos a los que se accede frecuentemente (o al menos que se actualizan frecuentemente) estén en un sistema local o en un único sistema remoto. Si es posible, deberían ser relativamente raras las transacciones que actualicen dos o más sistemas remotos.
Capítulo 23: Redes SOL y bases de datos distribuidas
831
Aplicaciones de redes y arquitectura de bases de datos Las innovaciones en las redes informáticas 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. Ofrecían una plataforma para soporte en la decisión, basada en datos descargados desde grandes sistemas. También admitían 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 innovación 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 década de los noventa. Posteriormente, la formación 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 innovación, porque las tasas de transacciones con altos picos de carga y la interacción personalizada con los usuarios guían las tecnologías de las cachés de bases de datos y las bases de datos residentes en memoria.
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 visualización en pantalla (presentación), los cálculos y el procesamiento de datos (lógica del negocio), hasta el acceso a la base de datos ocurría 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 gráfica de usuario (GUI, Graphical User lnteiface) del software de automatización de oficinas PC populares (hojas de cálculo, procesadores de texto, etc.) estableció un nuevo estándar de facilidad de uso, y las compañías demandaban el mismo estilo de interfaz para las aplicaciones corporativas. Admitir una GUI requiere mucha carga en el procesador y también 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 través de LAN (el protocolo X-windows), la mejor ubicación para ejecutar un código de capa de presentación de una aplicación de producción era claramente el mismo Pe. La economía fue también un factor. Los sistemas informáticos personales eran mucho más baratos, en ténninos del coste por potencia de procesamiento, que las minicomputadoras o los servidores basados en UNIX. Si buena parte del procesa-
832
SOL. Manual de referencia
Capítulo 23: Redes SOL y bases de datos distribuidas
miemo de una aplicación del negocio podía tener lugar en pe de bajo coste, ~el coste total del hardware para implantar una aplicación se reduciría. Esto fue un argumento para cambiar, no solamente la capa de presentación, sino gran parte de la capa de la lógica 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 están implantando actualmente utilizando esta arquitectura. SQL desempeña una función clave como lenguaje cliente/servidor. Las solicitudes se envían desde la lógica de la aplicación (en el pe) al SOBD (en el servidor) expresadas en instrucciones SQL Las respuestas vuelven a través de la red en forma de cóqigos de estado de terminación de SQL (para las actualizaciones de la base de datos. o resultados de la consulta SQL (para solicitudes de información).
capacidad de transmisión 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 instrucción SQL) genera al menos un viaje de ida y vuelta a través de la red. En una aplicación OLTP. las transacciones normales pueden requerir hasta más 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 aplicación de procesamiento de pedidos puede: • Ree;.uperar el número de cliente según el nombre del cliente (SELECT de una única fila). • Recuperar el límite de crédito del cliente para comprobar su capacidad de crédito (SELECT de una única fila). • Recuperar la información 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 información del producto para reflejar una menor cantidad disponible (UPDATE). • Actualizar el límite de crédito del cliente, reduciendo el crédito disponible
Aplicaciones cliente/servidor con procedimientos almacenados Siempre que una aplicación se divide entre dos o más sistemas informáticos en red. como en la Figura 23.15, uno de los problemas principales es la interfaz entre las dos mitades de la aplicación dividida. Cada interacción a través de esta interfaz genera tráfico de red y ]a red siempre es la parte más lenta del sistema global. en su
Computadora personal
(UPDATE).
• Llevar a cabo toda la transacción
con un':iotal de siete viajes de ida y vuelta entre la aplicación y la base de datos. En una aplicación real el número de accesos a la base de datos puede ser dos o tres veces esta cantidad. Al crecer el volumen de transacciones, la cantidad de tráfico 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 tráfico 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 lógica para toma de decisiones requerida para llevar a cabo todas las operaciones de la base de datos asociadas con la transacción. Básicamente, parte de la lógica del negocio que anteriormente residía en la aplicación misma se ha movido a través de la red al servidor de bases de datos. En lugar de enviar instrucciones SQL individuales a SGBD, la aplicación 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 crédito del cliente), se devuelve un código de error y un mensaje que lo describe. Mediante el uso del procedimiento almacenado se reduce el tráfico de red a una única interacción cliente/servidor. Hay otras ventajas de utilizar los procedimientos almacenados, pero la reducción en el tráfico 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 propósito general ofrece ahora esta capacidad.
SGBD
Resultados
• • Base de datos
Figura 23.15.
(COMMIT).
'1i,:!-
Servidor de bases de datos
Instrucciones Sal (1 solicitud/instrucciónl
833
Arquitectura de las aplicaciones cliente/servidor.
~
834
Capítulo 23: Redes SOL y bases de datos distribuidas
SOL. Manual de referencia
Computadora personal
Computadora personal
Servidor de bases de datos
Aplicación Windows o explorador '---
SGSD
I ~
-
¿
Solicitudes de bases de datos
~ ~
o
Servidor de bases de datos
Servidor de aplicaciones
Entrada de usuario
Mostrar datos
Aplicación empresarial
~
835
B
~
Resultados
~-..
~
A
-HV
Base de datos
Base de datos
Figura 23.16.
Arquitectura cliente/servidor con procedimientos almacenados.
Aplicaciones empresariales y caché de datos En la actualidad la mayoría 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 más potencia de procesamiento total a la aplicación, se utiliza frecuentemente una arquitectura de tres capas mostrada en-ia Figura 23.17. Incluso con el uso de procedimientos almacenados para minimizar el tráfico de red, la red y las demandas de acceso a la base de datos de la mayoría 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 aplicación de planificación de una cadena proveedora que ayuda a una compañía de fabricación a determinar las piezas que debe pedir a los proveedores. Para generar un plan completo, la aplicación 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.
\,--_--,_--,1 y-
\'--_yr---JI
Frontal
Capa intermedia
Figura 23.17.
\~_....,
-
_ _~J
y-
Dorsal
Arquitectura de tres capas de una importante aplicación em~ presarial.
Si se escribe milizando técnicas de programación sencillas, la aplicación para la planificación debe ejecutar una consulta a la base de datos para determinar el total de partes de todos los productos, y después todos los subcomponentes, para todos los pedidos, y acumular la información necesaria total en la base d~ d~tos de planificación para cada una de estas piez~s. Mediante. el uso de .esta tecfilca, la aplicación tardará horas en procesar los CIentos de mIles de pedIdos que puede haber actualmente en los libros. En realidad la aplicación 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 compañía ejecuta dichas aplicaciones. . . . Para conseguir un rendimiento aceptable, todas las aplicaCIOnes empresanal~s con datos intensivos emplean técnicas de caché, enviando los datos fuera del serv¡· dor de la base de datos, más cerca de la aplicación. En la mayoría de los casos, ~a aplicación utiliza técnicas 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 aplicación. Eliminando las consultas ,de la estruct~ra de los product.os.repetidas intensivamente, el programa puede mejorar dramáticamente su rendImiento. Recientemente los fabricantes de aplicaciones empresariales han comenzado a utilizar técnicas de caché más complejas. Pueden reproducir los datos a los cuales
836
Capítulo 23: Redes SOL V bases de datos distribuidas
SOL. Manual de referencia
se accede más frecuentemente (los datos calientes) en una tabla duplicada de la base de datos, en el mismo sistema que la aplicación. 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 pequeña 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 réplica avanzadas serán más importantes en respuesta a requisitos de negocio emergentes. Las compañías de fabricación líderes desean una planificación en tiempo real, donde los pedidos entrantes de los clientes y los cambios impacten inmediatamente en los planes de producción. Desean ofrecer productos más personalizados. con más configuraciones, con el fin de cumplir más específicamente los deseos de los clientes. Estas tendencias continuarán 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 métodos para manipular la gestión de datos de alto rendimiento están comenzando a seguir a los ya establecidos para la gestión de páginas Web de alto rendimiento. Los temas para las bases de datos son más complicados debido a factores de integridad de la base de datos, pero las técnicas emergentes son similares (réplica, acceso de lectura de gran volumen. bases de datos residentes en memoria y arquitecturas altamente tolerantes a fallos. Estas demandas crecerán solamente si el tráfico en Internet y la personalización continúan aumentando, llevándonos a arquitecturas de bases de datos en red más avanzadas.
Servidor de bases de datos
Gestión de grandes volúmenes de datos en Internet
Servidor de aplicaciones
<::...-..>1
I
¡
Las aplicaciones de Internet con grandes volúmenes de datos también están dirigiendo la tendencia a caché de base de datos y réplica en arquitecturas de base de datos en red. Por ejemplo, las empresas de servicios financieros están compitiendo por atraer a clientes por Internet ofreciendo informes de stock en tiempo real y capacidades de análisis cada vez más avanzadas. La gestión de datos para albergar esta aplicación exige la alimentación de datos en tiempo real (para asegurar que la información 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 volúmenes 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 también 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 páginas Web a las que se accede frecuentemente se envían a la red y se reproducen. Como resultado, la capacidad total de la red para servir páginas Web se ve aumentada y la cantidad de tráfico de red asociado con estas páginas se reduce. Están comenzando a emerger arquitecturas similares para la gestión de bases de datos Internet de gran volumen, como la mostrada en la Figura 23.18. En este caso, una aplicación de servicios de información Internet almacena en caché los datos calientes. como las noticias más recientes y la información financiera, en una base de datos residente en memoria principal de alto rendimiento de un fabricante como TimesTen Performance Software. También almacena infoonación resumida del perfil de usuario en una base de datos residente memoria
837
BD residente "en memoria principal
SGSD Internet
o
Perilles de usuario
Intranet
A
l(
:Exptorado~ Web -,---0
~-....-..¡
V
<'-~
<:
•
I~ Internet
V
LI ~ ~
BO residente en
~
Figura 23.18.
Base de datos dorsal
\2atos llcalientesl encaché
memoria principal
~
::>
1r
§k
• •
Aplicación Internet
Web
• • • Servidores reproducidos
• • •
Reparto de datos para la gestión de datos de alto rendimiento.
838
SOL Manual de referencia
Resumen
\ )
En este capítulo se han descrito las capacidades en la gestión 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 informáticos, cada uno ejecutando su propia copia de software SGBD y operando de forma autónoma 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 estén 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 pequeña parte de la actividad total de la base de datos; en este caso es más práctico dejar los datos en la ubicación remota y generar una carga en la red para cada acceso a la base de datos. • La réplica 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 más cerca del punto de acceso, pero con el coste de carga de la red para la sincronización de la réplica y sabiendo que Jos datos no están actualizados al cien por cien. • Los compromisos particulares del acceso a los datos remotos y las estrategias de réplica tienen implicaciones más allá de las decisiones tecnológicas; también deberían 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 están aumentando la complejidad del entorno de gestión de datos distribuidos. Las arquitecturas en N capas que utilizan requerirán una caché de datos inteligente y estrategias de réplica para conseguir un rendimiento adecuado.
CAPíTULO
24
SOL Y los objetos
El único reto imponante para el domioio de SQL y la gestión de ¡as bases de datos relacionales en los últimos años ha venido de la irrupción de una tendencia igualmente significativa: la creciente popularidad de las tecnologías orientadas a objetos. Los lenguajes de programación 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, más recientemente, los servicios Web) han emergido como tecnologías fundamentales para el desarrollo de software moderno. Las tecnologías de objetos ganaron gran parte de su popularidad inicial por la construcción de aplicaciones en computadoras personales con interfaces gráficas de usuario. Pero su impacto ha crecido y se están utilizando actualmente para construir (y, más importante aún, para vincular entre sí) aplicaciones basadas en red empresariales para grandes corporaciones. Al comienzo de los años 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 gestión de bases de datos. Estas compañías creyeron que sus bases de datos orientadas a objetos suplantarían a las anticuadas bases de datos relacionales de igual forma que el modelo relacional había suplantado anteriormente a los modelos de datos. Sin embargo, se encontraron con un limitado éxito en el mercado frente a las consolidadas tecnologías relacionales y SQL. En respuesta al reto de los objetos, muchos fabricantes de bases de datos se cambiaron agresivamente a tecnologías de objetos incrustadas en sus sistemas relacionales, creando modelos híbridos relacionales orientados a objetos. Este capítulo describe el reto de las bases de datos orientadas a objetos para SQL y las características resultantes relacionales orientadas a objetos proporcionadas por algunos de los principales fabricantes de SOBD.
Bases de datos orientadas a objetos Buena parte de la investigación académica en la tecnología de bases de datos durante la última década se ha enfocado en nuevos modelos de datos post-relaciona-
839
840
Capítulo 24: SOL y los objetos
SOL. Manual de referencia
les. Así como el modelo relacional proporcionó claras ventajas sobre los anteriores modelos jerárquicos y de red, el objetivo de la investigación fue el de desarrollar nuevos modelos de dales que superaran algunas de las desventajas del modelo relacional. Gran parte de esta investigación se centró en cómo combinar los principios de la programación orientada a objetos y el diseño con características tradicionales de la base de datos, como es el caso del almacenamiento persistente y la gestión de transacciones. Además de la investigación académica, al comienzo y a mediados de los años noventa algunas grandes inversiones de capital dieron como resultado la creación 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) creían firmemente que se produciría un cambio serio en el modelo relacional y se convertiría 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.
•
•
•
Características de las bases de datos oríentadas a objetos
•
Al contrario del caso del modelo de datos relacional, en que el artículo de Codd de 1970 proporcionó una definición matemática clara de una base de datos relacional, no hay una única definición de una base de datos orientada a objetos. Sin embargo. los principios principales de la mayoría de las bases de datos orientadas a objetos hacen referencia a los siguientes aspectos:
841
este atributo, por son subclases de VEHICULOS. La clase COCHES podría también tener el atributo «número de puertas» y la clase DESCAPOTABLES heredaría este atributo. Sin embargo, la clase BARCOS no heredaría este atributo. Atributos. Las características que un objeto posee se modelan con sus atributos. Ejemplos de esto son el color de un objeto o el número 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 métodos. Los objetos se comunican entre sí enviando y recibiendo mensajes. Cuando un objeto recibe un mensaje, responde ejecutando un método, un programa almacenado en el objeto que determina cómo se procesa el mensaje. Por ello, un objeto incluye un conjunto de comportamientos descritos por sus métodos. Normalmente, un objeto comparte muchos métodos con otros objetos en clases de un nivel más alto. Encapsulación, La estructura interna y los datos de los objetos se ocultan del mundo exterior (encapsulado) detrás 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 métodos, cuyas funciones y comportamientos se especifican claramente. Esto hace al objeto más predecible y limita las posibilidades de una corrupción 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).
Estos principios y técnicas hacen que las bases de datos orientadas a objetos sean muy adecuadas para aplicaciones que conllevan tipos de datos complejos, como el diseño asistido por computadora o documentos compuestos que combinan texto, gráficos y hojas de cálculo. La base de datos proporciona una forma natural de representar las jerarquías 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 todavía menores (párrafos, gráficos, etc.). La jerarquía de clase permite a la base de datos seguir el tipo de cada objeto en el documento (párrafos, gráficos, ilustraciones, títulos, pies de página, etc.). Finalmente, el mecanismo del mensaje ofrece un soporte natural para una interfaz gráfica de usuario. La aplicación puede enviar un mensaje «dibújate a ti mismo» a cada parte del documento, pidiéndole que se dibuje a sí mismo en la pantalla. Si el usuario cambia la forma de la ventana que muestra el documento, la aplicación puede responder enviando un mensaje «cambia de tamaño por ti mismo» a cada parte del documento, etc. Cada objeto en el documento cuenta con la responsabilidad de su propia visualización, por lo que se pueden agregar fácilmente nuevos objetos a la arquitectura del documento.
• Objetos. En una base de datos orientada a objetos, todo es un objeto y se manipula como un objeto. La organización tabular de filas y columnas de una base de datos relacional se reemplaza por la noción de colecciones de objetos. Generalmente, una colección 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 noción relacional de los tipos de datos atómicos por una noción jerárquica de las clases y subclases. Por ejemplo, VEHICULOS podría ser una clase de objeto, y los miembros individuales (instancias) podrían incluir coche, bicicleta, tren o barco. La clase VEHICULOS podría incluir subclases llamadas COCHES y BARCOS, representando una forma más especializada de vehículo. De forma similar, la clase COCHES podría incluir una subclase denominada DE8CAPOTABLES, etc. • Herencia, Los objetos heredan las características de sus clases y de todas las clases de nivel superior a la que pertenecen. Por ejemplo, una de las características de un vehículo podría ser «número de pasajeros». Todos los miembros de las clases COCHES, BARCOS Y DESCAPOTABLES también tienen
.-l-
842
SOL. Manual de referencia
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 están 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 programación y de las bases de datos. Piensan que la rígida 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 orientación a registros. Según éstos, para responder de forma efectiva a ~ituaciones reales, .es .esencial un modelo más) flexible, por el cual las clases de objetos puedan ser simIlares (esto es, compartan ciertos atributos), pero también diferentes entre sí. Otra reivindicación 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 tecnología relacional no sea útil para las demandas de rendimiento crecientes de las aplicaciones actuales. Finalmente, puesto que los objetos están bien establecidos como el modelo de datos residente en memoria principal para los programas modernos, los que están 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 más que los pu~teros de las bases de datos embebidos de bases de datos prerrelacionales jerárqUicas y de red. Apuntan que, al igual que estas primeras tecnologías de bases de datos, las bases de datos orientadas a objetos carecen de la fuerte teoría matemática que forma la base de las bases de datos relacionales. La falta de estándares de bases de datos orientadas a objetos y la ausencia de un lenguaje de consultas estándar, 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 tecnología relacional en algunas de las aplicaciones empresariales con más demanda en el rendimiento. También son cuidadosos en establecer una distinción entre el modelo relacional externo de los datos y la implementación subyacente, que puede contener punteros embebidos para la aceleración del rendimiento. Finalmente, afirman que cualquier desajuste entre la programación orientada a objetos y ~as bases de dat?s se puede solucionar mediante tecnologías 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
Capítulo 24: SQL y los objetos
843
que el modelo de clases y herencia orientada a objetos está muy cerca del modelo real. Sin embargo, las compañías 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 década del siglo XXI. Las supervivientes han tenido una época dura, consIguiendo a duras penas alcanzar la marca de 100 millones de dólares an~ales, lograr beneficios sostenibles, si bien han experimentado cambios significativos en la gestión. 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 dólares al año, además de que la tecnología de bases de datos relacionales continúa 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 aceptación en el mercado de la tecnología 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 generación relacional hace dos décadas. Han formado grupos de estandarización, como ODMG (Object Data Management Group), para estandarizar la tecnología de bases de datos orientadas a objetos. Algunos han agregado adaptadores relacionales, con interfaces estándar (ODBC y SQL) como capas opcionales para el acceso relacional a sus bases de datos. Varios se han centrado en el proceso de estandarización internacional y han trabajado para poner capacidades potentes orientadas a objetos en el estándar 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 orientación a objetos ha tenido también un impacto significativo en la corriente relacional principal. Algunas características que comenzaron como capacidades relacionales (por ejemplo, los procedimientos almacenados) se están ahora pregonando como ventajas orientadas a objetos (por ejemplo, la encapsulación). Los fabricantes también 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 híbrido entre las capacidades relacionales y de objetos. Extienden el modelo relacional (algunos dirían que pasándose de la raya) para incorporar características 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 adquisición de Illustra Software. La tecnología 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 versión 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 tecnologías relacionales orientadas a objetos. Oracle8, introducido en 1998, incorporó varios años de desarrollo intensivo de Oracle en esta área, y Oracle9 lo expandió aún más. La respuesta de los fabricantes de bases de datos orientadas a objetos y de los fabricantes relacionales ha tenido también un impacto importante en los estándares SQL. El cambio más significativo al estándar SQL2, incluido en el trabajo
844
SOL. Manual de referencia
Capítulo 24: SOL y los objetos
sobre SQL3, fue la agregación de capacidades de objelos. Cuando SQL3 fue finalmente aprobado como el estándar oficial SQL: 1999, las nuevas capacidades orientadas a objetos casi doblaban el tamaño de la especificación del lenguaje SQL en términos de páginas. La adquisición y desarrollo de bases de datos relacionales orientadas a objetos por parte de los lideres en la industria y la adopción formal de extensiones oriemadas a objetos de SQL señalan la creciente sinergia entre SQL y el mundo de la tecnología orientada a objetos.
Bases de datos relacionales orientadas a objetos
845
• 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 identificación de las filas, u otros identificadores únicos para los objetos.
,
normalment~on
Las bases de datos relacionales orientadas a objetos comienzan un fundamento de base de datos relacional y agregan características seleccionadas que proporcionan las capacidades orientadas a objetos. Este enfoque simplifica la agregación de capacidades orientadas a objetos para la mayoría de fabricantes de SGBDR, cuyos productos SGBDR empresariales se han desarrollado durante 15 o más años y reproducir desde cero supondría un coste enorme. También reconoce el gran número de sistemas relacionales instalados y ofrece al cliente una forma de actualización más suave (sin mencionar el aumento de ingresos de los fabricantes). Las extensiones orientadas a objetos que comúnmente se encuentran en las bases de datos relacionales orientadas a objetos son:
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, dirección de un empleado o descripción 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 técnicas que utilizan para gestionar el almacenamiento en disco y para indexar los datos parten de que las filas de datos ocuparán entre unos pocos cientos y miles de bytes. Los programas que almacenan y recuperan los datos pueden albergar fácilmente docenas o cientos de estos tipos de elementos de datos en memoria, y almacenar y recuperar filas de datos de una vez mediante búferes de memoria razonablemente dimensionados. Las técnicas de procesamiento por filas para los resultados de las consultas relacionales funcionan bien. Muchos tipos modernos de datos tienen características bastante diferentes de los datos tradicionales. Una única imagen gráfica de alta resolución para mostrar en la pantalla del pe puede requerir cientos de miles de bytes, o más, de almacenamiento. Un documento de un procesador de textos, como un contrato o el texto de este libro, puede ser aún más grande. El texto HTML que define las páginas web y los archivos PostScript que definen las imágenes 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 más 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.
• Objetos de datos de gran tamaño. Los tipos de datos relacionales tradicionales son menores en tamaño (enteros, fechas, cadenas de caracteres cortas); los objetos de datos de gran tamaño pueden almacenar documentos, audio y video ctips, páginas web y otros nuevos tipos de datos multimedia. • Tipos de datos estructurados/abstractos. Los tipos de datos relacionales son atómicos 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 jerarquías 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.
~
846 BLOB
en el modelo relacional
El primer enfoque para admitir BLOB en las bases de datos relacionales fue a través del sistema operativo subyacente y su sistema de archivos. Cada elemento de datos BLOB
Capítulo 24: SOL y los objetos
SOL. Manual de referencia
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. podía buscar en el resto de columnas de la tabla para encontrar filas que cumplieran un cierto criterio. Cuando una aplicación necesitaba manipular el contenido del ELOE asociado con una de las filas, leía el nombre del archivo y recuperaba los datos del BLOB. La gestión de la entrada/salida del archivo era responsabilidad de la aplicación. Este enfoque funcionaba, pero estaba sujelO a errores y requería que un programador comprendiera las interfaces tanto del SGBDR como del sistema de archivos. La falta de integración entre el contenido BLOB y la base de datos era aparente. Por ejemplo, no se podía 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 podía proporcionar siquiera capacidad básica de búsqueda de texto para el contenido BLOB. En la actualidad, la mayoría de los principales SGBD empresariales proporcio.nan un soporte directo para uno o más 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 condición de reunión o en una cláusula GROUP BY. Sybase proporciona dos tipos de datos de gran tamaño. 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 búsqueda 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, más 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 tamaño de DB2 (eLoB) almacena hasta dos mil millones de bytes de texto. Un tipo de objeto de caracteres de gran tamaño de dos bytes en DB2 (DacLoa) almacena hasta mil millones de caracteres de 2 bytes. Un objeto binario de gran tamaño de DB2 (BLoa) almacena hasta dos mil millones de daM tos binarios. Oracle ha proporcionado históricamente dos tipos de datos para objetos de gran tamaño. 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 restringía el uso del tipo LONG a solamente una única columna por tabla. Con la introducción 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.
847
• 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.
• Un tipo BFILE de Oracle almacena datos binarios de gran tamaño en un archivo externo a la base de datos. Los tip~s BLOB, CLOB Y NCLOB se integran estrechamente en la operación 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 semántica de la transacción 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 sección. El soporte para datos de objetos de gran tamaño de Universal Server de 1nfor- . mix es similar al de Oracle. Admite objetos de gran tamaño sencillos y objetos de gran tamaño elaborados: • Un tipo BYTE Informix es un objeto de gran tamaño sencillo que datos binarios. • Un tipo TEXT Informix es un objeto de gran tamaño sencillo que datos de texto. • Un tipo BLOB Informix es un objeto de gran tamaño elaborado que datos binarios. • Un tipo CLOB Informix es un objeto de gran tamaño elaborado que datos de texto (caracteres).
almacena almacena almacena almacena
Los objetos de gran tamaño Informix almacenan hasta un gigabyte de datos. Se debe recuperar o almacenar todo el objeto de gran tamaño como una unidad desde la aplicación, <.> se puede copiar entre la base de datos y un archivo del sistema operativo. Los objetos de gran tamaño elaborados pueden almacenar hasta 4 terabytes de datos. Se proporcionan funciones Informix especiales para procesar objetos de gran tamaño elaborados en trozos más pequeños y manejables. Estas funciones proporcionan acceso aleatorio a los contenidos de un objeto Informix elaborado, similar al acceso aleatorio típico proporcionado por los archivos del sistema operativo. Informix también proporciona controles avanzados sobre el registro histórico, la gestión de transacciones y la integridad de datos para objetos de gran tamaño 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
SOL. Manual de referencia
'1,
• Almacenamiento de datos y optimización. Almacenar un elemento BLOS en línea con los otros contenidos de la fila de una tabla destruiría la optimización que el SGBD realiza para ajustar los datos de la base de datos adecuadamente en páginas que coinciden con el tamaño de las páginas de disco. Por esta razón los datos BLOS siempre se almacenan en áreas de almacenamiento separadas fuera de línea. La mayoría 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 mayoría de los programas no pueden albergar a la vez lOdos los contenidos de un 8L08 en un búfer de memoria. Procesan porciones del 8L08 cada vez (por ejemplo, páginas de un documento de gran tamaño o imágenes individuales de un videt\~). Sin embargo, las API de SQL incorporado y SQL normal están 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 técnicas 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. • Recuperación 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 están diseñadas para el procesamiento de la instrucción SELECT O la instrucción 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 mayoría de los programas no puedan almacenar todos a la vez en un búfer de memoria. Se requieren técnicas especiales para recuperar los datos de la columna 8L08 de la base de datos, trozo a trozo. de forma que la aplicación los pueda procesar. • Registro histórico de transacciones. La mayoría de los SGBD admiten las transacciones mediante el mantenimiento anterior y posterior de las imágenes de datos posteriores en un registro histórico de transacciones. Debido al potencial mayor tamaño de los datos BL08, la sobrecarga del registro histórico podría ser extrema. Por esta razón muchas SGBD no admiten el registro histórico de datos BLOB o permiten el registro histórico, pero proporcionan la posibilidad de activarlo y desactivarlo.
----.J
Capítulo 24: SOL y fos objetos
849
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 términos 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 descripción de cada función de procesamiento LOB: (localizador, número, desplazamiento, búfer). Lee en el búfer PL/SQL el número indicado de bytes/caracteres del L08 identificado por el localizador, comenzando por el desplazamiento. dbms_lob.write (localizador, número, desplazamiento, búfer). Escribe el número indicado de bytes/caracteres del búfer 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, número, 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, número, desplazamientol, desplazamiento2). Copia número de bytes/ caracteres del LOB identificado por localizador2 de desplazamienro2 en el LOB identificado por localizador} de desplazamiento}. dbms_lob.trim (localizador!, número). Ajusta el L08 identificado por el. localizador al número indicado de bytes/caracteres. dbms_lob. substr (localizador, número, desplazamiento). Devuelve (como una cadena de texto devuelve un valor) el número indicado de bytes/caracte· res del L08 identificado por el localizador, comenzando por el desplazamiento; el valor devuelto de esta función se puede asignar a una variable PUSQL
• dbms_lob. read
•
•
•
•
• •
VARCHAR.
(localizador). Devuelve (como valor entero) el número de bytes/caracteres del LOB identificado por el localizador. • dbms_lob. compare (localizadorl, localizador2, número, desplazamientol, desplazamiento2). Compara el LOB identificado por localizadori con el LOB identificado por localizador2, comenzando por desplazamiento} y desplazamiento2 ·respectivamente, para un número de bytes/caracteres; devuelve cero si son el mismo, y un valor distinto si no lo son. • dbms_l.ob.instr (localizador, patrón, desplazamiento, i). Devuelve (como un valor entero) la posición en el LOB identificado por el localizador donde coincide la i-ésima ocurrencia del patrón; el valor devuelto se puede utilizar como un desplazamiento en llamadas posteriores de procesamiento L08. • dbms_lob.getlength
Varios SGBD solucionan estos problemas mediante API extendidas que admiten específicamente manipulación 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.
Oracle impone una restricción más sobre las actualizaciones y modificaciones de los valores L08 que se realizan mediante estas funciones. Los L08S pueden im-
----
850
SOL. Manual de referencia
poner una sobrecarga inaceptablemente alta sobre los mecanismos de transacción 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 aplicación O rutina PUSQL. Si se van a actualizar los datos LOE, la fila debe estar bloqueada explícitamente antes de modificarla. Esto se hace mediante la inclusión de una cláusula FOR UPDATE en la instrucción 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 CLOB¡ buftexto varchar (255) ;
'ob begin
/* Poner el texto a insertar en el búfer /
/* 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 */
Tipos de datos abstractos (estructurados) Los tipos de datos contemplados en el modelo de datos relacional son valores de datos sencillos, indivisibles y atómicos, Si un elemento de datos como una dirección está realmente compuesto por la dirección de una calle, ciudad, provincia y código postal, se tienen dos opciones como diseñador de bases de datos: se puede tratar la dirección 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 término medio que pennita tratar la dirección como una unidad para ciertas situaciones y acceder a sus componentes para otras. Muchos lenguajes de programación (incluso lenguajes no orientados a objetos como e o Pascal) proporcionan este término 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
Capítulo 24: SOL y los objetos
851
puede tratar como una única unidad cuando es, más 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 instrucción CREATE TABLE de Informix para una tabla sencilla .PERSONAL que utiliza un tipo de datos fila para almacenar información del nombre y la dirección: CREATE TABLE NUM_EMPL NOMBRE NOMBRE INICIAL APELLIDOS DIRECCION CALLE CIUDAD PROVINCIA CODIGOPOSTAL PRINCIPAL SUFIJO
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 paréntesis 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 DIRECClüN tiene cuatro campos. Los últimos cuatro campos tienen un tipo de datos fila y consisten en dos campos, En este ejemplo sencillo, la jerarquía sólo 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 extensión de la notación 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 después del nombre de la columna, se permite especificar los nombres de los campos individuales en una columna. Esta instrucción SELECT recupera el número de empleado y el primer y último nombre de todo el personal con un código 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, tenía la misma estructura NOMBRE que una de sus columnas, Entonces esta consulta recupera los números de los empleados que también son jefes: SELECT NUM_EMPL FROM PERSONAL, JEFES WHERE PERSONAL,NOMBRE
JEFES.NOMBRE;
852
SOL. Manual de referencia
'-
En la primera de estas dos consultas tiene sentido recuperar los campos individuales en la columna NOMBRE. La segunda consulta muestra una situación en la que es más conveniente utilizar el nombre de columna completo (los tres campos) como base para la comparación. Es claramente mucho más 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 jerarquía. Las columnas de tipos de datos fila requieren una gestión especial cuando se insertan datos en la base de datos. La tabla PERSONAL tiene tres columnas, por lo que una instrucción INSERT para la tabla debe tener tres elementos en su cláusula 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 instrucción INSERT válida para la tabla que ilustra el uso de la constructora ROW: INSERT INTO PERSONAL VALUES {1234, ROW( 'José', 'J.', 'García'}, ROW('Rosa, 197', 'Castuera', ROW(OG. 420));
Obsérvese que la definición 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 dirección en la tabla PERSONAL (y cualquier otra columna que alberga datos del nombre o dirección 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 asignación de nombres y en los tipos de datos en una base de datos relacional orientada a objetos. Veamos la nueva definición 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
'EX',
PERSONAL INTEGER. TIPO_NOMBRE, TIPO_DIR);
La Figura 24.1 muestra algunos ejemplos para esta tabla y la estructura jerárquica 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 instrucción CREATE TYPE para crear la misma estructura de datos abstractos para los nombres y direcciones:
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 diseño orientado a objetos, que es la reutilización. En lugar de hacer que cada objeto (las dos columnas en las dos tablas distintas) tenga su propia definición, el tipo de datos fila se debería definir una vez y entonces reutilizarlo para las dos columnas. Universal Server de Informix proporciona esta capacidad mediante su característica tipo fila COIl nombre (1os tipos de datos fila mostrados en el ejemplo anterior son tipos de datos fila sin nombre). Con la instrucción CREATE ROW TYPE se crea un tipo fila con nombre Informix. Veamos ejemplos de la tabla PERSONAL: TYPE TIPO_NOMBRE VARCHAR(lS) , CHAR(l), VARCHAR(20});
853
CIUDAD VARCHAR(151, PROVINCIA CHAR(2). CODIGOPOSTAL TIPO_POSTAL);
Definición de tipos abstractos de datos
CREATE ROW NOMBRE INICIAL APELLIDOS
Capitulo 24: SaL y los objetos
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
.,
CREATE ROW TYPE TIPO_POSTAL PRINCIPAL INTEGER. SUFIJO INTEGER); CREATE ROW TYPE TIPO_DIR CALLE VARCHAR(3SJ,
~
TIPO_DIR AS OBJECT VARCHAR(3Sl. VARCHAR{lSI, CHAR(2). TIPO_POSTAL);
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 terminología usual orientada a objetos. Ampliando más la terminología 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 notación de punto extendida para referirse a elementos de datos individuales en tipos de datos abstractos. Con los tipos abstractos
854
Capítulo 24: SOL y fos objetos
SOL. Manual de referencia
~
Además de este uso, las tablas con tipos también son un componente clave de la noción Informix de la herencia de tablas, descrito posteriormente en la sección «Herencia».
Tabla PERSONAL DIRECCIÓN NtJ!.LEMPL
I
NOMBRE
1234 sus,'m", 1374 Samuel 1421 José 1532 RobertO
I
INICIAL
IAPELLlOOSI
S. S. J. R.
KaJetín Ordói\ez García Matas
CALLE
Mayor,)1 Belén, 104 Rosa, 197 Cava
I
r
I CODIGOPQSTAI
CIUDAD
I Pltl:NINCIA PRIIt1~
Madrid
H
Sevilla C
AN
EX CA
28 40 06 08
SUPIJ
032 001 420 020
• • • Figura 24.1.
855
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 código poslal principal en la labia PERSONAL se ldenufica como:
Manipulación de tipos abstractos de datos Desafortunadamente, los tipos de datos estructurados crean nuevas complicaciones para las instrucciones de actualización 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 conversión 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 número 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 más 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 instrucción INSERT convirtiendo de forma explícita el valor al tipo fila construido para tener el tipo de datos TIPO_NOMBRE:
PERSONAL.DIRECCION.CODIGOPOSTAL PRINCIPAL
Si la tabla perteneciera a otro usuario, SamueI, el nombre calificado sería incluyo mayor:
el uso de tipos fila para ir un paso más allá de su función 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)
se puede definir la tabla
PERSONAL
utilizando el tipo fila como modelo:
CREATE TABLE PERSONAL OF TYPE TIPO_PERS;
. Las colum~as de esta tabla PERSONAL serán exactamente como eran en los ejemplos anten.ores CREATE T~BLE, pero ahora PERSONAL es una tabla con tipos. El .uso más básIco 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 función del tipo fila.
El operador dos puntos dobles convierte la fila construida de tres campos en una fila TIPO_NOMBRE y hace que la cláusula 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 instrucción CREATE TYPE), Oracle define automáticamente un método constructor para el tipo. Se puede pensar en el método constructor como una función 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 cláusula VALUES de la instrucción INSERT para pegar los valores de los elementos de datos individuales en un valor de datos estructurados que coincide con la definición de la columna. Veamos una instrucción 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}));
856
1
SQL. Manual de referencia
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 representación de un objeto, y los valores de sus campos individuales o subcolumnas son sus atributos. Otra característica 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 cómo puede funcionar la herencia en un modelo de datos de los empleados de una compañía. Todos los empleados son miembros de la clase PERSONAL y todos tienen los atributos asociados con ser un empleado (número de empleado, nombre y dirección). 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 académicos o el proyecto actual al que están asignados). Cada uno de estos tipos de empleados tiene su propia clase, que es una subclase de PERSONAL. La subclase hereda todas las características de la clase superior en la jerarquía (se desea recorrer todos los datos principales del personal, también en el caso de ingenieros y fabricantes). Sin embargo, las subclases tienen información 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 técnicos, desarrolladores y gestores.
Representantes
Ingenieros (TIPO_ING)
Técnicos (TIPO_TEC)
857
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 sección «Definición de tipos abstractos de datos», de este capítulo, 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 jerarquía:
Las constructoras (TIPO_NOMBRE, TIPO_OIR, TIPO_POSTAL) realizan las mismas funciones que la constructora ROW realiza en Informix y también proporciona la conversión de tipos requerida para asegurar la correspondencia de tipos de datos estricta.
(TIPO_VENTAS)
Capítulo 24: SQL y los objetos
CREATE ROW TYPE TIPO_VENTAS JEF_VEN INTEGER, SUELDO HONEY (9,2) , CUOTA MONEY(9,2)) UNOER TIPO_PERS; CREATE ROW SUELDO EXPER UNDER
,. Número de empleado del jefe de ventas Sueldo anual
'*
*'
*'
TYPE TIPO_ING HONEY(9,2), INTEGER TIPO_PERS;
'*
Sueldo anual
CREATE ROW TYPE TIPO_JEF COMP MONEY(9,2)) UNDER TIPO_ING;
'*
Complemento anual
CREATE ROW TYPE TIPO_TEC SUELDO_HORA MONEY(5,2)) UNDER TIPO_ING;
*'
/* Años de experiencia */
*'
,. Sueldo por hora .,
El tipo definido para los técnicos (TIPO_TEC) es un subtipo (subclase) del tipo ingeniero (TIPO_ING), por lo que hereda todos los campos del tipo del personal (TIPO_PERS), más los campos agregados en el nivel TIPO_ING, más el campo adicional agregado en su propia definición. 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 jerarquía 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 técnicos, 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
Jefes (TIPO_JEF)
Figura 24.2.. Jerarquía de clase natural para una aplicación de personal.
La jerarquía 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 fácil de definir. El resto de características de la tabla pueden (y deben) todavía estar definidas en la definición 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 podrían incluir, probablemente, una cláusula FOREIGN KEY como ésta: CREATE TABLE QF TYPE FOREIGN KEY REFERENCES
todavía se basan en una jerarquía de tipos definida, pero ahora tienen entre sí una jerarquía 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
REPS TIPO_VENTAS (JEF_VEN) PERSONAL (NUM_EMPL) ;
La herencia de tipos crea un vínculo en la estructura de las tablas que se basan en los tipos fila definidos._ pero las tablas permanecen independientes entre sí en función de los datos que contienen. Las filas insertadas en la tabla TECNICOS no aparecen automáticamente 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 vínculo entre los contenidos de la tabla, haciendo que las tablas sean muy parecidas a las clases de objetos. Se describe en la siguiente sección.
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 más 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
Cuando se define de esta forma una tabla (como bajo otra tabla), hereda muchas características de su supertabla además de la estructura de la columna, Hereda la clave externa, la clave principal, la integridad referencial y las restricciones de comprobación de la supertabla, cualquier desencadenador definido en la supertabla, así como índices, áreas de almacenamiento y otras características específicas de Informix. Es posible evitar esta herencia específicamente incluyendo las características omitidas en las instrucciones CREATE TABLE de las supertablas. Una jerarquía 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 jerarquía forman ahora una colección de conjuntos anidados, como se muestra en la Figura 24.4. Cuando se inserta una fila en la jerarquía de tabla se sigue insertando en una tabla en concreto. Juan García, por ejemplo, está en la tabla TECNICOS, mientras que Samuel Ordóñez está en la tabla INGENIEROS Y Susana Martín está en la tabla PERSONAL. Sin embargo, las consultas SQL se comportan de una forma·bastante diferente. Cuando se realiza una consulta en una base de datos sobre una de las tablas en la jerarquía, se devuelven no solamente las filas de la tabla, sino también de todas las subtablas incluidas en esa tabla. Esta consulta:
Herencia de tablas: implementación de clases de objetos
'
859
SELECT FROM PERSONAL;
I
,1 ",UNDER JEFES (TIPO_JEFF)
devuelve las filas de la tabla PERSONAL y las filas de las tablas y REPS. De igual forma, esta consulta:
,
INGENIEROS, TEC-
NICOS
I SELECT FROM INGENIEROS;
I
devuelve las filas de TECNICOS y JEFES además de INGENIEROS. El SGBD trata ahora las tablas como una colección anidada de filas, y una consulta sobre una
Una jerarquía de herencia de tablas en Informix.
1
860
SOL. Manual de referencia
Capítulo 24: SOL y los objetos
861
La misma lógica se aplica para las instrucciones UPDATE. La siguiente cambia el número de empleado, sin considerar en qué tabla de la jerarquía está la fila del empleado:
Conjunto PERSONAL
UPDATE PERSONAL SET APELLIDOS: 'CastaBo' WHERE NUM_EMPL = 1234;
Conjunto INGENIEROS
--------
Conjunto REPS
Nuiia Yepes
Conjunto TECNICOS
......------...
De nuevo, la construcción ONLY se puede utilizar para restringir el ámbito de la operación 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 jerarquía de tabla, las instrucciones SQL se pueden referenciar solamente a las columnas que se definen en ese nivel. No se puede utilizar esta instrucción:
Conjunto JEFES
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 instrucción: Figura 24.4.
Conjuntos anidados representados por una jerarquía de herencia
de tablas.
DELETE FROM JEFES WHERE SUELDO < 20000.00;
puesto que SUELDO se define en este nivel de la jerarquía de la tabla (clase). Como se observó, la herencia de la tabla mueve la operación 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 debería provocar que de repente apareciera en otras dos tablas? Y ¿por qué una instrucción DELETE buscada que no coincide con ninguna fila de la tabla debería provocar que otras- filas de otras tablas desaparecieran? Por supuesto, la jerarquía de tablas ha dejado de comportarse estrictamente como si fuera un conjunto de tablas relacionales y en su lugar ha adoptado muchas de las características de una clase de objetos y una jerarquía 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 implementación relacional orientada a objetos
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 lógica del conjunto de filas a las operaciones Esta instrucción DELETE:
DELE-
DELETE FROM PERSONAL WHERE NUM_EMPL : 1234;
borra de fonna satisfactoria la fila del número de empleado 1234 sin importar qué tabla de la jerarquía comiene la fila. La instrucción 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 jerarquía, pero no las filas de cualquier otra de sus subtablas, se puede utilizar esta instruc.ción:
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-
DELETE FROM.ONLY(INGENIEROSl WHERE NUM~EMPL : 1234;
----
862
SOL. Manual de referencia
Capítulo 24: SOL y los objetos
ROS. Supongamos que cada ingeniero tiene un conjunto de títulos académicos (por ejemplo, un licenciado en Ciencias Físicas por la UCM, un doctor en Ingeniería Eléctrica de Barcelona, elc.) q~e se van a almacenar en la base de datos. El número de títulos de cada ingeniero variará (de ninguno para algunos ingenieros a quizás media docena para otros). En una hase de datos relacional pura hay solamente una forma correcta de agregar esta información 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 título académico individual que tiene alguno de los ingenieros. Una columna en la tabla TITULOS alberga el número de empleado del ingeniero que tiene el título descrito en una fila particular y sirve como clave externa a la tabla INGENIEROS, vinculando las dos tablas en una relación padre/hijo. Las otras columnas en la tabla TITULaS describen las particularidades del título. Se ha visto el tipo de estructura de tabla relacional padrelhijo. mostrada en la Figura 24.5. muchas veces a lo largo de los capítulos anteriores y ha sido una construcción básica 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 difícil de comprender. En segundo lugar, muchas consultas comunes necesitan reunir tres, cuatro O más tablas para obtener las respuestas requeridas. En tercer lugar, con las implementaciones de las reuniones relacionales proporcíonadas por la mayoría de los SGBD. el rendimiento de las consultas se deteriorará, al suponer más y más reuniones.
Tabla INCENIEl{()S
I NUH.-OlPLI NOKIlRE
1234 1374 1421 1534:
I
-~ Susana Sa!llUel Josll
1INICIAL IAP!Lt.lOOsl
,. ,.
J.
Martín Ord6t1ez Garcia
• • •
DIRECCIÓN
1 CALLE Mayor, 31 Belén, 104 Rosa.
U7
CIUDAD
IJ ICODlGOPOSTAL PROVIOCIAlPílI!l:IP"'4SUF1JO
•
Madrid Sevilla ~ Ca.tuera EX
""'"
'"
001
no
Tabla TÍTULOS NUM-.U!PL
Cl11ve exeernll
12)4 1234 137& 1421
'1"
Figura 24.5.
"TUW UNIVERSIDAD ClC
W
= ='l" "'" "'" OC,
~
• •
Modelo relacional de los ingenieros y sus títulos.
~,J
45.000€ 30.000e: 34 .SOO€:
EXPER
, ,"
863
Un modelo orientado a objetos de los ingenieros y sus títulos tendería a rechazar la estructura de tabla de la Figura 24.5. Sostendría que los títulos no son objetos sustanciales por sí mismos, por lo que no merecen su propia tabla. En realidad son atributos del ingeniero que alberga los títulos. Ciertamente, se asocia a cada ingeniero un número variable de títulos, pero el modelo orientado a objetos no tendría problema con representar esta situación 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 colección. 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 más frecuentemente a un procedimiento almacenado. manipular el conjunto de datos como un todo o acceder a los miembros individuales del conjunto.
Definición de colecciones Universal Server de Infonnix incorpora las colecciones de atributos mediante sus tipos de datos colección. Alberga tres tipos diferentes de datos colección: • Listas. Una lista es una colección 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 año, en orden de contratación, podría ser {'Javier', 'María', 'Samuel', 'Jacinto', 'Juan'}. • Multiconjuntos. Un multiconjunto es una colección 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 implícito 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 contratación: {'Jacinto', 'Samuel', 'Juan', 'Jacinto', 'Mary'}. • Conjuntos. Un conjunto es una colección 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 implícito. Los elementos deben ser valores únicos. Los nombres en los ejemplos anteriores no serían un buen ejemplo, pero los apellidos podrían serlo: {'García', 'Ordóñez', 'Martín" 'Azañedo', 'Sánchez'}. Para ilustrar el concepto de datos de la colección, 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
864
SOL Manual de referencia
Capítulo 24: SOL V los objetos
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á información sobre los tílUlos académicos que cada ingeniero tiene. Se almacenarán dos elementos de dalos sobre cada título: el título real (licenciado, doctor, ingeniero superior, etc.) y la universi-
dad. Estos datos se almacenarán en una columna rnulticonjunto agregada a la tabla INGENIEROS, porque es posible tener dos entradas idénticas (por ejemplo, un ingeniero puede tener un título de licenciado en ingeniería y un título de licenciado en empresariales en la misma universidad). • La tabla TECNICOS incluirá información sobre los proyectos a que cada técnico está asignado. Cada técnico puede tener asignados dos o más 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.
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);
Estos tipos de columna colección 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 podría describir de forma más precisa como una tabla en una tabla. Naturalmente, el modelo relacional de tablas fila/columna con elementos de datos atómicos se ha extendido considerablemente con la introducci6n de los tipos de datos colección. Universal Server de Informix permite utilizar colecciones de una forma bastante general y entremezclarlos con otras extensiones relacionales orientadas a objetos. Una colección puede ser un campo de un tipo de datos fila. Los elementos de una colección pueden ser tipos de datos fila. También es posible definir las colecciones dentro de colecciones donde eso tenga sentido. Por ejemplo, los proyectos en este ejemplo podrían tener subproyectos que debe supervisar cada técnico. 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.
Tablas con columnas cuyo tipo·s son colecciones de datos.
Ocacle también proporciona un gran soporte para los datos de tipo colección ·mediante dos extensiones relacionales orientadas a objetos diferentes: • Arrays variables. Un array variable es una colección 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 número máximo 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
Capítulo 24: SOL y los objetos
SOL. Manual de referencia
• 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 número 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.
SUELDO MONEY(9.2) , CUOTA MONEY{9,21, OBJ_TRI VARRAY(4) OF NUMBER{9.2);
/- número 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 información cuatrimestral de la tabla REPS es la que más fácilmente se representa como una columna de array variable de Oracle. Habrá exactamente cuatro trimestres de infoonación, por lo que el tamaño máximo del array se conoce por adelantado. En este ejemplo, el array variable contiene datos sencillos como elementos, pero también es común definir arrays variables cuyos elementos sean tipos de datos abstractos (estructurados). La información del título académico para la tabla INGENIEROS se representa como una tabla anidada. Para un elemento de datos como éste. se podría decidir ubicar un límite superior al número de filas y utilizar una estructura de array variable en su lugar, pero, en general, si el máximo número de elementos es desconocido, la elección 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á información sobre el título y la universidad que lo conced.ió.
867
Consultas sobre datos de tipo colección 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 búsqueda, 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 más 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 colección 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 técnico que trabaja en un proyecto llamado «bingo»: SELECT NUM_EMPL. NOMBRE FROM TECNICOS WHERE 'bingo' IN (PROYECTOS);
El nombre de la columna con valor de colección (en este caso, la columna con valor de conjunto PROYECTOS) aparece entre paréntesis. lnformix trata los miembros de la colección como un conjunto y aplica la condición de coincidencia IN. En SQL interactivo se puede poner una columna con un valor colección en la lista de elementos de selección. Informix muestra la colección de datos como SET, LIST o MULTISET en la salida mostrada. Para procesar los datos con valor colección en la lista de selección de una solicitud mediante programación (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 paréntesis internos es una consulta para la tabla principal Selecciona la columna que contiene la tabla anidada, pero podría seleccionar también otras columnas. La operación 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
Capítulo 24: SaL y los objetos
SOL. Manual de referencia
ejemplo), y se convierte en el origen de resultados de la consulta candidata de la cláusula 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 requerirían recurrir a procedimientos almacenados. Sin embargo, la lógica interna de estas consultas y la tarea de construirlas correctamente puede ser extremadamente complicada, como incluso este ejemplo sencillo comienza a mostrar.
Se utilizan extensiones a la sintaxis SQL estándar para insertar nuevas filas en una tabla que contenga columnas ·con valor de colección. lnformix proporciona tres constructoras (la constructora SET, la constructora MULTISET y la constructora.LIsT) para este propósito. 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:
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 características del lenguaje de procedimientos almacenados especiales para este propósito. En Informix se deben utilizar variables de tipo colección del SPL especiales. Veamos un fragmento de procedimiento almacenado SPL que gestiona la columna de colección PROYECTOS de la tabla TECNICOS:
1* alberga la colección de proyectos *1 1* alberga los proyectos individuales *1 1* número de proyectos *1 1* búfer con el nombre de los técnicos *1
1* Comprueba cuántos proyectos está asumiendo el técnico *1 select cardina1ity(proyectosl into num-proy from tecnicos where num_empl : 1234; 1* Si hay demasiados proyectos, entonces se niega a agregar uno más *1
La primera instrucción 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 colección e insertarlos en la tabla. Recuérdese de la discusión de los tipos de datos abstractos de Draele que cada tipo de datos abstracto de Oracle tiene automáticamente un mélodo 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 automáticamente un método constructor para cada arcay variable o tabla anidada y se utiliza en las instrucciones INSERT: .
if (num-proy > 61 then .
1* Recupera la fila, técnico *1
incluyendo el conjunto de proyectos para el
select nombre, proyectos into nombre_empl, from tecnicos where num_emp1 : 1234;
col-proy
1* Agrega el proyecto 'gonzo' a la lista para este técnico *1 insert into tab1e(col_proy) values ('gonzo');
1* Busca en la lista de proyecto uno a uno *1 foreach proj_cursor for
----.:
870
SOL. Manual de referencia
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 gestión de colecciones en el SPL de Informix. En primer lugar, la colección se recupera de la base de datos en una variable SPL como un tipo de datos colección. También sería posible recuperarla .en una variable explícitamente declarada con el tipo SET (o, en otras situaciones, un tipo LIST o MULTSET). La colección almacenada en la variable entonces se trata explícitamente como·una tabla para manipular elementos en la colección. Para agregar un nuevo proyecto se realiza un IN5ERT en la tabla colección. Para encontrar y modificar un proyecto específico se utiliza un cursor para buscar en la tabla colección, y una instrucción UPDATE basada en cursores para cambiar el valor de tin miembro de la colección. Obsérvese que el bucle FOREACH recupera cada elemento de la colección en una variable, de forma que la rutina SPL lo pueda procesar. Finalmente, los contenidos de la variable colección se utilizan para actualizar la columna colección 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 están 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.
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 están siendo recuperadas. Ejecutar un bucle FOR con un índice variable n que cuenta desde 1 hasta el número de elementos en el array variable. El número 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 técnica similar para procesar las tablas anidadas; sin embargo, normalmente no es necesario. En su lugar, se utiliza generalmente el
Capítulo 24: SaL y los objetos
871
::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 todavía 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 años que gestionaban registros principales y detallados. Como ha ilustrado el análisis de esta sección, los tipos de colección y el procesamiento de elementos individuales de una colección tienden al acceso mediante programación a través de procedimientos almacenados, más que por el uso oportuno de SQL. Una de las críticas a las bases de .dalos orientadas a objetos es que suponen una regresión en cuanto a la simplicidad del modelo relacional y reintroducen la necesidad de la navegación explícita 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 crítica.
Tipos de datos definidos por el usuario Los sistemas de gestión 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 aplicación 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 localización, la aplicación puede necesitar definir funciones especiales, tales como la función DISTANCIA (X, Y) , que calcula la distancia entre dos ubicaciones. Se necesitará redefinir los significados de algunas operaciones incorporadas. como una comprobación de la igualdad (=) para los datos de localización. 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 términos orientados a objetos, los datos están completamente encapsulados. El usuario debe proporcionar de forma explícita (en rutinas externas, escritas en e o en lenguajes de programación similares) la estructura de datos para el tipo. código 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 código 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.
872
SOL. Manual de referenda
Capítulo 24: SOL V los objetos
Se proporciona una capacidad más básica de tipos de datos definidos por el usuario mediante la implementación 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 compañía 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 compañía, 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:
873
conocen la estructura interna de la base de datos a priori, pueden utilizar consultas SQL para averiguar cómo es. Los procedimientos almacenados proporcionan un mélodo para que las bases de datos relacionales ofrezcan capacidades que recuerdan las de los métodos orientados a objetos. Excepcionalmente, todos los usuarios de una base de datos relacional podrían obtener permiso para ejecutar solamente un conjunto limitado de procedimientos almacenados, y ningún permiso de acceso a datos subyacente so· bre las tablas de las bases de datos. En este caso, el acceso de los usuarios se acercaría a la encapsulación del ideal orientado a objetos. En la práctica, 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 están casi siempre explotadas por herramientas de consulta o programas de informes. Gracle formaliza el vínculo entre los métodos de objetos y los procedimientos almacenados de la base de datos, permitiendo definir de forma explícita un procedimiento almacenado como una función miembro de un tipo de datos abstraclo. Una vez definida de esta forma, se puede utilizar la función miembro en consultas que alcanzan al tipo de datos abstracto, de igual forma que si fuera una función incorporada del SOBD diseñada para funcionar sobre ese tipo. Veamos una redefinición del tipo de datos abstracto TIPO_DIR que se utiliza para almacenar direcciones, con una función miembro relativamente sencilla, denominada OBT_POST_COMPLETO. La función toma la parte del código postal de la dirección, la cual almacena un código postal principal de dos dígitos y un sufijo de tres dígitos como dos números separados y los combina en un número de cinco dígitos, el cual devuelve.
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 función de los tipos de datos TIPO_CIUDAD y TIPO_NOMBRE_CO. Si se intenta comparar columnas con estos dos tipos de datos distintos, SOBD automáticamente detecta la situación y genera un error. Se pueden comparar, pero solamente convirtiendo explícitamente 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.
CREATE TYPE CALLE CIUDAD PROVINCIA CODIGOPOSTAL MEMBER RETURN PRAGMA
Métodos y procedimientos almacenados En lenguajes orientados a objetos, los objetos encapsulan los datos y el código de programación que contienen; los detalles de las estructuras de datos en un objeto y las instrucciones de programación que gestionan dichas estructuras de datos están ocultados explícitamente. La única forma de manipular el objeto y obtener información sobre él es mediante los métodos, que son procedimientos explícitamente definidos, asociados con el objeto (o, más adecuadamente, con la clase de objetos). Por ejemplo, un método asociado con un objeto cliente podría contener el límite de crédito actual del cliente. Otro método podría proporcionar la capacidad de cambiar el límite de crédito. Los datos del límite de crédito están encapsulados, ocultos en el objeto cliente. Los datos en las tablas de la base de datos relacional no están inherentemente encapsulados. Los datos y su estructura están 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 catálogo del sistema de una base de datos relacional, el contraste c:on el ideal orientado a objetos es incluso más extremo. Con el catálogo, la base de datos es autodescriptiva, por ]0 que incluso las aplicaciones que no
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));
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 función miembro se identifica como tal en la instrucción CREATE TYPE para el tipo de datos abstracto, siguiendo las líneas que describen los elementos de datos. La cláusula adicional PRAGMA dice a Gracle que la función no modifica los contenidos de la base de datos, que es un requisito para una función que se va a utilizar en expresiones de consulta. Hay varias opciones más, que están fuera del
-'--
874
SOL Manual de referencia
ámbito de este análisis. Una instrucción CREATE TYPE BODY separada define el código procedimental real de la función. Después de las primeras palabras de la instrucción, sigue el mismo formato de las instrucciones estándar CREATE PRQCEDURE o CREATE FUNCTION. Una vez que se define la función miembro, se puede utilizar en expresiones de consulta como ésta, que encuentra los empleados que viven en el código postal 28-005: 28005;
Universal Server de Informix no tiene un mecanismo extendido como Oracle para transformar los procedimientos almacenados en métodos orientados a objetos. En su lugar, es posible utilizar un tipo fila de Informix (correspondiente a un tipo objeto de Gracle) como parámetro de una función almacenada. Cuando se llama, se pasa a la función un dato con el tipo fila apropiado (como el dato abstracto CODIGOPOSTAL en el ejemplo precedente de Orade) y se pueden realizar cálculos apropiados. Se podría, por ejemplo, definir una función almacenada Informix OBT_POST_COMPLETO () con un único parámetro del tipo TIPO_POSTAL. Con esa definición, se podría utilizar la instrucción Oracle SELECT precedente, sin modificar, en la base de datos Informix equivalente. Otra característica 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 jerarquía de clases objeto, suele ser necesario definir un método que realice las mismas o similares operaciones sobre diferentes clases de objetos. Por ejemplo, se puede desear definir un método (fun· ción) 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 método (que será implementado como una función almacenada) debería devolver el sueldo total anual objetivo del empleado al que se aplica. Las particularidades de los cálculos difieren según el tipo (clase) de empleo: • Para los técnicos, el sueldo total es la jornada semanal de 40 horas x 52 semanas al año. • Para los jefes, el sueldo total es igual a su sueldo anual más 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 parámetro y devuelve la cantidad calculada. Las tres rutinas tienen el mismo nombre, que es la razón por la cual se dice que el nombre está sobrecargado (se asocia un único nombre con más 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 cuál 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 extensión orientada a objetos adicional. Permite definir muchos procedimientos almacenados diferentes con nombres idénti-
Capítulo 24: SOL y los objetos
875
cos, dado que ninguno de ellos tiene idéntico número de argumentos con idénticos tipos de datos. En el ejemplo anterior, hay tres definiciones CREATE FUNCTION como estas: /* Calcula el sueldo objetivo de un técnico */ 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;
+
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 función OBT_SUELOO_OBJ () y pasarle una fila de la tabla INGENIEROS, JEFES o TECNICOS. El SGBD averigua automáticamente qué funciones utilizar y devuelve el valor calculado apropiado. Los procedimientos almacenados son incluso más valiosos para tablas con ti· pos mediante la característica posibilidad de sustitución 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 jerarquía de tipos intentando encontrar un procedimiento con el mismo nombre que esté definido para un supertipo TIPO_TEC. Si hay un procedimiento almacenado OBT_APELLIOO·S () definido para el tipo TIPO_ING, Informix ejecutará ese procedimiento almacenado para obtener la información requerida. Si no, continuará hacia arriba en la jerarquía, buscando un procedimiento almacena· do OBT_APELLIDOS () definido para el tipo TIPO_PERS. Por ello, la posibilidad de sustitución significa que se pueden definir procedimientos almacenados (métodos) para el tipo de nivel superior en la jerarquía a la cual se aplica. Los procedimientos almacenados están disponibles automáticamente para procesar todos los subtipos de ese tipo (esto es, todas las subclases heredan el método de la clase).
Soporte de objetos en el estándar SQL:1999 Como se mencionó al comienzo de este capítulo, el área mayor de expansión SQL en el estándar SQL: 1999 fue el soporte relacional orientado a objetos. El
876
Capítulo 24: SOL y los objetos
SOL. Manual de referencia
877
• Las capacidades relacionales orientadas a objetos son particularmente buenas para modelos de datos más complejos, donde el diseño completo de la base de datos puede ser más sencillo, incluso cuando las tablas/objetos individuales son más complejas. • Las capacidades relacionales orientadas a objetos son un punto fuerte de los esfuerzos de los estándares SQL3, y es probable que en el futuro sean incorporadas más bases de datos relacionales.
estándar SQL: 1999 especifica nuevas instrucciones, cláusulas 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 específicos. Es probable que en esta área de SQL se siga el patrón de otros con respecto al estándar. Lentamente, sobre una serie de versiones principales, los principales fabricantes SGBD proporciona· rán 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 años siguientes las capacidades relacionales orientadas a objetos que importan en las implementaciones continuarán siendo propiedad de los fabricantes.
Resumen Las bases de datos orientadas a objetos desempeñaran, probablemente, un papel creciente en segmentos especializados del mercado, corno el diseño en ingeniería, el procesamiento de documentos compuestos y las interfaces gráficas de usuario. No están siendo adoptadas de forma generalizada por aplicaciones de procesamiento de datos de las empresas principales. Sin embargo, se están 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 explícito para identificadores de objetos. Estas capacidades amplian en gran medida el modelo relacional sencillo y tienden a añadir 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 implementación.
~
CAPíTULO
25
SOL yXML
El Lenguaje de marcas extensible (XML, eXtensible Markup Language) es una de las tecnologías más importantes que vienen de la evolución de Internet y World Wide Web. XML es un lenguaje estándar para representar y extraer datos estructuradas. SQL es un lenguaje estándar para definir, acceder y actualizar los datos estructurados almacenados en bases de datos relacionales. Parece obvio a primera vista que debería haber una relación entre XML y SQL. Las preguntas lógicas son: ¿cuál es la relación? y ¿están las dos tecnologías en conflicto, o son complementarias entre sí? La respuesta incluye un poco de ambas opciones. Este capítulo ofrece un repaso de los fundamentos de XML y examina la relación creciente entre XML y SQL, y cómo XML se está integrando en los principales productos SQL.
XML Como su nombre indica, XML es un lenguaje de marcas. Comparte muchas características con su primo más cercano, el lenguaje de marcas de hipertexto (HDvtL, HyperText Markup lAnguage), que se ha convertido en un lenguaje ampliamente popular como tecnología principal que hace posibles World Wide Web y los exploradores Web. Los lenguajes tienen orígenes comunes en las marcas de documento, una técnica que es tan antigua como los negocios de imprenta y edición. Cuando un documento complejo, como este libro, un periódico o una revista, se va a imprimir, se puede pensar que tiene dos partes lógicas relacionadas. El contenido del documento, que normalmente consiste en texto y gráficos, contiene su significado. La estructura del documento (títulos, subtítulos, párrafos, pies) y el formato (fuentes, sangrados, diseños de página) ayudan a organizar el contenido y asegurar que se presentan de una forma comprensible. Desde los primeros días de la imprenta y la edición, los editores han empleado símbolos de marcas y marcas de formato, insertos en los contenidos del documento mismo, para indicar la estructura del documento y cómo se debería dar: formato para su impresión.
879
880
SOL. Manual de referencia
Capítulo 25: SOL y XML
Cuando entraron en escena los sistemas informáticos de edición. los comandos de marcas insectos en los contenidos de un documento se convirtieron en instrucciones para los programas software de edición. Cada tipo de software de edición tenía sus propios comandos de marcas, lo que hacía complicado cambiar de un sistema a otro. Se desarrolló el lenguaje de marcas estándar general (SGML, Standard General Markup Lallguage) como una forma de estandarizar los lenguajes de marcas, y finalmente se adoptó como un estándar ISO. De forma más precisa, SGML es un metalenguaje para definir lenguajes de marcas. Sus inventores reconocieron que ningún lenguaje de marcas podría cubrir todos los requisitos de marcas, pero que todos los lenguajes tenían elementos comunes. Mediante la estandarización 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 raíces 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 propósito es desarrollar y promocionar el uso de estándares asociados con Internet y World Wide Weh. Las recomendaciones W3C tienen un estatus «oficialmente adoptado»; la terminología significa que la organización W3C promociona y recomienda su uso. Mediante este proceso, HTML y XML son estándares industriales independientes del fabricante. HTML fue el primer lenguaje basado en SGML en tener una amplia popularidad. Los contenidos de toda página Web en todo sitio Web en la World Wide Web están expresados como un documento HTML. Los elementos de marcas especiales, denominados etiquetas en un documento HTML, indican elementos gráficos, tales como botones a mostrar en un explorador Web. Las etiquetas también describen los vínculos del hipertexto a otros documentos que el explorador debería seguir cuando se pulsa un botón. Otras etiquetas identifican elementos gráficos que se van a insertar en el texto HTML cuando se muestra. Como el uso de la World Wide Web explotó en los años 90, HTML se adaptó rápidamente para mostrar un contenido mucho más rico en páginas web con mucho formato. Se inventaron rápidamente etiquetas HTML para controlar el formato de las páginas Web, dirigiendo la visualización texto en negrita ó en cursiva, centrado y sangrados, y la ubicación del texto en la página. En algunos casos estas etiquetas eran dependientes de un explorador Web específico, tal como el explorador Netscape o Internet Explorer de Microsoft. Con el tiempo una gran parte de las marcas en una página HTML se centraban en el formato y presentación de la información. Esto tenía la ventaja de que el formato de la página Web estaba muy especificado, por lo que las páginas se mostraban de la misma forma sin importar el explorador o dispositivo sobre el cual se mostraba. Tenía la desventaja de que la estructura del contenido de la página Web tendía a perderse en el formato y los detalles de la presentación.
881
Un logro importante, original de SGML, fue el de que un elemento lógico dado, como un título de página subsección de una página Web, se podría identificar de forma consistente en cientos de documentos (por ejemplo, en ciemos de páginas de un sitio Web). Una sencilla directiva al explorador, tal como «muestra todos los títulos de subsecciones en azul, negrita, fuente Times New Roman 16 puntos» podría entonces asegurar la consistencia en la presentación de todas las páginas. En su lugar, los autores de páginas Web tendían a marcar explícitamente todo elemento, tales como los títulos de subsección con sus propias instrucciones de formato detalladas. Esto se podía fácilmente convertir en inconsisteme y, lo que es peor, un cambio en las instrucciones del formato requerirían cientos de cambios en las páginas individuales, en lugar de especificarse una sola vez para todas las páginas. Una de las principales tendencias que acompañaron el desarrollo de XML fue restaurar un nivel más lógico, en lugar de un nivel de formato. XML implementa reglas mucho más rígidas sobre la estructura del documento que HTML. La mayoría de sus componentes y capacidades están centradas en la representación de la estructura lógica del documento. Los estándares acompañantes, tales como XML Schema, que especifica los tipos de documentos, llevan este objetivo de XML incluso más allá.
Fundamentos de XML Para comprender las interacciones entre XML y SQL se necesita una comprensión básica de XML y cómo se utiliza. Si ya se ha comprendido o utilizado XML, se puede saltar esta sección y continuar con la siguiente. Si no se está familiarizado con XML, esta sección proporciona una introducción sencilla, basada en algunos ejemplos de documentos XML. La Figura 25.1 muestra una representación XML típica 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 símbolos «menor que» «) y «mayor que» (». En la Figura 25.110s párrafos se identifican mediante una etiqueta de apertura , y las cabeceras se identifican mediante una etiqueta de apertura . 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 carácter de barra (1), de nuevo encerrado entre símbolos «menor que» y «mayor que». En la Figura 25.1 los párrafos se acaban con una etiqueta , y las cabeceras con una etiqueta . 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
Capítulo 25: SOL y XML
SOL. Manual de referencia
Las consultas están en el centro_ para gestionar consultas complejas. Fundamentos de sQLEste capítulo comienza_ descrito en este capítulo."InstruccionesLa parte principal de ... en la Figura 5.1.
Toda instrucción SQL... constantes o expresiones.
ANSI/ISO SQL._ En la Tabla 5.3. <¡para>
En todo este libro_ en minúsculas.Las variables_ están SUBRAYADAS.NombresLos objetos en_ formularios de entrada de datos.El original_ caracteres especiales. hdrLevel;""2">Nombres de tablas Cuando se especifica_o o disef'iador.En un mayor_ nombre de tabla _ etc _. Consultas sencillasDe muchas formas_ en la base de datos. _ etc _ etc ...
Figura 25.1.
Documento XML de una parte de un libro.
883
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 jerarquía normal de elementos de la mayoría 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 más elementos para, posiblemente entremezclados con algunos elementos figure y algunos elementos tableo Cada elemento para tiene solamente texto corno contenido. Además de la jerarquía de elementos, la Figura 25.1 muestra algunos ejemplos de atributos, otra estructura XML fundamental. Se asocia un atributo con un elemento XML específico, y tal atributo describe algunas características 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 número de capítulo asociado con ese contenido particular. El elemento chapter tiene otro atributo denominado revStatus cuyo valor indica si el capítulo está en borrador, está siendo reescrito o en su forma final. Los elementos individuales, en la Figura 25.1, también 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 línea 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 más complejos, pero estos componentes fundamentales son los únicos importantes para la interacción XMU base de datos, Observesé que los nombres de los elementos y atributos consideran las mayúsculas. 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 mayúsculas. En la Figura 25.1 se muestra, de forma aclaratoria, una notación adicional abreviada de XML, pero es muy útil en la práctica. Para elementos que no tienen contenidos propios sino solamente atributos, el final del elemento se puede indicar con el mismo par de símbolos, «menor que» y «mayor que», que ]a etiqueta de apertura. indicada por una barra justo antes del símbolo «mayor que». Mediante el uso de este convenio el elemento de la Figura 25.1:
figNum~·5.1">
se puede representar como:
'-.r----' '
Etiqueta de apertura
Figura 25.2.
Juan
J,
Moreno
Cont-;nido del elemento
Anatomía de un elemento XML.
, '----.r---' Etiqueta de cierre
/>
La especificación XML define ciertas reglas que todo documento XML debería 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
Capítulo 25: SOL V XML
SOL. Manual de referencia
aparecer antes de la etiqueta de cierre de un elemento de nivel superior que lo contiene. El estándar también 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 raíces de XML están 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 típico 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 (númeroClience, númeropedido, fechaPedido y elementoPedido). elementoPedido está compuesto a su vez por otros subelementos. La Figura 25.3 también muestra algunas funciones del negocio asociadas con el pedido de compra como atributos del elemento términos. El atributo envío especifica cómo se va a enviar el pedido. El atributo factura especifica los términos del crédito para el pedido. Debería ser obvio que el sencillo documento de pedido XML de la Figura 25.3 tiene una gran relación 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 Apéndice A (Figura A.5.). Los niveles inferiores del documento coinciden principalmente con las columnas individuales de la tabla PEDIDOS, excepto el elemento términos. El elemento de nivel superior en el documento representa una fila com-
21171129611989-12-17106REI2a441731500.00
Figura 25.3.
Documento XML para un pedido sencillo.
885
pleta de la tabla. La transformación entre un grupo de documentos de la Figura 25.3 y un conjunto de filas en la tabla PEDIDOS es evideme, mecánica, por lo que debería ejecutar de forma automática un sencillo programa informálico. Al contrario que la tabla PEDIDOS, el documento XML impone un nivel medio de jerarquía, agrupando la información 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 podría ampliar fácilmente para admitir esta estructura, agregando un segundo o tercer elemento elemento Pedido después del primero. La base de datos de ejemplo no se puede ampliar de forma tan sencilla. Para admitir pedidos con varias líneas la tabla PEDIDOS se tendría que dividir probablemente en dos tablas: una con la información de la cabecera del pedido (número de pedido, fecha, ID del cliente, etc.) y otra con los elementos del pedido.
XML ySQL Los orígenes de SGML dan a XML varias características ú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 cómo se procesa. Se puede llamar a esto una característica de SQL; que se enfoca en qué datos se solicitan en lugar de en cómo recuperarlos. • Construcción de bloques. Los documentos XML están compuestos de un número muy pequeño de bloques de construcción básicos, 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 específicos 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 también grandes diferencias: • Orientación a documentos frente a orientación a datos. Los conceptos principales de XML vienen de las estructuras normales del documento. XML está centrado en el texto e implementa una fuerte distinción entre el contenido mismo (1os elementos de un documento) y las características 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-
886
SOL. Manual de referencia
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 jerárquica frente a tabular. Las estructuras XML naturales son jerárquicas. y reflejan la jerarquía de elementos en la mayoría de tipos de documentos (por ejemplo, un libro contiene capítulos; los capítulos contienen secciones, y las secciones contienen cabeceras, párrafos y figuras). Las estructuras son también flexibles y variables. Una sección puede contener cinco párrafos y una única figura; la siguiente, tres párrafos y dos figuras, y la siguiente, seis párrafos y ninguna figura. En cambio, las estructuras SQL son tabulares, no jerárquicas, y reflejan los registros típicos de las aplicaciones del procesamiento de datos. Las estructuras SQL son también bastante rígidas. 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 también pueden provocar conflictos cuando se utilizan XML y SQL conjuntamente. • Objetos frente a operaciones. El propósito 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 párrafo, un pedido o la dirección de un cliente, por ejemplo. El lenguaje SQL tiene un propósito más 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 operación sobre un objeto: crear un objeto, borrar un objeto, encontrar uno o más objetos, o actualizar el contenido de los objetos. Estas diferencias hacen a los dos lenguajes fundamentalmente complementarios en su propósito y uso.
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 jerarquía del documento XML; la jerarquía 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 ningún 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 combinación de texto (contenido) y otros subelementos.
Capítulo 25: SOL y XML
887
• Atributos. Un elemento en un documento XML puede tener uno O más atri· butos con nombre, y cada atributo tiene un valor de texto. Los atributos se adjuntan a un elemento en la jerarquía 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. Además, 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 posición 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 legítimas diferentes para expresar el contenido de una base de datos relacional con XML. Estas dos filas de datos: NUM_PEDIDO FAB PRODUCTO CANTIDAD
----------
112963 ACI 112983 ACI
--------
--------
41004 41004
2B 3
IMPORTE
----------
3 .276,OO€ 702,OOE
podrían ser representadas por este documento XML cuando los elementos se utilizan para representar valores de columna: 112963ACI41004283276.00112983ACI410043702.00
y se representaría con este documento XML cuando se utilizaran los atributos:
importe="3276.00">
888
SOL. Manual de referencia
producto=-41004cantidad","3" importe="702.00">
Como se podría esperar, hay fuertes partidarios tanto de los métodos de representación de elementos como de representación de atributos, con sólidas convicciones. Los partidarios del enfoque de elementos utilizan estos argumentos:
• Los elementos son más 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 debería representar como contenido en XML. • El orden de los elementos importa y, en algunos casos, también la ordenación de datos en un SGBD (por ejemplo, cuando se identifica una columna por su número en la especificación de una consulta o cuando se utiliza un número 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 atómico (entero, cadena) o tipos de datos más 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 atómicos).
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 deberían corresponder con elementos. Los valores de columna describen atributos de la entidad (fila) en la cual aparecen; se deberían representar como valores de atributos en XML. • La restricción 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 representación de atributos es más 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 práctica 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 elección depende de las preferencias del auLor
Capitulo 25: Sal y XMl
889
del documento y de los convenios de la organización que utiliza XML y SQL. Además, los estándares 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 rápido crecimiento de la popularidad de XML los fabricantes de productos de bases de datos se han movido rápidamente para ofrecer soporte XML en sus productos. La forma del soporte XML varía, pero tiende a caer en una o más de estas categorías: • Salida de XML. Un documento XML puede representar fácilmente los datos en una o más 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 fácilmente los datos a insertar, como una o más filas nuevas en una tabla. También puede representar los datos para actualizar una fila de una tabla, o la identificación 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 envían 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 planificación de recursos empresariales (Enterprise Resource Planning, ERP) o de integración de aplicaciones empresariales (Enterprise Application Integra tion, EAI) corporativos. • Almacenamiento de XML. Una base de datos relacional puede aceptar fácilmente 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 tamaño. En el nivel más básico 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 más fuerte si el SGBD permite declarar la columna con un tipo de datos «datos XML» explícito. • Integración de datos XML. Es posible un nivel más 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 búsqueda 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
890
SOL. Manual de referencia
Capitulo 25: SOL y XML
Salidas de XML Una de las combinaciones más sencillas de la tecnología 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 fácilmente a una representación XML. Consideremos esta sencilla consulta de la base de dalos de ejemplo: SELECT NUM_PEDIDO,
FAB.
PRODUCTO,
CANTIDAD,
IMPORTE
FROM PEDIDOS
WHERE CLIENTE = 2103; NUM_PEDIDO FAB PRODUCTO CANTIDAD
IMPORTE
-------- --------
-----------
---------112963
ACl
41004
112983 ACl 113027 ACl 112987 ACl
41004 41002
4100Y
3 .276,OO€
28 3
702. DO€" 4 .104,OO€
54
11 27 .SOQ,QO€
Si se instruye al SGBD para que saque los resultados de la consulta en formato XML, veamos qué salida podría resultar: SELECT NUM_PEDIDO, FAB, FROM PEDIDOS WHERE CLIENTE = 2103;
Esto es típico de la salida que pudiera recibirse de algún 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 envía el resultado a un analizador XML (los analizadores se describen en la sección posterior «Objetos grandes y analizadores»), el analizador los interpretará correctamente partiendo de que contiene: • Un elemento raíz, resul tadosConsul tao • CualIo subelementos fila bajo la raíz. • 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 través de una red a otro sistema, y debido a su formato XML sus elementos son autodescriptivos (todo sistema o aplicación 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 envío y recepción. Finalmente, si XML se transmite por un vínculo HTTP mediante el uso de los estándares del protocolo simple de acceso a objetos (Simple Object Access ProlOcol, SOAP), el mensaje con formato XML se puede trasladar a través de cortafuegos corporativos y vincular la aplicación que lo origina en una compañía a una aplicación que lo recibe en una compañía diferente. La salida con formato XML también tiene algunas desventajas. Una es el tamaño en bruto de los datos. El número 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 más almacenamiento. Si se envía a otro sistema de computadora por la red, tardará cuatro veces más en transmitirse o requerirá una red con cuatro veces más ancho de banda para preservar el mismo tiempo de transmisión. Éstos no son problemas serios en el caso del ejemplo, dada la pequeña 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 también pierde cierta información sobre los datos. El símbolo de la moneda que aparecía en la visualización 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 información, como se describirá posteriormente en la sección «XML Schema», pero con el inconveniente de todavía más aumento en el tamaño del texto de los resultados de la consulta.
892
SOL. Manual de referencia
Capítulo 25: SOL y XML
Entradas de XML
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 técnicas específicas 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 específicas de cada SGBD. No hay estándares (todavía) para el tipo de sintaxis híbrido SQUXML de estos ejemplos. Aunque representar los valores de entrada y actualización como pequeños documentos XML es conceptualmente sencillo, presenta algunos aspectos significativos del procesamiento del SOBD. Por ejemplo, la lista de columnas en una instrucción INSERT de SQL parece redundante si el documento XML que contiene los datos a insertar también 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 ningún problema en realizar esto, pero no es probable que se use el fonnato XML por una sesión SQL interactiva. Para el uso mediante programación de SQL. el problema radica en que el documento XML y los datos que contiene se proporcionarán al SGBD en tiempo de ejecución. Si los nombres de columna (o incluso el nombre de tabla) también están proporcionados solamente en el documento XML, entonces el SOBD no puede conocer, hasta el momento de la ejecución, qué tablas y columnas están afectadas. En esta situación el SGBD debe utilizar SQL dinámico para gestionar el procesamiento, como se describe en el Capítulo 18, con todas sus pegas asociadas sobre el rendimiento. Se producen problemas similares con la cláusula WHERE en una instrucción UPDATE o DELETE. Para conseguir el rendimiento y eficiencia en SQL estático, el SGBD debe conocer con antelación (cuando se compila el programa) qué condiciones de búsqueda se utilizarán y qué columnas se actualizarán. Un enfoque para este problema es utilizar la forma pararnetrizada de estas instrucciones. Veamos el mismo ejemplo UPDATE utilizando este enfoque:
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, también puede emplearse fácilmente 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 específico 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 instrucción INSERT: INSERT INTO OFICINAS (OFICINA, CIUDAD, REGION, VENTAS) VALUES (23, 'Sevilla', 'Oeste',O.OO)
se puede convertir fácilmente en una instrucción equivalente híbrida SQUXML como ésta: INSERT INTO OFICINAS (OFICINA, CIUDAD, REGION, VENTAS) VALUES 23SevillaOesteO.OO
Las actualizaciones de la base de datos se pueden gestionar de forma similar. Esta sencilla instrucción UPDATE: UPDATE OFICINAS SET OBJETIVO = 200000.00, JEF WHERE OFICINA = 23
=
UPDATE OFICINAS SET OBJETIVO = 7 WHERE OFICINA = ?
lOS
JEF
=
7
<7xrnl version="l. 0·7> 200000.00 10S 23
se puede convertir en su instrucción equivalente híbrida SQlJXML: UPDATE OFICINAS WHERE OFICINA = 23 200000.00lOSoficina = 23
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 compilación. El texto XML es autocontenido y el SOBD puede asociar los valores de sus parámetros a los parámetros de la instrucción necesarios en tiempo de ejecución. Este ejemplo sigue el estilo SQL usual para especificar parámetros por su posición, 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 parámetros de instrucción con nombre en tiempo de ejecución.
y una instrucción RE,
893
DELETE requiere solamente la especificación de la cláusula WHEusando los mismos convenios.
-
894
SOL. Manual de referencia
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 más útil si el SOBD proporciona más soporte incorporado explícito. Varios productos comerciales de SOBO ofrecen ahora la capacidad de realizar una exportación masiva de una tabla (o en una operación más 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 importación masiva desde este mismo tipo de archivo en una tabla del SGBD. Con este esquema, el documento SML se convierte en una forma estándar de representar los contenidos de la tabla para el intercambio. Obsérvese que, una vez que se ofrecen las capacidades de importación y exportación 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 podría bien ser una aplicación empresarial, como un sistema de gestión de la cadena de provisión (Supply Chain Managemen/, SCM). De igual forma, el destino podría ser una aplicación empresarial. Además, muchos sistemas EAI admiten ahora Jos archivos XML. Estos sistemas proporcionan más capacidades de procesamiento e integración, tales como eliminar datos duplicados y combinar datos de varios archivos de entrada.
Almacenamiento e integración 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.
Capítulo 25: SOL y XML
895
admiten documentos de hasta 4 gigabytes de datos CLOB o BLOB, lo que es adecuado para la gran mayoría de documentos XML. Para almacenar documentos XML mediante BLOS O CLOS, normalmente se definiría una tabla que contuviera una columna BLOB o CLOS para albergar el texto del documento y algunas columnas auxiliares (usando tipos de datos estándar) que contengan atributos que identifiquen el documento. Por ejemplo, si una tabla va a almacenar documentos de pedidos, se podrían definir columnas auxiliares para albergar el número de cliente, la fecha de pedido y el número de pedido mediante el uso de datos INTEGER, VARCHAR o DATE, además de la columna CLOB para el documento XML. Se puede buscar en la tabla de pedidos según los números de clientes, fechas del pedido o números de pedido y usar las técnicas de procesamiento del CLOB descritas en el Capítulo 24 para recuperar o almacenar el documento XML. Una ventaja de este enfoque es que es relativamente sencillo de implementar. También mantiene una separación limpia entre las operaciones SQL (tales como el procesamiento de consultas) y las operaciones XML. Una desventaja es que el nivel de integración XMUSGBD es bastante débil. En sus implementaciones más 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 extraído un atributo o elemento determinado del documento XML y también se represente como una columna separada en la tabla. Si se anticipa por adelantado qué tipos de búsquedas son probables, esto no supone una gran restricción. Algunas bases de datos relacionales orientadas a objetos proporcionan una capacidad de búsqueda más avanzada para CLOB ampliando la cláusula WHERE de SQL con la capacidad de búsqueda de texto completo. Estos productos permiten buscar columnas CLOB como texto, usando el tipo de capacidades de búsqueda de texto encontrado normalmente en procesadores de texto. Esto proporciona una capacidad expandida, aunque normalmente todavía limitada, para la búsqueda de documentos XML almacenados como columnas CLOB. Usando búsquedas de texto completas se podría, por ejemplo, ubicar todos los pedidos donde aparezca la frase «Zapatas serie 4». Sin embargo, será difícil o imposible buscar solamente en aquellos documentos XML donde «Zapatas serie 4» se encuentre en un elemento de descripción de un elemento de un pedido. Debido a que el software de búsqueda no conoce explícitamente la estructura de los documentos XML, probablemente también devolverá filas donde «Zapatas serie 4» ocurra en un elemento de comentario o en algún otro comentario.
Almacenamiento XML sencillo con grandes objetos
Objetos grandes y analizadores
Cualquier SGBD basado en SQL que incorpore grandes objetos contiene automáticamente soporte básico para el almacenamiento y recuperación de documentos ~ML~ La sec~ión titulada «Soporte de grandes objetos», en el Capítulo 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 tamaño (CLOB) u objetos binarios de gran tamaño (BLOB). Muchos productos comerciales
Cuando se intercambian entre aplicaciones O almacenan en un archivo o en una columna SGBD CLOB, los documentos XML están también en la forma de texto. Esto hace que los contenidos sean muy transportables, pero difíciles de manejar para los programas informáticos. Un analizador XML es un trozo de software que traduce los documentos XML de su forma texto a una representación interna más afín al programa. Cualquier SGDB basado en SQL que admita XML tendrá un
896
SOL. Manual de referencia
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 más integración con XML permitiendo que un analizador XML opere directamente sobre los contenidos de las columna eLüs. Hay dos tipos populares de analizadores XML, que admiten dos estilos de procesamiento XML: • Modelo de objetos documento (Document Object Model, DOM). Los analizadores DüM transforman un documento XML en una estructura jerárquica en árbol en la memoria principal de la computadora. Un programa puede entonces hacer llamadas al API DOM para navegar por el árbol, moviéndose arriba y abajo de forma secuencial por la jerarquía del elemento. La API DOM hace que la estructura del elemenLO de un documento XML sea fácilmente 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 según las va encontrando. Un programa se puede estructurar para que adopte ciertas acciones cuando encuentre el comienzo de una sección del documento o cuando encuentre un atributo particular. La API SAX impone un estilo más 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 también puede validar un documento XML en un esquema, como se describe en una sección posterior de este capítulo, «XML Schema». Un analizador DOM es práctico cuando el tamaño del documento almacenado XML es bastante pequeño; requerirá el doble de espacio de memoria que el documento de texto XML, puesto que genera una segunda representación estructurada en árbol de todo el documento. Para documentos muy grandes, un analizador SAX hace sencillo el procesamiento en trozos pequeños 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 estén en el orden secuencial. Cálculo de referencias XML
Almacenar documentos XML como objetos grandes en una base de datos es una excelente solución para algunos tipos de integración SQUXML. Si los documentos XML son, por ejemplo, documentos del negocio orientados a texto o si son componentes de texto de las páginas 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 más palabras clave o <\tributos, que se pueden fácilmente extraer y almacenar como columnas convencionales para la búsqueda.
Capítulo 25: SOL y XML
897
Si los documentos XML a procesar son realmente registros de procesamiento de datos, la sencilla integración proporcionada por los objetos grandes puede ser, sin embargo, demasiado primitiva. Probablemente se deseará procesar y acceder a los elementos individuales, y buscar basándonos en sus contenidos y atributos. El SGBD ya proporciona estas capacidades para sus datos nativos fila/columna. ¿Por qué el SOBD no puede descomponer automáticamente 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 cómo este enfoque puede funcionar para transformar los resultados de la consulta fila/columna en un documento XML. Esta misma técnica se podría utilizar para recomponer un documento XML si se necesitara otra vez en su formato de texto externo. El desafío de transformar documentos XML, que son una representación de datos externos ~xcelente, a y desde representaciones de datos internos más ú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 representación interna y binaria, se denomina resolución 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 cálculo de referencias (marshalling). Para los documentos XML muy sencillos, el proceso del cálculo y la resolución de referencias son muy sencillos y los productos SOBD comerciales se transforman para albergarlos. Consideremos una vez más 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 más sencillo, los nombres de los elementos (o atributos) serán idénticos a los nombres de las columnas correspondientes. El SGBD puede recibir un documento XML como el utilizado en la figura, devolver automáticamente 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 reconstrucción del documento XML de una fila de la tabla tampoco es un problema. El SGBD debe realizar ligeramente más 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 asociación entre los nombres del elemento (o nombres de atributo) y los nombres de columna. Es relativamente sencillo poner dicha asociación en el catálogo 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 ampliación del documento XML de pedidos de la Figura 25.3, que incorpora el requisito típico de la vida real de que un pedido puede contener varios elementos. ¿Cómo se deberían resolver las referencias de este documento XML en una base de datos de ejemplo? Una solución es convertir cada elemento de línea del pedido de compra en una fila independiente de la tabla de PEDIDOS (ignoremos por el momento que cada fila en
la tabla PEDIDOS debe contener un único número de pedido, puesto que el número de pedido es la clave principal). Esto produciría alguna duplicación de los datos, puesto que aparecerá el mismo número de pedido, fecha de pedido, número de cliente y número de representante en varias filas. También realizaría el cálculo de referencias de los datos para reconstruir el documento más complejo (el SGBD tendría que conocer que todas las filas con el mismo número de pedido debería calcular la referencia en un documento XML de pedidos con varios elementos de línea). Obviamente, el cálculo/resolución de referencias, incluso de este documento sencillo, requiere una asociación más compleja. El pedido de compra de varios elementos se queda simplemente en la superficie del cálculo y en la resolución de referencias de los documentos XML. La situación más 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 jerarquía XML. La razón subyacente de esta complejidad es el desajuste entre la estructura jerárquica natural de XML y la estructura normal en filas y columnas de una"base de datos relacional. El cálculo y resolución de referencias se simplifica y se hace más complejo si el SGBD admite extensiones relacionales orientadas a objetos, tales como los ti· pos de datos estructurados. La traducción a1desde XML puede ser más sencilla, puesto que las columnas individuales de una tabla pueden ahora tener su propia estructura jerárquica. Un elemento XML de nivel superior (con ~lementos tales
Figura 25.5.
Cálculo y resolución de referencias XML para una base de datos.
como una dirección de facturación compuesta por la calle, ciudad, provincia, país y código postal) se puede convertir en una columna que se corresponda con una de tipo abstracto de datos DIRECCION, con su propia jerarquía interna. Sin embargo, la traducción aldesde XML exige ahora más decisiones en el diseño de la base de datos, conservando la simplicidad del cálculo y resolución de referencias de los tipos de datos estructurados, frente a la flexibilidad de un enfoque de filas y columnas aplanadas. Varios productos comerciales están comenzando a ofrecer capacidades de cálculo y resolución de referencias, y han anunciado planes para proporcionar esta capacidad en versiones futuras. La disminución en el rendimiento de esta traducción puede ser sustancial y todavía queda por ver cuán populares serán en la práctica estas capacidades. Sin embargo, si una aplicación gestiona datos externos en formato XML, debe producirse en algún punto la traducción entre los datos XML y SQL, y la traducción en el propio SGBD puede ser el enfoque más eficiente.
XML y metadatos Una de las cualidades más potentes del modelo relacional es su muy rígido soporte para los tipos de datos y estructuras de datos, implementado por las definiciones
900
. :CapítuJo.Q5: SOL y XML
SOL. Manual de referencia
de tablas, columnas, claves principales, claves externas y restricciones. Además, como se mostró en el Capítulo 16, el catálogo del sistema de una base de datos relacional contiene metadatos o «datos sobre los datos» en la base de datos. Cuando se consulta el catálogo 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 jerárquica 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 aún 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 más fuerte para los datos y una estructura más rígida, Los estándares y productos XML han resuelto esta necesidad de varias formas durante la corta historia de las tecnologías XML. Éstas incluyen:
.";,' pIo, las empresas. de, servicios:financieros están trabajando en estándares que describen instrumentos financieros (acciones, bonos, etc;) y datos del mer_ ¡,cado. Las .empresas manufactureras están trabajando en estándares que des. criban los, documentos de pedidos, confirmaciones de pedidos y cosas parecidas. Estos estándares para los documentos específicos orientados a la industria se construyen normalmente sobre estándares genéricos tales como D.TD y XMLSchema.· ,. ,o· . ,.:.> :.,
El área de metadatos XML y estándares para tipos de documentos está evolucionando ,rápidamente. El.consorcio..W3C proporciona-:un sitio Web actualizado ffecuememente en h/lp://www.w3.or;g, el cuaL proporciona acceso a los diferen· tes estándares.relacionados con WML.e información sobre sus estados. Se puede encontrar información sobre estándares específicos para la industria en http:// w.ww.xml.org, 'un sitio organizado y.albergado: p.or OASIS (Organization for the Advanc.ement
'.' ,,'~
:.
'
',.:;
,
..
.~~:
, .- '; Z",
..
:
~.
r~;
:.\
Definiciones de tipos·de documentos·.fOTO)
",:' ,
• Definiciones de tipos de documentos (DTD, DOCllIllent Type Definition). Una parte de la especificación 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 válido (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 especificación de XML Schema. Microsoft adaptó su propia forma de XML· Data, denominándola XML-Data Reduced (XDR), y la implementó como parte de su servidor de integración BizTalk y el explorador Internet Explo· rer 5.0. La energía invertida en la propuesta XML-Data se trasladó, entre el final del año 1999 y el año 2000, a la propuesta XML Schema. • XML Schema. Una especificación independiente que se convirtió en una recomendación 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 más riguroso y tiene la ventaja de que la definición 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 estándar. • Estándares de los grupos industriales. Varios grupos industriales se han agrupadq para definir estándares XML para tipos específicos de documentos que son importantes para el intercambio de datos en su indu~tria. Por ejem~
90~
.' r:... ' :.. ;; ' .. ' '.,
,~"
¡
.'~:: ',;,!
El primer intento de estandarizar: los.·metadatos XML estaba "Contenido en la capacidad df::JDefinici6n de tipos-de, dodjinentds (DT.D)" tic"la"especificación 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 transferencüi"tle-fonUos). La 'Figura 25.6 muestra un DTD'que se podría. utilizar para un documento de pedido sencillo en la Figura 25.5. Esta DTD demuestra, solamente ,_',.'
Figura .25.6.!· DTD- para un' documento.simple d.e pedidos.
. i: .. ,; ~ "
902
SOL. Manual de referencia
una fracci6n de las capacidades completas de las DTD, pero ilustra los componentes principales de una DTD típica. Las entradas ! ELEMENT en la DTD definen la jerarquía de elemento que da al documento su forma básica. Las DTD mantienen estos tipos diferentes de elementos: • Elemento sólo 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 sólo elemento. El contenido del elemento son otros elementos (subelementos); es el padre en una jerarquía 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 vacío. 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 vacío 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 sólo de texto, indicado por las definiciones #-PCDATA. El elemento términos está vacío; 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. Obsérvese que esta DTD combina un estilo datos-corno-elementos (para la informaci6n del cliente) y otro estilo datos-corno-atributos (para los términos del pedido) solamente por facilitar la comprensi6n. En la práctica se elegiría un estilo o el otro para la representación de los datos y se utilizaría de forma conherente para simplificar el procesamiento. Las definiciones de tipos de documentos son fundamentales para hacer que XML sea realmente útil, en la práctica, en la representación 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 implementación de dicho documento~ resulta sencillo validar que un documento originado en alguna parte de la compañía, o incluso fuera de ·la compañía, sea un documento válido del
Capítulo 25: SOL y XML
903
tipo específico y se pueda procesar. Cualquier analizador XML, basado en las API DOM O SAX, es capaz de validar un documento XML en previsión del suministro de una OTO. Además, es posible declarar de forma explícita la OTD con la que el documento XML se debería 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 también carecen de un buen soporte para tipos definidos por el usuario (o corporación) 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 también en un documento de modificación de pedidos, un documento de cancelaci6n del pedido, un documento de pedidos atrasados y un documento de acuse de recibo del pedido. Sería 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 también son de alguna forma restrictivas en los tipos de estructuras de contenido que permiten, aunque en la práctica son lo suficientemente ricas para admitir las clases de documentos transaccionales necesarias para aplicaciones híbridas 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 después de la declaraci6n elementoPedido en la lista de elementos compraPedido, en la Figura 25.6, que significa «este elemento se puede repetir cero o más veces»). Aunque resulta familiar para los estudiantes que tratan con lenguajes informáticos, 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 después de la adopción 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 recomendación W3C oficial en mayo de 2001 y su soporte está creciendo rápidamente en productos comerciales relacionados con XML. Las DTD están todavía ampliamente admitidas para compatibilidad hacia atrás, pero XML Schema ofrece algunas ventajas convincentes y soluciona la mayoría 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 declaración 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. Además, el esquema en la Figura 25.7 es en sí mismo un documento XML, por lo que
904
SQL. Manual de .referencia
xmlns="http://www.w3.orgi2001/xMLschema->
. '-.1., .:_., .
., ." ".<':.: .:.... :,~. -;.::~
fractiondigits=·2~
1>
t' :~." ;-._ ,,'
~¡,=! -:!',,:".
o;. '~'
:'
.-'
.
. ".
. ,1 . ;~i .
,..
"
--;-'
i
---.C·-
"..,'.
-; ( ... '.
.;I·J
<~"
-'1 (.,
~:'
- : . . ':-" _"
.~,
-.
t, f'::-"
'. ;...'.
. " .
:c,;
-.-:'"
~l:!"
'.-~;
J,.
i,iI:!
~
• '..11,' :i':.:U:,:"':.
,:-,
¡''''._,.
~-,--:
-
';:;'~':';
-:'\....
'~(l\:;:'fo~,(;
:.:,
';',(.'.
NonNegativelnteger
Enter~~,
NonPositivelnteger
Enteros negativos o cero solamente.
InC
.Entero con signo de 32 bits.
Unsignedlnt
Entero .. , sin signo de 32 bits.
,• '
.,
•1
Short . ,,,) '... h '
·~L.. l'"
UnsignedShort· _ _ . ._
•••
~,,:
.'.'
~~
.'
,., ,~~t!?r
,
'\:Entero con signo de 16 bits.
.
~:' •• /Eilter~;sin signo
.;:. ;;.
••• __ .. _
~.'_
positivos o cero solamente.
... ' o .• . - . • • •
• • A _ _ . _• • •
._
•
•
de 16 bits.
. _ ••
'
, •• __ 0
.,
,.,j,.
j,\ r)
(:,,! ¡,:,;~:r!,j'; ~~:'::
Desde el punto de' vista de' las bases ·de ·datos. tel:fuerte 'soporte dCi)~L:;..St;:hériiá para los' tipos .de, datos y' estructuras.de,.datos~e.S-·una:-:de·Sus·(princípaIes"l.ventajas. XML Schema define alrededor'de 20 tipos de·.datos·incorpO'raaos;''ql,le''se-corres': de·datósu~fiñidosen 'S(¡)L,La·,Taola'25.YlistlÍ
los tipos ,de datos incorporádos en XML Schema.!TIás importantes .par3.'.e) procesamiento de bases de datos. :. __o -•• ,".:;'~~~'~ ,{j4:: . rAlo igual que los estándares SQL2,y :SQL3, XML-.Schema¡admite.tipos. de datos definidos por el usuario derivados de estos\tipos ·im;;or.poJ¡"ados·o,de otros tipos definidos por el usuario. Se puede especificar un;tipo.de datos'geúvado como una restricción.o otro tipo XML. Por ejemplo; veamos una¡definición;de un tipo
•• _
....
._
~-
Numérico, con posibles números decimales.
Decimal
Coma flotante con precisi6n estándar.
Float Double""
..
Coma' tlotar,tte: con' precisión -doblé.
,,¡ '{ • . • ,:". ,: ; . ' •
•• J¡,
;\'=
Datos de caracteres
de.caract~;~s ~d~ longitud ~~i;ble.·
String
Cadena
NormalizedString
Cadena con cafactefes de nu~va )íñea, i~~~{no del carro y tabulaciÓn converi:idos,a.esp·a~~o_<-~ _
Token
Cadena, procesada como normaliz-edStf.fn~; más eliminaci6n de espacios delante y detrás y
Tipos de datos incorporados en XML $chema (continuación)
Significado
Método
Gday
Día gregoriano (1 a 31).
GmonthDay
Mes/día gregoriano.
Otros datos Boolean
Valor TRUE/FALSE.
Byte
Dato de byte sencillo. con bit de signo.
unsignedByte
Dato de byte sencillo. sin bit de signo.
base64Binary
DalO binario, expresado en notación de base 64.
HexBinary
Dala binario, expresado con nOlación hexadecimal.
AnyURI
Internet URI, tal como http://www.w3.org.
Language
Lenguaje XML válido (inglés, francés •... ).
907
También 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 definición para un tipo complejo tipoListaRep, que es una lista de números de empleado de los representantes:
derivado tipoNumRep que restringe el número de empleados legales a un campo entre 101 y 199:
XML Schema también permite sobrecargar un tipo de datos definido por el usuario, pennitiendo adoptar uno de varios tipos de datos subyacentes dependiendo de la necesidad específica. Por ejemplo, en la definición anterior tipoDirCliente, el código postal de la dirección se define como un entero. Esto funciona para los códigos postales españoles (excepto en que no preserva los ceros), pero no para los códigos postales de Canadá con seis dígitos, que incluyen letras y dígitos. Un enfoque más internacional es declarar las versiones española y canadiense y posterionnente un código postal más universal, que puede ser cualquiera de los tipos:
name=~tipoNumRep·>
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 automáticamente la restricción. XML Schema proporciona un rico conjunto de características de tipos de datos (denominadas facetas) sobre las cuales se pueden construir restricciones. Éstas incluyen el tamaño de los datos (para datos de cadena y binarios), rangos de datos inclusivos o exclusivos, número de dígitos y dígitos fraccionarios (para datos numéricos), y listas explícitas 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 expresión regular como la utilizada en el lenguaje Perl. El XML Schema también proporciona la posibilidad de definir tipos de datos complejos, que son estructuras de datos definidos por el usuario. Por ejemplo, veamos una defini~ión de un tipo complejo tipoDirCliente que está compuesto de subelementos familiares:
name=~tipocpesS">
Con las definiciones de tipos de datos especificados por el usuario se puede definir con mayor facilidad estructuras mayores y más complejas. Por ejemplo, veamos una parte de un documento de pedidos en la Figura 25.7, expandido para incluir una dirección de facturación y envío y para permitir una lista de representantes:
... Aquí van otras declaraciones de elementos ...
type="tipoDirCliente~
/>
sat. ·MiUfiJal'de.f'eferéncia
90S
':- -Capítulo 25, Sal_ y XML
comillúa con otras declaraciones de.elementos... ,."
"
Elementos y atributos en XML Séhema .
.,,",;"
..
Además del soporte para una rica estructura de tipos de datos, XML Sehemá"tanibjén.prO~?~ci~l).,a! ~~ ~icl? voc.':lb.ul3;~~~ P~f:? ~~p~s~_ryc.~~ la ~struc.t~:.~ leg~~.?~ .I.Jn.tipo
• Contenido sencillo. El elemento dispone solamente de eonténii:lo' de texto (aunque, como se explicó en la sección anterior, el te~~o se puede restringir a datos de un tipo específico, como unaJecha o.un~á 'valor numérié~). ?~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-
;'J", ltos:y;.sn!propio contenido:de texto,,'AI coñtrario que·ehmodelo 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. rígida; ;Y:'los documentoS!iVálidos',del:>e~ ~!l .....adecuarse_a la secuencia definida.r:E"ste~tipo de contenido:se .defme.:utilizan~ do un atributo,mi-xed en·uni:elemento.compLe)lTYl,:.e:. 'l.':!: ~.:í'. ::;;:'-".1 '::t';.;....~ • Contenido vacío. 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 sólo elemento, sin elementos declarados. • Cualquier contenido. El elemento contiene cualguier mezc,la de' ~~iúénido 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:q~ju~t~~éÍl.!~ '. d~'~~~Ci9P~~;' (~~;I,~~.Cio~~:~. ~~f~~~q~o~~~,~§,~;.alni~B~~~Ja~ ~~ un archIVO e t~~I).t,tfj,: 1: .c·; .,.:.~~~.):~•.Ih ¿:;',H~ ¡g¡ ~~¡lilJ:lr J
Estos tipos de elementos básicos pueden apafecer·i.ndi~í(hialfuerjte~éÓ;'l~s 'declaraciones de elementos en el esquema. También se puede esi)ecifiqal:o-que.un elemento puede surgir varias veces en un documento y, opcionalmente,·:especificar un mínimo y un máximo número de sucesos. XML 'Scherná tainbi-eÍl'admire"lo's':válores 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 terminología XML es válof~ii, ~peró ~J.S?p'c~p~~ f(~;r~,; IP:~Stnp. ;E,~t~ .papapf
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í"; ':.;.'
.. 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-
~
910
SOL. Manual de referencia
Capitulo 25: SOL y XML
Hoja de estilo XML
...aquí van 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 están calificadas por uno de estos prefijos y, como resultado, ya no son ambiguas. Puesto que las referencias calificadas se pueden volver bastante complejas, es también posible especificar espacios de nombres predeterminados que minimizan la necesidad de prefijos. El siste~ ma de nombres completo de XML Schema es bastante más sofisticado que las capacidades mostradas aquí, pero las capacidades están claramente dirigidas a in· corporar la creación 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 validación basada en XML Schema. Se puede especificar el esquema al que un documento XML reclama conformidad dentro del propio documento, pero también se puede pedir a un analizador que valide un documento XML arbitrario con un esquema arbitrario.
D
-------Figura 25.8.
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 transfonnación se enmarcó en un par de especificaciones: eXtensible Stylesheet Language Transformation (XSLT) y XML Path lAnguage (XPath). Como XML, estas especificaciones tienen raíces 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 transformación, seleccionando los elementos del documento XML entrante que se van a transfonnar y dictando cómo 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 versión genérica de una página web en varios formularios que sean apropiados para representarlos en diferentes tamaños de pantalla y dispositivos de visualización. En el lenguaje XSLT, es frecuentemente necesario seleccionar elementos individuales o grupos de elementos a transformar, o navegar por la jerarquía de ele-
911
¡
¡
Documento XML de salida
Procesador XSLT
-----Transformación de un documento XML con XSLT.
mentas para especificar datos a combinar desde los elementos padre e hijo. XPath surgió como una parte del lenguaje XSLT para selección y navegación de elementos. Rápidamente se hizo patente que XPath era también útil para otras aplicaciones y la especificación se dividió de XSLT para tener la suya propia. En los primeros días de XML, XPath fue la capacidad de consultas de hecho para los documentos XML. Más recientemente, la atención 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 especificación 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 están en estado de borrador en proceso, y los dos lenguajes están fuertemente vinculados, con sintaxis y semántica común cuando es posible. Una descripción completa de XQuery y XPath excedería el ámbito de este libro. Debido a que XQuery 1.0 tiene solamente un estado de borrador en proceso, y no de recomendación oficial, está todavía sujeto a cambios en las revisiones de miembros del W3C. Sin embargo, un breve repaso de los conceptos de XQuery y unos pocos ejemplos ilustrarán la relación con SQL, y es poco probable que estos fundamentos cambien cuando XQuery 1.0 se convierta en un estándar oficial.
,I
Conceptos de XQuery
¡ I
Si el modelo de datos subyacente al lenguaje SQL es la tabla fila/columna, el modelo de datos detrás de XQuery es la jerarquía estructurada en árbol de nodos que
•
, i
912
\
SQL. MaHual ae, referencia
represeñtan· úii·doCUITié·óio ·){Me ){QueiY· utiliza reaiñiéñti·iúui'·¿s'i'i-üCiij·raeñ árl)oi de grano más fino que la jerarquía qe elementos de los documentos XML y XML Schema. Estos nodos XQuery son reievañres para·las consultas al estilo de las bases de datos: • Nodo elemento. Este tipo de nodo XQüery representa un elemento. • Nodo texto. Este tipo de nodo represéñi'á-Ios contenidos del elemento, Es un hijo del nodo elemento correspondiente, ._. • NódQ atributo. Este tipo de nodo representa un atributo y un valor de·atritiúto para un elemento. Es un hijo del nodo elemento correspondiente.. '. Nodo documento. Es un nodo elemento especializado que representa ·él nivel súperior o ra(, de un documento. .~ .'.. ~-; Para nayegar~or un árbol de elementos e identificar uno O más eleinentp~, P?ra su ..procesamiento, XQuery utiliza una expresión de rula. Una expresi6n~de ruta tieñe la mIsrñ"á'lunci6n en XQuery que una expresión de consulta SQL3,.. . descrita en el Capítulo 24, tiene en SQL. Una expresión de ruta identifica un nodo individual en el átb-PLd.e_ ~J.em~J1tºs.XQP~IY.~ e;sp.ecifica.Qdo upa..~eGyt;.I.lc!a. d.e Pª,s_o~.a través 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:
11. ~XP!~~~~4~~~jr~i~
~o~ ~~Íz:'PEI~ ~~~e~i~,~_~~i~i~,c
...I'~rte sUl'eqOr (la r'!Íz)..
913
CapítuJo,25:-50[ ,y XML
I
.j .••
I
Tabla 25.2. Al gunas expresiones.de rutas .)(Query normales. . ."" _.. ' ,,:./ .",1"':
~.:\1}F-~i.q~ ~e.J'f.~ .~._
•
Navegadon· . , .'
·;r'¡,i "
. j.
':'.
,.
Comi'enza en la parte superior de I"a Jerarquía y se ·mueve'hacia abajo desde ;libro, después' por el hijo parte, hasta .un hijo cap!'til,lo. '
'."
•..
~';·F
.. /capítulo
.
: I~.' . .,.
':i \. ~:~
,
,j'.
. /Ipár'r
..
!'..:;
~'..
~.
..
'.'.
~."
.
. '.1.
,l.:
~',.>.
:-
";,,
('. '¡',:'
'J'
;
,.~.
,,!' , " .. (; :,. :".
'¡;::
Selecciona el atributo niyelCab del nodo actual. -" ..:;.".
1¡
j
..'.
/cabecera~nivelcab
,
aparece'en cualquier pane"por'debajo del rioi:io'eil 'cursO erj")a }erargúía. ,'P'
"
t
Se mueve tiriCia arriba hasta el padre del nodo actual; después hacia abajo hasta "un' nodo hijo capítulo. ' . S.ele~,ciona.c:u;llqui"ern(cxio.hiJqJP~r.r que
!!. @n~velCal:?,
-: .. ::.
Se mueve hacia arriba desde el nodo actual hasta su padre.
",,'i
,1 .. 1 " ..
\.
'
Se mueve hariia abajo hastá!ün elemento hijo sección, y·hada·abajó desde allí hasta-un elemento hijo párr.
sección/párr h'ib~o'íparteic~pftüi'c;.
'(. .
,~'"
,,
••
'Selecciona el atributo ni veiCab de un nodo cabeceralhijo...
· . _ ..
. Los pasos en una ruta pu~den especificar el movimiento haéia 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~ién 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...o,ntipl!~ l~ ..ruta ,~ayia_ el elyrne~to objetivo. La Taqla 25;2 muestr,a algunas' e~pfeslOries de r,uta, típicas y his rutas de navegación 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 más elementos. Los elementos mismos podrían 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 atómico se trata normalmenle i com'o's1 flierá·-una·seCi.iéncia de un elemento: .! ".;
Selecciona el tercer elemento hijo con un tipOP"árr. ,.
párr {3] '. l'·."'
Selecciona tc;>d9S los hijos. del nodo actual. */párr
Selecciona todos los nietos párr del nodo ".' actual. ';'.' .-
capítulo[@estadoRev=-borrador-j
Selecciona todos los hijos capí tulo del nodo actual que tienen'un estado de revisión con valor bon:ador.
XQuery también recuerda a SQL, al ser un lenguaje con tipos fuertes. El documento de trabajo de la especificación XQuery está evolucionando para alinear los tipos de d~·tos XQuery- con los especificados en XML Schema, que se describieron antenornlente en este capítulo en·la sección·«XML Schema». Como SQL3, XQuery proporciona constructores para co.nstruir valores de datos más 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 expresión que se evalúa para producir un valor. Las expresiones de ruta son un tipo de expresión XQuery y producen una secuencia de nodos corno resultado. Otras expresiones pueden combinar valores literales, llamadas a funciones, expresiones aritméticas y booleanas y las combinaciones, encerradas nonnalmente entre pa-
9'14
Capítulo 25: SOL y XML
SOL. Manual de referencia
réntesis de éstas, para formar expresiones arbitrariamente complejas. Las expresiones también pueden combinar secuencias de nodos, utilizando operaciones de conjunto, como la unión o intersección de conjuntos, que coinciden con las operaciones de conjunto SQL correspondientes. Las variables con nombre en XQuery se denotan por un signo de dólar ($) delante de los nombres. Por ejemplo, $numPedido, $oficinaActual y $e serían nombres de variables XQuery válidos. 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 asignación en expresiones for o let.
Procesamiento de consultas en XQuery Las expresiones de ruta XQuery pueden proporcionar el equivalente XML de la sencilla instrucción SQL SELECT con una cláusula WHERE. Consideramos que una colección 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:
Identificar las oficinas dirigidas por el empleado número 108. /oficinas/oficina[jef:l08l
915
Obtiene el tercer párrafo del segundo capítulo de la parte 2. /libro/parte[2]/capítulo[2]/párr[3]
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 inglés «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 reunión de dos tablas y genera tres columnas específicas 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. { for $0 in document("pedidos.xml")/Ipedido[importe < 5000.001. $r in document(-representantes xml-l/lrepresentantes[num_empl :$p/pedido/rep) return { Sr/nombre, $p/fecha-pedido, $p/importe }
sortby (importe) }
Hallar todas las oficinas con ventas por encima del objetivo. loficinas/oficinalventas > objetivo)
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,lajerarquía XML tiene solamente tres niveles de profundidad. Para ilustrar las posibilidades de consulta en documentos XML más jerárquicos, consideremos una vez más el documento libro de la Figura 25.1. Veamos algunas solicitudes de consulta y sus correspondientes expresiones de ruta:
Hallar todos los componentes de capítulos que tienen el estado borrador. /libro/parte/capitulo[estadoRev:'borrador'J/*
En el nivel superior, los contenidos del elemento pedidos pequeños están especificados por la expresión XQuery encerrada entre las llaves más exteriores. La expresión for utiliza dos variables para reiterar por los dos documentos, variables correspondientes a las tablas PEDIDOS y REPRESENTANTES. Estas dos variables implementan efectivamente una reunión entre las dos tablas (documentos). Los predicados que al final de cada línea siguen la palabra clave for se corresponden con la cláusula WHERE de SQL. El predicado en la primera línea restringe la consulta a los pedidos con cantidades superiores a 5.000 €. El predicado en la segunda fila implementa la reunión, 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 expresión for especifica qué elementos se deberían devolver como los resultados de la evaluación de la expresión. Corresponde a la lista de selección 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 iteración se utilizan para calificar la ruta específica hasta el elemento cuyos contenidos se van
_______ J
916
Capitulo 25: SOL y XML
SOL. Manual de referencia
a devolver. Finalmente, la parte "sortby de la expresión funcjonacde-Ia"misma:for· Ola que la cláusula 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 expresión let en la iteración for para capturar valores de variables adicionales en el·bucle· for .que ,se pued:en n.ecesitar en predicados u otras expresiones. !:~ "-:1 ' , : ; • '" Una expresión if._then... else admite la ejecución condicionaL L~~Ju;naiones de agregación admiten consultas·XQuery agrupadas, que s~ Gor.r.etiPQnden ·con,.l~s c;onsultas de resllmen,SQL desj:ritas en el Capítulo 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 la·expr~sióo. de. ~onsul, la es bastante diferente, y .refleja.-la orientación de la expresión" y In¡n;m.y fuerte orientación de navegación. de 10& documentos XQuery y XML."~T':'.· . .
Bases de datos XML
,
.. '"-'-
Con la proliferación 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 mayoría de los productos de ba~es ,4e datos XML admiten XPath como capacidad principal de consulta, y mu,hos·de ellos han agregado extensiones propietarias a XPath para hacerlo un lenguaj-e. de consultas más 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 especificación 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 hacían una décadá,antes. Con -datos. externos represenlfido's de .forma creciente como XML, la mejor coin'cidencia es una'bas'e'de datos·que.lleva--el mismo modelo.·de -datos subyacente. La. elección de ;documento5- XML 'como ;l.rn formato nativo reduce la sobrecarga de resolución y cálculo 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 entrenadós~en -HTML y XML, úna' base- de' datos' XML 'puede ser. accesible a· más gente:que flas baSes de datos relaéionales 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, y·es demasiado pronto para juzgar su·éxito.e impacto finales en el mercado. Parece probable que una base de datos XML nativa pueda ser una buena decisici6n para las necesidades de gestión 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 de·ampliat¡·sus productos princi'pales para incorporar- las características más importantes' de-'riue':
917
vos modelos de dalOs en un paso que es lo suficientemente rápido 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 integración XML crecerá más estrechamente a lo largo del tiempo y los productos relacionales ofrecerán más y más características orientadas a XML
Resumen Este capítulo 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 orígenes en la imprenta y publicación; se diseñó originalmente como una forma de indicar y especificar los contenidos de los documentos, • La orientación a los documentos de XML produce una vista jerárquica natural de los datos. El desajuste entre las jerarquías XML y las tablas con filas y columnas de SQL es uno de los retos mayores cuando se integran las dos tecnologías. • Los documentos XML están formados por una jerarquía de elementos. Los elementos pueden llevar contenidos, pueden tener atributos con nombre y pueden tener otros elementos como hijos. • La integración 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 recuperación de datos XML en la base de datos. • XML Schema y el estándar anterior XML DTD definen estructuras rígidas para especificar tipos de documentos. Son útiles para restringir los contenidos de los documentos a una forma estándar 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 navegación de rutas lo hace bastante diferente al estilo SQL. • Se han introducido bases de datos XML nativas y se están cambiando para adoptar XQuery como un lenguaje de consultas nativo. Son un desafío al modelo relacional, pero los principales fabricantes de SGBD se están moviendo rápidamente para proporcionar extensiones XML a sus productos relacionales.
CAPíTULO
26
El futuro de SOL
SQL y las bases de datos relacionales basadas en SQL son una de las tecnologías más importantes del mercado informático actual. Desde su primera implementación comercial hace unas dos décadas SQL, se ha ido desarrollando hasta llegar a convertirse en el lenguaje de bases de dalos e.stándar. En esta primera década, el apoyo de IBM, la aprobación de los estándares, y el soporte entusiasta de fabricantes de SGBD hicieron de SQL un estándar dominante para la gestión de datos empresarial. En su segunda década, 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 década, SQL es la tecnología de base de datos estándar para la informática basada en Internet. La evidencia del mercado muestra claramente la importancia de SQL: • La segunda mayor compañía de softwa.re del mundo, Oracle, se ha construido sobre el éxito de la gestión 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 compañía de computadoras del mundo ofrece su línea de productos DB2 basada en SQL como base de todas sus líneas de producto, así como para ser utilizada en los sistemas de los competidores, y ha expandido su compromiso con SQL con la adquisición del SGBD de Inforrnix basado en SQL. • Microsoft, la mayor compañía de software del mundo, utiliza SQL Server como la parte fundamental de su estrategia para penetrar en el mercado de informática 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 compañía 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
SOL. Manual de referencia
~.-' • Tód~.:'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) ~stán construidas sobre bases._ de,datos basadas en SQL. . }!I! SQL está emergiendo como un están9"[ para bases de datos especializadas -:. ~_ ~·eD.:..aplicaciones que·vap de.~de·al~áceties"'ae datos, bases de datos de ponáti. '10 'lés~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 característica integral de Windows. disponible en la gran mayoría de sistemas de computadoras personales, y es una capacidad incorporada de productos software pe populares corno hojas de cálculo y generadores de infonnes. • El acceso basado en SQL a las bases de datos es una parte estándar de los servidores de aplicaciones para Internet, requerida por la especificación 12EE.
Este capítulo describe algonas de las tendencias actuales y desarrollos más importantes en el mercado de· bases de datos, así como'los proyectos de las principales fuerzas que actuarán.·sobre.la gesúón de SQL ~ las bases,de datos en .los próximos·años. '"
Tendencias'del mercado de bases' de datos El'mercado actual'para l.os productos de gestión' de base's de' datos excede'los 12:000 millones de dólares al año en beneficios de productos Y. servicios, -mientras'que hace una década· era de alrededor de 5.000 millones --de 'dólares ál año. En varia's O"cásiones, en la' década 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 gestÍón 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 análisis 'del negócio, Iá's arquitecturas de sitios Web .en tres capas han estimul~do una' nueva 'Ola' de tecnología 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 détada~ súp'Úne·\.in indiéio; h(tecnología. eri-bases de datos seguirá encontrando nuevas aplicaciones' y generando máyores'berieficios en "los años venidéros. Las tendencias que dan forma al mercado son el pJ;"e$agio de un buen est.ado de salud y apuntan a una tensión continua entre la maduréz:del mercado y la consolidación, '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 tecnología.d~ las bases de' datos relacionales se ha aceptado'como una tecnología de procesamiento de datos empresarial principal, y lás "b'ases-d.e datos rela-
921
cionales se han implantado en.casi-'todas ·las gra·ndes,corpo~.aciones,~.ebjdo\a~la importancia de las bases de datos corporativas y los años de experiencia en el uso de ·Ia teenología relacionál; muchas. si. no la mayorí-a. de I'as .grandes corporaciones, han seleccionado una.·única· marca de. SGBD como ·un e.slándar de-bases de datos empresarial. Una ·vez. que'dicho:estándar se ha establecido e.implant3do ampliamente en. una compañía, hay una gran. resistencia a cambiar de .marca. Incluso' si un' producto SGBD alternativo puede ·ofrecer:· ventajas para una aplicación particular o. puede representar una nueva y útil característica, .un. anuncio del fabricante estándar de que .esas mismas caracteríslicas están previstas para una versión futura ·tenderá a.evitar la pérdid-a.,del cliente del.fabricante estándar. H . ¡, . La tendencia de los estándares de bases de datos corporati.vos.ha.sido la·de 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 años se ha hecho tan importante, si" no más importante•..queJa. ventaja ·tecnológica. Con esta dinámica 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 años noventa, los analistas de la industria vieron y predijeron ·esta tendencia en Informix y Sybase. Oracle,·con una cuota de. mercado mucho mayor,.fue·Joezada 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 posición 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 desafío de los estándares 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 tecnologías de bases de datos, y crecen vendiéndoselas a· nuevos clientes. Estos nuevos clientes han ayudado a formar la tecnología y·a identificar las áreas de solución donde se pueden conseguir beneficios reales. Después de unos pocos años, cuando se han demostrado las ventajas. de la nueva tecnología, los nuevos fabricantes son fagocitados por grandes jugadores establecidos. Estos fabricantes pueden traer la nueva tecnología en su base instalada, y utilizan su fuerza en el mercado y sus ventas para imponerse a·sus competidores. Los primeros años de la década de los noventa asistieron a este panorama de adquisiciones de fabricantes de bases de datos. En los ,últimos años de ·esa década se aplicó el mismo modelo a fusiones y adquisiciones de fabricantes de SGBD. La adquisición 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 años después 1nformix fue adquirida por 1BM, continuando· esta particular cadena de consolidación." . ' ¡ ..
922
SOL. Manual de referencia
Capítulo 26: El futuro de SOL
Diversidad y segmentación del mercado
923
de la compañía. Las decisiones sobre la tecnología de la base de datos y la estandarización del fabricante era parte de la función de planificación de la arquitectura IS de la compañía. Las compañías agresivas se arriesgaron con nuevas tecnologías de bases de datos relativamente poco probadas, en la creencia de que podrían ganar ventajas competitivas utilizándolas. El crecimiento de Sybase en el sector de servicios financieros durante los últimos años ochenta y principios de los noventa es un ejemplo. En la actualidad la mayoría 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 están ahora suministradas por aplicaciones empaquetadas em. presariales junto con servicios de consultoría y personalización proporcionados por grupos de fabricantes de software. Algunos de estos fabricantes han alcanzado beneficios de muchos cientos de millones de dólares. Todos estos paquetes están construidos tomando como referencia las bases de datos relacionales basadas en SQL. La irrupción de aplicaciones empresariales dominantes ha tenido un efecto significativo en la dinámica 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 aplicación ERP empresarial, las bases de datos subyacentes se restringen a aquellas admitidas por los paquetes SAPo Esto ha tendido a reforzar la posición dominante de los jugadores del segmento superior de bases de datos empresariales, y dificulta la acción de los nuevos fabricantes de bases de datos. También ha tendido a disminuir los precios promedios de las bases de datos, puesto que el SGBD se ve más como una parte de una decisión guiada por la aplicación que como I;lmi decisión estratégica en sí misma. La irrupción de software empresarial empaquetado también 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 tensión 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.
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 continúan desarrollando nuevos segmentos y aparecen nichos que crecen rápidamente. En gran parte de la pasada década, el modo más útil de segmentar el mercado de bases de datos ha estado basado en el tamaño y escala de la base de datos (había 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 más diverso y está más adecuadamente segmentado, según la aplicación objetivo y las capacidades de la base de datos especializada para solucionar requisitos únicos de la aplicación. Entre los segmentos de mercado que han aparecido y han experimentado mayor crecimiento, están: • Bases de datos para almacenes de datos, centradas en la gestión de miles de gigabytes de datos, como los datos históricos de las ventas. • Bases de datos de procesamiento analítico en conexión (OLAP, online analytic . processing) y bases de datos relacionales de procesamiento analítico en conexión (ROLAP, relational online analytic processing) orientadas a realizar complejos análisis de los datos para descubrir tendencias subyacentes (minería de datos), permitiendo a las organizaciones adoptar mejores decisiones sobre el negocio. • Bases de datos móviles, para soporte de trabajadores móviles tales como representantes, personal de soporte, gente en el campo de servicios, consultores y profesionales móviles. Frecuentemente, estas bases de datos móviles están enlazadas a una base de datos centralizada para su sincronización. • Bases de datos incorporadas, que son una parte integral y transparente de una aplicación vendida por un fabricante de software independiente o un intermediario. Estas bases de datos están caracterizadas por pequeñas huellas y una administración muy sencilla. • Microbases de datos, diseñadas para dispositivos de aplicación tales como tarjetas inteligentes, computadoras en red, teléfonos inteligentes y PC de mano y organizadores. • Bases de datos residentes en memoria principal, diseñadas para aplicaciones OLTP de rendimiento ultra-alto, como las incorporadas en telecomunicaciones y redes de comunicaciones de datos, utilizadas para admitir interacción del cliente en aplicaciones de Internet de muy alto volumen. • Bases de datos agrupadas, diseñadas para aprovechar los potentes servidores de bajo coste utilizados en paralelo para realizar tareas de gestión de la base de datos con alta escalabilidad y fiabilidad.
Aplicaciones empresariales empaquetadas
Ganancias de rendimiento del hardware
Hace una o do~ décadas la gran mayoría de aplicaciones corporativas fueron desarrolladas en la propia corporación por el departamento de sistemas de información
Una de las contribuciones más importantes al ascenso de SQL ha sido un dramático incremento en el rendimiento de las bases de datos relacionales. Parte de este
l
924
SOL. Manual de referencia_.'
aumento en.el.rendimicntb iue.de1;?ida a;}os~avances en.la tecnología. de-bases de datos' y optimización-de consultas. Sin embargo. la mayor parte'de~la' mejora:en·el rendimiento de 'los SOBD 'vino de las gananc;ias en hl potencia dé procesamiento de los sistemas.informáticos subyacentes, ycambi6 en-e1.software:SGBD diseñado para capitalizar dichas ganancias: :Mientras que "el·rendimiento 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:() "más, 'año tras :año. ';-¡:. . Algunos de'los avances··más··dramáticos 'en el rendimiento;de Jos ·.servidotes viene·del crecimiento de los sistemas de: multiprocesamiento 'simétrico (SMP, SY11'i· metric Multiprocessing); donde dos, cuatro, .ocho o·incluso 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 pequeñas,";en paralelo. Los fabricantes OLTP tradicionales, como Tandem, siempre han .utilizado una arquiteccura.multiprocesador, y los. mayores.sistemas han· utilizado diseños multiprocesador durante. más de una década. En IOs ..años noventa, los:sistem.as ffiullijirocesador. se, convirtieron -en una parte' principal del·mer.cada de 'serv,idores basados en UNIX~;y"al'go después~¡'en un factor:impórtánte'en el..-:mereado de los servidores PC·de·altas1JréStaCioiles:~·~::... ,,: f: i .\,., "'. " . .':~' ,: Con la introducción 'de.placas·multiproc~sador; los 'sistemas SMP.¡;on·multiprocesamien~o' de.dos y cuaJro vías consiguieron su ,introducción; en.el.mec·cado dé los ser:viélores LAN, y..estu.vierori disponibles 'por menos ·de ·10.000' dólares.,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' hab¡tuaI.8,,0.16 procesadores !j' se venden i~n_ un-precio' de cientos de miles. de·, dólares. ·.Los:. servijiores UNIX niás:potentes::.actuaJmente se':pueden configurar...con más. de lOO.procesadores y.decerlas de.gigabYtes len. la memoria principal. Estos §istemas,: que ,rivalizan con"la poteñcia,;de ,computaéión de 'Jos .grandes sistemas· tradicionales!'p'reserrtan ! '. 'r;' ';:',11 ; ,;' ......:; ~1, ,~. precios 'multimillonarios: <:; Los sistemas.SMP:también ,proporcionaron benefiCios en' el rendimiento',en aplicaciones ,de áyuda,.a 'lá toma..de,de.cisi"Ones·y. análisis de dátos. Al ser más' 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_y·dividirla en varias rutas deiejediIeión en paralelo. Cuando un$GBD.cQIl-capacidades de consulta en paralelo. se instala en·un sistema SMP de,cl,latro u .óchQ vías·,.una consulta.qq.e podría suponer dos horas en 'un 'sistema 'de .un.único·proCesador, se'puede completar en merlos,de una.hbra.'Las 'coinpañías están .aprovechando·esta·mejora en· el rendiritiento'basada en 'eJ,baidware; de dos fonnas: obteniendo Tesulta"dos de. análisis del negocio y.llevando'a cabo'análisis más complejos y sofisticados. Los sistemas operativos que admiten nuevas características 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 creado·un dilema.especial'para los-fabricantes de'SGBD que neces'irán ·de'cidii:sf 'saltarse el sistema,'ope'rativo ·eil·;un 'intent~ .de·n1ejot~r 'el
CapítlJ/o'26: EHuturo."de SQL
925
rendimiento dejas bases de datos. ·EI·SGBD Sybase; por ejemplo{ plando se~intrí) dujo originalmente.operaba como un único proceso y asumía.Ja:responsabilidadlde su. propia gestión de. tareas, gesti6n de eventos··y. 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 sóbre~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 automática_para 'los 'sistemas Fivales;'que se' apoyaron ,en .el' sistema operativo:p.ar.a incorporatfla tarea de la· ges" lión, ,mientras·:quei Syoase tenía ·la ~sabrecarga.contjnuada de extender: y,.mejorar :su softWare de bajo nivel orientado a la mejora de rendiffiiento~ Este ciclo'ha,esperado diseños SMP,'y .Jos·,principales.fabricantes de bases de datos confían.ahora en los,sistemaS operativos'para e}:soporte de hilos'y escalado 8MP.. Pero:aún,existen los mismos: compromisos' en las nuevas características ,hardware. por aparecer, y~:se requieren deei6iones,estratégicas explícitas 'por, parte de los fabricantes de.SOBD. ... ,~ Actualmente,'la. búsqueda de cada -vez mayorrendirniento 'en las bases de datos no, muestra signós 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 relacionál, haciendo que el rendimiento sea igual, o mejor, que las mejores bases de datos no relacionales del pasado. Al mismo tiempo, por supuesto, continúa creciendo la demanda de cada vez mayores tasas transaccionales -en c~da¡~ez mayóres;'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!' ; ,; ",'.:. ", ",.
':,'", ••
.>-.
,.-.""
"
~,',
,,;,
Hardware para servidor.es de.•bases.·de -datos .~,
por Orade Corporation y su CEO, Larry Ellison. Ellison argumentaba que la era Internet había visto el éxilo de otros productos todo-en-uno, como equipamiento para redes y servidores caché Web. Orade anunció vínculos 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 más, esta vez en la forma de servidores de caché de bases de datos que residen en una red entre la aplicación y la base de datos corporativa. Estas tendencias apuntan el amplio éxito de la caché de las páginas Web en la arquitectura Internet, y postulan una oportunidad similar de la caché de datos. Al contrario que en las páginas Web, sin embargo, los contenidos de las bases de datos tienden a tener un carácter inherentemente transaccional, lo que hace mucho más importante y mucho más complicada la sincronización 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 cuestión de si el hardware caché para bases de datos calará o no se mantiene aún 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 selección del SGBD. El hecho de que el usuario esté centrado en el rendimiento de la base de datos, junto con el interés de los fabricantes de SGBD por vender configuraciones SGBD de alto precio y altos márgenes, 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 algún momento de la pasada década. Algunos se han centrado en el máximo rendimiento absoluto de la base de datos. Otros ponen el énfasis en el precio/rendimiento y efectividad del coste de su solución SGBD. Otros ponen el énfasis en el rendimiento para tipos específicos 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 después aparecieron dos pruebas independientes del fabricante. La prueba del débito y del crédito simulaba transacciones de contabilidad sencillas. La prueba TPI. definida por primera vez por Tandem, medía el rendimiento OLTP básico. Estas pruebas estandarizadas todavía eran sencillas de manipular por los fabricantes para producir los resultados que los colocaban en la posición más favorable. En un intento de traer más 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 estándares que pudieran permitir comparaciones con significado
Capítulo 26: El futuro de SaL
927
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 también asumió una función de cámara de compensación 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 común 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 más reciente, TPC-C, intenta medir no solamente el rendimiento del servidor de bases de datos por sí mismo, sino también el rendimiento de la configuración global cliente/servidor. Los modernos servidores, en un nivel de grupo de trabajo con varios procesadores, están 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 típicos (una agrupación de procesadores Alpha de 64 bits de muchos millones de dólares) exceden las 100.000 tpme. Transaction Processing Council ha ido más 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 están basadas en un típico esquema de bases de datos en almacenes de datos, e incluyen más consulta,s de análisis de datos complejas, en lugar de sencillas operaciones de base de datos más normales en entornos OLTP. Curiosamente, las pruebas TPC especifican que el tamaño de la base de datos debe aumentar al aumentar el número 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 provisión de las pruebas TPC se ha diseñado para agregar más realismo a los resultados de las pruebas, puesto que el tamaño de la base de datos y del sistema informático necesario para albergar una aplicación con demandas de 5.000 tpm es normalmente mucho menor que la escala requerida para albergar una aplicación con demandas de 20.000 tpm. Además del rendimiento en bruto, las pruebas TPC también miden el factor precio/rendimiento de la base de datos. El precio utilizado en el cálculo lo especifica el consejo como el coste de la propiedad durante cinco años de la base de datos, incluyendo el precio de adquisición del sistema informático, cinco años de mantenimiento y costes de soporte, etc. La medida del precio/rendimiento se expresa en dólares por TPC (por ejemplo «Orade en un servidor DELL de cuatro vías pasó la barrera de 500 $ por TPC-C»). Mientras que unos números altos son mejores para los resultados de transacciones por minuto, son deseables unos números bajos para las medidas del precio/rendimiento. En los últimos años, 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 todavía falta algo de tiempo para que las pruebas y comprobaciones del rendimiento sean parte del entorno del
928
Capítu.1o-26: El. futuro. de .saL
SOL. Manual de referencia'
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,ión. De forma -general, las:pequeñas ventajas en el rendimiento de una prueba para uILSGBD sobre otra estarán probablemenleenmascaradas por otros
factores': '~ "',
Estandarización de SaL
.'
.
. l,'
La adopción de un estándar ANSI/ISO SQL.oficial·fue uno de ·Ios -factores -principales que aseguraron la posición de SQL.como el-lenguaje estándar de base de datos, relaciQnales.,en los años ochenta.. La conformidad con el estándar ANSI! ISO se ha convertido. en un_eleménto~de:comprobación para.evaluar·lo·s produc.-. tos 'SGBD, por lo que- cada fabricante'de SGBD!;c0nsidera.."que :su;;producto'es comp~tible b está basado en .el estándar ANSI/ISO .. A ·:fines/de los·-dchenta e inicios! de· los noventa, todos los, productos SGBD ,populares evoluciOTiaroo·:para adaptarse.:3,laslpartes· del estándar :que .representaban' un;u$o,'cómún:·Jetr.as'~par tes,.:cb:mo ;el:l(,'~nguaje' de módulos.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 Capítulo -3, el estándar SQVl erá·.lfelativament~,débil. con··muchas -omisiones y áreas:'que se· dejaron a'.la :elección .de·la 1mplelÍ1enta~ón. Durante :varios años; el comité de~estándares'trabaj6.eniun,estándaI':.SQL2'.ey;.paridi:. do: que- J:em~diara_esta..debilidad. y. extendiera significativamente~el.lenguaje!SQL. AhontI:ario, que el: primer·.eslándal'.SQI.::•.oque·_especific~ba caraetetís.ticaSi,que ya estaban,disp0nibles'en la.rnayoIÍade..lqs .productos.cSQL, .el est~ml"".s.QL2,'cuan, do, se ;pJ:!bJ icó~:en ¡1992,-,sU-PUS0 un::intento· de J.ider:~,imás, quejde 'Seg~ir,;el·rqe.rQado~ Especificaba.'caracteóstigls:y.:fl;lncion~s·;que no estaban'iampliameilted.mple~entá:' das.en .los ,PI;oductos,.SGBD .actuales.-'lales ·_co~o; lo~
: :. . ; . :
':'.-
,-', ,
:
•
-: •••
929
de:procedimiento almacenado estandarizada como·SQL-PLM. En 1998;se estandarizó los· vínculos del lenguaje o-rientado a objetos para SQL·en la especificación SQL-OLB. ·Un·conjunto básico de.capacidades OLAP fueron' publicadas en un estándar SQL-OLAP en 2000. ' .. " , . '_';,' Aunque el progreso continuó sobre estas adiciones al estándar 'SQL2. "el trabajo en la parte central·del lenguaje SQL3 (denominada fundamentos del estándar) se centró en cómo agregar capacidades orientadas a objetos a SQL2. Esto se convirtió rápidamente en una actividad .muy controvertida. Los teóricos 'de las .bases de datos relacionales·y puristas adoptaron' una fuerte posición contra muchas de las extensiones propuestas.' Reivindicaban que las propuestas _-confundían temas conceptuales .y de arquitectura (por ejemplo, añadiendo subestructuras más allá de las tablas con 'filas'y columnas) con- temas de implementación (por ejemplo. temas de rendimiento·de bases de'datos normalizadas y reuniones multitabla). Los proponentes de las extensiqnes.objeto S.QL3 apuntaban a la popularidad de la programación. orientada a_objetos iBUaslte-cnicas de .desarroUo, e insistían 'en que la rígida estructura de frias ~y:coliJ.mnaside las bases de datos relacionales se debía extender para· abarcar c(~:mceptos-Jde;ºbje tos~; O "sería ·.omitida ,por :la re,!oluci6n ¡de!16s .objetos·. ;Sumrguni'en1ac;iónrfúé refo~aaa'e'n ~l.mercado;cuando los·fabricantes de~os principaLes.SGBIilrrelacionales agiégaron :extensiones or.ientadas.8Jobjetos;a-sus ·produ_ctos·•..;paratdesafiar la 'ofen~iYa de' las .bases de ·datos :Orientadas·rle 2: Fundamenlps.Es.el cuerpo principal,deJ:estándar.·enfocado.al:len' :. '1); ,guaje,S.QL 'mistno"Aquí.se.. especi.ficanJa~. instru~ciOnes .y;·cláu~ula~ S,QL. ~ .';.','. semántica 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.;a·9QjetQSl.:~')(; ··: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.
• Parte 4: Módulos almacenados persistentes. De forma:;similar,::cpntiene
Algunas partes del estándar estaban todavía en desarrollo cuando se escribió este libro, como se indica por los números que faltan en las paftes. Además, otros esfuerzos de estandarización relacionados con SQL se han dividido en sus actividades independientes. Un estándar independiente está bajo desarrollo para la gestión basada en SQL de datos multimedia, tales como contenidos de documentos de texto completo, audio y vídeo. Éste es, en sí mismo, un estándar con varias partes; algunas ya han sido publicadas. Otro estándar independiente hace oficial el SQL incorporado para Java, conocido como SQLJ. En el cambio de SQLl a SQL2, y después de SQL:1999, los estándares oficiales ANSlJISO SQL han aumentado en ámbito. El estándar SQLl tenía menos de 100 páginas; la sección Entorno (parte 1) del estándar SQL: 1999 es casi tan grande. La sección Fundamentos del estándar SQL: l 999 pasa de las 1000 páginas, y las partes actualmente publicadas, en conjunto, sobrepasan las 2000 páginas. El ámbito ampliamente expandido del estándar SQL: 1999 refleja la gran utilidad y aplicabilidad de SQL, pero el reto de implementar y adaptarse a un conjunto tan voluminoso de estándares es formidable, incluso para grandes fabricantes de SGBD con grandes plantillas de desarrollo. Conviene indicar que él estándar SQL:1999 adopta un enfoque muy diferente a las afirmaciones de conformidad con el estándar que los estándares SQLI y SQL2. El estándar SQL2 definió tres niveles de conformidad (entrada, intermedio y completo) e indicó las características específicas del estándar que se deben implementar para reivindicar la conformidad en cada nivel. En la práctica, los fabricantes de SOBO encontraron algunas características 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 características requeridas para la conformidad formal intermedia o completa. Con esta experiencia en mente, el grupo de estándares SQL:1999 definió solamente un nivel SQL nuclear de conformidad, que corresponde grosso modo al nivel de entrada de SQL2 más algunas características seleccionadas de los niveles intermedio y completo. Más allá de este SQL nuclear, las características 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 estándar que son más importantes para los mercados particulares a los que sirven y hace más práctico el cumplimiento de partes del estándar. Al escribir este libro, el estándar SQL: 1999 era demasiado nuevo para sopesar completamente su impacto en el mercado SOBO. Si puede servir como guía la experiencia con SQL2, los fabricantes evaluarán cuidadosamente y de forma individual los nuevos aspectos de la funcionalidad de SQL: 1999 y buscarán mediante la retroalimentación cuáles de sus bases de clientes son útiles. Con la nueva funcionalidad requerida por las características de SQL: 1999, como los tipos de datos defini90s por el usuario y las consultas recursivas, la implementación de algunas partes de SQL: 1999 supondrá más de un año incluso para los mayo-
Capítulo 26: El futuro de SOL
931
res fabricantes de SGBD. En la práctica el estándar SQLI (SQL-89) define las capacidades SQL principales admitidas virtualmente por todos los productos; el estándar SQL2 (SQL-92) representa el estado actual del arte en los grandes productos de bases de datos empresariales, y el estándar SQL: 1999 es un mapa para el desarrollo futuro. Además del estándar SQL oficial, los productos IBM y Gracle continuarán representando una poderosa influencia en la evolución de SQL. Como desarrollador de SQL y un asesor importante de la gestión de IS corporativa. las decisiones de IBM sobre SQL siempre han tenido un impacto principal sobre otros fabricantes de productos SQL. La posición dominante en el mercado de Gracle le ha dado un papel similar al agregar nuevas características 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 estándares IBM u Oracle. El camino futuro de la estandarización SQL aparece, por ello, corno una continuación de la historia de los últimos años. El núcleo del lenguaje SQL continuará estando altamente estandarizado. La mayoría de las características se convertirán lentamente en parte del núcleo y se definirán como paquetes añadidos o nuevos estándares en sí mismos. Los fabricantes de bases de datos continuarán agregando nuevas características propias en un esfuerzo continuado por diferenciar sus productos y ofrecer a los clientes una razón para su compra.
saL en la próxima década La predicción del camino del mercado de bases de datos y SQL en los próximos cinco a diez años es arriesgada. El mercado de computadoras se encuentra en medio de una gran transición a una era dirigida por Internet. Los primeros estados de esa era, dominados por World Wide Web y la interacción entre el usuario y el explorador, están dando lugar a una Internet ubicua utilizada para repartir todos los servicios de comunicación, información e interacción de los negocios electrónicos. La irrupción del pe y la creación de la era cliente/servidor de los años ochenta y noventa ilustra cómo los cambios subyacentes en el mercado de sistemas de computadoras puede producir cambios principales en las arquitecturas de gestión de da~os. Es probable que Internet tenga un impacto tan grande, si no mayor, en las arquitecturas de gestión de datos de los próximos diez años. No obstante, aparecen varias tendencias como predicciones seguras para la evolución futura de la gestión de bases de datos. Se analizan en las secciones finales de este capítulo.
Bases de datos distribuidas Al usarse más y más 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,,'.·
Capítulo 26: El futuro de SOL
paJes y miles· de.-usuarios -simultáneos. continuará erosianándose. Por contra, .las principales' bases de:datos ,corporativas serán cada ,yez,más y ·más·distribuidas, oon baBes de.. .:datos dedicadas' á .albergar las· principales. aplicadones y áreas"funcionales:de Ja corporaeión: 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.eracíón de estas bases'dedaLOs distribuidas debe.estar.al~amente coordinada. . Otro factor de "tensión sobre las .arquitecturas·-rle bases de datos c.entralizadas será et.,continuo-,crecimiemo de las computadoras .portátiles y otros dispositivos pOrtátiles"de informaeión. -Estos· dispositivos. son;'por ·su :naturaleza, más. útiles:si se p.ueden.convertir-.en una:parte integral de, una,r.~d distribuida..Sin embargo,·por su naturale.z.a. también·.están cOll~Gtados de forma, ocasional (algunas 'veces funcionan en-modo .conectado; otras· en modo pesconectado), y utiliza cedes-por· cable O inalámbricas. Las bases de datos principales de las aplicaciones' portátiles deben poder operar en este entorno,ocasionalmente ,conectado. . . . '=.' ·¡Estas; tendencias producirán 'una fuerte demanda_para' la distribución' de' datos. integración de las bases de ,datos, sincronización de datos, caché:de datos,· reparto de·datos' y tecnología·.'de bases ,de datos' distribuidas. Bn 'modelo: de datos de Wl támaño' que: se ajus~ a todó,y·transaccibnes distribuidas: no Les:.:el adecuado para el entorno altamenté:disl:ribúido·.eo'cualquier Jugarla cualquier, hora 'Que emergerá. Por contra, algunas transac~iones .requerirán. una';si:ocronización:absoluta conda base de datos centralizada principal, mientras que otras demandarán soporte para transacciones de larga duración en que la sincronización puede durar horas o días. 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-safío'de primer orden para los fabricantes de SG;BD en la siguiente déca~a y una fuente l. " ".,. .... . _. /.... • -, pnn~lpal'de beneficios para' los 'fabricantes que~prQpotcionen soluciones práct'icas, , . ' -. . '.' '. ~ ielativam'eiíte fácile's de'uiiiízar. " .. ' . ,
'Ei ;éxit6 é:dmpet¡'ti~o: oe WalMm; poi ejeITÍpl,d. 'se atri,DiJ.ye:!priI.Iéií,.aliñeíifel~ 'su:' iis6.ae·'la 't~'6i6g¡a~tle iii información' (conauc'ido pó¡'~la teciiologí~' de"oase's de'ldato§)"paTf(següir !sü'ln\ie6~ Úi(io 'y i¡~riHls'''de¡f6qná didH~?' bas"á"rH:ios2'én Ids 'datos··de· tt:anSacdQtl-e.S'de r8~:cájé! ro~:'E~tó.\perniitró-'3' iábblli~a.fuiFniihitiiitat su's fiívefes~'de' invéritanQ' y' gesti¿)hái de forma más directa sus relaciones con los proveedores. Las técnicaS' tle irnrierÍa de datos han permitido a las compañías descubrir tendencias inesperadas y relaciones basadas en sus datos acumulados (incluyendo el legendario descubrimiento de un comerciante de que las ventas noctumíi53d~pafiareS~stii15á~füer.teñfeñte~~ lacionadas con las ventas de cerveza). !:f'i. Parece::e1ar.q.. queJas- compañías cantinuaráfl;·acumulando·tanta.infQrroaO.0n como puedan..de·, sus ~clientes{i:'te.ntas, ,inv.entattiQsj, precios . yo Lotr_OS JaPto¿e~,.de,l-;negoJ:ió .. valioso-'pueaeh'gaIia('Una'vént~1a "é'ompetinva'ti¿meilda~
933
Internet crea unas grandes y nuevas posibilidades para esta clase de recopilación de información. Literalmente, todo cliente O interacción del posible cliente con el sitio Web de una compañía, clic a clic, proporciona indicios .potenciales de las necesidades, deseos y comportamiento del cliente, Ese tipo de información clic a clic puede general fácilmente decenas de megabytes de datos o más por día en un sitio Web ocupado. Las bases de datos para gestionar estas cantidades masivas de datos necesitarán incorporar sistemas de almacenamiento multinivel. Necesitarán imponar rápidamente grandes cantidades de nuevos datos, y analizar rápidamente 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 más actividades de marketing y ventas continuarán dirigiendo el crecimiento de los almacenes de datos. Además de la recolección y el almacenamiento de datos, habrá presión para realizar análisis del negocio en tiempo real. Grupos de consultoras IS están 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 ningún, o muy pequeño, retraso. Para cumplir este objetivo, los sistemas de bases de datos continuarán aprovechan· do los avances en la velocidad de los procesadores y tecnologías multiprocesadoras.
Bases de datos de rendimiento ultra-alto La irrupción 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 empequeñecen las cargas de trabajo de hace solamente unos pocos años. Cuando las bases de datos admitían principalmente las aplicaciones caseras utilizadas por unas pocas docenas de empleados a la vez, la cuestión del rendimiento de las bases de datos podría generar frustración 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 gestión de datos y la satisfacción de los clientes, pero las aplicaciones estaban todavía limitadas a muchos cientos de usuarios simultáneamente (las personas al teléfono en el centro de llamadas). Con Internet, la conexión entre un cliente y las bases de datos de la compañía es directa. Los problemas de rendimiento de la base de datos se traducen directamente en tiempos de respuesta del cliente más lentos, La no disponibilidad de la base de datos se traduce directamente en pérdidas de ventas. Además, las bases de datos y otras partes de la infraestructura de procesamiento de datos ya no se almacenan en búferes en los altos picos de carga de transacciones. Si una empresa de servicios financieros ofrece comercio interactivo o gestión de la cartera, necesitará prepararse para grandes volúmenes de carga en aquellos días 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 línea se debe preparar para afrontar la época de fin de año de mayores ventas, no sólo las tasas de transacciones de mediados de marzo.
934
Capítulo 26: El futuro de SOL
SOL Manual de referencia
Las demandas del comercio electrónico y el acceso a la información de Internet en tiempo real están ya produciendo factores de transacción con picos de .carga desde los servicios de Internet más populares, que son de un orden de magmtud o dos más rápidos que los sistemas RSGBD basados en disco convencionales más rápidos. Para cubrir estas demandas las ,compañías cam.biarán a las bases de datos distribuidas y reproducidas. Almacenaran los da.tos calientes en cach.é cerca de la interacción con los clientes en la red. Para cubnr las demandas de piCOS de carga utilizarán bases de datos residentes en memoria principal. Requerirán, en cambio, nuevo soporte para bases de datos para deci?ir los datos a ~l~a~enar en caché y los niveles de sincronización y réplica apropIados. En un pnnclpIo estos temas se aplicarán solamente a los sitios princ~pales y de may~r volumen, pero así ~omo la caché de páginas Web se ha convertIdo en una téCnica aceptada y ~senclal para mantener un rendimiento adecuado de los exploradores Web, la cache de los datos calientes se convertirá en la arquitectura de gestión de datos de Internet principal al ir creciendo el volumen.
Integración de los servicios de Internet y de red En la era de Internet, la gestión de las bases de datos irá convirtiéndose en solamente un servicio de Internet más, y debe estar fuertemente integrado con otros servicios, como el de mensajería, servicios de transacciones y la gestión de la red. En algunas de estas áreas, los estándares están bien establecidos, tal como el estándar XA para la gestión de transacciones distribuidas. En otros, los eS,tándares están en ciernes o acaban de emerger, como el estándar SOAP para enViar datos XML a través del protocolo HITP, y los estándares UDDI para buscar servicios en un entorno de red distribuido. La arquitectura de muchas capas que está dominando las aplicaciones centrales de Internet también plantea nuevas cuestiones sobre qué funciones se deberían realizar por parte del gestor de la base de datos y por otros componentes del sistema de información 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 solución. Cuando las transacciones de red conllevan una combinación 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 gestión de transacciones se traslada fuera de la base de datos y se requieren mecanismos externos. Un compromiso similar supone la irrupción de servidores de aplicaciones basados en Java como una plataforma de capa intermedia para ejecutar la lógica del negocio. Antes de la era Internet los procedimientos almacenados se convirtieron en una técnica SGBD aceptada para incorporar la lógica del negocio en la base de datos misma. Más 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 lógica del negocio escrita en Java, en este caso externa a la base de datos.
935
Todavía no está claro cómo se racionalizarán estas tendencias y si la lógica del negocio continuará esta migración a la base de datos o se establecerá en una capa del servidor de aplicaciones. Sin importar cuál de las tendencias predomine, se requerirá una integración 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 proporcionarán la mejor integración en sus propias líneas de productos. Todavía es una cuestión abierta si este enfoque prevalecerá en oposición al enfoque del mejor adaptado.
Bases de datos incorporadas La tecnología de bases de datos relacionales ha llegado a muchas partes de la industria informática, desde pequeños dispositivos de mano a grandes sistemas. Las bases de datos están por debajo de casi todas las aplicaciones empresariales, como el fundamento para almacenar y gestionar su información. La tecnología de bases de datos admite de forma más flexible un rango incluso mayor de aplicaciones. Los servjcios de directorio, una tecnología fundamental para la nueva era de servicios de red de comunicaciones de datos de valor añadido, permiten redes móviles, esquemas de facturación avanzados, servicios de mensajería inteligentes y capacidades similares. Estas aplicaciones de bases de datos incorporadas se han implementado tradicionalmente utilizando código de gestión de datos propietario y escrito para el cliente integrado con la aplicación. Este enfoque específico de la aplicación produjo el mayor rendimiento posible, pero a costa de una solución de la gestión de datos inflexible y difícil de mantener. Con la disminución 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 económicamente. La ventaja de una base de datos incorporada basada en estándares es sustancial. Sin un compromiso serio en el rendimiento, se puede desarrollar una aplicación de una forma más 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 rápidamente 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 tecnología de bases de datos relacionales. Como en otras muchas áreas de la tecnología de la información, 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.
Integración de objetos Lo más desconocido en la futura evolución de SQL es cómo se integrará con las tecnologías orientadas a objetos. Las modernas herramientas de desarrollo de apli-
936
Capítulo 26: El futuro de SOL
SOL. Manual de referencia
caciones y las metodologías están basadas en técnicas 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 están enraizados en la muy anterior etapa de COBOL de registros y cambios. no de objetos y métodos. La solución 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 estándares, 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 desafío de las bases de datos orientadas a objetos adoptando características orientadas a objetos, pero el resultado ha sido una proliferación de características no estándar y propias y ex~ tensiones SQL. Es claro que la tecnología de bases de datos relaciones y la tecnología de objetos debe estar más estrechamente integrada si las bases de datos relacionales van a permanecer como una parte integral de la siguiente generación de aplicaciones. Varias tendencias son visibles actualmente:
• Las interfaces basadas en Java a RSGBD. tales como JDBC y SQL incorporado para Java, continuarán aumentando rápidamente su popularidad. • Java se convertirá en un lenguaje de procedimientos almacenados más importante para implementar la lógica 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 aumentarán su soporte para tipos de datos abstractos y complejos que exhiben capacidades orientadas a objetos, tales como la encapsulación 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) varían sustancialmente. • El estándar SQL:1999 para las extensiones orientadas a objetos a SQL in~ fluirá en los productos de los fabricantes, pero lentamente, mientras los fabricantes continúan 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 integración con otras aplicaciones, crecerán en importancia, al hacer que la base de datos sea un componente más activo para integrar los sistemas. • XML emergerá como un formato estándar 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 ofrecerán extensiones de SQL para almacenar y recuperar documentos XML y para buscar y recuperar sus contenidos.
937
Todavía 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 continúan manteniendo que las capacidades orientadas a objetos construidas sobre un RSGBD no pueden proporcionar la clase de integración transparente necesaria. La mayor parte de ellos han adoptado de forma entusiasta XML como la corriente más nueva de la tecnología de objetos. Los fabricantes de SGBD empresarial han anunciado y agregado capacidades sustanciales relacionales orientadas a objetos Y. más recientemente, productos de integración XML y características, pero es difícil determinar cómo se están usando muchos de ellos. Además, la irrupción de XML como un estándar Internet importante ha dado lugar a una nueva ola de desafíos a las bases de datos que ofrecen bases de datos XML nativas. Con todas estas alternativas competidoras, la integración de las tecnologías orientadas a objetos en el mundo de las bases de datos relacionales parece cierta. La ruta específica que esta evolución adoptará permanece como el mayor desconocido en el futuro de SQL.
Resumen SQL continúa desempeñando una función significativa en la industria de computadoras y parece que continuará siendo una importante tecnología central: • Las bases de datos basadas en SQL son productos software líderes 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, portátiles y PDA manuales. • Todas las aplicaciones empresariales principales utilizadas en grandes organizaciones confían 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 desafíos del modelo de objetos, con extensiones SQL en las bases de datos orientadas a objetos/relacionales. • Las bases de datos basadas en SQL están respondiendo a las necesidades de las arquitecturas basadas en Internet incorporando XML e integrándose con los servidores de aplicaciones.
Parte VII
APÉNDICES
APENDICE
A
La base de datos de ejemplo
La mayoría de los ejemplos de este libro están basados en la base de datos que se describe en este apéndice. La base de datos de ejemplo contiene datos que admite una aplicación simple de procesamiento de pedidos para una pequeña empresa de distribución. Consiste en cinco tablas: 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.
• CLIENTES.
• REPRESENTANTES.
• •
•
La Figura A.l muestra gráficamente 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 continuación: 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
SOL. Manual de referencia
(OFICINA CIUDAD REGlON JEF OBJETIVO VENTAS PRIMARY REY FOREIGN KEY REFERENCES ON DELETE
Apéndice A: La base de datos de ejemplo
INTEGER NOT NULL, VARCHAR(15) NOT MULL, VARCHAR(lOJ NQT NULL. INTEGER, MONEY, MONEY NOT NULL, (OFICINA). TIENEJEF (JEFI REPRESENTANTES SET NULL)
TIENEJEF OFICINAS OFICINA CIUDAD REGION
CREATE TABLE (NUM_PEDIDO FECHA_PEDIDO CLIENTE REP
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.
FAB eHAR(3) NOT NULL, PRODUCTO CHAR(5) NOT NULL, CANTIDAD INTEGER NOT NULL, IMPORTE MQNEY NOT NULL, PRlMARY KEY
(NUM_PEDlDO).
FOREIGN KEY REFERENCES ON DELETE FOREIGN KEY REFERENCES ON DELETE FOREIGN KEY REFERENCES ON DELETE
FORMULADO POR (CLIENTE) CLIENTES CASCADE, SERVIDOPOR (REP) REPRESENTANTES SET NULL, PEDIDODE (FAB, PRODUCTO) PRODUCTOS RESTRICT)
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
943
VENTAS
CLIENTES NUM CLI EMPRESA REP_CLI LIMITE CREDITO
Figura A.1.
FORMULADOPOR TIENEREP
PRODUCTOS ID_FAB ID_PRODUCTO DESCRIPCION PRECIO
~
STOCK
SERVlDOPOR PEDlDODE
PEDIDOS NOM_PEDIDO FECHA_PEDIDO CLIENTE REP FAB
PRODUCTO CANTIDAD IMPORTE
-
1--
La estructura de la base de datos de ejemplo.
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.
944
Apéndice A: La base de datos de ejemplo
SOL. Manual de referencia
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.
103 101 lOS 102 110 101 106 loa 103 102 107 109 106 lOS 102 102 109 loa 104 103 101
La tabla CLIENTES.
NOIlBRE
""da
REP eLI
945
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.
946
SOL. Manual de referencia
DESCRIPCIÓN ID FAB ID PRODUCTO Rueda 2A45C REI Zapata pequeña 4100Y ACI OSA
XK47
Reductora
PRECIO 79,00€:
STOCK 210
2.750,OO€:
2S
355,OO€
38
180,OO€
O
1.875,OO€
9
Serie 3, cable
7,OO€
207
Serie 4, cable
117,00€:
139
41003
Hélice
652,00€
3
887P
Bulón
250,00€
2.
134,00€
203
SIC
41672
Plato
IMM
779C
90-kg brazo
ACI
41003
ACI
41004
SIe IMM OSA
XK48
Reductora
REI
2A44L
Llave
FEA
112
Huso
IMM
887H
Barrilete
sIe
41089
Retén
AeI
41001
Serie 1, cable
IMM
775C
50-kg brazo
1.425,OO€
S
ACI
4100Z
Zapata mediana
2.S00,OO€
28
OSA
XK48A
Reductora
AeI
41002
Serie 2, cable
REI
2A44R
Riostra
IMI<
773C
30-kg brazo
AeI
4l00X
Zapata grande
FEA
11.
Montura del motor
243,OO€:
15
!MM
887X
Brazo reten
475,OO€
32
REI
2A44G
Hilo de cobre
350,OO€:
14
Figura A,6. La tabla PRODUCTOS.
4.500,OO€
12
148,00€
lIS
54,OO€
223
225,00€
78
55,OO€
277
177,OO€
37
76,OO€
167
4.S00,OO€:
12
975,OO€:
28
25,OO€
37
APÉNDICE
B
Perfiles de los fabricantes de bases de datos Los fabricantes de sistemas de bases de datos perfilados en este apéndice han sido seleccionados debido a sus posiciones únicas en la amplia industria de bases de datos. Se incluyen los proveedores de productos SGBD empresariales líderes, algunas pequeñas compañías que son líderes en nuevas áreas de tecnología, pioneros de nuevos segmentos del mercado de bases de datos y fabricantes vinculados a tecnología de bases de datos incorporadas. Es fácil que cualquier compilación como ésta diste de ser exhaustiva, por lo que la omisión de una compañía no significa que sus productos o capacidades sean inferiores a las de los fabricantes perfilados aquí. Colectivamente, estas compañías 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
948 • • • • • •
Apéndice B: Perfí/es de los fabricantes de bases de datos
SOL. Manual de referencia
949
tidimensionales propietarias y se integra con las bases de datos relacionales convencionales. La última versión, 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 compañía de 500 millones de dólares (beneficios anuales) centrada en los informes y en el análisis del negocio. La línea de productos ha crecido para incluir un negocio sus· tancioso en productos de integración y servicios de personalización. Contiene aplicaciones desde análisis de un único usuario sobre estaciones de trabajo Windows hasta implantaciones OLAP empresariales basadas en Web para cientos de usuarios.
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 edición de catálogos integrado sobre bases de datos para diferentes medios que centraliza la gestión de los datos del catálogo, simplifica el proceso de prod!lcción del catálogo y automatiza completamente el flujo de trabajo para la producción del catálogo. El sistema incluye herramientas para crear, diseñar y publicar catálogos impresos y electrónicos, admite edición de una fuente única para diferentes medios a papel, CO-ROM y Web, y además gestiona de forma eficiente catálogos que contienen cientos de millones de elementos. Todos los productos de software A2i están en la parte superior de un SGBD basado en SQL. Incluyen aceleradores del rendimiento que mejoran el acceso al catálogo en un factor 10 a 1000 veces superior al de SQL, y presenta funcionalidad adicional específica del catálogo que admite exploración y ordenación interactiva de grandes bases de datos de formas que serían imposibles utilizando solamente un SGBD basado en SQL tradicional. La tecnología de búsqueda paramétrica de A2i (una alternativa a los formularios de consulta al estilo de SGBD que es intuitiva, fácil de utilizar y muy, muy rápida) permite a un usuario buscar todo un catálogo y localizar cualquier elemento o grupo de elementos en cuestión de segundos, de entre miles o millones de elementos a uno o varios en solamente unas pocas pulsaciones del ratón.
Birdstep Technology (www.birdstep.com) Birdstep Technology es una empresa de software noruega centrada en los sistemas inalámbricos y soluciones incorporadas. Birdstep entró en el negocio de las bases de datos con su adquisición 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 años y combinado con un gestor de objetos para crear el producto Raima Database Manager (RDM), ahora comercializado por Birdstep. Un producto Raima más 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á diseñado como una base de datos incorporable y la compañía 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 característica distintiva del servidor Velocis es su soporte explícito de los punteros incorporados del modelo de datos de red en una base de datos basada en SQL. Una instrucción CREATE JOIN especifica una relación explícita, 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 rápido. Velocis admite interfaces para lenguajes ClC++, Java, Visual Basic, Delphi, Perl, así como la interfaz ODBC estándar en la industria. Birdstep vende el producto Velocis como una edición servidor del Raima Data Engine. Hay una Mobile Edition complementaria para su uso en dispositivos portátiles con conectividad inalámbrica. Una tercera edición está enfocada a aplicaciones incorporadas.
Arbor Software (www.hyperion.com) Arbor fue uno de los primeros líderes en el desarrollo de bases de datos y herramientas de procesamiento en conexión analítico (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 analíticos. Las grandes corporaciones utilizan normalmente el conjunto de productos Essbase para crear infonnes integrados, análisis y sistemas de planificación. Las versiones actuales del producto Essbase admitenprocesamiento e informes analíticos cliente/servidor y basados en Web. También admiten datos precalculados (una característica propia de la mayoría de sistemas OLAP) y cálculos dinámicos 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 compañías de software independiente mayores en el mundo. Inicialmente centrada en software para grandes sistemas,
-'
950
SOL Manual de referencia
la compañía ha expandido continuamente su enfoque para proporcionar una extensa línea de productos y servicios de software para el procesamiento de datos empresariales. CompUler Associates se ha construid~ principalme~te mediante la adquisición, aprovechando sus grandes ventas dIrectas y relacIOnes bien establecidas con ejecutivos de sistemas de información senior Fertuoe 500. Mediante sus adquisiciones ha agregado de forma continuada más pro~ duetos a su catálogo. 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 investigación, bajo la dirección del profesor Michael Stonebreaker. El proyecto de investigación se convirtió en la fundación de una compañía independiente, que finalmente cambió su nombre al de logres Corporation en los años 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 mayoría de los analistas afirmaron el claro liderazgo técnico 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 estándar dominante. En los años noventa, logres fue vendida al grupo ASK y finalmente a Computer Associates. La versión actual del producto, Advantage lngres Enterprise Relational Database, es un amplio lote de productos de gestión de bases de datos relacionales. El núcleo Ingres/SGBD se ha aumentado mediante una capacidad que vincula el SGBD a la Web. El producto incluye acceso ODBC basado en estándares, un gestor de datos distribuidos sofisticado y soporte XML incorporado. Se ejecuta sobre la mayoría de plataformas de servidor UNIX y versiones del servidor Windows. Computer Associates también 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 núcleo del SGBD está fuertemente orientado a objetos, y muestra características de herencia múltiple, ejemplares y métodos y propiedades de las clases, y métodos de conjuntos. Los métodos para el SGBD orientado a objetos de Jasmine se pueden escribir en C, C++ o Java. Jasmine incluye una extensa librería de clases con soporte para tipos de datos multimedia (imágenes, secuencias de animación, audio, vídeo, texto enriquecido y diseño de páginas). CA está claramente posicionando a Jasmine como una nueva generación de bases de datos puramente orientada a objetos. No está posicionada para tener capacidades relacionales orientadas a objetos y no ofrece ningún acceso SQL a sus propias capacidades de gestión de datos. CA persigue la integración de lasmine con bases de datos relacionales dorsales (Oracle, Sybase, Informix, SQL Server, DB2) y archivos de grandes sistemas (VSAM y CA-IDMS). El vínculo a un dorsal Ingres es especialmente estrecho, con gestión de transacciones integrada fuertemente, seguridad y gestión de réplicas.
Apéndice B: Perfiles de los fabricantes de bases de datos
951
Computer Corporation of America Iwww.cca-int.com) Computer Corporation of America (CCA) es una de las compañías pioneras de software y ha estado implicada en la gestión de datos desde su fundación en 1965. Desarrolla y vende uno de los primeros sistemas SGBD: Model 204. El producto se ha mejorado sustancialmente con los años, pero el foco continúa 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 están 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 versión actual de Model 204 incluye opciones de consulta en muluprocesador y en paralelo para aplicaciones de almacén de datos. Con los años, 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 característica ú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 también 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 años 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 compañía fue fundada en 1979 en Túronto, Canadá, y actualmente sus oficinas centrales están 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 están bajo la capa de acceso SQL. Estas llamadas proporcionan acceso d~recto .a la capa de gestión de almacenamiento de Empress para operaciones .d~ mserclón, actualización, borrado y recuperación 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
SOL. Manual de referencia
Apéndice B: Perfiles de los fabricantes de bases de datos
radas. Ofrece una rica colección de tipos de datos más funciones y procedimientos definibles por el usuario. Para las aplicaciones basadas en Internet, Empress también ofrece interfaces para lenguajes de secuencias de comandos para los lenguajes de secuencias de comandos Perl y Tclrrk.
953
tienen su operación no necesita mantenimiento, además de una arquitectura ampliable. Se proporcionan interfaces OnBC 3.0 y JDBC. Los productos de la compañía complementan el núcleo 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 versión inicial de su sistema de bases de datos orientado a objetos
Los productos de bases de datos SQL NonStop de Hewlett-Packard son resultado de su unión con Compaq en 2002. Varios años antes, en 1997, Compaq (en esa época un fabricante de ·PC y servidores con arquitectura Intel) adquirió Tandem Computers, uno de los primeros líderes en el mercado de sistemas de computadoras tolerante a fallos. Muchos sistemas Tandem son utilizados por servicios financieros y compañías de transporte para el uso en aplicaciones de procesamiento de transacciones interactivas que demanda una operación sin interrupciones 7 días a la semana y 24 horas al día. 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 escribían en el lenguaje de aplicaciones de Tandem (Tandem Applicarion Language, TAL). Los sistemas Tandem más recientes se basan en sistemas operativos UNIX. La gestión de las bases de datos para aplicaciones sobre sistemas Tandem ha sido proporcionada por muchos años 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 técnicas especiales tales como los discos en espejo. También aprovecha la arquitectura multiprocesador inherente de Tandem y proporciona capacidades de bases de datos distribuidas. La interfaz de programación para NonStop SQL es mediante SQL incorporado. Durante los años ochenta y principios de los noventa, virtualmente todo fabricante de minicomputadoras tenía su propia implementación basada en SQL privativo (Digital con RdbNMS, Hewletl-Packard con Allbase/SQL, Data General con DG-SQL, etc.). Con los años. el resto de fabricantes de sistemas ha llegado a la conclusión que el alto coste en el mantenimiento de sus SGBDR con características competitivas era prohibitivo. También tenían dificultad en gestionar las funciones duales de competir con fabricantes SGBD independientes (tales como Oracle) y trabajar con ellos como compañeros ISV en sus plataformas. Como consecuencia, Hewlett-Packard (mediante su adquisición de la antigua línea 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 todavía 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, diseñado para ejecutarse en sistemas con 2 a más de 4.000 procesadores. NonStop SQL MX es una versióo NonStop SQL extendida con capacidades relacionales orientadas 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 solución con caché proporcionando un acceso rápido 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 años 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. Después de más o menos un año, la compañía aseguró su base instalada de clientes übjectStore volviendo a crear una división Object Design, responsable de la línea de productos ObjectStore, que permanece como un producto principal de la compañía en la actualidad. En mayor de 2001, eXcelon amplió de nuevo sus ofertas con C-bridge, una compañía 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 implantación de soluciones basado en estas tecnologías.
Gupta Technologies (www.guptaworldwide.coml Gupta Technologies fue fundado por un antiguo gestor de la división de microcomputadoras de Oracle, Umang Gupta. El nombre inicial de la compañía 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 años de los noventa, la compañía 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 compañía ha evolucionado considerablemente desde sus orígenes 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 información basado en tecnología RISC (por ejemplo, teléfonos inteligentes) e incluso tarjetas inteligentes. Deja una pequeña huella y
~
954
SOL. Manual de referencia
Apendice B: Perfiles de los fabricantes de bases de datos
IBM Corporation (www.ibm.com) lBM, la mayor compañía de computadoras del mundo, también 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 años setenta. En las siguientes dos décadas, la base de datos relacional líder de IBM (DB2) para sus grandes sistemas promovió varias capacidades relacionales que han abierto el camino a los productos de líderes SGBDR y a generaciones de estándares SQL. En este mismo tiempo, la tecnología 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 gestión de datos IBM bajo un único paraguas (utilizando el nombre OB2-Universal Database) y para ofrecer su tecnología de bases de datos relacionales DB2 a plataformas no JBM de otros fabricantes líderes del sistema UNIX. Además de su propio desarrollo de bases de datos, IBM expandió su alcance de b~ses de datos sustancialmente, con la adquisición 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 también ha sido un voraz fagocitador de otras compañías y tecnologías 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 línea de productos de software de gestión 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 implementación 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, réplica y distribución de datos y la mayoría de áreas de la actividad de bases de datos. Aunque IBM ha hecho que sus productos estén disponibles sobre plataformas no IBM, la gran mayoría 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 núcleo de DB2 está en los arandes sis~asDB2.
~
_ 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 informática portátil. El almacén
955
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 línea de producto DB2. UniVerse está enfocado en la gestión de datos basada en cliente/servidor y web, con una baja sobrecarga de gestión, pero también con un considerable solapamiento con otros productos IBM. Finalmente, es de notar que IMS (una base de datos jerárquica no SQL cuyo origen es anterior ai modelo relacional) permanece como un producto IBM de gestión de datos muy importante, con desarrollo continuado.
Informix Software (véase IBM Corporation) Informix fue uno de los líderes originales en el mercado de bases de datos relacionales basadas en UNIX. El primer SaBD relacional de la compañía se implementó sobre sistemas de microcomputadoras basados en UNIX a principios de los años ochenta, y se conocía 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 número de sistemas, desde PC mM bajo MS-DOS a grandes sistemas AmdahI que se ejecutan sobre UNIX. lnformix fue también uno de los primeros fabricantes de bases de datos en expandir sus ofertas de productos más 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 años noventa Informix expandió su línea de productos al área de la automatización de oficinas, incluyendo entre otros productos una hoja de cálculo 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 básicas de la base de datos. Uno de sus productos principales durante la mitad de los años noventa fue Informix Parallel Server, la tecnología líder en la llamada tecnología 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 simétrico (SMP). Posteriormente, Informix estableció una posición líder en la tecnología relacional orientada a objetos mediante la adquisición de Ilustra. Ilustra era una arriesgada empresa de software de bases de datos, liderada por Michael Stonebreaker (el mismo profesor de Berkeley que había liderado el desarrollo de Ingres años antes). Un efecto colateral de la adquisición de Ilustra fue la proliferación de líneas de productos y equipos de desarrollo en Infonnix, lo que supuso alguna confusión entre los clientes de lnformix. Cuando el mercado de bases de datos empresariales se convirtió en una carrera con tres caballos en los últimos años noventa, Informix se encontró como un competidor mucho más pequeño que los «tres grandes» (Oracle, IBM y Microsoft). Los recursos de Informix también se dividieron entre sus negocios de gestión de datos originales y un negocio emergente y de mayor crecimiento en herramientas de integración de datos empresariales. lnformix vendió la parte de bases de datos de su negocio a IBM en abril de 2001, por más de 1.000 millones de euros.
956
Apéndice B: Perfiles de los fabricantes de bases de datos
saL. Manual de referencia
La parle de la integración de datos del negocio se denominó AscentiaI Software y continúa siendo un foco en ese mercado.
Microsoft Corporation (www,microsoft.comJ Microsoft Corporation, la compañía de software para computadoras personales mayor del mundo, es también un fabricante principal en el mercado de bases de datos basadas en SQL. La primera incursión 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 gestión 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 versión del SGBD Sybase pasado a OS/2. Aunque Microsoft posteriormente abandonó OS/2 a favor de su propio sistema operativo Windows NT, SQL Server continúa 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 años noventa, Microsoft adquirió Foxbase Corporation, desarrollador del SGBD Foxbase. Foxbase se había establecido como un clan muy satisfactorio de dBASE, el producto de bases de datos más popular y utilizado en PC. Mediante la adquisición, Microsoft desafió a Bodand Intemational, que había adquirido los derechos de dBASE poco antes. Mientras que la adquisición de Foxbase se enfocó más 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 gráficas. Después de varios desarrollos de prototipos iniciales no fructíferos, se lanzó el nuevo producto resultado, Microsoft Access. Microsoft continúa en la actualidad como un producto de bases de datos ligero independiente y como un pilar para bases de datos de producción basadas en SQL. Microsoft también 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 introducción 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 asociación de fabricantes de bases de datos, para adoptarlo corno un estándar de API llarnable para bases de datos. Esta primera versión de ODBC se construyó finalmente sobre los estándares ISO formales y CL! (SQL CaU-Level Interface). Microsoft ha continuado evolucionando ODBC y expandiendo sus capacidades. .
I
I
957
Microsoft también 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 jerarquía 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 están en la capa superior de ODBC para el acceso a bases de datos relacionales. En paralelo con la evolución 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 características de SQL Server han crecido para incluir un servidor OLAP integrado y capacidades de información de negocios, poniendo a Microsoft en competición 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 conmutación por error, soporte multiprocesador de sistemas SMP hasta de 32 vías y servicios de réproducción mucho más extensivos para bases de datos distribuidas en línea y sin conexión y, más 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 gestión de datos empresariales continúa, pero Microsoft sigue trabajando, versión a versión, hacia ese objetivo.
l' MySQL AB (www,mysq/.comJ
I
MySQL AB es una compañía sueca que publica y distribuye la base de datos SQL de código abierto más popular, MySLQ. Fundada por dos suecos y un finlandés (David Axmark, AlIan Larsson y Monty Widenius), la misión de la compañía es «hacer la gestión superior de datos disponible para todos». La compañía pertenece principalmente a sus socios fundadores y tiene el objetivo flrme del modelo de fuente abierta. El software MySQL, incluido el código fuente, está disponible para su uso no comercial bajo una licencia GNU. Los socios han hecho crecer MySQL como una compañía virtual, con empleados distribuidos por el mundo. La compañía obtiene sus beneficios del soporte, formación 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 tamaño bastante pequeño y ofrecer un gran rendimiento. Las capacidades del producto continúan creciendo con una base activa de usuarios que contribuye a las mejoras. Monty Widenius, el principal autor del producto MySQL original, actúa como moderador para las contribuciones y orquesta las versiones formales desde MySQL AB.
958
SOL. Manual de referencia
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 réplica 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 automáticamente con identificadores de filas disponibles mediante la interfaz SQL. Las asociaciones de objetos en ~~OO están disponibles para su uso como un criterio de reunión SLQ. Los procedimientos almacenados y disparadores se presentan mediante características SQL extendidas. La sintaxis SQL extendida también 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 estándar. El pr~ducto ObjectivitylDB está centrado en la gestión 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 gestión 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 años Durante los años 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, además 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 años noventa. Una de las p.nnclpales ventajas de Oracle es su portabilidad. Está disponible en docenas de s~stema~ de computadoras diferentes, desde portátiles 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 posición líder en el
Apendice B: Perfiles de los fabricantes de bases de datos
959
mercado como un estándar de bases de datos corporativas impuesto por el departamento de sistemas de información 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 años, 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 reivindicación como líder en el rendimiento OLTP. Una serie de anuncios en las publicaciones industriales de informática proclamaban un importante nivel de 100.000 TPC-C transiciones por minuto en una agrupación de servidores SMP 64-bit Digital Alpha de altas prestaciones. Gracle ha combinado de forma coherente buena tecnología con ventas agresivas y campañas de marketing de gran perfil (incluida la presencia de su flamante CEO y fundador, Larry ElJison). Ha expandido su línea de productos para incluir no solamente software SGBD y herramientas de desarrollo y gestión de bases de datos, sino también software para aplicaciones empresariales orientado a aplicaciones financieras y de gestión del negocio. Los productos centrales de servidor de Gracle también incluyen un servidor de aplicaciones para implementar aplicaciones Internet de varias capas. Oracle también 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 consultoría y mantenimiento también representan una parte importante de sus beneficios. También 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 gestión de datos empresariales continúa siendo el núcleo del negocio de la compañia. Oracle8 y Oracle8i, introducidos en 1998 y 1999 respectivamente, y Oracle 9i, introducido en el 2000, representaron unos pasos importantes en la evolución 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 almacén de datos. Para adaptarse a un amplio rango de sistemas, continúan proporcionándose capacidades SGBD de bajo nivel mediante el producto Oracle Light para sistemas portátiles. Gracle 9i está especialmente centrado en la integración del SGBD Oracle con las tecnologías Internet, tales como servidores Web y de aplicaciones. Además, 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 visión de OracIe, la forma del almacenamiento de datos fundamental es el sistema de base de datos centralizado para toda la información en una organización, que debería estar accesible en cualquier momento y en cualquier lugar mediante Internet. Un control central y una administración más sencilla proporcionada por esta arquitectura son los puntos de venta claves para Oracle en las organizaciones rs empresariales.
960
Apéndice 8: Perfiles de los fabricantes de bases de datos
SOL. Manual de referencia
961
desarrolló Btrieve, fue adquirida en 1987 por Novell, el fabricante del sistema operativo para redes líder en esa época (NetWare). Como resultado, Btrieve se convirtió en una parte más 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 tecnologías en bases de datos se tradujeron en una nueva compañía, 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 pequeño y medio tamaño, así como a departamentos de grandes compañías. El producto actual de Pervasive, Pervasive SQL, combina sus productos Scalable SQL y Blrieve. Su importancia radica en sus decisivas características para el mercado de la pequeña o mediana empresa. Esto incluye baja administración de la base de datos, ampliación para soportar volúmenes de negocio, una pequeña huella SOBO y la capacidad de gestionar volúmenes 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.
Oracle también está siguiendo de forma agresiva un enfoque de un fabricante para las tiendas empresariales de tecnologías de la información. Con la introducción de los paquetes de aplicaciones de OracIe en los años noventa, OracIe se convirtió en un competidor para fabricantes de aplicaciones empresariales como SAP, BAAN y PeopleSofl. La adición del servidor de aplicaciones Oracle puso a OracIe en competencia para servidores de aplicación 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 compañías es con un enfoque «todo-Orade».
Persisten ce Software (www.persistence.com) Persistence Software estaba inicialmente centrada en un software que cubría el salto entre las tecnologías de desarrollo orientadas a objetos y de mensajería (incluyendo los agentes de solicitud de objetos) y la tecnología de bases de datos relacional. Sus productos de software intermedio albergaban estructuras y solicitudes de gestión 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 compañía incluye versiones diseñadas para incorporar desarrollo C++ o Java (mediante Enterprise JavaBeans). Una de las características 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 continúan ofreciendo independencia de la base de datos, integrándose 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. Más recientemente, Persistence ha vuelto a configurar su tecnología caché y la ha empaquetado en dos productos distintos. Persistence Dynamai es un producto diseñado para acelerar la búsqueda webdinámica, mediante la caché de las páginas Web generadas. Persistence EdgeXtend es una caché de datos para servidores de aplicaciones, diseñada para acelerar sus operaciones en aplicaciones intensivas sobre bases de datos. Funciona con BEA WebLogic e IBM WebSphere.
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 compañía fue fundada en 1998 por Bruce Scott, quien ya había 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 creación de varias de las primeras versiones principales de Oracle. En 1984 cofundó su segunda compañía exitosa de bases de datos, Gupta Technologies, con su producto SQLBase. Los productos PointBase se centran en permitir informática portátil, con sus requisitos especiales (réplica y sincronización de datos), y proporcionar capacidades de base de datos en una huella en memoria muy pequeña en el lado del cliente (por ejemplo, en dispositivos de mano). Para servir a este mercado PointBase se presenta en tres versiones. Una versión micro proporciona la menor huella y es apropiado para entornos muy restringidos, como dispositivos de mano con baterías. Una versión incorporada aumenta la huella para sistemas con una mayor memoria, pero en la que la base de datos está todavía invisiblemente incorporada en la aplicación. Una versión de servidor proporciona el dorsal.
Pervasive Software tiene sus raíces en los primeros días 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.ompañía que
La base relacional orientada a objetos Postgres tiene sus raíces en la Universidad de California, en Berkeley, cuna de la base de datos relacional pionera lngres.
1
962
SQL. Manual de referencia
Desde fines de los años ochenta hasta irucios de los noventa, el profesor Michael SlOnehreaker y sus colegas trabajaron en la extensión del modelo relacional para incluir capacidades orientadas a objetos, generando los prototipos de Postgres. A mediados de los años 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, después 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 distribuyéndolo a la comunidad de investigación corno PostgreSQL. Dadas sus raíces en la universidad, Postgres fue un ajuste natural para el movimiento de código abierto y comenzó a construirse a sí mismo como una base de datos de código abierto. PostgreSQLorg es la organización que finalmente se formó para organizar y coordinar el desarrollo de PostgreSQL En la actualidad actúa 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) Quadbase SQL es un sistema de base de datos cliente/servidor basada en SQL para
pe compatibles con IBM. Se ofertó originalmente a principios de los años noventa
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 implementación 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 características 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 atención al rendimiento. Quadbase también alberga esquemas de sólo lectura que permiten utilizarlo para crear y acceder a bases de datos de sólo lectura sobre CO-ROM. En los últimos años, la compañía ha aumentado el énfasis en sus herramientas de gráficos e informes y ha reducido se esfuerzo en sus productos de gestión de bases de datos.
Apéndice 8: Perfiles de los fabricantes de bases de datos
963
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 transfonnación de datos de alto rendimiento, limpieza y comprobación de la integridad. El software Red Brick también permite precálculo automático de valores de datos agregados (sumas, promedios, mínimos y máximos) durante el proceso de carga de la labIa. . El SGBO Red Brick también se centrÓ en una implementación de alto rendimiento de la estructura de esquema en estrella, frecuentemente encontrada en apljcaciones de almacén de datos. Su tecnología STARindex, y la capacidad asociada STARjoin, implementa soporte para esquemas en estrella en la estructura de la base de datos misma. El SOBD también [jene como característica índices de mapas de bits adaptativos para una selección rápida de los datos de tablas muy grandes. Las extensiones SQL en el lenguaje RSQL gestionan estructuras de consultas típicas para la toma de decisiones, tales como seleccionar los tres mayores o el percentil 95 de filas basándose en algunas medidas numéricas. A pesar de su temprana introducción en el mercado de almacén de datos y varios éxitos tempranos en clientes, a Red Brick le resultó difícil mantener su éxito inicial. Otros fabricantes de bases de datos mucho mayores, incluyendo Oracle Corporation, Sybase, IBM y finalmente Microsoft, vieron el almacén 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 líneas de productos. Aunque sus productos tenían ventajas técnicas reconocidas, Red Brick vio que sus clientes decidían esperar a sus fabricantes SGBD actuales: ..L a compañía 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 compañía de éxito en la mitad de la década de los ochenta, ~undada con decenas de millones de dólares de capital de riesgo. El equipo fundaCIOnal de la compañía y muchos de sus primeros empleados provenían de otros fabricantes SGBD, y para muchos de ellos. Sybase representaba la segunda o tercera SOBD que construían. Sybase posicionó de una forma bastante efecti:a su producto c~m.o el SGBD relacional para aplicaciones en línea y puso el énfaSIS en las caractenstlcas técnicas y de arquitectura que lo distinguían de productos SGBD basados en SQL de su época. Entre estas características están las siguientes:
Red Briek Systems (véase IBM Corporation) Red Brick (cuyo nombre está basado en el edificio de ladrillo rojo donde se fundó la compañía, en Los Gatos, California) fue uno de los primeros pioneros en el mercado de almacén de datos. Su fundador, Ralph Kimball, sigue siendo un experto reconocido en el almacén de datos. El núcleo de la oferta de la compañía es un SOBD basado en SQL que está fuertemente optimizado para aplicaciones de almacenes de datos..
• 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 gestión y de entrada/salida para una máxima eficiencia. .. • Una API para programación, en lugar de la interfaz SQL incorporada uuhzada por la mayoría de fabricantes SGBD de la época.
964
SOL Manual de referencia
• Procedimientos almacenados, disparadores y un dialecto Transact-SQL que ampliaba SQL hacia un completo lenguaje de programación para construir partes sustanciales de una aplicación en la base de datos misma. Un marketing agresivo y un abanico de primera clase de inversores arriesgados hizo que los analistas industriales prestaran atención a Sybase, pero fue un posterior trato OEM con Microsoft (el fabricante líder de software para pe) y AshlonTate (el fabricante de bases de datos para pe líder), lo que posicionó a la compañía 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 estratégico de IBM y Microsoft) para que Microsoft lo distribuyese en sistemas informáticos 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 después) continúa siendo el SGBD estratégico de Microsoft para Windows NT; Microsoft se ha separado de Sybase, buscando su propia ruta de desarrollo. Sybase continúa 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 años de los ochenta fueron copiados últimamente por otros fabricantes SGBD. El impulso inicial de Sybase cimentó su posición líder 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 años noventa, Sybase expandió su línea de productos para incluir herramientas de desarrollo mediante una combinación con PowerSoft, uno de los fabricantes líder de herramientas SGBD. Otras uniones y adquisiciones trajeron servicios de consultoría y otras tecnologías de gestión de datos. La línea 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 técnicas de optimización de consultas complejas que reivindican mejorar el rendimiento en cien veces los SGBDR convencionales. • SQL Anywhere está centrado en computadoras portátiles. Sus características son una pequeña 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 características 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 mensajería y servicios de consultoría, estas líneas de producto hacen de Sybase un proveedor de bases de datos de muchos cientos de millones de dólares.
Apéndice B: Perfiles de los fabricantes de bases de datos
965
TimesTen Performance Software (www.timesten.com) TimesTen es una compañía de bases de datos con capital de riesgo centrada en repartir rendimiento ultra-alto en sistemas de bases de datos residentes en memoria. La compañía se formó como un subproyecto de un proyecto de base de datos residente en memoria principal en Hewlett-Packard, y su tecnología subyacente se ha lanzado como un componente incorporado en los sistemas de telecomunicaciones HP desde 1996. La versión TimesTen de la tecnología inició su distribución en 1998. Tiene cnmo características unas API ODBC y JDBC, y SQL estándar 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 portátiles y aplicaciones de comunicaciones de datos. También 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 distribución de datos del mercado. Para aplicaciones OLTP típicas, el motor TimesTen aumenta al menos en diez veces (1.000 por ciento) el rendimiento de un SGBDR convencional con caché. TimesTen 4, la versión actual, admite direccionamiento de base de datos de 64 bits, y permite bases de datos residentes en memoria de diez gigabytes. Además de sus características SGBDR, TimesTen ofrece capacidades de réplica de datos de N vías para configuraciones de alta disponibilidad y compartimiento de carga, y una capacidad de edición de eventos. Los productos de bases de datos residente en memoria principal de la compañía se han medido con factores de transacción 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 versión actual de su producto de base de datos ofrece interfaces Java, C++ y SmallTalk. El motor de base de datos orientada a objetos es multisesión y multihebra, y se ejecuta en plataformas Windows NT y UNIX. Una de las características que lo distinguen es su capacidad de tolerancia a fallos con conmutación automática por error. Como todos los fabricantes de bases de datos orientadas a objetos puras, Yersant inicialmente se presentó como un sistema SGBD de siguiente generación, rechazando a los fabricantes relacionales y sus sistemas como una tecnología anticuada. Más recientemente, la compañía 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 están disponibles para servidores Versant sobre plataformas Solaris, AIX, HP-UX y Windows. Una versión
966
SOL. Manual de referencia
caché del producto Versant, denominada Versant enJin, proporciona una caché de datos orientada a objetos para su uso en conjunción con servidores de aplicaciones basadas en J2EE. La filosofía de la familia Versant SQL es presentar tantas capacidades SGB. DOO en un modelo relacional como sea posible. Automáticamente 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 intersección para representar las relaciones. La información del esquema SQL está disponible mediante las vistas virtuales del catálogo SYSTABLES, SYSCOLUMNS y SY8INDEXES. Los punteros incorporados en el esquema del objeto se explotan de forma transparente para mejorar el rendimiento de las consultas. Además de la interfaz mediante programación (ODBC) e interactiva SQL, la familia SQL incluye herramientas de carga de datos y extracción para trasladar información entre el SGBDOO Versant y los sistemas SOBDR convencionales.
APÉNDICE
e
Referencia de la sintaxis deSQL
El estándar de SQL ANSI/ISO especifica la sintaxis del lenguaje SQL usando una notación BNF formal. Desafortunadamente, el estándar es difícil de leer y comprender, por varios motivos. En primer lugar, el estándar especifica el lenguaje de forma ascendente, en lugar de descendente, haciendo difícil obtener la «imagen general» de una instrucción SQL. En segundo lugar, el estándar usa términos no familiares (tales como expresi6n-de·tabla y predicado). Finalmente, la notación BNF en el estándar es muy profunda: proporciona una especificación muy precisa, pero oculta la estructura relativamente simple del lenguaje SQL. Este apéndice presenta una especificación completa y simplificada en BNF para SQL «estándar», como está implementado usualmente en los productos de la mayoría de fabricantes de SOBD. En concreto: • El lenguaje descrito se ajusta generalmente al requerido para el acuerdo en el"nivel de entrada del estándar SQL2," además de las características de acuerdo en los niveles intermedios y completo que se encuentran habitualmenle en los productos SGBD principales. • Se omite el lenguaje de módulos 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 documentación de los fabrican les de SOBD, en lugar de los nombres técnicos usados en el estándar. La notación BNF de este apéndice usa los siguientes convenios: • Las palabras clave SQL aparecen en caracteres
MAYÚSCULAS y CON FUENTE
NO PROPORCIONAL.
• Los elementos sintácticos se especifican en cursiva. • La notación lista-de-elementos indica un elemento o una lista de elememos separados por comas.
967
968
SOL. Manual de referencia
Apéndice C: Referencia de la sintaxis de SOL
• Las barras verticales (1) indican una elección entre dos o más elementos sintácticos alternativos. • Los corchetes ([ ]) indican un elemento sintáctico opcional encerrado entre ellos. • Las llaves ({ }) indican una elección entre elementos sintácticos requeridos encerrados entre ellas.
unicidad
restricción-c{ave-extemo ref-clave-externa
CREATE TABLE tabla ( lista-elemelllos-def-rabla) DROP TABLE rabia 1 opciones-de-eliminacióll) TABLE
CREATE VIEW vista ( ( lista-collmmas) AS especificación-de-consulta [ WITH CHECK OPTION l DROP VIEW vista [ opciones.de·eliminación
DROP ALTER
privilegio
i
tipo-de-objelo-bd nombre.de·objeto-bd [
CREATE
Sintaxis dejinición-de-cofumna I restricción-de-lObla columna tipo-de-dotos ( DEFAULT ( literal I USER I NULL ) l ( lislo-de·restricciones-de-columno l CONSTRAINT nombre-de·re.uricciÓn 1 { NOT NULL 1 unicidad I ref-clave-eXlerna I rest'"..:iun-de_ comprobación } [ temporización.de-restricción l CONSTRAINT nombre-de-restricción l { unicidad J restricción-c/ave-extema J restriccián-de-comproba. ción } [ temporiz.ación-de-restricciÓn J UNIQUE ( lista-de-columnas) I PRlMARY KEY ( fista-decolumnas) FOREIGN KEY ( lista-de-columnas) ref·clave-externa REFERENCES tabla 1 ( /ista-de-cofunmas) J [ MATCH FULL 1 PARTIAL l [ ON DELETE acción-ref J
restricción-de-tabla
Estas instrucciones definen la estructura de una base de datos, incluyendo sus tablas, vistas y los «objetos» específicos del SGBD que contiene:
ALTER
Elemento del lenguaje demento-de/-tabla dejinición-de-columna
restriccióll-de-columna
Instrucciones de definición de datos
'969
opciones-de.e/iminación
CASCADE 1 SET NULL 1 SET DEFAULT I NO ACTION CHECK ( condicián-de-bú.rqlleda) ( INITIALLY IMMEDIATE INITIALLY DEFERRED l ( [ NOT l DEFERRABLE I SELECT I DELETE 1 UPDATE [ ( listo·de-colllmnas) INSERT [ ( lista-de-columnas) CASCADE 1 RESTRICT
I
especijicación-de-objeto-bd J
tipo-de-objelo-bd [ opciones-de-eliminación l
Instrucciones básicas de manipulación de datos
tipo-de-objeto-bd acció/l-de-modificación
GRANT ( ON { TO { WITH
La instrucción «SELECT unitaria» devuelve una única fila de datos en un conjunto de variables del anfitrión (SQL incorporado) o variables de un procedimiento almacenado:
I lista-de-privilegios) tipo.de-ohjeto-bd nomhre-de-objeto-bd } PUBLIC I lista-de-IlSllarios} GRANT OPTION l ALL PRIVILEGES
tabla
I
1
SELECT [ ALL DISTINCT l { lista-de-elementos-de·selecciÓn INTO lista-de-variables FROM lista-de-referencios-o-tablas WHERE condición-de-búsqlleda l
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 .. }
La instrucción «SELECT interactiva» devuelve cualquier número de.filas de datos en una sesión SQL interactiva (la devolución de varias filas en SQL incorporado O en procedimientos almacenados requiere instrucciones basadas en cursores):
Las palabras clave usadas para especificar objetos de la base de datos (tipo·de· objeto-bd) dependen del SOBD específico. 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 característica del SOBD que los alberga. El conjunto específico de acci6n-de-modificaciones que se permiten es también específico del SGBD y del tipo de objeto. Los elementos del lenguaje usados en las instrucciones CREATE, DROP, ALTER, GRANT Y REVOKE son:
SELECT [ ALL 1 DISTINCT l { lista·de-elementos-de-selección INTO lisla-de·variables-def.onfitrión FROH /ista-de-referellcias-a.rablas WHERE condición-de-búsqueda ) GROUP BY lista-de·referencias-a-co[lImnas HAVING condición·de-blÍsqueda l ORDER BY lista-de-elementos-de-ordenación
J
l
I .. )
970
SOL. Manual de referencia
Apéndice C: Referencia de la sintaxis de SQL
Estas instrucciones modifican los datos de la base de datos: INSERT INTO tabla {
GRQUP BY /isla·de-rejerencias-a-columna l HAVING condición-de.búsqueda l
[ WHERE cOlldic,ión-de-búsquedo
Las referencias a tabla (lista-de·rejerencias-a-tablas) de la cláusula den ser:
FROM
pue-
• 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 (véase 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 cláusula FROM. • Una referencia a tabla reunida (véase el texto que sigue) que combine datos de dos o más tablas usando operadores relacionales OUTER JOIN, INNER JOIN o cualquier operador de reunión. No todas las marcas de SOBD permiten que aparezcan especificaciones de reunión en la cláusula FROM.
Estas instrucciones emiten la señal del fin de una transacción SQL: [ WORK 1 [ WORK
ROLLBACK
I
lisla-de-re/erencias-o-tablas WHERE condición-de-búsqueda l
Instrucciones de procesamiento de transacciones
COMMIT
[ ALL
FROM
( WHERE condición-de-búsqlleda ]
tabla SET lis/a-de-asignación
UPDATE
La especificación de una consulta básica tiene la forma:
) J
971
Instrucciones de cursores Estas instrucciones de SQL para programación permiten la recuperación de datos y la actualización posicionada: DECLARE cursor [ SCROLL } CURSOR FOR upresióll~de~consulta [ aRDER BY ljsta~de~efementos-de·ordellación 1 [ FOR { READ ONLY I UPDATE [ OF lis/a-columnas] } 1
Las tablas reunidas se especifican de acuerdo con el estándar SQL2, como sigue; en la práctica, hay una gran variaci6n en los tipos específicos de reuniones albergadas en marcas de SGBD, en concreto, y en la sintaxis usada para especificar varios tipos de reunión:
OPEN cursor
Tipo de nuni6n
Sintaxis
tabla~reunida
relmi6n-inlema I reunión-uterna 1 reunión~de~unión I reunión~cruzada I ( tabla-reunida) referencia-o-tabla [ NATURAL ] [ INNER } JOIN referencia~a tabla I [ INNER l JOIN referencia-a.tabla { especijicación.de-reunión 1 referencio.~a~tabla ( NATURAL l (LEFT I RIGHT I FULLj
CLOSE Cllrsor
reunión-in/ema FETCH
[
[ dir-búsqueda l
FROM l
cursor INTO
lista~de~variables referellcia-a~tabla
DELETE FROM tabla WHERE CURRENT OF cursor
reunión-utema
UPDATE tabla SET
referencia~a-/abla
OUTER JOIN referencia~a~/abfa I [LEFTI RIGHTI FULL) OUTER JOIN
reunión-de-unión
referencia-o~tabla
lis/a-de~asignaciónWHERE
CURRENT OF cursor
referencia-a-tabla [
La dirección de búsqueda (dir-búsqueda. opcional) se especifica como sigue, y número-de-fila se puede especificar como una variable o un literal. NEXT
reunjón~cruzada
especificación-de~reunIón
1 PRIOR I FIRST I LAST 1 ABSOLUTE número-de-fila I RELATIVE número-de-fila
especijicación-de-reunión l
UNION JOIN referencia-a-tabla CROSS JOIN ON condjción-de-búsqueda I USING ( lista-de-columnas l
referencia.a~tabla
referencia-a-tabla
El estándar SQLZ permite combinar las especificaciones de consultas básicas entre sí usando las operaciones relacionales orientadas a conjuntos uNloN, EXCEPT e INTER5ECT. La expresión-de-consulta resultante proporciona la capacidad completa del procesamiento relacional de conjuntos del estándar. Encerrada entre paréntesis, una expresi6n-de-consulta se convierte en una subconsulta que puede aparecer en varias posiciones de una instrucción SQL (por ejemplo, dentro de ciertas condiciones de búsqueda en la cláusula WHERE).
Expresiones de consultas El estándar SQL2 proporciona un rico conjunto de expresiones para la especificación de consultas, desde consultas simples a las expresiones de consulta más complejas que usan operaciones de las bases de datos relacionales para combinar los resultados de consultas más simples.
J
972
SOL. Manual de referencia
Apéndice C: Referencia de la sintaxis de SOL
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:
973
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
junción·dislimo función-Iodas
Sintaxis
Expresión expresión-de-consulta
rabIa-simple I tabla-reunida I cxpresión-de-unión I expresiónexcepto I expresión-de-inrersección I ( expresión-de-consulta ) apresión-de-eonsullO UNION ( ALL l [ espuificación-de correspondencia l expresión-de-consulra expresión-de-consulla EXCEPT [ ALL l [ especificaciónde-corre.rpondcncia ) expresión-de-co/lsulto expresión-de-consulla INTER5ECT [ ALL l [especifica-
expresión-de-utlión expresión-excepto
Expresión-de.jnlerucció/l
ción-de-corr~spond~nciaJ
especijicación-de-correspondencia
eORRESPONDING
subconsulta (
[ BY
Elementos de las instrucciones o
expr~sión-d~-consulta
( listo-d~-columnas)
expresión-de-consulta)
Estos elementos aparecen en varias instrucciones SQL: Elemento del lenguaje asignación-set ~l~m~nl0-d~-ord~nación d~men1o-d~-inserción
elemento-de-selección r~ferencia-a-tabla
Condiciones de búsqueda
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
Estas expresiones seleccionan filas de la base de datos para procesarlas:
Elementos simples
Elemento del lenguaje
Los siguientes son los nombres básicos y l.a,.s constantes que aparecen en instrucciones SQL:
Sintaxis demento-de-búsqueda I elem~nto-d~·búsqueda ( AND I OR elemellto-de-búsqueda [ NOT ) { test·d~-blísqueda I ( cOlldición-de-búsqueda) test-de-comparación J t~sl-b~1Ween I t~st·Jike 1" t~st·d~-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 { lista·de-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 selección SQL y en las condiciones de búsqueda: Elemento del lenguaje
ex" elemento-de-upresión valor variable·del-anfitriólJ función
Sintaxis elememo-de-expresión 1 elemento-de-expresión { + I - I * I I } elemento-de-e.xpresi6n [ + I - } [ valor I "f-a-columna I fUllción I { expr J } lileral I USER I variabl~-del-allfitrión I variable-de-procedimiemDalmacenado variable [ [ INDICATDR ) variable J COUNT ( * ) I funci61l-dislintO 1 función-Iodas
Elemento del lenguaje tabla columna usuario variable literal entero tipo-de-datos alias cursor
Descripción Nombre de labia Nombre de columna Nombre de usuario de la base de datos Nombre de variable del anfitrión o de un procedimiento almacenado Número o literal de cadena encerrado entre comillas Número enlero Tipo de dalos SQL Identificador SQL Identificador SQL
APÉNDICE
D
La interfaz del nivel de llamadas de SOL En aras de la claridad, las rutinas se presentan con dos diferencias con respecto al estándar. Los nombres de los parámetros de las rutinas se abrevian en este apéndice para hacer que las rutinas sean más fáciles de leer Y. en algunos casos, para clarificar su función. En las llamadas reales a las rutinas desde un programa de aplicación, se usan los nombres de las variables del programa de aplicación como entrada y parámetros de salida en lugar de nombres de parámetros. También por evitar confusión, los tipos de datos de los parámetros se escriben aquí en términos de los tipos de datos reales del lenguaje Consulta (por ejemplo, long, short, *char). El estándar define los parámetros usando constantes simbólicas definidas (#define en el lenguaje C) para respresentar estos tipos de datos. El apéndice A.I del estándar (ISO/IEC 9075-3:1995) es un archivo de cabecera Consulta que define constantes simbólicas para todas las constantes y códigos especificados en el estándar, y usa los nombres de variables de parámetros completos especificados en el estándar. A continuación, un resumen de las rutinas organizadas por su función: AllocHandle () FreeHandle () AllocConnect () FreeConnect{) Connect () Disconnect() DataSources() AllocEnv () FreeEnv( ) SetEnvAttr ()
Asigna recursos para el entorno. conexión, descriptor o instrucción. Libera recursos asignados previamente. Asigna recursos para una conexión a una base de datos. Libera recursos de una conexión a una base de datos. Establece una conexión a una base de datos. Finaliza una conexión establecida a una base de datos. Obtiene una lista de servidores SQL disponibles a los que se puede realizar una conexión. Asigna recursos para un entorno SQL. Libera recursos de un entorno SQL. Establece el valor de atributo de un entorno SQL.
Obtiene el valor de atributo de un entorno SQL. Asigna recursos para una instrucción SQL. Libera recursos para una instrucción SQL. Establece un área de descriptor a usar por una instrucción SQL. Obtiene un área de descriptor de una instrucción SQL. Ejecuta directamente una instrucción SQL. Prepara una instrucción SQL para una ejecución posterior.
Ejecuta una instrucción SQL previamente preparada. Finaliza una transacción SQL. Cancela la ejecución de una instrucción 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 número 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 ubicación del programa a un valor de parámetro. Procesa los valores de los parámetros diferidos. Proporciona un valor de parámetro diferido o una porción 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 información de error. Obtiene el valor de un campo de registro de diagnóstico. Obtiene el valor de un registro de diagnóstico. Obtiene el número de filas afectadas por la última instrucción SQL.
Apéndice D: La interfaz del nivel de llamadas de SOL
GetFunctions () GetInfo () GetTypeInfo()
977
Obtiene información sobre las funciones incorporadas de una implementación SQL. Obtiene información sobre las características incorporadas de una implementación SQL. Obtiene información 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
99 -1
-2
Significado
Instrucción completada con éxito. Terminación con éxito y aviso: no se encontraron datos (cuando se recuperan resultados de una consulta). Se necesitan datos (el parámetro dinámico requirido está ausente). Error durante la ejecución de la instrucción SQL. Error --controlador no válido en la llamada.
Rutinas generales de gestión 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 más. La rutina de asignación 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 específicos de controladores, descritos en sus secciones respectivas. Estas rutinas se deben usar para asignar y liberar los controladores descriptores del programa de aplicación. /* Asigna un controlador para usarlo en llamadas eL! posteriores -/ short SQLAllocHandle ( short hdlType, /* IN: código entero del tipo de cont.rolador -, long inHdl, ,- IN: cont.rolador env o conn long -rtnHdl) OUT: cont.rolador devuelt.o
'*
*'*'
/* Libera un controlador asignado previamente con SQLAllocHandle() */
short SQLFreeHandle ( short hdlType, long
inHdl)
,- IN: código entero del tipo de cont.rolador */ /* IN: controlador a liberar */
978
SOL. Manual de referencia
Apéndice D: La interfaz del nivel de /Jamadas de SOL
Rutinas para la gestión del entorno SOL
char
*svrName,
Estas rutinas se usan para asignar un controlador de un nuevo entorno SQL, para liberar un controlador de entorno cuando no se necesita más y para recuperar y establecer el valor de los atributos asociados con el entorno SQL.
short
svrnamlen,
char
*userName,
/* Asigna un controlador para un nuevo entorno SQL */
short char short
usrnamlen, "passwd, pswlen)
short SQLAllocEnv ( long
*envHdl)
/* OUT:
controlador env devuelto */
,'O Libera un controlador de entorno previamente asignado "/ short SQLFreeEnv ( long envHdl)
/* IN:
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)
/* IN: /* IN:
controlador de entorno "/ código de atributo entero"/ /" OUT: valor devuelto "/ /" IN: longitud del búfer rtnVal "/ /* OUT: longitud de los datos actuales */
/* Establece el valor de un atributo de entorno SQL */ short SQLSetEnvAttr( long envHdl, /* IN: controlador de entorno */ long AttrCode, /* IN: código de atributo entero*/ void *attrVal, /* IN: nuevo valor de atributo "/ long *strLen) /* IN: longitud de los datos */
Rutinas para la gestión de las conexiones SOL Estas rutinas se usan para crear, terminar y gestionar una conexión con un servidor SQL. Asignan y liberan los controladores usados para mantener el estado de la conexión, establecer y terminar conexiones, gestionar los atributos asociados con una conexión y para obtener una lista de servidores SQL disponibles para la conexión. /" Asigna un controlador para una nueva conexión SQL */ short SQLAllocConnect ( long envHdl, /" IN: controlador de entorno */ long "'connRdl) /" OUT: controlador de conexión devuelto */
¡, IN: nombre del servidor SQL objetivo ,¡ ¡' IN; longitud del nombre del se:r:vidor SQL '¡ ¡' IN; nombre de usuario para la conexión '¡
" " servidor
/* Se desconecta del short SQLDisconnect ( long connHdl)
979
IN; longitud del nombre de usuario '
¡, IN: contrasei'l.a de conexión '¡
/*
IN:
longitud de
,.
,
contraseña "
SQL "/ IN: controlador de conexión "/
/* Obtiene los nombres de los servidores SQL accesibles para la conexión */ short SQLDataSources ( long envHdl, /* IN: controlador de entorno "/ short direction, /* IN: indica la primera o siguiente solicitud */ char *svrname , /* OUT: búfer para el nombre del servidor "/ buflen, short /* IN: longitud del búfer del nombre del servidor ,,/ short "'namlen, /* OUT: longitud actual del nombre del servidor "'/ *descrip, char /" OUT: búfer para la descripción "/ buf2len, short /* IN: longitud del búfer para la descripción "/ short *dsclen) /" OUT: longitud real del búfer para la descripción "/ /* Obtiene el valor de un atributo de la conexión SQL "/ short SQLGetConnectAttr( long connRdl, /* IN: controlador de conexión */ long AttrCode, /* IN: código de atributo entero*/ void *rtnVal. /" OUT: valor devuelto */ long bufLen, /* IN: longitud del búfer rtnVal */ long "strLen) /* OUT: longitud de los datos actuales */ /* Establece el valor de un atributo de conexión SQL */ short SQLSetConnectAttr( long connRdl. /* IN: controlador de conexión */ long AttrCode. /" IN: código de atributo entero"/ void *attrVal, /* IN: nuevo valor de atributo */ long *strLen) /* IN: longitud de los datos */
/* Libera un controlador de conexión previamente asignado */ short SQLFreeConnect ( long connAdl) /* IN: controlador de conexión "/
Rutinas para la gestión de las instrucciones SOL
/* Inicia una conexión con un servidor SQL */ short SQLConn~ct( long connRdl, /* IN: controlador de conexión */
Estas rutinas se usan para asignar y liberar el controlador asociado con una instrucción SQL, para pasar el texto de la instrucción SQL a ejecutar y para solicitar la preparación y la ejecución real de la instrucción mediante eL!.
980
Apéndice o: La interfaz del nivel de llamadas de SOL
SOL. Manual de referencia
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 instrucción *' /*
'*'*
*'
/* Libera un controlador de la instrucción asignado previamente*' short SQLFreeStrnt ( long stmtHdl. ,- IN: controlador de la instrucción long aption) ,- IN: opciones de cursor y desvinculación -,
*'
Vincula un parámetro de la instrucción SQL a un área de datos del programa */ short SQLBindParam ( long stmtHdl. IN: controlador de la instrucción short parmnr, IN: número del parámetro (1.2.3 ... ) *' short val type, '* IN: tipo de datos del valor proporcionado -, parmtype, short IN: tipo de datos del parámetro colsize. '* IN: tamano de la columna *' short decdigits, short '* IN: número de digitos decimales void '* IN: puntero al búfer de valores *value. parm ~, long "1enind) IN: puntero al búfer longitud' indicador -, /*
'*'*
*'
*' *'
'*
'*
/* Obtiene el valor de un atributo de una instrucción SQL *' short SQLGetStrntAttr (
long long void long long
strntHdl, AttrCode. *rtnVal. bufLen, *strLen)
'*
'* IN: IN: '* OUT: '* IN: ,- OUT:
*'
controlador de la instrucción código de atributo entero*' valor devuelto longitud del búfer rtnVal *' longitud de los datos actuales *'
*'
/* Establece el valor de un atributo de una instrucción SQL *' short SQLSetStrntAttr( long stmtHdl, IN: controlador de la instrucción long At trCode. '* IN: c6digo de atributo entero*' void *attrVal. '* IN: nuevo valor de atributo long 11 strLenl IN: longitud de los datos *'
'* '*
*'
*'
·stmttext. text1en)
*'
,- IN: texto de la instrucci6n SQL ,- IN: longitud del texto de la instrucción *'
,- Prepara la instrucción SQL. pasándola en forma de texto SQL short SQLPrepare ( long strntHdl. '* IN: controlador de la instrucción char -stmttext, IN: texto de la instrucción SQL short text1en) '* IN: longitud del texto de la instrucción
'*
*' *'
*'
*'
'* Execute a previous1y prepared SQL staternent *' short SQLExecute ( long stmtHdl) '* IN: controlador de la instrucción -,
*'
'* COMMIT o ROLLBACK una transacción 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 instrucción SQL en ejecución short SQLCancel ( short stmtHdlJ IN: controlador de la instrucción *'
'*
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 aplicación 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 instrucción
*'
'* Desplaza el cursor arriba o abajo por los resultados de la consulta short SQLFetchScroll ( '* IN: controlador de la instrucción -, long stmtHdl, ,- IN: dirección (primero'siguiente' short fetchdir, anterior) *' long offsetl IN: desplazamiento (número de filas) -,
*'
Rutinas para la ejecución de instrucciones SQL Estas rutinas se usan para pasar el texto de la instrucción SQL a la interfaz eLI y para solicitar la ejecución de la instrucción SQL, bien inmediatamente o bien después de haber sido preparada. También controlan la ejecución de transacciones SQL y la cancelación de instrucciones que se estén ejecutando.
*'
'* Pasa el texto de la instrucción SQL y solicita su ejecución short SQLExecDirect ( long . stmtHdl, IN: controlador de la instrucción *'
'*
char short
981
'*
,- Obtiene los datos de una única columna de los resultados de la consulta *' short SQLGetData '* IN: controlador de la instrucción *' long s trntRdl, ,- IN: número de columna a recuperar *' short co1nr, '* IN: tipo de datos a devolver al short tgttype, programa *'
982
SOL. Manual de referencia "'value,
void
buflen, *lenind)
long long
/* IN: puntero al búfer de los datos de columna "/ /" IN: longitud del búfer del programa "/ /" OUT: longitud real y/o ind NULL ,,/
/* Cierra un cursor para finalizar el acceso a
'*'
consulta shart SQLCloseCursor long
los resultados de la
(
stmtHdl)
/* Recupera el nombre de un cursor abierto "/
/" /* /" /*
void
value,
long
huElen, lenind)
long
strntHdl, color,
char
*colname,
shart
buflen,
short
*namlen,
short
*coltype,
short
"colsize,
short
*decdigits,
short
"nullable)
'"'" '" '" '"'"
"' "'
"'
'"
IN: controlador de la instrucción IN: número de la columna a describir OUT: nombre de la columna de lo. resultados de la consulta IN: longitud del búfer del nombre de la columna " OUT: longitud real del nombre de la columna OUT: código del tipo de datos de la columna devuelta OUT: longitud de los datos de la columna devuelta OUT: número de dí.gitos devueltos de una columna OUT: si la columna puede tener valores NULL "
"'
"'
"'
,
"'
"'
,
"' "'
'"'"
"'"'
IN: controlador de la instrucción IN: número 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 búfer del programa IN; puntero al búfer de longitud/ indicador
'"'" '" '" '" '" '" '"
/* Obtiene información detallada sobre una columna de resultados de la consul ta * / short SQLColAttribute ( long stmtHdl. IN: controlador de la instrucción */ short colnr, IN: número de la columna a describir "/ attrcode, /* IN: código del atributo a recuperar */ short *attrinfo, /* OUT: búfer de la información de char atributo */ buflen, /" IN: longitud del búfer del atributo de short la columna ,,/ *actlen) /* OUT: longitud de la información del short atributo actual */
IN: controlador de la instrucción "/ OUT: búfer del nombre devuelto ,,/ IN: longitud del búfer */ 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:,
long shart
/" IN: controlador de la instrucción */
/* Establece un nombre de cursor para un cursor abierto */ shart SQLSetCursorName ( /* IN: controlador de la instrucción */ long strntHdl, /* IN: nombre del cursor */ char cursname, /* IN: longitud del nombre del cursor */ shart namelen)
shart SQLGetCursorName ( long s trntHdl , char cursnarne, shart huflen, shart *namlenJ
983
Apéndice O: La interfaz del nivel de llamadas de SOL
"'
Rutinas para la descripción de los resultados de las consultas Estas rutinas se usan para obtener una descripción de los resulados de una consulta, incluyendo el número de columnas de resultados de la consulta, el tipo de datos y otros atributos de cada columna. /* Determina el número de columnas resultado de una consulta "/ short SQLNumResultCols ( long stmtHdl, /" IN: controlador de la instrucción */ short *colcount) /* OUT: número de columnas devuelto */ /* Determina las características de una columna de resultados de la consulta "/ short SQLDescribeCol
Rutinas para la gestión de descriptores de los resultados de las consultas Estas rutinas se usan para obtener una descripción 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 aplicación. ' /* Recupera información usada frecuentemente de un descriptor eLI */ short SQLGetDescRec ( long descHdl, IN: controlador del descriptor short recnr, IN: número de registro del descriptor char "name, OUT: nombre del elemento que se describe buflen, IN: longitud del búfer del nombre short *namlen, OUT: longitud real del nombre short devuelto OUT, código del tipo de datos del short "datatype, elemento"/
'"'" '" '"'" '"
"'
"'
"'
"'
"'
984
SOL. Manual de referencia short
·subtype.
short short
*length, ·precis.
short
*scale.
short
*nullable)
Apéndice D: La interfaz del nivel de l/amadas de SOL
/ ' OUT; subcódigo del tipo de datos del elemento 'O, / ' OUT: longitud del elemento ~/ / ' OUT: precisión del elemento, si es numérico ~/ / ' OUT: escala del elemento, si es numérico ~/ / ' OUT: si el elemento puede tener valores NULL ~/
/* Obtiene información detallada de un elemento descrito por un descriptor eL! */ short SQLColAttribute ( long descHdl. /~ IN: controlador del descriptor */ /~ IN: número de registro del short recnr. descriptor */ /* IN: c6digo del atributo a describir short attrcade. void '"'attrinfo. /* OUT: búfer de la información del atributo */ huflen, short /* IN: longitud del búfer del atributo col */ short *actlen) /* OUT: longitud de la información del atributo real */
985
/~ 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~/
Rutinas para el procesamiento diferido de parámetros dinámicos
~/
Establece información usada frecuentemente en un descriptor eLI */ short SQLSetDescRec ( long descHdl, /* IN: controlador del descriptor */ short recnr. /* IN: número de registro del descriptor */ short datatype, /* IN: código del tipo de datos del elemento*/ short subtype, /* IN: subcódigo del tipo de datos del elemento */ short length. /- IN: longitud del elemento */ short preciso /* IN; precisión del elemento, si es numérico */ short scale, /* IN: escala del elemento, si es numérico */ void *databuf /* IN; dirección del búfer de datos del elemento */ buflen, short /* IN: longitud del búfer de datos */ short *indbuf) /* IN: direcci6n del búfer del indicador para el elemento */ /*
I
1* Establece información detallada sobre un elemento descrito por un descriptor eL! */ short SQLColAttribute ( long descHdl. / ' IN: controlador del descriptor ' / short recnr, /' IN: número de registro del descriptor ' / short attrcade. / ' IN: código del atributo a describir ,/ void ·actrínfo. /' IN: búfer con información del atributo ' / short huflen) / ' IN: longitud de la información del atributo ' /
Estas rutinas se usan para procesar los parámetros diferidos cuando sus valores se solicitan por la interfaz eL! durante la ejecución de una instrucción SQL que Jos contiene. /* Obtiene la etiqueta del parámetro para el siguiente parámetro dinámico requerido */ short SQLParamData ( long stmtHdl, /~ IN: controlador stmt con parámetros dinámicos */ void *prmtag) /* OUT: búfer para el valor devuelto de la etiqueta del parámetro */ /* Obtiene información detallada para un elemento descrito por un descriptor eLI */ short SQLPutData ( long strntHdl, /* IN: controlador stmt con parámetros dinámicos */ void *prmdata, /* IN: búfer con datos para el parámetro * / prmlenind) short /* IN: longitud del parámetro o ind NULL */
Rutinas para errores, estado y diagnóstico Estas rutinas se usan para determinar el motivo de una condición de error devuelta por eLI, para determinar el número de filas afectadas en la ejecución correcta de la instrucción y para obtener información detallada de diagnóstico sobre las condiciones de error. / ' Devuelve l . anterior . / short SQLError long long long char
información de error asociada con una llamada CLI (
envHdl, connHdl, stmtHdl, *sqlstate,
/' /' /' /'
IN: controlador de entorno ' / IN: controlador de conexión ' / instrucción ' / IN: controlador de OUT: valor SQLSTATE de cinco caracteres ' /
,.
986
SOL. Manual de referencia long char short short
*nativeerr, 1° OUT: código de error nativo devuelto */ *msgbuf, 1° OUT: búfer para el texto del mensaje de error * / buElen, 1° IN: longitud del búfer del texto del mensaje de error */ *msglenl l ' OUT: longitud real del mensaje devuelta */
./* Determina el número de filas afectadas en la instrucción SQL previa */ short SQLRowCount ( /* IN: controlador de la instrucción */ long stmtHdl, /* OUT: número de filas */ long *rowcnt) /* Devuelve la información de uno de los registros de diagnóstico de
error de CLI */ short SQLGetDiagRec ( short hdl type, long inHdl, short recnr, char
*sqlstate,
long
*nativeerr,
char
*msgbuf,
short
buElen,
short
*msglen)
IN: código del tipo de controlador */ /* IN: controlador CLI */ /* IN: número de registro de error requerido */ /* OUT: código SQLSTATE de cinco caracteres */ /* OUT: código de error nativo devuelto */ /* OUT: búfer para el texto del mensaje de error */ /* IN: longitud del búfer del texto del mensaje de error */ /* OUT: longitud real del mensaje devuelta */ /*
/* Devuelve un campo de uno de los registros de error de diagnóstico CLI * / short SQLGetDiagField ( short hdl type. /* IN: código del tipo de controlador */ long inHdl, /* IN: controlador eLI */ short recnr, /* IN: número de registro de error requerido */ diagid, short /* IN: identificador del campo de diagnóstico */ *diaginfo, void /* OUT: información de diagnóstico devuelta */ short buflen, /* IN: longitud del búfer de información de diagnóstico */ short *actlen) /* OUT: longitud de la información real devuelta */
Rutinas de información de la implementación CL! Estas rutinas deyuelven información sobre la información eL! específica, incluyendo las llamadas eLl, las instrucciones y los tipos de datos que admite.
Apéndice O: La interfaz del nivel de llamadas de SaL /* Devuelve información sobre CLI */ short SQLGetInfo ( long connHdl, /* short infotype, /* void "infoval, /* short
buElen,
short
*infolen)
987
las capacidades de una implementación
IN: controlador de conexión */ IN: tipo de información requerida */ OUT: búfer de la información devuelta */ /* IN: longitud del búfer de información */ /* OUT: longitud real de la información devuelta */
/* Determina el número de filas afectadas por una instrucción SQL
previa */ short SQLGetFunctions ( long connHdl, /* IN: controlador de conexión */ short functid, /* IN: código identificador de la función */ *supported) /* OUT: si se admite la función */ short /* Determina información sobre los tipos de datos soportados */ short SQLGetTypeInfo ( long stmtHdl, /* IN: controlador de la instrucción */ short datatype) /* IN: ALL TYPES o tipo solicitado */
Códigos de los valores de los parámetros CL! Estos códigos se pasan o se obtienen de eL! como valores de parámetros para indicar los tipos de contoladores, los tipos de datos, los tipos de instrucción, etc.
Código Códigos de los tipos de controladores
Valor
SQL-environment handle
1
SQL-connection handle
2
SQL-statement handle
3
4 Códigos de los tipos de datos de la implementación SQL CHARACTER 1 SQL-descriptor handle
NUMERIC
2
DECIMAL
3
INTEGER
4
SMALLINT
5
FLOAT
6
REAL
7
DOUBLE
8
988
Apéndice D: La interfaz del nivel de /Jamadas de SaL
SOL. Manual de referencia
Código
Valor
Código
Valor
DATETIME
9
MINUTE TO SECQND
13
INTERVAL
10
Códigos de terminación de transacciones
VARCHAR
12
COMMIT
O
BIT
14
ROLLBACK
1
Implementation-defined
Códigos de opciones de procesamiento CLOSE CURSOR
FreeStmt ()
O
1 2 UNBIND PARAMS 3 Códigos de la orientación de la búsqueda FREE HANDLE
UNBIND COLUMNS
INTEGER
2 3 4
SMALLINT
5
NEXT
1
FLOAT
6 7 8
FIRST
PRIOR
2 3 4
ABSOLUTE
5
RELATIVE
6
NUMERIC DECIMAL
REAL DOUBLE
Implementation-defined Subcódigos Da teTime para los tipos de datos SQL
LAST
CHARACTER
1
TIMESTAMP
1 2 3
INTEGER
4
TIME w/ ZONE
4
SMALLINT
5
5
REAL
7
DOUBLE
8
DATE TIME
TIMESTAMP wl ZONE
Códigos de intervalo Tipos Da teTime YEAR MONTH
DAY
Da teTime
de SQL
Códigos de tipos de datos Ge tDa ta ( )
Códigos de rutinas CL! para la llamada GetFunction ()
1 2 3
AllocStmt
1 2 1001 3
BindCol
4
AllocConnect . AllocEnv AllocHandle
YEAR TO MONTH
4 5 6 7
DAY TO HOUR
8
CloseCursor
1003
DAY TO MINUTE
ColAttribute
DAY TO SECONO
9 10
HOUR TD MINUTE
I1
CopyDesc
HOUR TO SECOND
12
DataSources
6 7 1004 57
HOUR MINUTE SECOND
BindParam
1002
Cancel
5
Connect
989
APÉNDICE
El estándar del esquema de la información de SOL
Este apéndice describe las vistas del esquema de la información de SQL especifica~ das por el estándar 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 estándar; no se requieren en el nivel de ajuste de entrada. En la práctica, el soporte de las vistas del esquema de la información 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 información relevante sobre todos los objetos de la base de datos (esquemas, tablas, colum-
nas, vistas, restricciones, dominios, conjuntos de caracteres, etc.) que están accesibles. La siguiente tabla proporciona información sobre los esquemas, tablas y columnas: . SCHEMATA
Describe todos los esquemas propiedad del usuario actual
TABLES
Describe todas las tablas a las que puede acceder el usuario actual
COLUMNS
Describe todas las columnas de las tablas propiedad de o a las que puede acceder el usuario actual
Esta tabla proporciona información sobre las vistas:
VIEW_TABLE_USAGE
Describe todas las vistas las que puede acceder el usuario actual Describe todas las tablas de las que dependen las vistas
VIEW_COLUMN_USAGE
Describe las columnas de las que dependen las vistas
VIEWS
Esta tabla proporciona información sobre restricciones (unicidad, claves primarias, claves externas, restricciones de comprobación, asertos): TABLE_CONSTRAINTS
Describe todas las restricciones sobre las tablas propiedad del usuario
993
994
Apéndice E: El estándar del esquema de la información de SOL
Describe todas las restricciones de clave externa propiedad del usuario Describe todas las restricciones de comprobación 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
Tipo de datos
CATALOG~NAME
VARCHAR(lon)
SCHEMA_NAME
VARCHAR(lon)
SCHEMA_OWNER
VARCHAR(lOIl)
DEFAULT~CHARACTER_
VARCHAR(lOIl)
SET_CATALOG DEFAULT_CHARACTER_ SET_SCHEMA
VARCHAR(lon)
DEFAULT_CHARACTER_ SET_NAME
VARCHAR(lon)
995
Descripción Nombre del catálogo que contiene este esquema Nombre del esquema descrito por esta fila Nombre del creador del esquema Catálogo 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 información sobre los privilegios: Describe los privilegios sobre las tablas Describe los privilegios sobre las columnas
TABLE_PRIVILEGES COLUMN_PRIVILEGES
La vista
Describe los privilegios sobre otros objetos de la base de dalos
USAGE_PRIVILEGES
La vista TABLES contiene una fila de cada tabla definida en el catálogo actual que es acc.esible al usuario actuaL Su estructura se muestra en la tabla siguiente:
Esta tabla proporciona información sobre los dominios: DOMAINS DOMAIN_CONSTRAINTS DOMAIN_COLUMN_USAGE
TABLES
Describe los dominios accesibles al usuario Describe las restricciones que definen estos dominios Describe las columnas basadas en estos dominios
Nombre de columna TABLE_CATALOG TABLE_SCHEMA
Esta tabla proporciona información sobre los conjuntos de caracteres:
COLLATIONS
Describe conjuntos de caracteres Describe secuencias de ordenación
TRANSLATIONS
Describe traducciones entre conjuntos de caracteres
CHARACTER_SETS
y a continuación hay información sobre los lenguajes de programación admitidos: SQL_LANGUAGES
Describe los lenguajes admitidos y las API SQL
Los contenidos específicos de cada vista del esquema de la información se describen en las siguientes páginas.
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:
\ I
TABLE_NAME TABLE_TYPE
Tipo de datos
Descripción Nombre del catálogo que contiene VARCHAR(loll) esta definición de tabla Nombre del esquema que contiene VARCHAR(lOIl) esta definición de tabla Nombre de la tabla VARcHAR(lon) VARcHAR(maxloll) . TIpo de la tabla (BASE TABLE/VIEW/ GLOBAL TEMPORARY/LOCAL TEMPORARV)
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL. VARCHAR(maxIon) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementación SQL.
La vista
COLUMNS
La vista COLUMNS contiene una fila por cada columna de cada tabla definida en el catálogo actual que es accesible al usuario actual. Su estructura se muestra en la siguiente tabla:
Apéndice E: El estándar del esquema de la información de SOL
Tipo de datos
Nombre de columna
Tipo de datos
VARcHAR(lon)
COLLATION_NAME
VARCHAR(fon)
DOMAIN_CATALOG
VARCHAR(lon)
Descripción Nombre del catálogo que contiene la definición de tabla que contiene esta columna Nombre del esquema que conliene VARcHAR(lon) la definición de tabla que contiene esta columna VARcHAR(lon) Nombre de la tabla que contiene esta columna VARcHAR(lon) Nombre de la columna INTEGER > O Posición de la columna en esta tabla VARCHAR(maxion) Representación 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 (representación textual) INTEGER > O Longitud máxima, en caracteres, de las columnas de longitud variable INTEGER > O Longitud máxima, en bytes, para las columnas de longitud variable INTEGER > O Precisión de las columnas con tipo de datos numéricos INTEGER > O Base de la precisión
VARcHAR(lon) DOMAINJlAME
VARCHAR(1on)
el tipo de datos de los identificadores SQL; ion es la longitud máxima definida por la implementaci6n SQL. VARCHAR(maxfon) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementación SQL.
La vista
VIEWS
La vista VIEWS contiene una fila por cada vista definida en el catálogo actual que es accesible al usuario actual. Su estructura se muestra en la tabla siguiente:
Nombre de columna
Tipo de datos
Descripción
TABLE_CATALOG
VARCHAR(lon)
Nombre del catálogo que contiene esta definición de vista Nombre del esquema que contiene esta definición de vista Nombre de la vista Texto de la instrucción SQL que define la vista Opción de comprobación para esta vista (CASCADED/LOCAL/NONE) Si se puede actualizar la vista (VES!
VARCHAR(lon) TABLE_NAME
VARCHAR(lon)
VIEW_DEFINITION
VARCHAR(maxlon)
INTEGER > O
Escala del tipo de datos numérico
DATETIME_PRECISION
INTEGER > O
Precisión para las columnas de tipo de datos Da teTime
VARCHAR(max/on)
CHARACTER_SET_ CATALOG
VARCHAR(lon)
VARCHAR(max/on)
CHARACTER_SET_ SCHEMA
vARcHAR(lon)
Catálogo que contiene la definición del conjunto de caracteres de esta columna Esquema que contiene la definición del conjunto de caracteres de esta columna Nombre del conjunto de caracteres de esta columna, si lo hay Catálogo que contiene la definición de la ordenación para esta columna Esquema que contiene la definición de la ordenación para esta columna
COLLATION_CATALOG
vARcHAR(1on) VARcHAR(1on)
Descripción Nombre de la ordenación de esta columna, si la hay Catálogo que contiene la definición del dominio de esta columna Esquema que contiene la definición del dominio de esta columna Nombre del dominio de esta columna, si lo hay
VARcHAR(lon) es
NUMERIC_SCALE
VARcHAR(lon)
997
NO)
VARCHAR(/on) es el tipo de datos de los identificadores SQL; ion es la longitud máxima
definida por la implementación SQL. VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud máxima 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 catálogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla: .
998
saL.
Manual de referencia
Nombre de columna
Tipo de datos
VIEW_CATALOG
vARcHAR(lon)
VIEW_SCHEMA
vARcHAR(lon)
VIEW_NAME
VARCHAR(loll)
TABLE_CATALOG
VARCHAR(lon)
TABLE_SCHEMA
vARcHAR(lon)
TABLE_NAME
VARcHAR(lon)
Apéndice E: El estandar del esquema de la información de SOL
Descripción Nombre del catálogo que contiene la definición de la vista Nombre del esquema que contiene la definición de la vista Nombre de la vista Catálogo que contiene la definición de la tabla de que depende la vista Esquema que contiene la definición de la tabla de la que depende la vista Nombre de la tabla de la que depeode la vista
VARCHAR(lon) es el tipo de datos de los identificadores SQL;
JOII
La vista
TABLE_CON5TRAINT5
La vista TABLE_CONSTRAINTS contiene una fila por cada restricción de tabla definida por las tablas en el catálogo actual propiedad del usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
Tipo de datos
CONSTRAINT_CATALOG
VARcHAR(lon)
CONSTRAINT_SCHEMA
VARcHAR(lon)
CONSTRAINT_NAME
VARCHAR(lon)
TABLE_CATALOG
VARCHAR(lon)
TABLE_SCHEMA
CONSTRAINT_TYPE
Nombre del esquema que contiene la definición de la tabla VARcHAR(lon) Nombre de la tabla a la que se aplica la restricción VARCHAR(maxlon) Tipo de restricción (UNIQUE/ PRlMA-
IS_DEFERRABLE
VARCHAR(max/on)
es la longitud máxima
definida por la implementación SQL.
TABLE_NAME
La vista
VIEW_COLUMN_U5AGE
La vista VIEW_COLUM1CUSAGE contiene una fila por cada columna de la que depende una vista definida en el catálogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
Tipo de datos
VIEW_CATALOG
VARcHAR(lon)
VIEW_SCHEMA
VARcHAR(lon)
VIEW_NAME
VARCHAR(lol!)
TABLE_CATALOG
VARcHAR(lon)
TABLE_SCHEMA
VARCHAR(/on)
TABLE_NAME
VARCHAR(lon)
CüLUMN_NAME
VARCHAR(lon)
Descripción Nombre del catálogo que contiene la definición de la vista Nombre del esquema que contiene la definición de la vista Nombre de la vista Catálogo que contiene la definición de la columna de la que depende la vista Esquema que contiene la definición 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
e~ el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL.
VARCHAR(Jon)
999
Descripción Nombre del catálogo que contiene la definición de la restricción Nombre del esquema que contiene la definición de la restricción Nombre de la restricción Nombre del catálogo que contiene la definición de la tabla
VARcHAR(lon)
RY KEY/FOREIGN KEY/CHECK)
Si la restricción es diferible
(YES /
NO)
INITIALLY_DEFERRED
VARCHAR(maxlon)
Si la restricción está inicialmente diferida (YES/NO)
VARCHAR(/on) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima
definida por la implementación SQL. VARcHAR(maxlon) es un tipo de datos VARCHAR con la longitud máxima permitida por la
implementación SQL.
La vista
REFERENTIAL_CON5TRAINT5
La vista REFERENTIAL_CONSTRAINTS contiene una fila por cada restricción referencial (relación clave externa/clave primaria) definida para las tablas del catálogo actual propiedad del usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
Descripción Nombre del catálogo que contiene la definición de la restricción Nombre del esquema que contiene la definición de la restricción
1000
SOL. Manual de referencia
Nombre de columna
Tipo de datos
CONSTRAINT_NAME
vARcHAR(lon)
UNIQUE_CONSTRAINT_ CATALOG
VARcHAR(lon)
UNIQUE_CONSTRAINT_ SCHEMA
VARcHAR(lon)
UNIQUE_CONSTRAINT_ NAME
VARCHAR (ion)
VARcHAR(maxlon)
Apéndice E: El estándar del esquema de la información de SOL
Descripción Nombre de la restricción Nombre del catálogo que contiene la definición de restricción de unicidad o de clave primaria de la tabla padre Nombre del esquema que contiene la definición de restricción de unicidad o de clave primaria de la tabla padre Nombre de la definición de restricción de unicidad o de clave primaria de la tabla padre Tipo de la correspondencia de la clave externa parcial (NONEI PAR-
Nombre de columna Tipo de datos CHECK_CLAUSE
Descripción
VARCHAR(maxLon)
VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementaci6n SQL.
La vista KEY_COLUMN_USAGE contiene una fila por cada columna que participa en una clave definida en el catálogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla:
TIAL/FULL)
Nombre de columna
Tipo de datos
Regla de actualización de la restricción referencial (CASCADE/SET
CONSTRAINT_CATALOG
VARCHAR(lon)
VARCHAR(maxlon)
Regla de eliminación de la restricción referencial (CASCADE/ SET
CONSTRAINT_SCHEMA
VARCHAR(lon)
CONSTRAINT_NAME
VARcHAR(lon)
TABLE_CATALOG
VARCHAR(/on)
TABLE_SCHEMA
VARCHAR(lon)
TABLE_NAME
VARcHAR(lon)
COLUMN_NAME
VARcHAR(lon)
ORDINAL_POSITION
INTEGER >
NULL/SET DEFAULT/NO ACTION)
NULL/SET DEFAULT/NO ACTION)
VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud máxima mayor pennitida por la implementación SQL.
La vista CHECK_CONSTRAINTS
La vista CHECK_CONSTRAINTS contiene una fila por cada restricción de control (restricción de control, restricción del ámbito de control, o definición del aserto) definida por las tablas del catálogo actual propiedad del usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
Tipo de datos
CONSTRAINT_CATALOG
vARcHAR(lon)
CONSTRAINT_SCHEMA
VARCHAR(lon)
CONSTRAINT_NAME
vARcHAR(lon)
Descripción Nombre del catálogo que contiene la definición de restricción Nombre del esquema que contiene la definición de restricción Nombre de restricción
Texto de la condición de búsqueda SQL que define la restricción de control
VARCHAR(/on) es el tipo de datos de los identificadores SQL; ion es la longitud máxima definida por la implementación SQL.
vARcHAR(mailon)
VARCHAR(lon) es el tipo de datos de los identificadores SQL; ion es la longitud máxima definida por la implementación SQL.
1001
o
Descripción Nombre del catálogo que contiene la definición de la restricción de clave Nombre del esquema que contiene la definición de la restricción de clave Nombre de la restricción de clave Nombre del catálogo que contiene la definición de la tabla que contiene la clave Nombre del esquema que contiene la definición de la tabla que contiene la clave Nombre de la tabla que contiene la columna clave Nombre de la columna Posición de la columna dentro de la clave
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL.
La vista ASSERTIONS
La vista ASSERTIONS contiene una fila por cada aserto definido en el catálogo acma} propiedad del usuario actual. Su estructura se muestra en la siguiente tabla:
1002
Apéndice E: El estándar del esquema de la información de SOL
SOL. Manual de referencia
Descripción Nombre del catálogo 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 catálogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla:
Nombre de columna
Tipo de datos
TABLE_CATALOG
vARcHAR(lon)
TABLE_SCHEMA
VARcHAR(lon)
Tl\BLE_NAME
VARcHAR(lon)
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL.
COLUMN_NAME
VARcHAR(lon)
CQNSTRAINT_CATALOG
VARcHAR(lon)
VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementación SQL.
CONSTRAINT_SCHEMA
vARcHAR(lon)
CONSTRAINT_NAME
VARcHAR(lon)
La vista
CONSTRAINT_TABLE_USAGE
La vista CONSTRAINT_TABLE_USAGE contiene una fila por cada tabla usada por una restricción (restricción referencial, de unicidad, de comprobación o aserto) definida en el catálogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
Tipo de datos
TABLE_CATALOG
VARcHAR(lon)
TABLE_SCHEMA
VARCHAR(/on)
TABLE_NAME
VARCHAR(/on)
CONSTRAINT_CATALOG
VARcHAR(lon)
·CONSTRAINT_SCHEMA
VARcHAR(lon)
CONSTRAINT_NAME
VARcHAR(lon)
Descripción Nombre del catálogo que contiene la definición de la tabla Nombre del esquema que contiene la definición de la tabla Nombre de la tabla Nombre del catálogo que contiene la definición de la restricción Nombre del esquema que contiene la definición de la restricción Nombre de la restricción
VARCHAR(lOll) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL.
CONSTRAINT_COLUMN_USAGE
La vista CONSTRAINT_COLUMl'CUSAGE contiene una fila por cada columna usada por una restricción (restricción referencial, de unicidad, de comprobación o aser-
Descripción Nombre del catálogo que contiene la definición de la columna Nombre del esquema que contiene la definición de la columna Nombre de la tabla que contiene la columna Nombre de la columna Nombre del catálogo que contiene la definición de la restricción Nombre del esquema que contiene la definición de la restricción Nombre de la restricción
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL.
La vista
TABLE_PRIVILEGES
La vista TABLE_PRIVILEGES contiene una fila por cada privilegio sobre las tablas definidas en el catálogo 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
Tipo de datos
PRIVILEGE_TYPE
Descripción Identificador de autorización del usuario que concede el privilegio VARcHAR(lon) Identificador de autorización del usuario al que se le concede el privilegio VARcHAR(lon) Nombre del catálogo que contiene esta definición de vista VARCHAR(/on) Nombre del esquema que contiene esta definición de vista vARcHAR(lon) Nombre de la vista VARcHAR(maxlon) TIpo del privilegio (SELECT I INSERT I
IS_GRANTABLE
VARcHAR(maxlon)
GRANTOR GRANTEE
TABLE_CATALOG TABLE_SCHEMA TABLE_NAME
La vista
1003
VARCHAR(lon)
DELETEiuPDATE/REFERENCES)
Si el privilegio se concede con la opción GRANT (YES/NO)
1004
saL.
Manual de referencia
Apéndice E: El estándar del esquema de la información de SOL
VARCHAR(lon) es el tipo de datos de los identificadores SQL; ion es la longitud máxima definida por la implementación SQL. VARCHAR(maxlon) es un tipo de dalos VARCHAR con la longitud máxima mayor permitida por la implementación SQL.
La vista
COLUMN_PRIVILEGES
La vista COLUMN_PRIVILEGES contiene una fila por cada privilegio sobre las columnas definidas en el catálogo 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
Tipo de datos
GRANTOR
VARCHAR(lon)
GRANTEE
VARcHAR(lon)
TABLE_CATALOG
vARcHAR(lon)
TABLE_SCHEMA
VARcHAR(lon)
TABLE_NAME
VARcHAR(lon)
COLUMN_NAME
VARcHAR(lon)
PRIVILEGE_TYPE
VARCHAR(maxlon)
Descripción Identificador de autorización del usuario que concede el privilegio Identificador de autorización del usuario al que se le concede el privilegio Nombre del catálogo que contiene la definición de la tabla que contiene esta columna Nombre del esquema que contiene la definición 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)
IS_GRANTABLE
VARCHAR(maxlon)
Si el privilegio se concede con la opción GRANT (YES/NO)
1005
dido a todos los usuarios o concedido por el usuario actuaL Su estructura se muestra en la siguiente tabla:
Nombre de columna
Tipo de datos
Descripción
GRANTOR
VARCHAR(/on)
GRANTEE
VARCHAR(lon)
OBJECT_CATALOG
VARcHAR(lon)
OBJECT_SCHEMA
VARCHAR(lOIl)
OBJECT_NAME
VARcHAR(lon)
Identificador de autorización del usuario que concede el privilegio Identificador de autorización del usuario al que se le concede el privilegio Nombre del catálogo que contiene la definición del objeto Nombre del esquema que contiene la definición del objeto Nombre del objeto
OBJECT_TYPE
VARcHAR(maxlon)
Tipo del objeto (DOMAIN/CHARACTER SET/ COLLATION/TRANSLATION)
PRIVILEGE_TYPE
VARcHAR(maxion)
IS_GRANTABLE
vARcHAR(maxlon)
Tipo del privilegio (siempre el literal USAGE) Si el privilegio se concede con la opcióo GRANT (YESINO)
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL. VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementación SQL.
La vista
DOMAINS
La vista DOMAINS contiene una fila por cada dominio definido en el catálogo 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 máxima
Nombre de columna
Tipo de datos
Descripción
defmida por la implementación SQL. vARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementación SQL.
DOMAIN_CATALOG
VARCHAR(ion)
La vista
DOMAIN_NAME
VARcHAR(lon)
DATA_TYPE
VARCHAR(maxion)
Nombre del catálogo que contiene la definición del dominio Nombre del esquema que contiene la definición del dominio Nombre del dominio Tipo de datos SQLZ en el que se basa la definición del dominio (representación textual)
USAGE_PRIVILEGES
La vista USAGE;_PRIVILEGES contiene una fila por cada privilegio sobre los objetos definidos en el catálogo actual que ha sido concedido al usuario actual, conce-
VARCHAR(lon)
1006
Apéndice E: El estándar de! esquema de la información de SaL
SOL. Manual de referencia
1007
Tipo de datos
Descripción
Nombre de columna
Tipo de datos
Descripción
CHARACTER_MAXIMUM_ LENGTH
INTEGER > O
Longitud máxima, en caracteres, de
CONSTRAINT_CATALOG
VARcHAR(lon)
VARCHAR(lon)
INTEGER >
variable Longitu<;i máxima de los tipos de datos de longitud variable, en bytes
CONSTRAINT_SCHEMA
CHARACTER_OCTET_ LENGTH
Nombre del catálogo que contiene esta definición de restricción Nombre del esquema que contiene esta definición de restricción
CONSTRAINT_NAME
VARcHAR(lon)
Nombre de la restricción
COLLATION_CATALOG
VARcHAR(lon)
Nombre del catálogo que contiene
DOMAIN_CATALOG
VARcHAR(lon)
DOMAIN_SCHEMA
VARCHAR(lon)
Nombre del catálogo que contiene la definición del dominio sobre el que se aplica la restricción Nombre del esquema que contiene la definición del dominio sobre el que se aplica la restricción
DOMAIN_NAME
VARCHAR(lon)
IS_DEFERRABLE
VARCHAR(maxlon)
Nombre de columna
los tipos de caracteres de longitud
o
la definición de la ordenación para este dominio COLLATION_SCHEMA
VARCHAR(lon)
Nombre del esquema que contiene la ordenación para este dominio
COLLATION~NAME
VARcHAR(lon)
Nombre de la ordenación para este dominio
CHARACTER_SET_ CATALDG
VARCHAR(lon)
Nombre del catálogo que contiene la definición del conjunto de caracteres para este dominio Nombre del esquema que contiene la definición del conjunto de caracteres de este dominio
CHARACTER_SET_ SCHEMA
vARcHAR(lon)
CHARACTER_SET_NAME
VARCHAR(lon)
NUMERIC_PRECISIDN
INTEGER
>
O
NUMERIC_PRECISION_ RADIX
INTEGER
>
O
Base de la precisión
NUMERIC_SCALE
INTEGER
>
O
DATATIME_PRECISIQN
INTEGER >
o
Escala ~i este dominio está basado en un tipo de datos numérico Precisa si este dominio está basado en un tipo de datos Da teTime
DOMAIN_DEFAULT
VARCHAR(maxion)
Nombre del conjunto de caracteres de este dominio Precisa si este dominio está basado en un tipo de datos numérico
Si la restricción es diferible (YES I NO)
INITIALLY_DEFERRED
VARCHAR(maxlon)
Si la restricción está inicialmente diferida (YES /NO)
es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL. VARcHAR(maxlon) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementación SQL.
VARCHAR(lon)
La vista
DOMAIN_COLUMN_USAGE
La vista DOMAIN_COLUIDCUSAGE contiene una fila por cada columna usada por un dominio definido en el catálogo actual por el usuario actual. Su estructura se muestra en la siguiente tabla:
Representación textual del valor predeterminado del dominio
VARCHAR{lon) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima
definida por la implementación SQL. VARCHAR(maxlotl) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementación SQL.
La vista
Longitud máxima del tipo de datos de longitud variable. en octetos
DOMAIN_CONSTRAINTS
La vista DOMAIN_CONSTRAINTS contiene una fila por cada restricción de dominio para un dominio definido en el catálogo actual que es accesible al usuario actual. Su estructura se muestra en la siguiente tabla:
Nombre de columna
Tipo de datos
Descripción
OOMAIN_CATALOG
vARcHAR(lon)
DOMAIN_SCHEMA
VARCHAR(lon)
Nombre del catálogo que contiene la definición del dominio Nombre del esquema que contiene la definición del dominio
DOMAIN_NAME
VARcHAR(lon)
Nombre del dominio
TABLE_CATALOG
VARCHAR(/on)
TABLE_SCHEMA
VARCHAR(/on)
Nombre del catálogo que contiene la definición de la columna Nombre del esquema que contiene la definición de la columna
1008
SOL. Manual de referencia
Nombre de columna
Tipo de datos
TABLE_NAME
VARcHAR(lon) VARCHAR(lon)
Apéndice E: El estándar del esquema de fa información de SOL
Descripción Nombre de la tabla que contiene la
La vista
columna
La vista COLLATIONS contiene una fila por cada ordenación (secuencia de ordenación) definida en el catálogo actual que es accesible al usuario actual. Su estructura se muestra en la siguiente tabla:
Nombre de la columoa
VARCHAR(Jon) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQt.
COLLATIONS
Nombre de columna COLLATION_CATALOG
La vista
CHARACTER_SETS
COLLATION_SCHEMA
La vista CHARACTER_SETS contiene una fila por cada conjunto de caracteres definido en el catálogo actual que es accesible al usuario actual. Su estructura se muestra en la siguiente tabla: Nombre de columna
Tipo de datos
CHARACTER_SET_ CATALOG
VARcHAR(lon)
CHARACTER_ SET_ SCHEMA
vARcHAR(lon)
CHARACTER_SET_NAME
VARcHAR(lon)
FORM_OF~USE
VARCHAR(lon)
NUMBER_OF_ CHARACTERS
INTEGER > o
DEFAULT_CQLLATE CATALOG
VARcHAR(lon)
DEFAULT_COLLATE_ SCHEMA
VARcHAR(lon)
DEFAULT_COLLATE_
NAME
VARCHAR(lon)
1009
Descripción Nombre del catálogo que contiene la definición del conjunto de caracteres Nombre del esquema que contiene la definición del conjunto de caracteres Nombre del conjunto de caracteres Forma de uso del conjunto de caracteres Número de caracteres del conjunto de caracteres Nombre del catálogo que contiene la definición de la ordenación predeterminada para este conjunto de caracteres Nombre del esquema que contiene la definición de la ordenación predeterminada para este conjunto de caracteres Nombre de la ordenación predeterminada para este conjunto de caracteres
COLLATION_NAME CHARACTER_SET_ CATALOG
CHARACTER_SET_ SCHEMA
CHARACTER_SET_
NAME PAD_ATTRIBUTE
Tipo de datos
Descripción Nombre del catálogo que contiene la definición de la ordenación Nombre del esquema que contiene VARCHAR(lon) la definición de la ordenación Nombre de la ordenación VARCHAR(lon) VARCHAR(lon) Nombre del catálogo que contiene la definición del conjunto de caracteres sobre el que se define la secuencia de ordenación VARcHAR(lon) Nombre del esquema que contiene la definición del conjunto de caracteres sobre el que se define la secuencia de ordenación VARcHAR(lon) Nombre del conjunto de caracteres sobre el que se define la secuencia de ordenación VARcHAR(maxlon) Relleno de caracteres (PAD SPACE/ VARcHAR(lon)
NO PAD)
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL. VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementación SQL.
La vista
TRANSLATIONS
La vista TRANSLATIONS contiene una fila por cada traducción (conversión de un conjunto de caracteres en otro) definida en el catálogo actual que es accesible al usuario actuaL Su estructura se muestra en la siguiente tabla: Nombre de columna
Tipo de datos
VARCHAR(lon) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL.
TRANSLATION_CATALOG VARCHAR(lon)
VARCHAR(maxlon) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementación SQL.
TRANSLATION_SCHEMA
VARCHAR(lon)
Descripción Nombre del catálogo que contiene la definición de la traducción Nombre del esquema que contiene la definición de la traducción
1010
SOL. Manual de referencia
Nombre de columna
TIpo de datos
TRANSLATION_NAME
VARcHAR(lon)
SOURCE_CHARACTER_ SET_CATALOG
VARCHAR(lon)
SOURCE_CHARACTER_ SET_SCHEMA
VARCHAR(lon)
CHARACTER_SET_NAME
VARcHAR(lon)
TARGET_CHARACTER_ SET_CATALOG
VARcHAR(lon)
TARGET_CHARACTER_ SET_SCHEMA
VARCHAR(lon)
TARGET_CHARACTER_ SET_NAME
VARCHAR(Jon)
Apéndice E: El estándar del esquema de la información de SaL
Descripción Nombre de la traducción Nombre del catálogo que contiene la definición del conjunto de caracteres en el que ocurre la traducción Nombre del esquema que contiene la definición del conjunto de caracteres en el que ocurre la traducción Nombre del conjunto de caracteres en el que ocurre la traducción Nombre del catálogo que contiene la definición del conjunto de caracteres en el que ocurre la traducción Nombre del esquema que contiene la definición del conjunto de caracteres en el que ocurre la traducción Nombre del conjunto de caracteres en el que ocurre la traducción
VARCHAR(lOIf) es el tipo de datos de los identificadores SQL; Ion es la longitud máxima definida por la implementación SQL.
La vista
SQL_LANGUAGES
La vista SQL_LANGUAGES contiene una fila por cada lenguaje estándar ANSI admitido por esta implementación SQL. SU estructura se muestra en la siguiente tabla: Nombre de columna
Tipo de datos
Descripción Texto que identifica la fuente del estándar del lenguaje (por ejemplo. ISO 9075) VARcHAR(maxion) Año en el que se aprobó el estándar (por ejemplo. 1987) VARcHAR(maxion) Nivel de ajuste (1/2)
Descripción Estilo de vinculación (por ejemplo, EMBEDDED/MODULE/oIRECT)
Nombre del lenguaje de programación admitido (por ejemplo, ADA/cl COBOL/FORTRAN/PASCAL/PLI)
VARCHAR(maxlolI) es un tipo de datos VARCHAR con la longitud máxima permitida por la implementación SQL.
APÉNDICE
F
Guía de instalación del CD-ROM
El CD-ROM que acompaña a este libre incluye versiones completas para Windows NT12000 de las tres marcas líderes de SGBD basados en SQL: • Microsoft SQL Server 2000 • IBM DB2 • MySQL Además. la última sección de este Apéndice contiene instrucciones para descargar una versión de prueba del SGBD Oracle. No son versiones «derno» incompletas de los productos SGBD. En cambio, son versiones de evaluación completas del último software de los fabricantes líderes 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 específicas. El CD-ROM también 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 fácilmente las consultas de ejemplo de este libro. Los archivos residen en el directorio raíz del CD-ROM y se denominan:
Disfrute de este CD-ROM único que sólo está disponible con SQL Manual de referencia, el libro más completo sobre SQL con la colección más completa de
valiosos SGBD basados en SQL de los fabricantes líderes de SGBD. 1013
1014
El
SOL. Manual de referencia
Apéndice F: Guía de instalación del CD-ROM
Estos productos están sujetos a licencias restringidas de uso; son sólo para fines de evaluación y, en algunos casos, incluyen mecanismos de expiración que provocan que el software finafice su operación 90 o 120 días después de la instalación. Véanse las tablas en fas secciones a continuación para consultar los detalles específicos de cada producto.
Fabricante Fundado Ventas anuales
Cuando se inserta el eD-ROM acompañante en la unidad de CD-ROM, Windows inicia automáticamente el programa de instalación de SGBD en el CD-ROM. El programa pide que se acepte el acuerdo de licencia de McGraw-Hill/Osborne y después permite seleccionar el SOBD a instalar, como se muestra a continuaci6n: ~
Microsoft SQL Server 2000 Enterprise Edition requiere el siguiente hardware y software:
Categoría Computadora Sistema operativo
DBMS Selection Ch:Jose Mrl SQl DBMS you woUd ike lo nstal by relecti1g Irom !he ist beIow.
Miacsoft SQl SetVef 2COJ Ertetprice Eátion
('.:o IBM DB2 Univel~ DalabMe 7.2 Entes¡xise EdOOn
a
Mj6Ql3.Z3
ji
NelIt>
f~E~
Las secciones que siguen contienen instrucciones detalladas para la instalación de cada marca de SOBD basado en SQL.
Microsoft SOL Server 2000 La siguiente tabla lista los detalles y los datos del producto y la empresa: Nombre del producto Primera distribución Plataforma Limitaciones del software
Microsoft Corporation 1975 27,7 miles de millones de dólares
Requisitos de hardware y de software
Instalación del software SGBD SOL
r.
1015
SQL Server 2000 Enterprise Edition 1988 Windows NT!2000 Expira 120 días después de la instalación
Memoria (RAM) Espacio en disco duro Software de Internet Software de red
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 más recomendada. Aprox. 250MB para una instalación típica. Microsoft Imernet Explorer versión 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).
Notas sobre la instalación El CD-ROM oficial de evaluación de Microsoft SQL Server 2000 se ha recortado algo para que el software de SQL Server 2000 quepa en el'CD-ROM acompañante. Por tanto, se deben elegir con precisión las selecciones indicadas en las instrucciones de la siguiente sección, o la instalación no procederá correctamente. Además, no háy que intentar instalar OLAP Analysis Services. Si se tienen más preguntas sobre la instalación de SQL Server 2000, consóltese la guía 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 versión previa de SQL Server, hay que hacer una copia de seguridad de la instalación previa de Microsoft SQL Server y no instalar SQL Server 2000 en el mismo directorio que la instalación previa.
1016
SQL. Manual de referencia
Apendice F: Guía de instalación del CD-ROM
Instalación de SOL Server 2000 Para instalar SQL Server 2000 hay que seguir estos pasos: 1. 2. 3.
4:
5.
6. 7.
8.
9.
10. 11.
12.
13.
14.
Iniciar sesión en el sistema como miembro del grupo Administradores. Insertar el CD-ROM acompañante en la unidad de CD-ROM. Windows inicia automáticamente el programa de instalación de los SGBD del CD-ROM. Si el programa de instalación no se inicia automáticamente, hay que pulsar dos veces con el ratón SQLINSTALL.EXE en el directorio raíz del CD-ROM para iniciarlo manualmente. El programa de instalación muestra un cuadro de diálogo 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 instalación muestra el cuadro de diálogo de selección 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 diálogo de bienvenida (Welcome) de la instalación de SQL Server. Pulsar Next (Siguiente) para continuar. Aparece el cuadro de diálogo del nombre de la computadora (Computer Name). Pulsar Next (Siguiente) para aceptar la selección de la computadora local. Aparece el cuadro de diálogo de la selección de la instalación (Insta/latian Selection). Pulsar Next (Siguiente) para aceptar la creación 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 diálogo de la infonnación del usuario (User Information). Introducir el nombre y la compañía si son diferentes de los valores predeterminados indicados, y pulsar Next (Siguiente). Aparece el cuadro de diálogo del acuerdo de licencia del snftware (Software License Agreement). Pulsar Ves (Sí) para aceptar el acuerdo. Aparece el cuadro de diálogo de la definición de la instalación (!nstallation Definition). Pulsar Nat (Siguiente) para aceptar la selección del servidor (Server) y las herramientas del cliente (Client Tools). Aparece el cuadro de diálogo del nombre del ejemplar (Instance Name). Pulsar Next (Siguiente) para aceptar la casilla de verificación Default (predeterminado) o introducir un nombre de ejemplar si ya se tiene una instalación previa de SQL Server. Aparece el cuadro de diálogo del tipo de la instalación (Serup Type). Dejar la opción Typical (Típica) seleccionada. El cuadro de diálogo también indica los directorios predetenninados en los que se copiarán 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 diálogo de las cuentas de los servicios (Services Accouhts). Dejar seleccionada la opción Use The Same Account For Each
15.
16. 17. 18. 19.
1017
Service. Auto Start SQL Server Service (Usar la misma cuenta para cada servicio. Iniciar automáticamente SQL Server). Introducir un nombre de usuario y contraseña 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 diálogo Aurhentication Mode (Modo de autenticación). Seleccionar el modo mixto (Mued Mode) e introducir una contraseña para el inicio de sesión sao Aparece el cuadro de diálogo de la copia de archivos (Start Copying Files). Pulsar Next (Siguiente) para continuar. Si se solicita parar tareas en ejecución, pulsar Nat (Siguiente) para continuar y pulsar Finish (Terminar) para iniciar la instalación. El programa de instalación instala SQL Server en el disco duro. Esto puede durar varios minutos. Cuando la instalación está completa, aparece el cuadro de diálogo Setup Complete (Instalación terminada). Pulsar Finish (Tenninar) para volver a Windows.
Inicio de SOL Server 2000 Después de haber instalado SQL Server 2000 se debe reiniciar la computadora antes de poder empezar a usar el software. SQL server se inicia automáticamente después 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).
Desinstalación de SOL Server 2000 Hay que seguir los siguientes pasos para desinstalar SQL Server 2000: 1.
"
2.
3. 4. 5.
6.
Elegir Inicio 1 Configuración I Panel de control de la barra de tareas de Windows. Pulsar dos veces en la aplicación Agregar o quitar programas. Seleccionar Microsoft SQL Server 2000 de la lista de programas instalados actualmente y pulsar CambiarlEliminar. Aparece el cuadro de diálogo «Confirmar la ·supresión de archivos» .. Pulsar «Sí» para continuar. Aparece el cuadro de diálogo «¿Suprimir archivo compartido'?» y pide que se confinne si se desea suprimir los archivos compartidos que no se van a usar más. Pulsar «Sí» a todo para suprimir estos archivos y pulsar «Sí» cuando aparezca el segundo cuadro de diálogo de confirmación. Windows elimina el prngrama SQL Server 2000 del sistema.
1018
SOL. Manual de referencia
Apéndice F: Guía de instalación del CD-ROM
1019
IBM DB2
Instalación de DB2 Enterprise Edition
La siguiente tabla proporciona varios detalles sobre el producto y la empresa:
Para instalar DB2 Universal Database Enterprise Edition hay que seguir estos pasos:
Nombre del producto Primera distribución Plataforma Limitaciones del software Fabricante Fundado
Ventas anuales
DB2 Universal Database 7.2 Enterprise Ed~tion 1985 Windows NT12000 Expira 90 días después de la instalación IBM Corporation 1911 83,4 miles de millones de dólares
l.
• • • • 2. 3.
Requisitos de hardware y de software Microsoft SQL Server 2000 Enterprise Edition requiere el siguiente hardware y software: Categoría 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 más recomendada. Aprox. 245MB para una instalación típica. 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 instalación de DB2.
4. 5.
6. 7. 8. 9.
Notas sobre la instalación El CD-ROM oficial de evaluación de IBM DB2 2000 se ha recortado algo para que el software de DB2 quepa en el CD-ROM acompañante. Por tanto, se deben elegir con precisión las selecciones indicadas en las instrucciones de la siguiente sección, o la instalación no procederá correctamente. Además, no hay que intentar instalar OLAP Starter Kit. Si se tienen más preguntas sobre la instalación de DB2, consúltese la guía de instalación de DB2 en el CD-ROM. El archivo se encuentra en \lBMDB2\doc\ en\db2i6\db2i6.htm.
Iniciar sesión en el sistema como usu~o que cumpla los requisitos de la instalación de DB2. La cuenta en la que se inicie sesión debe estar (a) definida localmente, (b) pertenecer al grupo de Administradores locales y (e) tener los siguientes derechos de usuario avanzado:
10.
11.
Actuar como parte del sistema operativo. Crear objeto identificador. Incrementar cuotas. Reemplazar identificador de nivel de procesos.
Insertar el CD-ROM acompañante en la unidad de CD·ROM. Windows inicia automáticamente el programa de instalación de los SGBD del CD-ROM. Si el programa de instalación no se inicia automáticamente, hay que pulsar dos veces con el ratÓn SQLINSTALL.EXE en el directorio raíz del CD-ROM para iniciarlo manualmente. El programa de instalación muestra un cuadro de diálogo 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 instalación muestra el cuadro de diálogo de selección 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 instalación muestra un cuadro de diálogo 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 diálogo de selección de productos. Pulsar Nexl (Siguiente) para aceptar la selección DB2 Enterprise Edition. Aparece el cuadro de diálogo para seleccionar el tipo de instalación (Seleer Inslal1ation Type). Pulsar Next (Siguiente) para aceptar la instalación típica (Typical). Aparece el cuadro de diálogo (Seleet Destination Loeation) e indica el directorio predeterminado en el que se copiarán 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 diálogo para introducir el nombre de usuario y la contraseña (Enter Username and Password). Aceptar el nombre de usuario predeterminado db2admin. introducir una contraseña y pulsar Next (Siguiente). Si ya existía el nombre de usuario db2admin de una instalación previa de DB2, se debe introducir la contraseña existente para db2admin; en caso contrario, se pedirá que se confirme que se desea usar el nuevo nombre de usuario. Aparece el cuadro de diálogo de la copia de archivos (Star, Copyillg Files). Pulsar Next (Siguiente) para continuar.
1020 12. 13.
14.
15.
Apéndice F: Guía de instalación del CD·ROM
SOL. Manual de referencia
MySQL AB 1995 No publicadas
Fabricante
El programa de instalación instala DB2 en el disco duro. Esto puede du~ rar varios minutos. Aparece el cuadro de diálogo de instalación 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 instalación está completa, aparece el cuadro de diálogo Setup Complete (Instalación terminada). Pulsar Finish (Terminar) para salir del programa de instalación de DB2. Se ejecuta automáticamente el, programa primeros pasos en DB2 (DB2 Firsl Steps) para empezar a trabajar inmediatamente con DB2.
1021
Fundado
Ventas anuales
Requisitos de hardware y de software MySQL 3.23 requiere el siguiente hardware y software:
Categoría
Requisitos lotel o Pentium compatible. Windows 9x/Me, Windows NT4 SP3 o superior, Windows 2000lWindows XP. 128MB o más recomendada.
Inicio de DB2 Enterprise Edition
Computadora Sist~ma operativo
Después 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. Después de esto, DB2 se inicia automáticamente cada vez que se inicia la computadora.
Memoria (RAM) Espacio en disco duro Software de red
Desinstalación de DB2 Enterprise Edition
Notas sobre la instalación
Hay que seguir los siguientes pasos para desinstalar SQL Server 2000:
Si se tienen más preguntas sobre la instalación de MySQL, consúltense las instrucciones de instalación de MySQL en el sitio Web de MySQL. En el momento de la publicación de este libro, las instrucciones de instalación se encontraban en http://www.mysql.com/doc/W/i/Windows_installation.html. Si este vínculo Web queda anticuado o no es correcto, se pueden buscar en el sitio web principal de MySQL (www.mysql.com) las instrucciones de inst~lación. También se puede visitar el sitio Web de MySQL para descargar la versión más reciente del SGBD MySQL.
l.
2. 3. 4. 5.
6.
Elegir Inicio 1 Configuración I Panel de control de la barra de tareas de Windows. Pulsar dos veces en la aplicación «Agregar o quitar programas». Seleccionar IBM DB2 de la lista de programas instalados actualmente y pulsar «CambiarlEliminar». Aparece el cuadro de diálogo «Confirmar la supresión de DB2». Pulsar «Sí» para continuar. Si se está ejecutando DB2, aparece el cuadro de diálogo INFORMATION y pide que se confirme que se desean para todos los procesos DE2 en ejecución. Pulsar fes (Sí) para continuar. Windows elimina todos los programas DE2 del sistema.
TCP/IP.
Instalación de MySOL Para instalar MySQL hay que seguir estos pasos: l. 2. 3.
MySOL La siguiente tabla proporciona varios detalles sobre el producto y la empresa:
Nombre del producto Primera distribución Plataforma Limitaciones del software
Aprox. 50MB.
MySQL 3.23.51 1995 Windows 9x1Me, Windows NT4/2000/XP Ninguna
4.
,
Iniciar sesión en el sistema como miembro del grupo Administradores. Insertar el CD-ROM acompañante en la unidad de CD-ROM. Windows inicia automáticamente el programa de instalación de los SGBD del CD-RüM. Si el programa de instalación no se inicia automáticamente, hay que pulsar dos veces con el ratón SQLINSTALL.EXE en el directorio raíz del CD-ROM para iniciarlo manualmente. El programa de instalación muestra un cuadro de diálogo 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).
1022 5.
6. 7. 8.
9. 10. 11.
SOL. Manual de referencia
El programa de instalación muestra el cuadro de diálogo de selección del SOBD (DBMS, Database Managemem System). Seleccionar MySQL 3.23 de la lista de posibilidades y pulsar Next (Siguiente). Aparece el cuadro de diálogo de bienvenida (WeLcome) de la instalación de MySQL. Pulsar Next (Siguiente) para continuar. Aparece el cuadro de diálogo de información (Informalion). Pulsar Next (Siguiente) para continuar. Aparece el cuadro de diálogo para elegir la carpeta de destino (Choose Deslinatioll Locatioll) e indica el directorio predeterminado en los que se copiarán los archivos de MySQL. Aceptar el valor predeterminado o BrolVse (Examinar) para especificar diferentes directorios y pulsar Next (Siguiente). Aparece el cuadro de diálogo del tipo de instalación (Setup Type). Pulsar Next (Siguiente) para aceptar la selección tipica (Typical). El programa de instalación introduce MySQL en el disco duro. Esto puede durar varios minutos. Cuando la instalación está completa, aparece el cuadro de diálogo Setup Complete (Instalación tenuinada). Pulsar Finish (Terminar) para salir del programa de instalación de MySQL.
Inicio de MySOL Después de instalar MySQL, se puede ejecutar el programa cliente mysql.exe (ubicado en c:\mysql\bin) desde la línea de comandos para empezar a trabajar inme-
diatamente con MySQL.
Desinstalación de MySOL Hay que seguir los siguientes pasos para desinstalar MySQL: l. 2. 3. 4. 6.
Elegir «Inicio J Configuración I Panel de control de la barra de tareas de Windows». Pulsar dos veces en la aplicación «Agregar o quitar programas». Seleccionar «MySQL Servers And Clients» de la lista de programas instalados actualmente y pulsar «Cambiar!EliminaP). Aparece el cuadro de diálogo «Confirmao) la supresión de archivos. Pulsar «Sí») para continuar. Windows elimina los programas de MySQL del sistema.
Descarga del software del SGBD Oracle La última versión del SGBD Oracle ocupa tres CD-ROM, así que en esta edición de SQL Manual de referencia fue imposible incluirlo en el CD-ROM adjunto con
el resto de marcas de SGBD.
Apéndice F: Guía de instalación del CD·ROM
1023
No obstante se puede descargar la última versión del SGBD Orade directamente desde el sitio Web de Oracle. En el momento en que se publicó este libro, la última versión 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 vínculo Web mantenido por Oracle caduca o no es correcto en el futuro, así que si el vínculo no funciona se puede probar en el sitio Web principal de Oracle (www.oracle.com) para descargar la versión más reciente del SGBD Orade.
A2i, perfil del fabricante de bases de datos, 948 acceso a base de datos desde servidores de aplicaciones, 779·791 acceso a bases de datos con sesiones
heao,781·784 acceso a entidades con sesiones beao, 785-790 mejoras EJB 2.0. 790-791 tipos EJB. 780-781 visión general de, 779·780 distribuidas. 819-827 solicitudes distribuidas, 825-827 solicitudes remotas, 821 transacciones distribuidas, 824-825 transacciones remolas, 822-824 visión general de. 819-822 remotas. 35 extractos de tablas. 808-810 réplica de tablas, 810-812 transparencia y, 806-808
acceso de actualización, 821 acceso remolo, 802-806 acceso sólo 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, inslrucción, 376 DROP ALIAS, instrucción, 376 transparencia de datos remotos, 806~808 ALL, test, 223-225 almacenamiento físico, 368-369 almacenes de datos, 757-772 componentes, 760-761 conceptos, 758~760 cubos de hechos, 762-764 dimensiones multinivel, 766·768 esquemas en estrella, 764-766 estándar SQL para, 49-51, 919-920 evolución 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 adición de columnas, 371-372 cambio de las claves primarias y externas, 373-374 eliminación de columnas, 372-373 Informix, 864 visión general de, 370-371
1025
1026
índice
ampliación, arquitectura centralizadas y, 38-39 análisis de objetos grandes, 895·896 análisis, 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, estándares. 32·34 actualizaciones de vistas. 415-416 caracteres comodín, 119 características de integridad referencial, 287-288 catálogo 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 aritméticas, 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 aplicación) acceso al SGBo con, 592 arquitectura cliente/servidor y, 594 como alternativa a SQL para programación, 592 conceptos, 592-594 loBC. Véase IOBC (conectividad con base de datos lava) ÜDBC. Véase eL! (Call-Levellnterface);
ODBC (Open Dalabase Conneclivily) operación básica de, 592 Oracle. Véase OCI (Orade Call Interface) SQL Server. Véase dblib, API SQUintegración 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
índice aplicaciones, 831 características de SQL para, 12 implementación 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 múltiples bases de datos, 388-390 consu1Las cruzadas de bases de datos y, 390 SOBO, aplicación, 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 ubicación múltiple, 390-392 SOBO, aplicación, 390 ventajas/inconvenientes de, 390-391 arquitectura multicapa, 41~42 arquitectura. Véase también estructura de la base de datos aplicaciones de red y bases de datos, 831-837 réplica, 816-821 sitios Web de tres capas, 777-779 arrays, 861-871. Véase lambién arrays variables, Oraele bases de datos relacionales orientadas a objetos y, 845 consulta, 867-868 de parámetros, OOBC, 658-659 definición, 863-866 manipulación, 868-869 procedimientos almacenadosy, 869-871 variables de Oracle, 865-866 manipulación, 868 procesamiento, 870-871 AS/4oo, 43 ASCn, conjunto de caracteres, 185-186 asertos definición, 375 restricciones avanzadas, 301-303 restricciones de tabla y, 300 ASIC (Applicotion-Specific lntegraled Circuits), 925 ASSERTION, vista, SQL esquema de la información, 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
t
,
atributos, XML documentos y, 881-883 elementos y, 886-889 SQL y, 885 XML Schema, 908·909 auditoría, 736 aumento del nivel de bloqueo, 345 autenticación, 429431 autorreuniones, 151-154 AVG ( ), función de columna, 184
Backus Naur Form (BNF), notación, 903, 967 barras verticales (1), 967 basadas en Internet, 44 bases de datos. Véase también bases de datos distribuidas actualización, 21 adición, 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, 262·265 visión general de, 257·258 comercialización de XML nativo, 916-917 creación. Véase también estructura de la base de datos aljas y sinónimos, 376-378 base de datos simple de ejemplo, 22-23 definiciones de restricciones, 374-376 definiciones de tablas. Véase definición de labias diferencias de la estructura de las bases de datos en diferentes fabricanSes, 357-358 índices, 378-382 LOO (lenguaje de definición de datos) y, 355-356 objetos gestionados, 382·385 agrupadas, 922-923 de almacenes de datos, 760 de ejemplo, 941-946 contenido de las tablas de, 944-946 estructura de, 941-943 visión 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
1027
arquitecturas de réplica, 816·819 compromisos de las réplicas, 814-815 desafíos de, 795-801 extractos de tablas, 808-810 lenguaje SQL y, 7 protocolo de compromiso de dos fases. 827-830 réplica de tablas, 810-812 réplicas actualizables. 813 transparencia de datos remotos, 806808 visión general de, 80\-802 ejemplo simple actualizaciÓn de datos, 21 adición de datos, 20 creación, 22-23 eliminación datos, 22 protección de datos, 21-22 recuperación de datos, 17- I 9 resumen de datos, 19-20 visión general de. 15-17 el mercado de la próxima década. Véase mercado de la próxima década eliminación base de datos simple de ejemplo, 20 DELETE con subconsulta, 269-271 DELETE, instrucción, 266-268 eliminación de todas las filas. 268269 visión 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 portátiles. 796-798, 919~ 920 en red, 56-60 acceso, 57 inconvenientes de, 59 navegación, 58-59 procesamiento de pedidos y, 57 [N (información de negocios), base de datos, 758 integridad de datos y, 278 incorporadas. 922, 935 modificación aClUalización de todas las filas, 274 UPDATE con subconsulta·, 274-275 UPDATE, instrucción, 271-274 visión general de, 271
1028
índice
bases de datos (com.) móviles, 922 üLTP,758-759
orientadas a objetos. Véase 0008 (bases de dalos orientadas a objetos) procedimientos almacenados y disparadores y. 701-702 relacionales ejemplo simple. 15·17
SQL como, 4 tablas representando conjuntos of objetos, 862·863 relacionales orientadas a objetos, 844-850 BLOB, procesamiento. 847·850 aLOB, soporte, 846-847 conjuntos. arrays y coleccioneS, 863 LOB, soporte. 845 visión general de, 844-845 tendencias del mercado. Véase tendencias del mercado tendencias en el procesamiento de datos y, 701-702 XML, 889-899
almacenamiento e integración, 894·899 entrada, 892·894 intercambio de datos, 894
salida. 890-892 visión general de, 889 XML nativas, 916·917 BOOO (bases de datos orientadas a objetos), 839-844 características de, 840-841 historia de, 839 mercado para, 842-&44 pros y contras de, 842 BEGIN DECLARE SECTION, 508 BEGIN TRANSACTIQN, instrucción. 321 BEGIN ... END, secuencia, 713-714 BETWEEN, test, 113-115 bibliotecas de bases de datos. Véase dblib, API bibliotecas. Véase API (interfaces de programas de aplicación) BIND, programa, 491-492, 539 Birdstep Technology, 949 BLOB
(Binary Large Objecls)
almacenamiento XML y, 894-895 procesamiento especializado, 847-850 bloqueo en el nivel de filas, 335 en el nivel de páginas, 335
fndice en el nivel de tablas, 335 explícito. 340, 341 parámetros, 340 por intervalo de espera, 345 bloqueos bloqueo explícito. 340 bloqueo, parámetros, 345 compartido y exclusivo, 336 interbloqueos, 336-339 niveles de aislamiento y, 341-345 niveles, 334-335 técnicas avanzadas. 339 bloques de instrucciones, 713-715 BNF (Backus Naur Form), notación, 903, 967 bucles controlados por cursor, 726-729, 746 ejecución condicional y, 702 ejecución repetida con, 722-724 SQUPSM, 746-747 búsquedas compuestas. 121-124
C. lenguaje comprobación de errOres y, 499-502 declaración de variables del anfitrión, 508 GET DIAGNOSTICS, comprobación 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 cálculo de referencias, XML, 896-899 CallableStatement, objeto, JDBe. 687-691
Cal/-Levellnrerface. Véase CLI (Call-Level lnlerface) caracteres comodín, 117-119 caracteres de escape, 119 carga masiva, 258, 265-266 CASCADE, reglas ALTER TABLE, instrucción, 373 ciclos referenciales, 298 dominios, 375 DROP TABLE, instrucción, 370 reglas de actualización, 292-293 reglas de eliminación, 283-289, 292-294 CASE, expresión, 238-240 CAST, expresión, 236-238
catálogo del sistema comenlarios, 465·466 entidades en, 454-456 esquema de la información de SQL2, 472476 estándar ANSInSO, 453-454 función de, 452-453 herramientas de consulta y, 453 infamación 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 información, 477 catálogo del sistemas. 800-801 catálogos. Véase también catálogo del sistema OCI (Orac1e Cal! Interface), 666·667 üDBC, 655-656 SQL2, estándar, 396 CENTRALHOST, vínculo a la base de datos, 804-805 CHARACTER_SETS, vista, esquema de la infomación de SQL, 1008 CHECK_CONSTRAINTS, vista, esquema de la información de SQL, 1000 ciclos referenciales, 294-298 clases, bases de datos orientadas a objetos, 840-841 cláusulas FROM. Véase FROM, cláusula GROUP BY. Véase GROUP BY, cláusula HAVING. Véase HAVING, cláusula instrucciones SQL y, 76 INTO. Véase INTO, cláusula ORDER BY. Véase ORDER BY, cláusula resumen de, 254 SELECT. Véase SELECT, cláusula SET. Véase SET, cláusula VALUES. Véase VALUES, cláusula WHERE. Véase WHERE, cláusula claves externas cambio, 373-374 consultas padrelhijo y, 139-141 definición. 363-364 integridad referencial y. 286-287 modelo relacional de datos y, 66·68 soporte del catálogo para, 466·469 valores Null y, 299-300
1029
claves primarias 12 reglas de Codd y, 68 cambio, 373-374 consultas padre/hijo y, 139-141 definición, 363-364 integridad referencial y, 286-287 modelo relacional de datos. 64-65 soporte del catálogo para, 466-469 eLI (Cal/·Leve/lnterface), 615-652, 975991 atributos, 647·652 consultas dinámicas. 637-649 consultas, 631-635, 981-984 cursores con nombre. 636 cursores de desplazamiento, 636 ejecución de instrucciones, 624-630, 980981 ejemplo, programa. 918-620 errores y diagnósticos, 647-648, 985986 especificación, 34-35 estandarización de, 615-616 estruclUras de datos, 621-623 funciones de. 616-618 gestión de la conexión, 978-979 gestión de los conrroladores, 977 gestión del entorno, 978 llamadas de información, 651-653. 986 parámetros dinámicos diferidos, 985 procesamiento de transacciones, 630-631 resumen de rutinas, 975-976 secuencia de pasos en, 618-619 valores de los parámetros, 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 dinámicas y, 570 consultas multifila y, 521, 528-529 estándar SQL2, 587 Cloudscape, 922 COALESCE, expresión, 240-241 COBOL, lenguaje SQL incorporado y, 492-505 comprobación de errores y, 500 CODASYL, modelo. 57
1030
índice
CocId, Dc. E. F. ("Ted") 12 reglas, 68-70 historia de SQL y. 26 modelo relacional de. 59 códigos de error, transportabilidad de aplicaciones y. 36 códigos de estado. eLl, 620 códigos de valores de parámetros, eLl. 987991 colas de conexión IOBC, 670 ODBC, 656-657 COLLATIONS, vista. SQL esquema de la información, 1009 COLUMICPRIVILEGES, vista. esquema de la información de SQL, 1004 columnas
adición, 371-372 calculadas, 102-105 catálogo del sistema y, 455, 460-463 coincidentes (reuniones), 138 coincidenles múltiples. 142 concesión de privilegios, 441 de agrupación consultas agrupadas y. 194 múltiples, 196-198 valores Null y. 199-201 definición, 359-362 eliminación. 372-373 nombres, 81 valores de datos, 61-64 COLIDmS, vista, esquema de la información de SQL, 995-997 comentarios, catálogo del sistema, 465-466 COHMENT, instrucción, D82, 466 COHMIT TRAN5ACTION, instrucción, Sybase, 323 COHMIT, instrucciones ANSJlISO, modelo de transacciones, 320 comprobación diferida de restricciones y, 303 cursores y, 534 gestión 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 compensación del enlace, característica, ODBC, 659
índice comprobación de validez, 280-283 columnas, 281-282 definición, 277 dominios, 282-283 visión general de, 280-281 comprobación diferida de restricciones, 303306 computadoras personales. Véase Pe (Personal Computer, computadora personal) Computer Associates, 949-950 Computer Corporation of America, 951 condiciones de búsqueda búsquedas compuestas, 121-124 consultas multitabla, 141·142 consultas simples, 108 sintaxis de SQL, 972 condiciones de búsqueda de grupos. Véase HAVING, cláusula condiciones de búsqueda, subconsultas, 213· 225 ALL, test. 223-225 ANY, test, 219·223 test cuantificados, 219 test de comparación, 213-215 test de existencia, 217-219 test de pertenencia a conjuntos, 215·217 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 definición, 863·866 manipulación, 868-869 procedimientos almacenados y. 869·871 CONNECT TO, instrucciones, 803-804 consorcio X/Open europeo. 615 constantes cadenas, 86·87 fecha y hora. 88·89 numéricas, 86-89 simbólicas, 89 visión general de, 85-86 constantes de cadena, 86-87
constantes constantes constantes constantes
de fecha, 88-89 de hora, 88-89 numéricas, 86 simbólicas, 89
vista, esquema de la información de SQL, 1002 CONSTRAINT_TABLE_USAGE, vista, esquema de la información SQL. 1001-1002 constructoras de toma de decisiones, 720 consultas. Véase también subconsuhas ad hoc, 1I agrupadas. 192·201 columnas de agrupación, 194 múltiples columnas agrupadas, 196·198 procesamienlo, 195~ 196 restricciones sobre, 198~ 199 valores Null en columnas de agrupación, 199·201 almacenes de datos y, 771-772 avanzadas. 234-254 especificación 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 visión general de, 234-236 cláusulas de. 254 CL!, 631-635 correlacionadas, 231 datos colección. 867·868 de columnas columnas calculadas, 102-105 selección, 101·lD2 todas las columnas, 105·106 de resumen, 181-197 agrupadas. 192-196 AVG( J, 184 cláusula H1I.VING sin GROUP BY, 206 cláusula HAVING y, 201-205 COUNT( 1, 186-188 DISTINCT. palabra clave, 191·192 función de columnas. 181-183 MIN( l Y MAX( l, 185·186 múhiples columnas agrupadas, 196~ 198 procesamiento de funciones de columnas, 188-189 restricciones sobre condiciones de búsqueda de grupos, 205 CONSTRAINT_COLUMN_USAGE,
1031
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. condición. 5 J 6 recuperación con eSlructuras de datos, 519 recuperación de valores Null, 517-519 variables de enlrada y salida del anfitrión, 520 visión general de. 514-517 de una única labia, 127 definición, 4 dinámicas, 557·570 CL!, 637-649 CLOSE, instrucción. 570 dblib, API, 609-615 DECLARE CURSOR, inslrucción, 565-566 DESCRIBE, instrucción. 563-565 ejemplo, programa, 559-562 FETCH, inslrucción. 569 OPEN, instrucción. 565-568 pasos en, 557 SQL2, 584-588 visión general de, 557-558 expresiones, 970-972 herencia de tablas y, 860 instrucción SELECT y. 95-98 instrucciones SELECT y. 17 muItifila, SQL incorporado. 521-530 CLaSE, instrucción, 528 cursores de desplazamiento, 528-530 cursores, 524 DECLARE CURSOR, instrucción, 524-526 FETCH, instrucción, 526-528 OPEN, instrucción, 526 visión general de. 521-523 multitabla alias de tabla y. 154-155 aplicación a tres o más tablas, 143-145 aspectos de rendimiento con. 156 autorreuniones y, 151·154 ejemplo de dos tablas, 136-137 equirreuniones y, 137 multiplicación de tablas y, 157·158 nombres de columnas calificados y, 148-150 notación de la reunión externa, 166168
1032
índice
consuhas (conr.) reglas para el procesamiento, 158·159 reuniones externas por la izquierda y por la derecha. 163-166 reuniones internas y externas, 159-163 reuniones simples (equirreuniones). Véase reuniones simples (equirreuniones) reuniones sin igualdad. 147-148 reuniones y. 137-139 ___ selección de todas las columnas y. 150-151 resultados, 97·101 simples búsquedas compuestas. 121-124 columnas calculadas, 102-105 condiciones de búsqueda, 108
consultas de una única tabla, 127 filas duplicadas, 106·}07 ordenación de resultados,124-127 selección de columnas. 101-1 02 selección de filas, 107-108 test de comparación, 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, 128·131 uniones múltiples, 132-133 SQU, 235-236 SQL2. Véase consultas avanzadas XML, 910-916 conceptos de XQuery, 911-914 procesamiento en XQuery. 914-916 visión general de, 910-912 contenido de elemento vacío DTD,902 XML Schema, 908 contenido s610 elemento, XML Schema, 908 CONTINUE, instrucciones, 724 contraseñas, usuario, 429·431 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
í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 gestión 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 parámetros de entrada y salida, 707-708 variaciones del dialecto del SOBO, 707·708 CREATE RQW TYPE, instrucciones, 852 CREATE SCHEMA, instrucciones, 397-399 CREATE SNAPSHOT, instrucciones réplica de tablas y, 810-812 réplicas esclavas y, 813-815 CREATE TABLE, instrucciones, 361-369 almacenamiento físico, 367-369 creación 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, 858·861 tipos de datos fila, 850-852 MATCH FULL, opción, 299-300 MATCH PARTIAL, opción, 300 Oracle, 866 restricciones de comprobación, 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, instrucción, 405 criterio de selección 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, 528·530, 636 instrucción DECLARE CURSOR y, 524-525 instrucciones basadas en cursores, 524-528 posicionamiento con, FETCH y CLaSE, 526 procesamiento de transacciones y. 534 repetición de procedimientos almacenados basados en cursores, 725-729 SQUPSM y, 747-748 cursores con nombre, CLl. 636 cursores de actualización, 691 cursores de bloque, ODBC, 659 cursores de desplazamiento CL!,636 consultas multifila y, 528-530 instrucción FETCH y, 531 JDBC, 668, 691-693
Database 2. Véase DB2 (Databast! 2) datos adición. Véase bases de datos, adición a almacenamiento, 847 compatibilidad, 800 .de instantáneas, 810-812 eliminación. Véase bases de datos, eliminación de modificación. Véase bases de datos, modificación ordenación en almacenes de datos, 768 protección, 21·22 requeridos, 278, 279-280 resumen, 19-20 vistas múltiples, 11 DB2 (Database 2) actualizaciones de vistas y, 416 almacenamiento físico, 369 arquitectura de base de datos única y, 388 bloqueos múltiples. 336 códigos de tipos de datos SQLDA, 564 COMMENT, sintaxis de la instrucción, 466 consultas en SQL dinámico y, 587·588 dialectos de SQL dinámico y, 571-574 grupos de usuarios, 432 información de permisos, 471 reglas de actualización. 291-292 reglas de eliminación, 289·290
1033
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 versiÓn 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 dinámicas, 609-615 funciones. 594-595 interacción entre los programas y el servidor SQL, 595-597 lotes de instrucciones, 598-599 manejo de errores, 599-602 procesamiento de consultas recuperación aleatoria de filas, 607-608 recuperación de valores Null, 604-605 recuperación mediante punteros, 605· 607 . visión general de, 602-604 visión general de, 594 dbnextrowl 1,604-606 dbresults{ l, 599 DEALLOCATE PREPARE, instrucci6n, 576·577 DECLARE CURSOR, instrucción, 521, 524-525, 533-534, 565-566 DECLARE TABLE, instrucción, 495·496 DEFERRA.BLE, restricción, 305 definición de datos dinámicos, 11 sintaxis de las instrucciones SQL, 967·969 definición de tablas, 358-374 adición de columnas, 371-372 almacenamiento físico, 367-369 ALTER TABLE, instrucción, 370-374 claves primaria y externa, 363-364, 373-374 CREATE TABLE, instrucciones, 359, 359-369 definiciones de columna, 359-362 DROP TABLE, instrucción, 369·370 eliminación de columnas, 372-373 restricciones de comprobación, 366-367 restricciones de unicidad, 365-366 valores ausentes y predeterminados, 362363
1034
índice
definición dinámica de dalos, 11 DELETE posicionada, instrucción, 267. 531534 DELETE. instrucciones DELETE con subconsulta, 269·271
eliminación de datos. 20 eliminación de todas las filas. 268-269 herencia de tablas y. 860 problemas de la cláusula WHERE y. 893 visión general de, 266·281 DELETE, privilegio. 433 DESCRIBE, instrucciones consultas dinámicas y, 563-565 estándar SQL2. 585 Dracle y DB2, 571-572 descriptores CL!, 646-647 OCI, 665-666 SQL dinámico, 578-584 estructura de, 578-579 instrucciones de gestión, 579-580 SET DESCRIPTOR, instrucción, 582583 desigualdad (<», operador, 213-224 diagramas sintácticos ALTER TABLE, instrucción. 370-374 bucles controlados por cursor en SQU PSM,748 CASE, expresión, 238-240 CAST, expresión, 236 CLOSE, instrucción, 528 COALESCE, expresión, 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, instrucción, 380·381 CREATE PROCEDURE de SQUPSM, 746 CREATE SCHEMA, instrucciones, 398 CREATE TABLE, il)Strilcciones, 360 CREATE TRIGGER, instrucción, 754-755 CREATE VIEW, instrucción, 405 DB 2COMHENT, instrucción, 466 DECLARE CURSOR, instrucción, 524, 565566 DELETE, instrucción, 266-281 DESCRIBE, instrucción, 563 DROP SCHEMA, instrucciones, 399 DROP TABLE, instrucción, 369 estructuras de bloque en SQUPSM, 749 EXECUTE IMMEDIATE, instrucción, 541
índice instrucción, 549 tests, 217 FETCH. instrucción, 526-527, 569-570 FROM cláusula y, 155 función de columnas. 183 GET DIAGNOSTICS, instrucción, 503 GRANT, instrucciones, 438-439 INSERT sobre varias filas, 262 instrucción SELECT única, 514-515 instrucción UPDATE posicionada, 530-531 IS NULL, test, 124 LOCR TABLE, instrucción, 341 NULLIF, expresión, 241 OPEN, instrucción, 526, 566 PREPARE, instrucción, 547·548 REVORE, instrucciones, 444 subconsultas, 210 test de comparación de subconsultas, 214 test de comparación, 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, instrucción, 504-506 WHERE, cláusula, 121 dialectos de SQL dinámico, 570·574 comparación entre Oracle y OB2, 571-574 conversión de tipos de datos y, 574 visión general de, 570 DIFFERENCE, operaciones, consultas SQL2, 250-253 dimensiones multinivel, almacenes de datos, 766-768 DISCONNECT, instrucción, SQL, 804 disparadores, 735-743 consideraciones sobre, 742 estándares, 312-313, 753-754 integridad referencial y, 310-311 Orade PUSQL y, 741·742 SPL de Informix y, 739·741 tendencias en el procesamiento de datos y, 736 Transact-SQL y, 737-738 ventajas/inconvenientes, 311-312, 701· 702 visión general de, 735-736 dispositivos de mano, 796-798 dispositivos lógicos de bases de datos, Sybase, 368 EXECUTE,
EXISTS,
distinción de la caja (mayúsculas y minúsculas) 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. Véase OTD
(Documem Type Defillitioll.r) documentos comparación de SQL con XML, 886 tipos XML y SQL, 885 XML bien formado, 882 DOMAIN_COLUIoRCUSAGE, vista, SQL DOMAIN_RESTRICCIONES, vista, esquema de la información de SQL, 1006-1007 OOMAINS, vista, esquema de la información 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) comparación de XML Schema con, 901-904 definición, visión general de, dinámico, contenido web (dYllamic web
EJB (Enterprise Java Beans) estandarización del servidor de aplicaciones y, 778-779 mejoras, 790-791 visión general de, 780 ejbStore ( l, método de retrollamada, 788, 789 ejecución asíncrona, OOBC. 658 ejecución condicional, 702, 720-722
1035
! 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 sólo texto, OTO, 902-903 elementos de instrucciones, 973 en SQL, instrucciones, 973 jerarquía OTO, 901·903 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 encapsulación 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. Véase 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. Véase reuniones simples (equirreuniones) errores en tiempo de ejecución, 497 esquema de definición, 472 esquema de la base de datos, 392·393 esquema de la infonnación, SQL, 1007-1008 ASSERTIONS, vista, 1001 catálogo 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, 1005·1006 KEY_COLUMN_USAGE, vista, 1001 REFERENTIAL_CONSTRAINTS, vista, 999
1036
índice fndice
esquema de la información, 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. 998·999 VIEW_TABLE_USAGE, vista, 998 VIEWS, vista, 997 visión general de, 993·994 esquemas. Véase también esquema de la información 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 estándares. Véase también ANSIIlSO estándares; SQUPSM (SQUPersistent SlOred Modules) bases de datos orientadas a objetos, 842 capacidades de los objetos, 844 disparadores, 312-313, 742-744, 753-754 estándares XlOPEN, 32 Internet e integración de los servicios de red, 934-935 interoperabilidad entre bases de datos, 34-35 otros estándares, 34 procedimientos almacenados, 742·744 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 eliminación, 288 restricciones sobre consultas INSERT sobre varias filas, 265 SQL2 catálogo del sistema, 472-476 catálogos, 395 consultas avanzadas. Véase consultas avanzadas consultas dinámicas y, 584-588 dominios gel sistema, 476 esquemas, 396-399
instrucciones DELETE y, 271 instrucciones dinámicas, 575-577 privilegios ampliados, 433-435 reglas de actualización, 291-292 reglas de eliminación y, 288-289 restricción de comprobación de dominios, 282-283 restricciones avanzadas, 302-303 restricciones de columna de comprobación, 281-282 restricciones de integridad, 299-300 reuniones cruzadas y de unión, 174-176 reuniones externas, 172·173 reuniones internas, 169-172 reuniones multitabla, 176-179 SQLDA, 577-584 tipos de datos, 580·581 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Ú, estándares, 392-399 arquitectura de base de datos única, 387388 arquitectura de múltiple ubicación, 390-391 arquitectura de múltiples bases de datos, 388-390 múltiples servidores, 392 transportabilidad de aplicaciones y, 38 visión general de, 386-387 estructura SQL en inglés, 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. Véase manejo de errores EXECUTE IMMEDIATE, instrucciones, 541544,575 EXECUTE, instrucciones ejecución en dos pasos, 545·548 EXECUTE con SQLDA, 549-557 EXECUTE con variables del anfitrión, 549 SQL2, 575, 586
test, 217-219 instrucciones, 724 exploración de conexiones, ODBC, 656 expresiones de consultas, SQL2. 250-254 cláusula FROM y. 253 operaciones UNION. INTERSECT y DIFFERENCE, 250-253 visión general de, 250 de fila, SQLl, 235 de ruta, XQuery. 912·916 de tabla, SQU, 235 que devuelven escalares, 236-242 CASE, expresión, 238-240 CA-ST, expresión, 236·238 COALESCE, expresión. 240-241 NULLIF, expresión, 241·242 que devuelven filas, 242·246 comparaciones de valores de fila, 245 constructora de valores de fila, 242·244 subconsultas con valores de fila, 244· 246 que devuelven tablas, 247-249 constructora de valores de tablas, 246-247 especificación de consultas, 248-249 subconsultas con valores de tablas, 247-248 SQL, 89-90, 970-972, 972-973 extensibilidad, 12-13 eXtensible Markup 1Anguage. Véase XML (eXtensible Markup .Language) eXtensible Stylesheet Language Transformation (XSLT), 910·911 extensiones SQL, almacenes de datos, 768-769 extractos de tablas, 808-810 EXISTS/NOT EXISTS, EXIT,
fabricantes. Véase también tendencias del mercado acceso a bases de datos remotas, 803·806 bases de datos distribuidas, 800·801 capacidades orientadas a objetos, 841-844 de bases de datos, 947·966 A2i,948 Arbor Software. 948 Birdstep Technology, 949 Computer Associates, 949 Computer Corporation of America, 951 Empress Software, 951 eXcelon, 952
1037
Gupta Technologies, 952 Hewlett Packard. 953·954 IBM Corporation, 954-955 Informix Software, 955-956 lista de, 948 Microsoft Corporation, 956·957 MySQL AB, 957 Objectivity, 958 Oracle Corporation, 958·960 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 dinámicas y, 569 mu1tifila consultas y, 521, 526·528 estándar SQL2, 587 filas adición a bases de datos, 257 valores de datos y. 62-63 filas duplicadas consultas simples, 106-) 07 función de columnas y, 191· I92 filas, consultas filas duplicadas, 106·107 selección. 107-108 FIPS (Federal In/ormarion Prdcessing Standard), 9. 32 FOR, bucles, 722-724, 726-727 FOREACH, bucles, 727-728 FOREIGN KEY, cláusula, 363-364 FORTRAN, lenguaje, 492-495 FROH, cláusula consultas multitabla y, 155 expresiones de consultas y, 253·254 instrucciones SELECT y, 96-98 fuentes de datos, lDBC, 694 función de columnas AVG( 1,184 COUNT( 1,186-188 MIN( 1 y MAX( l, 184·186 procesamiento, 188-190
1038
índice
función de columnas (eom.) SUM( 1, 183-184
índice gupos de trabajo Novell. 48 Gupta Technologies. 952
Valores nulos y. 189-191 visión general de. 181-183
funciones almacenadas, 715-717 funciones predefinidas, estructuras del lenguaje SQL, 90·91
gestión de bases de dalos para trabajo en grupo, 48-5 J gestión de errores CL!, 648-649, 985-986
dblib Y SQL incorporado. 602 dbl ib, API, 599·602 lOBC,691 OCI, 666-667 procedimientos almacenados, 729-731 SQLiPSM, 749-751 gestión de errores, SQL incorporado instrucción WHENEVER y, 502-505 SQLCODE y. 497-500 SQLSTATE y. 500·502 tipos de errores, 497 gestión de la conexión, OCI, 663 gestor de controladores lOBC, 676-679 ODBC, 653-655 get { J. método de acceso, EJB, 790 GET DESCRIPTOR, instrucciones, 585 GET DIAGNOSTIC$, instrucciones, Sal, 503504 GET READY. mensaje, 828-830 GOTO, instrucciones. 724 grandes sistemas (mainframesJ, 796·798 de mM (mainframesJ, 44 GRANT OPTION, cláusula, 441-444, 446·448 GRANT, instrucciones, 438-444 permisos y, 21 privilegios de columna, 440 transmisión de privilegios con la cláusula GRANT OPTION, 441-444 visión general de, 438-440 GROUP BY, cláusula. Véase también consultas agrupadas; RAVING, cláusula instrucción SELECT y. 97 múltiples 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, cláusula, 201-206 consultas correlacionadas y, 231 instrucción SELECT y, 97 restricciones sobre, 205 subconsultas y, 207-209, 230·233 uso sin GROUP BY, 206 valores Null y, 205 visión general de, 201-205 , etiqueta, XML, 881-882 herencia de tipos, 858 herencia, 856-862 base de datos orientada a objetos, 840 definición, 856 tabla, 858-861 visión general de, 856-858 herramientas de análisis de datos, 760 herramientas de carga de almacenes de datos, 760 herramientas de consulta, 452 Hcwlett Packard, 953-954 hijo. Véase relación 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 línea de productos de, 920 LOCK TABLE, instrucción, 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 versión de 082, 28-29 identificadores de autorización. 393·394, 429. Véase también identificadores de usuarios identificadores de objetos, 845
identificadores de usuarios, 428-432 autenticación de usuarios, 429-431 grupos de usuarios. 431-432 seguridad en tiempo de ejecución y, 490491 visión 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 (información de negocios), base de datos, 758 IN, test, lI5-ll7. Véase también test de pertenencia a conjuntos (IN) 115·117 independencia del fabricante. 8. 654-655 índices asociativos, 381 como estructura de almacenamiento, 378 CREATE INDEX, .instrucción, 380-382 de árboles B. 381 de árboles T. 381 de mapas de bits, 381 DROP INDEX, instrucción, 381 soporte para, 3 tipos de, 38] ventajas de, 379 información de diagnóstico. CLI, 647-649, 985-986 información de negocios (lN), base de datos, 758 información de relaciones, catálogo 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 información de claves primarias y externas, 469 información de tablas, 459 mercado de las bases de datos empresariales y, 922 perfil del fabricante, 955-956 SYSCOLUMNS, 462 infraestructura de la industria informática, SQLy,14 Ingres LOCK TABLE, instrucción. 340 proyecto Ingres, 28-29 ubicaciones múltiples de almacenamiento, 367
1039
inicialización, OCIo 663-664 IN5ERT de una única fila, 258-262 inserción de todas las columnas, 261 inserción valores Null, 261 visiÓn general de. 258-261 IN5ERT sobre varias filas, 258, 262-265 INSERT, instrucciones adición de datos, 20 CREATE TABLE instrucciones y, 359 entrada XML y, 893 inserción de todas las columnas, 261 inserción de valores Null, 261 INSERT de una única fila, 258-262 INSERT sobre varias filas. 262·265 tablas replicadas y, 810 INSERT, operaciones. XML, 894 IN5ERT, privilegio, 432 instrucción DELETE con búsqueda, 267-268 instrucciones estructura de, 75·77 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 comprobación de validez. 280-283 datos requeridos, 279-280 integridad de las entidades, 283·285 integridad referencial. Véase integridad referencial pérdida de, 277·278 reglas de negocio, 307-313 restricciones avanzadas, 300-307 restricciones, 277-278 vislas e, 404 de las entidades definición, 278 unicidad y valores Null e, 284-285 referencial. 285·300 ciclos referenciales. 294-298 claves externas y valores nulos e, 299-300 definición, 278 disparadores e, 310-311 eliminaciones en cascada y actualizaciones, 292-294
1040
índice
integridad (COllt.) integridad de datos. Véase integridad referencial problemas de corrupción. 286-288
reglas de actualización e. 284·292 reglas de eliminación e. 288-292 visión general de, 285-286 réplicas 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 aplicación. Véase API (Application Program Interfaces) interfaces en el nivel de llamadas, 5. Véase tambi¿n eLl (Cal/-Leve! Interface) interfaces gráficas de usuario (GUn, 831 IntemationaJ Standards Organization (1S0),
9 Internet
acceso a bases de datos, 7. 13
conexiones. 796-798 gestión de grandes volúmenes de datos, 836 integración de los servicios de red y, 934-935 interoperabilidad, 34-35 interoperación entre base de datos, 34-35 1NTERSECT, operaciones, SQL2, 250-253 1NTO, cláusula, instrucciones INSERT, 258 15 NULL, test, 119-121 ISO (Intemalional Standards Organization),
9
J2EE (Java2 Enterprise Edition) estandarización de servidores de aplicaciones, 778·779 integración de SQL en, 13-14 servicios web, 52 Java Database Conneclivity. Véase roBC (conectividad con base de datos Java) Java Naming &.: Directory Interface (INDI), 669 Java Transaction Protocol (JTP), 827 Java. Véase también JDBC (conectividad con base de datos Java) API, 668-669 integración de objetos y, 936
índice integración de SQL con, 13-14 Internet e integración de los servicios de red, 934-935 orientación a objetos de, 676-677 servicios web, 52 Java2 Enterprise Edilion. Véase J2EE (Java2 Enterprise Editian) JDBe (conectividad con base de datos Java), 669-696 cursores de desplazamiento y de actualización, 691-693 enfoque basado en API, 483 historia y versiones, 669·670 instrucciones lIamables, 687-691 instrucciones preparadas, 984-687 integración de SQL en, 13-14 manejo de errores, 691 objetos y métodos de la API, 676-679 opciones avanzadas, 694-696 procesamiento de consullas, 682-684 procesamiento de instrucciones, 679-681 recuperación 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
vista, esquema de la información de SQL, 1001
KEY_COLUMICUSAGE,
LDO (lenguaje de definición de datos) CREATE, DROP y ALTER, 356 funciones de, 355-356 gestión de objetos con, 382-385 lenguaje de administración de bases de datos, SQL, 7 de consultas interactivo, 6, 10 de definición de datos. Véase LOO (Data Definilion Language) de manipulación de datos. Wase LMD (lenguaje de manipulación de datos) de pasarela de bases de datos, SQL, 7 de procedimientos almacenados, 702, 869-870 de programación de bases de datos, SQL,
7, JI
lenguajes de bases de datos, 11 de marcas, XML, 879-880 de modo dual, SQL, 482 de programación consuhas sobre una sola fila y sobre varias y, 514 estructuras de datos y, 519 incorporación de SQL en, 485 lipos de datos y, 509·510 de secuencias de comandos, 776-777 lenguaje, SQL constantes, 86-89 expresiones, 89·90 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 visión general de, 4-5 LIKE, test, 117·119 LIST, datos colección, 863, 868 lista de elementos, SQL, 967 listado de componentes, base de datos, 55-56 llamada a procedimientos almacenados, 708-710 llamadas de información, CLI, 651-652 llaves ({ 1), 968LMD (lenguaje de manipulación de datos) funciones de, 355-356 sintaxis de las instrucciones y, 969-970 SQL como, 257 LOB, procesamiento, Oracle, 848-850 LOB (Large Objects). Véase también BLOB (Binary Large Objecrs); CLOB (C/¡aracler lArge Objects) almacenamiento XML con, 895 analizadores y, 895-896 manipulación OCI de, 667·668 soporte para, 844-845 LOCK TABLE, instrucción, 340-341 lotes de instrucciones dblib, API, 598-599 OOBC, 658
mainframes. Véase grandes sistemas (mainframes) marcadores, ODBC, 660
MATCH FULL, opción, TABLE, 299-300
1041
instrucciones CREATE
MATCH PARTIAL, opción, CREATE TABLE, 300
instrucciones
1,182,184-186 mayor que (», operadores, 219, 881-884 menor que «), operador, 219, 881-884 mercado de la próxima década, 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 integración de objetos, 935-937 Internet/integración de los servicios de red, 934-935 MetaDara, objetos, JDBC, 676, 693-695 metadatas, recuperación, 693-695 meladatos XML definición, 899 .' OTOs y, 901-904 visión general de, 899·901 XML Schema y. 903 método constructor, Oracle, 865 métodos de acceso, EJB 2.0, 790 de selección, 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. Véase SQL Server Windows. Véase Windows, sistemas operativos MINt J, 182, 184-186 minicomputadoras, 44-45 modelo de datos jerárquico, 55-56 acceso, 56 bases de datos de lista de componentes y, 55 IMS como ejemplo de, 56-57 inconvenientes de, 58·59 XML,886
MAX(
1042
índice
modelo relacional de datos, 59~68 12 reglas de Codd. 68-71 características 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 visión general de, S9 modelos de datos. Véase también modelo relacional de datos bases de datos en red, 56·59 jerárquico. 55-56 sistemas de gestión de archivos. 53-55 modelos de transacciones, 319-323 motores de bases de datos. 6 msg_rtn ( 1, 600 multiprocesamiento simétrico (SMP, Symmelric Multiprocessing) ampliación horizontal con, 791 ganancias de rendimiento de, 923-925 versiones y. 350 MULTISET, dalos colección, 863. 868-869 MySQL AB, 957
Native. API, controladores, lDBe. 673-674 navegación. XQuery, 912-913 NCLoe, tipos, Oracle. 846-847 N·cubos (N·dimensional). 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, restricción, 305 NOT EXISTS/EXISTS/, test, 217·219 NOT FaUNO, condición, 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. 895·896 bases de datos orientadas a objetos. 839-844 bases de dalas relacionales orientadas a objetos, 844·850 binarios de gran tamaño. Véase BlOB (Binary Large Objects) conexión, JDBC, 676, 678. 680 conjuntos/arrays/colecciones, 861-871 consulta, 867-868 definición, 863-866 manipulación, 868·869 procedimientos almacenados y, 869-871 visión general de, 861·863 de caracteres de gran tamaño. Véase CLOB (Character Large Objects) de gran tamaño. Véase BlOB (Binary Large Objects); ClOB (Character Large Objects); LOB (Large Objects) de seguridad. 432 gestionados. 382·385 herencia. 856-861 tabla, 858-861 visión general de, 856 instrucción, JDBC, 676, 679·681 métodos 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
OCI (Oraele Cail Interface), 662-669 conexión con el servidor de Oracle. 663666 controladores, 662·663 ejecución de instrucciones, 664-665 funciones, 661 gestión de transacciones, 666·667 manejo de descriptores, 666 procesamiento de consultas, 665·666 visión general de, 660 ODBC (Open Database COllllectivity), 652. 660. Véase también CL! (Call·Level Interface) arquitectura, 653 basado en el estándar CLl, 34-35 capacidades extendidas. 656-660 enfoque API de, 482483 entre plataformas, 35 estructura de, 653-654 funciones del catálogo, 655 independencia del fabricante y, 654 soporte de Mjcrosoft para SQL en, 8·11 visi6n general de, 652 OOMO (Object Data Management Group), 843 OFICINAS, tabla contenido de, 944·945 copia, 808 estructura de, 941-943 OlAP (Online Analytical Processing), 51.
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 proliferación de SQL y, 47-48 Online Analytical Processing (OLAP), 51,922 OPAQUE, tipos de datos, lnformix, 871 Open Database ConneclivjlY. Véase ODBC (Open Database Conneclivity) OPEN, insl11Jcciones consultas dinámicas y, 566-568 consultas multifila y, 521, 526 estándar SQL2, 586 operaciones aritméticas, 90, 177 masivas, ODBC. 659 por lotes, lDBC, 669 operadores de comparación. Véase también test de comparación
1043
< (menor que). 219. 881, 884 <> (desigualdad), 222, 224 > (mayor que), 219. 881, 884 ALL, test, 223 ANY, test, 219 optimización bases de datos distribuidas y, 800 de instrucciones, 485 OR, palabra clave, 121·124 Oracle Caillnterface. Véase 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 conversión de tipos de datos, 855 dialectos dinámicos, 571·574 enfoque de fabricante único de, 922-924 estructura de la base de datos, 357-358 éxito de SQl y, 920 hardware del servidor, 925 información de claves primarias y externas, 469 información de tablas, 458 LOCK TABLE, insl11Jcci6n, 340 manipulación de datos colección, 868 mercado de las bases de datos empresariales y. 920 métodos, 872-874 notación de la reunión externa, 168 perfil del fabricante, 958-960 primer producto SGBD comercial de, 29 procedimientos almacenados, 870-873 procesamiento BLOB, 848·850 réplica de tablas, 810·812 soporte BLOB, 846-847 tablas anidadas en consultas SQl, 867 tipo de datos colección. 866 tipos abstractos de datos, 853·855 Oracle PUSQl, 74)·743 ordenación de datos. Véase ORDER BY, cláusula aRDER BY, cláusula, 97, 124-127,210 Organization for the Advancement of Structured Information Systems (OASIS), 901 orientación a objetos. SQL, 13,935-936
1044
índice
OS/2, 47 consultas mullitabla y, 159-163 definición, 161 notación. 166~168 reuniones externas reuniones externas por la izquierda y por la derecha. 163·166 SQL2, estándar, 172·173
palabras clave, SQL. 967 , eliqueta, XML, 881-882
parámetros array' OOBC, 659 bloqueo, 339, 345 con nombre, Oracle y DB2, 571 de entrada, 627·628, 707-708 de salida, 707-708. 717-719 dinámicos diferidos. 985 ejecución de instrucciones con, 626-630 entrada, 627-629 paso diferido, 629 paso diferido de parámetros, 629 pe (Personal Compurer, computadora personal) acceso estándar a bases de datos para, 35 dalos procesamiento comerciales y. 796·798 proliferación de SQL y, 45-47 PEDIDOS, labia
comparación del orden de compra XML con, 884-885 contenido de, 945 estructura de, 941-943 permisos protección de datos y, 21-22 vislas del catálogo de DB2y, 471 Persistence Software, 960 persistencia gestionada por hean definición, 787 gestionada por contenedor y, 789-790 uso, 788 gestionada por el contenedor aplicación, 788-789 definición, 787 limitaciones de, 789-790 Pervasive Software, 960 ?LlSQL,741-742 planes de aplicación instrucciones y,.485 optimización, 491·192, 539
índice PoinlBase, 961 PostgreSQL, 961 predicados, 108. Véase también condiciones de búsqueda prefijos, espacios de nombres XML, 910 PREPARE, instrucción. 545-548, 576 PreparedStatement, objeto. lDBC, 684 687 4
PRIMAR)' KE),
cláusula, 263-264 restricción, 302 privilegios de propiedad, 435-436 privilegios, 432-436 ampliados, 433 4435 catálogo del sistema y, 455, 471-472 concesión, 438-441 propiedad, 435 retirada, 444-450 tablas y vistas y. 432 transmisión, 441-444 visión general de, 426 problemas de datos inconsistentes, 328-330 de la actualización perdida, 326-327 de la inserción fantasma. 327-330 de lectura desfasada, 328 de lectura no repetible, 327 de los datos no comprometidos, 327-328 procedimientos almacenados. Véase también SQLJPSM (SQUPersiste1l1 Stored Modules): disparadores aplicación de ejemplo, 704-706 aplicaciones cliente/servidor y, 832·834 bases de datos relacionales orientadas a objetos y, 845 bloques de instrucciones, 713-715 colecciones y, 869-871 con nombre, 703 conceptos, 702-703 creación, 706-708 definidos por el sistema, 733 ejecución condicional, 720-722 ejecución repetida, 722-724 estándares 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 métodos y, 872·875
procedimientos almacenados (cont.) parámetros de salida, 716-719 procesamienlo de datos y, 701 repetición con cursores. 725-729 SQUPSM y, 752-753 valores devueltos, 715-717, 719-720 variables, 710·713 ventajas de, 7304732 procesamiento de consultas dblib
comparadas con SQL, 604 recuperación aleatoria de filas, 607-608 recuperación con punteros, 605607 recuperación de valores Null, 604-605 visión 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 explícito, 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 parámetros de bloqueo, 345 problemas de la actualización perdida, 326327 de la inserción fantasma, 330-331 de los datos inconsistentes, 328330
1045
de los datos no .comprometidos, 327-328 proliferación de SQL y, 47 registro histórico de transacciones y, 323-325 simultaneidad, 331-333 técnicas avanzadas de bloqueo, 339 versiones y, 346-350 interactivo de transacciones. Véase 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 implemenlación, 490 4492 propietarios de red, controladores, lDBC, 675-676 proyecto System/R, 28 prueba del débito y el crédito, 926 prueba TPl, 926 pruebas de Transaction Processing Council (TC?), 926-928 puenles JDBClODBC, 670-673 puestos de datos, 761 punteros, 605-607. Véase también controladores puntos de revisión, 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 recuperación aleatoria de filas, 607-608 recuperación de dalas. 17-19,69. Véase también consullas recuperación de una única fila, 111 recuperación, bases de datos distribuidas, 801 Red Brick lntelligelll SQL (RISQL), lenguaje, 769
1046
índice
Red Brick Syslems, 922, 962 redes. Véase también bases de datos distribuidas arquitectura centralizada, 38-39 arquitectura cliente/servidor, 40-41 arquitectura de servidor de archivos, 39AO arquitectura mullicapa, 42 reducción de tráfico, 731 REFERENCES, privilegio, SQL1, 433~435 referencia de la sintaxis. SQL, 967-973 condiciones de búsqueda, 972 elementos de instrucciones, 973 elementos simples, 973 expresiones, 972 expresiones de consultas. 970--972 instrucciones de cursor, 970 de definición de datos, 967-969 d~ procesamiento de transacciones, 970 de manipulación básica de datos, 969-970 referencias correlacionadas. 229 externas, 212·213, 229 REFERENTIAL_CONSTRAINTS, vista, esquema de la información de SQL, 999 registros históricos de transacciones, 323· 327. 848 reglas de actualización, DB2 actualizaciones en cascada, 292-293 ciclos referenciales y, 297 visión general de, 290-292 consistencia, integridad de datos, 272 eliminación, 288·293 ciclos referenciales y, 297 eliminaciones en cascada, 292-293 estándar SQL 1, 288 estándar SQL2, 288-290 eliminación, 375 negocio definición, 278-279 procedimientos almacenados y, 732 negocio de integridad de datos, 306-313 disparadores, 308·313 visión general de, 306-310 relación padre/hijo integridad referencial y, 286·287 modelos jerárquicos y, 55·56 modelos relacionales y, 66-67
fndice
relaciones múltiples, 67 reuniones simples (equirreuniones) y, 139141. 145-147 Relational OnLine Analytie Processing (ROLAP). 51. 922 rendimiento almacenes de datos, 769·772 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, 923·925 en tiempo de ejecución, 730 consultas multitabla y, 156 hardware, 923-925 transacciones distribuidas, 830 vistas y, 404 REPEATABLE READ, nivel de aislamiento, 342-343 réplicas actualizables, 813·815 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,8lO·812 REPRESENTANTES, tabla, 941·944 resolución de referencias, XML, 897-900 restricción referencial (FOREIGN KEY), 302 restricciones asertos, 300-302, 375 avanzadas, 300·306 asertos, 301-302 comprobación diferida, 303-306 restricciones, 300-306 SQL2. 302-303 técnicas avanzadas de bloqueo, 339-346 tipos de, 300-301 CHECK, restricciones, 281-283, 302 comprobación diferida, 303-306 de columna, 281·282, 300 de comprobación columnas y, 281-282 comparadas con disparadóres, 312 CREATE TABLE, instrucciones y, 365-367
restricciones (eont.) dominios y, 282·283 restricciones avanzadas y, 302 de dominio, 282-283, 300, 375 definición, 375 restricciones de tabla y, 300 visión general de, 282·283 de tabla, 299·"300 de unicidad instrucciones CREATE TABLE y, 365 integridad de las entidades y, 284-285 definición, 374-376 lista de, 277·279 NOT NULL, restricciones, 279-280, 302 PRIMARY KEY, restricción, 302 referenciales (FOREIGN KEY), 286, 302 UNIQUE, restricciones, 284-285, 302 RESTRICT, regla de eliminación instrucción ALTER TABLE y, 373 instrucción DROP TABLE, 370 reglas CASCADE, 288-289, 297 RESTRICT, reglas, 375 resultados de las consultas rutinas de descripción, 982-984 rutinas de procesamiento, 981-982 Resul tSet (conjunto de resultados), objetos. JDBC. 677. 683-684 retrollamadas, 896 reuniones. Véase también consultas multitabla cruzadas, SQL2, 173·176 de unión, SQL2, 173-176 definición, 137 externas por la derecha, 163-167 externas por la izquierda, 163·167 internas consultas multitabla y, 159-163 definición, 161 SQL2 y. 169-172 múltiples,,132·133 multitabla, 176-179 simples (equirreuniones), 137-147 aplicación a tres o más tablas, 143·145 claves primarias y externas y, 139141. 147 consultas padreJhijo, 139-141 criterio de selección de filas y, 141-142 múltiples columnas coincidentes, 142 visión general de, 137-139 sin igualdad, 147 subconsultas y, 225-226
1047
instrucciones, 444-450 cláusula GRANT OPTION y, 446~448 estándares ANSIIISO, 448-450 permisos y, 21-22 visión general de, 444-446 RISQL (Red Briek /melUgem SQLJ, lenguaje, 769 ROLAP (Relational 01lLine Analytie Processing), 5 1, 922 ROLLBACK TRANSACTION, instrucción, Sybase. 321 . ROLLBACK, instrucciones comprobación diferida de restricciones y, 303 cursores y, 534-535 gestión de transacciones eLl y, 630-631 modelo de transacciones ANSI/ISO y, 319 procesamiento de transacciones y, 317·319 protocolo de compromiso de dos fases, 828-830 SQL interactivo y, 321 ruta con raíz, expresión, XQuery, 912·913 ruta relativa, expresión, XQuery, 912·913 rutinas de estado, CLl, 985-986 CLl Véase CLI (eall-Level Jnteiface) SQL. 978-980 creación, 745 ejecución de instrucciones, 979 gestión de instrucciones, 979 gestión de la conexión, 978-979 gestión del entorno, 978 REVOKE,
SAA (Syslems Applieation Arehiteelure), 34 salida. XML. 889. 890-891 SAVE TRANSACTION, instrucción, Sybase, 321 SAX (Simple XPl for XML), analizadores, 896 SCHEMATA, vista, esquema de la información de SQL. 994-995 secuenciabilidad de transacciones, 332 secuencias, bases de datos relacionales orientadas a objetos, 845 secuencias de ordenación, transportabilidad de aplicaciones, 37 seguridad conceptos, 426-428 en tiempo de ejecución, 491-492 GRANT, instrucciones, 438-444 identificadores de usuarios, 428-432 objetos de seguridad, 432·433 privilegios, 433-436
1048
índice
seguridad (cont.) procedimientos almacenados y, 731 REVOKE. instrucciones, 444-450 viSlaS y. 404, 436-438 SELECT. cláusula. 96. 98 SELECT, instrucciones. 95-98 característica UNION, 128 cláusula FROM, 98 cláusulas de. 96-97 consultas agrupadas y. 195-196 consultas de una única fila y. 513-514 consultas multitabla y. 158-159 función de columnas en, 188·}89 HAVING, cláusula, 203-204
manipulación de datos. inslI1.lcciones, 969-970 recuperación de datos, 17 resultados de las consultas de, 128 selección de todas las columnas, 105-106, 150-152 5ELECT. cláusula. 98 subconsultas comparadas con, 209-210 tablas reproducidas. 810 SELECT, privilegio, 433 SERIALIZABLE, nivel de aislamiento, 342 series de hora, 768 servicios de red, 934·935 servicios web, SI-52 servidores de aplicaciones acceso a bases de datos con sesiones bean, 782-784 acceso a entidades con sesiones hean, 785·789 arquitecturas de sitios Web de tres capas y, 777-779 bases de datos access y, 779-780 caché,791-794 en Internet, 919 función de, 42 mejoras EJB 2.0, 790·791 primeros sitios Weby, 775-777 tipos EJB, 780-781 visión general de, 775 servidores de redes de área local, 796~798 servidores múltiples, 392 servidores. Véase también arquitectura cliente/servidor conexión con el servidor de Oracle, 663-664 estructuras de múltiples servidores, 392 ganancias de rendimiento en, 923-925 sesión bean, EJB, 781·784, 781·782 con estado, 782-783, 783-785 sin estado, 782-783
índice set ( ), método de acceso, EJB, 790 SET DEFAULT, regla de eliminación, 289·290 SET DESCRIPTOR, instrucción, 582-583, 585 SET LOCK, instrucción, 345 SET NULL regla de eliminación, 289-290 SET TRANSACTION, instrucciones, 335, 344 SET, cláusula, 274, 893 SET, datos colección, 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, 383·385 definición, 4 fabricantes, 8 funciones de, S grupos de usuarios, 432 historia de, 25-26 información de claves primarias y externas, 466-469 de columnas, 462 de permisos, 471 de tablas, 458-459 de vistas, 463-465 del catálogo del sistema, 477 modelos de datos, 53 motor de la base de datos como el corazón de, 6 papel de SQL en, 25-26 parámetros de bloqueo, 345 primeros productos, 28-30 privilegios, 435 / procedimientos almacenados. 703, 710713, 733-734 soporte de los índices, 380 SQL dinámico y, 538, 571-574 tablas del sistema, 455-456 tipos de datos, 509-510 vistas actualización, 416 eliminación, 419 manejo, 403
SGBDR (sistema gestor de bases de datos relacionales), 26 SOML (Standard General Markup ulIIguage), 880·881 signo de la arroba (@), 804-806 signo del dólar ($), 927 signo del euro (€), 914 Simple XPI para XML (SAX), analizadores~ 896 sinónimos, 376 . creación 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 gestión de archivos, 53·55 sistemas gestores de bases de datos. Véase SOBO (sistema gestor de bases de datos) sitios Web arquitectura de tres capas, 777-779 primeras implementaciones de, 775·777 SMP (Symmetric Multiprocessing). Véase multiprocesamiento simétrico 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), 26·32 aceptación comercial, 30-32 características y ventajas, 7-14 como lenguaje de modo dual, 481 como primeros productos SOBD, 28-29 estándares. Véase, estándares, SQL estandarización y, 928-931 hitos en el desarrollo de, 26·27 instrucciones. Véase instrucciones lenguaje. Véase lenguaje, SQL papeles de, 6-7 proliferación de, 42-52 almacenes de datos y, 49-51 aplicaciones distribuidas en Internet, 51-52
1049
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. Véase bases de datos distribuidas rutinas. Véase rutinas, SQL semejanzas de XML con, 885-886 sintaxis. Véase referencia de la sintaxis, SQL SQL Access Group, 34-35. 615 SQL CalJ-Levellnterface. Véase CLI (Cal/Level Interface) SQL Communications Area (SQLCA), 497-498 SQL Data Area. Véase SQLDA (SQL Data Area) SQL dinámico conceptos, 539-541 ejecución de instrucciones en dos pasos, 544-547 EXECUTE con SQLDA, 549-557 EXECUTE con variables del anfitrión, 549 EXECUTE IMMEDIATE, instrucción, 541-544 EXECUTE, instrucción, 548 limitaciones de SQL estático y, 537-539 PREPARE. instrucción, 547 transportabilidad de aplicaciones y, 37 SQL estático. Véase también SQL incorporado, 800 SQL incorporado actualizaciones y eliminaciones con cursores, 530-535 conceptos, 486 consultas de una única fila, 514-521 NOT FOUND, condición, 5 I6 recuperación con estructuras de dalaS, 519-520 recuperación de valores NulJ, 517-519 variables del anfitrión de entrada! salida y, 520 visión general de, 514-516 consultas multifila, 521·530 CLOSE, instrucción, 528 cursores de desplazamiento, 528-530 cursores y, 524 DECLARE CURSOR, instrucción, 524-525 FETCH, instrucción, 526-528
1050
índice índice
SQL incorporado (cont.) instrucción, 526 visión 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 implementación 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 anfitrión declaración, 508-509 (ipos de datos y, 509-510 valores Null y, 511·513 visión general, 506-508 visión general de, 5, 481-483 WHENEVER, instrucción, 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 programación. Véase lambién SQL incorporado papel de SQL en, 320 procesamiento de instrucciones y, 484-485 técnicas, 479-483 transportabilidad de aplicaciones y, 35 SQL Server. Véase también dblib, API estructura de la base de datos, 357 infonnación de claves primarias y externas, 469 infonnación de tablas, 459 interacción de los programas, 597 notación de la reunión 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 características· principales de, 743-745 control de flujo, instrucciones, 745-747 OPEN.
creación de rutinas SQL, 745 estructura de bloques, 747-749 gestión 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 información de SQL, 1010-1011 SQL2 dinámico, 575-588 consultas, 584-588 instrucciones, 575-577 SOLDA y, 577-584 tipos de datos, 580-5&1 visión general de, 575 SQLCA (SQL CommunicatiollS Area), 516 SQLCODE manejo de errores con, 497·498 NOT FOUND, condición, 516 SQLDA
,.
(SQL Data Area), 549-557
códigos 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, métodos, 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, 922·923 dialecto Transact-SQL y, 321 dispositivos lógicos de bases de datos, 368 estructura de la base de datos, 357-358 gestión 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 réplica, 817-818 subconjuntos de tablas horizontales, arquitectura de la réplica, 816-817 subconsultas anidadas, 226-228 cláusula HAVING y, 230-233 cláusula 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. Véase también 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 catálogo del sistema y, 454, 456·460 claves externas, 67-68 claves primarias, 64-65 como objeto de seguridad, 432 con espejo, arquitectura de las réplicas, 818 consultas, 135·137, 143-148 contenido de, 944·946
1051
del sistema 12 reglas de Codd y, 70 catálogo 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, 858·861 multiplication, 157-158 nombres, 80·81 réplica. Véase réplica SQL incorporado, 495-496 vacías, 64 virtuales, 70·71 TABLE_PRIVILEGES, vista, esquema de la informaci6n de SQL, 1003 TABLE_RESTRICCIONES, vista, esquema de la información 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 segmentación, 922-923 estandarización, 928·931 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, 920·921 terminación del programa, 320 test cuantificado (ANY y ALL) ALL, test, 223-225 ANY, test, 219·223 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
índice
In dice
1052 test (con!.)
de encaje de patrones caracteres comodín y. 117-119 caracteres de escape y. 119 consultas simples. 117-119 visión general de. 109, 117 de pertenencia a conjuntos (IN) cansullas simples. 115-117 subconsuhas, 215-217
visión general de, 109 de rango. 109. 113·115 tiempo de compilación errores, 497 y en tiempo de ejecución, 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
a objetos y, 844 definición. 852-855 manipulación, 855-856 visión general de, 850-852 ANSI/ISO SQL. 83-84 códigos SQLDA para DB2, 564 colección, 863-868 datos de consulta, 867-868 definición, 863-866 manipulación de datos, 868-869 procedimientos almacenados y, 869-871 conversión de enteros a decimales, 90 de filas, lnformix, 850-852 definidos por el usuario, 844, 871-872 definición del usuario, 844, 871-872 dialectos dinámicos 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 anfitrión 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
instrucciones (com.) con subconsulta, 274-275 visión general de, 271-274 UPDATE, privilegio, 433 USAGE_PRIVILEGES, vista, esquema de la información de SQL, 1004-1005 usuarios catálogo del sistema y, 455, 469·470 grupos de usuarios, 431-433 seguridad y, 426 UPDATE,
transacciones distribuidas, bases de datos distribuidas, 824-825 remotas, 823·824 simultáneas bloqueo y. 334-348 procesamiento de transacciones y, 331-333 versiones y, 347 Transact-SQL, 308-312, 737-739 TRANSLATIONS, vista, esquema de la información de SQL, 1009-1010 transparencia, datos remotos, 806-807 transportabilidad caracterfsticas SQL y, 9 estándares SQL y, 35-38 variaciones de los tipos de datos y, 84-86 TRUE. palabra clave, 121
operaciones, 128-130 anidadas, 132 expresiones de consultas SQL2, 250-253 filas duplicadas y, 130-132 múltiple, 131-133 ordenación de y, 131 UNIQUE, palabra clave, 380 UNIQUE, restricción, 302 Universal Server de Informix capacidades orientadas a objetos, 844 colecciones y procedimientos almacenados y.869-871 consulta de datos colección, 867-868 conversión de tipos de datos, 855 herencia de tablas, 858-861 herencia, 856-858 manipulación de datos colección, 868-869 métodos y procedimientos almacenados, 873-875 soporte de objetos de gran tamaño, 847 tipo de fila con nombre, 852-853 tipos abslractos de datos, 855 tipos de datos colección, 863-869 tipos de datos fila, 850-852 UPDATE, instrucciones actualización de bases de datos, 21 actualización de todas las filas, 274 herencia de tablas y, 861 posicionada, 531-534, 608-609 problemas de la cláusula SET/WHERE en, 892-893
UPDATE
validación 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
UNION,
Null
I
I
12 reglas de Codd y. 68-70 búsquedas compuestas y, 121-123 cláusula HAVING y, 199-201 claves externas y, 299-300 columnas de agrupación y,199-201 consultas de una única fila y, 517-519 definiciones de columna y, 362-363 estructuras del lenguaje SQL y, 91-93 expresión COALESCE y, 240~241 función de columnas y, 189-190 recuperación con dblib, API, 604-605 restricciones de unicidad y, 284-285 reuniones cruzadas y de unión y, 175-176 tests de comparación y, 112·113 variables del anfitrión y, 51J-513 VALUES, cláusula, 258, 261 variables con nombre, 703 de entrada del anfitrión, 520 de salida del anfitrión, 520 del anfitrión declaración, 506-508 entrada y salida, 520 estructura de datos como, 519-520 EXECUTE y, 549 tipos de datos, 509-512
1053
valores Null y, 511-S13 visión general, 506-508 denotación en XQuery, 912-913 procedimientos almacenados, 710-713 Versant Corporalion, 965 versiones, 346-350 implementación, 346-350 ventajas/inconvenientes, 350·351 visión general de, 346-347 VIEW_COLUHN_USAGE, vista, esquema de la infonnación de SQL, 998-999 VIE\CTABLE_US1I.GE, vista, esquema de la infonnación de SQL, 997 VIEWS, vista, esquema de la infonnaciÓn de SQL.997 vistas actualización, 414-419 ANSUISQ, estándares, 415-416 comprobación de actualizaciones, 416-419 opciones del SGBO, 416 visión" general de, 414-415 agrupadas, 409-412 catálogo del sistema y, 455, 463-465 como objeto de seguridad, 432 creación, 405-414 subconjuntos de filas y columnas, 409 visión general de, 405-412 vistas agrupadas, 410-412 vistas horizontales, 405-407 vistas reunidas, 412-414 vistas verticales, 407·409 de múltiples datos, 11 de subconjuntos de filas y columnas, 409 eliminación, 419-420 funciones de, 401-402 horizontales, 405-407, 436 manejo del SOBO de, 403 materializadas, 420-422 nombres y referencias, 403 restricción del acceso a columnas con, 436-437 restricción del acceso a filas con, 438 restricciones sobre la aplicación 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
W3C (World Wide Web Consortium) definición, 879-881 estandarización de XML, 900 estandarización de XQuery, 911 WalMart, 932-933 WHENEVER, instrucción, 502-505 acciones. 504 condiciones de excepción, 502 ventajas de, 505 \'IHERE, cláusula, 96 consultas de dos tablas y. 157 DELETE, instrucciones. 267 problemas con instrucciones UPDATE/ DELETE, 893 selección de filas y. 107-108 subconsultas y. 207-208, 210-212 UPDATE, instrucciones, 271·273 WHILE. bucles. 722-724, 728-729 Windows. sistemas operativos acceso a bases de datos y, 919·920 soporte de SQL en, 8-10 SQL Server y, 47·48 trabajo en grupo en Windows NT, 48 World Wide Web Consortium. Véase W3C (World Wide Web Consortium)
XlOPEN, estándares, 34, 615 XA. protocolo, 827
XML (eXtensible Markup Language) almacenamiento. 894~899 cálculo de referencias, 896~899 definición. 889 objetos grandes y analizadores. 895~ 896 visión general de. 894
bases de datos, 889-899, 916-917 almacenamiento e integración, 899 entrada, 892-894 intercambio de dalaS. 894 salida. 890~892 visión general de, 889 consultas. 910-916 definición, 879~881 elementos y atributos, 886-889 entrada XML, 889, 892-894 espacios de nombres, 909-910 integración de dalaS. 889 intercambio de datos, 889, 894 metadatos. 899~91 O DTD y, 901-903 visión general de, 899-901
XML Schema,
894~
904~91O
para datos, 884-889 salida XML. 889, 890-892 SQL comparado con, 885-886 visión 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
