Introducion DB2 - Version9 - Z - Español1

DB2 versión 9.
1 para z/OS
򔻐򗗠򙳰
Introducción a DB2 para z/OS
SC11-3682-02
Contenido
Acerca de esta información . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
A quién va dirigido este manual . . . . . . . . . . . . . . . . . .
. ix . . . . . . . . .
Conjunto de programas de utilidad de DB2 . . . . . . . . . . . . . . .
. ix . . . . . . . . .
Terminología y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Características de accesibilidad para DB2 Version 9.1 for z/OS . . . . . . . . . . . . . . . . . . x
Cómo enviar comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Capítulo 1. Visión general de DB2 y gestión de información . . . . . . . . . . . . . 1

Casos de ejemplo para utilizar DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Disponibilidad y escalabilidad para empresas grandes . . . . . . . . . . . . . . . . . . . . 1
Información empresarial crítica para los encargados de tomar decisiones . . . . . . . . . . . . . . 4
Distribución de datos y acceso de web. . . . . . . . . . . . . . . . . . . . . . . . . . 6
Estrategia de gestión de información de IBM . . . . . . . . . . . . . . . . . . . . . . . . 6
Servidores de datos y entornos de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Servidores empresariales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Ediciones distribuidas de DB2 Database . . . . . . . . . . . . . . . . . . . . . . . . . 11
DB2 en servidores a escala más reducida . . . . . . . . . . . . . . . . . . . . . . . . 12
Entornos personales, móviles y dominantes. . . . . . . . . . . . . . . . . . . . . . . . 12
Entornos de varias transacciones y aplicaciones . . . . . . . . . . . . . . . . . . . . . . 12
DB2 y comunicación de redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Clientes soportados por servidores de datos de DB2 . . . . . . . . . . . . . . . . . . . . . 13
Fuentes de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Herramientas de gestión de información. . . . . . . . . . . . . . . . . . . . . . . . . . 14
Herramientas de desarrollo de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . 15
Componentes de middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
DB2 Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
WebSphere Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
WebSphere Host Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Soporte de base de datos federada mediante WebSphere Information Integrator . . . . . . . . . . . 19
Réplica de datos mediante WebSphere Replication Server . . . . . . . . . . . . . . . . . . . 20
| WebSphere DataStage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
WebSphere QualityStage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Interfaces de programación de aplicaciones cliente . . . . . . . . . . . . . . . . . . . . . . 20
Estándares abiertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Capítulo 2. Conceptos de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . 23

Lenguaje de consulta estructurado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Visión general de pureXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Estructuras de datos de DB2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Tablas de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Índices de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Claves de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Vistas de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
| Esquemas y calificadores de esquemas de DB2 . . . . . . . . . . . . . . . . . . . . . . 33
Espacios de tablas de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Espacios de índice de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Grupos de almacenamiento de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Bases de datos de DB2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Objetos del sistema DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Catálogo de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Directorio de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Registros activo y de archivado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Conjunto de datos del programa de arranque . . . . . . . . . . . . . . . . . . . . . . . 42
Agrupaciones de almacenamientos intermedios . . . . . . . . . . . . . . . . . . . . . . 42
© Copyright IBM Corp. 2001, 2008 iii

Base de datos de soporte de control de definición de datos . . . . . . . . . . . . . . . . . . 43
Base de datos de recurso de límite de recursos . . . . . . . . . . . . . . . . . . . . . . 43
Base de datos de archivos de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Soporte de alta disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Imposición de reglas empresariales . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Integridad de entidad, integridad de referencia y restricciones de referencia . . . . . . . . . . . . . 44
Restricciones de comprobación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Desencadenantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Procesos de aplicaciones y transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Paquetes y planes de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Rutinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Procedimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Datos distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Servidores remotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Conectividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Capítulo 3. Arquitectura de DB2 para z/OS . . . . . . . . . . . . . . . . . . . . 53

z/Architecture y el sistema operativo z/OS . . . . . . . . . . . . . . . . . . . . . . . . 53
DB2 en el entorno z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Gestor de bloqueos de recursos interno de DB2 . . . . . . . . . . . . . . . . . . . . . . . 56
DB2 y z/OS Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
DB2 y DFSMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Recursos de conexión de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Recurso de conexión de CICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Recurso de conexión de IMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Recurso de conexión de TSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Recurso de conexión de llamada . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Recurso de conexión de RRS (Resource Recovery Services) . . . . . . . . . . . . . . . . . . 62
Recurso de datos distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
DB2 en un entorno Sysplex paralelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Capítulo 4. Objetos de DB2 y sus relaciones . . . . . . . . . . . . . . . . . . . 67

Diseño lógico de bases de datos utilizando creación de modelos de relación de entidad . . . . . . . . . . 67
Creación de modelos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Entidades para diferentes tipos de relaciones . . . . . . . . . . . . . . . . . . . . . . . 71
Aplicación de reglas empresariales a relaciones . . . . . . . . . . . . . . . . . . . . . . 72
Atributos para entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Normalización para evitar redundancias . . . . . . . . . . . . . . . . . . . . . . . . . 75
Diseño lógico de bases de datos con Unified Modeling Language (Lenguaje de creación de modelos unificados) . 80
Diseño físico de base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Desnormalización para mejorar el rendimiento . . . . . . . . . . . . . . . . . . . . . . 83
Utilización de vistas para personalizar los datos que ve un usuario. . . . . . . . . . . . . . . . 85
Utilización de índices para mejorar el rendimiento . . . . . . . . . . . . . . . . . . . . . 85
Capítulo 5. SQL: lenguaje de DB2 . . . . . . . . . . . . . . . . . . . . . . . . 87

Modos de acceder a datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Modos de seleccionar datos de columnas . . . . . . . . . . . . . . . . . . . . . . . . 87
Cómo funciona una sentencia SELECT . . . . . . . . . . . . . . . . . . . . . . . . . 90
Funciones y expresiones de SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Modos de filtrar el número de filas devueltas . . . . . . . . . . . . . . . . . . . . . . . 97
Modos de ordenar filas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Modos de resumir valores de grupo . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Modos de fusionar listas de valores . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Modos de especificar condiciones de búsqueda . . . . . . . . . . . . . . . . . . . . . . 109
Modos de unir datos de más de una tabla . . . . . . . . . . . . . . . . . . . . . . . . 110
Subconsultas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Modos de acceder a datos de DB2 que no están en una tabla . . . . . . . . . . . . . . . . . 118
Modos de modificar datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Inserciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
iv Introducción a DB2 para z/OS

Actualizaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Supresiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Modos de ejecutar SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
SQL estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
SQL dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
DB2 ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Acceso a DB2 para Java: SQLJ y JDBC . . . . . . . . . . . . . . . . . . . . . . . . . 121
SQL interactivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Tablas de ejemplo de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Tabla de actividades (DSN8910.ACT) . . . . . . . . . . . . . . . . . . . . . . . . . 124
Tabla de departamentos (DSN8910.DEPT) . . . . . . . . . . . . . . . . . . . . . . . . 125
Tabla de empleados (DSN8910.EMP) . . . . . . . . . . . . . . . . . . . . . . . . . 127
Tabla de fotografías y currículums de empleados (DSN8910.EMP_PHOTO_RESUME) . . . . . . . . . 130
Tabla de proyectos (DSN8910.PROJ) . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Tabla de actividades de proyectos (DSN8910.PROJACT) . . . . . . . . . . . . . . . . . . . 133
Tabla de empleados de actividades de proyectos (DSN8910.EMPPROJACT) . . . . . . . . . . . . 134
Tabla de ejemplo Unicode (DSN8910.DEMO_UNICODE) . . . . . . . . . . . . . . . . . . . 135
Relaciones entre las tablas de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . 136
Vistas en las tablas de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Almacenamiento de tablas de aplicaciones de ejemplo. . . . . . . . . . . . . . . . . . . . 141
Capítulo 6. Programación de aplicaciones para DB2 . . . . . . . . . . . . . . . 147

Desarrollo de aplicaciones de DB2 en entornos de desarrollo integrados . . . . . . . . . . . . . . . 147
WebSphere Studio Application Developer . . . . . . . . . . . . . . . . . . . . . . . . 148
DB2 Development Add-In for Visual Studio .NET . . . . . . . . . . . . . . . . . . . . . 148
Herramientas de desarrollo de aplicaciones de estación de trabajo . . . . . . . . . . . . . . . . 149
Lenguajes de programación y métodos para desarrollar programas de aplicaciones . . . . . . . . . . . 149
Proceso de preparación para un programa de aplicación . . . . . . . . . . . . . . . . . . . . 150
Aplicaciones de SQL estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Declaración de definiciones de tablas y vistas . . . . . . . . . . . . . . . . . . . . . . 155
Acceso de datos con variables de lenguaje principal . . . . . . . . . . . . . . . . . . . . 156
Acceso de datos con matrices de variables de lenguaje principal . . . . . . . . . . . . . . . . 157
Acceso de datos con estructuras de lenguaje principal . . . . . . . . . . . . . . . . . . . . 158
Recuperación de filas con un cursor . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Modos de comprobar la ejecución de sentencias de SQL . . . . . . . . . . . . . . . . . . . 161
Aplicaciones de SQL dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Tipos de SQL dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Conceptos sobre programación de SQL dinámico . . . . . . . . . . . . . . . . . . . . . 163
Utilización de ODBC para ejecutar SQL dinámico . . . . . . . . . . . . . . . . . . . . . 164
Utilización de Java para ejecutar SQL estático y dinámico . . . . . . . . . . . . . . . . . . . 165
Soporte de SQLJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Soporte de JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Utilización de un programa de aplicación como un procedimiento almacenado . . . . . . . . . . . . 168
Lenguajes utilizados para crear procedimientos almacenados . . . . . . . . . . . . . . . . . 169
Proceso de procedimientos almacenados . . . . . . . . . . . . . . . . . . . . . . . . 170
Utilización del lenguaje de procedimiento de SQL para crear un procedimiento almacenado . . . . . . . 172
Utilización de DB2 Developer Workbench para crear un procedimiento almacenado . . . . . . . . . . 173
Configuración del entorno de procedimientos almacenados . . . . . . . . . . . . . . . . . . 173
Preparación de un procedimiento almacenado . . . . . . . . . . . . . . . . . . . . . . 174
Cómo pueden llamar las aplicaciones a procedimientos almacenados . . . . . . . . . . . . . . . 174
Capítulo 7. Implementación del diseño de base de datos . . . . . . . . . . . . . 177

Creación de tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Tipos de tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Creación de tablas base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Creación de tablas temporales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Creación de tablas de consultas materializadas . . . . . . . . . . . . . . . . . . . . . . 182
Creación de una tabla con particionamiento controlado por tabla . . . . . . . . . . . . . . . . 183
Definición de columnas de una tabla . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Nombres de columna. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Contenido v
Tipos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Valores nulos y por omisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Utilización de restricciones de comprobación para imponer la validez de valores de columnas . . . . . . 196
Diseño de una fila . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Longitudes de registro y páginas . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Diseños que desperdician espacio . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Creación de espacios de tablas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Tipos de espacios de tablas de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Cómo DB2 crea implícitamente un espacio de tablas . . . . . . . . . . . . . . . . . . . . 208
| CómoDB2 crea implícitamente un espacio de tabla XML . . . . . . . . . . . . . . . . . . . 208
Asignación de espacios de tablas a almacenamiento físico . . . . . . . . . . . . . . . . . . 212
Creación de índices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Tipos de índices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Cómo pueden ayudar los índices a evitar clasificaciones . . . . . . . . . . . . . . . . . . . 216
Claves de índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Atributos de índices generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
| Atributos de índices XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Atributos de índices de tablas particionadas . . . . . . . . . . . . . . . . . . . . . . . 225
Creación de vistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Vista de una única tabla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Vista que combina información de varias tablas . . . . . . . . . . . . . . . . . . . . . . 232
Inserciones y actualizaciones de datos mediante vistas. . . . . . . . . . . . . . . . . . . . 232
Creación de objetos grandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Creación de bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Creación de relaciones con restricciones de referencia . . . . . . . . . . . . . . . . . . . . . 236
Cómo DB2 impone restricciones de referencia . . . . . . . . . . . . . . . . . . . . . . 236
Construcción de una estructura de referencia . . . . . . . . . . . . . . . . . . . . . . . 239
Tablas de una estructura de referencia . . . . . . . . . . . . . . . . . . . . . . . . . 240
Creación de tablas de excepción . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Creación de desencadenantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Creación de funciones definidas por el usuario . . . . . . . . . . . . . . . . . . . . . . . 241
Capítulo 8. Gestión del rendimiento de DB2 . . . . . . . . . . . . . . . . . . . 245

Pasos iniciales para la gestión del rendimiento . . . . . . . . . . . . . . . . . . . . . . . 245
Objetivos de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Diseño de las aplicaciones para el rendimiento . . . . . . . . . . . . . . . . . . . . . . 246
Origen de problemas de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . 246
Herramientas para análisis del rendimiento . . . . . . . . . . . . . . . . . . . . . . . 247
Modos de mover datos eficazmente en el sistema . . . . . . . . . . . . . . . . . . . . . . 248
Rol de las agrupaciones de almacenamientos intermedios en la puesta en antememoria de datos . . . . . 248
Efecto de la compresión de datos en el rendimiento . . . . . . . . . . . . . . . . . . . . 251
Cómo puede afectar al rendimiento la organización de los datos . . . . . . . . . . . . . . . . 251
Modos de mejorar el rendimiento para varios usuarios . . . . . . . . . . . . . . . . . . . . 255
Rendimiento mejorado mediante la utilización de bloqueos . . . . . . . . . . . . . . . . . . 256
Rendimiento mejorado mediante control de simultaneidad . . . . . . . . . . . . . . . . . . 260
Modos de mejorar el rendimiento de las consultas . . . . . . . . . . . . . . . . . . . . . . 261
Utilización de EXPLAIN para comprender la vía de acceso . . . . . . . . . . . . . . . . . . 262
Herramientas que ayudan a mejorar el rendimiento de las consultas . . . . . . . . . . . . . . . 263
Análisis del rendimiento de consultas y aplicaciones . . . . . . . . . . . . . . . . . . . . 265
Capítulo 9. Gestión de operaciones de DB2 . . . . . . . . . . . . . . . . . . . 269

Herramientas que le ayudan a gestionar DB2. . . . . . . . . . . . . . . . . . . . . . . . 269
Centro de control de DB2 y herramientas relacionadas . . . . . . . . . . . . . . . . . . . 269
DB2 Administration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
DB2 Interactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Utilización de mandatos y programas de utilidad para controlar las operaciones de DB2 . . . . . . . . . 271
Mandatos de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Programas de utilidad de DB2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Gestión de conjuntos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Mecanismos de autorización y seguridad para el acceso a datos . . . . . . . . . . . . . . . . . 273
vi Introducción a DB2 para z/OS

Cómo controlan el acceso a datos los ID de autorización . . . . . . . . . . . . . . . . . . . 274
Cómo mantienen privilegios y autoridades los ID de autorización . . . . . . . . . . . . . . . . 274
Modos de controlar el acceso a subsistemas DB2 . . . . . . . . . . . . . . . . . . . . . 276
Modos de controlar el acceso a los datos . . . . . . . . . . . . . . . . . . . . . . . . 278
Modos de controlar el acceso a objetos de DB2 mediante autoridades y privilegios explícitos . . . . . . . 279
Utilización de seguridad de varios niveles para controlar el acceso . . . . . . . . . . . . . . . 281
Utilización de vistas para controlar el acceso . . . . . . . . . . . . . . . . . . . . . . . 281
Utilización de otorgamiento y revocación de privilegios para controlar el acceso . . . . . . . . . . . 282
Copia de seguridad, recuperación y reinicio . . . . . . . . . . . . . . . . . . . . . . . . 284
Recursos y herramientas de copia de seguridad y recuperación. . . . . . . . . . . . . . . . . 286
Reinicio de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Copias de seguridad y comprobaciones de datos regulares . . . . . . . . . . . . . . . . . . 289
Control de los cambios en las bases de datos y de la coherencia de los datos . . . . . . . . . . . . 290
Sucesos del proceso de recuperación. . . . . . . . . . . . . . . . . . . . . . . . . . 292
Optimización de la disponibilidad durante la copia de seguridad y la recuperación . . . . . . . . . . 293
Capítulo 10. DB2 y la web . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Entorno de aplicaciones web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Componentes de aplicaciones basadas en la web . . . . . . . . . . . . . . . . . . . . . 298
Características arquitectónicas de aplicaciones basadas en la web . . . . . . . . . . . . . . . . 299
Ventajas de DB2 para z/OS como servidor . . . . . . . . . . . . . . . . . . . . . . . 302
Aplicaciones basadas en la web y WebSphere Studio Application Developer . . . . . . . . . . . . . 303
XML y DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Ventajas de utilizar XML con DB2 para z/OS. . . . . . . . . . . . . . . . . . . . . . . 305
Modos de utilizar XML con DB2 para z/OS . . . . . . . . . . . . . . . . . . . . . . . 306
SOA, XML y servicios web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Capítulo 11. Acceso a datos distribuidos . . . . . . . . . . . . . . . . . . . . 309

Modos de implementar datos distribuidos en programas . . . . . . . . . . . . . . . . . . . . 310
Sentencias CONNECT explícitas . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Nombres en tres partes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Modos en que los datos distribuidos afectan a otras tareas . . . . . . . . . . . . . . . . . . . 313
Efectos de los datos distribuidos en la planificación . . . . . . . . . . . . . . . . . . . . 313
Efectos de los datos distribuidos en la programación . . . . . . . . . . . . . . . . . . . . 313
Efectos de los datos distribuidos en la preparación de programas . . . . . . . . . . . . . . . . 314
Cómo se coordinan las actualizaciones entre sistemas distribuidos. . . . . . . . . . . . . . . . . 315
Soporte de gestor de transacciones de DB2 . . . . . . . . . . . . . . . . . . . . . . . 315
Servidores que dan soporte a confirmación en dos fases . . . . . . . . . . . . . . . . . . . 316
Servidores que no dan soporte a confirmación en dos fases . . . . . . . . . . . . . . . . . . 316
Modos de reducir el tráfico de la red . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Mejoras en la eficacia de las consultas . . . . . . . . . . . . . . . . . . . . . . . . . 317
Reducción del volumen de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . 318
Optimización para conjuntos de resultados grandes y pequeños . . . . . . . . . . . . . . . . 319
Mejoras del rendimiento para SQL dinámico . . . . . . . . . . . . . . . . . . . . . . . 320
Capítulo 12. Compartimiento de datos con los datos de DB2 . . . . . . . . . . . . 321

Ventajas del compartimiento de datos de DB2 . . . . . . . . . . . . . . . . . . . . . . . 321
Disponibilidad mejorada de los datos . . . . . . . . . . . . . . . . . . . . . . . . . 322
Crecimiento escalable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Configuraciones flexibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Inversiones protegidas en personas y habilidades . . . . . . . . . . . . . . . . . . . . . 329
Cómo DB2 protege la coherencia de los datos en un entorno de compartimiento de datos . . . . . . . . . 329
Cómo se realizan actualizaciones en un entorno de compartimiento de datos . . . . . . . . . . . . . 331
Cómo escribe DB2 los datos cambiados en disco en un entorno de compartimiento de datos . . . . . . . . 335
Modos en que el compartimiento de datos afecta a otras tareas. . . . . . . . . . . . . . . . . . 336
Modos en que el compartimiento de datos afecta a la disponibilidad . . . . . . . . . . . . . . . . 337
Recursos de información para DB2 for z/OS y productos relacionados . . . . . . . 339
Cómo obtener información de DB2 . . . . . . . . . . . . . . . . . . . . . . . 345

Contenido vii
Cómo utilizar la biblioteca de DB2 . . . . . . . . . . . . . . . . . . . . . . . 349
Avisos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Información de interfaz de programación . . . . . . . . . . . . . . . . . . . . . . . . . 355
Interfaz de programación de uso general e información de ayuda asociada . . . . . . . . . . . . . 355
Marcas registradas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Glosario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Índice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
viii Introducción a DB2 para z/OS

Acerca de esta información
Esta información proporciona una amplia introducción a IBM DB2 para z/OS.
Explica los conceptos básicos que se asocian en general a los sistemas de gestión
de bases de datos relacionales y, en concreto, a DB2 para z/OS.
Después de leer esta información, el usuario adquiere una comprensión de los

conceptos básicos sobre DB2.
Esta información asume que el subsistema de DB2 se está ejecutando en la versión

9.1, en la modalidad de nueva función. En general, las funciones nuevas descritas,
incluendo cambios en las funciones existentes, sentencias y límtes, solo están
disponibles en la modalidad de nuevas fuciones. Hay dos nuevas excepciones a
esta sentencia general y mejoras de la optimización y programas de utilidad
modificados, que también están disponibles en la modalidad de conversión, salvo
que se especifique lo contrario.
A quién va dirigido este manual

Si no conoce DB2 para z/OS, esta información va dirigida a usted.
Quizás ha trabajado con DB2 en otros sistemas operativos (Windows, Linux, AIX,
iSeries, VM o VSE). Quizás ha trabajado en sistemas de gestión de bases de datos
(DBMS) no IBM o en el DBMS jerárquico de IBM, denominado Information
Management System (IMS). Quizás nunca ha trabajado con DBMS, pero desea
trabajar con este producto, que muchas empresas utilizan para datos de tareas
críticas y programas de aplicaciones. Independientemente de sus conocimientos, si
desea aprender sobre DB2 para z/OS, esta información puede resultarle útil.
Si va a trabajar con DB2 para z/OS y ya conoce la tarea específica que va a

realizar, empiece por leer los tres primeros capítulos. A continuación, puede
considerar cuál será su rol al elegir la lectura de todos los capítulos restantes o de
algunos de ellos. Por ejemplo, supongamos que sabe que será un administrador de
bases de datos (DBA) para una organización que tiene algunas aplicaciones
distribuidas y empieza a planificar para ser un negocio bajo demanda. En este caso
probablemente decidirá leer los capítulos sobre diseño de objetos y datos,
implementación del diseño de base de datos, DB2 y la Web, y acceso a datos
distribuidos.
Esta información se ha escrito suponiendo que la mayoría de lectores son

profesionales del proceso de datos.
Conjunto de programas de utilidad de DB2

Importante: En esta versión de DB2 para z/OS, el conjunto de programas de
utilidad de DB2 está disponible como producto opcional. Debe solicitar y adquirir
por separado una licencia para dichos programas de utilidad, y cuando en esta
publicación se habla de las funciones de estos programas de utilidad no implica
que tenga una licencia sobre los mismos.
El conjunto de programas de utilidad de DB2 se ha diseñado para trabajar con el

programa DFSORT, para el que dispone de licencia de uso en soporte de
© Copyright IBM Corp. 2001, 2008 ix

programas de utilidad de DB2 incluso aunque no disponga de licencia de DFSORT
para uso general. Si el principal producto de clasificación no es DFSORT, no olvide
leer los APAR informativo de lectura obligada:
v II14047/II14213: USE OF DFSORT BY DB2 UTILITIES
v II13495: HOW DFSORT TAKES ADVANTAGE OF 64-BIT REAL
ARCHITECTURE
Estos APAR informativos se actualizan periódicamente.
Información relacionada
Empaquetado de los programas de utilidad de DB2 (Guía de utilidad)
Terminología y referencias
En esta información, se hace referencia a DB2 Versión 9.1 para z/OS como ″DB2
for z/OS.″ En los casos en que el contexto ofrece un significado claro, se hace
referencia a DB2 for z/OS como ″DB2.″ Cuando esta información se refiere a
títulos de publicaciones DB2 for z/OS, se utiliza un título abreviado. (Por ejemplo,
″Consulte DB2 SQL Reference″ es una referencia a la publicación IBM DB2 Version
9.1 for z/OS SQL Reference.)
Cuando se hace referencia a un producto de DB2 distinto a DB2 for z/OS, en esta
información se utiliza el nombre completo del producto para evitar ambigüedades.
Los términos siguientes se utilizan de la forma indicada:

DB2 Representa el programa bajo licencia DB2 o un subsistema concreto de
DB2.
OMEGAMON
Consulte cualquiera de los productos siguientes:
v IBM Tivoli OMEGAMON XE for DB2 Performance Expert on z/OS
v IBM Tivoli OMEGAMON XE for DB2 Performance Monitor on z/OS
v IBM DB2 Performance Expert for Multiplatforms and Workgroups
v IBM DB2 Buffer Pool Analyzer for z/OS
C, C++ y lenguaje C
Representa el lenguaje de programación C o C++.
| CICS Representa CICS Transaction Server para z/OS.
IMS Representa el Gestor de bases de datos IMS o el Gestor de transacciones
IMS.
MVS Representa el elemento MVS del sistema operativo z/OS, que equivale al
componente Programa de control base (BCP - Base Control Program) del
sistema operativo z/OS.
RACF Representa las funciones que proporciona el componente RACF del
Servidor de seguridad de z/OS.
Características de accesibilidad para DB2 Version 9.1 for z/OS

Las características de accesibilidad ayudan al usuario con incapacidades físicas,
como por ejemplo movilidad restringida o visión limitada, a utilizar
satisfactoriamente productos de tecnología de la información.
x Introducción a DB2 para z/OS

Características de accesibilidad
La lista siguiente incluye las principales características de accesibilidad en

productos z/OS, incluyendo DB2 Version 9.1 for z/OS. Estas características dan
soporte a lo siguiente:
v Utilización solamente mediante el teclado.
v Interfaces utilizadas habitualmente por lectores de pantalla y amplificadores de
pantalla.
v Personalización de atributos de visualización como color, contraste y tamaño de
font
Consejo: Centro de información de Information Management Software for z/OS

Solutions (que incluye información para DB2 Version 9.1 for z/OS) y sus
publicaciones relacionadas están habilitadas para la accesibilidad para IBM Home
Page Reader. Puede utilizar todas las características utilizando el teclado en lugar
del ratón.
Navegación mediante el teclado
Puede acceder a las funciones de los paneles de ISPF de DB2 Version 9.1 for z/OS
utilizando un teclado o atajos de teclado.
Para obtener información sobre la navegación por los paneles de ISPF de DB2
Version 9.1 for z/OS utilizando TSO/E o ISPF, consulte el manual z/OS TSO/E
Primer, z/OS TSO/E User’s Guide y z/OS ISPF User’s Guide. Estas guías describen
cómo navegar por cada una de estas interfaces, incluyendo la utilización de atajos
de teclado o teclas de función (teclas PF). Esta guía incluye los valores por omisión
para las teclas PF y explica cómo modificar estas funciones.
Información relacionada con la accesibilidad
Hay disponible documentación en línea para DB2 Version 9.1 for z/OS en el
Centro de información de Information Management Software for z/OS Solutions,
en el siguiente sitio web: http://publib.boulder.ibm.com/infocenter/dzichelp
IBM y accesibilidad
Consulte IBM Accessibility Center en http://www.ibm.com/able para obtener más

información acerca del compromiso que IBM tiene con la accesibilidad.
Cómo enviar comentarios

Sus comentarios ayudan a IBM a ofrecer información de calidad. Le agradeceremos
que envíe sus comentarios sobre esta publicación y otro tipo de documentación de
DB2 for z/OS. Puede utilizar los métodos siguientes para hacernos llegar sus
comentarios:
v Envíe sus comentarios por correo electrónico a db2zinfo@us.ibm.com e incluya el
nombre del producto, el número de la versión del producto y el número de la
publicación. Si va a comentar un texto específico, indique la ubicación del texto
(por ejemplo, un capítulo y el título del apartado o un título del tema de ayuda).
v Puede enviar los comentarios desde la web. Visite el sitio web DB2 for z/OS -
Recursos técnicos en:
http://www.ibm.com/support/docview.wss?&uid=swg27011656
Acerca de esta información xi

Este sitio web tiene un formulario de comentarios del lector en línea que puede
utilizar para enviar sus comentarios.
v También puede enviar sus comentarios utilizando el enlace de comentarios que
encontrará en el pie de cada página en el Centro de información de Information
Management Software for z/OS Solutions en el siguiente sitio web
http://publib.boulder.ibm.com/infocenter/db2zhelp.
xii Introducción a DB2 para z/OS

Capítulo 1. Visión general de DB2 y gestión de información
Si no tiene experiencia en DB2 for z/OS o desea saber más sobre éste, esta
información le proporcionará la información básica que necesita conocer. (Esta
información a veces utiliza el nombre abreviado de DB2 cuando el contexto hace
que el significado sea claro.)
Una buena forma de empezar a aprender sobre un producto de software es

observar cómo lo utilizan organizaciones reales. En el caso de DB2, miles de
empresas de todo el mundo utilizan este sistema de gestión de bases de datos para
realizar sus negocios. Incluso observar un pequeño porcentaje de estas empresas
puede resultar poco práctico. Los casos de ejemplo pueden ayudarle a imaginar
algunas de las posibilidades mediante la descripción de unos cuantas formas en
que las organizaciones dependen de DB2 para conseguir sus objetivos
empresariales.
Además de comprender cómo las organizaciones dependen de DB2 para conseguir

sus objetivos empresariales, también necesita comprender la estrategia global de
IBM para ayudar a sus clientes a gestionar datos empresariales de forma eficaz.
También necesita comprender cómo funciona DB2 con una amplia variedad de
sistemas operativos.
Casos de ejemplo para utilizar DB2

Esta información proporciona casos de ejemplo que ilustran cómo algunas
organizaciones pueden utilizar satisfactoriamente DB2.
¿Qué tienen en común las siguientes situaciones?

| v Un banco internacional que proporciona servicios ininterrumpidos a sus clientes
| 24 horas al día.
v Un sistema de universitario de varios campus que educa a miles de estudiantes
y ofrece cientos de cursos.
v Una compañía de electricidad que proporciona electricidad a una extensa región
geográfica.
La característica común en cada situación es que DB2 es un componente clave en el
entorno de proceso de datos de cada organización.
| Si es nuevo en DB2, quizás se pregunte cómo estas y otras organizaciones utilizan

| el producto. Quizás se pregunte qué tipos de organizaciones utilizan DB2. Es
| posible que se pregunte si las organizaciones que utilizan DB2 tienen la totalidad,
| o sólo una parte, de sus datos en el servidor de la empresa. (A veces, se hace
| referencia al servidor de la empresa como ″sistema principal.″) Quizás se pregunte
| por qué las organizaciones siguen colocando sus principales datos empresariales en
| el sistema principal.
Disponibilidad y escalabilidad para empresas grandes

Las empresas grandes eligen DB2 for z/OS debido a que necesitan un servidor de
bases de datos eficaz que asegure una disponibilidad y escalabilidad superiores.
© Copyright IBM Corp. 2001, 2008 1

Quizás piense que los términos “servidor empresarial” y “sistema principal”
implican que empresas muy grandes utilizan un producto como DB2 for z/OS.
Puede preguntarse: “¿Por qué las empresas grandes eligen DB2 for z/OS?” La
respuesta es “Porque estas empresas necesitan un servidor de bases de datos eficaz
que asegure una disponibilidad y escalabilidad superiores.”
Una disponibilidad y escalabilidad superiores en un entorno Sysplex paralelo son

las características clave que distinguen DB2 for z/OS de otros servidores de bases
de datos. Debido a estas cualidades, DB2 for z/OS está ampliamente desplegado
en industrias que incluyen:
v Las principales compañías de tarjetas de crédito
v Bancos
v Compañías de seguros
v Compañías de correduría
v Compañías de información de créditos
Son empresas que procesan volúmenes muy grandes de transacciones que

requieren millones de actualizaciones simultáneas cada día.
Considere algunos ejemplos.

v El volumen de operaciones que se produce en las principales bolsas puede
alcanzar mil millones de acciones en un solo día.
v Una compañía de correduría puede tener una red de miles de consejeros
financieros y cientos de miles de clientes que diariamente necesitan acceder en
línea a información financiera altamente sensible.
| v Una compañía de transportes puede entregar más de 10 millones de paquetes en
| un solo día. Cada paquete requiere varios pasos dentro del proceso de entrega
| como, por ejemplo, la recogida, los puntos de tránsito y la entrega final. El
| estado del paquete se puede mostrar a los clientes en la web.
| v Una compañía de información de créditos necesita proporcionar un millón de
| informes sobre créditos cada día, a la vez que necesita mantener los datos al día
| con más de 100 millones de actualizaciones en un solo día.
Resulta fácil comprender por qué estas empresas necesitan que el sistema de bases
de datos que procesa estas transacciones sea continuamente disponible, escalable y
seguro. Estos sistemas empresariales deben estar disponibles para los clientes que
buscan y confían en sus servicios 24 horas al día.
v Los sistemas deben proporcionar una disponibilidad continua.
Si espera que una transacción financiera se procese y la aplicación que ejecuta
dicha transacción de repente falla, puede perder la oportunidad de realizar un
negocio en la bolsa en un momento crítico. El objetivo clave de una alta
disponibilidad es asegurar que un sistema no tenga un único punto de anomalía.
v Los sistemas deben ser escalables.
A medida que las empresas crecen, el proceso de los datos también debe crecer.
Las acciones de las empresas como, por ejemplo, fusiones, adquisiciones y
servicios nuevos, o las nuevas regulaciones del gobierno, pueden acelerar la
rapidez con qué crecen las necesidades de proceso de datos de las empresas. A
medida que se produce un crecimiento rápido, las empresas necesitan un modo
para ajustar sus empresas de forma satisfactoria.
| Las empresas necesitan un sistema de bases de datos grande diseñado para
| absorber fácilmente las adiciones actuales de nuevos tipos de información y
| procesos de aplicaciones sin perjudicar el rendimiento ni la disponibilidad. Este
| sistema de bases de datos nunca debe imponer una restricción en el crecimiento.
2 Introducción a DB2 para z/OS

| A medida que las empresas añaden más capacidad informática, el sistema de
| bases de datos debe ampliarse de acuerdo con ello para asegurar que las
| empresas obtengan el beneficio completo de la capacidad añadida y que tengan
| acceso continuo a los datos.
Los casos de ejemplo siguientes describen cómo un banco internacional grande se

beneficia de estas capacidades de DB2 for z/OS para proporcionar a sus clientes la
calidad de servicio más alta.
Caso de ejemplo 1: Con frecuencia se producen fusiones de bancos. Cuando dos

bancos combinan operaciones, ¿cómo fusiona el banco recién formado las
aplicaciones no relacionadas?
El compartimiento de datos de DB2 for z/OS en un entorno Sysplex paralelo

proporciona la solución que el banco nuevo necesita para poder fusionar los dos
sistemas bancarios.
La tecnología de clúster Sysplex paralelo en DB2 es la respuesta a la disponibilidad

y escalabilidad. Sysplex paralelo es un clúster, o complejo, de sistemas z/OS que
funcionan juntos para manejar varias transacciones y aplicaciones. Esta tecnología
implementa un diseño de compartimiento de datos.
El diseño de compartimiento de datos de DB2 proporciona a las empresas la

capacidad de añadir nuevos subsistemas DB2 a un grupo de compartimiento de
datos, o clúster, cuando es necesario y sin ninguna interrupción. Dado que las
aplicaciones se ejecutan en más de un subsistema DB2, pueden leer del mismo
conjunto de datos compartidos o escribir en él simultáneamente.
| Sysplex paralelo puede crecer incrementalmente sin perjudicar el rendimiento. La

| arquitectura de Sysplex paralelo está diseñada para integrar un máximo de 32
| sistemas en un clúster. En un clúster de disco compartido, cada sistema es
| miembro del clúster y tiene acceso a los datos compartidos.
| Un componente integral de Sysplex paralelo es el recurso de acoplamiento, un

| mecanismo que coordina las transacciones entre los distintos miembros de un
| clúster. Otras soluciones intentan implementar posibilidades similares mediante
| software, pero la mensajería utilizando software puede causar una mayor
| sobrecarga y afectar directamente la capacidad de escalabilidad y ejecución.
Cuando se utiliza la tecnología de Sysplex paralelo, las aplicaciones de cada banco

pueden integrarse fácilmente en un grupo de compartimiento de datos y pueden
acceder a los datos compartidos.
Caso de ejemplo 2: El banco ejecuta trabajos por lotes cada noche y la carga de
trabajo en línea se ejecuta cerca de 24 horas al día. ¿Cómo puede ejecutar el banco
cargas de trabajo variadas, mantenerlas equilibradas y evitar problemas en las
horas punta?
| DB2 trabaja estrechamente con el componente z/OS Workload Manager (WLM).

| WLM proporciona el mejor modo de ejecutar cargas de trabajo mixtas
| simultáneamente y el compartimiento de datos proporciona al banco mucha
| flexibilidad en el modo de ejecutar las cargas de trabajo.
La tecnología de Sysplex paralelo está diseñada para manejar eficazmente cargas

de trabajo variadas e imprevisibles. Workload Manager asegura que las cargas de
trabajo del banco estén óptimamente equilibradas entre los sistemas de Sysplex.
Capítulo 1. Visión general de DB2 y gestión de información 3

Por ejemplo, cuando el banco añade un nuevo subsistema o la carga de trabajo se
desequilibra, no es necesario volver a distribuir los datos. El nuevo subsistema
tiene el mismo acceso directo a los datos que todos los subsistemas existentes en el
grupo de compartimiento de datos.
El compartimiento de datos funciona con WLM para proporcionar al banco la

flexibilidad que necesita para manejar fácilmente cargas en periodos de mayor
actividad. WLM proporciona la capacidad de iniciar servidores y subsistemas bajo
demanda basándose en objetivos de servicios predefinidos. Por ejemplo, el banco
puede iniciar miembros del compartimiento de datos para manejar cargas en
periodos de mayor actividad en el proceso de final de trimestre y detenerlos
cuando finalice el período de mayor actividad de final de trimestre.
| DB2 es el único servidor de datos en System z10 para sacar el máximo partido a
| las posibilidades de WLM.
Caso de ejemplo 3: El banco crea un sitio web para proporcionar a sus clientes
servicios bancarios en línea 24 horas al día. En este caso DBMS no puede estar
nunca fuera de servicio a causa de actividades de mantenimiento. ¿Cómo puede el
banco aplicar mantenimiento a su DBMS si tiene que estar operativo 24 horas al
día?
El compartimiento de datos y la tecnología Sysplex paralelo proporcionan al banco

una forma de aplicar mantenimiento de software (interrupción planificada) a la vez
que se mantiene siempre un subconjunto de sus subsistemas DB2 activo y en
ejecución.
El entorno Sysplex paralelo proporciona varias vías de acceso a los datos y crea
redundancia en el recurso de acoplamiento para evitar un único punto de
anomalía. Con la tecnología de Sysplex paralelo, el banco puede añadir
mantenimiento a un miembro a la vez mientras sus sistemas siguen ejecutándose y
permanecen actualizados en servicio. Esta tecnología también permite al banco
migrar a un nuevo release de software al aplicar el nuevo release a un miembro a
la vez. Con este diseño, el banco evita interrupciones.
En caso de que se produzca una anomalía de aplicación o sistema en un sistema

(interrupción no planificada), Workload Manager asegura que los otros sistemas de
Sysplex puedan tomar el relevo de la carga de trabajo completa. De nuevo, el
banco evita interrupciones.
Conceptos relacionados
“DB2 en un entorno Sysplex paralelo” en la página 63
Capítulo 12, “Compartimiento de datos con los datos de DB2”, en la página 321
Información empresarial crítica para los encargados de tomar

decisiones
La mayoría de organizaciones utilizan diversos productos de hardware y software
para almacenar una gran cantidad de datos. Los encargados de tomar decisiones
clave necesitan un acceso oportuno a la información que necesitan para tomar
decisiones empresariales críticas.
Considere un sistema universitario con varios campus. Un grupo de expertos en

educación gestiona el sistema día a día. Estas personas toman decisiones que
afectan a todos los campus universitarios. Los encargados de tomar decisiones

utilizan un depósito de datos para poder ″extraer″ datos de las numerosas bases de
datos del sistema y tomar las mejores decisiones para la organización.
Quizás ha oído hablar los términos depósito de datos y minería de datos. Puede
imaginar un depósito de datos como un sistema que proporciona información
empresarial crítica a una organización. Minería de datos es la acción de recopilar
información empresarial crítica del depósito de datos, correlacionarla y descubrir
asociaciones, patrones y tendencias. El sistema de depósito de datos depura los
datos para que sean exactos y actuales. El sistema de depósito de datos también
presenta los datos a los encargados de tomar decisiones para que puedan
interpretarlos y utilizarlos de forma efectiva y eficiente.
Depósito de datos y minería de datos son términos relacionados que incluye el

término más global inteligencia empresarial.
La mayoría de organizaciones utilizan diversos productos de hardware y software

para almacenar una gran cantidad de datos. Sin embargo, los encargados de tomar
decisiones clave de muchas empresas no tienen el acceso oportuno a la
información que necesitan para tomar decisiones empresariales críticas. Si tuvieran
la información, podrían tomar decisiones más inteligentes para sus empresas; de
aquí viene el término inteligencia empresarial.
| El sistema de depósito de datos de la universidad, que se basa en DB2, transforma

| la enorme cantidad de datos operativos en informativos. Un ejemplo de datos
| operativos en una universidad son las identidades de las personas que se inscriben
| en las distintas clases. Obviamente, la universidad necesita esta información para
| funcionar. Estos datos operativos se convierten en informativos cuando, por
| ejemplo, los encargados de tomar decisiones descubren que la mayoría de
| estudiantes que se inscriben en Cálculo avanzado también se inscriben en Crítica
| musical. La universidad no necesita esta información para funcionar, pero los
| encargados de tomar decisiones pueden gestionar una institución más eficazmente
| si disponen de datos informativos. Como resultado de tener acceso a estos datos
| informativos, el personal universitario puede tomar unas decisiones más
| adecuadas. Las personas que planifican las clases pueden asegurar que estas clases
| no se impartan al mismo tiempo, permitiendo de este modo que los alumnos
| puedan inscribirse en ambas clases. La utilización de DB2 como depósito de datos
| empresariales asegura que se tomen decisiones empresariales clave basadas en los
| datos correctos.
La universidad también utiliza las posibilidades de Internet. Cada campus tiene un

sitio web, que proporciona la información pertinente a los encargados de tomar
decisiones en la universidad, a los alumnos, a los padres y a los miembros de las
comunidades que rodean cada campus.
| La utilización de DB2 for z/OS como servidor empresarial, la universidad puede

| realizar lo siguiente:
v Evaluar la eficacia de los currículums, los gastos, los profesores y el desarrollo
profesional
v Identificar las tendencias emergentes suficientemente pronto para una acción
eficaz
v Completar aplicaciones para otorgar de una forma más rápida y eficaz
v Compilar un informe de resumen completo sobre cualquier alumno individual
v Permitir que los usuarios finales autorizados utilicen la web para realizar
cualquiera de estas acciones, además de otras

Distribución de datos y acceso de web
La capacidad de distribuir datos y proporcionar acceso de web a dichos datos es
vital para los proveedores de servicios y sus clientes.
Una compañía de electricidad proporciona electricidad a una extensa región

geográfica. Trabajando desde una única oficina, los representantes de servicios de
cliente de la empresa responden a las llamadas de los clientes y someten peticiones
de servicios. La compañía de electricidad tiene cientos de representantes del campo
que proporcionan servicios en las ubicaciones de los clientes. Los representantes
del campo trabajan desde numerosas oficinas locales y necesitan acceder a las
peticiones de servicios de cliente que la oficina central recibe.
Los representantes de servicios de cliente documentan las peticiones de los clientes

en sus estaciones de trabajo, que disponen de DB2 Connect Personal Edition. Esta
información se sube a DB2 for z/OS. A continuación, los representantes del campo
pueden utilizar aplicaciones de Java para acceder a la información de peticiones de
cliente en DB2 desde sus oficinas locales.
En este caso de ejemplo, en entorno distribuido de la compañía de electricidad se

basa en el recurso de datos distribuidos (DDF), que forma parte de DB2 for z/OS.
Las aplicaciones de DB2 pueden utilizar DDF para acceder a datos de otros sitios
de DB2 y a sistemas de bases de datos relacionales remotos que soporten
Distributed Relational Database Architecture (DRDA). DRDA es un estándar para
conectividad distribuida. Una organización denominada The Open Group ha
desarrollado el estándar, con la participación activa de varias empresas de la
industria, una de las cuales es IBM. Todos los servidores de datos de IBM DB2
soportan el estándar DRDA.
DDF también permite que las aplicaciones se ejecuten en un entorno remoto que
soporte DRDA. Estas aplicaciones pueden utilizar DDF para acceder a los datos de
servidores de DB2. Entre los ejemplos de peticionarios de aplicaciones se incluyen
IBM DB2 Connect y otros productos cliente compatibles con DRDA.
“Recurso de datos distribuidos” en la página 62
Capítulo 10, “DB2 y la web”, en la página 297
Estrategia de gestión de información de IBM

La estrategia de información de IBM está formada por tres componentes básicos
que le permiten capturar datos, integrar y analizar datos, y gestionar todos los
tipos de contenido empresarial.
La gestión de información de DB2 es una capacidad esencial para IBM. Por lo

tanto, IBM dispone de una organización amplia de varios sitios dedicada a
ayudarle a gestionar los datos y a mejorar la información empresarial. La estrategia
de gestión de información de IBM ha evolucionado con el tiempo a medida que los
avances tecnológicos y las necesidades de los clientes de IBM han ido cambiado.
Uno de los principales cambios recientes en la industria es la introducción del

negocio bajo demanda. Negocio bajo demanda es la integración de procesos
empresariales (de un extremo a otro de la empresa, con business partners,
proveedores y clientes) que permite que una empresa pueda responder con rapidez
a las demandas de los clientes y mercados. La estrategia de gestión de información
de IBM reconoce y soporta completamente la necesidad de las empresas de pasar
al mundo del negocio bajo demanda.

La estrategia de gestión de información de IBM consta de tres componentes
básicos:
Captura de datos.
Para mejorar los datos empresariales, primero es necesario capturar los
datos necesarios.
Integración y análisis de datos.
A continuación, debe integrar y analizar los datos que ha capturado para
poder obtener una comprensión valiosa para las operaciones y los
componentes. Los componentes incluyen clientes, empleados, proveedores,
business partners y miembros de la comunidad.
Gestión de todos los tipos de contenido empresarial.
Por último, puede beneficiarse de la extensión y profundidad de las
soluciones de Gestión de información de IBM gestionando todas las formas
de contenido empresarial como, por ejemplo, información de la web y
documentos grandes.
| La figura siguiente muestra DB2 en la base de otros segmentos de la estrategia.

| DB2 se ejecuta en muchos sistemas operativos como, por ejemplo, z/OS, i5/OS,
| Linux, UNIX, Windows y Solaris, como se puede ver en la parte inferior de la
| figura. Alrededor de los sistemas de gestión de información existe una estructura
| que incluye herramientas para análisis, réplica de datos, gestión de depósitos,
| gestión de contenido e integración de información. Como complemento de las
| herramientas existen tecnologías de base de datos clave, como XML, SOA
| (Arquitectura orientada a servicios) y servicios web, y grupos de comunidades de
| desarrolladores con los que trabaja IBM para completar las soluciones
| empresariales. Estas comunidades de desarrolladores incluyen PL\I, C, C++, Java y
| .NET, además de comunidades de código abierto (open source) para PHP, Perl,
| Python y Ruby on Rails.

Figura 1. Estrategia de gestión de información de IBM DB2
El lado izquierdo de la figura muestra los servicios de información empresarial que

satisfacen las principales necesidades empresariales de la organización como, por
ejemplo, Master Data Management y Entity Analytics. Además de estos productos
de IBM, la organización puede adquirir aplicaciones de varios proveedores de
software independientes.
En el lado izquierdo de la figura también puede ver el segmento de gestión

empresarial de la estrategia de gestión de información de IBM. Productos como
IBM DB2 y la colección de herramientas de Gestión de información ofrecen a las
organizaciones una amplia gama de herramientas para todo desde la gestión de
bases de datos hasta el análisis del rendimiento. El Centro de control de DB2
también proporciona herramientas para la gestión del entorno. Además, muchos
productos de IBM ofrecen soporte de herramientas de Tivoli, lo cual ayuda a las
organizaciones a gestionar información empresarial.
El fondo de la parte central de la figura demuestra el objetivo de la estrategia de

gestión de información: proporcionar una infraestructura de información que
avance al mismo paso que el desarrollo de aplicaciones que cambian rápidamente

y que la gestión de información para un negocio bajo demanda integrado. Hoy en
día, las aplicaciones necesitan más que nunca trabajar con una diversidad más
amplia de datos.
| Además de fuentes de aplicaciones tradicionales, las empresas necesitan integrar

| fuentes como XML, documentos de texto, imágenes escaneadas, contenido web y
| correo electrónico. La tecnología de integración de información proporciona un
| acceso rápido a datos diversos y distribuidos. La utilización de tecnologías
| innovadoras y emergentes, que incluyen tecnología de federación, réplica, ETL y
| XML, ayuda a que las empresas mejoren la información para seguir siendo
| competitivas. La tecnología de federación proporciona acceso a todas las formas de
| fuentes de datos diversas y distribuidas. La réplica de datos permite renovar datos
| en múltiples fuentes y destinos de datos relacionales y no relacionales, que se
| ejecutan en sistemas de IBM y de muchos otros proveedores. Puede utilizar réplica
| de datos cuando necesite una carga de trabajo de alto rendimiento y tiempos de
| respuesta inmediatos. El soporte de XML se está integrando en el motor de DB2 y
| está disponible en herramientas de WebSphere Studio.
Los segmentos de la parte central de la figura representan tres componentes clave

de la estrategia de gestión de información de IBM:
Gestión de contenido
La variedad y volumen actual de contenido digital están llevando a las
empresas más avanzadas a centrarse en la gestión de su contenido
electrónico. Para dar soporte a un servicio de cliente mejor, más rápido y
más útil y para agilizar los procesos internos, las empresas deben potenciar
todo el contenido pertinente. IBM Content Manager es un almacén de
datos entre plataformas muy sólido para todo tipo de contenido como, por
ejemplo, imágenes, salida del sistema, documentos y soporte enriquecido.
Almacén de datos es un término genérico para un lugar (por ejemplo, un
sistema de bases de datos, archivo o directorio) donde se guardan datos.
IBM Content Manager permite la integración rápida de contenido en
procesos de actividad principal.
| Análisis
| Las personas que toman decisiones en las organizaciones necesitan poder
| obtener respuestas a preguntas que requieren un análisis multidimensional.
| Las herramientas de análisis que IBM ofrece son las Herramientas de DB2
| e IMS, Query Management Facility (QMF) y DB2 Alphablox. QMF es una
| herramienta de consulta e informe bien integrada, eficaz y de confianza
| establecida para los DBMS de bases de datos de DB2. DB2 Alphablox
| proporciona la capacidad de crear de forma rápida aplicaciones analíticas
| basadas en la web y personalizadas.
| Gestión de depósitos
| Las organizaciones dependen de sus depósitos de datos para acceder a
| información empresarial crítica. El software de inteligencia empresarial que
| IBM proporciona da soporte a este segmento de la estrategia de gestión de
| información. Estos productos, tales como WebSphere DataStage, amplían la
| escalabilidad, la capacidad de gestión y la accesibilidad del depósito de
| DB2.
| IBM da mucha importancia a las relaciones con sus business partners, tales como
| SAP. Esta compañía, y otras similares, desarrollan y dan soporte a aplicaciones
| principales para sus clientes. Estas aplicaciones proporcionan funciones
| empresariales vitales como, por ejemplo, Gestión de relaciones con los clientes y
| Gestión de la cadena de suministro.

Capítulo 10, “DB2 y la web”, en la página 297
“Herramientas de gestión de información” en la página 14
“Utilización de DB2 Query Management Facility para Workstation” en la
página 123
Servidores de datos y entornos de DB2

Los productos de servidor de datos de DB2 se ejecutan en un amplio conjunto de
sistemas operativos, que incluyen Linux, UNIX, Windows, i5/OS y z/OS. Esta
información básicamente es una introducción al producto DB2 for z/OS.
| Además de aprender sobre DB2 for z/OS, también deseará tener información sobre
| algunos de los productos que trabajan con DB2 para z/OS. Probablemente su
| empresa utiliza algunos de estos otros productos.
| Los servidores de datos DB2 incluyen soporte para los siguientes productos:
v DB2 for z/OS
v DB2 para i5/OS
v DB2 Database para Linux, UNIX y Windows
v DB2 para Linux en IBM System z10
Recomendación: Descargue versiones de demostración gratis o de prueba de

muchos productos y herramientas de DB2. Utilizando código de demostración
puede aumentar la comprensión de los distintos productos sobre los que leerá en
esta información. Para descargar copias de demostración, visite el sitio web de IBM
en http://www14.software.ibm.com/webapp/download/home.jsp. A
continuación, seleccione un producto de DB2 específico y elija la opción de
descarga en la página principal del producto.
| IBM ha desarrollado específicamente los servidores de datos de DB2 de modo que

| el código subyacente de cada DBMS pueda explotar las posibilidades individuales
| de los distintos sistemas operativos.
| Los productos de servidor de datos de DB2 incluyen las características siguientes:

v Los tipos de datos entre los servidores de datos de DB2 son compatibles.
v Los estándares abiertos significan que muchos tipos diferentes de clientes
pueden acceder a los datos de los servidores de datos de DB2.
v Puede desarrollar aplicaciones con SQL que sean comunes entre servidores de
datos de DB2 y trasladar estas aplicaciones de un sistema operativo de DB2 a
otro con la mínima modificación. (Trasladar significa mover una aplicación de
un sistema operativo a otro.)
v Los servidores de datos de DB2 pueden soportar aplicaciones de cualquier
tamaño. Por ejemplo, imagine que la aplicación empieza con un número
reducido de usuarios y volúmenes reducidos de datos y transacciones, pero a
continuación crece de forma considerable. Debido a la compatibilidad entre
servidores de datos de DB2, la aplicación puede seguir funcionando eficazmente
al pasar a System z9.
v Generalmente se incorpora una función similar en cada servidor de datos de
DB2 con el tiempo.
v Existen herramientas disponibles para ayudarle a gestionar todos los servidores
de datos de DB2 de un modo similar.

Consejo: Busque una persona que esté familiarizada con el entorno I/S de la
empresa. Pida a esta persona que proporcione una lista de los productos que
probablemente va a utilizar. Puede que la empresa tan solo disponga de un
subconjunto de los productos que se mencionan en esta información. El
conocimiento de la información básica sobre el entorno de su empresa le ayudará a
saber qué temas le interesa más leer.
Servidores empresariales
Los servidores empresariales son los sistemas que gestionan los datos
empresariales principales de una empresa y dan soporte a aplicaciones
empresariales clave.
| DB2 for z/OS es el sistema operativo principal de la plataforma de hardware más

| robusta de IBM, IBM System z10. DB2 for z/OS sigue siendo el servidor de datos
| empresariales para System z10, ofreciendo la mayor disponibilidad y escalabilidad
| del sector. DB2 for z/OS da soporte a cientos de clientes y a millones de usuarios.
| Los siguientes productos de DB2 pueden actuar como servidores empresariales:
v DB2 for z/OS
v DB2 para i5/OS, que soporta aplicaciones en el entorno System i de rango
medio
v DB2 para VSE y VM, que soporta aplicaciones grandes en los entornos VSE y
VM
“z/Architecture y el sistema operativo z/OS” en la página 53
Ediciones distribuidas de DB2 Database

En el entorno de estación de trabajo de DB2 se ejecutan varias ediciones de DB2
Database.
v DB2 Enterprise Server Edition se ejecuta en un servidor de cualquier tamaño en
los entornos Linux, UNIX y Windows. Esta edición proporciona el fundamento
para las siguientes posibilidades:
– Proceso de transacciones
– Creación de depósitos de datos y soluciones basadas en la web
– Conectividad e integración para otras fuentes de datos empresariales de DB2
y para fuentes de datos de Informix
La característica DB2 Connect proporciona funcionalidad para acceder a datos
almacenados en sistemas de bases de datos de rango medio y servidores de
empresa como, por ejemplo, DB2 for z/OS y DB2 para i5/OS. Esta edición
admite clientes locales y remotos de DB2.
v DB2 Workgroup Server Edition se ha diseñado para un entorno empresarial
pequeño con un máximo de cuatro CPU. Estas ediciones admiten clientes locales
y remotos de DB2.
| v DB2 Personal Edition proporciona una base de datos de un único usuario para
| implementaciones de oficina remota o conectadas ocasionalmente. Puede utilizar
| esta edición para crear y gestionar bases de datos locales o como cliente de
| servidores de bases de datos de DB2 Enterprise Server Edition o Workgroup
| Server Edition. DB2 Personal Edition no acepta peticiones de clientes.
v IBM Database Enterprise Developer Edition le permite desarrollar y probar
aplicaciones que se ejecutan en un sistema operativo y acceder a bases de datos
en el mismo sistema operativo u otro diferente.

v DB2 Express Edition se ha diseñado para empresas de tamaño medio y
pequeño.
DB2 en servidores a escala más reducida

Además de los servidores empresariales, la mayoría de empresas dan soporte a
servidores a escala más reducida en redes de área local (LAN). Los servidores a
escala más reducida manejan aplicaciones importantes que no solicitan los recursos
disponibles en los servidores empresariales más grandes.
| DB2 se ejecuta en el sistema operativo Linux operating system, including Linux

| enSystem z10. La plataforma System z10 ofrece cuatro sistemas operativos en los
| que puede ejecutar productos de servidor de datos de DB2. Los cuatro sistemas
| operativos son z/OS, Linux, VM y VSE. Muchos clientes utilizan DB2 paraLinux
| en System z10 como servidor de aplicaciones, se conectan con DB2 para z/OS
| como servidor de datos, de modo que puedan aprovechar las ventajas de
| hipersockets para una comunicación rápida y segura.
Entornos personales, móviles y dominantes

DB2 está disponible en dispositivos muy pequeños diseñados para un uso
individual. Se pueden escribir programas que accedan a datos de DB2 desde el
propio escritorio, un ordenador portátil u ordenador de mano (PDA) mientras está
de viaje o trabaja en casa. Más adelante puede sincronizar estas bases de datos con
bases de datos corporativas de la empresa.
En entornos de estación de trabajo de escritorios y ordenadores portátiles, DB2

Personal Edition proporciona un motor de servidor de datos para un único
usuario. DB2 Personal Edition se adapta a sus necesidades si trabaja de forma
independiente y de vez en cuando trabaja conectado o móvil.
Para ordenadores de mano (PDA), DB2 Everyplace permite aplicaciones de bases

de datos ligeras en todo el sistema operativo Palm y en sistemas operativos
Windows CE, Embedded Linux, QNX Neutrino, Linux y Symbian EPOC. DB2
Everyplace está disponible en dos ediciones: Enterprise Edition y Database Edition.
Entornos de varias transacciones y aplicaciones

Para optimizar el rendimiento y el tiempo de respuesta, las organizaciones pueden
distribuir sus transacciones de aplicaciones y datos, y pueden ejecutar consultas de
base de datos en paralelo.
Un clúster es un complejo de máquinas que funcionan juntas para manejar diversas

transacciones y aplicaciones. Los siguientes productos de servidor de datos de DB2
utilizan tecnología de clúster:
v DB2 for z/OS
v DB2 para i5/OS, que se ejecuta en el entorno System i paralelo
| Los productos de servidor de datos de DB2 pueden funcionar en clústeres en los

| entornos siguientes:
v AIX
v HP-UX
v i5/OS
v Linux

v Solaris
v Windows (Windows XP, Windows 2000 y Windows NT)
v z/OS
DB2 y comunicación de redes

Los productos de servidor de datos de DB2 pueden comunicarse utilizando redes
de área amplia (WAN) y redes de área local (LAN).
WAN Una red de área amplia normalmente da soporte a servidores
empresariales como, por ejemplo, DB2 for z/OS; requiere Transmission
Control Protocol/Internet Protocol (TCP/IP) o Systems Network
Architecture (SNA).
| LAN Una red de área local normalmente da soporte a servidores más pequeños
| y requiere TCP/IP.
Clientes soportados por servidores de datos de DB2

Los servidores de datos de DB2 dan soporte a una amplia variedad de clientes.
| v AIX
| v HP-UX
| v Linux
| v Solaris
| v Windows (Windows XP, Windows 2000, Windows NT y Windows 98)
| v Navegadores web
| v APL2
| v Assembler
| v C
| v C++
| v C#
| v COBOL
| v Fortran
| v Java
| v Perl
| v PHP
| v PL/I
| v REXX
| v Ruby on Rails
| v Lenguaje de procedimiento de SQL
| v TOAD
| v Visual Basic .NET
Fuentes de datos
El acceso a datos heterogéneos es una ventaja muy útil para una organización que
tiene datos de diversas fuentes.
| DB2 Database para Linux, UNIX y Windows da soporte al acceso a distintas

| fuentes de datos con una única sentencia de SQL. Este soporte se denomina soporte
| de base de datos federada, proporcionado por productos de WebSphere Information
| Integration. Por ejemplo, con el soporte de base de datos federada, puede

| incorporar datos de una amplia variedad de fuentes de datos. La aplicación (y el
| desarrollador de aplicaciones) no necesita comprender dónde están los datos o las
| diferencias de SQL entre almacenes de datos diferentes. El soporte de datos
| federados incluye soporte para las siguientes fuentes de datos relacionales y no
| relacionales:
| v Todos los productos de servidor de datos de DB2
| v IMS
| v Informix
| v Oracle
| v Microsoft SQL Server, Microsoft Excel
| v Sybase
| v JDBC
| v Bases de datos con soporte de API JDBC
| v OLE DB
| v Teradata
| v EMC Documentum
Si también utiliza WebSphere Information Integrator, las aplicaciones que acceden a

los DBMS de DB2 pueden tener acceso de lectura-escritura a fuentes de datos
adicionales, servicios web y WebSphere Business Integration. El acceso a datos
heterogéneos o diferentes significa que las aplicaciones pueden conseguir más, con
menos código. La alternativa sería que los programadores escribieran varios
programas, cada uno de los cuales sea capaz de acceder a los datos de una de las
fuentes. A continuación, los programadores escribirían otro programa que
fusionaría los resultados.
Herramientas de gestión de información

Existen muchos productos y herramientas diferentes disponibles en el mercado
para ayudarle a gestionar el entorno DB2, independientemente de la plataforma
que utilice.
Los siguientes productos son especialmente útiles para personas que gestionan un
entorno DB2:
v Herramientas de DB2 e IMS
v Centro de control de DB2
Herramientas de IBM DB2 e IMS
Las herramientas de información de IBM ofrecen herramientas de DB2 para z/OS,

i5/OS, Linux, UNIX y Windows y herramientas para IMS, que es el DBMS
jerárquico que se ejecuta en el entorno z/OS.
Estas herramientas se clasifican en seis categorías diferentes con las siguientes

posibilidades:
Administración de bases de datos
Navegar hasta objetos de base de datos y realizar tareas de administración
de bases de datos en uno o más objeto a la vez. Esta categoría también
incluye herramientas que se utilizan para modificar, migrar y comparar
objetos del mismo sistema o de diferentes sistemas DB2.
Gestión de programas de utilidad
Gestionar sistemas DB2 con programas de utilidad de alto rendimiento y
automatización.

Gestión de rendimiento
Supervisar y ajustar sistemas y aplicaciones de DB2 para obtener un
rendimiento óptimo y un coste más bajo.
Gestión de recuperación
Examinar activos de recuperación y recuperar objetos de DB2 a un punto
en el tiempo en el caso de una interrupción del sistema o una anomalía de
la aplicación. Esta categoría también incluye herramientas para ayudarle a
gestionar activos de recuperación.
Gestión de réplicas
Propagar los cambios en los datos capturando y aplicando los cambios en
sistemas remotos a través de los servidores de datos de DB2.
Gestión de aplicaciones
Gestionar los cambios en aplicaciones de DB2 con el mínimo esfuerzo y
crear y desplegar aplicaciones en la empresa.
| La mayoría de herramientas de base de datos que dan soporte a DB2 for z/OS
| proporcionan una interfaz gráfica de usuario (GUI) y además contienen una
| interfaz ISPF (Interactive System Productivity Facility) que le permite realizar la
| mayoría de tareas de DB2 de forma interactiva. Con las interfaces ISPF integradas,
| puede moverse perfectamente de una herramienta a otra.
Con las herramientas de DB2 e IMS puede esperar lo siguiente:

v Soporte inmediato de nuevas versiones de DB2
v Entrega entre plataformas
v Interfaces coherentes
v Prueba detallada que se realiza en las mismas cargas de trabajo que los
productos de base de datos
Puede leer más sobre herramientas de gestión de información específicas a lo largo

de esta información.
Centro de control de DB2
| El Centro de control de DB2 es una herramienta de administración de bases de

| datos que puede utilizar para administrar entornos DB2, incluyendo DB2 for z/OS.
| El Centro de control de DB2 visualiza objetos de base de datos (como, por ejemplo,
| tablas) y las relaciones entre ellos. Mediante la utilización de la interfaz del Centro
| de control de DB2 puede gestionar servidores locales y remotos desde una única
| estación de trabajo. Desde el Centro de control, puede realizar operaciones en
| objetos de base de datos entre varios servidores de datos de DB2. También puede
| utilizar el Centro de control de DB2 para iniciar otras herramientas como, por
| ejemplo, el Centro de réplica.
″Herramientas de DB2″ en ibm.com
″Herramientas de IMS″ en ibm.com
Herramientas de desarrollo de aplicaciones

DB2 proporciona un conjunto de herramientas muy eficaces para el desarrollo de
aplicaciones. Los desarrolladores pueden utilizar estas herramientas para crear
procedimientos almacenados, aplicaciones de DB2 y aplicaciones que admiten
inteligencia empresarial y negocio bajo demanda.

WebSphere Studio Application Developer
WebSphere Studio Application Developer es un entorno de desarrollo Java

completamente integrado. Utilizando WebSphere Studio Application Developer
puede crear, compilar y probar aplicaciones J2EE (Java 2 Enterprise Edition) para
aplicaciones de negocio bajo demanda con:
v Archivos JSP (JavaServer Pages)
v Componentes EJB (Enterprise JavaBeans)
v Applets y servlets Java 100% puros
| WebSphere Developer for System z
| WebSphere Developer for System z puede mejorar la eficacia y proporciona ayuda

| mediante desarrollo de sistema principal, desarrollo web y carga de trabajo mixta
| integrada o desarrollo compuesto. Utilizando WebSphere Developer for System z9
| puede acelerar el desarrollo de aplicaciones web, aplicaciones COBOL y PL/I
| tradicionales, servicios web e interfaces basadas en XML.
| WebSphere Developer for System z proporciona un entorno de trabajo común y un

| conjunto de herramientas integradas que dan soporte a desarrollo de aplicaciones
| basado en un modelo, de extremo a extremo, prueba en tiempo de ejecución y
| despliegue rápido de aplicaciones bajo demanda. Con el entorno basado en
| estación de trabajo interactivo puede acceder de forma rápida a los datos de z/OS.
| Rational Application Developer for WebSphere Software
| El software de IBM Rational proporciona una serie completa de herramientas para

| satisfacer las necesidades de análisis, diseño y construcción, tanto si se trata de un
| desarrollador de software, un arquitecto de software, un ingeniero de sistemas o
| un diseñador de bases de datos. IBM Rational Application Developer for
| WebSphere Software ayuda a los desarrolladores a diseñar, desarrollar, analizar,
| probar, crear perfiles y desplegar con rapidez aplicaciones de portal, J2EE, Java,
| SOA (Service Oriented Architecture) y web de alta calidad.
| Utilizando Rational Application Developer puede aumentar la productividad,

| minimizar la trayectoria de aprendizaje y reducir los ciclos de desarrollo para
| poder desplegar aplicaciones de forma rápida.
DB2 Developer Workbench
| DB2 Developer Workbench es una herramienta que le ayuda a definir e

| implementar procedimientos almacenados y funciones definidas por el usuario.
| Utilizando esta herramienta puede crear procedimientos almacenados de Java y
| SQL para el entorno DB2 for z/OS o para otros servidores de datos de DB2. Puede
| iniciar DB2 Developer Workbench desde el Centro de control de DB2.
“Aplicaciones basadas en la web y WebSphere Studio Application Developer”
en la página 303
“Utilización de DB2 Developer Workbench para crear un procedimiento
almacenado” en la página 173

Componentes de middleware
Las interfaces de programación de aplicaciones (API) de middleware y de cliente
complementan los productos del servidor de datos de DB2. Las API de middleware
y de cliente ayudan a que los productos DB2 se comuniquen y trabajen
conjuntamente de una forma más eficaz.
Los componentes de middleware de IBM incluyen una amplia gama de productos

WebSphere que le ayudan a conseguir el objetivo de un negocio bajo demanda. La
familia de productos que incluye la gama de WebSphere proporciona todo el
software de infraestructura necesario para crear, desplegar e integrar el negocio
bajo demanda. Los productos WebSphere pertenecen a las siguientes categorías:
v Fundación y herramientas para el desarrollo y despliegue de aplicaciones
empresariales de alto rendimiento
v Portales empresariales para desarrollar portales empresariales escalables y
permitir un único punto de interacción personalizada con varios recursos
empresariales
v Integración empresarial para la integración global de aplicaciones
Los productos WebSphere se ejecutan en los sistemas operativos más populares,

incluidos z/OS, AIX, Linux, OS/390, i5/OS, Windows 2000, Windows NT y
Solaris.
DB2 Connect
DB2 Connect mejora la información de la empresa independientemente del lugar
donde está la información. DB2 Connect proporciona a las aplicaciones un acceso
rápido y fácil a las bases de datos existentes en servidores de empresas de IBM.
Las aplicaciones pueden ser aplicaciones empresariales bajo demanda u otras
aplicaciones que se ejecutan en sistemas operativos UNIX o Windows.
DB2 Connect ofrece varias ediciones que proporcionan conectividad con el sistema
principal y servidores de bases de datos de i5/OS. DB2 Connect Personal Edition
proporciona conectividad directa, mientras que DB2 Connect Enterprise Edition
proporciona conectividad indirecta mediante el servidor de DB2 Connect.
Con DB2 Connect, puede realizar las tareas siguientes:

v Ampliar el alcance de los datos empresariales proporcionando a los usuarios un
acceso rápido y seguro a los datos mediante intranets o mediante la Internet
pública
v Integrar las aplicaciones empresariales principales existentes en las aplicaciones
nuevas basadas en la web que se desarrollan
v Crear soluciones empresariales bajo demanda utilizando las numerosas
herramientas de programación de aplicaciones que se facilitan con DB2 Connect
v Crear aplicaciones de transacción distribuida
| v Desarrollar aplicaciones utilizando herramientas de programación de
| aplicaciones populares como, por ejemplo, Visual Studio .NET, ActiveX Data
| Objects (ADO), OLE DB y lenguajes populares como, por ejemplo, Java, PHP y
| Ruby on Rails
v Gestionar y proteger los datos
v Conservar la inversión actual en habilidades

Los usuarios de PC portátiles y de dispositivos de informática dominantes pueden
utilizar DB2 Connect para acceder a datos actualizados y de confianza desde
servidores de bases de datos de z/OS e i5/OS.
DB2 Connect proporciona el rendimiento, escalabilidad, fiabilidad y disponibilidad

necesarios para las aplicaciones más exigentes que utiliza su empresa. DB2 Connect
se ejecuta en AIX, HP-UX, Linux, Solaris, Windows XP, Windows Me, Windows
2000, Windows 98 y Windows NT.
WebSphere Application Server

WebSphere Application Server forma parte de la gama de Foundation & Tools
WebSphere. Este producto permite a las organizaciones pasar rápidamente de una
publicación web simple a un negocio bajo demanda seguro.
WebSphere Application Server es una plataforma basada en tecnología de servicios

web y Java 2 Enterprise Edition (J2EE). Con WebSphere Application Server puede
aprovechar las ventajas de los siguientes servicios:
v Servicios web para un desarrollo de aplicaciones más rápido.
v Servicios de aplicaciones dinámicas para gestionar el entorno de negocio bajo
demanda con soporte de servicios web y J2EE 1.3 que utiliza componentes
modulares estándar para simplificar las aplicaciones empresariales.
v Soporte de herramientas integradas con WebSphere Studio Application
Developer.
“SOA, XML y servicios web” en la página 307
WebSphere Studio
WebSphere Studio forma parte de la gama de Foundation & Tools WebSphere.
WebSphere Studio en realidad es una serie de herramientas que incluyen desarrollo
para la web, la empresa y los dispositivos inalámbricos.
La serie de herramientas de WebSphere Studio proporciona el soporte siguiente:

v Para desarrollo de aplicaciones: WebSphere Studio Application Developer
funciona con aplicaciones Java y J2EE y otras herramientas que incluyen
WebSphere Studio Enterprise Developer para el desarrollo de aplicaciones web y
J2EE avanzadas.
v Para conectividad de aplicaciones: WebSphere MQ es un sistema de gestión de
mensajes que permite a las aplicaciones comunicarse en un entorno distribuido
entre redes y sistemas operativos diferentes.
v Para desarrollo de webs: WebSphere Studio Homepage Builder es una
herramienta de creación para desarrolladores de webs nuevos y WebSphere
Studio Site Developer es para desarrolladores de webs con experiencia.
en la página 303
WebSphere Host Integration

WebSphere Host Integration forma parte de la gama de Foundation & Tools
WebSphere. WebSphere Host Integration proporciona soporte para aplicaciones
basadas en la web y en entornos de sistema principal.

WebSphere Host Integration en realidad es una gama de productos que ayuda a las
organizaciones a acceder, integrar y publicar información de sistema principal en
clientes y aplicaciones basados en la web.
Soporte de base de datos federada mediante WebSphere

Information Integrator
La familia de productos de WebSphere Information Integration es la parte clave de
la infraestructura de integración de información. Los componentes de los
productos incluyen un servidor de datos federado para integrar los diferentes tipos
de datos.
La tecnología de integración de información proporciona acceso a diferentes tipos

de datos distribuidos. Esta tecnología le permite integrar una amplia variedad de
datos, incluidos las fuentes de aplicaciones tradicionales además de XML,
documentos de texto, contenido web, correo electrónico e imágenes escaneadas.
Las siguientes tecnologías clave proporcionan integración de información:

| v Soporte para acceder a fuentes de datos XML
v Soporte de servicios web
v Tecnología de federación
v Características adicionales como, por ejemplo, búsqueda avanzada y réplica de
datos flexible
Los sistemas de bases de datos federadas de IBM ofrecen recursos de gran utilidad
para combinar información de varias fuentes de datos. Estos recursos le
proporcionan acceso de lectura y escritura a diversos datos de una amplia variedad
de fuentes y sistemas operativos como si los datos fueran un único recurso. Con
un sistema federado, puede:
v Conservar los datos donde residen en lugar de moverlos a un único almacén de
datos
v Utilizar una sola API para buscar, integrar y transformar datos como si
estuvieran en una única base de datos virtual
v Enviar peticiones distribuidas a varia fuentes de datos en una sola sentencia de
SQL
Por ejemplo, puede unir datos que residen en una tabla de DB2, una tabla de
Oracle y un archivo codificado XML.
El producto de IBM que da soporte a la federación de datos es WebSphere

Information Integrator.
Considere la federación como una estrategia de integración cuando los requisitos

técnicos del proyecto implican operaciones de búsqueda, inserción, actualización o
supresión en varias fuentes relacionadas heterogéneos o en destinos con formatos
diferentes. Durante la configuración de los sistemas federados, la información
sobre las fuentes de datos (por ejemplo, el número y el tipo de datos de columnas,
la existencia de un índice o el número de filas) es analizado por DB2 para formular
respuestas rápidas a consultas. La posibilidad de optimización de consultas de los
sistemas federados puede generar automáticamente un plan óptimo basado en
numerosos factores complejos de este entorno. Este plan generado de forma
automática hace que el desarrollo de aplicaciones en un sistema federado sea
mucho más fácil puesto que ya no es necesario que los desarrolladores determinen
las estrategias de ejecución del programa.

Réplica de datos mediante WebSphere Replication Server
WebSphere Replication Server para z/OS proporciona réplica de baja latencia y
alto volumen para casos de continuidad empresarial, distribución de carga de
trabajo o integración empresarial.
La réplica de datos es el proceso de mantenimiento de un conjunto definido de datos

en más de una ubicación. La réplica implica la copia de los cambios designados de
una ubicación (fuente) a otra ubicación (destino) y la sincronización de los datos en
ambas ubicaciones. La fuente y el destino pueden estar en servidores de la misma
máquina o en máquinas diferentes de la misma red.
| Puede utilizar WebSphere Replication Server como ayuda para mantener el

| depósito de datos y facilitar la inteligencia empresarial en tiempo real. WebSphere
| Replication Server proporciona la flexibilidad para distribuir, consolidar y
| sincronizar datos de muchas ubicaciones utilizando réplica diferencial o ETL.
| WebSphere DataStage
| IBM WebSphere DataStage proporciona la posibilidad de realizar operaciones de
| extracción, transformación y carga (ETL) desde varios orígenes en varios destinos,
| incluyendo DB2 for z/OS.
| Esta solución de ETL da soporte a recopilación, integración y transformación de

| volúmenes grandes de datos, con estructuras de datos que oscilan entre una
| complejidad simple y alta. WebSphere DataStage gestiona los datos que llegan en
| tiempo real y los datos recibidos de forma periódica o planificada.
| Las operaciones de ETL con WebSphere DataStage se basan en un registro y dan

| soporte a una amplia infraestructura de integración de datos. Puede realizar
| transformaciones más complejas y limpieza de datos, y puede fusionar datos de
| otras marcas de software de aplicaciones empresariales, incluidas SAP, Siebel y
| Oracle.
WebSphere QualityStage
IBM WebSphere QualityStage proporciona una solución de calidad de datos que
puede utilizarse para estandarizar hechos de cliente, ubicación y producto.
Puede utilizar WebSphere QualityStage para validar información de direcciones

globales y nombres internacionales y otros datos de clientes, incluyendo números
de teléfono, direcciones de correo electrónico y comentarios descriptivos para
descubrir relaciones. WebSphere QualityStage ofrece los datos de alta calidad
necesarios para triunfar dentro de una serie de iniciativas empresariales, entre las
que se incluye inteligencia empresarial, consolidación de herencia y gestión de
datos maestros.
Interfaces de programación de aplicaciones cliente

Las interfaces de programación de aplicaciones proporcionan varios métodos para
que los clientes accedan a un servidor de bases de datos de DB2.
Interfaces Java
DB2 proporciona dos interfaces de programación de aplicaciones (API) de

programación de Java basadas en estándares para escribir programas de
aplicaciones transportables que accedan a DB2:

JDBC Interfaz genérica para escribir aplicaciones independientes de la plataforma
que puedan acceder a cualquier base de datos de SQL.
SQLJ Otro modelo de SQL que un consorcio de los principales proveedores de
bases de datos ha desarrollado para complementar JDBC. ISO
(International Standards Organization) define SQLJ. SQLJ es más fácil de
codificar que JDBC y proporciona un mayor rendimiento, seguridad y
mantenimiento de SQL estático.
Con el soporte de DB2 for z/OS para JDBC se pueden escribir aplicaciones de SQL
dinámico en Java; con el soporte de SQLJ se pueden escribir aplicaciones de SQL
estático en Java. Estas aplicaciones Java pueden acceder a datos locales de DB2 o a
datos relacionales remotos de cualquier servidor con soporte de DRDA.
Con DB2 for z/OS se puede utilizar un procedimiento almacenado que esté escrito
en Java. (La familia de DB2 Database da soporte a procedimientos almacenados
escritos en numerosos lenguajes adicionales.) Un procedimiento almacenado es un
programa de aplicación escrito por el usuario que el servidor almacena y ejecuta.
Una única sentencia CALL de SQL invoca a un procedimiento almacenado. El
procedimiento almacenado contiene sentencias de SQL que se ejecutan localmente
en el servidor. El resultado puede ser una reducción significativa de transmisiones
en la red.
Se pueden desarrollar procedimientos almacenados de Java que contengan SQL

estático (utilizando SQLJ) o SQL dinámico (utilizando JDBC). El usuario puede
definir los procedimientos almacenados de Java o puede utilizar las herramientas
DB2 Developer Workbench y WebSphere Studio Application Developer.
ODBC
| DB2 Open Database Connectivity (ODBC) es la interfaz de SQL invocable de IBM

| para acceso a bases de datos relacionales. Se proporcionan funciones a los
| programas de aplicaciones para procesar sentencias de SQL dinámico. DB2 ODBC
| permite a los usuarios acceder a funciones de SQL directamente a través de una
| interfaz llamable. Mediante la interfaz, las aplicaciones utilizan llamadas de
| procedimiento durante el tiempo de ejecución para conectarse a bases de datos,
| emitir sentencias de SQL y obtener datos devueltos e información de estado. Los
| lenguajes de programación que dan soporte a ODBC son C y C++.
Servicios web
Los servicios web son aplicaciones modulares independientes que proporcionan

una interfaz entre el proveedor y el consumidor de recursos de aplicaciones de
negocio bajo demanda en Internet. Las aplicaciones cliente de servicios web
pueden acceder a una base de datos de DB2.
DB2 Database Add-Ins for Visual Studio 2005
| IBM DB2 Database Add-Ins for Microsoft Visual Studio 2005 es un conjunto de
| herramientas de administración y desarrollo de aplicaciones altamente integradas
| diseñadas para DB2 Database. Los Add-Ins (accesorios) se integran en el entorno
| de Visual Studio .NET para que los programadores de aplicaciones pueden trabajar
| con facilidad dentro de su entorno de desarrollo integrado (IDE) para acceder a
| datos de DB2.
Las características siguientes proporcionan ventajas clave:

v Soporte para aplicaciones cliente (aplicaciones de escritorio y basadas en la web)
para utilizar .NET para acceder a servidores remotos de DB2
v Una herramienta para crear procedimientos almacenados que facilita a cualquier
programador de aplicaciones el desarrollo y la prueba de procedimientos
almacenados con DB2 for z/OS sin necesidad de tener experiencia o un
conocimiento previo sobre System z10
“Utilización de Java para ejecutar SQL estático y dinámico” en la página 165
Capítulo 11, “Acceso a datos distribuidos”, en la página 309
“Utilización de un programa de aplicación como un procedimiento
“Lenguajes de programación y métodos para desarrollar programas de
aplicaciones” en la página 149
“Utilización de ODBC para ejecutar SQL dinámico” en la página 164
“SOA, XML y servicios web” en la página 307
“DB2 Development Add-In for Visual Studio .NET” en la página 148
Estándares abiertos
Los estándares abiertos proporcionan una infraestructura para negocios bajo
demanda ampliamente aceptada entre la industria informática. En estándares
abiertos, los clientes y proveedores pueden escribir programas de aplicaciones que
se pueden ejecutar en diferentes sistemas de bases de datos con muy poca o
ninguna modificación. La portabilidad de aplicaciones simplifica el desarrollo de
aplicaciones y finalmente reduce los costes de desarrollo.
| IBM es líder en el desarrollo de estándares industriales abiertos para sistemas de

| bases de datos. DB2 for z/OS se ha desarrollado basado en los siguientes
| estándares:
v Estándar SQL:2003 ANSI/ISO
| v Estándar técnico de The Open Group DRDA Versión 3
v Especificación JDBC API 3.0, desarrollada por Java Community Process

Capítulo 2. Conceptos de DB2
Muchos conceptos, estructuras y procesos están asociados a una base de datos
relacional. Los conceptos le proporcionan una comprensión básica de qué es una
base de datos relacional. Las estructuras son los componentes clave de una base de
datos de DB2 y los procesos son las interacciones que se producen cuando las
aplicaciones acceden a la base de datos.
En una base de datos relacional, se puede observar que los datos existen en una o
más tablas. Cada tabla contiene un número específico de columnas y un número de
filas sin ordenar. Cada columna de una tabla está relacionada de algún modo con
las otras columnas. Pensar en los datos como una colección de tablas hace que sea
más fácil visualizar los datos que se almacenan en una base de datos de DB2.
Las tablas están en el núcleo de una base de datos de DB2. Sin embargo, una base
de datos de DB2 implica algo más que una colección de tablas; una base de datos
de DB2 también implica otros objetos como, por ejemplo, vistas e índices, y
contenedores de datos más grandes como, por ejemplo, espacios de tablas.
Lenguaje de consulta estructurado

El lenguaje que utiliza para acceder a los datos de tablas de DB2 es el lenguaje de
consulta estructurado (SQL). SQL es un lenguaje estandarizado para definir y
manipular datos en una base de datos relacional.
| El lenguaje consta de sentencias de SQL. Las sentencias de SQL le permiten llevar

| a cabo las acciones siguientes:
v Definir, modificar o descartar objetos de datos como, por ejemplo, tablas.
v Recuperar, insertar, actualizar o suprimir datos en tablas.
Otras sentencias de SQL le permiten autorizar el acceso de los usuarios a recursos

específicos como, por ejemplo, tablas o vistas.
Cuando un usuario escribe una sentencia de SQL, especifica qué desea hacer, no
cómo hacerlo. Para acceder a datos, sólo necesita nombrar las tablas y columnas
que contienen los datos. No es necesario que describa cómo llegar a los datos.
De acuerdo con el modelo relacional de datos:

v La base de datos se percibe como un conjunto de tablas.
v Las relaciones se representan mediante valores de las tablas.
v Los datos se recuperan utilizando SQL para especificar una tabla de resultados que
puede proceder de una o más tablas.
DB2 transforma cada sentencia de SQL, es decir, la especificación de una tabla de

resultados, en una secuencia de operaciones que optimizan la recuperación de los
datos. Esta transformación se produce cuando se prepara la sentencia de SQL. Esta
transformación también se denomina vinculación.
Todas las sentencias de SQL ejecutables deben prepararse previamente para

poderse ejecutar. El resultado de la preparación es la forma operativa o ejecutable de
la sentencia.

Como ilustra el ejemplo siguiente, SQL normalmente es intuitivo.
Ejemplo: Suponga que va a comprarse unos zapatos y desea saber qué estilos de
zapatos están disponibles en el número 8. La consulta de SQL que debe escribir es
similar a la pregunta que le haría a un vendedor, ″¿Qué estilos de zapatos están
disponibles en el número 8?″ Del mismo modo que el vendedor comprueba el
inventario de zapatos y regresa con una respuesta, DB2 recupera información de
una tabla (SHOES) y devuelve una tabla de resultados. La consulta sería:
SELECT STYLE
FROM SHOES
WHERE SIZE = 8;
Suponga que la respuesta a su pregunta es que hay disponibles dos estilos de

zapatos en el número 8: mocasines y sandalias. La tabla de resultados es similar a
la siguiente:
STYLE
=======
LOAFERS
SANDALS
Puede enviar una sentencia de SQL a DB2 de varias formas. Una forma es
interactivamente, entrando sentencias de SQL en un teclado. Otra forma es
mediante un programa de aplicación. El programa puede contener sentencias de
SQL incluidas estáticamente en la aplicación. Como alternativa, el programa puede
crear sus propias sentencias de SQL dinámicamente, por ejemplo, en respuesta a la
información que un usuario proporciona al rellenar un formulario. En esta
información puede leer sobre estos dos métodos.
Capítulo 5, “SQL: lenguaje de DB2”, en la página 87
Capítulo 6, “Programación de aplicaciones para DB2”, en la página 147
Referencia relacionada
″DB2 for z/OS SQL Reference″
″DB2 Application Programming and SQL Guide″
Visión general de pureXML

pureXML es el soporte de DB2 for z/OS para XML. pureXML permite que las
aplicaciones cliente gestionen datos XML de tablas de DB2. Puede almacenar
documentos XML con el formato correcto en su forma jerárquica y recuperar todos
los documentos o parte de ellos.
Dado que los datos XML almacenados están completamente integrados en el

sistema de bases de datos de DB2, puede acceder y gestionar los datos XML
aprovechando las funciones y posibilidades de DB2.
Para gestionar eficazmente tipos de datos de SQL tradicionales y datos XML, DB2
utiliza dos mecanismos de almacenamiento diferentes. Sin embargo, el mecanismo
de almacenamiento subyacente que se utiliza para un tipo de datos determinado es
transparente para la aplicación. No es necesario que la aplicación especifique
explícitamente el mecanismo de almacenamiento que debe utilizarse o que gestione
el almacenamiento físico para objetos XML y no XML.
Almacenamiento de documentos XML
El tipo de datos de columna XML se proporciona para almacenar datos

XML en tablas de DB2. La mayoría de las sentencias de SQL dan soporte al
tipo de datos XML. Esto le permite realizar muchas operaciones comunes
de base de datos con datos XML, tales como la creación de tablas con
columnas XML, la adición de columnas XML a tablas existentes, la creación
de índices para columnas XML, la creación de desencadenantes en tablas
con columnas XML y la inserción, actualización o supresión de documentos
XML.
Como alternativa se proporciona un procedimiento almacenado de
descomposición para que pueda extraer elementos de datos de un
documento XML y almacenar estos elementos de datos en columnas de
tablas relacionales utilizando un esquema XML que tiene anotaciones con
instrucciones sobre cómo almacenar los elementos de datos.
Recuperación de documentos XML
Puede utilizar SQL para recuperar documentos enteros de columnas XML
de forma similar a cómo se recuperan datos de cualquier otro tipo de
columna. Cuando necesita recuperar partes de documentos, puede
especificar expresiones XPath mediante SQL con extensiones XML
(SQL/XML).
Desarrollo de aplicaciones
El soporte de desarrollo de aplicaciones de XML permite a las aplicaciones
combinar XML y almacenamiento y acceso a datos relacionales. Los
siguientes lenguajes de programación dan soporte al tipo de datos XML:
v Assembler
v C o C++ (SQL incorporado u ODBC de DB2)
v COBOL
v Java (JDBC o SQLJ)
v PL/I
Administración de bases de datos
El soporte de administración de bases de datos de DB2 for z/OS para
pureXML incluye los elementos siguientes:
Depósito de esquemas XML (XSR)
El depósito de esquemas XML (XSR) es un depósito para todos los
esquemas XML necesarios para validar y procesar documentos
| XML almacenados en columnas XML o descompuestos en tablas
| relacionales.
Soporte de programas de utilidad
Los programas de utilidad de DB2 for z/OS dan soporte al tipo de
datos XML. La estructura de almacenamiento para datos e índices
XML es similar a la estructura de almacenamiento para datos e
índices LOB. Al igual que los datos LOB, los datos XML no se
almacenan en el espacio de tablas base, sino que se almacenan en
espacios de tablas separados que contienen únicamente datos XML.
Los espacios de tablas XML también tienen sus propios espacios de
índice. Por lo tanto, las implicaciones de la utilización de
programas de utilidad para manipular, realizar copias de seguridad
y restaurar datos XML y datos LOB son similares.
Rendimiento
El soporte de indexación está disponible para datos almacenados en
columnas XML. La utilización de índices para datos XML puede mejorar la
eficacia de las consultas que el usuario emite para documentos XML. Un
índice XML se diferencia de un índice relacional en que un índice
Capítulo 2. Conceptos de DB2 25

relacional se aplica a una columna entera mientras que un índice XML se
aplica a una parte de los datos de una columna. Para indicar qué partes de
una columna XML están indexadas debe especificar un patrón XML, que es
una expresión XPath limitada.
Estructuras de datos de DB2

Las estructuras de datos son los elementos necesarios para utilizar DB2. Puede
acceder y utilizar estos elementos para organizar los datos. Entre los ejemplos de
estructuras de datos se incluyen tablas, espacios de tablas, índices, espacios de
índice, claves, vistas y bases de datos.
Las breves descripciones siguientes muestran cómo se organizan las estructuras en

una vista global de DB2. La figura siguiente muestra cómo las estructuras de DB2
contienen otras estructuras. Hasta cierto punto, la noción de “contención”
proporciona una jerarquía de estructuras.
Base de datos
Espacio de tabla no particionado
Tabla T1 Tabla T2
Espacio Espacio Grupo de almacenamiento G1

de índice de índice
Volumen 3
X1 X2 Volumen 2
Índice Índice
Volumen 1
Espacio Espacio
de tabla de índice
particionado
Tabla Índice de
Parte 1 part. Parte 1
Parte 2 Parte 2
Parte 3 Parte 3
Parte 4 Parte 4
Grupo de almacenamiento G2
Volumen
Volumen 3
2 Volumen
1
Figura 2. Jerarquía de estructuras de DB2
Las estructuras de DB2 desde las más inclusivas a las menos inclusivas son las
siguientes:
Bases de datos
Conjunto de estructuras de DB2 que incluyen una colección de tablas, sus
índices asociados y los espacios de tablas en los que residen.

Grupos de almacenamiento
Conjunto de volúmenes en discos que contienen los conjuntos de datos en
los que se almacenan realmente las tablas e índices.
Espacios de tablas
Conjunto de volúmenes en discos que contienen los conjuntos de datos en
los que se almacenan realmente las tablas e índices.
Tablas Todos los datos de una base de datos de DB2 se presentan en tablas, que
son colecciones de filas que tienen todas las mismas columnas. Una tabla
que contiene datos de usuario permanentes es una tabla base. Una tabla que
almacena datos temporalmente es una tabla temporal.
Vistas Una vista es una forma alternativa para representar datos que existen en
una o más tablas. Una vista puede incluir todas o algunas de las columnas
de una o más tablas base.
Índices
Un índice es un conjunto ordenado de punteros hacia los datos de una
tabla de DB2. El índice se almacena separadamente de la tabla.
“Objetos del sistema DB2” en la página 39
Tablas de DB2
Las tablas son estructuras lógicas mantenidas por DB2. DB2 da soporte a diferentes
tipos de tablas.
Las tablas están formadas por columnas y filas. Las filas de una tabla relacional no
tienen un orden fijo. Sin embargo, el orden de las columnas siempre es el orden en
que se han especificado al definir la tabla.
En la intersección de cada columna y fila existe un elemento de datos específico

que se denomina valor. Una columna es un conjunto de valores del mismo tipo.
Una fila es una secuencia de valores en la que el valor n es el valor de la columna
n de la tabla. Cada tabla debe tener una o más columnas, pero el número de filas
puede ser cero.
DB2 accede a los datos haciendo referencia a su contenido en lugar de hacer

referencia a su ubicación u organización en el almacenamiento.
DB2 da soporte a diferentes tipos de tablas:

v Tablas auxiliares
v Tablas base
v Tablas de clonación
v Tablas de consultas materializadas
v Tablas de resultados
v Tablas temporales
v Tablas XML
“Creación de tablas” en la página 177
“Tipos de tablas” en la página 178

Índices de DB2
Un índice es un conjunto ordenado de punteros hacia filas de una tabla. DB2 puede
utilizar índices para mejorar el rendimiento y asegurar la exclusividad. La
comprensión de la estructura de los índices de DB2 puede ayudarle a obtener el
mejor rendimiento para su sistema.
De modo conceptual, puede imaginar un índice de las filas de una tabla de DB2
como un índice de las páginas de un libro. Cada índice se basa en los valores de
datos de una o más columnas de una tabla.
DB2 puede utilizar índices para asegurar la exclusividad y mejorar el rendimiento

creando agrupaciones en clústeres de datos, particionando datos y proporcionando
vías de acceso eficaces a datos en las consultas. En la mayoría de casos, el acceso a
los datos es más rápido con un índice que con una exploración de los datos. Por
ejemplo, puede crear un índice en la columna DEPTNO de la tabla DEPT de
ejemplo para localizar de forma fácil un departamento específico y evitar la lectura
de cada fila, o la exploración, de la tabla.
Un índice se almacena separadamente de los datos de la tabla. Cada índice se

almacena físicamente en su propio espacio de índice. Cuando se define un índice
utilizando la sentencia CREATE INDEX, DB2 crea esta estructura y la mantiene de
forma automática. Sin embargo, puede realizar el mantenimiento necesario como,
por ejemplo, reorganizarla o recuperar el índice.
Las finalidades principales de los índices son las siguientes:

v Mejorar el rendimiento. El acceso a los datos a menudo es más rápido con un
índice que sin un índice.
v Asegurar que una fila sea exclusiva. Por ejemplo, un índice exclusivo en la tabla
de empleados asegura que no existan dos empleados con el mismo número de
empleado.
| v Agrupar en clústeres los datos.
| v Determinar a qué partición se dirigen los datos.
| v Proporciona acceso de sólo índice a los datos.
Excepto por los cambios en el rendimiento, los usuarios de la tabla no se dan

cuenta de que se está utilizando un índice. DB2 decide si va a utilizar el índice
para acceder a la tabla. Algunas técnicas le permiten influir en cómo influyen los
índices en el rendimiento al calcular el tamaño de almacenamiento de un índice y
determinar qué tipo de índice debe utilizarse.
| Un índice puede ser de particionamiento o sin particionamiento, y ambos tipos se

| pueden agrupar en clústeres. Por ejemplo, puede repartir los datos por apellidos,
| posiblemente utilizando una partición para cada letra del alfabeto. La elección de
| un esquema de particionamiento se basa en cómo una aplicación accede a los
| datos, de la cantidad de datos de que se dispone y cuánto se espera que crezca la
| cantidad total de datos.
Tenga en cuenta que los índices tienen tanto ventajas como desventajas. Un mayor
número de índices puede mejorar simultáneamente el rendimiento del acceso de
una transacción determinada y necesitar proceso adicional para insertar, actualizar
y suprimir claves de índice. Después de crear un índice, DB2 mantiene el índice,
pero puede realizar el mantenimiento necesario como, por ejemplo, su
reorganización o recuperación, según convenga.

“Creación de índices” en la página 214
″CREATE INDEX″ (Consulta de DB2 SQL)
Claves de DB2
Una clave es una columna o una colección ordenada de columnas que se identifica
en la descripción de una tabla, un índice o una restricción de referencia. Las claves
son decisivas para una estructura de tablas en una base de datos relacional.
Las claves son importantes en una base de datos relacional debido a que aseguran
que cada registro de una tabla se identifique de forma exclusiva, ayudan a
establecer e imponer integridad de referencia y establecen relaciones entre tablas.
La misma columna puede formar parte de más de una clave.
Una clave compuesta es un conjunto ordenado de dos o más columnas de la misma

tabla. El orden de las columnas no está restringido por su orden real dentro de la
tabla. El término valor, cuando se utiliza en relación a una clave compuesta, indica
un valor compuesto. Por ejemplo, considere esta regla: “El valor de la clave
foránea debe ser igual al valor de la clave primaria.” Esta regla significa que cada
componente del valor de la clave foránea debe ser igual al correspondiente
componente del valor de la clave primaria.
DB2 da soporte a varios tipos de claves.
Claves exclusivas
| Una restricción exclusiva es una regla en la que los valores de una clave únicamente
| son válidos si son exclusivos. Una clave restringida a tener valores exclusivos es
| una clave exclusiva. DB2 utiliza un índice exclusivo para imponer la restricción
| durante la ejecución del programa de utilidad LOAD y cada vez que se utilice una
| sentencia INSERT, UPDATE o MERGE para añadir o modificar datos. Cada clave
| exclusiva es una clave de un índice exclusivo. Puede definir una clave exclusiva
| utilizando la cláusula UNIQUE de la sentencia CREATE TABLE o ALTER TABLE.
| Una tabla puede tener cualquier número de claves exclusivas.
| Las columnas de una clave exclusiva no pueden contener valores nulos.
Claves primarias
Una clave primaria es un tipo especial de clave exclusiva y no puede contener

valores nulos. Por ejemplo, la columna DEPTNO de la tabla DEPT es una clave
primaria.
Una tabla no puede tener más de una clave primaria. Las claves primarias son
opcionales y se pueden definir en sentencias CREATE TABLE o ALTER TABLE.
| El índice exclusivo de una clave primaria se denomina índice primario. Cuando una
| clave primaria se define en una sentencia CREATE TABLE o una sentencia ALTER
| TABLE, DB2 crea automáticamente el índice primario si se cumple una de las
| condiciones siguientes:
v DB2 funciona en modalidad de nueva función y el espacio de tablas se crea
implícitamente.
| v DB2 está funcionando y se ejecuta el procesador de esquema.

Si ya existe un índice exclusivo en las columnas de la clave primaria cuando se
define en la sentencia ALTER TABLE, este índice exclusivo se designa como índice
primario cuando DB2 funciona en modalidad de nueva función y crea
implícitamente el espacio de tablas.
Claves padre
Una clave padre es una clave primaria o una clave exclusiva de la tabla padre de
una restricción de referencia. Los valores de una clave padre determinan los
valores válidos de la clave foránea de la restricción.
Claves foráneas
Una clave foránea es una clave que se especifica en la definición de una restricción
de referencia en una sentencia CREATE o ALTER TABLE. Una clave foránea hace
referencia a una clave padre específica o está relacionada con ella.
A diferencia de otros tipos de claves, una clave foránea no necesita un índice en su

columna o columnas subyacentes. Una tabla puede tener cero o más claves
foráneas. El valor de una clave foránea compuesta es nulo si cualquier componente
del valor es nulo.
La siguiente figura muestra la relación entre algunas columnas de la tabla DEPT y

la tabla EMP.
Figura 3. Relación entre las tablas DEPT y EMP
Notas de la figura: Cada tabla tiene una clave primaria:

v DEPTNO en la tabla DEPT
v EMPNO en la tabla EMP
Cada tabla tiene una clave foránea que establece una relación entre las tablas:
v Los valores de la clave foránea de la columna DEPT de la tabla EMP coinciden
con los valores de la columna DEPTNO de la tabla DEPT.
v Los valores de la clave foránea de la columna MGRNO de la tabla DEPT
coinciden con los valores de la columna EMPNO de la tabla EMP cuando un
empleado es un director.

Para ver una relación específica entre filas, observe cómo las filas sombreadas para
el departamento C01 y el número de empleado 000030 comparten valores comunes.
“Integridad de entidad, integridad de referencia y restricciones de referencia”
en la página 44
Vistas de DB2
Una vista es una forma alternativa para representar datos que existen en una o más
tablas. Una vista puede incluir todas o algunas de las columnas de una o más
tablas base.
Una vista es una especificación con nombre de una tabla de resultados.

Conceptualmente, una vista en cierto modo se parece a la utilización de unos
anteojos. Puede mirar a través de unos anteojos para ver un paisaje entero o para
ver una imagen específica dentro del paisaje como, por ejemplo, un árbol.
Puede crear una vista que:

v Combina datos de varias tablas base
v Se basa en otras vistas o en una combinación de vistas y tablas
v Omite determinados datos, protegiendo de este modo algunos datos de la tabla
de los usuarios finales
En realidad, son motivos subyacentes comunes para utilizar una vista. La

combinación de información de tablas base y vistas simplifica la recuperación de
datos para un usuario final y la limitación de los datos que un usuario puede ver
es útil para la seguridad. Puede utilizar vistas para muchos propósitos diferentes.
Una vista puede:
v Controlar el acceso a una tabla
v Facilitar la utilización de datos
v Simplificar la autorización al otorgar acceso a una vista sin otorgar acceso a la
tabla
v Mostrar únicamente parte de los datos de la tabla
v Mostrar datos de resumen para una tabla determinada
v Combinar dos o más tablas de formas significativas
v Mostrar sólo las filas seleccionadas que corresponden al proceso que utiliza la
vista
Para definir una vista, utilice la sentencia CREATE VIEW y asigne un nombre (con
un máximo de 128 caracteres de longitud) a la vista. La especificación de la vista
en otras sentencias de SQL es en efecto como ejecutar una sentencia SELECT de
SQL. En cualquier momento, la vista está formada por las filas que resultan de la
sentencia SELECT que contiene. Puede pensar en una vista formada por columnas
y filas al igual que la tabla base en la que está definida la vista.
Ejemplo 1: La figura siguiente muestra una vista de la tabla EMP que omite
información confidencial sobre empleados y renombra algunas de las columnas.

Figura 4. Vista de la tabla EMP
Nota sobre la figura: La vista EMPINFO representa una tabla que incluye
columnas denominadas EMPLOYEE, FIRSTNAME, LASTNAME, TEAM y
JOBTITLE. Los datos de la vista proceden de las columnas EMPNO, FIRSTNME,
LASTNAME, DEPT y JOB de la tabla EMP.
Ejemplo 2: La sentencia CREATE VIEW siguiente define la vista EMPINFO que se

muestra en la figura anterior:
CREATE VIEW EMPINFO (EMPLOYEE, FIRSTNAME, LASTNAME, TEAM, JOBTITLE)
AS SELECT EMPNO, FIRSTNME, LASTNAME, DEPT, JOB
FROM EMP;
Cuando se define una vista, DB2 almacena la definición de la vista en el catálogo

de DB2. Sin embargo, DB2 no almacena datos para la misma vista puesto que los
datos ya existen en la tabla o tablas bases.
Ejemplo 3: Puede reducir el ámbito de la vista EMPINFO limitando el contenido a

un subconjunto de filas y columnas que únicamente incluya los departamentos A00
y C01:
CREATE VIEW EMPINFO (EMPLOYEE, FIRSTNAME, LASTNAME, TEAM, JOBTITLE)
AS SELECT EMPNO, FIRSTNME, LASTNAME, DEPT, JOB
WHERE DEPT = 'AOO' OR DEPT = 'C01'
FROM EMP;
En general, una vista hereda los atributos del objeto del cual deriva. Las columnas
que se añaden a las tablas después de definir la vista en dichas tablas no aparecen
en la vista.
| Restricción: No se puede crear un índice para una vista. Además, no se puede

| crear ninguna forma de clave o restricción (de referencia o de otro tipo) en una
| vista. Estos índices, claves o restricciones deben crearse en las tablas a las que hace
| referencia la vista.
Para recuperar información o acceder a información de una vista, debe utilizar

vistas del mismo modo que utiliza tablas base. Puede utilizar una sentencia
SELECT para mostrar la información de la vista. La sentencia SELECT puede
nombrar otras vistas y tablas, y puede utilizar las cláusulas WHERE, GROUP BY y
HAVING. No puede utilizar la cláusula ORDER BY ni nombrar una variable de
lenguaje principal.
El hecho de que una vista se pueda utilizar en una operación de inserción,

actualización o supresión depende de su definición. Por ejemplo, si una vista
incluye una clave foránea de su tabla base, las operaciones INSERT y UPDATE que
utilizan esta vista están sujetas a la misma restricción de referencia que la tabla

base. Del mismo modo, si la tabla base de una vista es una tabla padre, las
operaciones DELETE que utilizan esta vista están sujetas a las mismas reglas que
las operaciones DELETE en la tabla base.
“Creación de vistas” en la página 231
“Tabla de empleados (DSN8910.EMP)” en la página 127
″CREATE VIEW″ (Consulta de DB2 SQL)
| Esquemas y calificadores de esquemas de DB2

| Los objetos de una base de datos relacional se organizan en conjuntos
| denominados esquemas. Un esquema es una colección de objetos con nombre. La
| primera parte de un nombre de esquema es el calificador.
| Un esquema proporciona una clasificación lógica de objetos de la base de datos.

| Los objetos que un esquema puede contener incluyen tablas, índices, espacios de
| tablas, tipos diferenciados, funciones, procedimientos almacenados y
| desencadenantes. Cuando se crea un objeto, se asigna a un esquema.
| Cuando se crea una tabla, un índice, un espacio de tablas, un tipo diferenciado,

| una función, un procedimiento almacenado o un desencadenante, se le proporciona
| un nombre calificado en dos partes. La primera parte es el nombre de esquema (o
| calificador), que se especifica implícita o explícitamente. El esquema por omisión es
| el ID de autorización del propietario del plan o paquete. La segunda parte es el
| nombre del objeto.
| En versiones anteriores, las sentencias CREATE tenían ciertas restricciones cuando

| el valor de CURRENT SCHEMA era diferente del valor de CURRENT SQLID.
| Aunque estas restricciones ya no existen, debe considerar cómo determinar la el
| calificador y el propietario cuando CURRENT SCHEMA y CURRENT SQLID
| contienen valores diferentes. Las reglas para la determinación del propietario
| dependen del tipo de objeto que se crea.
| CURRENT SCHEMA y CURRENT SQLID tan solo afectan a sentencias de SQL

| dinámico. CURRENT SCHEMA o CURRENT SQLID no afectan a sentencias
| CREATE estáticas.
| La tabla siguiente resume el efecto de CURRENT SCHEMA en la determinación

| del calificador de esquema y el propietario para los objetos siguientes:
| v Alias
| v Tabla auxiliar
| v Tabla temporal global creada
| v Tabla
| v Vista
| Tabla 1. Calificador de esquema y propietario para objetos
| Especificación del nombre
| para un objeto nuevo que se Calificador de esquema de
| crea objeto nuevo Propietario del objeto nuevo
| nombre (sin calificador) valor de CURRENT Valor de CURRENT SQLID
| SCHEMA
| abc.nombre (un solo abc abc
| calificador)

| Tabla 1. Calificador de esquema y propietario para objetos (continuación)
| ......abc.nombre (varios abc abc
| calificadores)
|
| La tabla siguiente resume el efecto de CURRENT SCHEMA en la determinación

| del calificador de esquema y el propietario para los objetos siguientes:
| v Tipo diferenciado definido por el usuario
| v Función definida por el usuario
| v Procedimiento
| v Secuencia
| v Desencadenante
| Tabla 2. Calificador de esquema y propietario para objetos adicionales
| nombre (sin calificador) valor de CURRENT Valor de CURRENT SQLID
| SCHEMA
| abc.nombre (un solo abc Valor de CURRENT SQLID
| calificador)
| ......abc.nombre (varios abc Valor de CURRENT SQLID
| calificadores)
|
| Espacios de tablas de DB2

Un espacio de tablas de DB2 es un conjunto de volúmenes en discos que contienen
los conjuntos de datos en los que se almacenan realmente tablas. Todas las tablas
se mantienen en espacios de tablas. Un espacio de tablas puede tener una o más
tablas.
| Un espacio de tablas puede estar formado por varios conjuntos de datos VSAM.
| Los conjuntos de datos son conjuntos de datos lineales (LDS) VSAM. Los espacios
| de tablas se dividen en unidades de igual tamaño, llamadas páginas, que se
| escriben en disco o se leen desde disco en una operación. Puede especificar
| tamaños de página (tamaños de 4 KB, 8 KB, 16 KB o 32 KB) para los datos; el
| tamaño de página por omisión es de 4 KB. Por regla general, debería tener como
| máximo entre 10 y 20 espacios de tabla en una base de datos de DB2. Si utiliza una
| base de datos de archivos de trabajo, debe crear como mínimo un espacio de tablas
| en la base de datos TEMP con páginas con un tamaño de 8 KB.
Los datos de la mayoría de espacios de tablas se pueden comprimir, lo que le

permite almacenar más datos en cada página de datos.
Puede definir explícitamente un espacio de tablas utilizando la sentencia CREATE

TABLESPACE, en la que puede especificar la base de datos a la que pertenece el
espacio de tablas y el grupo de almacenamiento que utiliza.
Como alternativa, puede dejar que DB2 cree implícitamente un espacio de tablas
en lugar del usuario emitiendo una sentencia CREATE TABLE que no especifique

un espacio de tablas existente. En este caso, DB2 asigna el espacio de tablas a la
base de datos por omisión y al grupo de almacenamiento por omisión. Si DB2
funciona en modalidad de conversión, se crea un espacio de tablas segmentado. En
modalidad de nueva función, DB2 crea un espacio de tablas de partición por
crecimiento.
Cuando crea un espacio de tablas, puede especificar el tipo de espacio de tablas

que crea. DB2 da soporte a diferentes tipos de espacios de tablas:
Espacios de tablas universales
Proporcionan una mejor gestión del espacio (para filas de longitud
variable) y un rendimiento de supresión masiva mejorado al combinar las
características de los esquemas de espacios de tablas particionados y
segmentados. Un espacio de tablas universal puede contener una tabla.
Espacios de tablas particionados
| Dividen el espacio disponible en unidades de almacenamiento
| denominadas particiones. Cada partición contiene un conjunto de datos de
| una tabla.
Espacios de tablas segmentados
Dividen el espacio disponible en grupos de páginas denominados
segmentos. Cada segmento tiene el mismo tamaño. Un segmento contiene
filas de una única tabla.
Espacios de tablas de objetos grandes
Contienen datos de objetos grandes como, por ejemplo, gráficos, vídeo o
series de texto muy grandes. Un espacio de tablas LOB siempre está
asociado al espacio de tablas que contiene los valores de columna LOB
lógicos.
Espacios de tablas simples
| Pueden contener más de una tabla. Las filas de tablas diferentes no se
| mantienen por separado (a diferencia de los espacios de tablas
| segmentados).
| Restricción: A partir de DB2 Versión 9.1 no se pueden crear espacios de

| tablas simples. Los espacios de tablas simples creados en una versión
| anterior de DB2 todavía están soportados.
| Espacios de tablas XML
| Contienen datos XML. Un espacio de tablas XML siempre está asociado al
| espacio de tablas que contiene el valor de columna XML lógico.
| Información relacionada
| ″Implementación de espacios de tablas de DB2″ (DB2 Administration Guide)
| Espacios de índice de DB2

| Un espacio de índice es una estructura de almacenamiento de DB2 que contiene un
| único índice.
| Cuando se crea un índice utilizando la sentencia CREATE INDEX, se define

| automáticamente un espacio de índice en la misma base de datos que la tabla. El
| usuario puede definir un nombre exclusivo para el espacio de índice o DB2 puede
| obtener un nombre exclusivo para el usuario. En algunas circunstancias, DB2 crea
| implícitamente espacios de índice.

Grupos de almacenamiento de DB2
Los grupos de almacenamiento de DB2 son un conjunto de volúmenes en discos
que contienen los conjuntos de datos en los que se almacenan realmente tablas e
índices.
La descripción de un grupo de almacenamiento nombra el grupo e identifica sus

volúmenes y el catálogo VSAM (virtual storage access method) que registra los
conjuntos de datos. El grupo de almacenamiento por omisión, SYSDEFLT, se crea
cuando se instala DB2.
Dentro del grupo de almacenamiento, DB2 realiza las acciones siguientes:

v Asigna almacenamiento para espacios de tablas e índices
v Define los conjuntos de datos VSAM necesarios
v Amplía y suprime conjuntos de datos VSAM
v Modifica conjuntos de datos VSAM
Todos los volúmenes de un grupo de almacenamiento determinado tienen el

mismo tipo de dispositivo. Sin embargo, las partes de una única base de datos se
pueden almacenar en diferentes grupos de almacenamiento.
DB2 puede gestionar los requisitos de almacenamiento auxiliar de una base de

datos utilizando grupos de almacenamiento de DB2. Los conjuntos de datos de
estos grupos de almacenamiento de DB2 se denominan conjuntos de datos
gestionados por DB2.
Estos grupos de almacenamiento de DB2 no son iguales que los grupos de

almacenamiento definidos por el subsistema de gestión de almacenamiento DFSMS
(DFSMSsms).
Existen varias opciones para gestionar conjuntos de datos de DB2:

v Dejar que DB2 gestione los conjuntos de datos. Esta opción significa menos
trabajo para los administradores de bases de datos de DB2.
Después de definir un grupo de almacenamiento de DB2, DB2 almacena
información sobre éste en el catálogo de DB2. (Este catálogo no es igual que el
catálogo del recurso de catálogos integrados que describe conjuntos de datos
VSAM de DB2). La tabla de catálogo SYSIBM.SYSSTOGROUP tiene una fila para
cada grupo de almacenamiento y SYSIBM.SYSVOLUMES tiene una fila para
cada volumen. Con la autorización adecuada, puede recuperar la información
del catálogo sobre grupos de almacenamiento de DB2 utilizando sentencias de
SQL.
Al crear espacios de tablas e índices, nombra el grupo de almacenamiento del
cual debe asignarse espacio. También puede asignar una base de datos completa
a un grupo de almacenamiento. Intente asignar objetos accedidos con frecuencia
(índices, por ejemplo) a dispositivos rápidos y asignar tablas muy poco
utilizadas a dispositivos más lentos. Este sistema para elegir grupos de
almacenamiento mejora el rendimiento.
Si tiene autorización para ello y no realiza pasos específicos para gestionar el
propio almacenamiento, todavía puede definir tablas, índices, espacios de tablas
y bases de datos. Se crea un grupo de almacenamiento por omisión, SYSDEFLT,
cuando se instala DB2. DB2 utiliza SYSDEFLT para asignar el almacenamiento
auxiliar necesario. La información sobre SYSDEFLT, como con cualquier otro
grupo de almacenamiento, se guarda en las tablas de catálogo
SYSIBM.SYSSTOGROUP y SYSIBM.SYSVOLUMES.

Para conjuntos de datos gestionados por el usuario y gestionados por DB2
necesita como mínimo un catálogo del recurso de catálogos integrados (ICF);
este catálogo puede ser un catálogo del usuario o un catálogo maestro. Estos
catálogos se crean con ICF. Debe identificar el catálogo del ICF al crear un grupo
de almacenamiento o al crear un espacio de tablas que no utilice grupos de
almacenamiento.
| v Dejar que SMS gestione algunos o todos los conjuntos de datos, al utilizar
| grupos de almacenamiento de DB2 o al utilizar conjuntos de datos definidos por
| uno mismo. Esta opción proporciona una carga de trabajo reducida para los
| administradores de almacenamiento y los administradores de bases de datos de
| DB2. Puede especificar clases de SMS al crear o modificar un grupo de
| almacenamiento.
v Definir y gestionar los propios conjuntos de datos utilizando servicios de
método de acceso VSAM. Esta opción le permite el máximo control sobre el
almacenamiento físico de tablas e índices.
Recomendación: Utilice grupos de almacenamiento de DB2 siempre que pueda,

específicamente o por omisión.
″Factores para determinar el tamaño de página de un espacio de tabla LOB″
(DB2 Administration Guide)
Bases de datos de DB2

Las bases de datos de DB2 son un conjunto de estructuras de DB2 que incluyen una
colección de tablas, sus índices asociados y los espacios de tablas en los que
residen. Para definir una base de datos utilice la sentencia CREATE DATABASE.
| Cuando se crea un espacio de tablas, se asigna explícita o implícitamente a una

| base de datos existente. Si crea un espacio de tablas y no especifica un nombre de
| base de datos, el espacio de tablas se crea en la base de datos por omisión,
| DSNDB04. En este caso, DB2 crea implícitamente una base de datos o utiliza una
| base de datos creada implícitamente existente para la tabla. Todos los usuarios que
| tienen la autorización para crear espacios de tablas o tablas en la base de datos
| DSNDB04 tienen autorización para crear tablas y espacios de tablas en una base de
| datos creada implícitamente. Si el espacio de tablas se crea implícitamente y no se
| especifica la cláusula IN en la sentencia CREATE TABLE, DB2 crea implícitamente
| la base de datos a la que se asigna el espacio de tablas.
Una única base de datos, por ejemplo, puede contener todos los datos asociados
con una aplicación o con un grupo de aplicaciones relacionadas. La recopilación de
estos datos en una base de datos le permite iniciar o detener el acceso a todos los
datos en una operación. También puede otorgar autorización de acceso a todos los
datos como una única unidad. Si suponemos que tiene autorización para acceder a
los datos, puede acceder a los datos que se almacenan en bases de datos diferentes.
| Recomendación: Evite utilizar una única base de datos para un número elevado de
| tablas. La definición de una base de datos para cada tabla mejora el rendimiento,
| la disponibilidad y la manejabilidad.
La figura siguiente muestra la organización de las principales estructuras de datos

de DB2. Dos bases de datos, A y B, se representan en forma de cuadrados. La base
de datos A contiene un espacio de tablas y dos espacios de índices. El espacio de
tablas está segmentado y contiene las tablas A1 y A2. Cada espacio de índice
contiene un índice, un índice en la tabla A1 y un índice en la tabla A2. La base de

datos B contiene un espacio de tablas y un espacio de índice. El espacio de tablas
está particionado y contiene la tabla B1, con las particiones de la 1 a la 4. El
espacio de índice contiene un índice de particionamiento, con las partes de la 1 a la
4.
Figura 5. Estructuras de datos en una base de datos de DB2
| Cuando se migra a la versión actual, DB2 adopta la base de datos por omisión y el
| grupo de almacenamiento por omisión que se ha utilizado en la versión anterior.
| Tiene la misma autorización para la versión actual que en la versión anterior.
| Las tablas temporales globales declaradas ahora se almacenan en la base de datos

| WORKFILE. La base de datos TEMP ya no se utiliza.
Motivos para definir una base de datos
En DB2 para z/OS, una base de datos es una colección lógica de espacios de tablas
y espacios de índices. Considere los factores siguientes cuando decida si va a
definir una nueva base de datos para un nuevo conjunto de objetos:
v Puede iniciar y detener una base de datos completa como una unidad; puede
visualizar los estados de todos sus objetos utilizando un único mandato que
nombre únicamente la base de datos. Por lo tanto, coloque en la misma base de
datos un conjunto de tablas que se utilicen juntas. (La misma base de datos
contiene todos los índices en dichas tablas.)
v Algunas operaciones bloquean una base de datos completa. Por ejemplo, algunas
fases del programa de utilidad LOAD impiden que algunas sentencias de SQL
(CREATE, ALTER y DROP) utilicen la misma base de datos simultáneamente.
Por lo tanto, la colocación de muchas tablas no relacionadas en una única base
de datos a menudo no resulta conveniente.
Cuando un usuario ejecuta una sentencia CREATE, ALTER o DROP para una
tabla, ningún otro usuario puede acceder a la base de datos que contiene dicha

tabla. Los usuarios de QMF, en especial, pueden llevar a cabo muchas
definiciones de datos; las operaciones de QMF SAVE DATA y ERASE objeto-datos
se realizan creando y eliminando tablas de DB2. Para conseguir la máxima
simultaneidad, cree una base de datos separada para cada usuario de QMF.
v Los descriptores de base de datos internos (DBD) pueden crecer demasiado. Los
DBD crecen a medida que se definen objetos nuevos, pero no se reducen
inmediatamente cuando se eliminan objetos; el espacio de DBD para un objeto
eliminado no se reclama hasta que se utiliza el programa de utilidad MODIFY
RECOVERY para suprimir los registros de copias obsoletas de
SYSIBM.SYSCOPY. Los DBD ocupan almacenamiento y son los objetos de
operaciones de entrada y salida ocasionales. Por lo tanto, la limitación del
tamaño de los DBD es otro motivo para definir nuevas bases de datos.
“Creación de bases de datos” en la página 235
Objetos del sistema DB2

DB2 tiene una amplia infraestructura que le permite proporcionar integridad de
datos, rendimiento y la capacidad de recuperar datos del usuario. A diferencia de
las estructuras de datos de DB2 creadas por los usuarios y a las que estos acceden,
DB2 controla objetos del sistema y accede a ellos.
Además, el compartimiento de datos de Sysplex paralelo utiliza objetos del sistema

compartidos.
“Estructuras de datos de DB2” en la página 26
Catálogo de DB2
DB2 mantiene un conjunto de tablas que contienen información sobre los datos que
DB2 controla. Estas tablas se conocen colectivamente con el nombre de catálogo. Las
tablas de catálogo contienen información sobre objetos de DB2 como, por ejemplo
tablas, vistas e índices. Cuando se crea, modifica o descarta un objeto, DB2 inserta,
actualiza o suprime filas del catálogo que describen el objeto.
El catálogo de DB2 consta de tablas de datos sobre todo lo que se ha definido en el

sistema DB2, incluyendo espacios de tablas, índices, tablas, copias de espacios de
tablas e índices, y grupos de almacenamiento. La base de datos del sistema
DSNDB06 contiene el catálogo de DB2.
Cuando se crea, modifica o descarta cualquier estructura, DB2 inserta, actualiza o

suprime filas del catálogo que describen la estructura e indican cómo se relaciona
la estructura con otras estructuras. Por ejemplo, SYSIBM.SYSTABLES es una tabla
de catálogo que registra información cuando se crea una tabla. DB2 inserta una fila
en SYSIBM.SYSTABLES que incluye el nombre de tabla, su propietario, su creador
y el nombre de su espacio de tablas y su base de datos.
Para comprender el rol del catálogo, considere lo que sucede cuando se crea la
tabla EMP. DB2 registra los datos siguientes:
Información de tabla
Para registrar el nombre de tabla y el nombre de su propietario, su creador,
su tipo, el nombre de su espacio de tablas y el nombre de su base de
datos, DB2 inserta una fila en el catálogo.

Información de columna
Para registrar información sobre cada columna de la tabla, DB2 inserta el
nombre de la tabla a la que pertenece la columna, su longitud, su tipo de
datos y su número de secuencia insertando una fila en el catálogo para
cada columna de la tabla.
Información de autorización
Para registrar que el propietario de la tabla tiene autorización para crear la
tabla, DB2 inserta una fila en el catálogo.
| Las tablas del catálogo son como cualquier otra tabla de base de datos en cuanto a
| la recuperación. Si dispone de autorización para ello, puede utilizar sentencias de
| SQL para ver datos de las tablas de catálogo del mismo modo que se recuperan
| datos de cualquier tabla de la base de datos de DB2. DB2 comprueba que el
| catálogo contiene descripciones de objetos precisas. Si tiene autorización para
| acceder a las tablas o vistas específicas del catálogo, puede aplicar SELECT al
| catálogo, pero no puede utilizar sentencias INSERT, UPDATE, DELETE,
| TRUNCATE o MERGE en el catálogo.
La base de datos de comunicaciones (CDB) forma parte del catálogo de DB2. La CDB
consta de un conjunto de tablas que establecen conversaciones con sistemas de
gestión de bases de datos (DBMS) remotos. El recurso de datos distribuidos (DDF)
utiliza la CDB para enviar y recibir peticiones de datos distribuidos.
″Tablas de catálogo de DB2″ (Consulta de DB2 SQL)
Directorio de DB2
El directorio de DB2 contiene información que DB2 utiliza durante la operación
normal.
No puede acceder al directorio utilizando SQL, aunque gran parte de la misma

información se incluye en el catálogo de DB2, en el que puede someter consultas.
Las estructuras del directorio no se describen en el catálogo de DB2.
El directorio está formado por un conjunto de tablas de DB2 que se almacenan en

cinco espacios de tablas de la base de datos del sistema DSNDB01. Cada uno de
los espacios de tablas que se listan en la tabla siguiente están contenidos en un
conjunto de datos lineal VSAM.
Tabla 3. Espacios de tablas del directorio
Nombre de espacio de tabla Descripción
SCT02 Contiene el formato interno de sentencias de SQL
Cursor de esquema (SKCT) que se incluyen en una aplicación. Cuando se
vincula un plan, DB2 crea una tabla de cursor de
esquema en SCT02.
SPT01 Parecido a SCT02, excepto en que la tabla de
Paquete de esquema paquete de esquema se crea al vincular un
paquete.

Tabla 3. Espacios de tablas del directorio (continuación)
Nombre de espacio de tabla Descripción
SYSLGRNX Realiza un seguimiento de la apertura y cierre de
Rango de registro los espacios de tablas, índices o particiones. Al
realizar un seguimiento de esta información y
asociarla con direcciones de byte relativo (RBA) tal
como están contenidas en el registro de DB2, DB2
puede reducir el tiempo de recuperación
disminuyendo la cantidad de registro que debe
explorarse para un espacio de tablas, índice o
partición determinados.
SYSUTILX Contiene una fila para cada trabajo de programa
Programas de utilidad del sistema de utilidad que se ejecuta. La fila permanece hasta
que finaliza el programa de utilidad. Si el
programa de utilidad termina sin haber finalizado,
DB2 utiliza la información de la fila al reiniciar el
programa de utilidad.
DBD01 Contiene información interna, denominada
Descriptor de base de datos (DBD) descriptores de base de datos (DBD), sobre las bases
de datos que existen en el subsistema DB2.
Cada base de datos tiene exactamente un DBD

correspondiente que describe la base de datos, los
espacios de tablas, las tablas, las restricciones de
comprobación de tabla, los índices y las relaciones
de referencia. Un DBD también contiene otra
información sobre el acceso a las tablas de la base
de datos. DB2 crea y actualiza los DBD cada vez
que se crean o actualizan las bases de datos
correspondientes.
Registros activo y de archivado

DB2 registra todos los cambios de los datos y otros sucesos significativos en un
registro. Con este registro de cambios, DB2 puede volver a crear los cambios en
caso de que se produzca una anomalía o puede retrotraer los cambios a un punto
anterior en el tiempo.
DB2 escribe cada registro del archivo de registro en un conjunto de datos de disco
denominado registro activo. Cuando el registro activo está lleno, DB2 copia el
contenido del registro activo en un conjunto de datos de disco o cinta magnética
denominado registro de archivado.
Puede elegir entre registro cronológico único y registro cronológico dual.

v Un registro activo único contiene como máximo 93 conjuntos de datos de
registro activo.
v Con el registro cronológico dual, el registro activo tiene el doble de capacidad
para los conjuntos de datos de registro activo debido a que se conservan dos
copias idénticas de los registros del archivo de registro.
| Cada subsistema DB2 gestiona varios registros activos y registros de archivado.

| Para cada registro activo de DB2 se cumplen los hechos siguientes:
v Se puede duplicar cada registro para asegurar una alta disponibilidad.
v Cada conjunto de datos de registro activo es un conjunto de datos lineal (LDS)
VSAM.

v DB2 da soporte a conjuntos de datos de registro activo separados.
″Lectura de registros del archivo de registro″ (DB2 Administration Guide)
″Gestión del registro y del conjunto de datos del programa de arranque″ (DB2
Administration Guide)
Conjunto de datos del programa de arranque

| El conjunto de datos del programa de arranque (BSDS) es un conjunto de datos en
| secuencia de clave (KSDS) de VSAM que contiene información decisiva para DB2,
| como por ejemplo los nombres de los registros. DB2 utiliza la información del
| BSDS para reinicios del sistema y para cualquier actividad que requiera lectura del
| registro.
Específicamente, el BSDS contiene:

v Un inventario de todos los conjuntos de datos de registro activo y de archivado
conocidos en DB2. DB2 utiliza esta información para realizar un seguimiento de
los conjuntos de datos de registro activo y de archivado. DB2 también utiliza
esta información para localizar registros del archivo de registro para satisfacer
peticiones de lectura de registro durante la actividad normal de DB2 y durante
el proceso de reinicio y recuperación.
v Un inventario de reinicio de toda la actividad de punto de comprobación de
DB2 reciente. DB2 utiliza esta información durante el proceso de reinicio.
v El registro de comunicaciones del recurso de datos distribuidos (DDF), que
contiene la información necesaria para utilizar DB2 como un peticionario o
servidor distribuido.
v Información sobre agrupaciones de almacenamientos intermedios.
Debido a que el BSDS es esencial para la recuperación en el caso de una anomalía

de subsistema, DB2 crea automáticamente dos copias del BSDS y, si el espacio lo
permite, las coloca en volúmenes separados.
El BSDS se puede duplicar para asegurar una alta disponibilidad.

″Gestión del registro y del conjunto de datos del programa de arranque″ (DB2
Agrupaciones de almacenamientos intermedios

Las agrupaciones de almacenamientos intermedios son áreas de almacenamiento virtual
en las que DB2 almacena temporalmente páginas de espacios de tablas o índices.
Cuando un programa de aplicación accede a una fila de una tabla, DB2 recupera la
página que contiene la fila y coloca la página en un almacenamiento intermedio. Si
los datos necesarios ya están en un almacenamiento intermedio, no es necesario
que el programa de aplicación espere a que se recuperen del disco, con lo cual el
tiempo y el coste de recuperación de la página se reducen significativamente.
Las agrupaciones de almacenamientos intermedios requieren supervisión y ajuste.

El tamaño de las agrupaciones de almacenamientos intermedios es decisivo para
las características de rendimiento de una aplicación o un grupo de aplicaciones que
accede a los datos de dichas agrupaciones de almacenamientos intermedios.

DB2 le permite especificar agrupaciones de almacenamientos intermedios por
omisión para datos del usuario e índices. Un tipo especial de agrupación de
almacenamientos intermedios que se utiliza únicamente en el compartimiento de
datos de Sysplex paralelo es la agrupación de almacenamientos intermedios de grupo,
que reside en el recurso de acoplamiento. Las agrupaciones de almacenamientos
intermedios residen en una partición lógica LPAR de PR/SM denominada recurso
de acoplamiento, que permite a varios subsistemas DB2 compartir información y
controlar la coherencia de los datos.
Las agrupaciones de almacenamientos intermedios residen en el espacio de

direcciones primario DBM1 de DB2. Esta opción proporciona el mejor rendimiento.
El tamaño máximo de una agrupación de almacenamientos intermedios es de 1 TB.
Base de datos de soporte de control de definición de datos

La base de datos de soporte de control de definición de datos (DDCS) hace referencia a
una colección de tablas mantenidas por el usuario utilizadas por el soporte de
control de definición de datos para limitar el sometimiento de sentencias DDL
(lenguaje de definición de datos) de DB2 a identificadores de aplicaciones
seleccionados (planes o colecciones de paquetes).
Esta base de datos se crea automáticamente durante la instalación. Después de

crear esta base de datos, debe llenar las tablas para utilizar el recurso. El nombre
de esta base de datos es DSNRGFDB.
Base de datos de recurso de límite de recursos

La base de datos de recurso de límite de recurso (DSNRLST) es un recurso que le
permite controlar la cantidad de recursos de procesador que las sentencias SELECT
dinámicas utilizan.
Por ejemplo, puede elegir inhabilitar las operaciones de vinculación durante

horas críticas del día a fin de evitar contención con el catálogo de DB2.
Puede establecer un único límite para todos los usuarios, límites diferentes para
usuarios individuales o ambas cosas. Puede elegir aplicar estos límites antes de
ejecutar la sentencia (denominado control predictivo o mientras se ejecuta una
sentencia (a veces denominado control reactivo). Incluso puede utilizar ambas
modalidades de manejo. Estos límites se definen en una o más tablas de
especificación de límite de recursos (RLST).
Base de datos de archivos de trabajo

Utilice la base de datos de archivos de trabajo como almacenamiento para procesar
sentencias de SQL que necesitan espacio de trabajo, como el que se necesita para
una clasificación.
| La base de datos de archivos de trabajo se utiliza como almacenamiento para

| archivos de trabajo de DB2 que procesan sentencias de SQL que necesitan espacio
| de trabajo (como el que se necesita para una clasificación) y como almacenamiento
| para tablas temporales globales creadas y tablas temporales globales declaradas.
| DB2 crea una base de datos de archivos de trabajo y varios espacios de tablas en él
| durante la instalación. Puede crear espacios de tablas de archivos de trabajo en
| cualquier momento. Puede descartar, volver a crear y modificar la base de datos de
| archivos de trabajo o los espacios de tablas de éste, o ambos, en cualquier
| momento.

| En un entorno sin compartimiento de datos, la base de datos de archivos de
| trabajo se denomina DSNDB07. En un entorno de compartimiento de datos, cada
| miembro de DB2 del grupo de compartimiento de datos tiene su propia base de
| datos de archivos de trabajo.
| También puede utilizar la base de datos de archivos de trabajo para todas las
| tablas temporales.
Soporte de alta disponibilidad

Debido a que DB2 proporciona soporte de alta disponibilidad, no es necesario
iniciar o detener con frecuencia DB2.
Una clave de la idea de alta disponibilidad consiste en ser capaz de obtener la

copia de seguridad del subsistema DB2 y ejecutar rápidamente después de una
interrupción no planificada.
v Se puede producir algún proceso de reinicio simultáneamente con trabajo nuevo.
Además, puede optar por posponer algún proceso.
v Durante un reinicio, DB2 aplica cambios en los datos desde el registro. Esta
técnica asegura que los cambios en los datos no se pierdan, incluso si no se han
escrito algunos datos durante la anomalía. Parte del proceso de aplicar cambios
del registro se puede ejecutar en paralelo
v Puede registrar DB2 en Automatic Restart Manager de z/OS. Este recurso
reinicia automáticamente DB2 si se detiene como resultado de una anomalía.
“Copia de seguridad, recuperación y reinicio” en la página 284
Imposición de reglas empresariales

La integridad de referencia asegura la integridad de los datos mediante la
imposición de reglas con restricciones de referencia, restricciones de comprobación
y desencadenantes. Puede hacer que la base de datos funcione utilizando
restricciones y desencadenantes. Puede basarse en estos mecanismos para asegurar
la integridad y validez de los datos, en lugar de basarse en aplicaciones
individuales que realizan este trabajo.
Integridad de entidad, integridad de referencia y restricciones

de referencia
DB2 asegura la integridad de referencia entre las tablas al definir restricciones de
referencia.
| Integridad de referencia es el estado en que todos los valores de todas las claves
| foráneas son válidos. La integridad de referencia está basada en la integridad de
| entidad. La integridad de entidad necesita que cada entidad tenga una clave
| exclusiva. Por ejemplo, si cada fila de una tabla representa relaciones para una
| entidad exclusiva, la tabla debería tener una columna o un conjunto de columnas
| que proporcione un identificador exclusivo para las filas de la tabla. Esta columna
| (o conjunto de columnas) se denomina clave padre de la tabla. Para asegurar que
| la clave padre no contenga valores duplicados, debe definirse un índice exclusivo
| en la columna o columnas que forman la clave padre. La definición de la clave
| padre se denomina integridad de entidad.
Una restricción de referencia es la regla de que los valores no nulos de una clave
foránea sólo son válidos si también aparecen como valores de una clave padre. La

tabla que contiene la clave padre se denomina tabla padre de la restricción de
referencia y la tabla que contiene la clave foránea es una tabla dependiente de dicha
tabla.
La relación entre algunas filas de las tablas DEPT y EMP, que se muestran en la
siguiente figura, ilustra los conceptos y terminología de integridad de referencia.
Por ejemplo, la integridad de referencia asegura que cada valor de clave foránea de
la columna DEPT de la tabla EMP coincide con un valor de clave primaria de la
columna DEPTNO de la tabla DEPT.
Figura 6. Integridad de referencia de las tablas DEPT y EMP
Existen dos relaciones entre padre y dependiente entre las tablas DEPT y EMP.
v La clave foránea de la columna DEPT establece una relación entre padre y
dependiente. La columna DEPT de la tabla EMP depende del DEPTNO de la
tabla DEPT. Según esta relación de clave foránea, la tabla DEPT es la tabla padre
de la tabla EMP. Puede asignar un empleado a ningún departamento
(especificando un valor nulo), no puede asignar un empleado a un
departamento que no exista.
v La clave foránea de la columna MGRNO también establece una relación entre
padre y dependiente. Debido a que MGRNO depende de EMPNO, EMP es la
tabla padre de la relación y DEPT es la tabla dependiente.
| Puede definir una clave primaria en una o más columnas. Una clave primaria que
| incluye dos o más columnas se denomina clave compuesta. Una clave foránea
| también puede incluir una o más columnas. Cuando una clave foránea contiene
| varias columnas, la clave primaria correspondiente debe ser una clave compuesta.
| El número de columnas de clave foránea debe ser igual al número de columnas de
| la clave padre y los tipos de datos de las columnas correspondientes deben ser
| compatibles. (La tabla de actividades de proyectos de ejemplo, DSN8910.PROJACT,
| es un ejemplo de una tabla con una clave primaria en varias columnas PROJNO,
| ACTNO y ACSTDATE.)
Una tabla puede depender de sí misma; este tipo de tabla se denomina tabla de
autorreferencia. Por ejemplo, la tabla DEPT es una tabla de autorreferencia debido a
que el valor del departamento administrativo (ADMRDEPT) debe ser un ID de

departamento (DEPTNO). Para imponer la restricción de autorreferencia, DB2
necesita que haya definida una clave foránea.
Una terminología similar se aplica a las filas de una relación padre-hijo. Una fila
de una tabla dependiente, denominada fila dependiente, hace referencia a una fila de
una tabla padre, denominada fila padre. Pero una fila de una tabla padre no
siempre es una fila padre (quizás nada hace referencia a ella). De forma similar,
una fila de una tabla dependiente no siempre es una fila dependiente (la clave
foránea puede permitir valores nulos, que no hacen referencia a ninguna otra fila).
Las restricciones de referencia son opcionales. Las restricciones de referencia se

definen utilizando sentencias CREATE TABLE y ALTER TABLE.
Para dar soporte a integridad de referencia, DB2 impone reglas cuando los
usuarios insertan, cargan, actualizan o suprimen datos.
Otro tipo de restricción de referencia es una restricción de referencia informativa. DB2

no impone este tipo de restricción durante operaciones normales. Un proceso de
proceso de aplicaciones debe verificar los datos de la relación de integridad de
referencia. Una restricción de referencia informativa permite que las consultas
aprovechen las ventajas de tablas de consultas materializadas.
“Tabla de departamentos (DSN8910.DEPT)” en la página 125
“Tabla de actividades de proyectos (DSN8910.PROJACT)” en la página 133
″Restricciones de referencia″ (DB2 Application Programming and SQL Guide)
Restricciones de comprobación
Una restricción de comprobación es una regla que especifica los valores permitidos en
una o más columnas de cada fila de una tabla base.
Al igual que las restricciones de referencia, las restricciones de comprobación son

opcionales y se definen mediante las sentencias CREATE TABLE y ALTER TABLE.
La definición de una restricción de comprobación limita los valores que una
columna específica de una tabla base puede contener.
Una tabla puede contener cualquier número de restricciones de comprobación. DB2

impone una restricción de comprobación aplicando la restricción a cada fila que se
inserta, carga o actualiza. Una restricción es que un nombre de columna de una
restricción de comprobación de una tabla debe identificar una columna de dicha
tabla.
Ejemplo: Puede crear una restricción de comprobación para asegurarse de que

todos los empleados ganan un salario de 30 000 $ o más:
CHECK (SALARY>= 30000)
Desencadenantes
Un desencadenante define un conjunto de acciones que deben ejecutarse cuando se
produce una operación de inserción, actualización o supresión en una tabla
especificada.

Cuando se ejecuta una inserción, carga, actualización o supresión, se dice que el
desencadenante se activa.
Puede utilizar desencadenantes junto con restricciones de referencia y restricciones

de comprobación para imponer reglas de integridad de datos. Los desencadenantes
son más eficaces que las restricciones porque se pueden utilizar para realizar las
acciones siguientes:
v Actualizar otras tablas
v Generar o transformar valores automáticamente para filas insertadas o
actualizadas
v Invocar funciones que realizan operaciones dentro y fuera de DB2
Por ejemplo, suponga que necesita evitar que se realice una actualización en una
columna cuando un valor nuevo exceda de una cantidad determinada. En lugar de
impedir la actualización, puede utilizar un desencadenante. El desencadenante
puede sustituir a un valor válido e invocar un procedimiento que envíe una
advertencia a un administrador sobre la actualización no válida que se ha
intentado.
Para definir desencadenantes utilice la sentencia CREATE TRIGGER.
| Los desencadenantes INSTEAD OF son desencadenantes que se ejecutan en lugar

| de la sentencia INSERT, UPDATE o DELETE que activa el desencadenante. A
| diferencia de otros desencadenantes, que sólo se definen en tablas, los
| desencadenantes INSTEAD OF sólo se definen en vistas. Los desencadenantes
| INSTEAD OF son especialmente útiles cuando es necesario que las acciones
| desencadenadas para sentencias INSERT, UPDATE o DELETE en vistas sean
| diferentes de las acciones para sentencias SELECT. Por ejemplo, se puede utilizar
| un desencadenante INSTEAD OF para facilitar una actualización mediante una
| consulta de unión o para codificar o descodificar datos de una vista.
“Creación de desencadenantes” en la página 241
Procesos de aplicaciones y transacciones

Un proceso de aplicaciones implica la ejecución de uno o más programas. Procesos
de aplicaciones diferentes pueden implicar la ejecución de programas diferentes o
la ejecución del mismo programa en distintos momentos. Cuando una aplicación
interactúa con una base de datos de DB2, se inicia una transacción.
Numerosos tipos programas diferentes acceden a datos de DB2 data: aplicaciones

escritas por el usuario, sentencias de SQL que los usuarios entran dinámicamente e
incluso programas de utilidad. El único término que describe cualquier tipo de
acceso a datos de DB2 se denomina proceso de aplicaciones. Todos los programas de
SQL se ejecutan como parte de un proceso de aplicaciones.
Una transacción es una secuencia de acciones entre la aplicación y la base de datos;

la secuencia se inicia cuando se leen datos de la base de datos o se escriben datos
en ella. Una transacción también se denomina unidad de trabajo.
Ejemplo: Considere lo que sucede cuando accede al capital de una cuenta

bancaria. Una transacción bancaria puede implicar la transferencia de capital de
una cuenta a otra. Durante la transacción, un programa de aplicación primero resta
el capital de la primera cuenta y, a continuación, lo añade el capital a la segunda

cuenta. Después del paso de resta, los datos son incoherentes. La coherencia se
restablece después de añadir el capital a la segunda cuenta.
Para asegurar la coherencia de los datos, DB2 utiliza varias técnicas que incluyen
una operación de confirmación, una operación de retrotracción y bloqueos.
Cuando los pasos de resta y adición de la transacción bancaria se han completado,

la aplicación puede utilizar la operación de confirmación para finalizar la
transacción y, de este modo, los cambios pasan a estar disponibles para otros
procesos de aplicaciones. La operación de confirmación hace que los cambios
realizados en la base de datos sean permanentes.
Considere lo que sucede si más de un proceso de aplicaciones solicita acceder a los

mismos datos al mismo tiempo. O, en determinadas circunstancias, una sentencia
de SQL puede ejecutarse simultáneamente con un programa de utilidad en el
mismo espacio de tablas. DB2 utiliza bloqueos para mantener la integridad de los
datos en estas condiciones para evitar, por ejemplo, que dos procesos de
aplicaciones actualicen la misma fila de datos simultáneamente.
DB2 adquiere bloqueos para evitar que los cambios sin confirmar realizados por un
proceso de aplicaciones pueda percibirlo otro proceso de aplicaciones. DB2 libera
automáticamente todos los bloqueos que ha adquirido en nombre de un proceso de
aplicaciones cuando el proceso finaliza, pero un proceso de aplicaciones también
puede solicitar explícitamente que los bloqueos se liberen antes. Una operación de
confirmación libera los bloqueos que un proceso de aplicaciones ha adquirido y
confirma los cambios realizados en la base de datos por el mismo proceso.
DB2 también proporciona un modo para restituir los cambios sin confirmar que
realiza un proceso de aplicaciones. Puede ser necesaria una restitución en el caso
de una anomalía en la parte de un proceso de aplicaciones o en una situación de
punto muerto. Un punto muerto se produce cuando la contención por la utilización
de un recurso como, por ejemplo, una tabla, no se puede resolver. Sin embargo, un
proceso de aplicaciones puede solicitar explícitamente que se restituyan los
cambios que ha realizado en la base de datos. Esta operación se denomina
retrotracción. La interfaz que un programa de SQL utiliza para especificar
explícitamente estas operaciones de confirmación y de retrotracción depende del
entorno. Por ejemplo, en el entorno JDBC las aplicaciones utilizan métodos de
confirmación y retrotracción para confirmar o retrotraer transacciones.
Paquetes y planes de aplicaciones

Un paquete contiene estructuras de control que DB2 utiliza cuando ejecuta
sentencias de SQL. Un plan de aplicación relaciona un proceso de aplicaciones con
una instancia local de DB2 y especifica opciones de proceso.
Los paquetes se producen durante la preparación de un programa. Puede imaginar

las estructuras de control como formularios vinculados o de operación de
sentencias de SQL. Todas las estructuras de control de un paquete derivan de las
sentencias de SQL incorporadas en un único programa fuente.
Un plan de aplicación contiene uno o ambos elementos siguientes:

v Una lista de nombres de paquetes
v El formulario vinculado de sentencias de SQL

La mayoría de aplicaciones de DB2 necesitan un plan de aplicación. Los paquetes
hacen que los programas de aplicaciones sean más flexibles y fáciles de mantener.
Por ejemplo, si utiliza paquetes, no necesita volver vincular el plan completo al
cambiar una sentencia de SQL.
Ejemplo: La figura siguiente muestra un plan de aplicación que contiene dos

paquetes. Suponga que decide cambiar la sentencia SELECT del paquete AA para
seleccionar datos de una tabla diferente. En este caso, tan solo debe volver a
vincular el paquete AA y no el paquete AB.
Figura 7. Plan de aplicación y paquetes
En general, los planes y paquetes se crean utilizando los mandatos BIND PLAN y
BIND PACKAGE de DB2.
Un paquete desencadenante es un tipo especial de paquete que se crea al ejecutar una

sentencia CREATE TRIGGER. Un paquete desencadenante sólo se ejecuta cuando
se activa el desencadenante con el que está asociado.
Los paquetes para aplicaciones JDBC, SQLJ y ODBC tienen propósitos diferentes
sobre los que puede leer más adelante en esta información.
“Proceso de preparación para un programa de aplicación” en la página 150
Rutinas
Una rutina es un objeto de SQL ejecutable. Los dos tipos de rutinas son funciones y
procedimientos.
Funciones
Una función es una rutina que se puede invocar desde otras sentencias de SQL y
que devuelve un valor.
| Para definir funciones utilice la sentencia CREATE FUNCTION. Puede clasificar las
| funciones como funciones incorporadas, funciones definidas por el usuario o
| funciones de conversión generadas para tipos diferenciados. Las funciones también

| se pueden clasificar como funciones de totales, escalares o de tabla, dependiendo d
| los valores de los datos de entada y los valores resultantes.
| Una función de tabla sólo se puede utilizar en la cláusula FROM de una sentencia.
| Las funciones de tabla devuelven columnas de una tabla y son similares a una
| tabla creada mediante una sentencia CREATE TABLE. Las funciones de tabla se
| pueden calificar con un nombre de esquema.
“Creación de funciones definidas por el usuario” en la página 241
″Funciones″ (Consulta de DB2 SQL)
Procedimientos
| Un procedimiento, también denominado procedimiento almacenado, es una rutina
| que se puede llamar para realizar operaciones que pueden incluir sentencias de
| SQL.
Los procedimientos se clasifican como procedimientos de SQL o procedimientos

externos. Los procedimientos de SQL sólo contienen sentencias de SQL. Los
procedimientos externos hacen referencia a un programa de lenguaje principal que
puede o no contener sentencias de SQL.
| DB2 for z/OS da soporte a los dos tipos de procedimientos de SQL siguientes:
Procedimientos de SQL externos
Los procedimientos de SQL externos son procedimientos cuyo cuerpo está
escrito en SQL. DB2 da soporte a este tipo de procedimientos generando
un programa C asociado para cada procedimiento. Todos los
procedimientos de SQL creados antes de la Versión 9.1 son procedimientos
de SQL externos. A partir de la Versión 9.1, se puede crear un
procedimiento de SQL externo especificando FENCED o EXTERNAL en la
sentencia CREATE PROCEDURE.
Procedimientos de SQL nativos
Los procedimientos de SQL nativos son procedimientos cuyo cuerpo está
escrito en SQL. Para procedimientos de SQL nativos, DB2 no genera un
programa C asociado. A partir de la Versión 9.1, todos los procedimientos
de SQL creados sin las opciones FENCED o EXTERNAL en la sentencia
CREATE PROCEDURE son procedimientos de SQL nativos. Se pueden
crear procedimientos de SQL nativos en un paso. Las sentencias de SQL
nativos dan soporte a más funciones y generalmente proporcionan un
mejor rendimiento que las sentencias de SQL externas.
| Las sentencias de control de SQL están soportadas en procedimientos de SQL. Las

| sentencias de control son sentencias de SQL que permiten utilizar SQL de una
| forma similar a la escritura de un programa en un lenguaje de programación
| estructurado. Las sentencias de control de SQL proporcionan la posibilidad de
| controlar el flujo lógico, declaran y establecen variables, y manejan avisos y
| excepciones. Algunas sentencias de control de SQL incluyen otras sentencias de
| SQL anidadas.
Los procedimientos de SQL proporcionan las mismas ventajas que los

procedimientos de un lenguaje principal. Es decir, una parte de un código debe
escribirse y mantenerse una sola vez y puede llamarse desde varios programas.

| Los procedimientos de SQL proporcionan ventajas adicionales cuando contienen
| sentencias de SQL. En este caso, los procedimientos de SQL pueden reducir o
| eliminar retrasos en la red asociados con la comunicación entre el cliente y el
| servidor, y entre cada sentencia de SQL. Los procedimientos de SQL pueden
| mejorar la seguridad al permitir que el usuario invoque un único procedimiento en
| lugar de ejecutar el SQL que el procedimiento contiene.
Para definir procedimientos utilice la sentencia CREATE PROCEDURE.

Datos distribuidos
Los datos distribuidos son datos que residen en un DBMS que no es el sistema local.
El DBMS local es el sistema en el que se vincula el plan de aplicación. Los demás

DBMS son remotos.
Muchas empresas necesitan gestionar datos de varios orígenes y ubicaciones. Un

entorno distribuido proporciona la flexibilidad necesaria para asignar recursos para
datos ubicados en diferentes sitios o sistemas de gestión de bases de datos (DBMS)
de una red de sistemas.
Servidores remotos
Un servidor remoto puede ser físicamente remoto o puede formar parte del mismo
sistema operativo bajo el cual se ejecuta el DBMS local.
Cuando un usuario solicita servicios remotos de un DBMS remoto, el DBMS

remoto es un servidor y el sistema local es un peticionario o cliente.
Conceptualmente, un servidor es como un camarero que recoge los pedidos de
comida, entrega la comida y proporciona otros servicios a los clientes. El cliente es
como la persona que realiza el pedido. La finalidad del servidor consiste en
proporcionar servicios a sus clientes.
Un servidor remoto puede ser realmente remoto en el sentido físico (situado a

miles de quilómetros) o puede formar parte del mismo sistema operativo bajo el
cual se ejecuta el DBMS local. En esta información generalmente se supone que el
DBMS local es una instancia de DB2 for z/OS. Un servidor remoto puede ser otra
instancia de DB2 for z/OS o una instancia de uno de muchos otros productos.
La figura siguiente muestra el entorno cliente/servidor.

Figura 8. Entorno de proceso cliente/servidor
Conectividad
La conectividad en el entorno de cliente/servidor permite la comunicación entre
aplicaciones y sistemas de bases de datos en sistemas operativos diferentes.
La conectividad en el entorno de cliente/servidor necesita una arquitectura que

pueda manejar los requisitos de rendimiento más rigurosos de un sistema basado
en transacciones y la flexibilidad de un sistema de soporte de decisiones utilizando
ODBC o JDBC. El método primario que DB2 utiliza para proporcionar conectividad
a cualquier número de DBMS es Distributed Relational Database Architecture
(DRDA), basado en el estándar técnico de Open Group. DRDA es una arquitectura
publicada abierta que permite la comunicación entre aplicaciones y sistemas de
bases de datos en sistemas operativos diferentes.
Mediante la utilización de protocolos de comunicación estándar, DB2 puede

vincular y volver a vincular paquetes en otros servidores y ejecutar las sentencias
en estos paquetes. Los protocolos de comunicación son reglas para gestionar el
flujo de datos a través de una red de sistemas del mismo modo que los semáforos
y las reglas de tráfico gestionan el flujo de tráfico de coches. Estos protocolos no
son visibles para aplicaciones de DB2. Por ejemplo, un sistema que utiliza DRDA,
puede invocar procedimientos almacenados de DB2 o solicitar que las sentencias
de SQL se ejecuten en cualquier servidor que cumpla el estándar DRDA.
En un entorno distribuido, las aplicaciones pueden conectarse con varias bases de

datos en servidores diferentes y pueden completar transacciones, incluyendo
operaciones de confirmación y retrotracción, al mismo tiempo. Este tipo de
conectividad se conoce como unidad de trabajo distribuida.

Capítulo 3. Arquitectura de DB2 para z/OS
z/OS es la siguiente generación del sistema operativo OS/390. Los sistemas z/OS
and the IBM System z10, System z9 109 y zSeries 990, 900 y 800 ofrecen una
arquitectura que proporciona cualidades de servicio decisivos para e-business.
z/Architecture y el sistema operativo z/OS

z/OS, que es un sistema operativo muy seguro, escalable y abierto, proporciona
alto rendimiento que da soporte a un entorno de ejecución de aplicaciones
diversas. La gran integración que DB2 tiene con la arquitectura System z y el
entorno z/OS crea una sinergia que permite aprovechar a DB2 la funciones
avanzadas de z/OS.
| z/OS, el sistema operativo para el hardware de IBM System z, es la próxima

| generación del sistema operativo z/OS. El sistema operativo z/OS está basado en
| z/Architecture de 64 bits. La gran capacidad de z/OS potencia las características
| más avanzadas de la tecnología de IBM System z10 y IBM System z9 y de los
| servidores de IBM eServer zSeries 990 (z990), 900 (z900), 890 (z890) y 800 (z800), lo
| cual permite al usuario gestionar cargas de trabajo empresariales incalculables.
DB2 obtiene un gran beneficio de z/Architecture. La arquitectura de DB2 for z/OS

se beneficia de la ventaja clave de z/Architecture: soporte de direccionamiento
virtual de 64 bits. Con z/Architecture de 64 bits, DB2 obtiene una ventaja
inmediata en el rendimiento.
DB2 se beneficia de las siguientes características de z/Architecture:

v Almacenamiento de 64 bits: el aumento de capacidad de memoria central de 2
GB a 64 GB elimina la mayoría de restricciones de almacenamiento. Un
almacenamiento de 64 bits significa 16 exabytes de espacio de direcciones
virtuales, un paso muy grande en la evolución constante del aumento del
almacenamiento virtual. Además de mejorar el rendimiento de DB2, el
almacenamiento de 64 bits mejora la disponibilidad y la escalabilidad, y
simplifica la gestión del almacenamiento.
v Comunicación de alta velocidad: HiperSockets permiten una comunicación
TCP/IP de alta velocidad entre particiones del mismo servidor zSeries como, por
ejemplo, entre Linux para zSeries y DB2 for z/OS.
v Gestión dinámica de cargas de trabajo: el gestor de almacenamiento de la
arquitectura de z/OS, Intelligent Resource Director (IRD), amplía las
posibilidades de Workload Manager (WLM) al gestionar los recursos de forma
dinámica basándose en prioridades de carga de trabajo.
| v Mejoras del procesador: el procesador de System z10 más reciente para DB2 es
| System z10 Integrated Information Processor (zIIP). zIIP está diseñado para
| mejorar la optimización de recursos y reducir el coste de las cargas de trabajo
| elegibles.
Además de las ventajas de z/Architecture, DB2 se beneficia de muchas otras

características del sistema operativo z/OS:
| v Alta seguridad: zSeries, z/OS y sus predecesores han proporcionado una
| seguridad eficaz durante décadas. Las características de seguridad ofrecen
| privacidad a usuarios, aplicaciones y datos, y estas características protegen la

| integridad y el aislamiento de los procesos en ejecución. Las funciones de
| seguridad actuales han evolucionado para incluir una amplia seguridad para
| redes y transacciones que funciona con muchos otros sistemas. Las mejoras en
| z/OS Security Server proporcionan opciones de seguridad mejoradas como, por
| ejemplo, seguridad de varios niveles. El entorno System z9 ofrece funciones
| criptográficas muy seguras y proporciona un rendimiento mejorado de SSL
| (Secure Sockets Layer).
v Tecnologías de software abierto: z/OS da soporte a las tecnologías de software
abierto más recientes que incluyen Enterprise JavaBeans, XML y Unicode.
v Tecnología de clúster: z/OS Sysplex paralelo proporciona tecnología de clúster
que alcanza una disponibilidad de 24 horas al día, 7 días a la semana. La
tecnología de clúster también proporciona la posibilidad de crecimiento
horizontal. El crecimiento horizontal resuelve los problemas de sobrecarga en el
rendimiento y los problemas de gestión del sistema que suelen producirse
cuando se combinan varias máquinas para acceder a la misma base de datos.
Con el crecimiento horizontal se consigue una mayor escalabilidad; el sistema
puede crecer más allá de los límites de una única máquina mientras que la base
de datos permanece intacta.
| v Procesadores más rápidos: con unos procesadores más rápidos y eficaces como,
| por ejemplo, System z10 Integrated Information Processor (zIIP), DB2 consigue
| niveles más altos de paralelismo de consultas y niveles más altos de rendimiento
| en transacciones. zIIP está diseñado para mejorar la optimización de recursos y
| reducir el coste de las cargas de trabajo elegibles mediante la mejora del rol del
| sistema principal como concentrador de datos de la empresa.
| v Tecnología de E/S mejorada: IBM Enterprise Storage Server (ESS) aprovecha las
| características de Parallel Access Volume y Multiple Allegiance de z/OS y da
| soporte a un máximo de 256 E/S por volumen de disco lógico. Un único sistema
| principal z/OS puede emitir E/S en paralelo al mismo volumen lógico y varios
| sistemas principales pueden emitir E/S a un volumen compartido en paralelo. El
| entorno System z10 da soporte al recurso Modified Indirect Data Address Word
| (MIDAW), que está diseñado para mejorar la utilización de canales y el
| rendimiento, y que potencialmente reduce los tiempos de respuesta de E/S.
| v Canales FICON: estos canales proporcionan beneficios de rendimiento
| significativos para cargas de trabajo de transacciones. Las características de
| FICON como, por ejemplo, una velocidad de transferencia de datos rápida (4 GB
| por segundo), también tienen como resultado exploraciones de tablas más
| rápidas y una mejora en el rendimiento de los programas de utilidad.
v Compresión de hardware mejorada: una compresión de hardware mejorada
tiene un efecto positivo en el rendimiento. Por ejemplo, los programas de
utilidad que ejecutan datos comprimidos se ejecutan con mayor rapidez.
DB2 en el entorno z/OS

DB2 opera como un subsistema formal de z/OS y funciona de forma eficaz con
otros subsistemas y componentes de z/OS.
DB2 funciona como un subsistema formal de z/OS. Un subsistema es un sistema

secundario o subordinado que por lo general es capaz de funcionar
independientemente, o de forma asíncrona con, un sistema de control. Un
subsistema de DB2 es una instancia diferenciada de un DBMS relacional. Su
software controla la creación, organización y modificación de una base de datos y
el acceso a los datos almacenados en la base de datos.

Los procesos de z/OS se separan en regiones que se denominan espacios de
direcciones. Los procesos de DB2 for z/OS se ejecutan en diferentes direcciones,
como se indica a continuación.
Servicios de bases de datos
| ssnmDBM1 manipula la mayoría de estructuras en las bases de datos
| creadas por el usuario. Las áreas de almacenamiento tales como
| agrupaciones de almacenamientos intermedios residen por encima de la
| barra de 2 GB del espacio de direcciones ssnmDBM1. Con un
| direccionamiento virtual de 64 bits para acceder a estas áreas de
| almacenamiento, las agrupaciones de almacenamientos intermedios pueden
| ampliarse a tamaños sumamente grandes.
Servicios del sistema
| ssnmMSTR realiza varias funciones relacionadas con el sistema.
Recurso de datos distribuidos
ssnmDIST proporciona soporte para peticiones remotas.
IRLM (gestor de bloqueo de recursos interno)
IRLMPROC controla el bloqueo de DB2.
Establecidos por WLM
Cero para muchos espacios de direcciones para procedimientos
almacenados y funciones definidas por el usuario. Los espacios de
direcciones establecidos por WLM se manejan en orden de prioridad y se
separan de otros procedimientos almacenados o funciones definidas por el
usuario que se ejecutan en otros espacios de direcciones.
Espacios de direcciones del usuario
Como mínimo uno, posiblemente varios, de los siguientes tipos de espacios
de direcciones del usuario:
v TSO
v Por lotes
v CICS
v Región dependiente de IMS
v Región de control de IMS
v WebSphere
DB2 funciona de forma eficaz con otros subsistemas y componentes de z/OS como,
por ejemplo, z/OS Security Server y el entorno Sysplex paralelo zSeries.
| Los programas de utilidad de DB2 se ejecutan en el entorno de proceso por lotes o

| de procedimiento almacenado de z/OS. Las aplicaciones que acceden a recursos de
| DB2 pueden ejecutarse en el mismo sistema z/OS en los entornos CICS, IMS, TSO,
| WebSphere, de procedimiento almacenado o de proceso por lotes, o en otros
| sistemas operativos. Estas aplicaciones pueden acceder a recursos de DB2
| utilizando los servicios de cliente/servidor del recurso de datos distribuidos (DDF)
| de DB2. IBM proporciona recursos de conexión para conectar DB2 a cada uno de
| estos entornos.
“DB2 y z/OS Security Server” en la página 56
“DB2 en un entorno Sysplex paralelo” en la página 63
“Recursos de conexión de DB2” en la página 57
“Recurso de datos distribuidos” en la página 62
Capítulo 3. Arquitectura de DB2 para z/OS 55

Gestor de bloqueos de recursos interno de DB2
El gestor de bloqueos de recursos interno (IRLM) de DB2, que es un subsistema
individual y un componente integral de DB2, trabaja con DB2 para controlar el
acceso a los datos.
IRLM se proporciona con DB2 y cada subsistema DB2 debe tener su propia
instancia de IRLM. No se puede compartir un IRLM entre subsistemas DB2 o entre
subsistemas DB2 e IMS. (IRLM también se proporciona con IMS.) Si ejecuta un
grupo de compartimiento de datos de DB2, un grupo de IRLM corresponde a
dicho grupo de compartimiento de datos.
IRLM trabaja con DB2 para serializar el acceso a los datos. DB2 solicita bloqueos
desde IRLM para asegurar la integridad de los datos cuando aplicaciones,
programas de utilidad y mandatos intentan acceder a los mismos datos.
Recomendación: Ejecute siempre con el último nivel de IRLM.
IRLM requiere control y supervisión. Las interfaces externas con IRLM incluyen:
Instalación
Instale IRLM cuando instale DB2. Considere que los bloqueos ocupan
almacenamiento y un almacenamiento adecuado para IRLM es decisivo
para el rendimiento del sistema.
Otro elemento importante para el rendimiento es hacer que el espacio de
direcciones de IRLM tenga prioridad sobre todos los espacios de
direcciones de DB2.
Mandatos
Algunos mandatos de z/OS específicos de IRLM le permiten modificar
parámetros, visualizar información sobre el estado de IRLM y la utilización
de su almacenamiento, además de iniciar y detener IRLM.
Rastreo
El recurso de rastreo de DB2 le permite realizar un rastreo de las
interacciones de bloqueo.
Puede utilizar opciones IRLMPROC y mandatos de rastreo de z/OS para
controlar los rastreos de diagnóstico para IRLM. Normalmente estos
rastreos se utilizan bajo la dirección del Servicio de soporte de software de
IBM.
“Rendimiento mejorado mediante la utilización de bloqueos” en la página 256
DB2 y z/OS Security Server

z/OS Security Server evita accesos no autorizados al sistema y puede proteger
recursos de DB2 como, por ejemplo, tablas. A veces z/OS Security Server se
denomina como RACF, que es uno de sus componentes clave.
Para controlar el acceso al sistema z/OS puede utilizar el componente Resource

Access Control Facility (RACF) de z/OS Security Server o un producto
equivalente. Cuando los usuarios inician una sesión, z/OS Security Server
comprueba sus identidades para evitar un acceso no autorizado al sistema. z/OS
Security Server proporciona una protección eficaz para datos de DB2 al permitir
únicamente un acceso gestionado por DB2 a conjuntos de datos de DB2.

Mediante z/OS Security Server puede controlar directamente la mayoría de
autorizaciones a objetos de DB2, definir autorizaciones o utilizar seguridad de
varios niveles.
Recomendación: Utilice z/OS Security Server para comprobar la identidad de los

usuarios de DB2 y proteger los recursos de DB2.
“Mecanismos de autorización y seguridad para el acceso a datos” en la página
273
″Seguridad y auditoría″ (DB2 Administration Guide)
DB2 y DFSMS
SMS (Storage Management Subsystem) DFSMSdfp se puede utilizar para gestionar
conjuntos de datos de disco de DB2.
La finalidad de DFSMS es automatizar lo máximo posible la gestión del

almacenamiento físico centralizando el control, automatizando las tareas y
proporcionando controles interactivos para los administradores del sistema. DFSMS
puede reducir las necesidades de los usuarios en relación con los detalles físicos
del rendimiento, espacio y gestión de dispositivos.
Consulte con el administrador de almacenamiento del sitio sobre cómo utilizar

DFSMS para datos privados, copias de imágenes y registros de archivado de DB2.
Los datos que son especialmente sensibles al rendimiento pueden necesitar más
control manual durante la situación del conjunto de datos.
Los espacios de tablas o índices con conjuntos de datos de más de 4 GB necesitan

conjuntos de datos gestionados por DFSMS.
Los conjuntos de datos particionados ampliados (PDSE), una característica de

DFSMSdfp, son útiles para gestionar procedimientos almacenados que se ejecutan
en un espacio de direcciones de procedimientos almacenados. PDSE permite
información de extensión para actualizar dinámicamente las bibliotecas de carga,
reducir la necesidad de iniciar y detener el espacio de direcciones de
procedimientos almacenados.
DFSMS Implementing System Managed Storage
Recursos de conexión de DB2

Un recurso de conexión proporciona la interfaz entre DB2 y otro entorno. También
puede iniciar sesiones de DB2 desde otros entornos en clientes como, por ejemplo,
Windows o UNIX utilizando interfaces que incluyan ODBC, JDBC y SQLJ.
La figura siguiente muestra los recursos de conexión de z/OS con interfaces con
DB2.

Figura 9. Recursos de conexión con interfaces con DB2
| Los entornos z/OS incluyen:

v WebSphere
v CICS (Customer Information Control System)
v IMS (Information Management System)
v TSO (Time Sharing Option)
v Por lotes
Los recursos de conexión de z/OS incluyen:

v CICS
v IMS
v TSO
v CAF (recurso de conexión de llamada)
v RRS (Resource Recovery Services)
Los recursos de conexión funcionan en los distintos entornos tal como se describe a
continuación:
v Los productos WebSphere que están integrados con DB2 incluyen WebSphere
Application Server, WebSphere Studio y Transaction Servers & Tools. En el
entorno WebSphere, puede utilizar el recurso de conexión RRS.
v CICS es un servidor de aplicaciones que proporciona gestión de transacciones en
línea para aplicaciones. En el entorno CICS, puede utilizar el recurso de
conexión CICS para acceder a DB2.
v IMS es un sistema informático de bases de datos. IMS incluye el gestor de bases
de datos jerárquico de IMS, el gestor de transacciones de IMS y productos
middleware de base de datos que proporcionan acceso a bases de datos y
transacciones de IMS. En el entorno IMS, puede utilizar el recurso de conexión
IMS para acceder a DB2.
v TSO proporciona la posibilidad de compartimiento de tiempo interactivo desde
terminales remotos. En los entornos TSO y de proceso por lotes, puede utilizar
los recursos de conexión TSO, CAF (recurso de conexión de llamada) y RRS
(Resource Recovery Services) para acceder a DB2.
| v Los entornos de procedimientos almacenados están gestionados por el
| componente Workload Manager de z/OS. En un entorno de procedimientos
| almacenados, puede utilizar el recurso de conexión RRS.
Recurso de conexión de CICS

Customer Information Control System (CICS) Transaction Server proporciona el
recurso de conexión de CICS, que le permite acceder a DB2 desde CICS.

Las operaciones de CICS, la programación de aplicaciones, la administración del
sistema y las operaciones de organizaciones pueden utilizar el recurso de conexión
de CICS.
Operaciones de CICS
Después de iniciar DB2, puede utilizar DB2 desde un terminal CICS. Puede
iniciar y detener CICS y DB2 de forma independiente y puede establecer o
terminar la conexión entre ellos en cualquier momento. También puede
permitir que CICS se conecte a DB2 de manera automática.
CICS Transaction Server también proporciona aplicaciones CICS con acceso
a datos de DB2 mientras se opera en el entorno CICS. Por lo tanto,
cualquier aplicación CICS puede acceder tanto a datos de DB2 como a
datos de CICS. En el caso de una anomalía del sistema, CICS coordina la
recuperación de los datos de DB2 y de los datos de CICS.
El recurso de conexión de CICS utiliza servicios de nivel de mandatos de
CICS cuando es necesario.
Ejemplos::
EXEC CICS WAIT EXEC CICS ABEND
Una parte del recurso de conexión de CICS se ejecuta bajo el control de la

transacción mediante la emisión de peticiones de SQL. Por lo tanto, estas
llamadas de servicios CICS parece que las emita la transacción de
aplicaciones.
Con la planificación adecuada, se puede incluir DB2 en un caso de

recuperación de XRF de CICS.
Programación de aplicaciones
Los programadores de aplicaciones que escriben programas de nivel de
mandatos de CICS pueden utilizar las mismas técnicas de codificación de
comunicación de datos para escribir las partes de comunicación de datos
de los programas de aplicaciones que acceden a datos de DB2. Tan solo
cambia la parte de base de datos de la programación. Para las partes de
base de datos, los programadores utilizan sentencias de SQL para
recuperar o modificar datos de tablas de DB2.
Para un usuario de terminal CICS, los programas de aplicaciones que
acceden a datos de CICS y de DB2 parecen idénticos a los programas de
aplicaciones que únicamente acceden a datos de CICS.
DB2 da soporte a esta programación entre productos mediante la
coordinación de los recursos de recuperación con los de CICS. Por lo tanto,
las aplicaciones CICS pueden acceder tanto a recursos controlados por
CICS como a bases de datos de DB2.
El suministro de funciones de peticiones de SQL no está soportado. En un
entorno de operación en varias regiones (MRO) de CICS, cada espacio de
direcciones de CICS puede tener su propia conexión al subsistema DB2.
Sólo puede estar conectada una única región de CICS a un único
subsistema DB2 a la vez.
Administración del sistema y operaciones

Un operador de terminal CICS autorizado puede emitir mandatos de DB2
para controlar y supervisar el recurso de conexión y DB2. Los operadores
de terminal autorizados también pueden iniciar y detener bases de datos
de DB2.
Aunque ejecute funciones de DB2 a través de CICS, necesita tener el
recurso de conexión de TSO e ISPF para aprovechar las funciones en línea
que se proporcionan con DB2 para instalar y personalizar el sistema.
También necesita la conexión de TSO para vincular paquetes y planes de
aplicaciones.
Recurso de conexión de IMS

El recurso de conexión de IMS le permite acceder a DB2 desde IMS.
El recurso de conexión de IMS recibe e interpreta peticiones para acceder a bases

de datos de DB2 utilizando rutinas de salida que forman parte de subsistemas de
IMS. Una rutina de salida es un programa que se ejecuta como una extensión de
DB2 cuando recibe el control desde DB2 para realizar funciones específicas.
Normalmente, IMS se conecta a DB2 automáticamente sin la intervención de
ningún operador.
Además de llamadas de Data Language I (DL/I) (Lenguaje de datos I) y de Fast

Path (Vía de acceso rápida), las aplicaciones de IMS pueden realizar llamadas a
DB2 utilizando sentencias de SQL incorporadas. En el caso de una anomalía del
sistema, IMS coordina la recuperación de los datos de DB2 y de los datos de IMS.
Con la planificación adecuada, se puede incluir DB2 en un caso de recuperación de

XRF (Extended Recovery Facility) de IMS.
Con el recurso de conexión de IMS, DB2 proporciona servicios de base de datos

para regiones dependientes de IMS. El soporte de proceso por lotes DL/I permite
que cualquier usuario autorizado acceda a datos de IMS y a datos de DB2 del
entorno de proceso por lotes de IMS.
La programación de aplicaciones, la administración del sistema y las operaciones

de organizaciones pueden utilizar el recurso de conexión de CICS.
Programación de aplicaciones
Con el recurso de conexión de IMS, DB2 proporciona servicios de base de
datos para regiones dependientes de IMS. El soporte de proceso por lotes
DL/I permite a los usuarios acceder a datos (DL/I) de IMS y a datos de
DB2 del entorno de proceso por lotes de IMS, que incluye:
v Acceso a DB2 y datos DL/I desde programas de aplicaciones.
v Recuperación coordinada mediante un proceso de confirmación en dos
fases.
v Utilización de llamadas de reinicio ampliado (XRST) de IMS y de punto
de comprobación simbólico (CHKP) por parte de programas de
aplicaciones para coordinar la recuperación con IMS, DB2 y archivos de
método de acceso secuencial generalizado (GSAM).
Los programadores de IMS que escriben la parte de comunicación de datos
de los programas de aplicaciones no necesitan modificar su técnica de
codificación para escribir la parte de comunicación de datos al acceder a
DB2; tan solo cambian las partes de base de datos de los programas de
aplicaciones. Para las partes de base de datos, los programadores codifican
sentencias de SQL para recuperar o modificar datos de tablas de DB2.

Para un usuario de terminal de IMS, los programas de aplicaciones de IMS
que acceden a DB2 aparecen idénticos que en IMS.
DB2 proporciona soporte a esta programación entre productos coordinando
servicios de recuperación de base de datos con los de IMS. Cualquier
programa de IMS utiliza las mismas llamadas de sincronización y
retrotracción en programas de aplicaciones que acceden a datos de DB2
que utilizan en programas de aplicaciones de IMS que acceden a datos
DL/I.
Otra ayuda para programación entre productos es el programa bajo
licencia DataPropagator de IMS, que permite actualizaciones automáticas
en tablas de DB2 cuando se actualiza información correspondiente de una
base de datos de IMS. Este producto también permite actualizaciones
automáticas en una base de datos de IMS cuando se actualiza una tabla de
DB2.
Administración del sistema y operaciones
Un operador de terminal de IMS autorizado puede emitir mandatos de
DB2 para controlar y supervisar DB2. El operador de terminal también
puede iniciar y detener bases de datos de DB2.
Aunque ejecute funciones de DB2 mediante IMS, necesita el recurso de
conexión de TSO e ISPF para beneficiarse de las funciones en línea
proporcionados con DB2 para instalar y personalizar el sistema. También
necesita el recurso de conexión de TSO para vincular paquetes y planes de
aplicaciones.
Recurso de conexión de TSO

Puede vincular planes y paquetes de aplicaciones y ejecutar varias funciones en
línea de DB2 mediante el recurso de conexión de TSO. TSO también permite a los
usuarios o trabajos autorizados de DB2 crear, modificar y mantener bases de datos
y programas de aplicaciones
Con el recurso de conexión de TSO puede acceder a DB2 ejecutando en primer

plano o por lotes. Puede acceder en primer plano mediante un terminal TSO;
puede acceder por lotes invocando el programa de supervisor de terminal (TMP)
de TSO desde un trabajo lotes.
La mayoría de aplicaciones de TSO deben utilizar el recurso de conexión de TSO,

el cual invoca el procesador de mandatos de DSN. Hay disponibles dos
procesadores de mandatos:
Procesador de mandatos de DSN
Proporciona un método alternativo para ejecutar programas que acceden a
DB2 en un entorno TSO. Este procesador se ejecuta como un procesador de
mandatos de TSO y utiliza el recurso de conexión de TSO.
DB2 Interactive (DB2I)
Consiste en paneles de Interactive System Productivity Facility (ISPF). ISPF
dispone de una conexión interactiva con DB2, que invoca el procesador de
mandatos de DSN. Mediante paneles de DB2I, puede ejecutar programas
de utilidad, mandatos y sentencias de SQL.
Tanto si accede a DB2 en primer plano o por lotes, la conexión mediante el recurso
de TSO y el procesador de mandatos de DSN hace que el acceso sea más fácil.

DSN y TSO juntos proporcionan servicios tales como conexión automática a DB2,
soporte de tecla de atención y conversión de códigos de retorno en mensajes de
error.
Cuando se utilizan servicios de DSN, la aplicación debe ejecutarse bajo el control

de DSN. Invoque el procesador de mandatos de DSN desde primer plano
emitiendo un mandato en un terminal TSO. Desde un proceso por lotes, invoque
primero TMP desde un trabajo por lotes y, a continuación, pase mandatos a TMP
en el conjunto de datos SYSTSIN.
Cuando DSN está en ejecución, puede emitir mandatos de DB2 o submandatos de

DSN. Sin embargo, no puede emitir un mandato START DB2 desde DSN. Si DB2
no está ejecución, DSN no puede establecer una conexión. Se requiere una
conexión para que DSN pueda transferir mandatos a DB2 para procesarlos.
Recurso de conexión de llamada

El recurso de conexión de llamada (CAF) proporciona una conexión alternativa para
TSO y aplicaciones por lotes que necesitan un control estricto sobre el entorno de
sesión.
Las aplicaciones que utilizan CAF pueden controlar explícitamente el estado de sus
conexiones en DB2 utilizando funciones de conexión que CAF proporciona.
Recurso de conexión de RRS (Resource Recovery Services)

La característica RRS de z/OS coordina el proceso de confirmación de recursos
recuperables en un sistema z/OS.DB2 da soporte a la utilización de estos servicios
para aplicaciones de DB2 que utilizan el recurso de conexión de RRS (RRSAF) que
DB2 proporciona.
| La implementación de z/OS Resource Recovery Services (RRS) se basa en la misma

| tecnología que CAF pero ofrece posibilidades adicionales. Utilice el recurso de
| conexión de RRS para acceder a recursos tales como tablas de SQL, bases de datos
| de DL/I, mensajes de MQSeries y archivos VSAM (Virtual Storage Access Method)
| dentro de un único ámbito de transacción. Los programas que se ejecutan por lotes
| y con TSO pueden utilizar RRSAF. Puede utilizar RRS con procedimientos
| almacenados y en un entorno WebSphere.
La conexión de RRS es necesaria para procedimientos almacenados que se ejecutan

en un espacio de direcciones establecido por WLM.
Recurso de datos distribuidos

El recurso de datos distribuidos (DDF) permite que las aplicaciones cliente que se
ejecutan en un entorno que da soporte a DRDA puedan acceder a datos de
servidores de DB2. Además, una aplicación de DB2 puede acceder a datos de otros
servidores de DB2 y de sistemas de bases de datos relacionales remotos con
soporte de DRDA.
DDF soporta los protocolos de red TCP/IP y Systems Network Architecture (SNA).
DDF permite que el servidor de DB2 actúe como pasarela para clientes y
servidores remotos. Un servidor de DB2 puede reenviar peticiones en nombre de
clientes remotos a otros servidores remotos independientemente de si los datos
solicitados están en el servidor de DB2.

Con DDF, puede tener un máximo de 150 000 hebras distribuidas conectadas a un
único servidor de DB2 al mismo tiempo. Una hebra es una estructura de DB2 que
describe la conexión de una aplicación y realiza un rastreo de su progreso.
DDF utiliza métodos para transmitir tablas de resultados de consultas que

minimizan el tráfico de la red cuando se accede a datos distribuidos. También
puede utilizar procedimientos almacenados para reducir los costes de procesador y
tiempo transcurrido del acceso distribuido. Un procedimiento almacenado es un
programa de SQL escrito por el usuario que un peticionario puede invocar en el
servidor. Cuando se encapsulan sentencias de SQL en un único mensaje en el
servidor de DB2, circulan muchos menos mensajes por el cable.
| Las aplicaciones locales de DB2 también pueden utilizar procedimientos

| almacenados para aprovechar la capacidad de encapsular sentencias de SQL que se
| comparten entre diferentes aplicaciones.
Además de optimizar el tráfico de mensajes, DDF le permite transmitir mayores

cantidades de datos de forma eficaz utilizando el ancho de banda completo de la
red.
Ejemplo: Suponga que una empresa necesita satisfacer peticiones de clientes en

cientos de ubicaciones y los representantes de la empresa que responden a estas
peticiones trabajan en ubicaciones que abarcan una amplia área geográfica. Puede
documentar las peticiones en estaciones de trabajo que disponen de DB2 Connect
Personal Edition. Esta información se sube a DB2 para z/OS. A continuación, los
representantes pueden utilizar aplicaciones de Java para acceder a la información
de peticiones de cliente de DB2 desde sus oficinas locales.
El entorno distribuido de la empresa se basa en el entorno de datos distribuidos

(DDF), que forma parte de DB2 UDB para z/OS. Las aplicaciones de DB2 pueden
utilizar DDF para acceder a datos de otros sitios de DB2 y a sistemas de bases de
datos relacionales remotos que soporten Distributed Relational Database Architecture
(DRDA). DRDA es un estándar para conectividad distribuida. Todos los servidores
de IBM DB2 soportan el estándar DRDA.
DDF también permite que las aplicaciones se ejecuten en un entorno remoto que
soporte DRDA. Estas aplicaciones pueden utilizar DDF para acceder a los datos de
servidores de DB2. Entre los ejemplos de peticionarios de aplicaciones se incluyen
IBM DB2 Connect y otros productos cliente compatibles con DRDA.
La decisión de acceder a datos distribuidos tiene implicaciones para muchas

actividades de DB2: programación de aplicaciones, recuperación de datos y
autorización, entre otras.
″Programación para DRDA″ (DB2 for z/OS Reference for Remote DRDA
Requesters and Servers)
DB2 en un entorno Sysplex paralelo

Parallel Sysplex es un ejemplo clave de la sinergia de DB2 y los entornos IBM
System z10,IBM System z9 y zSeries.

| DB2 se beneficia del entorno Sysplex paralelo con sus posibilidades superiores de
| proceso. Cuando tiene dos más procesadores que comparten los mismos datos,
| puede:
v Maximizar el rendimiento a la vez que minimiza el coste
v Mejorar la disponibilidad y simultaneidad del sistema
v Configurar el entorno del sistema para que sea más flexible
v Hacer crecer el sistema de modo incremental
Con compartimiento de datos, las aplicaciones que se ejecutan en más de un

subsistema DB2 pueden leer desde y escribir en el mismo conjunto de datos
simultáneamente. Esta posibilidad le permite acceder a datos de DB2 de forma
continuada, incluso cuando se está actualizando un nodo con software nuevo.
Los subsistemas DB2 que comparten datos deben pertenecer a un DB2 grupo de
compartimiento de datos. Un grupo de compartimiento de datos es una colección de
uno o más subsistemas DB2 que acceden a datos compartidos de DB2. Cada
subsistema DB2 que pertenece a un grupo de compartimiento de datos
determinado es un miembro de este grupo. Todos los miembros de un grupo
utilizan el mismo catálogo compartido de DB2. La figura siguiente muestra un
ejemplo de un grupo de compartimiento de datos con tres miembros.
Figura 10. Grupo de compartimiento de datos de DB2
Con un grupo de compartimiento de datos, el número de hebras que se pueden

conectar a un servidor de DB2 se multiplica por el número de subsistemas del
grupo. Por ejemplo, un grupo de compartimiento de datos de ocho miembros
puede tener alrededor de un millón de hebras simultáneas conectadas a un
servidor de DB2.
Con compartimiento de datos, puede hacer crecer el sistema de forma incremental

añadiendo complejos centrales de procesadores y subsistemas DB2 adicionales al
grupo de compartimiento de datos. No es necesario mover parte de la carga de
trabajo a otro sistema, disminuyendo la necesidad de gestionar copias de los datos
o de utilizar proceso distribuido para acceder a los datos.
Puede configurar su entorno de manera flexible. Por ejemplo, puede adaptar cada
imagen de z/OS para que cumpla los requisitos para el usuario establecido en esa
imagen. Para un proceso que tiene lugar durante periodos de carga de trabajo en
horas punta, puede activar un DB2 latente para ayudar a procesar el trabajo.

″Compartimiento de datos″ (DB2 Data Sharing: Planning and Administration)

Capítulo 4. Objetos de DB2 y sus relaciones
La creación de modelos de datos lógicos y la creación de modelos de datos físicos
son dos tareas que debe llevar a cabo para diseñar una base de daos de DB2.
Al diseñar cualquier tipo de base de datos, necesita responder a numerosas

preguntas. Lo mismo sucede al diseñar una base de datos de DB2. ¿Cómo va a
organizar los datos? ¿Cómo va a crear relaciones entre tablas? ¿Cómo debería
definir las columnas de las tablas? ¿Qué tipo de espacio de tablas debería utilizar?
Para diseñar una base de datos se realizan dos tareas generales. La primera tarea
es la creación de modelos de datos lógicos y la segunda tarea es la creación de
modelos de datos físicos. En la creación de modelos de datos lógicos, se diseña un
modelo de datos sin prestar atención a las funciones y posibilidades específicas del
DBMS que almacenará los datos. En realidad, incluso podría crear un modelo de
datos lógicos sin saber qué DBMS va a utilizar. A continuación, viene la tarea de
creación de modelos de datos físicos. Aquí ya se acerca más a una implementación
física. La finalidad básica de la etapa de diseño físico es optimizar el rendimiento a
la vez que se asegura la integridad de los datos.
| Esta información empieza con una introducción a la tarea de creación de modelos

| de datos lógicos. El tema sobre la creación de modelos de datos lógicos se centra
| en el modelo de entidad-relación y proporciona una visión general del UML
| (Unified Modeling Language) y de IBM Rational Data Architect. La información
| finaliza con la tarea de diseño físico de la base de datos.
Una vez completado el diseño lógico y físico de la base de datos, se implementa el

diseño.
Capítulo 7, “Implementación del diseño de base de datos”, en la página 177
Diseño lógico de bases de datos utilizando creación de modelos de

relación de entidad
Antes de implementar una base de datos, debe planificarla o diseñarla para que
cumpla todos los requisitos. Esta primera tarea de diseñar una base de datos se
denomina diseño lógico.
“Diseño lógico de bases de datos con Unified Modeling Language (Lenguaje de
creación de modelos unificados)” en la página 80
“Diseño físico de base de datos” en la página 82
Creación de modelos de datos

La creación de modelos de datos lógicos es el proceso de documentación sobre los
requisitos de información empresarial completos en un formato preciso y
coherente.
Para el diseño y la implementación de una base de datos satisfactoria, que

satisfaga las necesidades de una organización, se requiere un modelo de datos
lógicos. Los analistas que crean modelos de datos definen los elementos de datos y
las reglas empresariales que afectan a dichos elementos de datos. El proceso de
creación de modelos de datos considera que los datos empresariales son una
ventaja vital que es necesario que la organización comprenda y gestione con
atención. Este tema contiene información adaptada de la publicación Handbook of
Relational Database Design.
Considere los siguientes hechos empresariales que una empresa de fabricación

necesita representar en su modelo de datos:
v Los clientes compran productos.
v Los productos constan de componentes.
v Los proveedores fabrican componentes.
v Los almacenes almacenan componentes.
v Los vehículos de transporte transportan los componentes desde los proveedores
a los almacenes y, a continuación, a los fabricantes.
Todos ellos son hechos empresariales que un modelo de datos lógico de una
empresa de fabricación debe incluir. Muchas personas dentro y fuera de la empresa
cuentan con la información basada en estos hechos. Muchos informes incluyen
datos sobre estos hechos.
Cualquier negocio, no únicamente las empresas de fabricación, se puede beneficiar

de la tarea de creación de un modelo de datos. Los sistemas de bases de datos que
proporcionan información a las personas que toman decisiones, los clientes, los
proveedores y otros son más satisfactorios si se basan en un modelo de datos
adecuado.
Visión general del proceso de creación de modelos de datos
Quizás se pregunte cómo se crean los modelos de datos. Los analistas de datos
pueden realizar la tarea de creación de modelos de varias formas. (En este proceso
se supone que un analista de datos realiza los pasos, pero algunas empresas
asignan esta tarea a otras personas de la organización.) Muchos analistas de datos
siguen estos pasos:
1. Crean vistas de usuario críticas.
Los analistas empiezan la creación de un modelo de datos examinando con
atención una única actividad o función empresarial. Desarrollan una vista de
usuario, que es el modelo o representación de información crítica necesaria para
la actividad empresarial. (En una etapa posterior, el analista combina cada vista
de usuario individual con todas las otras vistas de usuario para formar un
modelo de datos lógico consolidado.) Esta etapa inicial del proceso de creación
de modelos de datos es sumamente interactivo. Debido a que los analistas no
pueden comprender por completo todas las áreas de la empresa para la que
realizan el modelo, trabajan estrechamente con los usuarios reales. El hecho de
trabajar juntos permite a los analistas y usuarios definir las principales entidades
(objetos significativos de interés) y determinar las relaciones generales entre
estas entidades.
| 2. Añaden reglas empresariales a vistas de usuario.
A continuación, los analistas añaden elementos de información detallada clave
y las reglas empresariales más importantes. Las reglas empresariales clave
afectan a las operaciones de inserción, actualización y supresión realizadas en
los datos.
Ejemplo 1: Una regla empresarial requiere que cada entidad de cliente tenga
como mínimo un identificador exclusivo. Cualquier intento de insertar o

actualizar un identificador de cliente que coincida con otro identificador de
cliente no será válido. En un modelo de datos, un identificador exclusivo recibe
el nombre de clave primaria.
3. Añaden detalles a las vistas de usuario y las valida.
Después de que los analistas han trabajo junto con los usuarios para definir las
entidades y relaciones clave, añaden otros detalles descriptivos menos vitales.
También asocian estos detalles descriptivos, llamados atributos, con las
entidades.
Ejemplo 2: Una entidad de cliente probablemente tiene un número de teléfono

asociado. El número de teléfono es un atributo no clave de la entidad de
cliente.
Los analistas también validan todas las vistas de usuario que han desarrollado.
Para validar las vistas, los analistas utilizan el proceso de normalización y
modelos de proceso. Los modelos de proceso documentan los detalles sobre cómo
la empresa utilizará los datos. Puede leer más sobre los modelos de proceso y
los modelos de datos en otras publicaciones sobre dichos temas.
4. Determinan reglas empresariales adicionales que afectan a los atributos.
A continuación, los analistas clarifican las reglas empresariales dirigidas a los
datos. Las reglas empresariales dirigidas a los datos son restricciones en valores de
datos determinados. Estas restricciones deben cumplirse, independientemente
de los requisitos de proceso particulares. Los analistas definen estas
restricciones durante la etapa de diseño de datos en lugar de durante el diseño
de aplicaciones. La ventaja de definir reglas empresariales dirigidas a los datos
es que los programadores de numerosas aplicaciones no necesitan escribir
código para imponer estas reglas empresariales.
Ejemplo 3: Suponga que una regla empresarial necesita que una entidad de
cliente disponga de un número de teléfono o una dirección, o ambas cosas. Si
esta regla no se aplica a los mismos datos, los programadores deben desarrollar,
probar y mantener aplicaciones que verifiquen la existencia de uno de estos
atributos.
Los requisitos empresariales dirigidos a los datos mantienen una relación
directa con los datos, evitando de este modo un trabajo adicional a los
programadores.
5. Integran vistas de usuario.
En esta última etapa de la creación de modelos de datos, los analistas combinan
las distintas vistas de usuario que han creado para formar un modelo de datos
lógico consolidado. Si ya existen otros modelos de datos en la organización, los
analistas integran el nuevo modelo de datos en el existente. En esta etapa, los
analistas también se esfuerzan para hacer que el modelo de datos sea flexible
de modo que pueda soportar el entorno empresarial actual y los posibles
cambios futuros.
Ejemplo 4: Suponga que una empresa minorista trabaja en un único país y que
dicha empresa planea añadir una ampliación a otros países. Con el
conocimiento de estos planes, los analistas pueden crear el modelo para que sea
suficientemente flexible para soportar la expansión a otros países.
Recomendaciones para la creación de modelos de datos lógicos
Para crear modelos de datos adecuados, los analistas siguen un método bien
planificado, que incluye:
v Trabajar interactivamente con los usuarios lo máximo posible.
Capítulo 4. Objetos de DB2 y sus relaciones 69

v La utilización de diagramas para representar la mayor parte posible del modelo
de datos lógico.
v La creación de un diccionario de datos como complemento de los diagramas de
modelos de datos lógicos. (Un diccionario de datos es un depósito de
información sobre los programas de aplicaciones, bases de datos, modelos de
datos lógicos, usuarios y autorizaciones de una organización. Un diccionario de
datos puede ser manual o automatizado.)
Creación de modelos de datos: ejemplos prácticos
Para llevar a cabo la tarea de creación de modelos de datos empiece definiendo las
entidades, los objetos significativos de interés. Las entidades son las cosas sobre las
que desea almacenar información. Por ejemplo, puede que desee definir una
entidad para los empleados denominada EMPLOYEE ya que necesita almacenar
información sobre todos los que trabajan para su organización. También puede
definir una entidad, denominada DEPARTMENT, para los departamentos.
A continuación, define las claves primarias para las entidades. Una clave primaria
es un identificador exclusivo para una entidad. En el caso de la entidad
EMPLOYEE, probablemente necesita almacenar mucha información. Sin embargo,
gran parte de esta información (como, por ejemplo, sexo, fecha de nacimiento,
dirección y fecha de contratación) no sería una opción correcta para la clave
primaria. En este caso, podría elegir un ID o número de empleado exclusivo
(EMPLOYEE_NUMBER) como clave primaria. En el caso de la entidad
DEPARTMENT, utilizaría un número de departamento exclusivo
(DEPARTMENT_NUMBER) como clave primaria.
Después de decidir sobre las entidades y sus claves primarias, puede definir las
relaciones que existen entre las entidades. Las relaciones se basan en las claves
primarias. Si tiene una entidad para EMPLOYEE y otra entidad para
DEPARTMENT, la relación que existe es que se asignan empleados a
departamentos.
Después de definir las entidades, sus claves primarias y sus relaciones, puede
definir atributos adicionales para las entidades. En el caso de la entidad
EMPLOYEE, puede definir los siguientes atributos adicionales:
v Fecha de nacimiento
v Fecha de contratación
v Dirección particular
v Número de teléfono de la oficina
v Sexo
v Currículum
Puede leer más sobre la definición de atributos más adelante en esta información.
Por último, se normalizan los datos.

“Claves de DB2” en la página 29
“Integridad de entidad, integridad de referencia y restricciones de referencia”
en la página 44
“Normalización para evitar redundancias” en la página 75
“Entidades para diferentes tipos de relaciones” en la página 71

Entidades para diferentes tipos de relaciones
En una base de datos relacional, deben definirse entidades separadas para
diferentes tipos de relaciones.
En una base de datos relacional, puede expresar varios tipos de relaciones.

Considere las posibles relaciones entre empleados y departamentos. Un empleado
determinado puede trabajar en un único departamento; esta relación es de uno con
uno para empleados. Normalmente un departamento tiene muchos empleados; esta
relación es de uno con varios para departamentos. Las relaciones pueden ser de uno
con varios, de varios con uno, de uno con uno o de varios con varios.
El tipo de una relación determinada puede variar según el entorno específico. Si

los empleados de una empresa pertenecen a varios departamentos, la relación entre
empleados y departamentos es de varios con varios.
Debe definir entidades separadas para diferentes tipos de relaciones. Cuando se

crean modelos de relaciones, puede utilizar convenios de diagramas para describir
las relaciones utilizando distintos estilos de líneas para conectar las entidades.
Relaciones de uno con uno

En un diseño de base de datos, las relaciones de uno con uno son relaciones
bidireccionales, lo que significa que tienen un único valor en ambas direcciones.
Por ejemplo, un empleado tiene un único currículum; cada currículum pertenece

únicamente a una persona. La figura siguiente muestra que existe una relación de
uno con uno entre las dos entidades. En este caso, la relación refleja las reglas en
las que un empleado sólo puede tener un currículum y que un currículum puede
pertenecer a únicamente un empleado.
Figura 11. Asignación de hechos de uno con uno a una entidad
Relaciones de uno con varios y de varios con uno

En un diseño de base de datos, una relación de uno con uno se produce cuando
una entidad tiene una relación de varios valores con otra entidad.
En la figura siguiente, puede ver que existe una relación de uno con varios entre
las dos entidades: empleado y departamento. Esta figura refuerza las reglas
empresariales en las que un departamento puede tener varios empleados, pero
cada empleado individual sólo puede trabajar para un departamento.
Figura 12. Asignación de hechos de varios con uno a una entidad

Relaciones de varios con varios
En un diseño de base de datos, una relación de varios con varios es una relación
que tiene varios valores en ambas direcciones.
La siguiente figura ilustra este tipo de relación. Un empleado puede trabajar en

más de un proyecto y un proyecto puede tener asignado más de un empleado.
Figura 13. Asignación de hechos de varios con varios a una entidad
Si observa las tablas de ejemplo de esta información, encontrará las respuestas a las
siguientes preguntas:
v ¿En qué trabaja Wing Lee?
v ¿Quién trabaja en el número de proyecto OP2012?
Ambas preguntas tienen varias respuestas. Wing Lee trabaja en los números de
proyecto OP2011 y OP2012. Los empleados que trabajan en el número de proyecto
OP2012 son Ramlal Mehta y Wing Lee.
“Tablas de ejemplo de DB2” en la página 124
Aplicación de reglas empresariales a relaciones

Tanto si una relación determinada es de uno con uno, de uno con varios, de varios
con uno o de varios con varios, es necesario que las relaciones tengan sentido
empresarialmente.
Los diseñadores de bases de datos y los analistas de datos pueden ser más eficaces
cuando tienen una buena comprensión de la empresa. Si comprenden los datos, las
aplicaciones y las reglas empresariales, pueden tener éxito al producir un diseño de
base de datos acertado.
Al definir las relaciones, se influye mucho en la ejecución de la empresa sin

problemas. Si no se realiza un buen trabajo en esta tarea, la base de datos y las
aplicaciones asociadas pueden tener muchos problemas, algunos de los cuales
pueden no manifestarse durante años.
Atributos para entidades

Cuando se definen atributos para las entidades, normalmente se trabaja con el
administrador de datos para decidir los nombres, los tipos de datos y los valores
adecuados para los atributos.
Convenios de denominación para atributos

Los convenios de denominación para atributos ayudan a los diseñadores de bases
de datos a asegurar la coherencia dentro de una organización.
La mayoría de organizaciones tienen convenios de denominación. Además de los

siguientes convenios, los administradores de bases de datos también basan las

definiciones de atributos en palabras de clases. Una palabra de clase es una única
palabra que indica la naturaleza de los datos a los que representa el atributo.
Ejemplo: La palabra de clase NUMBER indica un atributo que identifica el

número de una identidad. Por lo tanto, los nombres de atributos que identifican a
los números de identidades deben incluir la palabra de clase NUMBER. Algunos
ejemplos son EMPLOYEE_NUMBER, PROJECT_NUMBER y
DEPARTMENT_NUMBER.
Cuando una organización no tiene unas direcciones bien definidas para los
nombres de atributos, los administradores de bases de datos intentan determinar
cómo los diseñadores de bases de datos utilizan atributos denominados
históricamente. Se producen problemas cuando varias personas inventan sus
propios esquemas de denominación sin consultarse entre ellos.
Tipos de datos para atributos

Debe especificarse un tipo de datos para cada atributo.
La mayoría de organizaciones tienen directrices bien definidas para utilizar los

diferentes tipos de datos. A continuación se proporciona una visión general de los
principales tipos de datos que se pueden utilizar para los atributos de las
entidades.
Serie Datos que contienen una combinación de letras, números y caracteres
especiales. Los tipos de datos de serie se listan a continuación:
v CHARACTER: Series de caracteres de longitud fija. El nombre abreviado
común para este tipo de datos es CHAR.
v VARCHAR: Series de caracteres de longitud variable.
v CLOB: Series de objetos grandes de caracteres de longitud variable, que
se suelen utilizar cuando es posible que una serie de caracteres exceda
los límites del tipo de datos VARCHAR.
v GRAPHIC: Series gráficas de longitud fija que contienen caracteres de
doble byte.
v VARGRAPHIC: Series gráficas de longitud variable que contienen
caracteres de doble byte.
v DBCLOB: Series de longitud variable de caracteres de doble byte en un
objeto grande.
| v BINARY: Una secuencia de bytes que no está asociada a una página de
| códigos.
| v VARBINARY: Series binarias de longitud variable.
v BLOB: Series binarias de longitud variable en un objeto grande.
| v XML: Serie de longitud variable que es una representación interna de
| XML.
Numéricos
Datos que contienen dígitos. Los tipos de datos numéricos se listan a
continuación:
v SMALLINT: para enteros pequeños.
| v INTEGER: para enteros grandes.
| v BIGINT: para valores más grandes.
v DECIMAL(p,s) o NUMERIC(p,s), donde p es precisión y s es escala: para
números decimales empaquetados con precisión p y escala s. Precisión es
el número total de dígitos y escala es el número de dígitos que hay a la
derecha del separador decimal.
| v DECFLOAT: para números decimales de coma flotante.
v REAL: para números de coma flotante de precisión simple.
v DOUBLE: para números de coma flotante de precisión doble.
Fecha y hora
Valores de datos que representan fechas, horas o indicaciones de fecha y
hora. Los tipos de datos de fecha y hora se listan a continuación:
v DATE: Fechas con un valor de tres partes que representa un año, mes y
día.
v TIME: Fechas con un valor de tres partes que representa la hora del día
en horas, minutos y segundos.
v TIMESTAMP: Indicaciones de fecha y hora con un valor de siete partes
que representa una fecha y hora mediante año, mes, día, hora, minuto,
segundo y microsegundo.
Ejemplos: Puede utilizar los siguientes tipos de datos para los atributos de la
entidad EMPLOYEE:
v EMPLOYEE_NUMBER: CHAR(6)
v EMPLOYEE_LAST_NAME: VARCHAR(15)
v EMPLOYEE_HIRE_DATE: DATE
v EMPLOYEE_SALARY_AMOUNT: DECIMAL(9,2)
Los tipos de datos que selecciona son definiciones empresariales del tipo de datos.
Durante el diseño físico de bases de datos es posible que necesite cambiar
definiciones de tipos de datos o utilizar un subconjunto de estos tipos de datos.
Puede que la base de datos o el lenguaje principal no dé soporte a todas estas
definiciones o puede que realice una selección diferente por motivos de
rendimiento.
Por ejemplo, es posible que necesite representar cantidades monetarias, pero DB2 y
muchos lenguajes principales no tienen un tipo de datos MONEY. En Estados
Unidos, una selección natural del tipo de datos SQL en esta selección es
DECMAL(10,2) para representar dólares. Pero también es posible que considere el
tipo de datos INTEGER para obtener un rendimiento rápido y eficaz.
“Nombres de columna” en la página 184
Valores para atributos de clave

Cuando diseña una base de datos debe decidir qué valores son aceptables para los
distintos atributos de una entidad.
Por ejemplo, puede que no desee permitir datos numéricos en un atributo para un
nombre de persona. Los tipos de datos que elige limitan los valores que se aplican
a un atributo determinado, pero también puede utilizar otros mecanismos. Estos
otros mecanismos son dominios, valores nulos y valores por omisión.
Dominio
Un dominio describe las condiciones que un valor de atributo debe cumplir para ser
un valor válido. Algunas veces el dominio identifica un rango de valores válidos.
Cuando se define el dominio para un atributo determinado, se aplican reglas
empresariales para asegurar que los datos tengan sentido.
Ejemplos:

v Un dominio puede establecer que un atributo de número de teléfono debe ser
un valor de 10 dígitos que únicamente contenga números. No querrá que el
número de teléfono esté incompleto ni que contenga caracteres alfabéticos o
especiales con lo cual no sería válido. Puede elegir entre utilizar un tipo de
datos numérico o un tipo de datos de caracteres. Sin embargo, el dominio
establece la regla empresarial de que el valor debe ser un valor de 10 dígitos
formado por números. Antes de finalizar esta regla, considere si necesita
números de teléfono internacionales, que tienen formatos diferentes.
v Un dominio puede establecer que un atributo de mes debe ser un valor de 2
dígitos entre 01 y 12. De nuevo, puede elegir entre utilizar tipos de datos de
fecha y hora, de caracteres o numéricos para este valor, pero el dominio exige
que el valor debe estar dentro del rango de 01 a 12. En este caso, la
incorporación del mes en un tipo de datos de fecha y hora es probablemente la
mejor opción. Esta decisión debería revisarse de nuevo durante el diseño físico
de la base de datos.
Valores nulos
Al diseñar atributos para entidades, a veces puede encontrarse con que un atributo
no tiene un valor válido para cada instancia de la entidad. Por ejemplo, puede que
desee un atributo para un nombre medio de persona, pero no puede exigir un
valor porque algunas personas no tienen un nombre medio. En estos casos, puede
definir el atributo de modo que pueda contener valores nulos.
Un valor nulo es un indicador especial que representa la ausencia de un valor. La

ausencia del valor puede deberse a que es desconocido, todavía no se ha
proporcionado o no existe. DBMS trata el valor nulo como un valor real, no como
un valor cero, un blanco ni una serie vacía.
Del mismo modo que debería permitirse que algunos atributos contengan valores
nulos, otros atributos no deberían contener valores nulos.
Ejemplo: Para la entidad EMPLOYEE, puede que no desee permitir que el atributo
EMPLOYEE_LAST_NAME contenga un valor nulo.
Valores por omisión
En algunos casos, puede que no desee que un atributo específico contenga un

valor nulo, pero no desea exigir que el usuario o programa proporcione siempre
un valor. En este caso, puede ser apropiado utilizar un valor por omisión.
Un valor por omisión es un valor que se aplica a un atributo si no hay disponible

ningún otro valor válido.
Ejemplo: Suponga que no desea que el atributo EMPLOYEE_HIRE_DATE

contenga valores nulos y que no desea exigir que los usuarios proporcionen este
dato. Si los datos sobre empleados nuevos se añaden generalmente a la base de
datos el primer día de contratación del empleado, podría definir un valor por
omisión de la fecha actual.
Normalización para evitar redundancias

La normalización ayuda a evitar redundancias e incoherencias en los datos. En esta
información se describen varias formas de normalización.

Después de definir las entidades y decidir los atributos para las entidades, se
normalizan las entidades para evitar redundancias. Una entidad está normalizada
si cumple un conjunto de restricciones para una forma normal determinada, que se
describe en esta información. Las entidades pueden tener las formas normales
primera, segunda, tercera y cuarta, cada una de las cuales tiene unas determinadas
reglas asociadas. En algunos casos, el usuario sigue estas reglas y, en otros casos,
no las sigue.
Las reglas para la forma normal son acumulativas. Es decir, para que una entidad
cumpla las reglas de la segunda forma normal, también debe cumplir las reglas de
la primera forma normal. Una entidad que cumple las reglas de la cuarta forma
normal también cumple las reglas de la primera, segunda y tercera forma normal.
En el contexto de creación de modelos de datos lógicos, una instancia es una

aparición concreta. Una instancia de una entidad es un conjunto de valores de
datos para todos los atributos que corresponden a la entidad.
Ejemplo: La figura siguiente muestra una instancia de la entidad EMPLOYEE.
Figura 14. Instancia de una entidad
“Desnormalización para mejorar el rendimiento” en la página 83
Primera forma normal

Una entidad relacional cumple el requisito de la primera forma normal si cada
instancia de una entidad contiene únicamente un valor, pero varios atributos
repetitivos.
Los atributos repetitivos, a menudo denominados grupo repetitivo, son atributos

diferentes que son inherentemente iguales. En una entidad que cumple el requisito
de la primera forma normal, cada atributo es independiente y exclusivo en su
significado y en su nombre.
Ejemplo: Suponga que una entidad contiene los atributos siguientes:

EMPLOYEE_NUMBER
JANUARY_SALARY_AMOUNT
FEBRUARY_SALARY_AMOUNT
MARCH_SALARY_AMOUNT
Esta situación viola el requisito de primera forma normal, puesto que

JANUARY_SALARY_AMOUNT, FEBRUARY_SALARY_AMOUNT y
MARCH_SALARY_AMOUNT son esencialmente el mismo atributo,
EMPLOYEE_MONTHLY_SALARY_AMOUNT.
Segunda forma normal

Una entidad cumple la segunda forma normal si cada atributo que no está en la
clave primaria proporciona un hecho que depende de la clave completa.

Se produce una violación de la segunda forma normal cuando un atributo de clave
no primaria es un hecho sobre un subconjunto de una clave compuesta.
Ejemplo: Una entidad de inventario registra las cantidades de componentes

específicos que se almacenan en determinados almacenes. La figura siguiente
muestra los atributos de la entidad de inventario.
Figura 15. Clave primaria que viola la segunda forma normal
En este caso, la clave primaria consta de los atributos PART y WAREHOUSE

juntos. Debido a que el atributo WAREHOUSE_ADDRESS tan solo depende del
valor de WAREHOUSE, la entidad viola la regla para la segunda forma normal.
Este diseño puede causar varios problemas:
v Cada instancia de un componente almacenado en este almacén repite la
dirección del almacén.
v Si la dirección del almacén cambia, debe actualizarse cada instancia que hace
referencia a un componente almacenado en dicho almacén.
v Debido a la repetición, los datos pueden resultar incoherentes. Instancias
diferentes podrían mostrar direcciones diferentes para el mismo almacén.
v Si en cualquier momento el almacén no almacena ningún componente, es posible
que la dirección del almacén no exista en ninguna instancia de la entidad.
Para cumplir la segunda forma normal, la información de la figura anterior estaría

en dos entidades, tal como muestra la figura siguiente.
Figura 16. Dos entidades que cumplen la segunda forma normal
“Claves de DB2” en la página 29
Tercera forma normal

Una entidad cumple la tercera forma normal si cada atributo de clave no primaria
proporciona un hecho independiente de otros atributos no de clave y que depende
únicamente de la clave.
Se produce una violación de la tercera forma normal cuando un atributo de no

primario es un hecho sobre otro atributo no de clave.
Ejemplo: La primera entidad de la figura siguiente contiene los atributos

EMPLOYEE_NUMBER y DEPARTMENT_NUMBER. Suponga que un programa o
un usuario añade un atributo, DEPARTMENT_NAME, a la entidad. El nuevo
atributo depende de DEPARTMENT_NUMBER, mientras que la clave primaria está
en el atributo EMPLOYEE_NUMBER. Ahora la entidad viola la tercera forma
normal.
El cambio del valor de DEPARTMENT_NAME basado en la actualización de un

único empleado, David Brown, no cambia el valor de DEPARTMENT_NAME para

otros empleados del departamento. La versión actualizada de la entidad de la
figura siguiente ilustra la incoherencia resultante. Adicionalmente, la actualización
de DEPARTMENT_NAME en esta tabla no lo actualiza en otra tabla que puede
contener una columna DEPARTMENT_NAME.
Figura 17. Actualización de una entidad sin normalizar. La información de la entidad se ha

vuelto incoherente.
Puede normalizar la entidad modificando la entidad EMPLOYEE_DEPARTMENT y

creando dos entidades nuevas: EMPLOYEE y DEPARTMENT. La figura siguiente
muestra las entidades nuevas. La entidad DEPARTMENT contiene atributos para
DEPARTMENT_NUMBER y DEPARTMENT_NAME. Ahora bien, una actualización
en la que se cambia un nombre de departamento es mucho más fácil. Tan solo
debe realizar la actualización en la entidad DEPARTMENT.

Figura 18. Entidades normalizadas: EMPLOYEE, DEPARTMENT y
EMPLOYEE_DEPARTMENT
Cuarta forma normal

Una entidad pertenece a la cuarta forma normal si ninguna instancia contiene dos
o más hechos de varios valores independientes sobre una entidad.
Ejemplo: Considere la entidad EMPLOYEE. Cada instancia de EMPLOYEE podría

tener SKILL_CODE y LANGUAGE_CODE. Un empleado puede tener varias
habilidades y varios idiomas. Existen dos relaciones, una entre empleados y
habilidades y otra entre empleados e idiomas. Una entidad no pertenece a la
cuarta forma normal si representa ambas relaciones, como muestra la figura
siguiente.
Figura 19. Entidad que viola la cuarta forma normal
En lugar de ello, puede evitar esta violación creando dos entidades que
representen a ambas relaciones, como muestra la figura siguiente.
Figura 20. Entidades que pertenecen a la cuarta forma normal
Sin embargo, si los hechos son interdependientes (es decir, el empleado aplica
determinados idiomas únicamente a determinadas habilidades) no debería dividir
la entidad.

Puede colocar cualquier dato en la cuarta forma normal. Una regla correcta que
debe seguir al realizar diseño de bases de datos lógicas consiste en organizar todos
los datos de las entidades que pertenecen a la cuarta forma normal. A
continuación, decida si el resultado produce un nivel aceptable de rendimiento. Si
el rendimiento no es aceptable, la desnormalización del diseño es una buena
técnica para mejorar el rendimiento.
Diseño lógico de bases de datos con Unified Modeling Language

(Lenguaje de creación de modelos unificados)
La creación de modelos de UML se basa en principales de programación orientada
a objetos. UML define un conjunto estándar de diagramas de creación de modelos
para todas las fases de desarrollo de un sistema de software.
Esta información describe el modelo de relación de entidad del diseño de base de

datos. Otro modelo que se puede utilizar es Unified Modeling Language (UML). El
grupo de gestión de objetos es un consorcio que creó el estándar de UML. Este
tema proporciona una breve visión general de UML.
La diferencia básica entre el modelo de relación de entidad y el modelo de UML es

que, en lugar de diseñar entidades como describe esta información, el usuario crea
modelos de objetos. Conceptualmente, los diagramas de UML son como copias
azules para el diseño de un proyecto de desarrollo de software.
A continuación se proporcionan algunos ejemplos de diagramas de UML:

Clase Identifica entidades de alto nivel, conocidas como clases. Una clase describe
un conjunto de objetos que tienen los mismos atributos. Un diagrama de
clases muestra las relaciones entre clases.
Caso de uso
Presenta una vista de alto nivel de un sistema desde la perspectiva del
usuario. Un diagrama de casos de uso define las interacciones entre los
usuarios y las aplicaciones o entre aplicaciones. Estos diagramas describen
gráficamente el comportamiento del sistema. Puede trabajar con diagramas
de casos de uso para capturas requisitos del sistema, conocer cómo
funciona el sistema y especificar el comportamiento del sistema.
Actividad
Crea modelos del flujo de trabajo de un proceso empresarial, generalmente
definiendo reglas para la secuencia de actividades del proceso. Por
ejemplo, una empresa de contabilidad puede utilizar diagramas de
actividades para crear modelos de transacciones financieras.
Interacción
Muestra la secuencia necesaria de interacciones entre objetos. Los
diagramas de interacciones pueden incluir diagramas de secuencias y
diagramas de colaboraciones.
v Los diagramas de secuencias muestran interacciones entre objetos en una
secuencia basada en el tiempo que establece los roles de objetos y ayuda
a determinar interfaces y responsabilidades de clases.
v Los diagramas de colaboraciones muestran asociaciones entre objetos
que definen la secuencia de mensajes que implementan una operación o
una transacción.

Componente
Muestra las relaciones de dependencia entre componentes como, por
ejemplo, programas principales y subprogramas.
Numerosas herramientas disponibles de la familia de productos de WebSphere y

Rational facilitan la tarea de crear un modelo de UML. Los desarrolladores pueden
representar gráficamente la arquitectura de una base de datos y cómo ésta
interactúa con aplicaciones utilizando las siguientes herramientas de creación de
modelos de UML:
v WebSphere Business Integration Workbench, que proporciona un creador de
modelos de UML para crear diagramas de UML estándar.
v Un conector de WebSphere Studio Application Developer para crear modelos de
aplicaciones y servicios web de Java y para correlacionar el modelo de UML con
el modelo de relación de entidad.
v Rational Rose Data Modeler, que proporciona un entorno de creación de
modelos que conecta diseñadores de bases de datos que utilizan el modelo de
relación de entidad con desarrolladores de aplicaciones OO.
v Rational Rapid Developer, un creador de modelos global y un generador de
códigos que proporciona un entorno para diseño rápido, integración, creación y
desarrollo de aplicaciones empresariales basadas en portal, sin cables.
| v IBM Rational Data Architect (RDA) tiene una funcionalidad muy completa que
| proporciona a los profesionales de datos la posibilidad de diseñar una base de
| datos relacional o federada y de realizar análisis de impacto entre modelos.
Existen semejanzas entre componentes del modelo de relación de entidad y de

diagramas de UML. Por ejemplo, la estructura de clase se corresponde exactamente
con la estructura de entidad.
La utilización de la herramienta de creación de modelos Rational Rose Data

Modeler permite a los desarrolladores utilizar un tipo específico de diagrama para
cada tipo de modelo de desarrollo:
v Modelo empresarial: diagrama de casos de uso, diagrama de actividades,
diagrama de secuencias
v Modelos lógicos de datos o modelos de aplicaciones: diagrama de clases
v Modelos físicos de datos: diagrama de modelos de datos
El modelo lógico de datos proporciona una visión general de los requisitos

empresariales capturados ya que corresponden a entidades de datos. El diagrama
de modelo de datos representa gráficamente el modelo físico de datos. El modelo
físico de datos utiliza los requisitos capturados del modelo lógico de datos y los
aplica a lenguajes de DBMS específicos. Los modelos físicos de datos también
capturan el detalle de nivel inferior de una base de datos DBMS.
Los diseñadores de bases de datos pueden personalizar el diagrama de modelo de

datos desde otros diagramas de UML, lo cual les permite trabajar con conceptos y
terminología tales como columnas, tablas y relaciones, con los que ya están
familiarizados. Los desarrolladores también pueden transformar un modelo lógico
de datos en un modelo físico de datos.
El hecho de que el diagrama de modelo de datos incluya diagramas para crear

modelos de un todo un sistema permite que los diseñadores de bases de datos,
desarrolladores de aplicaciones y otros miembros de un equipo de desarrollo
puedan compartir y realizar un seguimiento de los requisitos empresariales
durante todo el proceso de desarrollo. Por ejemplo, los diseñadores de bases de
datos pueden capturar información como, por ejemplo, restricciones,

desencadenantes e índices directamente en el diagrama de UML. Los
desarrolladores también pueden realizar transferencias entre modelos de objetos y
datos y utilizar tipos de transformación básicos como, por ejemplo, relaciones de
varios con varios.
“Diseño lógico de bases de datos utilizando creación de modelos de relación de
entidad” en la página 67
“Diseño físico de base de datos”
Diseño físico de base de datos

El diseño físico de la base de datos optimiza el rendimiento a la vez que asegura la
integridad de los datos al evitar repeticiones innecesarias de datos. Durante el
diseño físico, se transforman las entidades en tablas, las instancias en filas y los
atributos en columnas.
Una vez completado el diseño lógico de la base de datos, se pasa al diseño físico.
El personal que realiza el diseño debe tomar decisiones que afectan al diseño físico,
algunas de las cuales se listan a continuación.
v Cómo convertir entidades en tablas físicas
v Qué atributos utilizar para las columnas de las tablas físicas
v Qué columnas de las tablas deben definirse como claves
v Qué índices deben definirse en las tablas
v Qué vistas deben definirse en las tablas
v Cómo desnormalizar las tablas
v Cómo resolver relaciones de varios con varios
| El diseño físico es el momento en que se abrevian los nombres que se han elegido
| durante el diseño lógico. Por ejemplo, puede abreviar el nombre de columna que
| identifica a los empleados, EMPLOYEE_NUMBER, como EMPNO. En DB2 para
| z/OS, debe abreviar los nombres de columna y los nombres de tabla para
| ajustarlos a la restricción física de un máximo de 30 bytes para nombres de
| columna y un máximo de 128 bytes para nombres de tabla.
La tarea de crear el diseño físico es un trabajo que realmente no acaba nunca. Es

necesario supervisar continuamente las características de rendimiento e integridad
de los datos de la base de datos a medida que pasa el tiempo. Muchos factores
necesitan mejoras periódicas en el diseño físico.
DB2 le permite cambiar muchos de los atributos clave del diseño mediante
sentencias ALTER SQL. Por ejemplo, suponga que diseña una tabla particionada de
modo que almacena datos para 36 meses. Más adelante descubre que necesita
ampliar el diseño a datos para 84 meses. Puede añadir o rotar particiones para los
36 meses actuales a fin de acomodar el nuevo diseño.
El resto de esta información incluye información valiosa que puede ayudarle a

crear y mejorar el diseño físico de la base de datos. Sin embargo, esta tarea
generalmente requiere tener más experiencia en DB2 que la probablemente tienen
la mayoría de lectores de esta información de nivel introductorio.
“Diseño lógico de bases de datos utilizando creación de modelos de relación de
entidad” en la página 67
“Diseño lógico de bases de datos con Unified Modeling Language (Lenguaje de
creación de modelos unificados)” en la página 80

Desnormalización para mejorar el rendimiento
Las reglas de normalización no consideran el rendimiento. En algunos casos, es
necesario considerar la desnormalización para mejorar el rendimiento.
Durante el diseño físico, los analistas transforman las entidades en tablas y los
atributos en columnas. Considere de nuevo el ejemplo del apartado “Segunda
forma normal” en la página 76. La columna de dirección de almacén aparece
primero como parte de una tabla que contiene información sobre componentes y
almacenes. Para normalizar adicionalmente el diseño de la tabla, los analistas
eliminan la columna de dirección de almacén de la tabla. Los analistas también
definen la columna como parte de una tabla que contiene información únicamente
sobre almacenes.
La normalización de tablas es la propuesta que se suele recomendar. Pero ¿qué

sucede si las aplicaciones necesitan información sobre componentes y almacenes,
incluidas las direcciones de los almacenes? La premisa de las reglas de
normalización es que las sentencias de SQL pueden recuperar la información
uniendo las dos tablas. El problema es que, en algunos casos, se pueden producir
problemas de rendimiento como resultado de una normalización. Por ejemplo,
algunas consultas de usuario pueden ver datos que están en una o más tablas
relacionadas; el resultado es demasiadas uniones. A medida que crece el número
de tablas, los costes de acceso pueden aumentar, según el tamaño de las tablas, los
índices disponibles, etc. Por ejemplo, si no hay índices disponibles, la unión de
numerosas tablas grandes puede tardar demasiado tiempo. Puede que necesite
desnormalizar las tablas. La desnormalización es la duplicación intencionada de
columnas en varias tablas y esto aumenta la redundancia de datos.
Ejemplo 1: Considere el diseño en que ambas tablas tienen una columna que
contiene las direcciones de almacenes. Si este diseño hace que no sean necesarias
operaciones de unión, podría ser que la redundancia valga la pena. Las direcciones
de almacenes no cambian a menudo y si cambia alguna puede utilizar SQL para
actualizar todas las instancias con bastante facilidad.
Consejo: No suponga automáticamente que todas las uniones tardan demasiado

tiempo. Si une tablas normalizadas, no es necesario mantener los mismos valores
de datos sincronizados en varias tablas. En muchos casos, las uniones son el
método de acceso más eficaz, a pesar de la sobrecarga que suponen. Por ejemplo,
algunas aplicaciones alcanzan 44 uniones en un tiempo de respuesta de
subsegundos.
Cuando crea el diseño físico, el usuario y sus colegas necesitan decidir si deben
desnormalizarse los datos. Específicamente, necesita decidir si deben combinarse
tablas o partes de tablas a las que accedan con frecuencia uniones que tienen
requisitos de alto rendimiento. Se trata de una decisión compleja sobre la cual esta
información no puede proporcionar un consejo específico. Para tomar esta decisión
necesita evaluar los requisitos de rendimiento, los diferentes métodos de acceder a
los datos y los costes de desnormalización de los datos. Debe tener en cuenta el
coste y el resultado; ¿es la duplicación, en varias tablas, de columnas solicitadas
con frecuencia menos costosa que el tiempo de llevar a cabo las uniones?
Recomendaciones:
v No desnormalice tablas a menos que tenga una buena comprensión de los datos
y las transacciones empresariales que acceden a los datos. Consulte con los
desarrolladores de aplicaciones antes de desnormalizar tablas para mejorar el
rendimiento de las consultas de los usuarios.

v Cuando decida si va a desnormalizar una tabla, considere todos los programas
que accedan de forma regular a la tabla, tanto para lectura como para
actualización. Si los programas actualizan con frecuencia una tabla, la
desnormalización de la tabla afecta al rendimiento de los programas de
actualización puesto que las actualizaciones se aplican más a varias tablas que a
una sola tabla.
En la figura siguiente, la información sobre componentes, almacenes y direcciones

de almacenes aparecen en dos tablas, ambas en la forma normal.
Figura 21. Dos tablas que cumplen la segunda forma normal
La siguiente figura ilustra la tabla desnormalizada.
Figura 22. Tabla desnormalizada
La resolución de relaciones de varios con varios es una actividad especialmente

importante puesto que ayuda a mantener la claridad e integridad en el diseño
físico de de bases de datos. Para resolver relaciones de varios con varios, se
introducen tablas asociativas, que son tablas intermedias que se utilizan para
enlazar, o asociar, dos tablas entre sí.
Ejemplo 2: Los empleados trabajan en muchos proyectos. Los proyectos tienen

muchos empleados. En el diseño lógico de bases de datos, esta relación se muestra
como una relación de varios con varios entre proyecto y empleado. Para resolver
esta relación, se crea una nueva tabla asociativa, EMPLOYEE_PROJECT. Para cada
combinación de empleado y proyecto, la tabla EMPLOYEE_PROJECT contiene una
fila correspondiente. La clave primaria para la tabla estaría formada por el número
de empleado (EMPNO) y el número de proyecto (PROJNO).
Otra decisión que debe tomar está relacionada con la utilización de grupos
repetitivos.
Ejemplo 3: Suponga que una transacción que se utiliza mucho necesita el número
de cables que se venden al mes en un año específico. Los factores de rendimiento
podrían justificar cambiar una tabla de modo que viole la regla de la primera
forma normal almacenando grupos repetitivos. En este caso, el grupo repetitivo
sería: MONTH, WIRE. La tabla contendría una fila para el número de cables
vendidos para cada mes (cables de enero, cables de febrero, cables de marzo, etc.).
Recomendación: Si decide desnormalizar los datos, documéntese en profundidad

sobre la desnormalización. Describa, de forma detallada, la lógica de la
desnormalización y los pasos que ha seguido. A continuación, si en el futuro la
organización necesita normalizar los datos, los encargados de realizar este trabajo
dispondrán de un registro preciso.
“Normalización para evitar redundancias” en la página 75

“Primera forma normal” en la página 76
Capítulo 8, “Gestión del rendimiento de DB2”, en la página 245
“Creación de índices” en la página 214
Utilización de vistas para personalizar los datos que ve un

usuario
Una vista es una forma alternativa para describir los datos que existen en una o
más tablas.
Algunos usuarios pueden encontrarse con que ninguna tabla individual contiene
todos los datos que necesitan; en lugar de ello, los datos pueden estar diseminados
entre varias tablas. Además, una tabla puede contener más datos de los que los
usuarios desean ver o más datos de los que se desea dar autorización a los
usuarios para que los vean. En estas situaciones se pueden crear vistas.
Puede desear utilizar vistas por varios motivos:

v Para limitar el acceso a determinados tipos de datos
Puede crear una vista que contenga sólo las columnas y filas seleccionadas de
una o más tablas. Los usuarios con la autorización apropiada sobre la vista tan
solo ven la información que se especifica en la definición de vista.
Ejemplo: Puede definir una vista para la tabla EMP para mostrar todas las
columnas excepto SALARY y COMM (comisión). Puede otorgar acceso a esta
vista a personas que no son directores debido a que probablemente no desea que
tengan acceso a este tipo de información.
v Para combinar datos de varias tablas
| Puede crear una vista que utilice uno de los operadores establecidos, UNION,
| INTERSECT o EXCEPT, para combinar datos de forma lógica a partir de tablas
| de resultados intermedios. Además, puede especificar DISTINCT (valor por
| omisión) o ALL con un operador establecido. Puede consultar una vista definida
| con un operador establecido como si fuera una tabla de resultados grande.
Ejemplo: Suponga que tres tablas contienen datos para un periodo de tiempo de
un mes. Puede crear una vista que sea UNION ALL de tres selecciones
completas, una para cada mes del primer trimestre del 2004. Al final del tercer
mes, puede ver datos trimestrales completos.
Puede crear una vista en cualquier momento una vez que las tablas subyacentes
existen. El propietario de un conjunto de tablas implícitamente tiene la
autorización para crear una vista para estas tablas. Un usuario con autorización
administrativa en el nivel del sistema o de base de datos puede crear una vista
para cualquier propietario de cualquier conjunto de tablas. Si disponen de la
autorización necesaria, otros usuarios también pueden crear vistas para una tabla
que no han creado.
273
“Vista que combina información de varias tablas” en la página 232
Utilización de índices para mejorar el rendimiento

Los índices se utilizan para optimizar el acceso a datos, para asegurar la
exclusividad y habilitar la agrupación en clústeres.

| Si participa en el diseño físico de una base de datos, trabaja con otros diseñadores
| para determinas qué columnas y expresiones deben indexarse. Se utilizan modelos
| de proceso que describen cómo diferentes aplicaciones accederán a los datos. Esta
| información es muy importante al decidir las estrategias de indexación para
| asegurar un rendimiento adecuado.
Las finalidades principales de un índice son:

v Optimizar el acceso a datos. En muchos casos, el acceso a datos es más rápido
con un índice que sin un índice. Si el DBMS utiliza un índice para buscar una
fila de una tabla, la exploración puede ser más rápida que cuando el DBMS
explora una tabla completa.
v Asegurar la exclusividad. Una tabla con un índice exclusivo no puede tener dos
filas con los mismos valores en la columna o columnas que forman la clave de
índice.
Ejemplo: Si las aplicaciones de nóminas utilizan números de empleado, no

pueden existir dos empleados con el mismo número de empleado.
| v Habilitar la agrupación en clústeres. Un índice de agrupación en clústeres
| mantiene las filas de una tabla en una secuencia especificada para minimizar el
| acceso de página para un conjunto de filas. Cuando un espacio de tablas está
| particionado, se produce un tipo especial de agrupación en clústeres; las filas se
| agrupan en clústeres en cada partición. La agrupación en clústeres puede estar
| en el mismo orden del particionamiento o el orden puede ser diferente.
| Ejemplo: Si la partición está en el mes y el índice de agrupación en clústeres

| está en el nombre, las filas se agrupan en clústeres en el nombre dentro del mes.
En general, los usuarios de la tabla no se dan cuenta de que se está utilizando un

índice. DB2 decide si va a utilizar el índice para acceder a la tabla.

Capítulo 5. SQL: lenguaje de DB2
Esta información contiene numerosos ejemplos de SQL para que se familiarice con
los distintos tipos de sentencias de SQL, su finalidad, su codificación y las
ocasiones en que deben utilizarse.
Modos de acceder a datos

Puede recuperar datos utilizando la sentencia SELECT de SQL para especificar una
tabla de resultados que puede proceder de una o más tablas.
En esta información, varios ejemplos de sentencias de SQL ilustran cómo codificar

y utilizar cada cláusula de la sentencia SELECT para consultar una tabla. Los
ejemplos de consultas más avanzadas explican cómo ajustar las consultas
utilizando funciones y expresiones y cómo consultar varias tablas con sentencias
más complejas que incluyen uniones, combinaciones y subconsultas. La mejor
forma de aprender sobre SQL es desarrollar sentencias de SQL similares a estos
ejemplos y, a continuación, ejecutarlas dinámicamente utilizando una herramienta
como, por ejemplo, DB2 QMF para Workstation.
Los datos que se recuperan mediante SQL siempre tienen formato de tabla. Como
las tablas de las que se recuperan datos, una tabla de resultados tiene filas y
columnas. Un programa capta estos datos de una o más filas a la vez.
Ejemplo: Considere esta sentencia SELECT:

SELECT LASTNAME, FIRSTNME
FROM EMP
WHERE DEPT = 'D11'
ORDER BY LASTNAME;
Esta sentencia SELECT devuelve la siguiente tabla de resultados:

LASTNAME FIRSTNME
======== ========
BROWN DAVID
LUTZ JENNIFER
STERN IRVING
Muchos de los ejemplos de esta información se basan en las tablas de ejemplo, que
representan información de ejemplo sobre una empresa de informática.
Capítulo 2, “Conceptos de DB2”, en la página 23
Modos de seleccionar datos de columnas

Hay disponibles varias técnicas para seleccionar columnas de una base de datos
para las tablas de resultados.
Selección de todas las columnas
| No es necesario conocer los nombres de columna para seleccionar datos de DB2.

| Utilice un asterisco (*) en la cláusula SELECT para indicar todas las columnas de
| cada fila seleccionada de la tabla especificada. DB2 selecciona las columnas en el
| orden en que las columnas se han declarado en la tabla. Las columnas ocultas

| como, por ejemplo, columnas ROWID y columnas de ID de documento XML, no se
| incluyen en el resultado de la sentencia SELECT *.
Ejemplo: Considere esta consulta:

SELECT *
FROM DEPT;
La tabla de resultados es similar a la siguiente:
Esta sentencia SELECT recupera datos de cada columna (SELECT *) de cada fila
recuperada de la tabla DEPT. Debido a que el ejemplo no especifica ninguna
cláusula WHERE, la sentencia recupera datos de todas las filas.
En este ejemplo, la quinta fila contiene un valor nulo debido a que no se identifica
ningún director para este departamento. Todos los ejemplos de salida de esta
información muestran guiones para los valores nulos.
SELECT * es lo más apropiado cuando se utiliza con SQL dinámico y definiciones

de vistas.
Recomendación: Evite utilizar SELECT * en SQL estático. Las aplicaciones de SQL

estático se escriben cuando se conoce el número de columnas que devolverá la
aplicación. Este número puede cambiar fuera de la aplicación. Si se produce un
cambio en la tabla, debe actualizar la aplicación para reflejar el número de
columnas cambiada de la tabla.
Selección de algunas columnas
Seleccione las columnas que desea especificando el nombre de cada columna.

Todas las columnas aparecen en el orden que se especifica, no en el orden que
tienen en la tabla.
Ejemplo: Observe que la tabla DEPT contiene la columna DEPTNO antes de la

columna MGRNO. Considere esta consulta:
SELECT MGRNO, DEPTNO
FROM DEPT;

MGRNO DEPTNO
====== ======
000010 A00
000020 B01
000030 C01
000060 D11
------ E21
Esta sentencia SELECT recupera datos contenidos en las dos columnas

especificadas de cada fila de la tabla DEPT. Puede seleccionar datos de 1 columna
o hasta 750 columnas con una única sentencia SELECT.
Selección de columnas derivadas
Puede seleccionar columnas que deriven de una constante, una expresión o una
función.
Ejemplo: Considere esta consulta, que contiene una expresión:

SELECT EMPNO, (SALARY + COMM)
FROM EMP;

EMPNO
====== =======
000010 56970.00
000020 44550.00
000030 41310.00
000060
. 34830.00
.
.
Esta consulta selecciona datos de todas las filas de la tabla EMP, calcula el
resultado de la expresión y devuelve las columnas en el orden en que indica la
sentencia SELECT. En la tabla de resultados, las columnas derivadas, como
(SALARY + COMM) en este ejemplo, no tienen nombres. Puede utilizar la cláusula
AS para proporcionar nombres a las columnas sin nombre.
Para ordenar las filas de la tabla de resultados según los valores de una columna
derivada, especifique un nombre para la columna utilizando la cláusula AS y
utilice este nombre en la cláusula ORDER BY.
Eliminación de filas duplicadas
La palabra clave DISTINCT elimina las filas duplicadas redundantes de la tabla de

resultados para que cada fila contenga datos exclusivos.
Ejemplo 1: Considere la consulta siguiente:

SELECT ADMRDEPT FROM DEPT;

ADMRDEPT
========
A00
A00
A00
D11
D11
Cuando se omite la palabra clave DISTINCT, se devuelve el valor de la columna

ADMRDEPT de cada fila seleccionada, aunque la tabla de resultados incluya varias
filas duplicadas.
Ejemplo 2: Compare el Ejemplo 1 con la consulta siguiente, que utiliza la palabra

clave DISTINCT para listar los números de departamento de los departamentos
administrativos:
SELECT DISTINCT ADMRDEPT
FROM DEPT;

ADMRDEPT
========
A00
D11
Puede utilizar más de una palabra clave DISTINCT en una única consulta.
Capítulo 5. SQL: lenguaje de DB2 89

Denominación de columnas de resultados
Con AS, puede denominar columnas en una cláusula SELECT. Esta palabra clave
es especialmente útil para una columna que deriva de una expresión o una
función.
Ejemplo: En la consulta siguiente, la expresión SALARY+COMM se denomina

TOTAL_SAL:
SELECT EMPNO, SALARY + COMM AS TOTAL_SAL
FROM EMP
ORDER BY TOTAL_SAL;

EMPNO TOTAL_SAL
====== =========
000320 21546.00
200340 25747.00
000330 27400.00
000200
. 29957.00
.
.
Este resultado es diferente del resultado de una consulta similar que no utiliza una
cláusula AS.
“Modos de filtrar el número de filas devueltas” en la página 97
“Valores nulos” en la página 99
“Modos de ordenar filas” en la página 104
″Sentencia select″ (Consulta de DB2 SQL)
Cómo funciona una sentencia SELECT

Las sentencias SELECT (y las sentencias de SQL en general) están formadas por
una serie de cláusulas definidas por SQL como ejecutadas en un orden lógico.
| La siguiente lista de cláusulas muestra el orden lógico de las cláusulas en una

| sentencia:
1. FROM
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
6. ORDER BY
Además:
v Las subselecciones se procesan de la subselección más interna a la subselección
más externa. Una subselección de una cláusula WHERE o una cláusula HAVING
de otra sentencia de SQL se denomina subconsulta.
| v La cláusula ORDER BY se puede incluir en una subselección, una selección
| completa o en una sentencia SELECT.
v Si utiliza una cláusula AS para definir un nombre en la cláusula SELECT más
exterior, tan solo la cláusula ORDER BY puede hacer referencia a dicho nombre.
Si utiliza una cláusula AS en una subselección, puede hacer referencia al nombre
al que define fuera de la subselección.

Ejemplo 1: Considere esta sentencia SELECT, que no es válida:
SELECT EMPNO, (SALARY + COMM) AS TOTAL_SAL
FROM EMP
WHERE TOTAL_SAL> 50000;
La cláusula WHERE no es válida porque DB2 no procesa la parte AS TOTAL_SAL

de la sentencia hasta después de procesar la cláusula WHERE. Por lo tanto, DB2 no
reconoce el nombre TOTAL_SAL que la cláusula AS define.
Ejemplo 2: Sin embargo, la siguiente sentencia SELECT es válida porque la

cláusula ORDER BY hace referencia al nombre de columna TOTAL_SAL que la
cláusula AS define:
SELECT EMPNO, (SALARY + COMM) AS TOTAL_SAL
FROM EMP
ORDER BY TOTAL_SAL;
Funciones y expresiones de SQL

Puede utilizar funciones y expresiones para controlar el aspecto y los valores de las
filas y columnas de las tablas de resultados. DB2 ofrece muchas funciones
incorporadas, entre las que se incluyen funciones de totales y funciones escalares.
Una función incorporada es una función que se proporciona con DB2 for z/OS.
Concatenación de series
Puede concatenar series utilizando el operador CONCAT o la función incorporada
CONCAT.
Cuando se concatenan los operandos de dos series, el resultado de la expresión es

una serie. Los operandos de concatenación deben ser series compatibles.

SELECT LASTNAME CONCAT ',' CONCAT FIRSTNME
FROM EMP;
Esta sentencia SELECT concatena el apellido, una coma y el nombre de cada fila de
resultados. La tabla de resultados es similar a la siguiente:
================
HAAS,CHRISTINE
THOMPSON,MICHAEL
KWAN,SALLY
STERN,IRVING
.
.
.
Una sintaxis alternativa para la sentencia SELECT previamente mostrada es la

siguiente:
SELECT LASTNAME CONCAT(CONCAT(LASTNAME,','),FIRSTNME)
FROM EMP;
En este caso, la sentencia SELECT concatena el apellido y, a continuación,

concatena el resultado con el nombre.
″CONCAT″ (Consulta de DB2 SQL)

Cálculo de valores en una o más columnas
Puede realizar cálculos en datos numéricos o de fecha y hora.
Los tipos de datos numéricos son entero binario, separador flotante decimal y
decimal. Los tipos de datos de fecha y hora son fecha, hora e indicación de fecha y
hora.
Puede recuperar valores calculados, del mismo modo que se visualizan columnas
de valores, para filas seleccionadas.

SELECT EMPNO,
SALARY / 12 AS MONTHLY_SAL,
SALARY / 52 AS WEEKLY_SAL
FROM EMP
WHERE DEPT = 'A00';

SELECT EMPNO,
SALARY / 12 AS MONTHLY_SAL,
SALARY / 52 AS WEEKLY_SAL
FROM EMP
WHERE DEPT = 'A00';
La tabla de resultados visualiza los salarios mensuales y semanales de empleados

del departamento A00. Si prefiere los resultados con únicamente dos dígitos a la
derecha del separador decimal, puede utilizar la función DECIMAL.
Ejemplo: Para recuperar el número de departamento, el número de empleado, el

salario y la comisión para los empleados cuyo salario y comisión combinados son
superiores a 45 000 $, escriba la consulta del modo siguiente:
SELECT DEPT, EMPNO, SALARY, COMM
FROM EMP
WHERE SALARY + COMM> 45000;

DEPT EMPNO SALARY COMM
==== ====== ======== =======
A00 000010 52750.00 4220.00
A00 200010 46500.00 4220.00
“Funciones escalares” en la página 94
Cálculo de valores de totales

Puede utilizar las funciones de totales de SQL para calcular los valores basados en
columnas enteras de datos. Los valores calculados pertenecen sólo a filas
seleccionadas (todas las filas que cumplen la cláusula WHERE).
Una función de totales es una operación que obtiene su resultado de la utilización de

valores de una o más filas. Una función de totales también se conoce con el
nombre de función de columna. El argumento de una función de totales es un
conjunto de valores que se obtienen de una expresión.
Puede utilizar las siguientes funciones de totales:

SUM Devuelve el valor total.
MIN Devuelve el valor mínimo.
AVG Devuelve el valor medio.

MAX Devuelve el valor máximo.
COUNT
Devuelve el número de filas seleccionadas.
| COUNT_BIG
| Devuelve el número de filas o valores de un conjunto de filas o valores. El
| resultado puede ser mayor que el valor máximo de un entero.
XMLAGG
Devuelve una concatenación de elementos XML de una colección de
elementos XML.
| Ejemplo 1: Esta consulta calcula, para el departamento A00, la suma de los

| salarios de los empleados, el salario mínimo, medio y máximo y el número de
| empleados del departamento:
| SELECT SUM(SALARY) AS SUMSAL,
| MIN(SALARY) AS MINSAL,
| AVG(SALARY) AS AVGSAL,
| MAX(SALARY) AS MAXSAL,
| COUNT(*) AS CNTSAL
| FROM EMP
| WHERE DEPT = 'A00';
| La tabla de resultados es similar a la siguiente:

|
| SUMSAL MINSAL AVGSAL MAXSAL CNTSAL
| ========= ======== ============== ======== ======
| 128500.00 29250.00 42833.33333333 52750.00 3
Puede utilizar (*) en las funciones COUNT y COUNT_BIG. En este ejemplo,

COUNT(*) devuelve las filas que DB2 procesa basándose en la cláusula WHERE.
Ejemplo 2: Esta consulta cuenta el número de empleados que se describen en la

tabla EMP:
SELECT COUNT(*)
FROM EMP;
| Puede utilizar DISTINCT con las funciones SUM, AVG, COUNT y COUNT_BIG.
| DISTINCT indica que la función seleccionada tan solo funciona en los valores
| exclusivos de una columna.
Ejemplo 3: Esta consulta cuenta las distintas ocupaciones de la tabla EMP:

SELECT COUNT(DISTINCT JOB)
FROM EMP;
Las funciones de totales como COUNT ignoran los nulos en los valores en los que
operan. El ejemplo anterior cuenta los valores de ocupaciones diferentes que no
son nulos.
Nota: No utilice DISTINCT con las funciones MAX y MIN puesto que su
utilización no afecta al resultado de estas funciones.
| Tan solo puede utilizar SUM y AVG con números. Puede utilizar MIN, MAX,
| COUNT y COUNT_BIG con cualquier tipo de datos incorporados.
″DECIMAL o DEC″ (Consulta de DB2 SQL)

Funciones escalares
DB2 ofrece numerosas funciones escalares, incluidas las funciones CHAR,
DECIMAL y NULLIF.
Como una función de totales, una función escalar produce un único valor. A
diferencia del argumento de una función de totales, un argumento de una función
escalar es un único valor.
Ejemplo: YEAR: Esta consulta, que utiliza la función escalar YEAR, devuelve el
año en que se contrató a cada empleado de un departamento concreto:
SELECT YEAR(HIREDATE) AS HIREYEAR
FROM EMP
WHERE DEPT = 'A00';

HIREYEAR
========
1975
1990
1985
La función escalar YEAR produce un único valor escalar para cada fila de EMP
que cumpla la condición de búsqueda. En este ejemplo, tres filas cumplen la
condición de búsqueda, por lo tanto YEAR tiene como resultado tres valores
escalares.
| DB2 ofrece numerosas funciones escalares, incluidas CHAR, DECIMAL y NULLIF.

| CHAR
| La función CHAR devuelve una representación de serie del valor de
| entrada.
| Ejemplo: CHAR: La sentencia de SQL siguiente establece la variable de

| lenguaje principal AVERAGE en la representación de serie de caracteres del
| salario medio de un empleado:
| SELECT CHAR(AVG(SALARY))
| INTO :AVERAGE
| FROM EMP;
| DECIMAL
| La función DECIMAL devuelve una representación decimal del valor de
| entrada.
| Ejemplo: DECIMAL: Suponga que desea cambiar el tipo de datos decimal

| para devolver un valor con la precisión y escala que prefiere. El ejemplo
| siguiente representa el salario medio de los empleados como un número
| decimal de ocho dígitos (precisión) y dos de estos dígitos están a la
| derecha del separador decimal (escala):
| SELECT DECIMAL(AVG(SALARY),8,2)
| FROM EMP;

| ==========
| 32602.30

| NULLIF
| NULLIF devuelve un valor nulo si los dos argumentos de la función son
| iguales. Si los argumentos no son iguales, NULLIF devuelve el valor del
| primer argumento.
| Ejemplo: NULLIF: Suponga que desea calcular los ingresos medios de

| todos los empleados elegibles para recibir una comisión. Todos los
| empleados elegibles tienen una comisión mayor que 0 y los empleados no
| elegibles tienen un valor 0 para la comisión:
| SELECT AVG(SALARY+NULLIF(COMM,0))
| AS "AVERAGE EARNINGS"
| FROM EMP;

| AVERAGE EARNINGS
| ================
| 35248.8461538
| La especificación de una expresión simple para la suma del salario y la comisión

en la lista de selección incluiría todos los empleados en el cálculo del promedio.
Para evitar que se incluyan los empleados que no ganan una comisión media,
puede utiliza la función NULLIF para devolver un valor nulo en su lugar. El
resultado de añadir un valor nulo para la comisión en SALARY es en sí mismo un
valor nulo y las funciones de totales, como AVG, ignoran los valores nulos. Por lo
tanto, esta utilización de NULLIF en AVG hace que la consulta excluya las filas en
las que el empleado no es elegible para una comisión.
″Funciones escalares″ (Consulta de DB2 SQL)
Funciones anidadas
Las funciones escalares y de totales se pueden anidar de varias formas.
Puede anidar funciones de las siguientes formas:

v Funciones escalares dentro de funciones escalares
Ejemplo: Suponga que desea conocer el mes y día de contratación de un

empleado concreto del departamento D11. Suponga que también desea obtener
el resultado en formato de EE.UU. (mm/dd/aaaa). Utilice esta consulta:
SELECT SUBSTR((CHAR(HIREDATE, USA)),1,5)
FROM EMP
WHERE LASTNAME = 'BROWN' AND DEPT = 'D11';

=====
03/03
v Funciones escalares dentro de funciones de totales
En algunos casos, puede que sea necesario invocar una función escalar desde
una función de totales.
Ejemplo: Suponga que desea conocer el número medio de años de empleo para
los empleados del departamento A00. Utilice esta consulta:
SELECT AVG(DECIMAL(YEAR(CURRENT DATE - HIREDATE)))
FROM EMP
WHERE DEPT = 'A00';

=======
20.6666
La forma real del resultado, 20.6666, depende de cómo se defina la variable de

lenguaje principal a la que se asigna el resultado.
v Funciones de totales dentro de funciones escalares
Ejemplo: Suponga que desea conocer el año en que se contrató el último

empleado del departamento E21. Utilice esta consulta:
SELECT YEAR(MAX(HIREDATE))
FROM EMP
WHERE DEPT = 'E21';

====
2002
“Tipos de datos de fecha, hora e indicaciones de fecha y hora” en la página 188
″Funciones de totales″ (Consulta de DB2 SQL)
″Funciones escalares″ (Consulta de DB2 SQL)
Funciones definidas por el usuario

Las funciones definidas por el usuario son programas pequeños que se pueden
escribir para realizar una operación. Puede utilizar una función definida por el
usuario siempre que pueda utilizar una función incorporada.
La sentencia CREATE FUNCTION se utiliza para crear explícitamente una función

definida por el usuario.
Ejemplo: Suponga que define un tipo diferenciado denominado US_DOLLAR. Es

posible que desee permitir que se añadan instancias de US_DOLLAR. Puede crear
una función definida por el usuario que utilice una operación de adición
incorporada y toma instancias de US_DOLLAR como entrada. Este tipo de función,
denominada función derivada, no requiere ninguna codificación de aplicación.
Como alternativa, puede crear una función definida por el usuario más compleja
que puede tomar una instancia de US_DOLLAR como entrada y, a continuación,
convertir de dólares de EE.UU. a otra moneda.
Indique la función y especifique su semántica de modo que la función cumpla sus

necesidades de programación específicas. Puede utilizar una función definida por
el usuario siempre que pueda utilizar una función incorporada.
“Creación de funciones definidas por el usuario” en la página 241
″Funciones definidas por el usuario″ (Consulta de DB2 SQL)
Expresiones CASE
Se puede utilizar una expresión CASE para ejecutar expresiones de SQL de
distintas formas, según el valor de una condición de búsqueda.
Una de las utilizaciones de una expresión CASE es para sustituir los valores de
una tabla de resultados por unos valores más significativos.

Ejemplo: Suponga que desea visualizar el número de empleado, el nombre y nivel
de educación de todos los representantes de campo de la tabla EMP. Los niveles de
formación se almacenan en la columna EDL como enteros pequeños, pero desea
sustituir los valores de esta columna por frases más descriptivas. Utilice una
consulta como la siguiente:
SELECT EMPNO, FIRSTNME, LASTNAME,
CASE
WHEN EDL<=12 THEN 'HIGH SCHOOL OR LESS'
WHEN EDL>12 AND EDL<=14 THEN 'JUNIOR COLLEGE'
WHEN EDL>14 AND EDL<=17 THEN 'FOUR-YEAR COLLEGE'
WHEN EDL>17 THEN 'GRADUATE SCHOOL'
ELSE 'UNKNOWN'
END
AS EDUCATION
FROM EMP
WHERE JOB='FLD';

EMPNO FIRSTNME LASTNAME EDUCATION
====== ======== ======== =================
000320 RAMLAL MEHTA FOUR-YEAR COLLEGE
000330 WING LEE JUNI0R COLLEGE
200340 ROY ALONZO FOUR-YEAR COLLEGE
La expresión CASE sustituye cada valor entero pequeño de EDL por una
descripción del grado de formación de cada representante de campo. Si el valor de
EDL es nulo, la expresión CASE sustituye a la palabra UNKNOWN.
Otra utilización de una expresión CASE es para evitar que se realicen operaciones
no deseadas como, por ejemplo, una división entre cero, en valores de la columna.
Ejemplo: Si desea determinar la proporción de las comisiones de los empleados

respecto a sus salarios, debe ejecutar esta consulta:
SELECT EMPNO, DEPT,
COMM/SALARY AS "COMMISSION/SALARY",
FROM EMP;
Sin embargo, esta sentencia SELECT tiene un problema. Si un empleado no ha

ganado ningún salario, se produce un error de división entre cero. Al modificar la
sentencia SELECT siguiente con una expresión CASE puede evitar una división
entre cero:
SELECT EMPNO, DEPT,
(CASE WHEN SALARY=0 THEN NULL
ELSE COMM/SALARY
END) AS "COMMISSION/SALARY"
FROM EMP;
La expresión CASE determina la proporción de comisión respecto al salario

únicamente si el salario no es cero. De lo contrario, DB2 establece la proporción en
un valor nulo.
″Expresiones CASE″ (Consulta de DB2 SQL)
Modos de filtrar el número de filas devueltas

Varios operadores de comparación diferentes en el predicado de una cláusula
WHERE le permiten filtrar el número de filas devueltas.

Puede utilizar una cláusula WHERE para seleccionar las filas que le interesan. Por
ejemplo, suponga que tan solo desea seleccionar las filas que representan a los
empleados que ganan un salario superior a $40 000. Una cláusula WHERE
especifica una condición de búsqueda. Una condición de búsqueda es el criterio que
DB2 utiliza para seleccionar filas. Para cualquier fila, el resultado de una condición
de búsqueda es verdadero, falso o desconocido. Si la condición de búsqueda se
evalúa como verdadera, la fila se califica para proceso adicional. Es decir, esta fila
puede convertirse en una fila de la tabla de resultados que devuelve la consulta. Si
la condición se evalúa como falsa o desconocida, la fila no se califica para proceso
adicional.
Una condición de búsqueda consta de uno o más predicados que se combinan

mediante la utilización de los operadores lógicos AND, OR y NOT. Un predicado
individual especifica la prueba que desea que DB2 aplique a cada fila, por ejemplo,
SALARY> 40000. Cuando DB2 evalúa un predicado para una fila, se evalúa como
verdadero, falso o desconocido. Los resultados sólo son desconocidos si un valor
(denominado operando) del predicado es nulo. Si no se conoce el salario de un
empleado determinado (y se establece en un valor nulo), el resultado del predicado
SALARY> 40000 es desconocido.
Puede utilizar varios operadores de comparación diferentes en el predicado de una

cláusula WHERE, tal como se muestra en la tabla siguiente.
| Tabla 4. Operadores de comparación utilizados en condiciones
| Tipo de
| comparación Especificado con... Ejemplo de predicado con comparación
| Igual a nulo IS NULL COMM IS NULL
| Igual a = DEPTNO = ’X01’
| No igual a <> DEPTNO <> ’X01’
| Menor que < AVG(SALARY) < 30000
| Menor que o igual a <= SALARY <= 50000
| Mayor que > SALARY> 25000
| Mayor que o igual a >= SALARY>= 50000
| Similar a otro valor LIKE NAME LIKE ’ o STATUS LIKE ’N_’
| Como mínimo uno de dos OR HIREDATE < ’2000-01-01’ OR SALARY < 40000
| predicados
| Ambos predicados AND HIREDATE < ’2000-01-01’ AND SALARY < 40000
| Entre dos valores BETWEEN SALARY BETWEEN 20000 AND 40000
| Igual a un valor de un IN (X, Y, Z) DEPTNO IN (’B01’, ’C01’, ’D11’)
| conjunto
| Compara un valor con otro DISTINCT valor 1 IS DISTINCT de valor 2
| valor
| Nota: Otro predicado, EXISTS, comprueba la existencia de determinadas filas. El resultado del predicado es
| verdadero si la tabla de resultados que devuelve la subselección contiene como mínimo una fila. De lo contrario, el
| resultado es falso.
| El predicado XMLEXISTS se puede utilizar para limitar el conjunto de filas que devuelve una consulta, basándose en
| los valores de columnas XML. El predicado XMLEXISTS especifica una expresión XPath. Si la expresión XPath
| devuelve una secuencia vacía, el valor del predicado XMLEXISTS es falso. De lo contrario, XMLEXISTS devuelve un
| valor verdadero. Se devuelven las filas que corresponden a un valor verdadero de XMLEXISTS.
|

También puede buscar las filas que no cumplen uno de los predicados utilizando
la palabra clave NOT antes del predicado especificado.
Valores nulos
Un valor nulo indica la ausencia de un valor de columna en una fila. Un valor nulo
no es igual que cero o todo blancos. Puede recuperar o excluir filas que contengan
un valor nulo en una fila específica.
Ejemplo 1: Puede utilizar una cláusula WHERE para recuperar filas que contengan
un valor nulo en una columna específica. Especifique:
WHERE nombre-columna IS NULL
Ejemplo 2: También puede utilizar un predicado para excluir los valores nulos.
Especifique:
WHERE nombre-columna IS NOT NULL
No puede utilizar el signo de igualdad para recuperar filas que contengan un valor
nulo. (WHERE nombre-columna = NULL no está permitido.)
Igualdades y desigualdades
Puede utilizar un signo de igual (=), varios símbolos de desigualdad y la palabra
clave NOT para especificar condiciones de búsqueda en la cláusula WHERE.
Cómo probar la igualdad:
Puede utilizar un signo de igual (=) para seleccionar filas para las cuales una
columna especificada contiene un valor especificado.
Para seleccionar únicamente las filas en las que el número de departamento es A00,
utilice WHERE DEPT = ’A00’ en la sentencia SELECT:
SELECT FIRSTNME, LASTNAME
FROM EMP
WHERE DEPT = 'A00';
Esta consulta recupera el nombre y apellido de cada empleado del departamento

A00.
Cómo probar desigualdades:
Puede utilizar operadores de desigualdad para especificar condiciones de

búsqueda en sentencias SELECT.
Puede utilizar las siguientes desigualdades para especificar condiciones de

búsqueda:
<> < <= > >=
Ejemplo: Para seleccionar los empleados que se contrataron antes del 1 de enero
de 2001, puede utilizar esta consulta:
SELECT HIREDATE, FIRSTNME, LASTNAME
FROM EMP
WHERE HIREDATE < '2001-01-01';
Esta sentencia SELECT recupera la fecha de contratación y el nombre de cada

empleado contratado antes del 2001.
Cómo probar la igualdad o desigualdad en un conjunto de columnas:

Puede utilizar el operador de igual o el operador de no igual para probar si un
conjunto de columnas es igual o no es igual a un conjunto de valores.
Ejemplo 1: Para seleccionar las filas en las que el número de departamento es A00
y el nivel de educación es 14, puede utilizar la consulta siguiente:
SELECT FIRSTNME, LASTNAME
FROM EMP
WHERE (DEPT, EDL) = ('A00', 14);
| Ejemplo 2: Para seleccionar las filas en las que el número de departamento no es

| A00, o el nivel de educación no es 14, puede utilizar la consulta siguiente:
| SELECT FIRSTNME, LASTNAME
| FROM EMP
| WHERE (DEPT, EDL) <> ('A00', 14);
Cómo probar una condición falsa:
Puede utilizar la palabra clave NOT para probar una condición falsa.
Puede utilizar la palabra clave NOT para seleccionar todas las filas para las que el
predicado es falso (pero no las filas para las que el predicado es desconocido). La
palabra clave NOT debe preceder al predicado.
Ejemplo: Para seleccionar todos los directores cuya compensación no es superior a

40 000 $, utilice:
SELECT DEPT, EMPNO
FROM EMP
WHERE NOT (SALARY + COMM)> 40000 AND JOB = 'MGR'
ORDER BY DEPT;
La tabla siguiente compara cláusulas WHERE que utilizan una palabra clave NOT
con operadores de comparación y cláusulas WHERE que solamente utilizan
operadores de comparación. Las cláusulas WHERE son equivalentes.
Tabla 5. Cláusulas WHERE equivalentes
Que utilizan NOT Cláusula equivalente sin NOT
WHERE NOT DEPTNO = ’A00’ WHERE DEPTNO <> ’A00’
WHERE NOT DEPTNO < ’A00’ WHERE DEPTNO>= ’A00’
WHERE NOT DEPTNO> ’A00’ WHERE DEPTNO <= ’A00’
WHERE NOT DEPTNO <> ’A00’ WHERE DEPTNO = ’A00’
WHERE NOT DEPTNO <= ’A00’ WHERE DEPTNO> ’A00’
WHERE NOT DEPTNO>= ’A00’ WHERE DEPTNO < ’A00’
No puede utilizar la palabra clave NOT directamente antes de operadores de

comparación de igualdad y desigualdad.
Ejemplo: La cláusula WHERE siguiente tiene como resultado un error:

Erróneo:
WHERE DEPT NOT = 'A00'
Ejemplo: Las dos cláusulas siguientes son equivalentes:

Correcto:
WHERE MGRNO NOT IN ('000010', '000020')
WHERE NOT MGRNO IN ('000010', '000020')

Semejanzas de datos de caracteres
Puede utilizar el predicado LIKE para especificar una serie de caracteres que sea
similar al valor de columna de las filas que desea seleccionar.
Un patrón LIKE debe coincidir con la serie de caracteres en su totalidad.

v Utilice un signo de porcentaje (%) para indicar cualquier serie de cero o más
caracteres.
v Utilice un signo de subrayado (_) para indicar cualquier carácter individual.
También puede utilizar NOT LIKE para especificar una serie de caracteres que no
es similar al valor de columna de las filas que desea seleccionar.
Cómo seleccionar valores similares a una serie de caracteres

desconocidos
El signo de porcentaje (%) indica “cualquier serie o ninguna serie.”
Ejemplo: La consulta siguiente selecciona datos de cada fila para empleados con
las iniciales D B:
SELECT FIRSTNME, LASTNAME, DEPT
FROM EMP
WHERE FIRSTNME LIKE 'D%' AND LASTNAME LIKE 'B
Ejemplo: La consulta siguiente selecciona datos de cada fila de la tabla de

departamentos, donde el nombre de departamento contiene “CENTER” en
cualquier lugar de su nombre:
SELECT DEPTNO, DEPTNAME
FROM DEPT
WHERE DEPTNAME LIKE '
Ejemplo: Suponga que la columna DEPTNO es una columna de tres caracteres de

longitud fija. Puede utilizar la siguiente condición de búsqueda para devolver filas
con números de departamento que empiecen con E y finalicen con 1:
...WHERE DEPTNO LIKE 'E%1';
En este ejemplo, si E1 es un número de departamento, su tercer carácter es un

blanco y no contiene la condición de búsqueda. Si define la columna DEPTNO
como una columna de tres caracteres de longitud variable en lugar de longitud fila,
el departamento E1 coincidiría con la condición de búsqueda. Las columnas de
longitud variable pueden tener cualquier número de caracteres, hasta el número
máximo especificado cuando se ha creado la columna, incluido éste.
Ejemplo: La consulta siguiente selecciona datos de cada fila de la tabla de

departamentos, donde el número de departamento empieza con E y contiene un 1:
FROM DEPT
WHERE DEPTNO LIKE 'E
Cómo seleccionar un valor similar a un carácter desconocido

individual
El signo de subrayado (_) indica “cualquier carácter individual.”
Ejemplo: Considere la consulta siguiente:

FROM DEPT
WHERE DEPTNO LIKE 'E_1';
En este ejemplo, ’E_1’ significa E, seguido de cualquier carácter, seguido de 1.

(Tenga cuidado: ’_’ es un carácter de subrayado, no un guión.) E_1’ selecciona
únicamente números de departamento de tres caracteres que empiezan con E y
finalizan con 1; no selecciona el número de departamento ’E1’.
“Tipos de datos de serie” en la página 184
Varias condiciones
Puede utilizar los operadores AND y OR para combinar predicados y buscar varias
condiciones.
Utilice el operador AND para especificar que una búsqueda debe cumplir ambas
condiciones. Utilice el operador OR para especificar que la búsqueda debe cumplir
como mínimo una de las condiciones.
Ejemplo: Esta consulta recupera el número de empleado, la fecha de contratación

y el salario de cada empleado contratado antes de 1998 y que gana un salario
inferior a 35 000 $ al año:
SELECT EMPNO, HIREDATE, SALARY
FROM EMP
WHERE HIREDATE < '1998-01-01' AND SALARY < 35000;
Ejemplo: Esta consulta recupera el número de empleado, la fecha de contratación

y el salario de cada empleado tanto si fue contratado antes de 1998 como si gana
un salario inferior a 35 000 $ al año o ambas cosas
Nota: :
SELECT EMPNO, HIREDATE, SALARY
FROM EMP
WHERE HIREDATE < '1998-01-01' OR SALARY < 35000;
Cómo utilizar paréntesis con AND y OR
Si utiliza más de dos condiciones con los operadores AND u OR, puede utilizar
paréntesis para especificar el orden en que desea que DB2 evalúe las condiciones
de búsqueda. Si mueve los paréntesis, el significado de la cláusula WHERE puede
cambiar significativamente.
Ejemplo: Esta consulta recupera la fila de cada empleado que cumple como
mínimo una de las condiciones siguientes:
v La fecha de contratación del empleado es anterior a 1998 y el salario es inferior a
40 000 $.
v El nivel de formación del empleado es inferior a 18.
SELECT EMPNO
FROM EMP
WHERE (HIREDATE < '1998-01-01' AND SALARY < 40000) OR (EDL < 18);
Ejemplo: Esta consulta recupera la fila de cada empleado que cumple ambas
condiciones siguientes:
v La fecha de contratación del empleado es anterior a 1998.
v El salario del empleado es inferior a 40 000 $ o el nivel de formación del
empleado es inferior a 18.

SELECT EMPNO
FROM EMP
WHERE HIREDATE < '1998-01-01' AND (SALARY < 40000 OR EDL < 18);
Ejemplo: Esta consulta recupera el número de empleado de cada empleado que

cumple una de las condiciones siguientes:
v Contratado antes de 1998 y con un salario inferior a 40 000 $.
v Contratado después del 1 de enero de 1998 y con un salario superior a 40 000 $.
SELECT EMPNO
FROM EMP
WHERE (HIREDATE < '1998-01-01' AND SALARY < 40000)
OR (HIREDATE> '1998-01-01' AND SALARY> 40000);
Cómo utilizar NOT con AND y OR
Cuando se utiliza NOT con AND y OR, la ubicación de los paréntesis es

importante.
Ejemplo: La siguiente consulta recupera el número de empleado, el nivel de

formación y la ocupación de cada empleado que cumple ambas condiciones
siguientes:
v El salario del empleado es inferior a 50 000 $.
v El nivel de formación del empleado es inferior a 18.
SELECT EMPNO, EDL, JOB
FROM EMP
WHERE NOT (SALARY>= 50000) AND (EDL < 18);
En esta consulta, el operador NOT afecta únicamente a la primera condición de

búsqueda (SALARY>= 50000).
Ejemplo: La consulta siguiente recupera el número de empleado, el nivel de

formación y la ocupación de cada empleado que cumple como mínimo una de las
condiciones siguientes:
v El salario del empleado es inferior o igual a $50 000.
v El nivel de formación del empleado es inferior o igual a 18.
SELECT EMPNO, EDL, JOB
FROM EMP
WHERE NOT (SALARY> 50000 AND EDL> 18);
Para negar un conjunto de predicados, encierre todo el conjunto entre paréntesis y

preceda el conjunto con la palabra clave NOT.
Rangos de valores
Puede utilizar BETWEEN para seleccionar filas en las que una columna tiene un
valor dentro de dos límites.
Especifique primero el límite inferior del predicado BETWEEN y, a continuación,

especifique el límite superior. Los límites son inclusivos.
| Ejemplo: Suponga que especifica la cláusula WHERE siguiente en la que el valor

| de la columna nombre-columna es un entero:
| WHERE nombre-columna BETWEEN 6 AND 8
| DB2 selecciona todas las filas cuyo valor de nombre-columna es 6, 7 u 8. Si se

| especifica un rango entre un número más grande y un número más pequeño (por
| ejemplo, BETWEEN 8 AND 6), el predicado no se evalúa nunca como verdadero.

Ejemplo: Esta consulta recupera el número de departamento y el número de
director de cada departamento cuyo número esté entre C00 y D31:
SELECT DEPTNO, MGRNO
FROM DEPT
WHERE DEPTNO BETWEEN 'C00' AND 'D31';
También puede utilizar NOT BETWEEN para seleccionar filas en las que una
columna tiene un valor que está fuera de los dos límites.
Valores de una lista

Puede utilizar el predicado IN para seleccionar cada fila que tenga un valor de
columna igual a uno de varios valores de una lista.
En la lista de valores después del predicado IN, el orden de los elementos no es

importante y no afecta al orden del resultado. Encierre la lista completa de valores
entre paréntesis y separe los elementos mediante comas; los blancos son
opcionales.
Ejemplo: La siguiente consulta recupera el número de departamento y el número

de gestor para los departamentos B01, C01 y D11:
SELECT DEPTNO, MGRNO
FROM DEPT
WHERE DEPTNO IN ('B01', 'C01', 'D11');
La utilización del predicado IN proporciona los mismos resultados que un

conjunto mucho más largo de condiciones separadas por la palabra clave OR.
Ejemplo: Como alternativa puede codificar la cláusula WHERE en la sentencia

SELECT del ejemplo anterior del modo siguiente:
WHERE DEPTNO = 'B01' OR DEPTNO = 'C01' OR DEPTNO = 'D11';
Sin embargo, el predicado IN ahorra tiempo de codificación y es más fácil de

comprender.
Ejemplo: La siguiente consulta busca los proyectos que no incluyen empleados en

el departamento C01 o E21:
SELECT PROJNO, PROJNAME, RESPEMP
FROM PROJ
WHERE DEPTNO NOT IN ('C01', 'E21');
Modos de ordenar filas

Puede utilizar la cláusula ORDER BY para recuperar filas en un orden específico.
La utilización de ORDER BY es el único modo de garantizar que las filas estén en

la secuencia deseada. Esta información muestra cómo utilizar la cláusula ORDER
BY.
″Cláusula order by″ (Consulta de DB2 SQL)
Clave de clasificación
Puede especificar el orden de las filas seleccionadas utilizando claves de
clasificación que se identifican en la cláusula ORDER BY.

Una clave de clasificación puede ser un nombre de columna, un entero que
representa el número de una columna en la tabla de resultados o una expresión.
Puede identificar más de una columna
Puede listar las filas en orden ascendente o descendente. Los valores nulos se
incluyen los últimos en una clasificación ascendente y los primeros en una
clasificación descendente.
DB2 clasifica series de la secuencia de clasificación asociada con el esquema de

codificación de la tabla. DB2 clasifica números de forma algebraica y clasifica
valores de fecha y hora de forma cronológica.
Orden ascendente
Puede recuperar resultados en orden ascendente especificando ASC en la cláusula
ORDER BY.
Ejemplo: La consulta siguiente recupera los números de empleado, los apellidos y

las fechas de contratación de los empleados del departamento A00 en orden
ascendente de fechas de contratación:
SELECT EMPNO, LASTNAME, HIREDATE
FROM EMP
WHERE DEPT = 'A00'
ORDER BY HIREDATE ASC;

EMPNO LASTNAME HIREDATE
====== ========= ==========
000010 HAAS 1975-01-01
200010 HEMMINGER 1985-01-01
000120 CONNOR 1990-12-05
Esta sentencia SELECT muestra la antigüedad de los empleados. ASC es el orden

de clasificación por omisión.
Orden descendente
Puede recuperar resultados en orden descendente especificando DESC en la
cláusula ORDER BY.
Ejemplo: Esta consulta recupera números de departamento, apellidos y números

de empleados en orden descendente del número de departamento:
SELECT DEPT, LASTNAME, EMPNO
FROM EMP
WHERE JOB = 'SLS'
ORDER BY DEPT DESC;

DEPT LASTNAME EMPNO
==== ========= ======
C01 NICHOLLS 000140
A00 HEMMINGER 200010
A00 CONNOR 000120

Claves de clasificación con varias columnas

Puede especificar más de un nombre de columna en la cláusula ORDER BY para
ordenar filas por más de un valor de columna.
Cuando varias filas tienen el mismo valor de primera columna de clasificación,

estas filas siguen el orden de la segunda columna que se identifica en la cláusula
ORDER BY, después de la tercera columna de clasificación, etc.

SELECT JOB, EDL, LASTNAME
FROM EMP
WHERE DEPT = 'A00'
ORDER BY JOB, EDL;

JOB EDL LASTNAME
==== === ==========
PRES 18 HAAS
SLS 14 CONNOR
SLS 18 HEMMMINGER
Claves de clasificación con expresiones

Puede especificar una expresión con operadores como clave de clasificación para la
tabla de resultados de una sentencia SELECT.
Cuando especifica una expresión con operadores como clave de clasificación, la

consulta a la que se aplica la clasificación debe ser una subselección.
Ejemplo: La consulta siguiente forma parte de una subselección. La consulta

recupera los números de empleado, salarios, comisiones y compensación total
(salario más comisión) para empleados con una compensación total superior a
40000. Ordene los resultados por compensación total:
SELECT EMPNO, SALARY, COMM, SALARY+COMM AS "TOTAL COMP"
FROM EMP
WHERE SALARY+COMM> 40000
ORDER BY SALARY+COMM;

EMPNO SALARY COMM TOTAL COMP
====== ======== ======= ==========
000030 38250.00 3060.00 41310.00
000020 41250.00 3300.00 44550.00
200010 46500.00 4220.00 50720.00
000010 52750.00 4220.00 56970.00
Modos de resumir valores de grupo

Puede utilizar la cláusula GROUP BY para resumir valores de grupo.

Utilice GROUP BY para agrupar filas por los valores de una o más columnas. A
continuación, puede aplicar funciones de totales a cada grupo. Puede utilizar una
expresión en la cláusula GROUP BY para especificar cómo desea agrupar las filas.
Excepto las columnas indicadas en la cláusula GROUP BY, la sentencia SELECT

debe especificar las columnas seleccionadas como un operando de una de las
funciones de totales.
Ejemplo: Esta consulta lista, para cada departamento, el nivel de formación más
alto y más bajo dentro del departamento. La tabla de resultados es similar a la
siguiente:
SELECT DEPT, MIN(EDL), MAX(EDL)
FROM EMP
GROUP BY DEPT;
DEPT
==== == ==
A00 14 18
B01 18 18
C01 18 20
D11 16 18
E21 14 16
Si una columna especificada en la cláusula GROUP BY contiene valores nulos, DB2

considera que estos valores nulos son iguales y todos los nulos forman un único
grupo.
Dentro de la sentencia SELECT, la cláusula GROUP BY sigue a la cláusula FROM y

cualquier cláusula WHERE, y precede a las cláusulas HAVING y ORDER BY.
También puede agrupar las filas por los valores de más de una columna.
Ejemplo: Esta consulta busca el salario medio de los empleados con la misma
ocupación en los departamentos D11 y E21:
SELECT DEPT, JOB, AVG(SALARY) AS AVG_SALARY
FROM EMP
WHERE DEPT IN ('D11', 'E21')
GROUP BY DEPT, JOB;

DEPT JOB AVG_SALARY
==== === ==============
D11 DES 28790.00000000
D11 MGR 32250.00000000
E21 FLD 23053.33333333
En este ejemplo, DB2 agrupa la primera fila por número de departamento y a

continuación (dentro de cada departamento) por ocupación antes de determinar el
valor de salario medio para cada grupo.
Ejemplo: Esta consulta busca el salario medio para todos los empleados que se
contrataron en el mismo año. Puede utilizar la siguiente subselección para agrupar
las filas por año de contratación:
SELECT AVG(SALARY), YEAR(HIREDATE)
FROM EMP
GROUP BY YEAR(HIREDATE);
″Cláusula group by″ (Consulta de DB2 SQL)

Modos de fusionar listas de valores

Puede utilizar la palabra clave UNION para fusionar listas de valores.
Una unión es una operación de SQL que combina los resultados de dos sentencias
SELECT para formar una única tabla de resultados. Cuando DB2 encuentra la
palabra clave UNION, procesa cada sentencia SELECT para formar una tabla de
resultados temporales. A continuación, DB2 combina la tabla de resultados
temporales de cada sentencia. Si utiliza UNION para combinar dos columnas con
el mismo nombre, la columna correspondiente de la tabla de resultados hereda este
nombre.
Puede utilizar la palabra clave UNION para obtener diversas filas en la tabla de
resultados de una unión o puede utilizar UNION con la palabra clave opcional
ALL para obtener todas las filas, incluidos los duplicados.
Cómo eliminar duplicados

Utilice UNION para eliminar duplicados al fusionar listas de valores que se
obtienen de varias tablas. El ejemplo siguiente combina valores de la tabla EMP y
de la tabla EMPPROJACT.
Ejemplo 1: Liste los números de empleado de todos los empleados para los cuales
se cumplen las siguientes sentencias:
v El número de departamento de empleado empieza con ’D’.
v El empleado se asigna a proyectos cuyos números de proyecto empiezan con
’MA’.
SELECT EMPNO FROM EMP
WHERE DEPT LIKE 'D%'
UNION
SELECT EMPNO FROM EMPPROJACT
WHERE PROJNO LIKE 'MA

EMPNO
======
000010
000020
000060
000200
000220
El resultado es la unión de dos tablas de resultados, una formada a partir de la

tabla EMP y otra formada a partir de la tabla EMPPROJACT. El resultado, una
tabla de una columna, es una lista de números de empleados. Las entradas de la
lista son diferentes.
Cómo conservar duplicados
Si desea conservar los duplicados en el resultado de una unión, especifique la

palabra clave opcional ALL después de la palabra clave UNION.
Ejemplo 1: Sustituya la palabra clave UNION del ejemplo anterior por UNION
ALL:

SELECT EMPNO FROM EMP
WHERE DEPT LIKE 'D%'
UNION ALL
SELECT EMPNO FROM EMPPROJACT
WHERE PROJNO LIKE 'MA

EMPNO
======
000220
000200
000060
000010
000020
000010
Ahora, 000010 se incluye en la lista más de una vez debido a que este empleado
trabaja en un departamento que empieza con ’D’ y también trabaja en un proyecto
que empieza con ’MA’.
″Selección completa″ (Consulta de DB2 SQL)
Modos de especificar condiciones de búsqueda

Puede utilizar la cláusula HAVING de varios modos para especificar condiciones
de búsqueda.
Utilice HAVING para especificar una condición de búsqueda que cada grupo
recuperado debe cumplir. La cláusula HAVING actúa como una cláusula WHERE
para grupos y puede contener el mismo tipo de condiciones de búsqueda que se
especifican en una cláusula WHERE. La condición de búsqueda de la cláusula
HAVING prueba las propiedades de cada grupo en lugar de las propiedades de
filas individuales del grupo.

SELECT DEPT, AVG(SALARY) AS AVG_SALARY
FROM EMP
GROUP BY DEPT
HAVING COUNT(*)> 1
ORDER BY DEPT;

DEPT AVG_SALARY
==== ==============
A00 42833.33333333
C01 31696.66666666
D11 29943.33333333
E21 23053.33333333
La cláusula HAVING COUNT(*)> 1 asegura que sólo se visualicen los

departamentos con más de un miembro. (En este caso, el departamento B01 no se
visualiza porque tan solo está formado por un empleado.)
Ejemplo: Puede utilizar la cláusula HAVING para recuperar el salario medio y el

nivel de formación mínimo de los empleados contratados después de 1990 y que
informan a los departamentos en los que el nivel de formación es mayor o igual
que 14. Si suponemos que desea obtener resultados sólo para los departamentos
A00 y D11, la siguiente sentencia de SQL prueba la propiedad de grupo,
MIN(EDL):

SELECT DEPT, AVG(SALARY) AS AVG_SALARY,
MIN(EDL) AS MIN_EDL
FROM EMP
WHERE HIREDATE>= '1990-01-01' AND DEPT IN ('A00', 'D11')
GROUP BY DEPT
HAVING MIN(EDL)>= 14;

DEPT AVG_SALARY MIN_EDL
==== ============== =======
A00 29250.00000000 14
D11 29943.33333333 16
Si especifica GROUP BY y HAVING, la cláusula HAVING debe seguir a la cláusula

GROUP BY en la sintaxis. Una función de una cláusula HAVING puede incluir
varias apariciones de la cláusula DISTINCT. También puede conectar varios
predicados de una cláusula HAVING con AND y OR, y puede utilizar NOT para
cualquier predicado de una condición de búsqueda.
“Modos de resumir valores de grupo” en la página 106
″Cláusula having″ (Consulta de DB2 SQL)
″Cláusula where″ (Consulta de DB2 SQL)
Modos de unir datos de más de una tabla

| Si desea ver información de varias tablas, puede utilizar una sentencia SELECT,
| que recupera y une valores de columna de una o más tablas en una única fila. La
| recuperación se basa en una condición especificada, generalmente de coincidencia
| de valores de columna.
Normalmente, el principal componente de una unión es la coincidencia de valores

de columna de filas de cada tabla que participa en la unión. El resultado de una
unión asocia filas de una tabla con filas de otra tabla. Según el tipo de operación
de unión, pueden formarse algunas filas que contengan valores de columna de una
tabla que no coincidan con valores de columna de otra tabla.
| Una tabla unida especifica una tabla de resultados intermedios que es el resultado
| de una unión interna o una unión externa. La tabla se obtiene aplicando uno de los
| operadores de unión (INNER, FULL OUTER, LEFT OUTER o RIGHT OUTER) a
| sus operandos.
DB2 da soporte a uniones internas y uniones externas (izquierda, derecha y

completa).
DB2 da soporte a uniones internas y uniones externas (izquierda, derecha y

completa).
Unión interna
Combina cada fila de la tabla izquierda con cada fila de la tabla derecha,
conservando sólo las filas en las que la condición de unión se cumple.
Unión externa
Incluye las filas producidas por la unión interna, más las filas que faltan,
según el tipo de unión externa:

Unión externa izquierda
Incluye las filas de la tabla izquierda que faltaban en la unión
interna.
Unión externa derecha
Incluye las filas de la tabla derecha que faltaban en la unión
interna.
Unión externa completa
Incluye las filas de ambas tablas que faltaban en la unión interna.
La mayoría de ejemplos de este tema utilizan dos tablas de ejemplo: la tabla de

componentes (PARTS) y la tabla de productos (PRODUCTS), formada por
existencias de hardware.
La figura siguiente muestra que cada fila de la tabla PARTS contiene datos de de
un único componente: el nombre de componente, el número de componente y el
proveedor del componente.
Figura 23. Tabla PARTS de ejemplo
La figura siguiente muestra que cada fila de la tabla PRODUCTS contiene datos
para un único producto: el número, el nombre y el precio del producto.
Figura 24. Tabla PRODUCTS de ejemplo
La figura siguiente muestra las distintas formas de combinar las tablas PARTS y
PRODUCTS utilizando funciones de unión externa. La ilustración se basa en un
subconjunto de columnas de cada tabla.

Figura 25. Uniones externas de dos tablas. Cada unión se realiza en la columna PROD#.
Una unión interna consta de filas formadas a partir de las tablas PARTS y
PRODUCTS, basándose en la coincidencia de igualdad de valores de columna
entre la columna PROD# de la tabla PARTS y la columna PROD# de la tabla
PRODUCTS. La unión interna no contiene ninguna fila formada a partir de
columnas no coincidentes cuando las columnas PROD# no son iguales.
Se pueden especificar uniones en la cláusula FROM de una consulta. Se unen los

datos de las filas que cumplen las condiciones de búsqueda de todas las tablas
para formar la tabla de resultados.
Las columnas resultantes de una unión tienen nombres si la lista SELECT más
exterior hace referencia a columnas base. Sin embargo, si se utiliza una función
(por ejemplo, COALESCE) para crear una columna del resultado, dicha columna
no tiene ningún nombre a menos que se utilice la cláusula AS en la lista SELECT.
Unión interna
Puede solicitar una unión interna, ejecutando una sentencia SELECT en la que
especifique las tablas a las que desea unir la cláusula FROM y especificar una
cláusula WHERE o una cláusula ON para indicar la condición de unión. La
condición de unión puede ser cualquier condición de búsqueda simple o
compuesta que no contenga ninguna referencia de subconsulta.
En el tipo más simple de unión interna, la condición de unión es

columna1=columna2.
Ejemplo: Puede unir las tablas PARTS y PRODUCTS en la columna PROD# para
formar una tabla de componentes con sus proveedores y los productos que utilizan
los componentes. Considere las dos sentencias SELECT siguientes:

SELECT PART, SUPPLIER, PARTS.PROD#, PRODUCT
FROM PARTS, PRODUCTS
WHERE PARTS.PROD# = PRODUCTS.PROD#;
FROM PARTS INNER JOIN PRODUCTS
ON PARTS.PROD# = PRODUCTS.PROD#;
Cualquiera de estas sentencias produce el resultado siguiente:

PART SUPPLIER PROD# PRODUCT
======= ============ ===== =========
WIRE ACWF 10 GENERATOR
MAGNETS BATEMAN 10 GENERATOR
BLADES ACE_STEEL 205 SAW
PLASTIC PLASTIK_CORP 30 RELAY
Observe tres cosas en este ejemplo:

v Un componente de la tabla PARTS (OIL) tiene un número de producto (160) que
no está en la tabla PRODUCTS. Un producto (505, SCREWDRIVER) no tiene
componentes listados en la tabla PARTS. Ni OIL ni SCREWDRIVER aparecen en
el resultado de la unión.
v La sintaxis explícita expresa que esta unión es una unión interna. Puede utilizar
INNER JOIN en la cláusula FROM en lugar de la coma. ON (más que WHERE)
especifica la condición de unión cuando se unen tablas explícitamente en la
cláusula FROM.
v Si no especifica una cláusula WHERE en la primera forma de la consulta, la
tabla de resultados contiene todas las combinaciones posibles de filas para las
tablas que se identifican en la cláusula FROM. Puede obtener el mismo resultado
especificando una condición de unión que sea siempre verdadera en la segunda
forma de la consulta.

ON 1=1;
El número de filas de la tabla de resultados es el producto del número de filas

de cada tabla:
======= ============ ===== ===========
WIRE ACWF 10 SCREWDRIVER
WIRE ACWF 10 RELAY
WIRE ACWF 10 SAW
OIL WESTERN_CHEM 160 SCREWDRIVER
OIL WESTERN_CHEM 160 RELAY
OIL WESTERN_CHEM 160 SAW
OIL
. WESTERN_CHEM 160 GENERATOR
.
.
Puede especificar condiciones de unión más complicadas para obtener diferentes

conjuntos de resultados.
Ejemplo: Para eliminar los proveedores que empiezan con la letra A de la tabla de
componentes, proveedores, números de producto y productos, escriba una consulta
como la siguiente:

ON PARTS.PROD# = PRODUCTS.PROD#
AND SUPPLIER NOT LIKE 'A%';
El resultado de la consulta es todas las filas que no tienen un proveedor que

empieza con la letra A:
======= ============ ===== =========
Ejemplo: En este ejemplo se une la tabla PROJ a sí misma utilizando una unión
interna. La consulta devuelve el número y nombre de cada proyecto principal,
seguido del número y nombre del proyecto que forma parte del mismo:
SELECT A.PROJNO, A.PROJNAME, B.PROJNO, B.PROJNAME
FROM PROJ A, PROJ B
WHERE A.PROJNO = B.MAJPROJ;
En este ejemplo, A indica la primera instancia de la tabla PROJ y B indica una

segunda instancia de esta tabla. La condición de unión es una condición en la que
el valor de la columna PROJNO de la tabla PROJ A debe ser igual al valor de la
columna MAJPROJ de la tabla PROJ B.

PROJNO PROJNAME PROJNO PROJNAME
====== =============== ====== ====================
IF2000 USER EDUCATION MA2100 DOCUMENTATION
MA2100 DOCUMENTATION MA2110 SYSTEM PROGRAMMING
OP2011 SYSTEMS SUPPORT OP2012 APPLICATIONS SUPPORT
En este ejemplo, la coma en la cláusula FROM especifica implícitamente una unión

interna y actúa del mismo modo que si se hubieran utilizado las palabras clave
INNER JOIN. Cuando utiliza la coma para una unión interna, debe especificar la
condición de unión en la cláusula WHERE. Cuando utiliza las palabras clave
INNER JOIN, debe especificar la condición de unión en la cláusula ON.
“Subconsultas” en la página 117
“Modos de acceder a datos” en la página 87
Unión externa izquierda

| La cláusula LEFT OUTER JOIN incluye filas de la tabla que se especifica antes de
| LEFT OUTER JOIN que no tienen valores coincidentes en la tabla que se especifica
| después de LEFT OUTER JOIN.
Al igual que en una unión interna, la condición de unión de una unión externa
izquierda puede ser cualquier condición de búsqueda simple o compuesta que no
contenga ninguna referencia de subconsulta.
Ejemplo: Para incluir filas de la tabla PARTS que no tengan valores coincidentes
en la tabla PRODUCTS e incluir los precios superiores a $10.00, ejecute esta
consulta:

SELECT PART, SUPPLIER, PARTS.PROD#, PRODUCT, PRICE
FROM PARTS LEFT OUTER JOIN PRODUCTS
ON PARTS.PROD#=PRODUCTS.PROD#
AND PRODUCTS.PRICE>10.00;

PART SUPPLIER PROD# PRODUCT PRICE
======= ============ ===== ========= =====
WIRE ACWF 10 GENERATOR 45.75
MAGNETS BATEMAN 10 GENERATOR 45.75
OIL WESTERN_CHEM 160 --------- -----
BLADES ACE_STEEL 205 SAW 18.90
PLASTIC PLASTIK_CORP 30 --------- -----
Debido a que la tabla PARTS puede tener filas que no coincidan con valores de las
columnas unidas y debido a que la columna PRICE no está en la tabla PARTS, las
filas en las que el valor de PRICE no es superior a $10.00 se incluyen en el
resultado de la unión, pero el valor de PRICE se establece como nulo.
En esta tabla de resultados, la fila para PROD# 160 tiene valores nulos en las dos
columnas de la derecha debido a que PROD# 160 no coincide con otro número de
producto. PROD# 30 tiene valores nulos en las dos columnas de la derecha debido
a que el precio de PROD# 30 es inferior a $10.00.
“Subconsultas” en la página 117
Unión externa derecha

| La cláusula RIGHT OUTER JOIN incluye las filas de la tabla que se especifica
| después de RIGHT OUTER JOIN que no tienen valores coincidentes en la tabla
| que se especifica antes de RIGHT OUTER JOIN.
Al igual que en una unión interna, la condición de unión de una unión externa
derecha puede ser cualquier condición de búsqueda simple o compuesta que no
contenga ninguna referencia de subconsulta.
Ejemplo: Para incluir las filas de la tabla PRODUCTS que no tengan valores
coincidentes en la tabla PARTS y para incluir únicamente los precios superiores a
$10.00, ejecute la consulta siguiente:
SELECT PART, SUPPLIER, PRODUCTS.PROD#, PRODUCT, PRICE
FROM PARTS RIGHT OUTER JOIN PRODUCTS
ON PARTS.PROD# = PRODUCTS.PROD#
WHERE PRODUCTS.PRICE>10.00;

PART SUPPLIER PROD# PRODUCT PRICE
======= ============ ===== ========== =====
MAGNETS BATEMAN 10 GENERATOR 45.75
WIRE ACWF 10 GENERATOR 45.75
BLADES ACE_STEEL 205 SAW 18.90
Debido a que la tabla PRODUCTS no puede tener filas que no coincidan con
valores de las columnas unidas y debido a que la columna PRICE está en la tabla
PRODUCTS, las filas en las que el valor de PRICE no es superior a $10.00 no se
incluyen en el resultado de la unión.

Unión externa completa

La cláusula FULL OUTER JOIN produce como resultado la inclusión de filas de
ambas tablas. Si falta un valor cuando se unen las filas, este valor es nulo en la
tabla de resultados.
La condición de unión para una unión externa completa debe ser una condición de
búsqueda que compare dos columnas. Los predicados de la condición de búsqueda
se pueden combinar únicamente con AND. Cada predicado debe tener la forma
’expresión = expresión’.
Ejemplo 1: Esta consulta realiza una unión externa completa de las tablas PARTS y
PRODUCTS:
FROM PARTS FULL OUTER JOIN PRODUCTS

======== ============ ===== ===========
OIL WESTERN_CHEM 160 -----------
------- ------------ ----- SCREWDRIVER
Utilización de COALESCE
Esta función puede ser especialmente útil en operaciones de unión externa

completa debido a que devuelve el primer valor no nulo. Por ejemplo, observe que
el resultado del ejemplo anterior es nulo para SCREWDRIVER, aunque la tabla
PRODUCTS contiene un número de producto para SCREWDRIVER. Si por el
contrario selecciona PRODUCTS.PROD#, PROD# es nulo para OIL. Si selecciona
PRODUCTS.PROD# y PARTS.PROD#, el resultado contiene dos columnas y ambas
columnas contienen algunos valores nulos.
Ejemplo 2: Puede fusionar datos de ambas columnas en una única columna,

eliminando los valores nulos, mediante la función COALESCE. Considere esta
consulta con las mismas tablas PARTS y PRODUCTS:
SELECT PART, SUPPLIER,
COALESCE(PARTS.PROD#, PRODUCTS.PROD#) AS PRODNUM, PRODUCT
FROM PARTS FULL OUTER JOIN PRODUCTS
Esta sentencia produce el resultado siguiente:

PART SUPPLIER PRODNUM PRODUCT
======= ============ ======= ===========
OIL WESTERN_CHEM 160 -----------
------- ------------ 505 SCREWDRIVER

La cláusula AS, AS PRODNUM, proporciona un nombre para el resultado de la
función COALESCE.
Subconsultas
Puede utilizar una subconsulta para limitar una condición de búsqueda basada en
información de una tabla intermedia.
Una subconsulta es una sentencia de SQL anidada, o subselección, que contiene una
sentencia SELECT dentro de la cláusula WHERE o HAVING de otra sentencia de
SQL. También puede codificar subconsultas más complejas como, por ejemplo,
subconsultas correlacionadas y subconsultas con predicados cuantificados.
Puede utilizar una subconsulta cuando necesita limitar la condición de búsqueda

basada en información de una tabla intermedia. Por ejemplo, puede que desee
buscar todos los números de empleado de una tabla que también existan para un
proyecto concreto en una segunda tabla.
Ejemplo: Suponga que desea obtener una lista de los números de empleado,
nombres y comisiones de todos los empleados que trabajan en un proyecto
determinado como, por ejemplo, el número de proyecto IF2000. La primera parte
de la sentencia SELECT es fácil de escribir:
SELECT EMPNO, LASTNAME, COMM
FROM EMP
. WHERE EMPNO
.
.
Sin embargo, no puede continuar porque la tabla EMP no incluye datos sobre el
número de proyecto. No puede saber qué empleados trabajan en el proyecto
IF2000 sin emitir otra sentencia SELECT para la tabla EMPPROJACT.
Puede utilizar una subselección para solucionar este problema. La sentencia

SELECT que contiene la subconsulta es la sentencia SELECT externa.
Ejemplo: Esta consulta amplía la sentencia SELECT que ha iniciado en el ejemplo

anterior para incluir una subconsulta:
FROM EMP
WHERE EMPNO IN
(SELECT EMPNO
FROM EMPPROJACT
WHERE PROJNO = 'IF2000');
Para comprender mejor qué sucede como resultado de esta sentencia de SQL,
imagine que DB2 realiza el proceso siguiente:
1. DB2 evalúa la subconsulta para obtener una lista de valores de EMPNO:
(SELECT EMPNO
FROM EMPPROJACT
WHERE PROJNO = 'IF2000');
El resultado es la siguiente tabla de resultados intermedios:
EMPNO
======
000140
000140
000030

2. A continuación, la tabla de resultados intermedios sirve como lista en la
condición de búsqueda de la sentencia SELECT externa. En realidad, DB2
ejecuta esta sentencia SELECT:
FROM EMP
WHERE EMPNO IN
('000140', '000030');
EMPNO LASTNAME COMM
===== ======== =======
000140 NICHOLLS 2274.00
000030 KWAN 3060.00
Modos de acceder a datos de DB2 que no están en una tabla

Puede acceder a datos de DB2 que no están en una tabla devolviendo el valor de
una expresión de SQL (que no incluye una columna de una tabla) en una variable
de lenguaje principal.
El acceso se puede llevar a cabo de dos modos.

v Establezca el contenido de una variable de lenguaje principal en el valor de una
expresión utilizando la sentencia de asignación de variable de lenguaje principal
SET.
Ejemplo:
EXEC SQL SET :HVRANDVAL = RAND(:HVRAND);
v Además, puede utilizar la sentencia VALUES INTO para devolver el valor de
una expresión en una variable de lenguaje principal.
Ejemplo:
EXEC SQL VALUES RAND(:HVRAND)
INTO :HVRANDVAL;
“Acceso de datos con variables de lenguaje principal” en la página 156
Modos de modificar datos

| Puede utilizar sentencias de SQL para añadir, modificar, fusionar y eliminar datos
| en tablas existentes. Esta información proporciona una visión general sobre cómo
| utilizar las sentencias INSERT, UPDATE, MERGE y DELETE para manipular datos
| de DB2.
Si inserta, actualiza, fusiona o suprime datos, puede recuperar los datos

inmediatamente. Si abre un cursor y, a continuación, modifica datos, tan solo verá
los datos modificados en algunas circunstancias.
Cualquier modificación debe mantener la integridad de las relaciones entre tablas.

DB2 asegura que una operación de inserción, actualización o supresión no viole
ninguna restricción de referencia ni restricción de comprobación definida para una
tabla.
Antes de modificar datos de las tablas, debe crear tablas duplicadas con fines de
prueba para que los datos de las tablas originales permanezcan intactos. Suponga
que ha creado dos tablas nuevas, NEWDEPT y NEWEMP, que son los duplicados
de las tablas DEPT y EMP.

Editor de tablas de DB2
| Utilice la herramienta Editor de tablas de DB2 para acceder, actualizar, suprimir y

| crear datos de forma rápida y fácil entre varios sistemas operativos de base de
| datos de DB2. Las características de esta herramienta le permiten llevar a cabo las
| tareas siguientes:
v Navegar por bases de datos, tablas y vistas de DB2 y buscar datos relacionados.
v Editar tablas de DB2 utilizando puntos de entrada de usuario final que incluyan
navegadores web habilitados para Java, interfaces basadas en Java iniciadas
desde el Centro de control de DB2, Microsoft Windows o una interfaz ISPF.
v Crear formularios de edición de tablas basados en Java o Windows específicos
de tareas y versátiles que contengan validación de datos incorporados y reglas
empresariales.
“Utilización de restricciones de comprobación para imponer la validez de
valores de columnas” en la página 196
Inserciones
Puede utilizar una sentencia INSERT o una sentencia MERGE para añadir filas
nuevas a una tabla o vista.
Puede utilizar una sentencia INSERT para llevar a cabo las acciones siguientes:
v Especificar los valores que deben insertarse en una única fila. Puede especificar
constantes, variables de lenguaje principal, expresiones, DEFAULT o NULL.
| v Utilizar matrices de variables de lenguaje principal en la cláusula VALUES de la
| sentencia INSERT FOR n ROWS para insertar varias filas en una tabla. También
| puede utilizar una sentencia MERGE con matrices de variables de lenguaje
| principal para insertar y actualizar datos.
v Incluir una sentencia SELECT en la sentencia INSERT para indicar a DB2 que
otra tabla o vista contiene los datos para la fila o filas nuevas.
Ejemplo 1: Suponga que desea añadir una fila nueva a la tabla NEWDEPT. Utilice
esta sentencia INSERT:
INSERT INTO NEWDEPT (DEPTNO, DEPTNAME, MGRNO, ADMRDEPT)
VALUES ('E31', 'PUBLISHING', '000020', 'D11');
Ejemplo 2: Después de insertar la nueva fila de departamento en la tabla

NEWDEPT, puede utilizar una sentencia SELECT para ver cómo aparece la tabla
modificada. Utilice esta consulta:
SELECT *
FROM NEWDEPT
WHERE DEPTNO LIKE 'E%'
ORDER BY DEPTNO;
La tabla de resultados le proporciona la nueva fila de departamento que ha

insertado para el departamento E31 y los departamentos existentes con un número
de departamento que empieza con E.
DEPTNO DEPTNAME MGRNO ADMRDEPT
====== ================ ====== ========
E21 SOFTWARE SUPPORT ------ D11
E31 PUBLISHING 000020 D11
También puede añadir datos nuevos a una tabla existente de otras formas. Quizás
necesite añadir grandes cantidades de datos a una tabla existente. Algunas

opciones eficaces incluyen la copia de una tabla en otra tabla, la escritura de un
programa de aplicación que entre datos en una tabla y la utilización del programa
de utilidad LOAD de DB2 para entrar datos.
″INSERT″ (Consulta de DB2 SQL)
″MERGE″ (Consulta de DB2 SQL)
Actualizaciones
Puede cambiar los datos de una tabla utilizando la sentencia UPDATE o la
sentencia MERGE.
| La sentencia UPDATE modifica cero o más filas de una tabla, dependiendo de

| cuántas filas cumplan la condición de búsqueda que se especifica en la cláusula
| WHERE.
| Puede utilizar una sentencia UPDATE o MERGE para especificar los valores que
| deben actualizarse de una única fila. Puede especificar constantes, variables de
| lenguaje principal, expresiones, DEFAULT o NULL. Especifique NULL para
| eliminar un valor de una columna de una fila (sin eliminar la fila).
Ejemplo: Suponga que un empleado obtiene un ascenso. Para actualizar varios

elementos de los datos del empleado en la tabla NEWEMP que refleja el
movimiento, utilice la sentencia UPDATE:
UPDATE NEWEMP
SET JOB = 'MGR',
DEPT = 'E21'
WHERE EMPNO = '100125';
″UPDATE″ (Consulta de DB2 SQL)
″MERGE″ (Consulta de DB2 SQL)
Supresiones
Puede utilizar la sentencia DELETE para eliminar filas enteras de una tabla.
La sentencia DELETE elimina cero o más filas de una tabla, dependiendo de

cuántas filas cumplen la condición de búsqueda que se especifica en la cláusula
WHERE. Si se omite una cláusula WHERE de una sentencia DELETE, DB2 elimina
todas las filas de la tabla o vista que se mencionan. Por lo tanto, utilice la sentencia
DELETE con cuidado. La sentencia DELETE no elimina columnas específicas de la
fila.
Ejemplo: Considere esta sentencia DELETE:

DELETE FROM NEWEMP
Esta sentencia DELETE suprime cada fila de la tabla NEWEMP que tenga el
número de empleado 000060.
″DELETE″ (Consulta de DB2 SQL)

Modos de ejecutar SQL

Puede ejecutar sentencias de SQL en aplicaciones o de forma interactiva. El método
de preparación de una sentencia de SQL para ejecutarla y la persistencia de su
forma operativa determinan la diferencia entre SQL estático y SQL dinámico.
SQL estático
La forma de origen de una sentencia de SQL estático se incluye en un programa de
aplicación que se escribe en un lenguaje de programación de sistema principal
como, por ejemplo, C. La sentencia se prepara antes de ejecutar el programa y la
forma operativa de la sentencia permanece hasta después de la ejecución del
programa.
Puede utilizar SQL estático cuando sabe antes del tiempo de ejecución qué
sentencias de SQL necesita ejecutar la aplicación.
″Diferencias entre SQL estático y dinámico″ (DB2 Application Programming and
SQL Guide)
″SQL estático″ (Consulta de DB2 SQL)
SQL dinámico
Las sentencias de SQL dinámico se construyen y preparan durante el tiempo de
ejecución.
Puede utilizar SQL dinámico si desconoce el contenido de una sentencia de SQL al

escribir un programa o antes de ejecutarlo.
″Diferencias entre SQL estático y dinámico″ (DB2 Application Programming and
SQL Guide)
″SQL dinámico″ (Consulta de DB2 SQL)
DB2 ODBC
DB2 ODBC (Open Database Connectivity) es una interfaz de programación de
aplicaciones (API) que permite que programas de aplicaciones C y C++ accedan a
bases de datos relacionales.
Esta interfaz ofrece una alternativa a la utilización de SQL estático incorporado y

un modo distinto de ejecutar SQL dinámico. Mediante la interfaz, una aplicación
invoca una función C durante el tiempo de ejecución para conectarse a una fuente
de datos, para emitir sentencias de SQL de forma dinámica y recuperar datos e
información de estado.
DB2 ODBC Guide and Reference
Acceso a DB2 para Java: SQLJ y JDBC

SQLJ y JDBC son dos métodos para acceder a datos de DB2 desde el lenguaje de
programación Java.

En general, las aplicaciones de Java utilizan SQLJ para SQL estático y utilizan
JDBC para SQL dinámico.
DB2 Application Programming Guide and Reference for Java
SQL interactivo
SQL interactivo hace referencia a sentencias de SQL que se someten a DB2
utilizando una herramienta de consulta como, por ejemplo, DB2 QMF para
Workstation.
El modo más fácil y eficaz de ejecutar SQL es utilizando una herramienta de

consulta. DB2 Query Management Facility (QMF) para Workstation es una
herramienta de consulta popular que le permite entrar y ejecutar las sentencias de
SQL de un modo fácil. Este tema le informa sobre la utilización de DB2 QMF para
Workstation para crear y ejecutar sentencias de SQL. DB2 QMF para Workstation
simplifica el acceso a DB2 desde una estación de trabajo. De hecho, QMF para
Workstation se creó para DB2.
Aunque este tema se centra en DB2 QMF para Workstation, hay disponibles otras
opciones. Puede utilizar DB2 QMF para WebSphere para entrar y ejecutar
sentencias de SQL desde el navegador web o utilizar DB2 QMF para TSO/CICS
para entrar y ejecutar sentencias de SQL desde TSO o CICS. Además, puede entrar
y ejecutar sentencias de SQL en un terminal TSO utilizando el recurso SPUFI
(procesador de SQL utilizando entrada de archivo). SPUFI prepara y ejecuta estas
sentencias dinámicamente. Todas estas herramientas preparan y ejecutan
dinámicamente las sentencias de SQL.
La familia de tecnologías de DB2 QMF establecen una producción elevada y el

compartimiento de inteligencia empresarial para tareas orientadas a la información
en la organización. DB2 QMF ofrece muchas ventajas, incluyendo las siguientes:
| v Soporte para funcionalidad de la base de datos de DB2, incluyendo nombres
| largos, Unicode y mejoras de SQL
v Posibilidad de arrastrar y soltar para crear analíticas OLAP, consultas de SQL,
tablas de pivote y otros análisis e informes empresariales
| v Paneles de instrumentos ejecutivos y soluciones visuales de datos que ofrecen
| una funcionalidad visual completa e interactiva e interfaces para análisis de
| datos
v Soporte para DB2 QMF para WebSphere, una herramienta que convierte
cualquier navegador web en un cliente ligero, sin ningún mantenimiento, para
acceso visual bajo demanda a datos empresariales de DB2
| v Entorno de desarrollo entre plataformas con ingeniería rediseñada
| v Nuevo modelo de seguridad para control y personalización de acceso
| Las soluciones visuales previamente proporcionadas por DB2 QMF Visionary

| actualmente se incluyen en la tecnología básica de DB2 QMF.
Además de DB2 QMF para Workstation, que se describe en este tema, la familia de
DB2 QMF incluye las ediciones siguientes:

v DB2 QMF Enterprise Edition proporciona toda la familia de tecnologías de DB2
QMF, lo que habilita la información empresarial en el ámbito de toda la empresa
entre sistemas operativos de usuarios finales y bases de datos. Esta edición
consta de:
– DB2 QMF para TSO/CICS
– DB2 QMF High Performance Option (HPO)
– DB2 QMF para Workstation
– DB2 QMF para WebSphere
v DB2 QMF Classic Edition da soporte a usuarios finales que trabajan con
terminales principales tradicionales (incluido WebSphere Host On Demand) para
acceder a bases de datos de DB2. Esta edición consta de DB2 QMF para
TSO/CICS.
Utilización de DB2 Query Management Facility para Workstation

DB2 Query Management Facility (QMF) para Workstation es una herramienta que
le ayuda a crear y gestionar consultas muy eficaces sin necesidad de tener
conocimientos previos sobre SQL.
Con las características relacionadas con consultas de DB2 QMF para Workstation
puede realizar las tareas siguientes:
v Crear consultas muy eficaces sin conocimientos de SQL
v Analizar resultados de consultas en línea, incluido el análisis OLAP
v Editar resultados de consultas para actualizar datos de DB2
v Formatear informes basados en texto tradicional e informes con formato rico
v Visualizar gráficas y otros visuales complejos
v Enviar resultados de consultas a la aplicación que el usuario selecciona
v Desarrollar aplicaciones utilizando mandatos de API de gran capacidad
Cómo se especifican y procesan sentencias de SQL
Puede crear las sentencias de SQL utilizando DB2 QMF para Workstation de varias
formas:
v Utilice la ventana Database Explorer para encontrar y ejecutar con facilidad
consultas guardadas (también conocida como una consulta escrita) que pueden
compartir todos los usuarios del mismo servidor de bases de datos.
v Si tiene conocimientos sobre SQL, escriba la sentencia de SQL directamente en la
ventana.
v Si no tiene conocimientos sobre SQL, utilice la interfaz asistida o de diagrama
para crear la sentencia de SQL.
Database Explorer presenta los objetos guardados en un servidor en una estructura

en árbol. Mediante la expansión y la contracción de las ramificaciones puede
localizar y utilizar las consultas guardadas de una forma fácil. Puede abrir la
consulta seleccionada y ver las sentencias de SQL o ejecutar la consulta.
Si necesita crear una consulta nueva, puede entrar las sentencias de SQL
directamente en la ventana de consulta o puede crear las sentencias de SQL
utilizando diagramas o solicitudes. Cuando crea una consulta utilizando diagramas
o solicitudes, puede abrir una vista para ver el SQL que se está creando.

Cómo trabajar con resultados de consultas
Cuando termine de crear la consulta, puede pulsar el botón Run Query (Ejecutar
consulta) para ejecutar las sentencias de SQL. Después de ejecutar la consulta, DB2
QMF para Workstation devuelve los resultados de la consulta en una ventana
interactiva.
Los resultados de la consulta se formatean con las amplias opciones de formateo

de DB2 QMF para Workstation. Un lenguaje de expresión eficaz le permite
formatear condicionalmente los resultados de la consulta mediante valores de
columna recuperados. Puede añadir columnas calculadas a los resultados de la
consulta y agrupar las columnas de datos en ambos ejes con o sin resúmenes.
También puede utilizar las extensas posibilidades de arrastrar y soltar para
reestructurar fácilmente el aspecto de los resultados de la consulta.
Además de formatear los resultados de la consulta, puede realizar las acciones

siguientes:
v Crear informes basados en texto tradicionales o informes más avanzados con
formato rico.
v Visualizar resultados de consultas utilizando gráficas y otros visuales complejos.
v Compartir informes almacenándolos en el servidor de bases de datos.
v Enviar resultados de consultas a varias aplicaciones como, por ejemplo,
Microsoft Excel o Lotus 1-2-3.
″DB2 Query Management Facility″ en ibm.com
Tablas de ejemplo de DB2

Gran parte de la información de DB2 hace referencia o se basa en tablas de
ejemplo de DB2. Como un grupo, las tablas incluyen información que describe
empleados, departamentos, proyectos y actividades y forman una aplicación de
ejemplo que ilustra muchas de las características de DB2.
El grupo de almacenamiento, las bases de datos, los espacios de tablas, las

tablas y vistas de ejemplo se crean cuando se ejecutan los trabajos de ejemplo de
instalación DSNTEJ1 y DSNTEJ7. Los objetos de ejemplo de DB2 que incluyen LOB
se crean en el trabajo DSNTEJ7. Los demás objetos de ejemplo se crean en el
trabajo DSNTEJ1. Las sentencias CREATE INDEX para las tablas de ejemplo no se
muestran aquí; también se crean mediante los trabajos de ejemplo DSNTEJ1 y
DSNTEJ7.
Se proporciona la autorización PUBLIC sobre todos los objetos de ejemplo para

que los programas de ejemplo sean más fáciles de ejecutar. Puede revisar el
contenido de cualquier tabla ejecutando una sentencia de SQL, por ejemplo
SELECT * FROM DSN8910.PROJ. Para facilitar la interpretación de los ejemplos,
las tablas de departamentos y empleados se listan completas.
Tabla de actividades (DSN8910.ACT)

La tabla de actividades describe las actividades que se pueden realizar durante un
proyecto.
La tabla de actividades reside en la base de datos DSN8D91A y se crea con

la siguiente sentencia:

CREATE TABLE DSN8910.ACT
(ACTNO SMALLINT NOT NULL,
ACTKWD CHAR(6) NOT NULL,
ACTDESC VARCHAR(20) NOT NULL,
PRIMARY KEY (ACTNO) )
IN DSN8D91A.DSN8S91P
CCSID EBCDIC;
Contenido de la tabla de actividades
La tabla siguiente muestra el contenido de las columnas de la tabla de actividades.

Tabla 6. Columnas de la tabla de actividades
Nombre de
Columna columna Descripción
1 ACTNO ID de actividad (clave primaria)
2 ACTKWD Palabra clave de actividad (seis caracteres como
máximo)
3 ACTDESC Descripción de actividad
La tabla de actividades contiene los índices siguientes.

Tabla 7. Índices de la tabla de actividades
Nombre En la columna Tipo de índice
DSN8910.XACT1 ACTNO Primario, ascendente
DSN8910.XACT2 ACTKWD Exclusivo, ascendente
Relación con otras tablas
La tabla de actividades es una tabla padre de la tabla de actividades de un

proyecto, mediante una clave foránea en la columna ACTNO.
Tabla de departamentos (DSN8910.DEPT)

La tabla de departamentos describe cada departamento de la empresa e identifica
su director y el departamento al cual informa.
La tabla de departamentos reside en el espacio de tablas

DSN8D91A.DSN8S91D y se crea con la sentencia siguiente:
CREATE TABLE DSN8910.DEPT
(DEPTNO CHAR(3) NOT NULL,
DEPTNAME VARCHAR(36) NOT NULL,
MGRNO CHAR(6) ,
ADMRDEPT CHAR(3) NOT NULL,
LOCATION CHAR(16) ,
PRIMARY KEY (DEPTNO) )
IN DSN8D91A.DSN8S91D
CCSID EBCDIC;
Debido a que la tabla de departamentos hace referencia a sí misma y también

forma parte de un ciclo de dependencias, sus claves foráneas deben añadirse más
adelante con las sentencias siguientes:
ALTER TABLE DSN8910.DEPT
FOREIGN KEY RDD (ADMRDEPT) REFERENCES DSN8910.DEPT
ON DELETE CASCADE;

ALTER TABLE DSN8910.DEPT
FOREIGN KEY RDE (MGRNO) REFERENCES DSN8910.EMP
ON DELETE SET NULL;
Contenido de la tabla de departamentos
La tabla siguiente muestra el contenido de las columnas de la tabla de

departamentos.
Tabla 8. Columna de la tabla de departamentos
Nombre de
1 DEPTNO ID de departamento, clave primaria.
2 DEPTNAME Nombre que describe las actividades generales del
departamento.
3 MGRNO Número de empleado (EMPNO) del director de
departamento.
4 ADMRDEPT ID del departamento al cual informa este
departamento; el departamento en el nivel superior
informa a sí mismo.
5 LOCATION El nombre de ubicación remota.
La tabla siguiente muestra los índices de la tabla de departamentos.

Tabla 9. Índices de la tabla de departamentos
DSN8910.XDEPT1 DEPTNO Primario, ascendente
DSN8910.XDEPT2 MGRNO Ascendente
DSN8910.XDEPT3 ADMRDEPT Ascendente
La tabla siguiente muestra el contenido de la tabla de departamentos.

Tabla 10. DSN8910.DEPT: tabla de departamentos
DEPTNO DEPTNAME MGRNO ADMRDEPT LOCATION
A00 SPIFFY COMPUTER SERVICE 000010 A00 ----------------

DIV.
B01 PLANNING 000020 A00 ----------------
C01 INFORMATION CENTER 000030 A00 ----------------
D01 DEVELOPMENT CENTER ------ A00 ----------------
E01 SUPPORT SERVICES 000050 A00 ----------------
D11 MANUFACTURING SYSTEMS 000060 D01 ----------------
D21 ADMINISTRATION SYSTEMS 000070 D01 ----------------
E11 OPERATIONS 000090 E01 ----------------
E21 SOFTWARE SUPPORT 000100 E01 ----------------
F22 BRANCH OFFICE F2 ------ E01 ----------------
G22 BRANCH OFFICE G2 ------ E01 ----------------
H22 BRANCH OFFICE H2 ------ E01 ----------------
I22 BRANCH OFFICE I2 ------ E01 ----------------
J22 BRANCH OFFICE J2 ------ E01 ----------------

La columna LOCATION contiene valores nulos hasta que el trabajo de ejemplo
DSNTEJ6 actualiza esta columna con el nombre de ubicación.
La tabla de departamentos hace referencia a sí misma: el valor del departamento

de administración debe ser un ID de departamento válido.
La tabla de departamentos es una tabla padre de las siguientes:

v La tabla de empleados, mediante una clave foránea en la columna WORKDEPT
v La tabla de proyectos, mediante una clave foránea en la columna DEPTNO
La tabla de departamentos depende de la tabla de empleados, mediante su clave

primaria en la columna MGRNO.
Tabla de empleados (DSN8910.EMP)

La tabla de empleados identifica todos los empleados mediante un número de
empleado y lista información personal básica.
La tabla de empleados reside en el espacio de tablas particionado

DSN8D91A.DSN8S91E. Debido a que esta tabla tiene una clave primaria que hace
referencia a DEPT, esta tabla y el índice de su clave primaria deben crearse
primero. A continuación, se crea EMP con la sentencia siguiente:
CREATE TABLE DSN8910.EMP
(EMPNO CHAR(6) NOT NULL,
FIRSTNME VARCHAR(12) NOT NULL,
MIDINIT CHAR(1) NOT NULL,
LASTNAME VARCHAR(15) NOT NULL,
WORKDEPT CHAR(3) ,
PHONENO CHAR(4) CONSTRAINT NUMBER CHECK
(PHONENO >= '0000' AND
PHONENO <= '9999') ,
HIREDATE DATE ,
JOB CHAR(8) ,
EDLEVEL SMALLINT ,
SEX CHAR(1) ,
BIRTHDATE DATE ,
SALARY DECIMAL(9,2) ,
BONUS DECIMAL(9,2) ,
COMM DECIMAL(9,2) ,
PRIMARY KEY (EMPNO) ,
FOREIGN KEY RED (WORKDEPT) REFERENCES DSN8910.DEPT
ON DELETE SET NULL )
EDITPROC DSN8EAE1
IN DSN8D91A.DSN8S91E
CCSID EBCDIC;
Contenido de la tabla de empleados
La tabla siguiente muestra el tipo de contenido de cada una de las columnas de la

tabla de empleados. La tabla tiene una restricción de comprobación, NUMBER, que
comprueba que el número de teléfono de cuatro dígitos esté dentro del rango
numérico de 0000 a 9999.
Tabla 11. Columnas de la tabla de empleados
Nombre de
1 EMPNO Número de empleado (clave primaria)

Tabla 11. Columnas de la tabla de empleados (continuación)
Nombre de
2 FIRSTNME Nombre del empleado
3 MIDINIT Inicial media del empleado
4 LASTNAME Apellido del empleado
5 WORKDEPT ID de departamento en el que trabaja el empleado
6 PHONENO Número de teléfono del empleado
7 HIREDATE Fecha de contratación
8 JOB Ocupación del empleado
9 EDLEVEL Número de años de educación formal
10 SEX Sexo del empleado (M o F)
11 BIRTHDATE Fecha de nacimiento
12 SALARY Salario anual en dólares
13 BONUS Bonificación anual en dólares
14 COMM Comisión anual en dólares
La tabla siguiente muestra los índices de la tabla de empleados.

Tabla 12. Índices de la tabla de empleados
DSN8910.XEMP1 EMPNO Primario, particionado, ascendente
DSN8910.XEMP2 WORKDEPT Ascendente
La tala siguiente muestra la primera mitad (lado izquierdo) del contenido de la

tabla de empleados. (La Tabla 14 en la página 129 muestra el resto del contenido
(lado derecho) de la tabla de empleados.)
Tabla 13. Mitad izquierda de DSN8910.EMP: tabla de empleados. Observe que un espacio en blanco en la columna
MIDINIT es un valor real de ″ ″ en lugar de un nulo.
EMPNO FIRSTNME MIDINIT LASTNAME WORKDEPT PHONENO HIREDATE
000010 CHRISTINE I HAAS A00 3978 1965-01-01

000020 MICHAEL L THOMPSON B01 3476 1973-10-10
000030 SALLY A KWAN C01 4738 1975-04-05
000050 JOHN B GEYER E01 6789 1949-08-17
000060 IRVING F STERN D11 6423 1973-09-14
000070 EVA D PULASKI D21 7831 1980-09-30
000090 EILEEN W HENDERSON E11 5498 1970-08-15
000100 THEODORE Q SPENSER E21 0972 1980-06-19
000110 VINCENZO G LUCCHESSI A00 3490 1958-05-16
000120 SEAN O’CONNELL A00 2167 1963-12-05
000130 DOLORES M QUINTANA C01 4578 1971-07-28
000140 HEATHER A NICHOLLS C01 1793 1976-12-15
000150 BRUCE ADAMSON D11 4510 1972-02-12
000160 ELIZABETH R PIANKA D11 3782 1977-10-11
000170 MASATOSHI J YOSHIMURA D11 2890 1978-09-15
000180 MARILYN S SCOUTTEN D11 1682 1973-07-07
000190 JAMES H WALKER D11 2986 1974-07-26

Tabla 13. Mitad izquierda de DSN8910.EMP: tabla de empleados (continuación). Observe que un espacio en blanco
en la columna MIDINIT es un valor real de ″ ″ en lugar de un nulo.
EMPNO FIRSTNME MIDINIT LASTNAME WORKDEPT PHONENO HIREDATE
000200 DAVID BROWN D11 4501 1966-03-03

000210 WILLIAM T JONES D11 0942 1979-04-11
000220 JENNIFER K LUTZ D11 0672 1968-08-29
000230 JAMES J JEFFERSON D21 2094 1966-11-21
000240 SALVATORE M MARINO D21 3780 1979-12-05
000250 DANIEL S SMITH D21 0961 1969-10-30
000260 SYBIL P JOHNSON D21 8953 1975-09-11
000270 MARIA L PEREZ D21 9001 1980-09-30
000280 ETHEL R SCHNEIDER E11 8997 1967-03-24
000290 JOHN R PARKER E11 4502 1980-05-30
000300 PHILIP X SMITH E11 2095 1972-06-19
000310 MAUDE F SETRIGHT E11 3332 1964-09-12
000320 RAMLAL V MEHTA E21 9990 1965-07-07
000330 WING LEE E21 2103 1976-02-23
000340 JASON R GOUNOT E21 5698 1947-05-05
200010 DIAN J HEMMINGER A00 3978 1965-01-01
200120 GREG ORLANDO A00 2167 1972-05-05
200140 KIM N NATZ C01 1793 1976-12-15
200170 KIYOSHI YAMAMOTO D11 2890 1978-09-15
200220 REBA K JOHN D11 0672 1968-08-29
200240 ROBERT M MONTEVERDE D21 3780 1979-12-05
200280 EILEEN R SCHWARTZ E11 8997 1967-03-24
200310 MICHELLE F SPRINGER E11 3332 1964-09-12
200330 HELENA WONG E21 2103 1976-02-23
200340 ROY R ALONZO E21 5698 1947-05-05
(La Tabla 13 en la página 128 muestra la primera mitad (lado derecho) del
contenido de la tabla de empleados.)
Tabla 14. Mitad derecha de DSN8910.EMP: tabla de empleados
(EMPNO) JOB EDLEVEL SEX BIRTHDATE SALARY BONUS COMM
(000010) PRES 18 F 1933-08-14 52750.00 1000.00 4220.00

(000020) MANAGER 18 M 1948-02-02 41250.00 800.00 3300.00
(000030) MANAGER 20 F 1941-05-11 38250.00 800.00 3060.00
(000050) MANAGER 16 M 1925-09-15 40175.00 800.00 3214.00
(000060) MANAGER 16 M 1945-07-07 32250.00 600.00 2580.00
(000070) MANAGER 16 F 1953-05-26 36170.00 700.00 2893.00
(000090) MANAGER 16 F 1941-05-15 29750.00 600.00 2380.00
(000100) MANAGER 14 M 1956-12-18 26150.00 500.00 2092.00
(000110) SALESREP 19 M 1929-11-05 46500.00 900.00 3720.00
(000120) CLERK 14 M 1942-10-18 29250.00 600.00 2340.00
(000130) ANALYST 16 F 1925-09-15 23800.00 500.00 1904.00
(000140) ANALYST 18 F 1946-01-19 28420.00 600.00 2274.00
(000150) DESIGNER 16 M 1947-05-17 25280.00 500.00 2022.00
(000160) DESIGNER 17 F 1955-04-12 22250.00 400.00 1780.00
(000170) DESIGNER 16 M 1951-01-05 24680.00 500.00 1974.00
(000180) DESIGNER 17 F 1949-02-21 21340.00 500.00 1707.00
(000190) DESIGNER 16 M 1952-06-25 20450.00 400.00 1636.00
(000200) DESIGNER 16 M 1941-05-29 27740.00 600.00 2217.00
(000210) DESIGNER 17 M 1953-02-23 18270.00 400.00 1462.00

Tabla 14. Mitad derecha de DSN8910.EMP: tabla de empleados (continuación)
(EMPNO) JOB EDLEVEL SEX BIRTHDATE SALARY BONUS COMM
(000220) DESIGNER 18 F 1948-03-19 29840.00 600.00 2387.00

(000230) CLERK 14 M 1935-05-30 22180.00 400.00 1774.00
(000240) CLERK 17 M 1954-03-31 28760.00 600.00 2301.00
(000250) CLERK 15 M 1939-11-12 19180.00 400.00 1534.00
(000260) CLERK 16 F 1936-10-05 17250.00 300.00 1380.00
(000270) CLERK 15 F 1953-05-26 27380.00 500.00 2190.00
(000280) OPERATOR 17 F 1936-03-28 26250.00 500.00 2100.00
(000290) OPERATOR 12 M 1946-07-09 15340.00 300.00 1227.00
(000300) OPERATOR 14 M 1936-10-27 17750.00 400.00 1420.00
(000310) OPERATOR 12 F 1931-04-21 15900.00 300.00 1272.00
(000320) FIELDREP 16 M 1932-08-11 19950.00 400.00 1596.00
(000330) FIELDREP 14 M 1941-07-18 25370.00 500.00 2030.00
(000340) FIELDREP 16 M 1926-05-17 23840.00 500.00 1907.00
(200010) SALESREP 18 F 1933-08-14 46500.00 1000.00 4220.00
(200120) CLERK 14 M 1942-10-18 29250.00 600.00 2340.00
(200140) ANALYST 18 F 1946-01-19 28420.00 600.00 2274.00
(200170) DESIGNER 16 M 1951-01-05 24680.00 500.00 1974.00
(200220) DESIGNER 18 F 1948-03-19 29840.00 600.00 2387.00
(200240) CLERK 17 M 1954-03-31 28760.00 600.00 2301.00
(200280) OPERATOR 17 F 1936-03-28 26250.00 500.00 2100.00
(200310) OPERATOR 12 F 1931-04-21 15900.00 300.00 1272.00
(200330) FIELDREP 14 F 1941-07-18 25370.00 500.00 2030.00
(200340) FIELDREP 16 M 1926-05-17 23840.00 500.00 1907.00
La tabla de empleados es una tabla padre de:

v La tabla de departamentos, mediante una clave foránea en la columna MGRNO
v La tabla de proyectos, mediante una clave foránea en la columna RESPEMP
La tabla de empleados depende de la tabla de departamentos, mediante su clave

foránea en la columna WORKDEPT.
Tabla de fotografías y currículums de empleados

(DSN8910.EMP_PHOTO_RESUME)
La tabla de fotografías y currículums de empleados complementa la tabla de
empleados.
Cada fila de la tabla de fotografías y currículums contiene una fotografía

del empleado, en dos formatos y el currículum del empleado. La tabla de
fotografías y currículums reside en el espacio de tablas DSN8D91A.DSN8S91E. La
sentencia siguiente crea la tabla:
CREATE TABLE DSN8910.EMP_PHOTO_RESUME
EMP_ROWID ROWID NOT NULL GENERATED ALWAYS,
PSEG_PHOTO BLOB(500K),
BMP_PHOTO BLOB(100K),
RESUME CLOB(5K))
PRIMARY KEY (EMPNO)
IN DSN8D91L.DSN8S91B
CCSID EBCDIC;

DB2 necesita una tabla auxiliar para cada columna LOB de una tabla. Las
sentencias siguientes definen las tablas auxiliares para las tres columnas LOB de
DSN8910.EMP_PHOTO_RESUME:
CREATE AUX TABLE DSN8910.AUX_BMP_PHOTO
IN DSN8D91L.DSN8S91M
STORES DSN8910.EMP_PHOTO_RESUME
COLUMN BMP_PHOTO;
CREATE AUX TABLE DSN8910.AUX_PSEG_PHOTO

IN DSN8D91L.DSN8S91L
COLUMN PSEG_PHOTO;
CREATE AUX TABLE DSN8910.AUX_EMP_RESUME

IN DSN8D91L.DSN8S91N
COLUMN RESUME;
Contenido de la tabla de fotografías y currículums
La tabla siguiente muestra el contenido de las columnas de la tabla de fotografías y

currículums de empleados.
Tabla 15. Columnas de la tabla de fotografías y currículums de empleados
Columna Nombre de columna Descripción
1 EMPNO ID de empleado (clave primaria).
2 EMP_ROWID ID de fila para identificar exclusivamente cada fila
de la tabla. DB2 proporciona los valores de esta
columna.
3 PSEG_PHOTO Fotografía del empleado, en formato PSEG.
4 BMP_PHOTO Fotografía del empleado, en formato BMP.
5 RESUME Currículum del empleado.
La tabla siguiente muestra los índices para la tabla de fotografías y currículums de

empleados.
Tabla 16. Índices de la tabla de fotografías y currículums de empleados
DSN8910.XEMP_PHOTO_RESUME EMPNO Primario, ascendente
La tabla siguiente muestra los índices para las tablas auxiliares que dan soporte a
la tabla de fotografía y currículums de empleados.
Tabla 17. Índices de las tablas auxiliares para la tabla de fotografías y currículums de
empleados
Nombre En la tabla Tipo de índice
DSN8910.XAUX_BMP_PHOTO DSN8910.AUX_BMP_PHOTO Exclusivo
DSN8910.XAUX_PSEG_PHOTO DSN8910.AUX_PSEG_PHOTO Exclusivo
DSN8910.XAUX_EMP_RESUME DSN8910.AUX_EMP_RESUME Exclusivo

La tabla de fotografías y currículums de empleados es una tabla padre de la tabla

de proyectos, mediante una clave foránea en la columna RESPEMP.
Tabla de proyectos (DSN8910.PROJ)

La tabla de proyectos describe cada proyecto que la empresa está desarrollando
actualmente. Los datos contenidos en cada fila de la tabla incluyen el número de
proyecto, el nombre, la persona responsable y las fechas de planificación.
La tabla de proyectos reside en la base de datos DSN8D91A. Dado que esta

tabla tiene claves foráneas que hacen referencia a DEPT y EMP, estas tablas y los
índices de sus claves primarias deben crearse primero. A continuación, se crea
PROJ con la sentencia siguiente:
CREATE TABLE DSN8910.PROJ
(PROJNO CHAR(6) PRIMARY KEY NOT NULL,
PROJNAME VARCHAR(24) NOT NULL WITH DEFAULT
'PROJECT NAME UNDEFINED',
DEPTNO CHAR(3) NOT NULL REFERENCES
DSN8910.DEPT ON DELETE RESTRICT,
RESPEMP CHAR(6) NOT NULL REFERENCES
DSN8910.EMP ON DELETE RESTRICT,
PRSTAFF DECIMAL(5, 2) ,
PRSTDATE DATE ,
PRENDATE DATE ,
MAJPROJ CHAR(6))
CCSID EBCDIC;
Debido a que la tabla de proyectos hace referencia a sí misma la clave foránea para
esta restricción debe añadirse más adelante con la sentencia siguiente:
ALTER TABLE DSN8910.PROJ
FOREIGN KEY RPP (MAJPROJ) REFERENCES DSN8910.PROJ
ON DELETE CASCADE;
Contenido de la tabla de proyectos
La tabla siguiente muestra el contenido de las columnas de la tabla de proyectos.

Tabla 18. Columnas de la tabla de proyectos
1 PROJNO ID de proyecto (clave primaria)
2 PROJNAME Nombre de proyecto
3 DEPTNO ID del departamento responsable del proyecto
4 RESPEMP ID del empleado responsable del proyecto
5 PRSTAFF Número medio estimado de personas necesarias
entre PRSTDATE y PRENDATE para completar el
proyecto entero, incluidos los subproyectos
6 PRSTDATE Fecha de inicio estimada del proyecto
7 PRENDATE Fecha de finalización estimada del proyecto
8 MAJPROJ ID de cualquier proyecto del que forme parte este
proyecto

La tabla siguiente muestra los índices para la tabla de proyectos:
Tabla 19. Índices de la tabla de proyectos
DSN8910.XPROJ1 PROJNO Primario, ascendente
DSN8910.XPROJ2 RESPEMP Ascendente
La tabla hace referencia a sí misma: un valor no nulo de MAJPROJ debe ser un

número de proyecto válido. La tabla es una tabla padre de la tabla de actividades
de proyectos, mediante una clave foránea en la columna PROJNO. Depende de las
tablas siguientes:
v La tabla de departamentos, mediante su clave foránea en DEPTNO
v La tabla de empleados, mediante su clave foránea en RESPEMP
Tabla de actividades de proyectos (DSN8910.PROJACT)

La tabla de actividades de proyectos lista las actividades que se realizan para cada
proyecto.
La tabla de actividades de proyectos reside en la base de datos DSN8D91A.

Debido a que esta tabla tiene claves foráneas que hacen referencia a PROJ y ACT,
estas tablas y los índices de sus claves primarias deben crearse primero. A
continuación, se crea PROJACT con la sentencia siguiente:
CREATE TABLE DSN8910.PROJACT
(PROJNO CHAR(6) NOT NULL,
ACTNO SMALLINT NOT NULL,
ACSTAFF DECIMAL(5,2) ,
ACSTDATE DATE NOT NULL,
ACENDATE DATE ,
PRIMARY KEY (PROJNO, ACTNO, ACSTDATE),
FOREIGN KEY RPAP (PROJNO) REFERENCES DSN8910.PROJ
ON DELETE RESTRICT,
FOREIGN KEY RPAA (ACTNO) REFERENCES DSN8910.ACT
ON DELETE RESTRICT)
CCSID EBCDIC;
Contenido de la tabla de actividades de proyectos
La tabla siguiente muestra el contenido de las columnas de la tabla de actividades

de proyectos.
Tabla 20. Columnas de la tabla de actividades de proyectos
Nombre de
1 PROJNO ID de proyecto
2 ACTNO ID de actividad
3 ACSTAFF Número medio estimado de empleados que se
necesitan para realizar la actividad
4 ACSTDATE Fecha de inicio estimada de la actividad
5 ACENDATE Fecha de finalización estimada de la actividad

La tabla siguiente muestra el índice de la tabla de actividades de proyectos:
Tabla 21. Índice de la tabla de actividades de proyectos
Nombre En columnas Tipo de índice
DSN8910.XPROJAC1 PROJNO, ACTNO, primario, ascendente
ACSTDATE
La tabla de actividades de proyectos es una tabla padre de la tabla de empleados

de actividades de proyectos, mediante una clave foránea en las columnas PROJNO,
ACTNO y EMSTDATE. Depende de las tablas siguientes:
v La tabla de actividades, mediante su clave foránea en la columna ACTNO
v La tabla de proyectos, mediante su clave foránea en la columna PROJNO
“Tabla de proyectos (DSN8910.PROJ)” en la página 132
“Tabla de actividades (DSN8910.ACT)” en la página 124
Tabla de empleados de actividades de proyectos

(DSN8910.EMPPROJACT)
La tabla de empleados de actividades de proyectos identifica el empleado que
realiza una actividad para un proyecto, indica la proporción de tiempo necesario
del empleado y proporciona una planificación para la actividad.
La tabla de empleados de actividades de proyectos reside en la base de

datos DSN8D91A. Dado que esta tabla tiene claves foráneas que hacen referencia a
EMP y PROJACT, estas tablas y los índices de sus claves primarias deben crearse
primero. A continuación, se crea EMPPROJACT con la sentencia siguiente:
CREATE TABLE DSN8910.EMPPROJACT
PROJNO CHAR(6) NOT NULL,
ACTNO SMALLINT NOT NULL,
EMPTIME DECIMAL(5,2) ,
EMSTDATE DATE ,
EMENDATE DATE ,
FOREIGN KEY REPAPA (PROJNO, ACTNO, EMSTDATE)
REFERENCES DSN8910.PROJACT
ON DELETE RESTRICT,
FOREIGN KEY REPAE (EMPNO) REFERENCES DSN8910.EMP
ON DELETE RESTRICT)
CCSID EBCDIC;
Contenido de la tabla de empleados de actividades de proyectos
La tabla siguiente muestra el contenido de las columnas de la tabla de empleados

de actividades de proyectos.
Tabla 22. Columnas de la tabla de empleados de actividades de proyectos
1 EMPNO Número de ID del empleado
2 PROJNO ID de proyecto del proyecto

Tabla 22. Columnas de la tabla de empleados de actividades de proyectos (continuación)
3 ACTNO ID de actividad dentro del proyecto
4 EMPTIME Proporción del tiempo completo del empleado (entre
0,00 y 1,00) que debe dedicarse a la actividad
5 EMSTDATE Fecha de inicio de la actividad
6 EMENDATE Fecha de finalización de la actividad
La tabla siguiente muestra los índices para la tabla de empleados para actividades
de proyectos:
Tabla 23. Índices de la tabla de empleados de actividades de proyectos
Nombre En columnas Tipo de índice
DSN8910.XEMPPROJACT1 PROJNO, ACTNO, Exclusivo, ascendente
EMSTDATE, EMPNO
DSN8910.XEMPPROJACT2 EMPNO Ascendente
La tabla de empleados de actividades de proyectos depende de las tablas

siguientes:
v La tabla de empleados, mediante su clave foránea en la columna EMPNO
v La tabla de actividades de proyectos, mediante su clave foránea en las columnas
PROJNO, ACTNO y EMSTDATE.
Tabla de ejemplo Unicode (DSN8910.DEMO_UNICODE)

La tabla de ejemplo Unicode se utiliza para comprobar que las conversiones de
datos entre EBCDIC y Unicode funcionen como se espera.
La tabla reside en la base de datos DSN8D91A y se define con la sentencia

siguiente:
CREATE TABLE DSN8910.DEMO_UNICODE
(LOWER_A_TO_Z CHAR(26) ,
UPPER_A_TO_Z CHAR(26) ,
ZERO_TO_NINE CHAR(10) ,
X00_TO_XFF VARCHAR(256) FOR BIT DATA)
IN DSN8D81E.DSN8S81U
CCSID UNICODE;
Contenido de la tabla de ejemplo Unicode
La tabla siguiente muestra el contenido de las columnas de la tabla de ejemplo

Unicode:
Tabla 24. Columnas de la tabla de ejemplo Unicode
1 LOWER_A_TO_Z Matriz de caracteres, de ’a’ a ’z’

Tabla 24. Columnas de la tabla de ejemplo Unicode (continuación)
2 UPPER_A_TO_Z Matriz de caracteres, de ’A’ a ’Z’
3 ZERO_TO_NINE Matriz de caracteres, de ’0’ a ’9’
4 X00_TO_XFF Matriz de caracteres, de x’00’ a x’FF’
Esta tabla no tiene índices.
Esta tabla no tiene ninguna relación con otras tablas.

″Conversión de caracteres en DB2″ (DB2 for z/OS Internationalization Guide)
Relaciones entre las tablas de ejemplo

Las relaciones entre las tablas de ejemplo se establecen mediante claves foráneas en
tablas dependientes que hacen referencia a claves primarias de tablas padre.
La figura siguiente muestra las relaciones entre las tablas de ejemplo.

Encontrará las descripciones de las columnas en las descripciones de las tablas.
Figura 26. Relaciones entre tablas en la aplicación de ejemplo
“Tabla de actividades (DSN8910.ACT)” en la página 124
“Tabla de departamentos (DSN8910.DEPT)” en la página 125

“Tabla de fotografías y currículums de empleados
(DSN8910.EMP_PHOTO_RESUME)” en la página 130
“Tabla de proyectos (DSN8910.PROJ)” en la página 132
“Tabla de empleados de actividades de proyectos (DSN8910.EMPPROJACT)” en
la página 134
“Tabla de ejemplo Unicode (DSN8910.DEMO_UNICODE)” en la página 135
Vistas en las tablas de ejemplo

DB2 crea un número de vistas en las tablas de ejemplo para utilizarlas en las
aplicaciones de ejemplo.
La tabla siguiente indica las tablas en las que se define cada vista y las
aplicaciones de ejemplo que utilizan la vista. Todos los nombres de vista tienen el
calificador DSN8910.
Tabla 25. Vistas en tablas de ejemplo
Nombre de vista En tablas o vistas Utilizada en la aplicación
VDEPT DEPT
Proyecto de
Proyecto
VHDEPT DEPT Organización distribuida
VEMP EMP
Organización distribuida
Proyecto de
Proyecto
VPROJ PROJ Proyecto
VACT ACT Proyecto
VPROJACT PROJACT Proyecto
VEMPPROJACT EMPPROJACT Proyecto
VDEPMG1 Organización
DEPT
EMP
VEMPDPT1 Organización
DEPT
EMP
VASTRDE1 DEPT
VASTRDE2 Organización
VDEPMG1
EMP
VPROJRE1 Proyecto
PROJ
EMP
VPSTRDE1 Proyecto
VPROJRE1 VPROJRE2
VPSTRDE2 VPROJRE1 Proyecto

Tabla 25. Vistas en tablas de ejemplo (continuación)
Nombre de vista En tablas o vistas Utilizada en la aplicación
VFORPLA Proyecto
VPROJRE1
EMPPROJACT
VSTAFAC1 Proyecto
PROJACT
ACT
VSTAFAC2 Proyecto
EMPPROJACT
ACT
EMP
VPHONE Teléfono
EMP
DEPT
VEMPLP EMP Teléfono
La sentencia de SQL siguiente crea la vista denominada VDEPT.

CREATE VIEW DSN8910.VDEPT
AS SELECT ALL DEPTNO ,
DEPTNAME,
MGRNO ,
ADMRDEPT
FROM DSN8910.DEPT;
La sentencia de SQL siguiente crea la vista denominada VHDEPT.

CREATE VIEW DSN8910.VHDEPT
AS SELECT ALL DEPTNO ,
DEPTNAME,
MGRNO ,
ADMRDEPT,
LOCATION
FROM DSN8910.DEPT;
La sentencia de SQL siguiente crea la vista denominada VEMP.

CREATE VIEW DSN8910.VEMP
AS SELECT ALL EMPNO ,
FIRSTNME,
MIDINIT ,
LASTNAME,
WORKDEPT
FROM DSN8910.EMP;
La sentencia de SQL siguiente crea la vista denominada VPROJ.

CREATE VIEW DSN8910.VPROJ
AS SELECT ALL
PROJNO, PROJNAME, DEPTNO, RESPEMP, PRSTAFF,
PRSTDATE, PRENDATE, MAJPROJ
FROM DSN8910.PROJ ;
La sentencia de SQL siguiente crea la vista denominada VACT.

CREATE VIEW DSN8910.VACT
AS SELECT ALL ACTNO ,
ACTKWD ,
ACTDESC
FROM DSN8910.ACT ;

La sentencia de SQL siguiente crea la vista denominada VPROJACT.
CREATE VIEW DSN8910.VPROJACT
AS SELECT ALL
PROJNO,ACTNO, ACSTAFF, ACSTDATE, ACENDATE
FROM DSN8910.PROJACT ;
La sentencia de SQL siguiente crea la vista denominada VEMPPROJACT.

CREATE VIEW DSN8910.VEMPPROJACT
AS SELECT ALL
EMPNO, PROJNO, ACTNO, EMPTIME, EMSTDATE, EMENDATE
FROM DSN8910.EMPPROJACT ;
La sentencia de SQL siguiente crea la vista denominada VDEPMG1.

CREATE VIEW DSN8910.VDEPMG1
(DEPTNO, DEPTNAME, MGRNO, FIRSTNME, MIDINIT,
LASTNAME, ADMRDEPT)
AS SELECT ALL
DEPTNO, DEPTNAME, EMPNO, FIRSTNME, MIDINIT,
LASTNAME, ADMRDEPT
FROM DSN8910.DEPT LEFT OUTER JOIN DSN8910.EMP
ON MGRNO = EMPNO ;
La sentencia de SQL siguiente crea la vista denominada VEMPDPT1.

CREATE VIEW DSN8910.VEMPDPT1
(DEPTNO, DEPTNAME, EMPNO, FRSTINIT, MIDINIT,
LASTNAME, WORKDEPT)
AS SELECT ALL
DEPTNO, DEPTNAME, EMPNO, SUBSTR(FIRSTNME, 1, 1), MIDINIT,
LASTNAME, WORKDEPT
FROM DSN8910.DEPT RIGHT OUTER JOIN DSN8910.EMP
ON WORKDEPT = DEPTNO ;
La sentencia de SQL siguiente crea la vista denominada VASTRDE1.

CREATE VIEW DSN8910.VASTRDE1
(DEPT1NO,DEPT1NAM,EMP1NO,EMP1FN,EMP1MI,EMP1LN,TYPE2,
DEPT2NO,DEPT2NAM,EMP2NO,EMP2FN,EMP2MI,EMP2LN)
AS SELECT ALL
D1.DEPTNO,D1.DEPTNAME,D1.MGRNO,D1.FIRSTNME,D1.MIDINIT,
D1.LASTNAME, '1',
D2.LASTNAME
FROM DSN8910.VDEPMG1 D1, DSN8910.VDEPMG1 D2
WHERE D1.DEPTNO = D2.ADMRDEPT ;
La sentencia de SQL siguiente crea la vista denominada VASTRDE2.

CREATE VIEW DSN8910.VASTRDE2
(DEPT1NO,DEPT1NAM,EMP1NO,EMP1FN,EMP1MI,EMP1LN,TYPE2,
DEPT2NO,DEPT2NAM,EMP2NO,EMP2FN,EMP2MI,EMP2LN)
AS SELECT ALL
D1.LASTNAME,'2',
D1.DEPTNO,D1.DEPTNAME,E2.EMPNO,E2.FIRSTNME,E2.MIDINIT,
E2.LASTNAME
FROM DSN8910.VDEPMG1 D1, DSN8910.EMP E2
WHERE D1.DEPTNO = E2.WORKDEPT;
La figura siguiente muestra la sentencia de SQL que crea la vista denominada

VPROJRE1.

CREATE VIEW DSN8910.VPROJRE1
(PROJNO,PROJNAME,PROJDEP,RESPEMP,FIRSTNME,MIDINIT,
LASTNAME,MAJPROJ)
AS SELECT ALL
PROJNO,PROJNAME,DEPTNO,EMPNO,FIRSTNME,MIDINIT,
LASTNAME,MAJPROJ
FROM DSN8910.PROJ, DSN8910.EMP
WHERE RESPEMP = EMPNO ;
Figura 27. VPROJRE1
La sentencia de SQL siguiente crea la vista denominada VPSTRDE1.

CREATE VIEW DSN8910.VPSTRDE1
(PROJ1NO,PROJ1NAME,RESP1NO,RESP1FN,RESP1MI,RESP1LN,
PROJ2NO,PROJ2NAME,RESP2NO,RESP2FN,RESP2MI,RESP2LN)
AS SELECT ALL
P1.PROJNO,P1.PROJNAME,P1.RESPEMP,P1.FIRSTNME,P1.MIDINIT,
P1.LASTNAME,
P2.LASTNAME
FROM DSN8910.VPROJRE1 P1,
DSN8910.VPROJRE1 P2
WHERE P1.PROJNO = P2.MAJPROJ ;
La sentencia de SQL siguiente crea la vista denominada VPSTRDE2.

CREATE VIEW DSN8910.VPSTRDE2
(PROJ1NO,PROJ1NAME,RESP1NO,RESP1FN,RESP1MI,RESP1LN,
PROJ2NO,PROJ2NAME,RESP2NO,RESP2FN,RESP2MI,RESP2LN)
AS SELECT ALL
P1.LASTNAME,
P1.LASTNAME
FROM DSN8910.VPROJRE1 P1
WHERE NOT EXISTS
(SELECT * FROM DSN8910.VPROJRE1 P2
WHERE P1.PROJNO = P2.MAJPROJ) ;
La sentencia de SQL siguiente crea la vista denominada VFORPLA.

CREATE VIEW DSN8910.VFORPLA
(PROJNO,PROJNAME,RESPEMP,PROJDEP,FRSTINIT,MIDINIT,LASTNAME)
AS SELECT ALL
F1.PROJNO,PROJNAME,RESPEMP,PROJDEP, SUBSTR(FIRSTNME, 1, 1),
MIDINIT, LASTNAME
FROM DSN8910.VPROJRE1 F1 LEFT OUTER JOIN DSN8910.EMPPROJACT F2
ON F1.PROJNO = F2.PROJNO;
La sentencia de SQL siguiente crea la vista denominada VSTAFAC1.

CREATE VIEW DSN8910.VSTAFAC1
(PROJNO, ACTNO, ACTDESC, EMPNO, FIRSTNME, MIDINIT, LASTNAME,
EMPTIME,STDATE,ENDATE, TYPE)
AS SELECT ALL
PA.PROJNO, PA.ACTNO, AC.ACTDESC,' ', ' ', ' ', ' ',
PA.ACSTAFF, PA.ACSTDATE,
PA.ACENDATE,'1'
FROM DSN8910.PROJACT PA, DSN8910.ACT AC
WHERE PA.ACTNO = AC.ACTNO ;
La sentencia de SQL siguiente crea la vista denominada VSTAFAC2.

CREATE VIEW DSN8910.VSTAFAC2
(PROJNO, ACTNO, ACTDESC, EMPNO, FIRSTNME, MIDINIT, LASTNAME,
EMPTIME,STDATE, ENDATE, TYPE)
AS SELECT ALL

EP.PROJNO, EP.ACTNO, AC.ACTDESC, EP.EMPNO,EM.FIRSTNME,
EM.MIDINIT, EM.LASTNAME, EP.EMPTIME, EP.EMSTDATE,
EP.EMENDATE,'2'
FROM DSN8910.EMPPROJACT EP, DSN8910.ACT AC, DSN8910.EMP EM
WHERE EP.ACTNO = AC.ACTNO AND EP.EMPNO = EM.EMPNO ;
La sentencia de SQL siguiente crea la vista denominada VPHONE.

CREATE VIEW DSN8910.VPHONE
(LASTNAME,
FIRSTNAME,
MIDDLEINITIAL,
PHONENUMBER,
EMPLOYEENUMBER,
DEPTNUMBER,
DEPTNAME)
AS SELECT ALL LASTNAME,
FIRSTNME,
MIDINIT ,
VALUE(PHONENO,' '),
EMPNO,
DEPTNO,
DEPTNAME
FROM DSN8910.EMP, DSN8910.DEPT
WHERE WORKDEPT = DEPTNO;
La sentencia de SQL siguiente crea la vista denominada VEMPLP.

CREATE VIEW DSN8910.VEMPLP
(EMPLOYEENUMBER,
PHONENUMBER)
AS SELECT ALL EMPNO ,
PHONENO
FROM DSN8910.EMP ;
Almacenamiento de tablas de aplicaciones de ejemplo

Normalmente, los datos relacionados se almacenan en la misma base de datos.
La figura siguiente muestra cómo se relacionan las tablas de ejemplo con

bases de datos y grupos de almacenamientos. Se utilizan dos bases de datos para
ilustrar la posibilidad.

Figura 28. Relación entre bases de datos y espacios de tablas de ejemplo
Además del grupo de almacenamientos y las bases de datos que se muestran en la

figura anterior, se crean el grupo de almacenamiento DSN8G91U y la base de datos
DSN8D91U cuando se ejecuta DSNTEJ2A.
Grupo de almacenamiento para datos de aplicaciones de

ejemplo
Los datos de aplicaciones de ejemplo se almacenan en el grupo de almacenamiento
DSN8G910. El grupo de almacenamiento por omisión, SYSDEFLT, que se crea
cuando se instala DB2, no se utiliza para almacenar los datos de aplicaciones de
ejemplo.
El grupo de almacenamiento que se utiliza para almacenar datos de

aplicaciones de ejemplo se define con la sentencia siguiente:
CREATE STOGROUP DSN8G910
VOLUMES (DSNV01)
VCAT DSNC910;
Bases de datos para datos de aplicaciones de ejemplo

Los datos de aplicaciones de ejemplo se almacenan en varias bases de datos. La
base de datos por omisión que se crea cuando se instala DB2 no se utiliza para
almacenar los datos de aplicaciones de ejemplo.
DSN8D91P es la base de datos que se utiliza para tablas relacionadas con

programas. Las otras bases de datos se utilizan para tablas que están relacionadas
con aplicaciones. Las bases de datos se definen mediante las sentencias siguientes:
| CREATE DATABASE DSN8D91A
| STOGROUP DSN8G910
| BUFFERPOOL BP0
| CCSID EBCDIC;
|
| CREATE DATABASE DSN8D91P
| STOGROUP DSN8G910
| BUFFERPOOL BP0
| CCSID EBCDIC;
|
| CREATE DATABASE DSN8D91L
| STOGROUP DSN8G910
| BUFFERPOOL BP0
| CCSID EBCDIC;
|
| CREATE DATABASE DSN8D91E
| STOGROUP DSN8G910
| BUFFERPOOL BP0
| CCSID UNICODE;
|
| CREATE DATABASE DSN8D91U
| STOGROUP DSN8G91U
| CCSID EBCDIC;
Espacios de tablas para datos de aplicaciones de ejemplo

Los espacios de tablas que no se definen explícitamente se crean implícitamente en
la base de datos DSN8D91A, utilizando los atributos de espacio por omisión.
Las sentencias de SQL siguiente definen explícitamente una serie de

espacios de tablas.
CREATE TABLESPACE DSN8S91D
IN DSN8D91A
USING STOGROUP DSN8G910
PRIQTY 20
SECQTY 20
ERASE NO
LOCKSIZE PAGE LOCKMAX SYSTEM
BUFFERPOOL BP0
CLOSE NO
CCSID EBCDIC;
CREATE TABLESPACE DSN8S91E

IN DSN8D91A
PRIQTY 20
SECQTY 20
ERASE NO
NUMPARTS 4
(PART 1 USING STOGROUP DSN8G910
PRIQTY 12
SECQTY 12,
PART 3 USING STOGROUP DSN8G910
PRIQTY 12
SECQTY 12)
BUFFERPOOL BP0
CLOSE NO
COMPRESS YES
CCSID EBCDIC;
CREATE TABLESPACE DSN8S91B
IN DSN8D91L
PRIQTY 20
SECQTY 20
ERASE NO
LOCKSIZE PAGE
LOCKMAX SYSTEM
BUFFERPOOL BP0
CLOSE NO
CCSID EBCDIC;

CREATE LOB TABLESPACE DSN8S91M
IN DSN8D91L
LOG NO;
CREATE LOB TABLESPACE DSN8S91L

IN DSN8D91L
LOG NO;
CREATE LOB TABLESPACE DSN8S91N

IN DSN8D91L
LOG NO;
CREATE TABLESPACE DSN8S91C
IN DSN8D91P
PRIQTY 160
SECQTY 80
SEGSIZE 4
LOCKSIZE TABLE
BUFFERPOOL BP0
CLOSE NO
CCSID EBCDIC;
CREATE TABLESPACE DSN8S91P

IN DSN8D91A
PRIQTY 160
SECQTY 80
SEGSIZE 4
LOCKSIZE ROW
BUFFERPOOL BP0
CLOSE NO
CCSID EBCDIC;
CREATE TABLESPACE DSN8S91R
IN DSN8D91A
PRIQTY 20
SECQTY 20
ERASE NO
BUFFERPOOL BP0
CLOSE NO
CCSID EBCDIC;
CREATE TABLESPACE DSN8S91S
IN DSN8D91A
PRIQTY 20
SECQTY 20
ERASE NO
BUFFERPOOL BP0
CLOSE NO
CCSID EBCDIC;
CREATE TABLESPACE DSN8S81Q
IN DSN8D81P
PRIQTY 160
SECQTY 80
SEGSIZE 4
LOCKSIZE PAGE
BUFFERPOOL BP0
CLOSE NO
CCSID EBCDIC;
CREATE TABLESPACE DSN8S81U
IN DSN8D81E

PRIQTY 5
SECQTY 5
ERASE NO
BUFFERPOOL BP0
CLOSE NO
CCSID UNICODE;

Capítulo 6. Programación de aplicaciones para DB2
DB2 permite una amplia variedad de opciones para diseñar y codificar programas
de aplicaciones. Las opciones de diseño de aplicaciones incluyen desde
aplicaciones de un único nivel a aplicaciones de varios niveles y hay disponible
una amplia gama de opciones para herramientas y lenguajes para desarrollar
aplicaciones.
Los programadores disponen de una amplia variedad de opciones para diseñar sus
aplicaciones de base de datos. Estas opciones incluyen desde aplicaciones de un
único nivel, en las que la lógica y los datos residen en zSeries, hasta aplicaciones
de varios niveles. Una aplicación de varios niveles compleja puede tener un cliente
navegador con lógica de aplicaciones empresariales para acceso a datos que se
ejecute en un servidor de aplicaciones web de nivel medio y lógica de base de
datos que se ejecute con el servidor de bases de datos como procedimientos
almacenados.
Los usuarios disponen de una amplia gama de opciones no sólo para la

arquitectura de la aplicación, sino también para las herramientas y lenguajes que se
utilizan para el desarrollo. La escritura de un programa de aplicación varía para
cada lenguaje de programación y para cada estilo de aplicación. Esta información
no pretende enseñarle cómo convertirse en un programador de aplicaciones. En
lugar de ello, describe los conceptos generales sobre codificación que necesita saber
que son específicos de DB2 for z/OS. Puede aplicar estos conceptos a los distintos
lenguajes. La información explica diversas técnicas que se pueden utilizar para
escribir un programa de aplicación para DB2.
Se proporcionan detalles principalmente para las partes de la aplicación que se

ejecutan en z/OS. Las aplicaciones cliente que se ejecutan en otros sistemas
operativos y acceden a datos de DB2 for z/OS se describen brevemente.
Desarrollo de aplicaciones de DB2 en entornos de desarrollo

integrados
Puede utilizar varias herramientas y lenguajes para desarrollar aplicaciones que
accedan a datos de DB2 for z/OS. Las herramientas de desarrollo más populares
incluyen la familia de productos de IBM WebSphere Studio, las herramientas de
Microsoft Visual Studio, VisualCafe, Borland JBuilder y muchas otras. El acceso
desde estas herramientas se realiza mediante varias opciones de acceso como, por
ejemplo servicios web y API populares. Además de estos mecanismos de acceso se
crean varios estilos de código.
Tanto si se desarrollan aplicaciones de escritorio o basadas en la web, DB2 ofrece

opciones para trabajar con varios lenguajes de programación, estilos de desarrollo
de aplicaciones y sistemas operativos. DB2 proporciona herramientas para
desarrollar aplicaciones en entornos de desarrollo Java y Microsoft. Las tres áreas
primarias del soporte de desarrollo de DB2 en entornos de desarrollo integrados
(IDE) se proporcionan con WebSphere Studio, Microsoft Visual Studio y DB2
Developer Workbench.
v WebSphere Studio: la integración de DB2 con WebSphere Studio proporciona
desarrollo del servidor para procedimientos almacenados y funciones definidas
por el usuario e integración con el entorno de desarrollo J2EE. Este IDE facilita

el desarrollo de funciones del servidor y el desarrollo de aplicaciones de J2EE y
de aplicaciones de servicio web dentro del mismo entorno de desarrollo.
v Microsoft Visual Studio: la integración con Microsoft Visual Studio proporciona
integración de desarrollo del servidor y aplicaciones de DB2. En este IDE, los
programadores de aplicaciones pueden crear aplicaciones que utilicen soporte de
Microsoft.
v DB2 Developer Workbench: DB2 Developer Workbench está integrado con las
otras herramientas de administración de DB2 como, por ejemplo, el Centro de
control de DB2. DB2 Developer Workbench está enfocado al desarrollo del
servidor de DB2 para procedimientos almacenados y funciones definidas por el
usuario.
El acceso desde estas herramientas se realiza mediante todas las API de utilización
frecuente entre las que se incluye JDBC y ODBC, OLE DB, ADO.NET y ADO. Con
estas opciones de acceso, los programadores de aplicaciones pueden utilizar
muchas otras herramientas de desarrollo actuales, que incluyen soporte de editor
básico y de línea de mandatos, para el desarrollo de aplicaciones de DB2.

IBM WebSphere Studio Application Developer proporciona soporte global para
desarrollar aplicaciones que accedan a DB2.
| La familia de WebSphere Studio proporciona una serie de herramientas muy

| eficaces para el desarrollo de aplicaciones y webs. Una herramienta clave para el
| desarrollo de aplicaciones es WebSphere Studio Application Developer, que
| sustituye a su predecesora, IBM VisualAge para Java.
Con WebSphere Studio Application Developer puede crear aplicaciones J2EE con
archivos JSP (JavaServer Page) y componentes de EJB (Enterprise JavaBean), crear
aplicaciones de servicios web y generar documentos XML.
en la página 303
DB2 Development Add-In for Visual Studio .NET

DB2 Development Add-In for Microsoft Visual Studio .NET proporciona soporte de
desarrollo de DB2 estrechamente integrado en el entorno de desarrollo de
Microsoft Visual Studio .NET. Las características Add-In (accesorios) facilitan a los
programadores de aplicaciones el trabajo con servidores de DB2 y el desarrollo de
rutinas y objetos de DB2.
Las características Add-In permiten realizar las siguientes tareas a los

desarrolladores:
v Crear objetos del lado del servidor de DB2
DB2 Connect proporciona un proveedor de datos .NET para DB2, que permite a
las aplicaciones .NET acceder a DB2 for z/OS y sistemas operativos de estación
de trabajo (Windows, UNIX y Linux).
Utilizando Solution Explorer, los desarrolladores pueden utilizar archivos de
script para crear objetos que incluyan rutinas, desencadenantes, tablas y vistas.

v Acceder a conexiones de datos de DB2 y gestionarlas
IBM Explorer proporciona acceso a conexiones de base de datos de IBM y
permite realizar las tareas siguientes a los desarrolladores:
– Trabajar con varias conexiones de DB2
– Ver propiedades de objetos
– Recuperar y actualizar datos de tablas y vistas
– Ver código fuente para procedimientos y funciones de DB2
– Generar código ADO .NET utilizando una técnica de arrastrar y soltar
v Iniciar herramientas de administración y desarrollo de DB2
Estas herramientas incluyen DB2 Developer Workbench, Centro de control,
Centro de duplicación, Centro de mandatos, Centro de tareas, Diario y Centro de
información de DB2.
Herramientas de desarrollo de aplicaciones de estación de

trabajo
Existe una amplia variedad de herramientas disponibles para realizar tareas como,
por ejemplo, consultar una base de datos. Estas herramientas incluyen
herramientas basadas en ODBC tales como Lotus Approach, Microsoft Access,
Microsoft Visual Basic, Microsoft Excel y muchas otras.
Las herramientas basadas en ODBC proporcionan una alternativa más simple para
desarrollar aplicaciones que la utilización de un lenguaje de programación de alto
nivel. QMF para Windows proporciona acceso a datos de DB2 para estas
herramientas. Con todas estas herramientas, puede especificar DB2 for z/OS como
la base de datos a la que debe accederse.
“Utilización de DB2 Query Management Facility para Workstation” en la
página 123
Lenguajes de programación y métodos para desarrollar programas de

aplicaciones
Puede utilizar una amplia variedad de lenguajes de programación y técnicas para
desarrollar programas de aplicaciones para DB2 for z/OS. Además, hay
disponibles varios métodos para comunicarse con DB2.
Puede elegir entre los siguientes lenguajes de programación:

| v APL2
v C
v C++
v C#
v COBOL
v Fortran
v Assembler de alto nivel (parte del sistema operativo z/OS)
v Java
v .NET
| v Perl
| v PHP
v PL/I
v REXX
| v Ruby on Rails
v Smalltalk
v Lenguaje de procedimiento de SQL
Capítulo 6. Programación de aplicaciones para DB2 149

| v TOAD para DB2
v Visual Basic
Puede utilizar uno de los siguientes métodos de programación:

SQL estático
La forma de origen de una sentencia de SQL estático se incluye en un
programa de aplicación que se escribe en un lenguaje de programación
tradicional. (Los lenguajes de programación tradicionales incluyen C, C++,
COBOL, Fortran, PL/I y Assembler.) La utilización de SQL estático es una
buena opción si sabe qué sentencias necesita ejecutar una aplicación antes
de ejecutar la aplicación.
SQL dinámico
A diferencia del SQL estático, las sentencias dinámicas se crean y preparan
durante el tiempo de ejecución. La utilización de SQL dinámico es una
buena opción si no conoce el formato de una sentencia de SQL al escribir
un programa. También es una buena opción si el programa necesita
generar parte o toda una sentencia de SQL basándose en entrada de sus
usuarios.
ODBC
ODBC es una interfaz de programación de aplicaciones (API) que los
programas de aplicaciones C y C++ pueden utilizar para acceder a bases
de datos relacionales. ODBC se adapta mejor al entorno cliente/servidor.
SQLJ y JDBC
Como ODBC y C++, las interfaces SQLJ y JDBC de Java le permiten
escribir programas de aplicaciones trasladables independientes de
cualquier producto de base de datos.
v El soporte de aplicación SQLJ le permite escribir aplicaciones de SQL
estático en el lenguaje de programación Java. Con SQLJ, puede incluir
sentencias de SQL en las aplicaciones de Java.
v El soporte de aplicación JDBC le permite escribir aplicaciones de SQL
dinámico en el lenguaje de programación Java. JDBC es similar a ODBC,
pero está específicamente diseñado para utilizarse con Java.
“Aplicaciones de SQL estático” en la página 154
“Aplicaciones de SQL dinámico” en la página 162
Tareas relacionadas
″Planificación y diseño de aplicaciones de DB2″ (DB2 Application Programming
and SQL Guide)
Proceso de preparación para un programa de aplicación

El modo en que se prepara un programa de aplicación para ejecutarse depende del
tipo de aplicación. Los pasos de la preparación de un programa para aplicaciones
varían según el tipo de lenguaje de programación que se utiliza.
Las aplicaciones de DB2 necesitan diferentes métodos de preparación de

programas, según el tipo de aplicación.

Aplicaciones que contienen sentencias de SQL estático o dinámico incorporadas
Las aplicaciones de DB2 incorporan sentencias de SQL en programas de
lenguajes tradicionales. Para utilizar estos programas, es necesario seguir
los pasos de preparación típicos (compilación, edición de enlaces y
ejecución) además de los pasos de precompilación y vinculación de DB2.
La primera de las figuras siguientes proporciona una visión general de
estos pasos de preparación.
| Aplicaciones en lenguajes interpretados como, por ejemplo, REXX y APL2
Los procedimientos REXX utilizan SQL dinámico. No se precompilan,
compilan, editan enlaces ni vinculan procedimientos REXX de DB2 antes
de ejecutarlos.
Aplicaciones que contienen llamadas ODBC
Estas aplicaciones pasan sentencias de SQL dinámico como argumentos.
No se precompilan ni vinculan aplicaciones ODBC. Las aplicaciones ODBC
utilizan un conjunto de funciones estándar para ejecutar sentencias de SQL
y servicios relacionados durante el tiempo de ejecución.
Aplicaciones de Java, que pueden contener llamadas JDBC o sentencias de SQL
incorporadas
La preparación de un programa de Java que contiene únicamente métodos
JDBC es igual que la preparación de cualquier otro programa de Java. Para
compilar el programa se utiliza el mandato javac. Las aplicaciones JDBC
no requieren los pasos de precompilación ni vinculación.
| La preparación de un programa SQLJ requiere un paso de precompilación
| y un paso de vinculación.
Los lenguajes de programación tradicionales requieren los siguientes pasos de

preparación de programa.
Precompilar
Antes de compilar o ensamblar un programa de lenguaje tradicional debe
preparar las sentencias de SQL que están incorporadas en el programa. El
precompilador de DB2 prepara sentencias de SQL para aplicaciones C,
COBOL, Fortran, PL/I y Assembler. Debido a que la mayoría de
compiladores no reconocen sentencias de SQL debe utilizar el
precompilador de DB2 antes de compilar el programa para evitar errores
de compilador. El precompilador explora el programa y devuelve código
fuente modificado que, a continuación se puede compilar y al que se
puede aplicar edición de enlaces.
| Como alternativa, puede utilizar un coprocesador de lenguaje principal de
| DB2 para C, C++, COBOL y PL/I cuando compile el programa. El
| coprocesador de DB2 realiza funciones de precompilador de DB2 durante
| el tiempo de compilación.
La salida principal del precompilador es un módulo de petición de base de
datos (DBRM). Un DBRM es un conjunto de datos que contiene sentencias
de SQL e información de variables de lenguaje principal que se obtiene del
programa fuente durante la preparación del programa. La finalidad de un
DBRM es comunicar las peticiones de SQL con DB2 durante el proceso de
vinculación.
Vincular
Antes de ejecutar la aplicación de DB2 debe utilizar el mandato BIND para
vincular el DBRM con un plan o un paquete. Por ejemplo, puede decidir
poner determinadas sentencias de SQL juntas en el mismo programa a fin
de precompilarlas en el mismo DBRM y, a continuación, vincularlas en un

único paquete. Cuando se ejecuta el programa, DB2 utiliza una indicación
de fecha y hora para verificar que el programa coincide con el plan o
paquete correcto.
Un plan puede contener varios DBRM, una lista de paquetes que
especifique paquetes o colecciones de paquetes o una combinación de
varios DBRM y una lista de paquetes. El plan debe contener como mínimo
un paquete o como mínimo un DBRM directamente vinculado. Cada
paquete que se vincula sólo puede contener un DBRM.
Una colección es un grupo de paquetes asociados. La vinculación de
paquetes en colecciones de paquetes le permite añadir paquetes a un plan
de aplicación existente sin necesidad de volver a vincular todo el plan. Si
incluye un nombre de colección en la lista de paquetes al vincular un plan,
cualquier paquete que esté en la colección estará disponible para el plan.
Incluso es posible que la colección esté vacía la primera vez que vincula el
plan. Más adelante, puede añadir paquetes a la colección y descartar o
sustituir paquetes existentes sin volver a vincular el plan.
El registro especial CURRENT PACKAGE PATH especifica un valor que
identifica una lista de colecciones que DB2 utiliza para resolver las
referencias a paquetes que se utilizan para ejecutar sentencias de SQL.
Compilar, editar enlaces
Para permitir que la aplicación intercambie información con el subsistema
DB2 debe utilizar un procedimiento de edición de enlaces para crear un
módulo de carga ejecutable que cumpla los requisitos del entorno (tales
como CICS, IMS, TSO o de proceso por lotes). El módulo de carga es una
unidad de programa que se carga en el almacenamiento principal para la
ejecución.
Ejecutar
Una vez completados los pasos anteriores puede ejecutar la aplicación de
DB2. Existen varios métodos disponibles para preparar una aplicación para
ejecutarse. Puede hacer lo siguiente:
v Utilizar paneles de DB2 Interactive (DB2I), que le guían paso a paso
desde la preparación del programa a la ejecución del programa.
v Someter una aplicación en primer plano de TSO o por lotes en segundo
plano de TSO.
v Iniciar la lista de mandatos de preparación de programas (CLIST) en
primer plano de TSO o por lotes.
v Utilizar el procesador de mandatos de DSN.
v Utilizar procedimientos de JCL para incluirlos en conjuntos de datos
(por ejemplo, SYS1.PROCLIB) durante la instalación de DB2.
También puede precompilar y preparar un programa de aplicación utilizando un

procedimiento proporcionado por DB2. DB2 dispone de un procedimiento
exclusivo para cada lenguaje soportado.

Programa
fuente
de entrada
DB2
Compilador DBRM
precompilador
Editor de Proceso de
enlaces vinculación
Módulo Paquete
de carga o plan
Figura 29. Visión general del proceso de preparación de un programa para aplicaciones que
contienen SQL incorporado cuando se utiliza el precompilador de DB2

Figura 30. Visión general del proceso de preparación de un programa cuando se utiliza el
coprocesador de DB2
Herramienta DB2 Bind Manager
La herramienta DB2 Bind Manager ayuda a los programadores de aplicaciones a:

v Predecir si una vinculación de un DBRM tendrá como resultado una vía de
acceso modificada
v Ejecutar selecciones de vía de acceso en un proceso por lotes de DBRM
v Eliminar los pasos de vinculación innecesarios entre los programas de
aplicaciones y la base de datos
v Comparar los DBRM con subsistemas y módulos de carga
| Herramienta DB2 Path Checker
| DB2 Path Checker le ayuda a aumentar la estabilidad de los entornos de DB2 y a

| evitar interrupciones molestas y costosas. DB2 Path Checker puede ayudarle a
| descubrir y corregir cambios de vía de acceso inesperados antes de que se le
| informe de ellos.
Tareas relacionadas
″Preparación de una aplicación para ejecutarla en DB2 para z/OS″ (DB2
Application Programming and SQL Guide)
Aplicaciones de SQL estático

Para la mayoría de usuarios de DB2, SQL estático proporciona una vía de acceso
directa y eficaz a los datos de DB2.

La forma de origen de una sentencia de SQL estático se incluye en un programa de
aplicación que se escribe en un lenguaje de programación tradicional como, por
ejemplo, C. La sentencia se prepara antes de ejecutar el programa y la forma
operativa de la sentencia permanece hasta después de la ejecución del programa.
Puede utilizar SQL estático cuando sabe antes del tiempo de ejecución qué
sentencias de SQL necesita ejecutar la aplicación.
| Cuando utiliza SQL estático, no puede cambiar la forma de las sentencias de SQL a
| menos que realice cambios en el programa. Sin embargo, puede aumentar la
| flexibilidad de estas sentencias utilizando variables de lenguaje principal. La
| utilización de SQL estático y variables de lenguaje principal es más segura que la
| utilización de SQL.
Ejemplo: Suponga que codifica SQL estático en un programa COBOL. La siguiente

sentencia UPDATE puede actualizar el salario de cualquier empleado. Cuando
escribe el programa sabe que deben actualizarse los salarios pero no sabe hasta el
tiempo de ejecución los salarios de quién deben actualizarse ni cuánto.
01 IOAREA.
02 EMPID PIC X(06).
. 02 NEW-SALARY PIC S9(7)V9(2) COMP-3.
.
.
(Otras declaraciones)
READ CARDIN RECORD INTO IOAREA
. AT END MOVE 'N' TO INPUT-SWITCH.
.
.
(Otras sentencias COBOL)
EXEC SQL
UPDATE EMP
SET SALARY = :NEW-SALARY
WHERE EMPNO = :EMPID
END-EXEC.
La sentencia UPDATE no cambia, ni tampoco su estructura básica, pero la entrada

puede cambiar los resultados de la sentencia UPDATE.
Se aplican los conceptos de codificación de SQL básica a los lenguajes de

programación tradicionales: C, C++, COBOL, Fortran, PL/I y Assembler.
Suponga que escribe un programa de aplicación para acceder a los datos de una
base de datos de DB2. Cuando el programa ejecuta una sentencia de SQL, el
programa necesita comunicarse con DB2. Cuando DB2 finaliza el proceso de una
sentencia de SQL, DB2 devuelve un código de retorno, denominado código de
retorno de SQL. El programa debe probar el código de retorno para examinar los
resultados de la operación.
Se aplican instrucciones y detalles exclusivos a cada lenguaje.

“SQL estático” en la página 121
Declaración de definiciones de tablas y vistas

La declaración de definiciones de tablas o vistas es opcional, pero tiene varias
ventajas. Puede declarar una tabla o una vista incluyendo una sentencia SQL
DECLARE en el programa.
Antes de que el programa emita sentencias de SQL que recuperan, actualizan,

suprimen o insertan datos, debe declarar las tablas y vistas a las que accede el
programa. La declaración de tablas o vistas no es necesaria; sin embargo, su

declaración tiene ventajas tales como la documentación de programas de
aplicaciones y el suministro al precompilador de información utilizada para
comprobar las sentencias de SQL incorporado.
| Ejemplo: La sentencia DECLARE TABLE (escrita en COBOL) para la tabla DEPT

| es similar a la siguiente:
| EXEC SQL
| DECLARE DEPT TABLE
| (DEPTNO CHAR(3) NOT NULL,
| DEPTNAME VARCHAR(36) NOT NULL,
| MGRNO CHAR(6) ,
| ADMRDEPT CHAR(3) NOT NULL )
| END-EXEC.
En cada lenguaje tradicional, se delimita una sentencia de SQL en el programa

entre EXEC SQL y un terminador de sentencia. En el ejemplo anterior, EXEC SQL y
END-EXEC delimitan la sentencia de SQL en un programa COBOL.
Como alternativa a codificar la sentencia DECLARE, puede utilizar el

subcomponente DCLGEN, el generador de declaraciones, de DB2.
″DECLARE STATEMENT″ (Consulta de DB2 SQL)
Acceso de datos con variables de lenguaje principal

Puede utilizar variables de lenguaje principal, matrices de variables de lenguaje
principal y estructuras de lenguaje principal en el programa de aplicación para
intercambiar datos entre la aplicación y el DBMS.
Una variable de lenguaje principal es un elemento de datos que se declara en un

programa para utilizar dentro de una sentencia de SQL. Puede hacer lo siguiente:
v Recuperar datos en la variable de lenguaje principal para que los utilice el
programa de aplicación.
v Situar datos en la variable de lenguaje principal para insertarlos en una tabla o
cambiar el contenido de una fila.
v Utilizar los datos de la variable de lenguaje principal cuando se evalúa una
cláusula WHERE o HAVING.
v Asignar el valor de la variable de lenguaje principal a un registro especial. Un
registro especial es un área de almacenamiento que DB2 define para un proceso
para contener información a la que pueden hacer referencia sentencias de SQL.
Ejemplo 1: El registro especial CURRENT SQLID contiene el ID de autorización

de SQL de un proceso, definido en una sentencia de SQL. DB2 sustituye el
nombre de registro por el valor del ID de autorización cuando se ejecuta la
sentencia de SQL.
v Utilizar la variable de lenguaje principal para indicar un valor nulo
El modo de codificar una variable de lenguaje principal varía según el lenguaje de

programación que se utiliza. Algunos lenguajes requieren una sección de
declaración separada para variables de SQL. En este caso, puede codificar las
sentencias BEGIN y END DECLARE SECTION en un programa de aplicación
cuando aparezcan declaraciones de variables de acuerdo con las reglas del lenguaje
principal. Una sección de declaración de variable de lenguaje principal empieza
con la sentencia BEGIN DECLARE SECTION y finaliza con la sentencia END
DECLARE SECTION.

La cláusula INTO de la sentencia SELECT nombre una o más variables de lenguaje
principal para que contengan los valores de columna devueltos. Para variables de
lenguaje principal y matrices de variables de lenguaje principal, las variables
nombradas se corresponden una a una con la lista de nombres de columna de la
lista SELECT.
El ejemplo siguiente utiliza una variable de lenguaje principal para recuperar una
única fila de datos.
Ejemplo 2: Suponga que desea recuperar los valores de columna EMPNO,

LASTNAME y DEPT de una única fila de la tabla EMP. Puede definir una variable
de lenguaje principal en el programa para que contenga cada columna. La variable
de lenguaje principal consta del nombre de variable local, precedido de dos
puntos. A continuación, puede nombrar las áreas de datos con una cláusula INTO,
tal como se muestra:
EXEC SQL
SELECT EMPNO, LASTNAME, DEPT
INTO :CBLEMPNO, :CBLNAME, :CBLDEPT
FROM EMP
END-EXEC.
| Debe declarar las variables de lenguaje principal CBLEMPNO, CBLNAME y

| CBLDEPT en la parte de declaración de datos del programa. Los tipos de datos de
| las variables de lenguaje principal deben ser compatibles con los tipos de datos de
| SQL de las columnas EMPNO, LASTNAME y DEPT de la tabla EMP.
Suponga que no sabe cuántas filas devolverá DB2 o espera que se devuelva más de
una fila. En los dos casos, debe utilizar una alternativa para la sentencia SELECT ...
INTO. Mediante la utilización de un cursor de DB2, una aplicación puede procesar
un conjunto de filas y recuperar filas de la tabla de resultados.
“Recuperación de filas con un cursor” en la página 158
″Variables de lenguaje principal, matrices de variables de lenguaje principal y
estructuras″ (DB2 Application Programming and SQL Guide)
″Referencias a variables de lenguaje principal″ (Consulta de DB2 SQL)
Acceso de datos con matrices de variables de lenguaje

principal
Una matriz de variables de lenguaje principal es una matriz de datos declarada en un
lenguaje principal para utilizarlo en una sentencia de SQL. Puede recuperar datos
en matrices de variables de lenguaje principal para que los utilice el programa de
aplicación y situar datos en matrices de variables de lenguaje principal para
insertar filas en una tabla.
Puede especificar matrices de variables de lenguaje principal en C, C++, COBOL o

PL/I. Cada matriz de variables de lenguaje principal contiene valores para una
columna y cada elemento de la matriz corresponde a un valor para una columna.
Debe declarar la matriz en el programa de lenguaje principal antes de utilizarlo.
Ejemplo: La siguiente sentencia utiliza la principal matriz de variables de lenguaje

principal, COL1, y la correspondiente matriz de indicador, COL1IND. Suponga que
COL1 tiene 10 elementos. El primer elemento de la matriz corresponde al primer
valor, etc. COL1IND debe tener como mínimo 10 entradas.
EXEC SQL
SQL FETCH FIRST ROWSET FROM C1 FOR 5 ROWS
INTO :COL1 :COL1IND
END-EXEC.
Acceso de datos con estructuras de lenguaje principal

Una estructura de lenguaje principal es un grupo de variables de lenguaje principal a
las que puede hacer referencia una sentencia de SQL utilizando un único nombre.
Cuando el entorno de lenguaje de sistema principal lo permite, puede utilizar
sentencias de lenguaje de sistema principal para definir estructuras de lenguaje
principal.
Ejemplo 1: Suponga que el programa COBOL incluye la siguiente sentencia de

SQL:
EXEC SQL
SELECT EMPNO, FIRSTNME, LASTNAME, DEPT
INTO :EMPNO, :FIRSTNME, :LASTNAME, :WORKDEPT
FROM VEMP
END-EXEC.
Ahora suponga que desea evitar el listado de variables de lenguaje principal en el

ejemplo anterior.
Ejemplo 2: Puede sustituir el nombre de una estructura, como :PEMP, que

contiene :EMPNO, :FIRSTNME, :LASTNAME y :DEPT:
EXEC SQL
SELECT EMPNO, FIRSTNME, LASTNAME, WORKDEPT
INTO :PEMP
FROM VEMP
END-EXEC.
Puede declarar una estructura de lenguaje principal en el programa. También

puede utilizar DCLGEN para generar una descripción de registro COBOL, una
declaración de estructura PL/I o una declaración de estructura C que corresponda
a las columnas de una tabla.
Recuperación de filas con un cursor

DB2 dispone de un mecanismo denominado cursor. La utilización de un cursor es
como mantener el dedo en una línea de texto determinada de una página impresa.
En DB2, un programa de aplicación utiliza un cursor para indicar una o más filas
de un conjunto de filas que se recuperan de una tabla. También puede utilizar un
cursor para recuperar filas de un conjunto de resultados que un procedimiento
almacenado devuelve. El programa de aplicación puede utilizar un cursor para
recuperar filas de una tabla.
Puede recuperar y procesar un conjunto de filas que cumpla la condición de

búsqueda de una sentencia de SQL. Cuando utiliza un programa para seleccionar
las filas, el programa procesa una o más filas a la vez.

La sentencia SELECT a la que se hace referencia en este tema debe estar dentro de
una sentencia DECLARE CURSOR y no incluir ninguna cláusula INTO. La
sentencia DECLARE CURSOR define y denomina el cursor, identificando el
conjunto de filas que debe recuperarse con la sentencia SELECT del cursor. Se hace
referencia a este conjunto de filas como la tabla de resultados.
Después de ejecutarse la sentencia DECLARE CURSOR, procese la tabla de

resultados de un cursor del modo como se indica a continuación:
1. Abra el cursor antes de recuperar ninguna fila.
Para indicar a DB2 que está preparado para procesar la primera fila de la tabla
de resultados, haga que el programa emita la sentencia OPEN. A continuación,
DB2 utiliza la sentencia SELECT dentro de una sentencia DECLARE CURSOR
para identificar un conjunto de filas. Si utiliza variables de lenguaje principal
en esta sentencia SELECT, DB2 utiliza el valor actual de las variables para
seleccionar las filas.
2. Utilice una sentencia FETCH para recuperar una o más filas.
La manera más simple de que la sentencia FETCH recupere una única fila de la
tabla de resultados es utilizando un cursor de ubicación de fila. En cualquier
momento dado, un cursor de ubicación de fila recupera como máximo una
única fila de la tabla de resultados en las variables de lenguaje principal. Puede
utilizar una sentencia FETCH para recuperar más de una fila de la tabla de
resultados utilizando un cursor habilitado para procesar conjuntos de filas. Un
conjunto de filas es un conjunto de filas que se recupera mediante una captación
de varias filas.
| Cuando el programa emite una sentencia FETCH de ubicación de fila, DB2
| utiliza el cursor para indicar una fila de la tabla de resultados, conviertiéndola
| en la fila actual. A continuación, DB2 mueve el contenido de la fila actual a las
| variables de lenguaje principal de programa que el usuario ha especificado en
| la cláusula INTO de la sentencia FETCH. La sentencia FETCH mueve el cursor.
| Puede utilizar matrices de variables de lenguaje principal y devolver varias
| filas de datos con una única sentencia FETCH.
3. Cierre el cursor cuando se produzca la condición de fin de los datos.
Si termina de procesar las filas de la tabla de resultados y desea volver a
utilizar el cursor, emita una sentencia CLOSE para cerrar el cursor.
Recomendación: Cierre explícitamente el cursor cuando termine de utilizarlo.
El programa puede tener varios cursores. Cada cursor tiene los siguientes
requisitos:
v Una sentencia DECLARE CURSOR para definir el cursor
v Sentencias OPEN y CLOSE para abrir y cerrar el cursor
v Una sentencia FETCH para recuperar filas de la tabla de resultados del cursor
Debe declarar las variables de lenguaje principal antes de hacer referencia a ellas
en una sentencia DECLARE CURSOR. Para definir e identificar un conjunto de
filas a las que se debe acceder con un cursor, emita una sentencia DECLARE
CURSOR. La sentencia DECLARE CURSOR nombra un cursor y especifica una
sentencia SELECT. La sentencia SELECT define los criterios para las filas que
pertenecen a la tabla de resultados.
Puede utilizar cursores para captar, actualizar o suprimir una o más filas de una
tabla, pero no puede utilizarlos para insertar una fila en una tabla.

Suponga que el programa examina los datos sobre las personas del departamento
D11 y guarda los datos en la tabla EMP. Los ejemplos siguientes muestran las
sentencias de SQL que debe incluir en un programa COBOL para definir y utilizar
un cursor. En estos ejemplos, el programa utiliza el cursor para procesar un
conjunto de filas de la tabla EMP.
Ejemplo: Defina el cursor: La sentencia siguiente define un cursor denominado

THISEMP:
EXEC SQL
DECLARE THISEMP CURSOR FOR
SELECT EMPNO, LASTNAME,
DEPT, JOB
FROM EMP
WHERE DEPT = 'D11'
FOR UPDATE OF JOB
END-EXEC.
Ejemplo: Abra el cursor: La sentencia siguiente abre el cursor:

EXEC SQL
OPEN THISEMP
END-EXEC.
Ejemplo: Utilice el cursor para recuperar una fila: La sentencia siguiente utiliza el
cursor, THISEMP, para recuperar una fila:
EXEC SQL
FETCH THISEMP
INTO :EMP-NUM, :NAME2,
:DEPT, :JOB-NAME
END-EXEC.
Ejemplo: Actualice la fila actual utilizando el cursor: La sentencia siguiente

utiliza el cursor, THISEMP, para actualizar el valor de JOB para empleados
específicos del departamento D11:
EXEC SQL
UPDATE EMP
SET JOB = :NEW-JOB
WHERE CURRENT OF THISEMP
END-EXEC.
Ejemplo: Cierre el cursor: La sentencia siguiente cierra el cursor:

EXEC SQL
CLOSE THISEMP
END-EXEC.
| Si el cursor es sólo de avance, cada captación sitúa el cursor en la siguiente fila o

| conjunto de filas secuenciales. Un cursor con desplazamiento bidireccional puede
| desplazarse hacia adelante y hacia atrás y puede volverse a situar al principio, al
| final o en un punto de desplazamiento relativo. Las aplicaciones pueden utilizar
| un conjunto de sentencias de SQL muy útiles para captar datos utilizando un
| cursor en un orden aleatorio. Los cursores con desplazamiento bidireccional son
| especialmente útiles para aplicaciones basadas en pantallas. Puede especificar que
| los datos de la tabla de resultados deben permanecer estáticos. Por ejemplo, una
| aplicación de contabilidad puede necesitar que los datos permanezcan constantes,
| mientras que una aplicación de sistema de reservas de una línea aérea tiene que
| visualizar la información de disponibilidad de vuelos más reciente.

También puede definir opciones en la sentencia DECLARE CURSOR que
especifiquen hasta qué punto un cursor con desplazamiento bidireccional es
sensible a los cambios en los datos subyacentes cuando se producen inserciones,
actualizaciones o supresiones.
v Un cursor sensible es sensible a los cambios que se realizan en la base de datos
después de generar la tabla de resultados. Por ejemplo, cuando una aplicación
ejecuta sentencias UPDATE y DELETE ubicadas con el cursor, estos cambios se
pueden ver en la tabla de resultados.
v Un cursor insensible no es sensible a las inserciones, actualizaciones o supresiones
que se realizan en las filas subyacentes de una tabla de resultados una vez
creada ésta. Por ejemplo, el orden de las filas y los valores para cada fila de la
tabla de resultados no cambian después de que la aplicación abra el cursor.
Para indicar que un cursor es de desplazamiento bidireccional, declárelo con la

palabra clave SCROLL.
Ejemplo: El ejemplo siguiente muestra una declaración para un cursor con

desplazamiento bidireccional insensible:
EXEC SQL DECLARE C1 INSENSITIVE SCROLL CURSOR FOR
SELECT DEPTNO, DEPTNAME, MGRNO
FROM DEPT
ORDER BY DEPTNO
END-EXEC.
Para utilizar este cursor para capturar la quinta fila de la tabla de resultados,
puede utilizar una sentencia FETCH como la siguiente:
EXEC SQL FETCH ABSOLUTE +5 C1 INTO :HVDEPTNO, :DEPTNAME, :MGRNO;
DB2 for z/OS proporciona otro tipo de cursor denominado cursor con
desplazamiento bidireccional dinámico. Con un cursor con desplazamiento
bidireccional dinámico, las aplicaciones pueden desplazarse directamente en una
tabla base y a la vez acceder a los datos más actuales.
″DECLARE CURSOR″ (Consulta de DB2 SQL)
″FETCH″ (Consulta de DB2 SQL)
Modos de comprobar la ejecución de sentencias de SQL

DB2 proporciona varios modos para comprobar la ejecución de sentencias de SQL
en un programa.
Un programa que incluye sentencias de SQL puede tener un área que se reserva
para la comunicación con DB2—un área de comunicaciones de SQL (SQLCA). Cuando
DB2 procesa una sentencia de SQL en el programa, coloca códigos de retorno en
las variables de lenguaje principal SQLSTATE y SQLCODE o en los
correspondientes campos del SQLCA. Los códigos de retorno indican si la
sentencia se ha ejecutado satisfactoriamente o ha fallado.
Recomendación: Debido a que el SQLCA es una herramienta de diagnóstico de

problemas valiosa, incluya las instrucciones necesarias para visualizar parte de la
información que existe en el SQLCA de los programas de aplicaciones.
| Puede utilizar una sentencia GET DIAGNOSTICS o una sentencia WHENEVER en

| el programa para complementar la comprobación de campos de SQLCA después
| de ejecutar cada sentencia de SQL.

v La sentencia GET DIAGNOSTICS devuelve información de diagnóstico sobre la
última sentencia de SQL que se ha ejecutado. Puede solicitar tipos específicos de
información de diagnóstico o toda la información de diagnóstico disponible
sobre una sentencia. Por ejemplo, la sentencia GET DIAGNOSTICS devuelve el
número de filas afectadas por una inserción, actualización o supresión de datos.
v La sentencia WHENEVER le permite especificar qué debe hacer si una condición
general es verdadera. DB2 comprueba el SQLCA y continúa el proceso del
programa. Si se produce un error, una excepción o un aviso cuando se ejecuta
una sentencia de SQL, DB2 se bifurca a otra área del programa. A continuación,
el programa puede examinar SQLSTATE o SQLCODE para reaccionar de forma
específica al error o a la excepción.
″GET DIAGNOSTICS″ (Consulta de DB2 SQL)
″WHENEVER″ (Consulta de DB2 SQL)
Aplicaciones de SQL dinámico

Con SQL dinámico, DB2 prepara y ejecuta las sentencias de SQL dentro de un
programa mientras el programa se ejecuta. SQL dinámico es una buena opción si
no conoce el formato de una sentencia de SQL antes de escribir o ejecutar un
programa.
“SQL dinámico” en la página 121
Tipos de SQL dinámico

Hay disponibles cuatro tipos de SQL dinámico.
SQL dinámico incorporado
La aplicación coloca la fuente de SQL en variables de lenguaje principal e
incluye sentencias PREPARE y EXECUTE que indican a DB2 que prepare y
ejecute el contenido de dichas variables de lenguaje principal durante el
tiempo de ejecución. Debe precompilar y vincular los programas que
incluyen SQL dinámico incorporado.
SQL interactivo
Un usuario entra sentencias de SQL mediante una herramienta interactiva
como, por ejemplo, DB2 QMF para Windows. DB2 prepara y ejecuta estas
sentencias como sentencias de SQL dinámico.
SQL incorporado diferido
Las sentencias de SQL incorporado diferido no son completamente
estáticas ni completamente dinámicas. Al igual que las sentencias estáticas,
las sentencias de SQL incorporado diferido se incorporan dentro de
aplicaciones; sin embargo, al igual que las sentencias dinámicas, se
preparan durante el tiempo de ejecución. DB2 procesa las sentencias de
SQL incorporado diferido con reglas de tiempo de vinculación. Por
ejemplo, DB2 utiliza el ID de autorización y el calificador (determinados
durante el tiempo de vinculación) como propietario del plan o paquete.
SQL dinámico ejecutado mediante funciones ODBC y JDBC
La aplicación contiene llamadas a funciones ODBC que pasan sentencias de
SQL dinámico como argumentos. No es necesario precompilar y vincular
los programas que utilizan llamadas a funciones ODBC.
El soporte de aplicaciones JDBC le permite escribir aplicaciones de SQL
dinámico en Java.

“SQL dinámico” en la página 121
“Cómo controlan el acceso a datos los ID de autorización” en la página 274
″SQL dinámico″ (DB2 Application Programming and SQL Guide)
Conceptos sobre programación de SQL dinámico

Esta información describe el comportamiento de una aplicación que utiliza SQL
dinámico y proporciona un ejemplo de un programa que incluye SQL dinámico.
Una aplicación que utiliza SQL dinámico genera una sentencia de SQL con formato
de serie de caracteres o acepta una sentencia de SQL como entrada. Según las
necesidades de la aplicación, podría ser capaz de simplificar la programación.
Intente planificar la aplicación para que no utilice sentencias de SELECT o para
que emita únicamente las sentencias que devuelven un número de valores
conocidos de tipos de datos conocidos. En general, los programas dinámicos más
complejos son aquéllos en los que desconoce previamente las sentencias de SQL
que va a emitir la aplicación. Una aplicación normalmente realiza los pasos
siguientes:
1. Convierte los datos de entrada en una sentencia de SQL.
2. Prepara la sentencia de SQL para ejecutarse y adquiere una descripción de la
tabla de resultados (si existe alguna).
3. Obtiene, para sentencias SELECT, suficiente almacenamiento principal para
contener datos recuperados.
4. Ejecuta la sentencia o capta las filas de datos.
5. Procesa la información que se devuelve.
6. Maneja códigos de retorno de SQL.
Ejemplo de SQL dinámico: En este ejemplo se muestra un fragmento de un

programa C que emite dinámicamente sentencias de SQL a DB2. Suponga que está
escribiendo un programa para mantener un inventario de libros. La tabla que
necesita actualizar depende de la entrada para el programa. Este ejemplo muestra
cómo puede crear una sentencia de SQL y, a continuación, llamar a DB2 para
ejecutarla.
/*********************************************************/
/* Determinar qué tabla debe actualizarse y crear la */
/* sentencia de SQL dinámicamente en la variable 'stmt'. */
/*********************************************************/
strcpy(stmt,"UPDATE ");
EXEC SQL SELECT TYPE INTO :book_type FROM BOOK_TYPES WHERE

TITLE=:bktitle;
IF (book_type=='FICTION') strcpy(table_name,"FICTION_BOOKS");
ELSE strcpy(table_name,"NON_FICTION_BOOKS");
strcat(stmt,table_name);
strcat(stmt,
" SET INVENTORY = INVENTORY-1 WHERE TITLE = :bktitle");
/*********************************************************/

/* Aplicar PREPARE y EXECUTE a la sentencia */
/*********************************************************/
EXEC SQL PREPARE OBJSTMT FROM :stmt;
EXEC SQL EXECUTE OBJSTMT;
“Utilización de ODBC para ejecutar SQL dinámico”
″SQL dinámico″ (DB2 Application Programming and SQL Guide)
Utilización de ODBC para ejecutar SQL dinámico

Open Database Connectivity (ODBC) le permite acceder a datos mediante llamadas
de función ODBC en la aplicación. La interfaz ODBC elimina la necesidad de
complicación previa y vinculación de la aplicación y aumenta la portabilidad de la
aplicación.
La interfaz ODBC está específicamente diseñada para que aplicaciones C y C++

accedan a bases de datos relacionales. Las aplicaciones que utilizan la interfaz
ODBC pueden ejecutarse en varios orígenes de datos sin compilarse para cada una
de las bases de datos. ODBC se adapta mejor al entorno de cliente/servidor en el
cual la fuente de datos de destino puede ser desconocida cuando se crea la
aplicación.
Las sentencias de SQL se ejecutan pasándolas a DB2 mediante una llamada de

función ODBC. Las llamadas de función permiten a una aplicación conectarse a la
fuente de datos, emitir sentencias de SQL y recibir datos de retorno e información
de estado.
Puede preparar sentencias de SQL llamando a la función ODBC SQLPrepare(). A

continuación, la sentencia se ejecuta llamando a la función ODBC SQLExecute(). En
ambos casos, la aplicación no contiene ninguna sentencia PREPARE o EXECUTE
incorporada. Puede ejecutar la sentencia, sin preparación, pasando la sentencia a la
función ODBC SQLExecDirect().
Otra ventaja del acceso ODBC es que puede ayudar a ocultar las diferencias entre
catálogos del sistema de servidores de bases de datos diferentes. A diferencia de
SQL incorporado, DB2 ODBC proporciona una interfaz coherente para que las
aplicaciones consulten y recuperen información de catálogo del sistema dentro de
la familia de sistemas de gestión de bases de datos de DB2 Database. Esta
posibilidad reduce la necesidad de escribir consultas de catálogo específicas de
cada servidor de bases de datos. DB2 ODBC puede devolver tablas de resultados a
estos programas.
Ejemplo de ODBC: Este ejemplo muestra una parte de un programa ODBC que
mantiene un inventario de libros.
/*********************************************************/
/* Determinar qué tabla debe actualizarse */
/*********************************************************/
rc = SQLBindParameter( hStmt,
1,
SQL_PARAM_INPUT,
SQL_C_CHAR,
SQL_CHAR,
50,
0,
bktitle,

sizeof(bktitle),
&bktitle_len);
if( rc != SQL_SUCCESS ) goto dberror;
rc = SQLExecDirect( hStmt,
"SELECT TYPE FROM BOOK_TYPES WHERE TITLE=?"
SQL_NTS );
rc = SQLBindCol( hStmt,
1,
SQL_C_CHAR,
book_type,
sizeof(book_type),
&book_type_len);
rc = SQLFetch( hStmt );
rc = SQLCloseCursor( hStmt );
/*********************************************************/
/* Actualizar tabla */
/*********************************************************/
strcpy( (char *)update_sqlstmt, (char *)"UPDATE ");
if( strcmp( (char *)book_type, (char *)"FICTION") == 0)
{
strcat( (char *)update_sqlstmt, (char *)"FICTION_BOOKS" );
}
else
{
strcpy( (char *)update_sqlstmt, (char *)"NON_FICTION_BOOKS" );
}
strcat( (char *)update_sqlstmt,
(char *)" SET INVENTORY = INVENTORY-1 WHERE TITLE = ?");
rc = SQLPrepare( hStmt, update_sqlstmt, SQL_NTS );

rc = SQLExecute( hStmt );
rc = SQLEndTran( SQL_HANDLE_DBC, hDbc, SQL_COMMIT );

“Conceptos sobre programación de SQL dinámico” en la página 163
″Utilización de antememoria de sentencias de SQL dinámico″ (DB2 for z/OS
ODBC Guide and Reference)
Utilización de Java para ejecutar SQL estático y dinámico

DB2 for z/OS da soporte a SQLJ y JDBC. En general, las aplicaciones de Java
utilizan SQLJ para SQL estático y JDBC para SQL dinámico.
Con la utilización del lenguaje de programación Java obtiene las siguientes

ventajas:
v Puede escribir una aplicación en cualquier plataforma habilitada para Java y
ejecutarla en cualquier plataforma que disponga de Java Development Kit (JDK).
v Puede desarrollar una aplicación una vez y ejecutarla en cualquier lugar, lo cual
proporciona las siguientes ventajas potenciales:
– Costes de desarrollo reducidos

– Costes de mantenimiento reducidos
– Costes de gestiones de sistemas reducidos
– Flexibilidad en el soporte de diversas configuraciones de hardware y software
La tabla siguiente muestra algunas de las principales diferencias entre SQLJ y

JDBC.
Tabla 26. Comparación de SQLJ y JDBC
Características de SQLJ Características de JDBC
SQLJ sigue el modelo de SQL estático y JDBC sigue el modelo de SQL dinámico.
proporciona ventajas de rendimiento en
comparación con JDBC.
Los programas fuente SQLJ son más Los programas fuente JDBC son más grandes
pequeños que los programas JDBC que los programas SQLJ equivalentes ya que
equivalentes ya que SQLJ genera SQLJ genera automáticamente un
automáticamente un determinado código que determinado código que el desarrollador
los desarrolladores deben incluir en debe incluir en programas JDBC.
programas JDBC.
SQLJ selecciona tipos de datos durante el JDBC pasa valores hacia y desde tablas de
proceso de preparación de programa e SQL sin seleccionar tipos de datos durante la
impone tipificación estricta entre columnas compilación.
de tabla y expresiones de sistema principal
Java.
En programas SQLJ, se pueden incluir JDBC requiere una sentencia separada para
expresiones de sistema principal Java en cada variable de vinculación y especifica la
sentencias de SQL. vinculación por número de posición.
SQLJ proporciona las ventajas de la selección Debido a que JDBC utiliza SQL dinámico, el
de autorización de SQL estático. En SQLJ, el ID de autorización bajo el que se ejecutan las
ID de autorización bajo el que se ejecutan las sentencias de SQL no se conoce hasta el
sentencias de SQL es el propietario del plan tiempo de ejecución, por lo tanto no se
o paquete. DB2 selecciona los privilegios de puede producir ninguna selección de
tabla durante la vinculación. autorización de privilegios de tabla hasta el
tiempo de ejecución.
Soporte de SQLJ
DB2 for z/OS incluye SQLJ, que proporciona soporte para incluir sentencias de
SQL estático en aplicaciones y servlets de Java. Los servlets son programas de
aplicaciones escritos en Java y que se ejecutan en un servidor web.
Debido a que SQLJ coexiste con JDBC, un programa de aplicación puede crear una
conexión JDBC y, a continuación, utilizar esta conexión para ejecutar sentencias de
SQL dinámico mediante JDBC y sentencias de SQL estático incluidas mediante
SQLJ.
Un grupo de empresas entre las que se incluyen Oracle, Hewlett Packard e IBM,
inicialmente desarrollaron SQLJ para complementar el modelo JDBC de SQL
dinámico con un modelo de SQL estático.
El código SQLJ para actualizar el salario de cualquier empleado es el siguiente:

#sql [myConnCtxt] { UPDATE EMP
SET SALARY = :newSalary
WHERE EMPNO = :empID };
Utilizando SQLJ se beneficia de las ventajas siguientes:

v Aplicaciones portátiles entre plataformas y sistemas de gestión de bases de
datos.
v Tipificación estricta, con comprobación durante la compilación y el tiempo de
vinculación para asegurar que las aplicaciones estén correctamente diseñadas
para la base de datos.
v Mejor rendimiento, manejabilidad y comprobación de autorizaciones de SQL
estático.
v Productividad de programador mejorada y mantenimiento más fácil. En
comparación con una aplicación JDBC, el programa resultante normalmente es
más corto y fácil de comprender.
v Familiaridad para programadores que utilizan SQL incluido en otros lenguajes
de programación tradicionales.
″Programación de aplicaciones SQLJ″ (DB2 for z/OS ODBC Guide and
Reference)
Soporte de JDBC
| DB2 for z/OS da soporte a aplicaciones que utilizan interfaces JDBC de Sun
| Microsystems para acceder a datos de DB2 utilizando SQL dinámico. El soporte de
| DB2 for z/OS para JDBC permite a las organizaciones escribir aplicaciones Java
| que accedan a datos locales de DB2 o a datos relacionales remotos de un servidor
| con soporte de DRDA.
Sun Microsystems ha desarrollado las especificaciones JDBC. Las especificaciones

JDBC definen un conjunto de API (basadas en ODBC) que permite que las
aplicaciones Java accedan a datos relacionales. Las API proporcionan una interfaz
genérica para escribir aplicaciones independientes de la plataforma que puedan
acceder a cualquier base de datos de SQL. Las API están definidas en 16 clases y
dan soporte a funciones básicas de SQL para conectar a una base de datos, ejecutar
sentencias de SQL y procesar resultados. Juntas, estas interfaces y clases
representan las posibilidades de JDBC mediante las cuales una aplicación Java
puede acceder a datos relacionales.
Este ejemplo muestra una parte de un programa JDBC que mantiene un inventario
de libros.
| /*********************************************************/
| /* Determinar qué tabla debe actualizarse y crear la */
| /* sentencia dinámicamente. */
| /*********************************************************/
| String tableName = null;
| Statement stmt = con.createStatement();
|
| ResultSet rs = stmt.executeQuery("SELECT TYPE FROM " +
| " BOOK_TYPES WHERE " +
| " TITLE = \"" + bkTitle + "\"");
| if (rs.next())
| {
| if (rs.getString(1).equalsIgnoreCase("FICTION"))
| tableName = "FICTION_BOOKS";
| else
| tableName = "NON_FICTION_BOOKS";
| /*********************************************************/
| /* Aplicar PREPARE y EXECUTE a la sentencia */

| /*********************************************************/
| stmt.executeUpdate("UPDATE " + tableName + " SET INVENTORY = INVENTORY-1 " +
| "WHERE TITLE = \"" + bkTitle + "\"");
| }
| rs.close();
| stmt.close();
El soporte de DB2 for z/OS para JDBC ofrece varias ventajas para acceder a datos
de DB2:
v JDBC combina la ventaja de ejecutar las aplicaciones en un entorno z/OS con la
portabilidad y facilidad de escribir aplicaciones Java.
v La interfaz JDBC ofrece la posibilidad de cambio entre controladores y de
acceder a varias bases de datos sin registrar el programa Java.
v Las aplicaciones JDBC no requieren precompilaciones ni vinculaciones.
v JDBC proporciona una interfaz coherente para que las aplicaciones consulten y
recuperen información de catálogo del sistema dentro de la familia de sistemas
de gestión de bases de datos de DB2 Database. Esta posibilidad reduce la
necesidad de escribir consultas de catálogo específicas de cada servidor de bases
de datos.
“Conceptos sobre programación de SQL dinámico” en la página 163
″Programación de aplicaciones JDBC″ (DB2 for z/OS ODBC Guide and
Reference)
Utilización de un programa de aplicación como un procedimiento

almacenado
Un procedimiento almacenado es un programa compilado, almacenado en un
servidor local o remoto de DB2, que puede ejecutar sentencias de SQL. Esta
información describe los casos en que debe considerarse la utilización de un
procedimiento almacenado.
Un procedimiento almacenado típico contiene dos o más sentencias de SQL y

proceso de manipulación o lógico en un programa. Un programa de aplicación
cliente utiliza la sentencia CALL de SQL para invocar el procedimiento
almacenado.
Considere la utilización de procedimientos almacenados para una aplicación

cliente/servidor que como mínimo realiza una de las acciones siguientes:
v Ejecuta varias sentencias de SQL remotas.
| Las sentencias de SQL remotas pueden dar como resultado muchas operaciones
| de envío y recepción, lo cual aumenta los costes de procesador y los tiempos
| transcurridos.
Los procedimientos almacenados pueden encapsular muchas de las sentencias
de SQL de la aplicación en un único mensaje hacia el servidor DB2, con lo cual
el tráfico en la red se reduce a una única operación de envío y recepción para
una serie de sentencias de SQL.
Los bloqueos de tablas de DB2 no se mantienen entre transmisiones en la red, lo
cual reduce la contención para los recursos en el servidor.
v Accede a tablas de un entorno de SQL dinámico en el cual no son aconsejables
privilegios de tabla para la aplicación que se ejecuta.

Los procedimientos almacenados permiten autorización de SQL estático desde
un entorno dinámico.
v Accede a variables de lenguaje principal a las que desea garantizar seguridad e
integridad.
Los procedimientos almacenados eliminan aplicaciones de SQL de la estación de
trabajo, con lo cual se evita que los usuarios de estación de trabajo deban
manipular el contenido de sentencias de SQL y variables de lenguaje principal
sensibles.
v Crea un conjunto de resultados de filas para devolverlo a la aplicación cliente.
″Procedimientos almacenados″ (DB2 Application Programming and SQL Guide)
″Procedimientos almacenados″ (Consulta de DB2 SQL)
″Implementación de procedimientos almacenados de DB2″ (DB2 Administration
Guide)
Lenguajes utilizados para crear procedimientos almacenados

Los procedimientos almacenados se pueden escribir en distintos lenguajes de
programación que van desde los lenguajes de programación orientados a objetos
hasta los lenguajes de programación tradicionales.
Puede escribir procedimientos almacenados en los siguientes lenguajes de

programación:
Java Si tiene más experiencia en escribir aplicaciones en un entorno de
programación orientado a objetos, posiblemente deseará crear
procedimientos almacenados utilizando Java
Lenguaje de procedimiento de SQL
Si la aplicación está formada completamente por sentencias de SQL, lógica
de flujo de control simple y ninguna lógica de aplicación compleja, puede
optar por crear los procedimientos almacenados utilizando el lenguaje de
procedimiento de SQL.
REXX Puede crear procedimientos almacenados utilizando programas REXX que
pueden contener SQL dinámico. Los DBA y programadores generalmente
utilizan REXX para tareas administrativas.
Lenguajes de programación tradicionales: C, C++, COBOL, PL/I y Assembler
Todos los programas de lenguajes tradicionales deben diseñarse para
ejecutarse utilizando Language Environment. Los procedimientos
almacenados COBOL y C++ pueden contener ampliaciones orientadas a
objetos.
El programa que llama al procedimiento almacenado puede estar en cualquier

lenguaje que dé soporte a la sentencia SQL CALL. Las aplicaciones ODBC y JDBC
pueden utilizar una cláusula de escape para pasar una llamada de procedimiento
almacenado a DB2.
“Utilización del lenguaje de procedimiento de SQL para crear un procedimiento

Proceso de procedimientos almacenados
Esta información explica cómo funciona el proceso de un procedimiento
almacenado, proporciona ejemplos de procedimientos almacenados y muestra
cómo ejecutar procedimientos almacenados.
La figura siguiente ilustra un proceso sin procedimientos almacenados.
Figura 31. Proceso sin procedimientos almacenados. Una aplicación incluye sentencias de
SQL y se comunica con el servidor de forma separada para cada sentencia.
La figura siguiente ilustra un proceso con procedimientos almacenados.

Notas de la figura:
v La aplicación de estación de trabajo utiliza la sentencia de SQL CONNECT para crear una
conversación con DB2.
v DB2 crea una hebra de DB2 para procesar peticiones de SQL. Una hebra es la estructura
de DB2 que describe la conexión de una aplicación y rastrea el progreso de la aplicación.
v La sentencia de SQL CALL indica al servidor de DB2 que la aplicación va a ejecutar un
procedimiento almacenado. La aplicación que realiza la llamada proporciona los
argumentos necesarios.
v DB2 procesa información sobre la petición y carga el programa de procedimiento
almacenado.
v El procedimiento almacenado ejecuta sentencias de SQL.
Una de las sentencias de SQL abre un cursor que se ha declarado como WITH RETURN.
Esto hace que se devuelva un conjunto de resultados a la aplicación de estación de
trabajo.
v El procedimiento almacenado asigna valores a los parámetros de salida y sale. Se
devuelve el control a la región de procedimientos almacenados de DB2 y desde allí pasa
al subsistema DB2.
| v Se devuelve el control a la aplicación que realiza la llamada, la cual recibe los parámetros
| de salida y el conjunto de resultados.
| La aplicación puede llamar a otros procedimientos almacenados o puede ejecutar
| sentencias de SQL adicionales. DB2 recibe y procesa la petición COMMIT o ROLLBACK.
| La operación de confirmación o de retrotracción incluye todas las operaciones de SQL que
| la aplicación o el aplicación ejecuta durante la unidad de trabajo.
| Si la aplicación incluye IMS o CICS, se produce un proceso similar. Este proceso se basa
| en el modelo de sincronización de IMS o CICS, en lugar de una sentencia de SQL
| COMMIT o ROLLBACK.
Figura 32. Proceso con procedimientos almacenados. La misma serie de sentencias de SQL
utiliza una única operación de envío o recepción.

Guide)
Utilización del lenguaje de procedimiento de SQL para crear

un procedimiento almacenado
Con lenguaje de procedimiento de SQL puede escribir procedimientos almacenados
formados totalmente por sentencias de SQL.
Un procedimiento de SQL puede incluir declaraciones de variables, condiciones,

cursores y manejadores. El procedimiento de SQL también puede incluir control de
flujo, sentencias de asignación y SQL tradicional para definir y manipular datos
relacionales. Estas ampliaciones proporcionan un lenguaje de procedimiento para
escribir procedimientos almacenados y son coherentes con la parte de Módulos
almacenados permanentes del estándar de SQL.
Ejemplo: Este ejemplo muestra un procedimiento almacenado de SQL simple (la

sintaxis para la sentencia CREATE PROCEDURE sólo muestra una parte de las
cláusulas de la sentencia):
CREATE PROCEDURE ITERATOR() LANGUAGE SQL
BEGIN
..
DECLARE not_found CONDITION FOR SQLSTATE '02000';
DECLARE c1 CURSOR FOR ....;
DECLARE CONTINUE HANDLER FOR not_found (2)
SET at_end = 1;
OPEN c1;
ftch_loop1: LOOP
FETCH c1 INTO v_dept, v_deptname, v_admdept; (1)
IF at_end = 1 THEN
LEAVE ftch_loop1; (3)
ELSEIF v_dept = 'D01' THEN
INSERT INTO department (deptno, deptname, admrdept)
VALUES ( 'NEW', v_deptname, v_admdept);
END IF;
END LOOP;
CLOSE c1;
END
En este ejemplo:
v El proceso pasa por ftch_loop1, suponiendo que se encuentra una fila.
v La primera vez que FETCH no encuentra una fila, el proceso pasa a HANDLER
(1).
v HANDLER establece el distintivo at_end. Debido a que el procedimiento utiliza
CONTINUE HANDLER, el proceso continúa en el siguiente paso después de
FETCH (2).
v El proceso continúa con la sentencia de SQL CLOSE (3).

Guide)
Utilización de DB2 Developer Workbench para crear un

procedimiento almacenado
DB2 Developer Workbench ayuda a los desarrolladores de aplicaciones a crear
procedimientos almacenados en el lenguaje de programación Java y en el lenguaje
de procedimiento de SQL. Estos procedimientos almacenados son trasladables en
toda la familia de servidores de DB2, incluyendo DB2 for z/OS, DB2 para iSeries y
DB2 Database para Linux, UNIX y Windows.
Introducido en la Versión 8 de DB2 for z/OS, DB2 Developer Workbench amplía

las posibilidades de su predecesor, DB2 Stored Procedure Builder.
Sin DB2 Developer Workbench, el proceso de instalación de un procedimiento

almacenado en un servidor, local o remota, requiere pasos manuales en los que
puede haber errores. Por el contrario, DB2 Developer Workbench genera, con una
simple pulsación en el icono Build (Crear), los pasos para el sistema operativo
necesario.
Cuando se configura un subsistema DB2 para la creación de procedimientos

almacenados de SQL y Java, los desarrolladores de aplicaciones pueden crear,
instalar y probar fácilmente procedimientos almacenados para DB2 for z/OS
utilizando DB2 Developer Workbench. DB2 Developer Workbench también
proporciona pasos similares para crear e instalar procedimientos almacenados de
Java de DB2 en sistemas operativos distribuidos.
Mediante un conjunto totalmente integrado de Development Add-Ins for Microsoft

Visual Studio 6.0 (para Visual Basic, Visual C ++ , Visual InterDev y Visual
Studio.NET), DB2 Developer Workbench también da soporte a un rápido desarrollo
interactivo de procedimientos almacenados del servidor y la generación e
integración de código ADO de cliente con Visual Source Safe.
Además del desarrollo de procedimientos almacenados, DB2 Developer Workbench

da soporte a acceso de sólo lectura para funciones definidas por el usuario,
desencadenantes, tablas y vistas.
Configuración del entorno de procedimientos almacenados

La configuración del entorno de procedimientos almacenados incluye el
establecimiento del entorno de procedimientos almacenados y la definición del
procedimiento almacenado en DB2. Normalmente, un administrador del sistema
personaliza el entorno y un programador de aplicaciones define el procedimiento
almacenado.
Para poder ejecutar un procedimiento almacenado antes debe definirlo en DB2.

Utilice la sentencia de SQL CREATE PROCEDURE para definir un procedimiento
almacenado en DB2. Para modificar la definición, utilice la sentencia ALTER
PROCEDURE.
Tareas relacionadas
″Configuración del entorno de procedimientos almacenados″ (DB2 Application
Programming and SQL Guide)

Preparación de un procedimiento almacenado
Esta información describe lo que debe considerar antes de utilizar un
procedimiento almacenado.
Un procedimiento almacenado puede estar formado por más de un programa,

cada uno de ellos con su propio paquete. El procedimiento almacenado puede
llamar a otros programas, procedimientos almacenados o funciones definidas por
el usuario. Utilice los recursos del lenguaje de programación para llamar a otros
programas.
Si el procedimiento almacenado llama a otros programas que contienen sentencias

de SQL, cada uno de los programas llamados deben tener un paquete de DB2. El
propietario del paquete o plan que contiene la sentencia CALL debe tener la
autorización EXECUTE para todos los paquetes que los otros programas utilizan.
Cuando un procedimiento almacenado llama a otro programa, DB2 determina la

colección a la que pertenece el paquete del programa llamado.
″Creación de un procedimiento almacenado″ (DB2 Application Programming
and SQL Guide)
Cómo pueden llamar las aplicaciones a procedimientos

almacenados
La sentencia CALL de SQL se utiliza para llamar a un procedimiento almacenado y
pasar una lista de argumentos al procedimiento.
Un programa de aplicación puede llamar a un procedimiento almacenado de las

siguientes formas:
v Ejecute la sentencia CALL localmente o envíe la sentencia CALL a un servidor.
La aplicación ejecuta una sentencia CONNECT para conectarse al servidor. A
continuación, la aplicación ejecuta la sentencia CALL o emite un nombre en tres
partes para identificarse y conectarse implícitamente al servidor donde se
encuentra el procedimiento almacenado.
v Después de conectarse a un servidor, combine sentencias CALL con otras
sentencias de SQL. Para ejecutar la sentencia CALL, puede ejecutar la sentencia
CALL de forma estática o utilizar una cláusula de escape en una aplicación
ODBC o JDBC para pasar la sentencia CALL a DB2.
La ejecución de un procedimiento almacenado implica dos tipos de autorización:

v Autorización para ejecutar el procedimiento almacenado
v Autorización para ejecutar el paquete de procedimientos almacenados y
cualquier paquete que esté bajo el paquete de procedimientos almacenados
Si el propietario del procedimiento almacenado tiene autoridad para ejecutar los

paquetes, la persona que ejecuta los paquetes no necesita la autoridad.
Las autorizaciones necesarias dependen de si el nombre del procedimiento

almacenado se especifica explícitamente en la sentencia CALL o si está contenido
en una variable de lenguaje principal.

Si el procedimiento almacenado invoca funciones definidas por el usuario o
desencadenantes, necesita autorizaciones adicionales para ejecutar la función
definida por el usuario, el desencadenante y los paquetes de funciones definidas
por el usuario.
″Ejemplo de un procedimiento almacenado simple″ (DB2 Application
Programming and SQL Guide)

Capítulo 7. Implementación del diseño de base de datos
Después de crear un diseño lógico y un diseño físico de la base de datos relacional
y recopilar los requisitos de proceso, puede pasar a la fase de implementación. En
general, la implementación del diseño físico implica la definición de varios objetos
y la aplicación de restricciones a las relaciones de datos.
Los objetos de una base de datos relacional se organizan en conjuntos

denominados esquemas. Un esquema proporciona una clasificación lógica de objetos
de la base de datos. El nombre de esquema se utiliza como calificador de objetos
de SQL como, por ejemplo, tablas, vistas, índices y desencadenantes.
Esta información explica la tarea de implementar el diseño de base de datos de

forma que puedan comprenderla la mayoría de usuarios nuevos. Cuando realice
realmente la tarea, puede seguir los pasos en un orden diferente.
Puede definir, o crear, objetos ejecutando sentencias de SQL. Esta información

resume algunos de los convenios de denominación para los diversos objetos que
puede crear. Además en esta información, verá ejemplos de sentencias y palabras
clave de SQL básico que puede utilizar para crear objetos en una base de datos de
DB2. (Esta información no documenta la sintaxis de SQL completa.)
| Consejo: Al crear objetos de DB2 (como tablas, espacios de tablas, vistas e índices),
| puede anteponer un calificador al nombre de objeto para distinguirlo de los objetos
| que crean otras personas. (Por ejemplo, MYDB.TSPACE1 es un espacio de tablas
| diferente de YOURDB.TSPACE1.) Cuando utilice un calificador, evite utilizar SYS
| como los tres primeros caracteres. Si no especifica ningún calificador, DB2 asigna
| un calificador para el objeto.
Capítulo 4, “Objetos de DB2 y sus relaciones”, en la página 67
Creación de tablas
Diseño de tablas utilizadas por muchas aplicaciones es una tarea crítica. El diseño
de tablas puede ser difícil ya que la misma información se puede representar de
muchas formas diferentes. Esta información resume brevemente cómo crear y
modificar tablas, y cómo controlar la autorización.
Para crear tablas debe utilizar la sentencia SQL CREATE TABLE. Después de haber
creado y empezado a utilizar las tablas, es posible que en algún momento deba
realizar cambios en ellas. La sentencia ALTER TABLE le permite añadir y cambiar
columnas, añadir o eliminar una clave primaria o una clave foránea, añadir o
eliminar restricciones de comprobación de tabla o añadir y cambiar particiones.
Considere los cambios de diseño con atención para evitar o reducir el impacto en
las aplicaciones.
Si tiene la autorización DBADM (administración de bases de datos), probablemente

deseará controlar la creación de bases de datos y espacios de tablas de DB2. Estos
objetos pueden tener un impacto grande en el rendimiento, el almacenamiento y la
seguridad de toda la base de datos relacional. En algunos casos, también puede
que desee conservar la responsabilidad de la creación de tablas. Después de
diseñar la base de datos relacional, puede crear las tablas necesarias para los

programas de aplicaciones. A continuación, puede pasar la autorización para que la
utilicen los desarrolladores de aplicaciones, directa o indirectamente, mediante el
uso de vistas.
Sin embargo, si lo desea, puede otorgar la autorización para crear tablas a los
responsables de la implementación de la aplicación. Por ejemplo, probablemente
deseará autorizar determinados programadores de aplicaciones para crear tablas si
necesitan tablas temporales con finalidades de prueba.
Puede que algunos usuarios de la organización deseen utilizar DB2 con la mínima
asistencia o el mínimo control. Puede definir un grupo de almacenamiento y una
base de datos separados para estos usuarios y autorizarlos para crearlos objetos de
datos que necesiten como, por ejemplo, tablas.
Capítulo 4, “Objetos de DB2 y sus relaciones”, en la página 67
273
Tipos de tablas
En DB2, los datos del usuario se almacenan en tablas. DB2 da soporte a varios
tipos de tablas, cada uno de los cuales tiene sus propias finalidades y
características.
DB2 da soporte a los siguientes tipos de tablas:

tabla base
El tipo más común de tabla en DB2. Para crear una tabla base utilice la
sentencia de SQL CREATE TABLE. La tabla de catálogo de DB2,
SYSIBM.SYSTABLES, almacena la descripción de la tabla base. La tabla es
permanente (tanto su descripción como sus datos). Todos los programas y
usuarios que hacen referencia a este tipo de tabla, hacen referencia a la
misma descripción de la tabla y a la misma instancia de la tabla.
tabla de resultados
Tabla que contiene un conjunto de filas que DB2 selecciona o genera,
directa o indirectamente, desde una o más tablas base en respuesta a una
sentencia de SQL. A diferencia de una tabla base o una tabla temporal, una
tabla de resultados no es un objeto que se define utilizando una sentencia
CREATE.
tabla temporal
| Tabla que se define mediante la sentencia de SQL CREATE GLOBAL
| TEMPORARY TABLE o DECLARE GLOBAL TEMPORARY TABLE para
| contener datos temporalmente. Las tablas temporales son especialmente
| útiles cuando se necesita clasificar o consultar tablas de resultados
| intermedios que contienen un número elevado de filas, pero tan solo se
| desea almacenar de forma permanente un subconjunto reducido de estas
| filas.
| tabla temporal global creada
| Tabla que se define con la sentencia de SQL CREATE GLOBAL
| TEMPORARY TABLE. La tabla de catálogo DB2,
| SYSIBM.SYSTABLES, almacena la descripción de la tabla temporal
| creada. La descripción de la tabla es permanente y compartible. Sin
| embargo, cada proceso de aplicaciones individual que hace
| referencia a una tabla temporal creada tiene una instancia diferente

| de la tabla. Es decir, si el proceso de aplicaciones A y el proceso de
| aplicaciones B utilizan una tabla temporal creada llamada
| TEMPTAB:
| v Cada proceso de aplicaciones utiliza la misma descripción de
| tabla.
| v Ningún proceso de aplicaciones tiene acceso ni conocimiento de
| las filas de la instancia de TEMPTAB del otro.
| tabla temporal global declarada
| Tabla que se define con la sentencia de SQL DECLARE GLOBAL
| TEMPORARY TABLE. El catálogo de DB2 no almacena una
| descripción de la tabla temporal declarada. Por lo tanto, ni la
| descripción ni la instancia de la tabla es permanente. Varios
| procesos de aplicaciones pueden hacer referencia a la misma tabla
| temporal declarada por nombre, pero en realidad no comparten la
| misma descripción o instancia de la tabla. Por ejemplo,
| supongamos que el proceso de aplicaciones A define una tabla
| temporal declarada denominada TEMP1 con 15 columnas. El
| proceso de aplicaciones B define una tabla temporal declarada
| denominada TEMP1 con 5 columnas. Cada proceso de aplicaciones
| utiliza su propia descripción de TEMP1; ningún proceso de
| aplicaciones tiene acceso ni conocimiento de las filas de la instancia
| de TEMP1 de las otras aplicaciones.
tabla de consultas materializadas
Tabla, definida con la sentencia de SQL CREATE TABLE, que contiene
datos materializados que proceden de una o más tablas fuente. Las tablas
de consultas materializadas son útiles para consultas complejas que se
ejecutan en cantidades muy grandes de datos. DB2 puede calcular
previamente todas estas consultas, o parte de ellas, y utilizar los resultados
previamente calculados, o materializados, para responder a las preguntas
de una forma más eficaz. Las tablas de consultas materializadas se utilizan
con frecuencia en aplicaciones de depósito de datos e inteligencia
empresarial.
Varias tablas de catálogo de DB2, que incluyen SYSIBM.SYSTABLES y
SYSIBM.SYSVIEWS, almacenan la descripción de la tabla de consultas
materializadas e información sobre su dependencia de una tabla, vista o
función. Los atributos que definen una tabla de consultas materializadas
indican a DB2 si la tabla:
v Está mantenida por el sistema o mantenida por el usuario.
v Es renovable: todas las tablas materializadas se pueden actualizar con la
sentencia REFRESH TABLE. Sólo las tablas de consultas materializadas
mantenidas por el usuario también se pueden actualizar con el programa
de utilidad LOAD y las sentencias de SQL UPDATE, INSERT y DELETE,
v Está habilitada para optimización de consultas: se puede habilitar o
inhabilitar la utilización de una tabla de consultas materializadas en la
reescritura automática de consultas.
tabla auxiliar
| Tipo de tabla especial que contiene datos de objetos grandes y datos XML.
| tabla de clonación
| Tabla estructuralmente idéntica a una tabla base. Para crear una tabla de
| clonación utilice una sentencia ALTER TABLE para la tabla base que
| incluya una cláusula ADD CLONE. La tabla de clonación se crea en una
| instancia diferente del mismo espacio de tablas que la tabla base, es
Capítulo 7. Implementación del diseño de base de datos 179

| estructuralmente idéntica a la tabla base en todos los aspectos y tiene los
| mismos índices, desencadenantes BEFORE y objetos LOB. En el catálogo de
| DB2, la tabla SYSTABLESPACE indica que el espacio de tablas tan solo
| contiene una tabla, pero SYSTABLESPACE.CLONE indica que existe una
| tabla de clonación. Las tablas de clonación sólo se pueden crear en un
| espacio de tablas particionado por rango o de partición por crecimiento
| que esté gestionado por DB2. La tabla base y la tabla de clonación tienen
| conjuntos de datos VSAM subyacentes distintos (identificados por sus
| números de instancia de conjunto de datos) que contienen filas de datos
| independientes.
| tabla XML
| Tipo de tabla especial que contiene únicamente datos XML.
Estos tipos de tablas diferentes se diferencian en otros aspectos que no se describen

en este tema.
“Creación de tablas de consultas materializadas” en la página 182
“Creación de objetos grandes” en la página 233
“Tablas de ejemplo de DB2” en la página 124
Creación de tablas base

Utilice la sentencia CREATE TABLE para crear una tabla base que haya designado.
Cuando crea una tabla, DB2 registra una definición de la tabla en el catálogo de
DB2. La creación de una tabla no almacena los datos de aplicaciones. Puede
colocar datos en la tabla utilizando varios métodos como, por ejemplo, el programa
de utilidad LOAD o la sentencia INSERT.
Ejemplo: La siguiente sentencia CREATE TABLE crea la tabla EMP, que está en
una base de datos denominada MYDB y en un espacio de tablas denominado
MYTS:
CREATE TABLE EMP
FIRSTNME VARCHAR(12) NOT NULL,
LASTNAME VARCHAR(15) NOT NULL,
DEPT CHAR(3) ,
HIREDATE DATE ,
JOB CHAR(8) ,
EDL SMALLINT ,
SALARY DECIMAL(9,2) ,
COMM DECIMAL(9,2) ,
PRIMARY KEY (EMPNO))
IN MYDB.MYTS;
La sentencia CREATE TABLE previa muestra la definición de varias columnas.

“Definición de columnas de una tabla” en la página 183
″CREATE TABLE″ (Consulta de DB2 SQL)
Creación de tablas temporales

Las tablas temporales son útiles cuando necesita clasificar o consultar tablas de
resultados intermedios que contienen un número elevado de filas e identificar un

subconjunto reducido de filas para que se almacene de forma permanente. Los dos
tipos de tablas temporales son tablas temporales creadas y tablas temporales
declaradas.
Puede utilizar tablas temporales para clasificar volúmenes grandes de datos y

consultar estos datos. A continuación, después de identificar el número reducido
de filas que desea almacenar de forma permanente, puede almacenarlas en una
tabla base. Los dos tipos de tablas temporales de DB2 son la tabla temporal creada
y la tabla temporal declarada. Los temas siguientes describen cómo definir cada
tipo.
Tabla temporal creada
Algunas veces necesita una descripción compartible y permanente de una tabla

pero necesita almacenar datos únicamente mientras dura un proceso de
aplicaciones. En este caso, puede definir y utilizar una tabla temporal creada. DB2
no registra las operaciones que realiza en tablas temporales creadas; por lo tanto,
las sentencias de SQL que las utilizan pueden ejecutarse más eficazmente. Cada
proceso de aplicaciones tiene su propia instancia de la tabla temporal creada.
Ejemplo: La sentencia siguiente define una tabla temporal creada, TEMPPROD:

CREATE GLOBAL TEMPORARY TABLE TEMPPROD
(SERIALNO CHAR(8) NOT NULL,
DESCRIPTION VARCHAR(60) NOT NULL,
MFGCOSTAMT DECIMAL(8,2) ,
MFGDEPTNO CHAR(3) ,
MARKUPPCT SMALLINT ,
SALESDEPTNO CHAR(3) ,
CURDATE DATE NOT NULL);
Tabla temporal declarada
Algunas veces necesita almacenar datos mientras dura un proceso de aplicaciones,

pero no necesita una descripción compartible y permanente de la tabla. En este
caso, puede definir y utilizar una tabla temporal declarada.
A diferencia de otras sentencias DB2 DECLARE, DECLARE GLOBAL

TEMPORARY TABLE es una sentencia ejecutable que se puede incluir en un
programa de aplicación o emitir de forma interactiva. También puede preparar la
sentencia de forma dinámica.
Cuando un programa de un proceso de aplicaciones emite una sentencia

DECLARE GLOBAL TEMPORARY TABLE DB2 crea una instancia vacía de la
tabla. Puede llenar la tabla temporal declarada utilizando sentencias INSERT,
modificar la tabla utilizando sentencias UPDATE o DELETE buscadas o situadas y
consultar la tabla utilizando sentencias SELECT. También puede crear índices en la
tabla temporal declarada. La definición de la tabla temporal declarada existe
mientras se ejecuta el proceso de aplicaciones.
| Ejemplo: La sentencia siguiente define una tabla temporal declarada, TEMP_EMP.

| (En este ejemplo se supone que ya ha creado la base de datos WORKFILE y el
| espacio de tablas correspondiente para la tabla temporal.)
| DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_EMP
| (EMPNO CHAR(6) NOT NULL,
| SALARY DECIMAL(9, 2) ,
| COMM DECIMAL(9, 2));

| Si se especifica explícitamente, el calificador para el nombre de una tabla temporal
| declarada debe ser SESSION. Si no se especifica el calificador, se define
| implícitamente para que sea SESSION.
Al final de un proceso de aplicaciones que utiliza una tabla temporal declarada,

DB2 suprime las filas de la tabla e implícitamente elimina la descripción de la
tabla.
″Tablas temporales″ (DB2 Application Programming and SQL Guide)
″DECLARE GLOBAL TEMPORARY TABLE″ (Consulta de DB2 SQL)
″CREATE GLOBAL TEMPORARY TABLE″ (Consulta de DB2 SQL)
Creación de tablas de consultas materializadas

Las tablas de consultas materializadas mejoran el rendimiento de las consultas
complejas que operan en cantidades muy grandes de datos. Esta información
explica cómo se utiliza y se crea una tabla de consultas materializadas.
Mediante el uso de una tabla de consultas materializadas, DB2 calcula por

adelantado los resultados de los datos que derivan de una o más tablas. Al
someter una consulta, DB2 puede utilizar los resultados que se almacenan en una
tabla de consultas materializadas en lugar de calcular los resultados a partir de las
tablas fuente subyacentes sobre las que se define la tabla de consultas
materializadas. Si la consulta reescrita es menos costosa, DB2 elige optimizar la
consulta utilizando la consulta reescrita, un proceso que se denomina reescritura
automática de consulta.
Para beneficiarse de la reescritura automática de consulta, debe definir, llenar y

renovar periódicamente la tabla de consultas materializadas. Utilice la sentencia
CREATE TABLE para crear una tabla nueva como una tabla de consultas
materializadas.
Ejemplo: La sentencia CREATE TABLE siguiente define una tabla de consultas

materializadas denominada TRANSCNT. TRANSCNT resume el número de
transacciones de la tabla TRANS por cuenta, ubicación y año:
CREATE TABLE TRANSCNT (ACCTID, LOCID, YEAR, CNT) AS
(SELECT ACCOUNTID, LOCATIONID, YEAR, COUNT(*)
FROM TRANS
GROUP BY ACCCOUNTID, LOCATIONID, YEAR )
DATA INITIALLY DEFERRED
REFRESH DEFERRED
MAINTAINED BY SYSTEM
ENABLE QUERY OPTIMIZATION;
La selección completa, junto con la cláusula DATA INITIALLY DEFERRED y la

cláusula REFRESH DEFERRED, define la tabla como una tabla de consultas
materializadas.
″Creación de tablas de consultas materializadas″ (DB2 Administration Guide)

Creación de una tabla con particionamiento controlado por
tabla
El particionamiento controlado por tabla no necesita ningún índice para el
particionamiento y se define mediante cláusulas PARTITION en la sentencia
CREATE TABLE.
| Cuando defina un índice de particionamiento en una tabla de un espacio de tablas

| particionado, especifique los valores de clave de particionamiento y de clave límite
| en la cláusula PARTITION de la sentencia CREATE INDEX. Este tipo de
| particionamiento recibe el nombre de particionamiento . Debido a que el índice se
| crea separadamente de la tabla asociada, no puede insertar datos en la tabla hasta
| que se haya creado el índice de particionamiento.
| DB2 también da soporte a un método denominado particionamiento controlado por

| tabla para definir particiones de tabla. Puede utilizar el particionamiento controlado
| por tabla en lugar del particionamiento controlado por índice.
En el particionamiento controlado por tabla, identifique los valores de columna

que delimitan los límites de partición con la cláusula PARTITION BY y la cláusula
PARTITION ENDING AT de la sentencia CREATE TABLE. Cuando utilice este tipo
de particionamiento, no se necesita ningún índice para el particionamiento.
Ejemplo: Suponga que necesita crear una tabla de transacciones grande que
incluya la fecha de la transacción en una columna denominada POSTED. Suponga
que desea mantener las transacciones para cada mes en una partición separada.
Para crear la tabla, utilice la sentencia siguiente:
CREATE TABLE TRANS
(ACCTID ...,
STATE ...,
POSTED ...,
... , ...)
PARTITION BY (POSTED)
(PARTITION 1 ENDING AT ('01/31/2003'),
PARTITION 2 ENDING AT ('02/28/2003'),
...
PARTITION 13 ENDING AT ('01/31/2004'));
“Índices de particionamiento” en la página 226
Definición de columnas de una tabla

Una definición de columna tiene dos componentes básicos, el nombre de columna
y el tipo de datos. Esta información describe lo que debe considerarse al definir
columnas.
Los dos componentes básicos de la definición de columna son el nombre y el tipo

de datos. Una columna contiene valores que tienen el mismo tipo de datos. Si está
familiarizado con los conceptos de registros y campos, puede pensar en un valor
como un campo de un registro. Un valor es la unidad más pequeña de datos que
se puede manipular con SQL. Por ejemplo, en la tabla EMP, la columna EMPNO
identifica a todos los empleados mediante un número de empleado exclusivo. La
columna HIREDATE contiene las fechas de contratación de todos los empleados.
No se pueden solapar columnas.
Las mejoras de los esquemas en línea proporcionan una flexibilidad que le permite
cambiar una definición de columna. Considere con atención las decisiones que

tome sobre definiciones de columnas. Una vez implantado el diseño de las tablas,
puede cambiar una definición de columna con la mínima interrupción en las
aplicaciones.
Durante la fase de implementación del diseño de base de datos, consulte las

descripciones completas de la sintaxis de las sentencias de SQL y la utilización de
cada sentencia de SQL con la que trabaje.
Nombres de columna
Las siguientes directrices de denominación de columnas que se desarrollan para la
organización aseguran la elección de opciones correctas que sean coherentes.
Generalmente, el administrador de base de datos (DBA) participa en la

determinación de los nombres de atributos (o columnas) durante la fase del diseño
físico de la base de datos. Para realizar las elecciones correctas para los nombres de
columna, los DBA siguen las directrices que los administradores de los datos de la
organización han desarrollado.
Algunas columnas deben añadirse a la base de datos una vez completado el

diseño. En este caso, deben seguirse las reglas de DB2 para nombres de columna
exclusivos. Los nombres de columna deben ser exclusivos dentro de una tabla,
pero se puede utilizar el mismo nombre de columna en diferentes tablas. Intente
elegir un nombre significativo para describir los datos de una columna para que el
esquema de denominación sea intuitivo. La longitud máxima de un nombre de
columna es de 30 bytes.
Tipos de datos
Cada columna de cada tabla de DB2 tiene un tipo de datos. El tipo de datos
influye en el intervalo de valores que puede tener la columna y en el conjunto de
operadores y funciones que se le aplican.
El tipo de datos de cada columna se especifica cuando crea la tabla. También

puede cambiar el tipo de datos de una columna de tabla. La nueva definición de
tipo de datos se aplica a todos los datos de la tabla asociada cuando se reorganiza
la tabla.
Algunos tipos de datos tienen parámetros que definen adicionalmente los

operadores y funciones que se aplican a la columna. DB2 da soporte a tipos de
datos proporcionados por IBM y a tipos de datos definidos por el usuario. Los
tipos de datos proporcionados por IBM a veces se denominan tipos de datos
incorporados.
En DB2 for z/OS, los tipos de datos definidos por el usuario se denominan tipos
diferenciados.
“Tipos de datos para atributos” en la página 73
“Tipos diferenciados” en la página 191
Tipos de datos de serie

DB2 da soporte a varios tipos de datos de serie: series de caracteres, series gráficas
y series binarias.
| Las series de caracteres contienen texto y pueden ser de longitud fija o de longitud
| variable. Las series gráficas contienen datos gráficos, que pueden ser de longitud fija

| o de longitud variable. Las series binarias contienen series de bytes binarios y
| pueden ser de longitud fija o de longitud variable. Todos estos tipos de datos de
| serie se pueden representar como objetos grandes.
La tabla siguiente describe los diferentes tipos de datos de serie e indica el rango
para la longitud de cada tipo de datos de serie.
| Tabla 27. Tipos de datos de serie
| Tipo de datos Indica una columna de...
| CHARACTER(n) Series de caracteres de longitud fija con una longitud de n bytes. n
| debe ser mayor que 0 y no mayor que 255. La longitud por omisión
| es 1.
| VARCHAR(n) Series de caracteres de longitud variable con una longitud máxima
| de n bytes. n debe ser mayor que 0 y menor que un número que
| depende del tamaño de página del espacio de tablas. La longitud
| máxima es 32704.
| CLOB(n) Series de caracteres de longitud variable con un máximo de n
| caracteres. n no puede exceder de 2 147 483 647. La longitud por
| omisión es 1.
| GRAPHIC(n) Series gráficas de longitud fija que contienen n caracteres de doble
| byte. n debe ser mayor que 0 y menor que 128. La longitud por
| omisión es 1.
| VARGRAPHIC(n) Series gráficas de longitud variable. La longitud máxima, n, debe
| ser mayor que 0 y menor que un número que depende del tamaño
| de página del espacio de tablas. La longitud máxima es 16352.
| DBCLOB(n) Caracteres de doble byte de longitud variable con un máximo de n
| caracteres de doble byte. n no puede exceder de 1 073 741 824. La
| longitud por omisión es 1.
| BINARY(n) Series binarias de longitud fija o longitud variable con una longitud
| de n bytes. n debe ser mayor que 0 y no mayor que 255. La
| longitud por omisión es 1.
| VARBINARY(n) Series binarias de longitud variable con una longitud de n bytes. La
| longitud de n debe ser mayor que 0 y menor que un número que
| depende del tamaño de página del espacio de tabla. La longitud
| máxima es 32704.
| BLOB(n) Series binarias de longitud variable con una longitud de n bytes. n
| no puede exceder de 2 147 483 647. La longitud por omisión es 1.
|
En la mayoría de casos, el contenido de los datos que una columna debe almacenar
impone el tipo de datos que se elige.
Ejemplo: La tabla DEPT tiene una columna, DEPTNAME. El tipo de datos de la

columna DEPTNAME es VARCHAR(36). Debido a que los nombres de
departamento varían considerablemente de longitud, la selección de un tipo de
datos de longitud variable parece apropiada. Si selecciona un tipo de datos
CHAR(36), por ejemplo, el resultado es mucho espacio sin utilizar desaprovechado.
En este caso, DB2 asigna a todos los nombres de departamentos la misma cantidad
de espacio (36 bytes) sin tener en cuenta la longitud. Un tipo de datos CHAR(6)
para el número de empleado (EMPNO) es una opción razonable ya que todos los
valores son valores de longitud fija (6 bytes).
Series de caracteres de longitud fija y de longitud variable
La utilización de VARCHAR ahorra espacio de disco, pero conlleva un
coste adicional de 2 bytes para cada valor. La utilización de VARCHAR

también requiere proceso adicional para filas de longitud variable. Por lo
tanto, es preferible utilizar CHAR en lugar de VARCHAR, a menos que el
espacio ahorrado al utilizar VARCHAR sea significativo. El espacio
ahorrado no es significativo si la longitud máxima de columna es reducida
o si las longitudes de los valores no presentan una variación significativa.
Recomendación: Normalmente, no debe definir una columna como

VARCHAR(n) o CLOB(n) a menos que n tenga 18 caracteres como mínimo.
Subtipos de serie
| Si una aplicación que accede a la tabla utiliza un esquema de codificación
| diferente del que utiliza DBMS, los siguientes subtipos de serie pueden ser
| importantes:
BIT No representa caracteres.
SBCS Representa caracteres de un solo byte.
MIXED
Representa caracteres de un solo byte y caracteres de varios bytes.
Los subtipos de serie tan solo se aplican a los tipos de datos CHAR,
VARCHAR y CLOB. Sin embargo, el subtipo de serie BIT no está
permitido para el tipo de datos CLOB.
Datos gráficos y mixtos
Cuando las columnas contienen caracteres del juego de caracteres de doble
byte (DBCS), puede definirlas como datos gráficos o datos mixtos.
Los datos gráficos pueden ser GRAPHIC, VARGRAPHIC o DBCLOB. La
utilización de VARGRAPHIC ahorra espacio de disco, pero conlleva un
coste adicional de 2 bytes para cada valor. La utilización de VARGRAPHIC
también requiere proceso adicional para filas de longitud variable. Por lo
tanto, es preferible utilizar GRAPHIC en lugar de utilizar VARGRAPHIC a
menos que el espacio ahorrado al utilizar VARGRAPHIC sea significativo.
El espacio ahorrado no es significativo si la longitud máxima de columna
es reducida o si las longitudes de los valores no varían significativamente.
Recomendación: Normalmente, no debe definir una columna como

VARGRAPHIC(n) a menos que n tenga 18 caracteres de doble byte como
mínimo (lo cual representa una longitud de 36 bytes).
Las columnas de serie de caracteres de datos mixtos pueden contener
caracteres SBCS (juego de caracteres de un solo byte) y DBCS. Puede
especificar las columnas de serie de caracteres de datos mixtos como
CHAR, VARCHAR o CLOB con MIXED DATA.
Recomendación: Si todos los caracteres son caracteres DBCS, utilice los

tipos de datos gráficos. (Kanji es un ejemplo de un idioma que necesita
caracteres DBCS.) Para caracteres SBCS, utilice datos mixtos para guardar 1
byte para cada carácter de un solo byte de la columna.
“Codificación de esquemas para datos de serie” en la página 191
Tipos de datos numéricos

DB2 da soporte a varios tipos de tipos de datos numéricos, cada uno de los cuales
tiene sus propias características.

Para datos numéricos, utilice columnas numéricas en lugar de columnas de serie.
Las columnas numéricas requieren menos espacio que las columnas de serie y DB2
verifica que los datos tengan el tipo asignado.
Ejemplo: Suponga que DB2 calcula un rango entre dos números. Si los valores
tienen un tipo de datos de serie, DB2 supone que los valores pueden incluir todas
las combinaciones de caracteres alfanuméricos. Por el contrario, si los valores
tienen un tipo de datos numérico, DB2 puede calcular un rango entre los dos
valores de forma más eficaz.
La tabla siguiente describe los tipos de datos numéricos.

| Tabla 28. Tipos de datos numéricos
| Tipo de datos Indica una columna de...
| SMALLINT Enteros pequeños. Un entero pequeño es un entero binario con una
| precisión de 15 bits. El rango oscila entre -32768 y +32767.
| Enteros grandes. Un entero grande es un entero binario con una
| INTEGER o INT precisión de 31 bits. El rango oscila entre -2147483648 y
| +2147483647.
| BIGINT Enteros muy grandes. Un entero muy grande es un entero binario con
| una precisión de 63 bits. El rango de los enteros muy grandes oscila
| entre -9223372036854775808 y +9223372036854775807.
| Un número decimal es un número decimal empaquetado con una
| DECIMAL o coma decimal implícita. La posición de la coma decimal la
| NUMERIC determina la precisión y la escala del número. La escala, que es el
| número de dígitos en la parte fraccionaria del número, no puede ser
| negativa o mayor que la precisión. La precisión máxima es de 31
| dígitos.
| Todos los valores de una columna decimal tienen la misma

| precisión y escala. El rango de una variable decimal o los números
| de una columna decimal están entre -n y +n, donde n es el número
| positivo más grande que se puede representar con la precisión y
| escala aplicable. El rango máximo oscila entre 1 - 10³¹ y 10³¹ - 1.
| DECFLOAT Un valor de coma flotante decimal es un número IEEE 754r con un a
| coma decimal. La posición de la coma decimal se almacena en cada
| valor de coma flotante decimal. La precisión máxima es de 34
| dígitos.
| El rango de un número de coma flotante decimal tiene 16 ó 34

| dígitos de precisión; el rango de exponente es respectivamente
| oscila entre 10-383 y 10+384 o entre 10-6143 y 10+6144.
| REAL Un número de coma flotante de precisión simple es un número de
| coma flotante corto de 32 bits. El rango de los números de coma
| flotante de precisión simple oscila aproximadamente entre -7.2E+75
| y 7.2E+75. En este rango, el valor negativo más grande está cerca de
| -5.4E-79 y el valor positivo más pequeño está cerca de 5.4E-079.
| DOUBLE Un número de coma flotante de doble precisión es un número de coma
| flotante largo de 64 bits. El rango de los números de coma flotante
| de doble precisión oscila aproximadamente entre -7.2E+75 y
| 7.2E+75. En este rango, el valor negativo más grande está cerca de
| -5.4E-79 y el valor positivo más pequeño está cerca de 5.4E-079.
| Nota: zSeries y z/Architecture utilizan el formato de System/390 y dan soporte al formato
| de coma flotante IEEE.
|

Para valores enteros, SMALLINT INTEGER o BIGINT (según el rango de los
valores) generalmente es preferible DECIMAL.
Puede definir una columna numérica exacta como una columna de identidad. Una
columna de identidad tiene un atributo que permite a DB2 generar automáticamente
un valor numérico exclusivo para cada fila que se inserta en la tabla. Las columnas
de identidad se adaptan mejor a la tarea de generar valores de clave primaria
exclusivos. Las aplicaciones que utilizan columnas de identidad pueden evitar los
problemas de simultaneidad y rendimiento que se producen a veces cuando las
aplicaciones implementan sus propios contadores exclusivos.
Tipos de datos de fecha, hora e indicaciones de fecha y hora

Aunque puede considerar almacenar fechas y horas como valores numéricos,
puede aprovechar las ventajas de los tipos de datos de fecha y hora: DATE, TIME
y TIMESTAMP.
La tabla siguiente describe los tipos de datos para fechas, horas e indicaciones de
fecha y hora.
Tabla 29. Tipos de datos de fecha, hora e indicaciones de fecha y hora
Tipo de datos Indica una columna de...
DATE Fechas. Una fecha es un valor de tres partes que representa un año,
mes y día dentro del rango de 0001-01-01 a 9999-12-31.
TIME Horas. Una hora es un valor de tres partes que representa una hora
del día en horas, minutos y segundos dentro del rango de 00.00.00 a
24.00.00.
TIMESTAMP Indicaciones de fecha y hora. Una indicación de fecha y hora es un
valor de siete partes que representa una fecha y hora mediante año,
mes, día, hora, minuto, segundo y microsegundo, dentro del rango
de 0001-01-01-00.00.00.000000 a 9999-12-31-24.00.00.000000.
DB2 almacena valores de tipos de datos de fecha y hora en un formato interno

especial. Cuando se cargan o recuperan datos, DB2 puede convertirlos a o de
cualquiera de los formatos de la tabla siguiente.
Tabla 30. Opciones de formato de fecha y hora
Nombre de formato Abreviatura Fecha típica Hora típica
International Standards ISO 2003-12-25 13.30.05
Organization
Estándar de IBM en EE.UU. USA 12/25/2003 1:30 PM
Estándar de IBM en Europa EUR 25.12.2003 13.30.05
Japanese Industrial Standard, era JIS 2003-12-25 13:30:05
cristiana
Ejemplo 1: La consulta siguiente muestra las fechas en las que se ha contratado a

todos los empleados, en formato estándar de IBM en EE.UU., independientemente
del valor por omisión local:
SELECT EMPNO, CHAR(HIREDATE, USA) FROM EMP;
Si utiliza tipos de datos de fecha y hora, puede beneficiarse de las funciones

incorporadas de DB2 que funcionan específicamente en valores de fecha y hora, y
puede especificar cálculos para valores de fecha y hora.

Ejemplo 2: Suponga que una empresa de fabricación tiene como objetivo entregar
todos los pedidos de clientes en cinco días. Para ello defina las columnas
SHIPDATE y ORDERDATE como tipos de datos DATE. La empresa puede utilizar
los tipos de datos de fecha y hora y la función incorporada DAYS para comparar la
fecha de entrega con la fecha de pedido. A continuación se muestra cómo la
empresa puede codificar la función para generar una lista de pedidos que excedan
el objetivo de entrega en cinco días:
DAYS(SHIPDATE) — DAYS(ORDERDATE)> 5
Como resultado, los programadores no tienen que desarrollar, probar y mantener

código de aplicación para realizar aritmética de fecha y hora compleja que necesita
que se permita el número de días de cada mes.
Puede utilizar las siguientes funciones definidas por el usuario de ejemplo (que se
facilitan con DB2) para modificar cómo se visualizan las fechas y horas.
v ALTDATE devuelve la fecha actual en un formato especificado por el usuario o
convierte una fecha especificada por el usuario de un formato a otro.
v ALTTIME devuelve la hora actual en un formato especificado por el usuario o
convierte una hora especificada por el usuario de un formato a otro.
Durante la instalación, también puede proporcionar una rutina de salida para

realizar conversiones de o a cualquier estándar local.
Durante la carga de valores de fecha u hora desde una fuente externa, DB2 acepta
cualquiera de las opciones de formato de fecha y hora que se listan en esta
información. DB2 convierte valores de entrada válidos al formato interno. Para la
recuperación, se especifica un formato por omisión durante la instalación de DB2.
Posteriormente puede alterar temporalmente el valor por omisión utilizando una
opción de precompilador para todas las sentencias de un programa o utilizando la
función escalar CHAR para una sentencia de SQL determinada y especificando el
formato deseado.
Tipo de datos XML

El tipo de datos XML se utiliza para definir columnas de una tabla que almacena
valores XML. Este tipo de datos pureXML proporciona la capacidad de almacenar
documentos XML con la forma correcta en una base de datos.
| Todos los datos XML se almacenan en la base de datos en una representación

| interna. Los datos de tipo carácter de esta representación interna siguen el
| esquema de codificación UTF-8.
Los valores XML que se almacenan en una columna XML tienen una
representación interna que no es una serie y no se puede comparar directamente
con valores de serie. Un valor XML puede transformarse en un valor de de tipo
serie serializado que representa el documento XML utilizando la función
XMLSERIALIZE o recuperando el valor en una variable de aplicación de un tipo
XML, serie o binario. De forma similar, un valor de tipo serie que representa un
documento XML puede transformarse en un valor XML utilizando la función
XMLPARSE o almacenando un valor de un tipo de datos de aplicación XML,
binario o serie en una columna XML.
El tamaño de un valor XML de una tabla de DB2 no tiene límite de arquitectura.

Sin embargo, los datos XML serializados que se almacenan en una columna XML o
se recuperan de una columna XML tienen un límite de 2 GB.

La validación de un documento XML según un esquema XML, generalmente
realizado durante una operación INSERT o UPDATE en una columna XML, está
soportada por el depósito de esquemas XML (XSR).
Tipos de datos de objetos grandes

Los tipos de datos VARCHAR, VARGRAPHIC y VARBINARY tienen un límite de
almacenamiento de 32 KB. Sin embargo, a menudo las aplicaciones necesitan
almacenar documentos de texto grandes o diversos tipos de datos adicionales
como, audio, vídeo, dibujos, imágenes y una combinación de texto y gráficos. Para
objetos de datos de más de 32 KB, puede utilizar los correspondientes tipos de
datos de objetos grandes (LOB) para almacenar estos objetos.
| DB2 proporciona tres tipos de datos para almacenar estos objetos de datos como
| series con un tamaño máximo de 2 GB:
Objetos grandes de caracteres (CLOB)
Utilice el tipo de datos CLOB para almacenar SBCS o datos mixtos como,
por ejemplo, documentos que contienen un juego de caracteres simple.
Utilice este tipo de datos si los datos son superiores (o pueden crecer hasta
superar) el límite que el tipo de datos VARCHAR permite.
Objetos grandes de caracteres de doble byte (DBCLOB)
Utilice el tipo de datos DBCLOB para almacenar grandes cantidades de
datos DBCS como, por ejemplo, documentos que utilizan un juego de
caracteres DBCS.
Objetos binarios grandes (BLOB)
Utilice el tipo de datos BLOB para almacenar grandes cantidades de datos
no de tipo carácter como, por ejemplo, imágenes, voz y medios mixtos.
Si los datos no caben totalmente dentro de una página de datos, puede definir una
o más columnas como columnas LOB. Una ventaja de utilizar LOB es que se
pueden crear funciones definidas por el usuario sólo permitidas en tipos de datos
LOB.
″Objetos grandes (LOB)″ (Consulta de DB2 SQL)
Tipo de datos ROWID

Utilice el tipo de datos ROWID para identificar filas de forma exclusiva y
permanente en un subsistema DB2.
DB2 puede generar un valor para la columna cuando se añade una fila, según la
opción que se elija (GENERATED ALWAYS o GENERATED BY DEFAULT) al
definir la columna. Puede utilizar una columna ROWID en una tabla por varios
motivos.
v Puede definir una columna ROWID para incluir datos LOB en una tabla.
v Puede utilizar acceso directo de fila para que DB2 acceda a una fila directamente
a través de la columna ROWID. Si una aplicación selecciona una fila de una
tabla que contiene una columna ROWID, el valor de ID de fila contiene
implícitamente la ubicación de la fila. Si utiliza este valor de ID de fila en la
condición de búsqueda de sentencias SELECT posteriores, es posible que DB2 no
pueda navegar directamente hasta la fila.

Tipos diferenciados
Un tipo diferenciado es un tipo de datos definido por el usuario basado en tipos de
datos incorporados existentes de DB2. Es decir, un tipo diferenciado es
internamente igual que un tipo de datos incorporado, pero DB2 lo trata como un
tipo separado e incompatible por finalidades de semántica.
La definición del propio tipo diferenciado asegura que tan solo las aplicaciones
definidas explícitamente en un tipo diferenciado puedan aplicarse a sus instancias.
Ejemplo 1: Podría definir un tipo diferenciado US_DOLLAR basado en el tipo de

datos DB2 DECIMAL para identificar valores decimales que representan dólares de
Estos Unidos. El tipo diferenciado US_DOLLAR no adquiere automáticamente las
funciones y operadores de su tipo fuente, DECIMAL.
Aunque puede tener distintos tipos diferenciados basados en los mismos tipos de
datos incorporados, los tipos diferenciados tienen la propiedad de tipificación
estricta. Con esta propiedad, no se pueden comparar directamente instancias de un
tipo diferenciado con cualquier otra instancia del mismo tipo. La tipificación
estricta impide semánticamente operaciones incorrectas (como, por ejemplo, la
adición explícita de dos monedas diferentes) sin pasar primero por un proceso de
conversión. El usuario define los tipos de operaciones que pueden producirse para
instancias de un tipo diferenciado.
Si su empresa desea realizar un seguimiento de las ventas en varios países, deberá

convertir la moneda para cada país donde realiza ventas.
Ejemplo 2: Puede definir un tipo diferenciado para cada país. Por ejemplo, para
crear tipos US_DOLLAR y tipos CANADIAN_DOLLAR, puede utilizar las
siguientes sentencias CREATE DISTINCT TYPE:
CREATE DISTINCT TYPE US_DOLLAR AS DECIMAL (9,2);
CREATE DISTINCT TYPE CANADIAN_DOLLAR AS DECIMAL (9,2);
Ejemplo 3: Una vez definidos los tipos diferenciados, puede utilizarlos en las
sentencias CREATE TABLE:
CREATE TABLE US_SALES
(PRODUCT_ITEM_NO INTEGER,
MONTH INTEGER,
YEAR INTEGER,
TOTAL_AMOUNT US_DOLLAR);
CREATE TABLE CANADIAN_SALES
(PRODUCT_ITEM_NO INTEGER,
MONTH INTEGER,
YEAR INTEGER,
TOTAL_AMOUNT CANADIAN_DOLLAR);
Las funciones definidas por el usuario soportan la manipulación de tipos

diferenciados.
“Codificación de esquemas para datos de serie”
Codificación de esquemas para datos de serie

Par los datos de serie, todos los caracteres están representados por una
representación de codificación común (Unicode, ASCII o EBCDIC). La codificación
de esquemas se aplica a tipos de datos de serie y a otros tipos que están basados
en tipos de serie.

| Las empresas multinacionales que participan en el comercio internacional a
| menudo almacenan datos de más de un país en la misma tabla. Algunos países
| utilizan identificadores de juegos de caracteres codificados diferentes. DB2 for
| z/OS da soporte al esquema de codificación de Unicode, que representa numerosas
| ubicaciones e idiomas. Si necesita realizar conversión de caracteres en datos
| Unicode, es más probable que la conversión conserve toda la información.
En algunos casos, puede que sea necesario convertir caracteres a una

representación de codificación diferente. El proceso de conversión se denomina
conversión de caracteres. La mayoría de usuarios no necesitan tener conocimientos
sobre conversión de caracteres. Cuando se produce una conversión de caracteres, lo
hace de modo automático y una conversión correcta es invisible para la aplicación
y los usuarios.
“Tipos de datos de serie” en la página 184
“Tipos diferenciados” en la página 191
Cómo compara DB2 tipos de datos

DB2 compara valores de tipos y longitudes diferentes.
Se produce una comparación cuando ambos valores son numéricos, ambos valores
son series de caracteres o ambos valores son series gráficas. También se pueden
producir comparaciones entre datos de caracteres y gráficos o entre datos de
caracteres y de fecha y hora si los datos de caracteres son una representación de
caracteres válida de un valor de fecha y hora. Los diferentes tipos de
comparaciones de serie o numéricas pueden repercutir en el rendimiento.
Valores nulos y por omisión

Los valores nulos y los valores por omisión son útiles en situaciones en las que no
se puede especificar el contenido de algunas columnas al crear columnas de tabla.
Valores nulos
Algunas columnas no pueden tener un valor significativo en cada fila. DB2 utiliza
un indicador de valor especial, el valor nulo, para indicar un valor desconocido o
que falta. Un valor nulo es un valor especial que DB2 interpreta para indicar que
no hay datos presentes.
Si no especifica lo contrario, DB2 permite que cualquier columna contenga valores

nulos. Los usuarios pueden crear filas en la tabla sin proporcionar un valor para la
columna.
Mediante la utilización de la cláusula NOT NULL puede no permitir valores nulos

en la columna. Las claves primarias deben definirse como NOT NULL.
Ejemplo: La definición de tabla para la tabla DEPT especifica cuándo puede

utilizar un valor nulo. Tenga en cuenta que sólo puede utilizar nulos para la
columna MGRNO:
CREATE TABLE DEPT
(DEPTNO CHAR(3) NOT NULL,
DEPTNAME VARCHAR(36) NOT NULL,
MGRNO CHAR(6) ,
ADMRDEPT CHAR(3) NOT NULL,
PRIMARY KEY (DEPTNO) )
IN MYDB.MYTS;

Antes de decidir si permitir o no nulos para valores desconocidos en una columna
determinada, debe tener en cuenta cómo afectan los nulos a los resultados de una
consulta:
v Nulos en programas de aplicaciones
En una sentencia de SQL, los nulos tan solo cumplen la condición del predicado
especial IS NULL. DB2 clasifica los valores nulos de manera diferente que los
valores no nulos. Los valores nulos no se comportan como los otros valores. Por
ejemplo, si pregunta a DB2 si un valor nulo es más grande que un valor
conocido determinado, la respuesta será UNKNOWN. Si, a continuación,
pregunta a DB2 si un valor nulo es más pequeño que el mismo valor conocido,
la respuesta seguirá siendo UNKNOWN.
Si la obtención de un valor UNKNOWN es inaceptable para una columna
determinada, en su lugar puede definir un valor por omisión. Los
programadores están familiarizados con el comportamiento de los valores por
omisión.
v Nulos en una operación de unión
Los nulos necesitan un manejo especial en operaciones de unión. Si realiza una
operación de unión en una columna que puede contener valores nulos, considere
utilizar una unión externa.
“Valores para atributos de clave” en la página 74
“Modos de unir datos de más de una tabla” en la página 110
Valores por omisión

DB2 define algunos valores por omisión y el usuario define otros (utilizando la
cláusula DEFAULT en la sentencia CREATE TABLE o ALTER TABLE).
Si una columna está definida como NOT NULL WITH DEFAULT o si el usuario no
especifica NOT NULL, DB2 almacena un valor por omisión para una columna
cada vez que una inserción o una carga no proporciona un valor para dicha
columna. Si una columna está definida como NOT NULL, DB2 no proporciona
ningún valor por omisión.
valores por omisión definidos por DB2
DB2 genera un valor por omisión para columnas ROWID. DB2 también determina
valores por omisión para columnas que los usuarios definen con NOT NULL
WITH DEFAULT, pero para las que no se especifica un valor específico, tal como
se muestra en la tabla siguiente.
| Tabla 31. Valores por omisión definidos por DB2 para tipos de datos
| Para columnas de... Tipos de datos Valor por omisión
| Números SMALLINT, INTEGER, 0
| BIGINT, DECIMAL,
| NUMERIC, REAL, DOUBLE,
| DECFLOAT o FLOAT
| Series de longitud fija CHAR o GRAPHIC Blancos
| BINARY Ceros hexadecimales

| Series de longitud variable VARCHAR, CLOB, Serie vacía
| VARGRAPHIC, DBCLOB,
| VARBINARY o BLOB
| Fechas DATE CURRENT DATE

| Tabla 31. Valores por omisión definidos por DB2 para tipos de datos (continuación)
| Para columnas de... Tipos de datos Valor por omisión
| Horas TIME CURRENT TIME
| Indicaciones de fecha y hora TIMESTAMP CURRENT TIMESTAMP
| ROWID ROWID Generado por DB2
|
Valores por omisión definidos por el usuario
Puede especificar un valor por omisión determinado como, por ejemplo:

DEFAULT 'N/A'
Cuando elige un valor por omisión, debe poder asignarlo al tipo de datos de la
columna. Por ejemplo, todas las constantes de tipo serie son VARCHAR. Puede
utilizar una constante de tipo serie VARCHAR como valor por omisión para una
columna CHAR aunque el tipo no coincida de forma exacta. Sin embargo, no
puede especificar un valor por omisión ’N/A’ para una columna con un tipo de
datos numérico.
En el ejemplo siguiente, las columnas están definidas como CHAR (longitud fija).
Los registros especiales (USER y CURRENT SQLID) a los que se hace referencia
contienen valores de longitud variable.
Ejemplo: Si desea un registro de cada usuario que inserta cualquier fila de una
tabla, defina la tabla con dos columnas adicionales:
PRIMARY_ID CHAR(8) WITH DEFAULT USER,
SQL_ID CHAR(8) WITH DEFAULT CURRENT SQLID,
A continuación, puede crear una vista que omita estas columnas y permita a los
usuarios actualizar la vista en lugar de la tabla base. Después, DB2 añade, por
omisión, el ID de autorización primario y el SQLID del proceso.
Cuando añada columnas a una tabla existente, debe definirlas como anulables o no
nulas con valor por omisión. Suponga que añade una columna a una tabla
existente y especifica no nulo con valor por omisión. Si DB2 lee de la tabla antes
de añadir datos a la columna, los valores de la columna que se recuperan son los
valores por omisión. Con muy pocas excepciones, los valores por omisión para una
recuperación son iguales que los valores por omisión para una inserción.
Valores por omisión para ROWID
DB2 siempre genera los valores por omisión para ROWID.

273
Comparación de valores nulos y valores por omisión

En algunas situaciones la utilización de un valor nulo es más fácil y más adecuado
que la utilización de un valor por omisión.
Suponga que desea averiguar cuál es el salario medio de todos los empleados de
un departamento. La columna de salario no siempre necesita contener un valor
significativo, por lo tanto puede elegir entre las opciones siguientes:
v Permitir valores nulos para la columna SALARY

v Utilizar un valor por omisión no nulo (como por ejemplo, 0)
Al permitir valores nulos puede formular la consulta de forma fácil y DB2

proporciona el promedio de todos los salarios conocidos o registrados. El cálculo
no incluye las filas que contienen valores nulos. En el segundo caso,
probablemente se obtendrá una respuesta engañosa a menos que se conozca el
valor por omisión no nulo para los salarios desconocidos y se formule la consulta
de acuerdo con esto.
La figura siguiente muestra dos casos de ejemplo. La tabla de la figura excluye los
datos de salario para el empleado número 200440 debido a que la empresa acaba
de contratar a este empleado y todavía no ha determinado su salario. El cálculo del
salario medio para el departamento E21 varía, en función de si se utilizan valores
no nulos o valores por omisión no nulos.
v En la parte izquierda de la figura se supone que se utilizan valores nulos. En
este caso, el cálculo del salario medio para el departamento E21 solamente
incluye tres empleados (000320, 000330 y 200340) para los cuales están
disponibles datos sobre el salario.
v En la parte derecha de la figura se supone que se utiliza un valor por omisión
no nulo distinto de cero (0). En este caso, el cálculo del salario medio para el
departamento E21 incluye todos los cuatro empleados, aunque sólo existe
información válida sobre el salario para tres empleados.
Como se puede observar, únicamente la utilización de un valor nulo tiene como

resultado un salario medio preciso para el departamento E21.
Figura 33. Cuándo es preferible utilizar nulos que valores por omisión
| Los valores nulos son diferentes en la mayoría de situaciones para que dos valores
| nulos no sean iguales entre sí.
Ejemplo: El ejemplo siguiente muestra cómo comparar dos columnas para ver si
son iguales o si ambas columnas son nulas:
WHERE E1.DEPT IS NOT DISTINCT FROM E2.DEPT

Utilización de restricciones de comprobación para imponer la
validez de valores de columnas
Una restricción de comprobación es una regla que especifica los valores permitidos
en una o más columnas de cada fila de una tabla. Puede utilizar restricciones de
comprobación para asegurarse de que únicamente se permitan valores del dominio
para la columna o atributo.
Como resultado de la utilización de restricciones de comprobación, los

programadores no tienen que desarrollar, probar ni mantener código de aplicación
que realice estas comprobaciones.
Puede optar por definir restricciones de comprobación utilizando la sentencia

CREATE TABLE o la sentencia ALTER TABLE de SQL. Por ejemplo, puede que
desee asegurarse de que cada valor de la columna SALARY de la tabla EMP
contiene más de una cantidad mínima determinada.
DB2 impone una restricción de comprobación aplicando la condición de búsqueda

pertinente a cada fila que se inserta, actualiza o carga. Se produce un error si el
resultado de la condición de búsqueda es falso para cualquier columna.
Utilización de restricciones de comprobación para insertar filas

en tablas
Cuando se utiliza la sentencia INSERT o la sentencia MERGE para añadir una fila
a una tabla, DB2 impone automáticamente todas las restricciones de comprobación
para dicha tabla. Si los datos violan alguna restricción de comprobación definida
para la tabla, DB2 no inserta la fila.
Ejemplo 1: Suponga que la tabla NEWEMP tiene las dos restricciones de

comprobación siguientes:
v Los empleados no pueden recibir una comisión mayor que su salario.
v Los números de departamento deben estar entre ’001’ y ’100’ inclusive.
Considere esta sentencia INSERT, que añade un empleado que tiene un salario de
65 000 $ y una comisión de 6 000 $:
INSERT INTO NEWEMP
(EMPNO, FIRSTNME, LASTNAME, DEPT, JOB, SALARY, COMM)
VALUES ('100125', 'MARY', 'SMITH','055', 'SLS', 65000.00, 6000.00);
La sentencia INSERT de este ejemplo es satisfactoria porque cumple ambas

restricciones.
Ejemplo 2: Considere esta sentencia INSERT:

INSERT INTO NEWEMP
(EMPNO, FIRSTNME, LASTNAME, DEPT, JOB, SALARY, COMM)
VALUES ('120026', 'JOHN', 'SMITH','055', 'DES', 5000.00, 55000.00 );
La sentencia INSERT de este ejemplo no es satisfactoria porque la comisión de

55 000 $ es mayor que el salario de 5 000 $. Esta sentencia INSERT viola una
restricción de comprobación en NEWEMP.
Utilización de restricciones de comprobación para actualizar

tablas
DB2 impone de forma automática todas las restricciones de comprobación para una
tabla cuando se utiliza la sentencia UPDATE o la sentencia MERGE para cambiar
una fila de la tabla. Si la actualización propuesta viola cualquier restricción de
comprobación definida para la tabla, DB2 no actualiza la fila.

Ejemplo: Suponga que la tabla NEWEMP tiene las dos restricciones de
comprobación siguientes:
v Los empleados no pueden recibir una comisión mayor que su salario.
v Los números de departamento deben estar entre ’001’ y ’100’ inclusive.
Considere esta sentencia UPDATE:

UPDATE NEWEMP
SET DEPT = '011'
WHERE FIRSTNME = 'MARY' AND LASTNAME= 'SMITH';
Esta actualización es satisfactoria porque cumple las restricciones definidas en la

tabla NEWEMP.
Ejemplo: Considere esta sentencia UPDATE:

UPDATE NEWEMP
SET DEPT = '166'
WHERE FIRSTNME = 'MARY' AND LASTNAME= 'SMITH';
Esta actualización no es satisfactoria porque el valor de DEPT es ’166’ y viola la

restricción de comprobación en NEWEMP de que los valores de DEPT deben estar
entre ’001’ y ’100.’
Diseño de una fila

El tamaño de registro es una consideración importante en el diseño de una tabla.
En DB2, un registro es la representación en almacenamiento de una fila.
DB2 almacena registros con páginas con un tamaño de 4 KB, 8 KB, 16 KB o 32 KB.
Normalmente, no se puede crear una tabla con un tamaño de registro máximo que
sea superior al tamaño de página. No existe ningún otro límite absoluto, pero se
arriesga a desperdiciar espacio de almacenamiento si ignora el tamaño de registro
para implementar un buen diseño teórico.
| Si la longitud de registro es superior al tamaño de página, considere utilizar un

| tipo de datos LOB (objeto grande) o un tipo de datos XML.
“Tipos de datos de objetos grandes” en la página 190
“Visión general de pureXML” en la página 24
Longitudes de registro y páginas

La suma de las longitudes de todas las columnas es la longitud del registro. La
longitud de los datos físicamente almacenados en la tabla es la longitud del
registro más la actividad general de DB2 para cada fila y cada página. Puede elegir
entre varios tamaños de página para longitudes de registro que se adapten mejor a
sus necesidades.
Si los tamaños de fila son muy pequeños, utilice el tamaño de página de 4 KB.
Utilice el valor por omisión de tamaños de página de 4 KB cuando el acceso a los
datos es aleatorio y generalmente sólo requiere unas pocas filas de cada página.
Algunas situaciones requieren tamaños de página más grandes. DB2 proporciona

tres tamaños de página más grandes de 8 KB, 16 KB y 32 KB para permitir
registros más largos. Por ejemplo, si el tamaño de las filas individuales es superior

a 4 KB, debe utilizar un tamaño de página más grande. En general, puede mejorar
el rendimiento utilizando páginas para longitudes de registro que se adapten mejor
a sus necesidades.
Diseños que desperdician espacio

Un espacio de tablas que contiene registros con una longitud inferior a una página
pueden desperdiciar espacio.
En general, se desperdicia espacio en un espacio de tabla que contiene únicamente

registros que sean ligeramente más largos que una media página puesto que una
página sólo puede contener un registro. Si puede reducir la longitud de registro
para que sea inferior a media página, tan solo necesita la mitad de páginas.
Consideraciones similares se aplican a registros de un poco más de un tercio de
página, un cuarto de página, etc.
Creación de espacios de tablas

| DB2 soporta tres tipos diferentes de espacios de tablas: segmentados, particionados
| y LOB. Cada tipo de espacio de tablas tiene sus propias ventajas y desventajas, las
| cuales debería tener en cuenta al elegir el espacio de tablas que se adapte mejor a
| lo que necesita.
| DB2 divide los espacios de tablas en unidades de igual tamaño, llamadas páginas,
| que se escriben en disco o se leen desde disco en una operación. Puede especificar
| tamaños de página para los datos; el tamaño de página por omisión es de 4 KB. Si
| DB2 ha creado implícitamente el espacio de tablas, DB2 elige el tamaño de página
| basado en un algoritmo de tamaño de fila.
Recomendación: Utilice espacios de tablas particionados para todos los espacios

de tablas a los que se hace referencia en consultas que pueden beneficiarse del
paralelismo de consulta. De lo contrario, utilice espacios de tablas segmentados
para otras consultas.
“Espacios de tablas de DB2” en la página 34
″Ejemplos de definiciones de espacio de tabla″ (DB2 Administration Guide)
Tipos de espacios de tablas de DB2

DB2 soporta diferentes tipos de espacios de tabla. Cada tipo de espacio de tabla
sirve para diferentes finalidades y tiene características diferentes.
Los espacios de tabla DB2 se pueden segmentar, particionar, segmentar y

particionar (universal) o bien ni segmentar ni particionar (simple) de forma
exclusiva.
Espacios de tabla que se segmentan exclusivamente

Un espacio de tablas segmentado exclusivamente es ideal para almacenar más de
una tabla, en especial tablas relativamente pequeñas. Las páginas contienen
segmentos y cada segmento contiene registros de sólo una tabla.
Los espacios de tablas segmentados contienen un máximo de 64 GB de datos y

pueden contener uno o más conjuntos de datos VSAM. Un espacio de tablas
pueden ser más grande si se cumple alguna de las condiciones siguientes:
v El espacio de tablas es un espacio de tablas particionado que se crea con la
opción DSSIZE.

v El espacio de tablas es un espacio de tablas LOB.
Por regla general, cada base de datos de DB2 no debería contener como máximo
entre 50 y 100 espacios de tablas. La siguiente directriz ayuda a minimizar el
mantenimiento, a aumentar la simultaneidad y a reducir el volumen de registro.
Las páginas de un espacio de tablas pueden tener un tamaño de 4KB, 8 KB, 16 KB

o 32 KB. Las páginas contienen segmentos y cada segmento contiene registros de
sólo una tabla. Cada segmento contiene el mismo número de páginas y cada tabla
utiliza únicamente los segmentos necesarios.
Cuando se ejecuta una sentencia que busca todas las filas para una tabla, DB2 no
necesita explorar todo el espacio de tablas. En lugar de ello, DB2 puede explorar
únicamente los segmentos del espacio de tablas que contienen dicha tabla. La
siguiente figura muestra una posible organización de los segmentos en un espacio
de tablas segmentado.
Figura 34. Posible organización de segmentos en un espacio de tablas segmentado
| Cuando se utiliza una sentencia INSERT, una sentencia MERGE o el programa de

| utilidad LOAD para insertar registros en una tabla, los registros de la misma tabla
| se almacenan en segmentos diferentes. Puede reorganizar el espacio de tablas para
| mover segmentos juntos a la misma tabla.
Definición de un espacio de tabla segmentado exclusivamente
| Un espacio de tablas segmentado exclusivamente consta de segmentos que

| contienen los registros de una tabla. El espacio de tablas segmentado es la opción
| de espacio de tablas por omisión. Para definir un espacio de tablas segmentado
| utilice la sentencia CREATE TABLESPACE con la cláusula SEGSIZE. Si utiliza esta
| cláusula, el valor que especifica representa el número de páginas de cada
| segmento. El valor debe ser un múltiplo de 4 (entre 4 y 64). La selección del valor
| depende del tamaño de las tablas que se almacenan. La tabla siguiente resume las
| recomendaciones para SEGSIZE.
Tabla 32. Recomendaciones para SEGSIZE
Número de páginas Recomendación para SEGSIZE
≤ 28 entre 4 y 28
> 28 < 128 páginas 32
≥ 128 páginas 64
Otra cláusula de la sentencia CREATE TABLESPACE es LOCKSIZE TABLE. Esta

cláusula sólo es válida para tablas que están en espacios de tablas segmentados.
Por lo tanto, DB2 puede adquirir bloqueos que bloqueen una única tabla, en lugar
de todo el espacio de tablas.

Si desea dejar páginas de espacio libre en un espacio de tablas segmentado, debe
tener como mínimo una página libre en cada segmento. Especifique la cláusula
FREEPAGE con un valor inferior al valor de SEGSIZE.
Ejemplo: Si utiliza FREEPAGE 30 con SEGSIZE 20, DB2 interpreta el valor de

FREEPAGE como 19 y se obtiene una página libre en cada segmento.
Restricción: Si crea un espacio de tablas segmentado para que lo utilicen tablas

temporales declaradas, no puede especificar ni la cláusula FREEPAGE ni la
cláusula LOCKSIZE.
Características de los espacios de tabla que se segmentan

exclusivamente
Los espacios de tabla que se segmentan exclusivamente comparten las

características siguientes:
v Cuando DB2 explora todas las filas para una tabla, sólo es necesario explorar los
segmentos asignados a dicha tabla. DB2 no necesita explorar todo el espacio de
tablas. No es necesario captar las páginas de segmentos vacíos.
v Cuando DB2 bloquea una tabla, el bloqueo no interfiere en el acceso a
segmentos de otras tablas.
v Cuando DB2 descarta una tabla, sus segmentos pasan a estar disponibles para
reutilizarse inmediatamente después de confirmarse el descarte sin esperar la
intervención de un trabajo del programa de utilidad REORG.
v Cuando se suprimen todas las filas de una tabla, todos los segmentos excepto
del primer segmento pasan a estar disponibles para reutilizarse inmediatamente
después de confirmarse la supresión. No es necesaria la intervención de un
trabajo del programa de utilidad REORG.
| v Una supresión masiva, que consiste en la supresión de todas las filas de una tabla,
| funciona mucho más rápido y produce mucha menos información de registro.
v Si el espacio de tablas sólo contiene una tabla, su segmentación significa que el
programa de utilidad COPY no copia las páginas que están vacías. Las páginas
pueden estar vacías como resultado de una tabla descartada o de una supresión
masiva.
v Algunos programas de utilidad de DB2 como, por ejemplo, LOAD con la opción
REPLACE, RECOVER y COPY, funcionan únicamente en un espacio de tablas o
en una partición, no en segmentos individuales. Por lo tanto, para un espacio de
tablas segmentado debe ejecutarse estos programas de utilidad en todo el
espacio de tablas. Para un espacio de tablas más grande, puede observar
problemas de disponibilidad.
v El mantenimiento de la correlación de espacios crea una sobrecarga adicional.
La creación de menos espacios de tablas almacenando varias tablas en un espacio

de tablas puede ayudarle a evitar que se alcance el número máximo de conjuntos
de datos abiertos simultáneamente. Cada espacio de tablas necesita como mínimo
un conjunto de datos. Durante la instalación se determina un número máximo de
conjuntos de datos abiertos simultáneamente. La utilización de menos espacios de
tablas reduce el tiempo dedicado a asignar y desasignar conjunto de datos.
Capítulo 8, “Gestión del rendimiento de DB2”, en la página 245
“Modos de mejorar el rendimiento para varios usuarios” en la página 255
“Utilización de espacio libre en almacenamiento de datos e índices” en la
página 252

“Directrices para la reorganización de datos” en la página 252
| ″Cómo crear un espacio de tabla explícitamente″ (DB2 Administration Guide)
″Factores para determinar el tamaño de página de un espacio de tabla″ (DB″
| ″CREATE TABLESPACE″ (Consulta de DB2 SQL)
Espacios de tabla que se particionan exclusivamente

Un espacio de tabla que se particiona exclusivamente almacena una única tabla.
DB2 divide el espacio de tablas en particiones.
Las particiones se basan en los valores de límite definidos para columnas

específicas. Los programas de utilidad y sentencias de SQL pueden ejecutarse
simultáneamente en cada partición.
En la figura siguiente cada partición contiene una parte de una tabla.
Figura 35. Páginas de un espacio de tablas particionado
Definición de espacios de tabla que se particionan exclusivamente
En un espacio de tabla particionado, puede imaginar cada partición como una

unidad de almacenamiento. Utilice la cláusula PARTITION de la sentencia
CREATE TABLESPACE para definir un espacio de tablas particionado. Para cada
partición que especifica en la sentencia CREATE TABLESPACE, DB2 crea un
conjunto de datos separado. El usuario asigna el número de particiones (entre 1 y
4096) y puede asignar particiones independientemente a diferentes grupos de
almacenamiento.
El número máximo de particiones de un espacio de tablas depende del tamaño de

conjunto de datos (parámetro DSSIZE) y del tamaño de página. El tamaño del
espacio de tabla depende del tamaño del conjunto de datos y de la cantidad de
particiones que están en el espacio de tabla.
Características de los espacios de tabla que se particionan

exclusivamente
Los espacios de tabla que se particionan exclusivamente comparten las

características siguientes:
v Se puede planificar el crecimiento. Cuando se define un espacio de tablas
particionado, normalmente DB2 distribuye los datos equitativamente entre las
particiones. Con el tiempo, la distribución de los datos puede volverse desigual
a medida que se producen inserciones y supresiones.
Se pueden volver a equilibrar los datos entre las particiones redefiniendo los
límites de particiones sin ningún impacto en la disponibilidad. También puede
se añadir una partición a la tabla y a cada índice particionado de la tabla: la
nueva partición estará disponible inmediatamente.

v Se puede dividir una tabla grande entre varios conjuntos de datos o grupos de
almacenamiento de DB2. No todas las particiones de la tabla necesitan usar el
mismo grupo de almacenamiento.
v Los espacios de tablas particionados permiten que un trabajo de programa de
utilidad trabaje en una parte de los datos mientras que se permite que otras
aplicaciones accedan simultáneamente a los datos de otras particiones. De este
modo, varios trabajos de programa de utilidad simultáneos pueden, por ejemplo,
cargar simultáneamente todas las particiones de un espacio de tablas. Puesto que
se puede trabajar en una parte de los datos, algunas de las operaciones en los
datos pueden necesitar menos tiempo.
v Se pueden utilizar trabajos separados para operaciones masivas de actualización,
supresión o inserción en lugar de utilizar un trabajo grande; cada trabajo más
pequeño puede trabajar en una partición diferente. La separación del trabajo
grande en varios trabajos más pequeños que se pueden ejecutar
simultáneamente puede reducir el tiempo transcurrido para la tarea global.
Si el espacio de tablas utiliza índices no particionados, puede que sea necesario
modificar el tamaño de los conjuntos de datos en los índices para evitar que se
produzca contención de E/S entre trabajos que se ejecutan simultáneamente.
Utilice el parámetro PIECESIZE de la sentencia CREATE INDEX o ALTER
INDEX para modificar los tamaños de los conjuntos de datos de índices.
v Se pueden colocar los datos a los que se accede con frecuencia en dispositivos
más rápidos. Evalúe si el particionamiento de tablas o el particionamiento de
índices puede separar más datos frecuentemente accedidos del resto de la tabla.
Se pueden colocar los datos frecuentemente accedidos en una partición para
ellos. También se puede utilizar un tipo de dispositivo diferente.
v Se puede beneficiar del paralelismo en determinadas consultas de sólo lectura.
Cuando DB2 determina que el proceso probablemente será extenso, puede
iniciar el proceso en paralelo de más de una partición a la vez. El proceso en
paralelo (para consultas de sólo lectura) es más eficaz cuando se dividen las
particiones entre diferentes volúmenes de disco y se permite que cada sistema
de E/S funcione en un canal separado.
Utilice la tecnología de compartimiento de datos de Sysplex paralelo para
procesar una única consulta de sólo lectura entre varios subsistemas DB2 de un
grupo de compartimiento. Se puede optimizar el proceso de consultas de
Sysplex paralelo situando cada subsistema DB2 en un complejo central de
procesadores separado.
v Las exploraciones de tabla particionada a veces son menos eficaces que las
exploraciones de espacio de tablas de espacios de tablas segmentados.
v DB2 abre más conjuntos de datos cuando se accede a datos de un espacio de
tablas particionado que cuando se accede a datos de otros tipos de espacios de
tablas.
v Los índices no particionados y los índices secundarios particionados de datos a
veces son una desventaja para espacios de tablas particionados.
“Asignación de espacios de tablas a almacenamiento físico” en la página 212
| “Espacios de tablas universales particionados por rango” en la página 205
| “Espacios de tablas de partición por crecimiento” en la página 204
″Factores para determinar el tamaño de página de un espacio de tabla″ (DB2

Tareas relacionadas
| ″CREATE INDEX″ (Consulta de DB2 SQL)
Espacios de tablas y espacios de índices habilitados para EA

Se pueden habilitar espacios de tablas particionados para direccionabilidad
ampliada (EA), una función de DFSMS. El término para los espacios de tablas y los
espacios de índices habilitados para direccionabilidad ampliada es habilitados para
EA.
Es necesario utilizar espacios de tablas o espacios de índices habilitados para EA si

se especifica un tamaño máximo de partición (DSSIZE) superior a 4 GB en la
sentencia CREATE TABLESPACE.
Los espacios de tablas particionados habilitados para EA y no habilitados para EA

sólo pueden tener una tabla y un máximo de 4096 particiones. La tabla siguiente
resume las diferencias.
Tabla 33. Diferencias entre espacios de tablas habilitados para EA y no habilitados para EA
Espacios de tablas habilitados para EA Espacios de tablas no habilitados para EA
Contienen un máximo de 4096 particiones de Contienen un máximo de 4096 particiones de
64 GB 4 GB
Se crean con cualquier valor válido de DSSIZE no puede exceder de 4 GB
DSSIZE
Los conjuntos de datos están gestionados por Los conjuntos de datos están gestionados por
SMS VSAM o SMS
Necesitan configuración Sin configuración adicional
| ″Cómo crear espacios de tabla y espacios de índice habilitados para EA″ (DB2
| Administration Guide)
Espacios de tablas simples

| Un espacio de tabla simple ni está particionado ni está segmentado. Aunque la
| creación de espacios de tablas simples ya no está soportada, la utilización de los
| espacios de tablas simples existentes está soportada.
| No puede crear espacios de tablas simples, pero puede modificar, actualizar datos
| o recuperar datos de espacios de tablas simples. Si crea implícitamente un espacio
| de tabla o crea explícitamente un espacio de tablas sin especificar las opciones
| SEGSIZE, NUMPARTS o MAXPARTITIONS, DB2 crea un espacio de tablas
| segmentado en lugar de un espacio de tablas simple. Por omisión, el espacio de
| tabla segmentado tiene un valor de 4 para SEGSIZE y un valor de ROW para
| LOCKSIZE.
Recomendación: Convierta los espacios de tabla simples en otros tipos de espacios

de tablas lo más pronto posible.

Tareas relacionadas
″Cómo eliminar, volver a crear o convertir un espacio de tabla″ (DB2
Espacios de tablas universales

Puede combinar las ventajas de la gestión de espacios segmentado con la
organización de espacios de tabla particionados utilizando espacios de tabla
universales. Un espacio de tabla universal es una combinación de esquemas de
espacio de tabla particionados y segmentados.
Algunas de las ventajas de los espacios de tabla universales son:

v Funcionalidad de partición por crecimiento
v Gestión del espacio mejorado al relacionarse con filas de longitud variable ya
que una página de correlación de espacios segmentados tiene más información
sobre espacio libre que una página de correlación de espacios particionados
v Rendimiento mejorado de supresión masiva mejorada debido a que la supresión
masiva en una organización de espacios de tablas segmentados tiende a ser más
rápida que en otros tipos de organizaciones de espacios de tabla
v Exploraciones de tablas localizadas en segmentos
v Reutilización inmediata de todos los segmentos de una tabla, o de la mayoría de
ellos, una vez que la tabla se ha descartado o suprimido masivamente
Restricciones:
| v Los espacios de tabla universales no se pueden crear en la base de datos de
| archivo de trabajo.
| v Los espacios de tabla universales necesitan más páginas de correlación de
| espacio que los espacios de tabla particionados de forma exclusiva.
| “Espacios de tabla que se segmentan exclusivamente” en la página 198
| “Espacios de tabla que se particionan exclusivamente” en la página 201
Espacios de tablas de partición por crecimiento:
Los espacios de tabla de partición por crecimiento le permiten particionar según el

crecimiento de los datos, lo que permite tablas segmentadas particionadas según su
crecimiento, sin necesidad de utilizar rangos de claves.
Los espacios de tabla de partición por crecimiento son un tipo de espacio de tabla
universal que puede contener una única tabla. El espacio en un espacio de tabla de
partición por crecimiento se divide en diferentes particiones. Los espacios de tabla
de partición por crecimiento se utilizan mejor cuando se cree que una tabla puede
superar los 64 GB y no contiene una clave de partición adecuada para dicha tabla.

| Los espacios de tabla de partición por crecimiento son similares a los espacios de
| tabla segmentados que gestiona DB2 para tablas únicas. DB2-managed segmented
| table spaces. DB2 gestiona espacios de tabla de partición por crecimiento y añade
| automáticamente una nueva partición cuando se necesita más espacio para
| satisfacer una inserción. El espacio de tabla empieza como un espacio de tabla de
| partición simple y crece automáticamente, como sea necesario, a medida que se
| añaden más particiones para alojar el crecimiento de los datos. Los espacios de
| tablas de partición por crecimiento pueden aumentar hasta 128 TB. El tamaño
| máximo se determina por los valores MAXPARTITIONS y DSSIZE que haya
| especificado y por el tamaño de página.
Aunque un espacio de tabla de partición por crecimiento esté particionado,

contiene prestaciones de organización segmentada y de gestió del espacio
segmentado en cada partición. A diferencia de una estructura no segmentada, la
estructura segmentada proporciona una mejor gestión del espacio y prestaciones de
supresión masiva. La estructura de particionamiento permite a los programas de
utilidad de DB2 continuar las operaciones a nivel de partición y prestaciones de
paralelismo.
Restricciones: Las siguientes restricciones se aplican a los espacios de tabla de

partición por crecimiento:
v La opción PART del programa de utilidad LOAD no está soportada.
| v La opción REBALANCE del programa de utilidad REORG no está soportada.
v El valor predeterminado SEGSIZE es 4.
v Los espacios de tabla deben estar gestionados por DB2 (no por el usuario) de
modo que DB2 tenga la libertad de crear conjuntos de datos cuando las
particiones se llenen.
v No se pueden crear espacios de tablas con la opción MEMBER CLUSTER.
v Las particiones no se pueden modificar, rotar ni añadir explícitamente. Esto
significa que las sentencias ALTER TABLE ADD PARTITION, ALTER TABLE
ROTATE PARTITION o ALTER TABLE ALTER PARTITION no pueden tener
como destino una partición de un espacio de tabla de partición por crecimiento.
v DB2 define siempre implícitamente los espacios XML.
| v Si el espacio de tablas de partición por crecimiento se define explícitamente, el
| espacio de tablas LOB para la primera partición del espacio de tablas de
| partición por crecimiento se define basándose en SQLRULES(DB2) o
| SQLRULES(STD). DB2 define siempre implícitamente cualquier espacio de tabla
| LOB adicional para la nueva partición de crecimiento del espacio de tabla de
| partición por crecimiento, sin tener en cuenta si SQLRULES está en vigor. La
| especificación de la opción SQLRULES(DB2) o SQLRULES(STD) no tiene efecto
| en el espacio de tabla LOB para los espacios de tabla de partición por
| crecimiento definidos implícitamente.
v Un índice sin particionamiento (NPI) siempre utiliza un identificador de registro
(RID) de 5 bytes.
v Los índices particionados no están soportados.
| ″ALTER TABLESPACE″ (Consulta de DB2 SQL)
Espacios de tablas universales particionados por rango:

Los Espacios de tablas universales particionados por rango utiliza una organización de
espacio de tabla segmentado y se basan en rangos de particionamiento.
Un espacio de tabla universal particionado por rango contiene una única tabla, que
la hace similar al espacio de tabla que está exclusivamente particionado. Puede
crear un índice de cualquier tipo en una tabla de un espacio de tabla particionado
por rango.
Puede implementar espacios de tablas universales particionados por rango

especificando las dos palabras clave SEGSIZE y NUMPARTS en una sentencia
CREATE TABLESPACE. Después de crear el espacio de tabla actividades ya
permitidas en espacios de tablas particionados o segmentados exclusivamente se
permiten en el espacio de tabla universal particionado por rango. Puede especificar
rangos de partición para un espacio de tabla universal particionado por rango en
una sentencia CREATE TABLE o CREATE INDEX subsiguiente.
Espacios de tablas de objetos grandes

Los espacios de tablas de objetos grandes (LOB) (también conocidos como espacios de
tablas auxiliares) son necesarios para almacenar datos de objetos grandes como,
por ejemplo, gráficos, vídeo o series de texto muy grandes. Si los datos no caben
totalmente dentro de una página de datos, puede definir una o más columnas
como columnas LOB.
Los objetos LOB pueden hacer algo más que almacenar datos de objetos grandes.
También se pueden definir columnas LOB para datos a los que se accede con poca
frecuencia. Si lo hace, una exploración de espacio de tablas del resto de datos de la
tabla base será potencialmente más rápida porque la exploración suele incluir
menos páginas.
Un espacio de tablas LOB siempre tiene una relación directa con el espacio de
tablas que contiene los valores de columna LOB lógicos. El espacio de tablas que
contiene la tabla con las columnas LOB es, en este contexto, el espacio de tablas base.
Los datos LOB se asocian lógicamente a la tabla base, pero se almacenan
físicamente en una tabla auxiliar que reside en un espacio de tablas LOB. Tan solo
puede existir una tabla auxiliar en un espacio de tablas de objetos grandes. Un
valor LOB puede abarcar varias páginas. Sin embargo, sólo se almacena un valor
LOB por página.
Es necesario tener un espacio de tablas LOB para cada columna LOB que exista en
una tabla. Por ejemplo, si la tabla tiene columnas LOB para resúmenes y
fotografías, necesitará una tabla LOB (y una tabla auxiliar) para cada una de estas
columnas. Si el espacio de tablas base es un espacio de tablas particionado,
necesitará un espacio de tablas LOB para cada LOB de cada partición.
Si el espacio de tablas base no es un espacio de tablas particionado, cada espacio

de tablas LOB se asocia a una columna de LOB de una tabla base. Si el espacio de
tablas base es un espacio de tablas particionado, cada columna de LOB de cada
partición se asocia a un espacio de tablas LOB.
| En un espacio de tablas particionado, puede almacenar más datos LOB en cada

| columna puesto que cada partición debe tener un espacio de tablas LOB. El

| usuario asigna el número de particiones (entre 1 y 4096). La tabla siguiente
| muestra la cantidad aproximada de datos que se pueden almacenar en una
| columna para los diferentes tipos de espacios de tablas.
Tabla 34. Tamaño máximo aproximado de datos LOB en una columna
Máximo de datos LOB (aproximado) en
Tipo de espacio de tablas cada columna
Segmentado 16 TB
Particionado, con NUMPARTS hasta 64 1000 TB
Particionado con DSSIZE, NUMPARTS hasta 254 4000 TB
Particionado con DSSIZE, NUMPARTS hasta 64000 TB
4096
Recomendaciones:
v Considere la definición de columnas de series largas como columnas LOB
cuando una fila no quepa en una página de 32 KB. Utilice las directrices
siguientes para determinar si una columna LOB es la opción adecuada:
– La definición de una columna de serie larga como una columna LOB puede
ser más adecuada si se cumplen las condiciones siguientes:
- Normalmente se ejecutan exploraciones de espacio de tablas en la tabla.
- No se hace referencia con frecuencia a la columna de serie larga.
- La eliminación de la columna de serie larga de la tabla base es posible que
mejore el rendimiento de las exploraciones de espacio de tablas.
– Se almacenan físicamente los LOB en otro espacio de tablas. Por lo tanto, el
rendimiento de inserciones, actualizaciones y recuperaciones de series largas
puede ser mejor para series no LOB que para series LOB.
| v Considere la especificación de una agrupación de almacenamientos intermedios
| separada para datos de objetos grandes.
″Factores para determinar el tamaño de página de un espacio de tabla LOB″
(DB2 Administration Guide)
Espacios de tablas XML

Un espacio de tablas XML almacena la tabla XML.
Un espacio de tablas XML se crea implícitamente cuando se añade una columna

XML a una tabla base. Si la tabla base está particionada, existe un espacio de tablas
particionado para cada columna de datos XML. Un espacio de tablas XML siempre
está asociado al espacio de tablas que contiene el valor de columna XML lógico. En
este contexto, el espacio de tablas que contiene la tabla con la columna XML se
denomina espacio de tablas base.

| ″Cómo DB2 crea implícitamente un espacio de tabla XML″ (DB2 Administration
| Guide)
Cómo DB2 crea implícitamente un espacio de tablas

Tal como sucede con los grupos y bases de datos de almacenamiento DB2, no
necesita crear un espacio de tabla antes de crear una tabla, a menos que esté
definiendo una tabla temporal declarada o gestionando todos sus conjuntos de
datos.
| Cuando utiliza la sentencia CREATE TABLE, DB2 le genera un espacio de tabla.

| Sin embargo, DB2 generará únicamente un espacio de tabla si utiliza la sentencia
| CREATE TABLE sin especificar un nombre de espacio de tabla existente. Si la tabla
| contiene una columna LOB y SQLRULES son STD, DB2 también creará el espacio
| de tabla LOB, la tabla auxiliar y el índice auxiliar. En este caso, DB2 utiliza el
| grupo de almacenamiento predeterminado, SYSDEFLT.
Si crea un espacio de tabla implícitamente, DB2 utilizará valores predeterminados

para los atributos de asignación del espacio. Los valores predeterminados de
PRIQTY y SECQTY especifican la asignación de espacio para el espacio de tabla. Si
el valor del parámetro de subsistema TSQTY es no cero, determina los valores
predeterminados para PRIQTY y SECQTY. Si el valor de TSQTY es cero, los valores
predeterminados para PRIQTY y SECQTY se determinan según se describe en la
sentencia CREATE TABLESPACE.
Cuando no especifica el nombre de espacio de tabla en una sentencia CREATE

TABLE (y el espacio de tabla se crea implícitamente), DB2 deriva el nombre de
espacio de tabla del nombre de su tabla según las siguientes reglas:
v El nombre de espacio de tabla es el mismo que el nombre de tabla si se aplican
las siguientes condiciones:
– Ningún otro espacio de tabla ni espacio de índice de la base de datos contiene
ya ese nombre.
– El nombre de la tabla no tiene más de ocho caracteres.
– Los caracteres son todos alfanuméricos y el primer carácter no es un dígito.
v Si existe otro espacio de tabla en la base de datos que ya contiene el mismo
nombre que la tabla, DB2 asignará un nombre del formulario xxxxnyyy, donde
xxxx corresponderá a los primeros cuatro caracteres del nombre de la tabla y
nyyy será un único dígito y tres letras que garantizan la exclusividad.
DB2 almacena este nombre en el DB2 catálogo de la tabla

SYSIBM.SYSTABLESPACE, junto con el resto de nombres de espacios de tabla.
| CómoDB2 crea implícitamente un espacio de tabla XML

| Cuando cree una columna XML en una tabla, DB2 crea implícitamente un espacio
| de tabla XML y una tabla XML para almacenar los datos XML y un ID de nódulo.
| Cada columna XML tiene su propio espacio de tablas. El espacio de tablas XML no
| tiene teclas de limitación. Los datos XML residen en el número de partición de la
| fila de base.

| Las tablas que contienen columnas XML también tienen los objetos siguientes
| creados implícitamente:
| v Una columna oculta para almacenar la ID de documento.
| La ID de documento es un valor que genera DB2 y que identifica de forma
| exclusiva una fila. La ID de documento se utiliza para identificar los
| documentos en la tabla XML. La ID de documento es habitual en todas las
| columnas XML y su valor es exclusivo en la tabla.
| v Un índice exclusivo en la ID de documento (índice de ID de documento).
| El índice de ID de documento apunta al RID de la tabla base. Si el espacio de
| tabla base está particionado, el índice de ID de documento será un índice
| alternativo no particionado (NPSI).
| v La tabla base tendrá una columna de indicador para cada columna XML que
| contenga un bit nulo, no válido o varios bytes reservados.
| El espacio de tabla hereda varios de los atributos del espacio de tabla base, como
| por ejemplo:
| v LOG
| v CCSID
| v LOCKMAX
| Si el espacio de tabla base es un espacio de tabla partition-by-growth, la DSSIZE

| del espacio de tabla XML será 4GB. De lo contrario, DSSIZE del espacio de tabla
| XML se basará en una combinación de la DSSIZE y del tamaño de página del
| espacio de tabla base.
| Estructura de almacenamiento para datos XML

| La estructura de almacenamiento para datos XML es similar a la estructura de
| almacenamiento para datos LOB.
| Tal como en los datos LOB, la tabla que contiene una columna XML(la tabla base)
| está en un espacio de tabla diferente a la tabla que contiene los dato s XML.
| La estructura de almacenamiento depende del tipo de espacio de tabla que

| contiene la tabla base.
| La tabla siguiente describe la organización del espacio de tabla para los datos
| XML.
| Tabla 35. La organización de los espacios de tabla base corresponden a los espacios de
| tabla XML
| Organización del espacio de XOrganización del
| tabla base espacio de tabla XML Notas
| Simple Partition-by-growth
| universal
| Segmentado Partition-by-growth
| universal
| Particionado Range-partitioned Si la fila de una tabla base se
| universal desplaza a una partición nueva, el
| documento XML también se
| desplaza a una nueva partición.

| Tabla 35. La organización de los espacios de tabla base corresponden a los espacios de
| tabla XML (continuación)
| Organización del espacio de XOrganización del
| tabla base espacio de tabla XML Notas
| Range-partitioned universal Range-partitioned Si la fila de una tabla base se
| universal desplaza a una partición nueva, el
| documento XML también se
| desplaza a una nueva partición.
| Partition-by-growth universal Partition-by-growth Un documento XML se puede
| universal distribuir a más de una partición. El
| espacio de tabla base y el espacio de
| tabla XML se amplían de forma
| independiente.
|
| La siguiente figura demuestra la relación entre los espacios de tabla segmentados

| para las tablas base con columnas XML y entre los espacios de la tabla XML y las
| tablas. Las relaciones son similares a los espacios de tabla base simples y a los
| espacios de tabla base partition-by-growth.
|
Índice de ID Tabla para

de nodo XMLCOL1
Columnas:
DOCID
Índice de id de Índice MIN_NODEID
documento XML XMLDATA
Espacio tabla partición
por crecimiento para
XMLCOL1
Tabla
base
Columnas:
DB2_GENERATED-
DOC_ID_FOR_XML Índice de ID Tabla para
XMLCOL1 de nodo XMLCOL2
XMLCOL2 Columnas:
DOCID
Espacio de tabla Índice MIN_NODEID
base segmentada XML XMLDATA
Espacio tabla partición
por crecimiento para
XMLCOL2
Figura 36. Estructura de almacenamiento XML para una tabla base en un espacio de tabla segmentada
| La siguiente figura demuestra la relación entre los espacios de tabla segmentados

| para las tablas base con columnas XML y y con las tablas y espacios de tablas XML
| correspondientes. Las relaciones son similares a los espacios de tabla base
| range-partitioned universal
|

Índice Id documento Índice Id nodo
(no-particionado) (no-particionado, ampliado)
Índice XML
Tabla base
Partición 1
Columnas: Columnas:
DB2_GENERATED- Tabla XML DOCID
DOC_ID_FOR_XML Partición 1 MIN_NODEID
XMLCOL1 XMLDATA
XMLCOL2 Columnas:
Tabla XML DOCID
Partición 2 MIN_NODEID
Tabla base
XMLDATA
Partición 2
Columnas: Espacio de tabla particionado por
DB2_GENERATED- rango con particiones para XMLCOL1
DOC_ID_FOR_XML
XMLCOL1
XMLCOL2
Espacio de tabla base Índice Id nodo
particionada con dos (no-particionado, ampliado)
particiones. La tabla
tiene dos columnas XML.
Índice XML
Columnas:
Tabla XML DOCID
XMLDATA
Columnas:
Tabla XML DOCID
XMLDATA
Espacio de tabla particionado por
rango con particiones para XMLCOL1
Figura 37. Estructura de almacenamiento XML para una tabla base en un espacio de tabla particionada
| Cuando crea una tabla con columnas XML o MODIFICA una tabla para añadir
| columnas XML, el servidor de bases de datos DB2 crea implícitamente los
| siguientes objetos:
| v Espacio de tablas y tabla para cada columna XML. Los datos de una columna
| XML se almacenan en la tabla correspondiente.
| DB2 crea el espacio de tabla XML y la tabla en la misma base de datos donde
| está la tabla que contiene la columna XML (la tabla base). El espacio de tabla
| XML está en el codificado UTF-8 Unicode.
| v Una columna en la tabla base con el nombre
| DB2_GENERATED_DOCID_FOR_XML.

| DB2_GENERATED_DOCID_FOR_XML contienen un identificador único de
| documento para las columnas XML de una fila.Una columna
| DB2_GENERATED_DOCID_FOR_XML se utiliza para todas las columnas XML.
| La columna DB2_GENERATED_DOCID_FOR_XML tiene el atributo
| GENERATED ALWAYS. Por lo tanto, el valor de esta columna no podrá ser
| NULL.
| v Una columna con indicador XML en la tabla base para cada columna XML.
| v Un índice en la columna DB2_GENERATED_DOCID_FOR_XML.
| Este índice se conoce como un índice de ID de documento.
| v Un índice en cada tabla XML que DB2 utiliza para mantener el orden del
| documento.
| Este índice se conoce como índice de ID de nódulo. El índice de ID de nódulo es
| un índice ampliado que no se puede particionar.
| Puede realizar operaciones SQL limitadas, como las siguientes, en los objetos
| creados implícitamente:
| v Altere los siguientes atributos en el espacio de tabla XML
| – SEGSIZE
| – BUFFERPOOL
| – STOGROUP
| – PCTFREE
| – GBPCACHE
| v Modifique cualquiera de los atributos del índice de ID de documento o del
| índice de ID de nódulo, excepto estos:
| – CLUSTER
| – PADDED
| – Número de columnas (ADD COLUMN no está permitido)
| Consulte los temas ALTER TABLE, ALTER TABLESPACE y ALTER INDEX para
| obtener una lista completa de las operaciones que puede realizar con estos objetos.
Asignación de espacios de tablas a almacenamiento físico

Puede almacenar espacios de tablas y espacios de índice en almacenamiento
gestionado por el usuario, almacenamiento gestionado por SMS o en grupos de
almacenamiento gestionados por DB2. (Un grupo de almacenamiento es un conjunto
de volúmenes de disco.)
Si no utiliza SMS, debe especificar los grupos de almacenamiento de DB2 cuando

cree espacios de tablas o espacios de índice. DB2 asigna espacio para estos objetos
desde el grupo de almacenamiento especificado. Puede asignar diferentes
particiones del mismo espacio de tablas a diferentes grupos de almacenamiento.
| Recomendación: Utilice productos de la familia de IBM Storage Management

| Subsystem (SMS) como, por ejemplo, Data Facility SMS (DFSMS), para gestionar
| algunos o todos los conjuntos de datos. Las organizaciones que utilizan SMS para
| gestionar conjuntos de datos de DB2 pueden definir grupos de almacenamiento
| con la cláusula VOLUMES(*). También puede asignar atributos de clase de gestión,
| clase de datos y clase de almacenamiento. Como resultado, SMS asigna un
| volumen a los espacios de tablas y los espacios de índice de dicho grupo de
| almacenamiento.
La figura siguiente muestra cómo funcionan los grupos de almacenamiento junto

con las diferentes estructuras de datos de DB2.

Figura 38. Jerarquía de estructuras de DB2
| Para crear un grupo de almacenamiento de DB2, utilice la sentencia de SQL

| CREATE STOGROUP. Utilice la cláusula VOLUMES(*) para especificar la clase de
| gestión de SMS (MGMTCLAS), la clase de datos de SMS (DATACLAS) y la clase
| de almacenamiento de SMS (STORCLAS) para el grupo de almacenamiento de
| DB2.
Después de definir un grupo de almacenamiento, DB2 almacena información sobre

él en el catálogo de DB2. La tabla de catálogo SYSIBM.SYSSTOGROUP tiene una
fila para cada grupo de almacenamiento y SYSIBM.SYSVOLUMES tiene una fila
para cada volumen del grupo.
El proceso de instalación de DB2 incluye la definición de un grupo de

almacenamiento por omisión, SYSDEFLT. Si tiene autorización para ello puede
definir tablas, índices, espacios de tablas y bases de datos. DB2 utiliza SYSDEFLT
para asignar el almacenamiento auxiliar necesario. DB2 almacena información
sobre SYSDEFLT y todos los otros grupos de almacenamiento en las tablas de
catálogo SYSIBM.SYSSTOGROUP y SYSIBM.SYSVOLUMES.
Recomendación: Utilice grupos de almacenamiento siempre que pueda de forma

explícita o implícita (utilizando el grupo de almacenamiento por omisión). En

algunos casos, las organizaciones necesitan mantener un control más estricto sobre
el almacenamiento físico de tablas e índices. Estas organizaciones optan por
gestionar sus propios conjuntos de datos definidos por el usuario en lugar de
utilizar grupos de almacenamiento. Debido a que este proceso es complejo, esta
información no describe los detalles.
Ejemplo: Considere la sentencia CREATE STOGROUP siguiente:

CREATE STOGROUP MYSTOGRP
VOLUMES (*)
VCAT ALIASICF;
Esta sentencia crea el grupo de almacenamiento MYSTOGRP. El asterisco (*) de la

cláusula VOLUMES indica que SMS debe gestionar el grupo de almacenamiento.
La cláusula VCAT identifica ALIASICF como el nombre o alias del catálogo del
recurso de catálogos integrados que el grupo de almacenamiento debe utilizar. El
catálogo del recurso de catálogos integrados almacena entradas para todos los
conjuntos de datos que DB2 crea en nombre de un grupo de almacenamiento.
IBM Storage Management Subsystem
DB2 for z/OS incluye las posibilidades de Storage Management Subsystem (SMS).
Un producto clave de la familia de SMS es Data Facility Storage Management
Subsystem (DFSMS). DFSMS puede gestionar automáticamente todos los conjuntos
de datos que DB2 utiliza y necesita. Si utiliza DFSMS para gestionar los conjuntos
de datos, el resultado es una carga de trabajo reducida para los administradores de
almacenamiento y los administradores de bases de datos de DB2.
Puede beneficiarse de las ventajas siguientes al utilizar DFSMS:

v Asignación de conjuntos de datos simplificada
v Control de asignación mejorado
v Gestión del rendimiento mejorado
v Gestión de espacio de disco automatizada
v Gestión de disponibilidad de los datos mejorada
v Movimiento de datos simplificado
Los administradores de bases de datos de DB2 pueden utilizar DFSMS para

conseguir todos sus objetivos para la ubicación y el diseño de conjuntos de datos.
Para utilizar satisfactoriamente DFSMS, los administradores de almacenamiento y
los administradores de bases de datos de DB2 deben trabajar conjuntamente para
asegurar que se satisfagan las necesidades de ambos grupos.
“Grupos de almacenamiento de DB2” en la página 36
″CREATE STOGROUP″ (Consulta de DB2 SQL)
Creación de índices
Esta información describe cómo se utilizan los índices y qué debe considerarse al
crear índices.
| Los índices proporcionan un acceso eficaz a los datos. Cuando crea una tabla que
| contiene una clave primaria o una restricción exclusiva, debe crear un índice
| exclusivo para la clave primaria y para cada restricción exclusiva. DB2 marca la

| definición de tabla como incompleta hasta la creación explícita de los índices
| forzados necesarios, que se pueden crear implícitamente según si el espacio de
| tablas se ha creado implícitamente, el procesador de esquemas o el registro especial
| CURRENT RULES. Si los índices necesarios se crean implícitamente, la definición
| de tabla no se marca como incompleta.
También puede optar por utilizar índices debido a los requisitos de acceso.
Tenga en cuenta que la utilización de índices implica un intercambio. Un mayor

número de índices puede mejorar simultáneamente el rendimiento del acceso de
una transacción determinada y necesitar proceso adicional para insertar, actualizar
y suprimir claves de índice.
Después de crear un índice, DB2 mantiene el índice, pero puede realizar el

mantenimiento necesario como, por ejemplo, su reorganización o recuperación,
según convenga.
Tipos de índices
Puede utilizar índices para mejorar el rendimiento del acceso a datos. Los distintos
tipos de índices tienen características diferentes que deben considerarse cuando se
crea un tipo determinado.
| Normalmente el tipo de índice que debe definirse se determina después de definir

| una tabla.
Un índice puede tener varias características diferentes. Las características de

índices se clasifican en dos categorías amplias: características generales que se
aplican a los índices de todas las tablas y características específicas que se aplican
únicamente a los índices de tablas particionadas. La tabla siguiente resume estas
categorías.
Tabla 36. Tipos de índices para espacios de tablas generales, particionados y universales
Tipo de tabla o de
espacio de tablas Tipo de índice
General (se aplica a v Índices exclusivos
todos los índices)
v Índices de agrupación en clúster
v Índices rellenados
v Índices no rellenados
| v Índice en expresión
| v Índices XML
| v Índices comprimidos
Particionado v Índices de particionamiento
| v Índices secundarios particionados de datos
| v Índices secundarios no particionados
|| Universal v Índices de particionamiento (sólo universal particionado por rango)
| v Índices secundarios particionados de datos (sólo universal
| particionado por rango)
| v Índices secundarios no particionados

Cómo pueden ayudar los índices a evitar clasificaciones
DB2 puede utilizar índices para evitar clasificaciones al procesar consultas con la
cláusula ORDER BY.
Cuando una consulta contiene una cláusula ORDER BY, DB2 busca índices que
cumplan el orden en la consulta. Para que DB2 pueda utilizar un índice para
acceder a datos ordenados, debe definir un índice en las mismas columnas tal
como se especifica en la cláusula ORDER BY.
Exploración de índice hacia adelante
Para que DB2 utilice una exploración de índice hacia adelante, el orden
debe ser exactamente igual que en la cláusula ORDER BY.
Exploración de índice hacia atrás
Para que DB2 utilice una exploración de índice hacia atrás, el orden debe
ser exactamente contrario al que se solicita en la cláusula ORDER BY.
Ejemplo 1: Por ejemplo, si define un índice especificando DATE DESC,

TIME ASC como los nombres de columna y orden, DB2 puede utilizar este mismo
índice para las siguientes cláusulas ORDER BY:
v Exploración hacia adelante para ORDER BY DATE DESC, TIME ASC
v Exploración hacia atrás para ORDER BY DATE ASC, TIME DESC
No es necesario crear dos índices para las dos cláusulas ORDER BY. DB2 puede
utilizar el mismo índice para la exploración de índice hacia adelante y la
exploración de índice hacia atrás.
| Además de exploraciones hacia adelante y hacia atrás, existe la opción de crear

| índices con un orden seudoaleatorio. Esta opción de orden es útil cuando
| inserciones ascendentes o zonas activas causan contención dentro de los índices.
| Los índices creados con la opción RANDOM no dan soporte a exploraciones de
| rango. En cambio, sí dan soporte a búsquedas de igualdad.
Ejemplo 2: Suponga que la consulta incluye una cláusula WHERE con un

predicado con el formato COL=constante. Por ejemplo:
...
WHERE CODE = 'A'
ORDER BY CODE, DATE DESC, TIME ASC
DB2 puede utilizar cualquiera de las claves de índice siguientes para cumplir el
orden:
v CODE, DATE DESC, TIME ASC
v CODE, DATE ASC, TIME DESC
v DATE DESC, TIME ASC
v DATE ASC, TIME DESC
DB2 puede ignorar la columna CODE de la cláusula ORDER BY y el índice debido

a que el valor de la columna CODE de la tabla de resultados de la consulta no
influye en el orden de los datos. Si se incluye la columna CODE, puede estar en
cualquier posición en la cláusula ORDER BY y en el índice.

Claves de índice
La utilidad de un índice depende del diseño de su clave, que se puede crear
cuando se crea el índice.
| Una clave de índice es el conjunto de columnas o expresiones que se obtiene de un

| conjunto de columnas de una tabla que se utiliza para determinar el orden de las
| entradas de índice. Una tabla puede tener más de un índice y una clave de índice
| puede utilizar una o más columnas. Una clave de índice es una columna o una
| colección de columnas ordenadas en las que se define un índice. Como candidatas
| de clave son adecuadas las columnas o expresiones que se utilizan con frecuencia
| en operaciones que seleccionan, unen, agrupan y ordenan datos.
No es necesario que todas las claves de índice sean exclusivas. Por ejemplo, un
índice en la columna SALARY de la tabla EMP permite duplicados puesto que
varios empleados pueden ganar el mismo salario.
| La utilidad de un índice depende de su clave. Las columnas y expresiones que se

| utilizan con frecuencia en operaciones de selección, unión, agrupación y
| ordenación son unas candidatas de clave adecuadas.
Una clave compuesta es una clave que se crea en entre 2 y 64 columnas.
Consejo: En general, intente crear un índice que sea selectivo ya que cuanto más
selectivo es un índice, más eficaz es. Un índice eficaz contiene varias columnas, se
ordena en la misma secuencia que la sentencia de SQL y se utiliza con frecuencia
en sentencias de SQL.
La lista siguiente identifica algunos puntos que debería recordar al definir claves
de índice.
| v Actualice un índice después de actualizar, insertar o suprimir columnas de
| datos.
v Defina el menor número posible de índices en una columna que se actualice con
frecuencia ya que cada cambio realizado en los datos de la columna debe
reflejarse en cada índice.
v Considere utilizar una clave compuesta, que puede resultar más útil que una
clave en una única columna cuando la comparación es para igualdad. Un único
índice de varias columnas es más eficaz cuando la comparación es para igualdad
y están disponibles las columnas iniciales. Sin embargo, para comparaciones más
generales como, por ejemplo, A > valor AND B > valor, varios índices pueden
resultar más eficaces.
v Mejore el rendimiento utilizando índices.
Ejemplo 1: En este ejemplo se crea un índice exclusivo en la tabla EMPPROJACT.

Se define una clave compuesta en dos columnas, PROJNO y STDATE.
CREATE UNIQUE INDEX XPROJAC1
ON EMPPROJACT
(PROJNO ASC,
. STDATE ASC)
.
.
Ejemplo 2: Esta clave compuesta es útil cuando no es necesario buscar

información de proyectos por fecha de inicio. Considere una sentencia SELECT con
la siguiente cláusula WHERE:
WHERE PROJNO='MA2100' AND STDATE='2004-01-01'

Esta sentencia SELECT puede ejecutarse más eficazmente si se definen índices
separados en PROJNO y STDATE.
“Análisis del rendimiento de consultas y aplicaciones” en la página 265
Atributos de índices generales

Normalmente el tipo de índice que debe definirse se determina después de definir
un espacio de tablas. Un índice puede tener numerosos atributos diferentes.
Los atributos de índices se clasifican en dos categorías amplias: atributos generales

que se aplican a los índices de todas las tablas y atributos específicos que se
aplican únicamente a los índices de tablas particionadas. La tabla siguiente resume
estas categorías.
Tabla 37. Atributos de índices
Tipo de tabla o de espacio
de tablas Atributo de índice
Cualquiera v Exclusivo o no exclusivo
v Agrupado en clústeres o no agrupado en clústeres
v Rellenado o no rellenado
Particionado v De particionamiento
v Secundario
Este tema explica los tipos de índices que se aplican a todas las tablas. Los índices
que se aplican únicamente a tablas particionadas se tratan aparte.
“Atributos de índices de tablas particionadas” en la página 225
Índices exclusivos
DB2 utiliza índices exclusivos para asegurarse de que no se almacenen valores de
clave idénticos en una tabla.
Cuando crea una tabla que contiene una clave primaria, debe crear un índice
exclusivo para dicha tabla en la clave primaria. DB2 marca la tabla como no
disponible hasta la creación explícita de los índices necesarios.
Restricción del acceso con índices exclusivos
También puede utilizar índices para cumplir requisitos de acceso.
Ejemplo 1: Un candidato apropiado para un índice exclusivo es la columna

EMPNO de la tabla EMP. La figura siguiente muestra un conjunto reducido de
filas de la tabla EMP e ilustra el índice exclusivo en EMPNO.

Índice en la
tabla EMP Tabla EMP
EMPNO Pag. Fila EMPNO LASTNAME JOB DEPT
1 000220 LUTZ DES D11
000030 1 2 000330 LEE FLD E21
000060 3 000030 KWAN MGR C01
000140
000200 1 200140 NATZ ANL C01
000220 2 2 000320 RAMLAL FLD E21
000330 3 000200 BROWN DES D11
200140
000320 1 200340 ALONZO FLD E21
200340 3 2 000140 NICHOLLS SLS C01
3 000060 STERN MGR D11
Figura 39. Índice exclusivo en la columna EMPNO
DB2 utiliza este índice para representar la inserción de una fila de la tabla EMP si
su valor de EMPNO coincide con el de una fila existente. La figura anterior ilustra
la relación entre cada valor de EMPNO en el índice y el número de página y fila
correspondientes. DB2 utiliza el índice para ubicar la fila para el empleado 000030,
por ejemplo, en la fila 3 de la página 1.
Si no desea valores duplicados en la columna de clave, cree un índice exclusivo

utilizando la cláusula UNIQUE de la sentencia CREATE INDEX.
Ejemplo 2: La tabla DEPT no permite ID de departamento duplicados. La creación

de un índice exclusivo, como se muestra en el ejemplo siguiente, evita los valores
duplicados.
CREATE UNIQUE INDEX MYINDEX
ON DEPT (DEPTNO);
El nombre de índice es MYINDEX y la columna indexada es DEPTNO.
| Si una tabla tiene una clave primaria (como en el caso de la tabla DEPT), sus
| entradas deben ser exclusivas. DB2 impone esta exclusividad mediante la
| definición de un índice en las columnas de clave primaria, con las columnas de
| índice en el mismo orden que las columnas de clave primaria.
Antes de crear un índice exclusivo en una tabla que ya contiene datos, asegúrese
de que ningún par de filas tenga el mismo valor de clave. Si DB2 encuentra un
valor duplicado en un conjunto de columnas de clave para un índice exclusivo,
DB2 emite un mensaje de error y no crea el índice.
Si una clave de índice permite nulos para todos o algunos de sus valores de
columna, puede utilizar la cláusula WHERE NOT NULL para asegurar que los
valores no nulos de la clave de índice sean exclusivos.
Los índices exclusivos son una parte importante de implementación de

restricciones de referencia entre las tablas de la base de datos de DB2. No puede
definir una clave foránea a menos que ya exista la correspondiente clave primaria
y tenga un índice exclusivo definido para ésta.

Cuándo no debe utilizarse un índice exclusivo
En algunos casos, es posible que no desee utilizar un índice exclusivo. Puede crear
un índice por omisión para mejorar el rendimiento del acceso a datos cuando los
valores de las columnas del índice no son necesariamente exclusivos.
Cuando crea un índice por omisión, DB2 le permite entrar valores duplicados en
una columna de clave.
Por ejemplo, suponga que más de un empleado se llama David Brown. Considere
un índice definido en las columnas FIRSTNME y LASTNAME de la tabla EMP.
CREATE INDEX EMPNAME ON EMP (FIRSTNME, LASTNAME);
Es un ejemplo de un índice que puede contener entradas duplicadas.
Consejo: No cree este tipo de índice en tablas muy pequeñas puesto que es más
eficaz utilizar exploraciones de las tablas que utilizar índices.
Índices no exclusivos
Puede utilizar índices no exclusivos para mejorar el rendimiento del acceso a datos
cuando los valores de las columnas del índice no son necesariamente exclusivos.
Recomendación: No cree índices no exclusivos en tablas muy pequeñas puesto

que es más eficaz utilizar exploraciones de las tablas que utilizar índices.
Para crear índices no exclusivos, utilice la sentencia SQL CREATE INDEX. Para
índices no exclusivos, DB2 permite a los usuarios y programas entrar valores
duplicados en una columna de clave.
Ejemplo: Suponga que más de un empleado se llama David Brown. Considere un

índice definido en las columnas FIRSTNME y LASTNAME de la tabla EMP.
CREATE INDEX EMPNAME
ON EMP (FIRSTNME, LASTNAME);
Este índice es un ejemplo de un índice no exclusivo que puede contener entradas

duplicadas.
Índices de agrupación en clúster

Un índice de agrupación en clúster determina cómo se ordenan físicamente (agrupan
en clúster) las filas en un espacio de tablas. Los índices de agrupación en clúster
proporcionan ventajas de rendimiento significativas en algunas operaciones, en
especial en las que implican muchos registros. Por ejemplo, las operaciones de
agrupación y ordenación y las comparaciones que no sean iguales se benefician de
los índices de agrupación en clúster.
Puede definir un índice de agrupación en clúster en un espacio de tablas

particionado o en un espacio de tablas segmentado. En un espacio de tablas
particionado, un índice de agrupación en clúster puede ser un índice de
particionamiento o un índice secundario. Si un índice de clúster en una tabla
particionada no es un índice de particionamiento, las filas se ordenan en la
secuencia de clúster en cada partición de datos en lugar de dividirse entre las

particiones. (Antes de la Versión 8 de DB2 UDB para z/OS, el índice de
particionamiento era necesario que fuera el índice de agrupación en clúster.
| Restricción: Un índice de una expresión o un índice XML no puede ser un índice

| de agrupación en clúster.
Cuando una tabla tiene un índice de agrupación en clúster , una sentencia INSERT
hace que DB2 inserte los registros lo más cerca posible del orden de sus valores de
índice. El primer índice que se define en la tabla sirve implícitamente como índice
de agrupación en clúster a menos que el usuario especifique explícitamente
CLUSTER al crear o modificar otro índice. Por ejemplo, si el usuario define
primero un índice exclusivo en la columna EMPNO de la tabla EMP, DB2 inserta
filas en la tabla EMP en el orden del número de identificación de empleado a
menos que el usuario defina explícitamente otro índice para que sea el índice de
agrupación en clúster.
Aunque una tabla puede tener varios índices, sólo un índice puede ser un índice
de agrupación en clúster. Si el usuario no define ningún índice de agrupación en
clúster para una tabla, DB2 reconoce el primer índice creado en la tabla como el
índice de agrupación en clúster implícito cuando ordena filas de datos.
Consejo:
v Defina siempre un índice de agrupación en clúster. De lo contrario, es posible
que DB2 no elija la clave que se prefiere para el índice.
v Defina la secuencia de un índice de agrupación en clúster para dar soporte al
proceso de un gran volumen de datos.
Utilice la cláusula CLUSTER de la sentencia CREATE INDEX o ALTER INDEX

para definir un índice de agrupación en clúster.
Ejemplo: Suponga que a menudo necesita reunir información sobre empleados por
departamento. En la tabla EMP puede crear un índice de agrupación en clúster en
la columna DEPTNO.
CREATE INDEX DEPT_IX
ON EMP
(DEPTNO ASC)
CLUSTER;
Como resultado, probablemente todas las filas para el mismo departamento estarán
cerca. Generalmente DB2 puede acceder a todas las filas para dicho departamento
en una única lectura. (La utilización de un índice de agrupación en clúster no
garantiza que todas las filas para el mismo departamento se almacenen en la
misma página. El almacenamiento real de las filas depende del tamaño de las filas,
del número de filas y de la cantidad de espacio libre disponible. Asimismo algunas
páginas pueden contener filas para más de un departamento.)
La figura siguiente muestra un índice de agrupación en clúster en la columna

DEPT de la tabla EMP; sólo se muestra un subconjunto de las filas.

Figura 40. Índice de agrupación en clúster en la tabla EMP
Suponga que posteriormente crea un índice de agrupación en clúster en la misma

tabla. En este caso, DB2 lo identifica como el índice de agrupación en clúster pero
no reorganiza los datos que ya existen en la tabla. La organización de los datos
permanece tal como estaba con el índice sin agrupación en clúster original creado.
Sin embargo, cuando el programa de utilidad REORG reorganiza el espacio de
tablas, DB2 agrupa en clúster los datos según la secuencia del nuevo índice de
agrupación en clúster, Por lo tanto, si sabe que desea un índice de agrupación en
clúster, debe definir el índice de agrupación en clúster antes de cargar la tabla. Si
esto no es posible, debe definir el índice y a continuación reorganizar la tabla. Si
crea o descarta y vuelve a crear un índice de agrupación en clúster después de
cargar la tabla, los cambios entran en vigor después de una reorganización
posterior.
Índices rellenados o no rellenados

Las opciones NOT PADDED y PADDED de las sentencias CREATE INDEX y
ALTER INDEX especifican cómo se almacenan las columnas de serie de longitud
variable en un índice.
Puede elegir no rellenar columnas de serie de longitud variable del índice hasta su
longitud máxima (valor por omisión) o puede elegir rellenarlas.
| Si especifica la cláusula NOT PADDED en una sentencia CREATE INDEX,

| las columnas de longitud variable de la clave de índice no se rellenan a su
| longitud máxima. Si una clave de índice existente incluye columnas de longitud
| variable, puede considerar la modificación del índice para utilizar la cláusula NOT
| PADDED. Sin embargo, la utilización de la cláusula NOT PADDED en la sentencia
| ALTER INDEX para cambiar el relleno coloca el índice en el estado de pendiente
| de REBUILD (RBDP). Debe volver a crear el índice para eliminar el estado de
| RBDP.
La utilización de la cláusula NOT PADDED tiene las ventajas siguientes:

v DB2 puede utilizar acceso de sólo índice para las columnas de longitud variable
de la clave de índice, lo cual mejora el rendimiento.

v DB2 almacena únicamente datos reales, lo cual reduce los requisitos de
almacenamiento para la clave de índice.
Sin embargo, la utilización de la cláusula NOT PADDED también puede tener las
desventajas siguientes:
v Las comparaciones de claves de índice son más lentas porque DB2 debe
comparar cada par de columnas de longitud variable correspondientes en lugar
de comparar la clave entera cuando se rellenan las columnas a su longitud
máxima.
v DB2 almacena un campo con una longitud de 2 bytes adicional para cada
columna de longitud variable. Por lo tanto, si la longitud del relleno (hasta la
longitud máxima) es menor que o igual a 2 bytes, los requisitos de
almacenamiento en efecto podrían ser mayores para las columnas de longitud
variable que no se rellenan.
Consejo: Utilice la cláusula NOT PADDED para implementar acceso de sólo índice
si la aplicación normalmente accede a columnas de longitud variable.
Para controlar si las columnas de longitud variable se rellenan por omisión, utilice
la opción PAD INDEXES BY DEFAULT en el panel de instalación DSNTIPE.
| Índice en expresión
| Un índice en expresión le permite crear un índice en una expresión general. Puede
| mejorar el rendimiento de las consultas si el optimizador elige el índice que se crea
| en la expresión.
| Utilice un índice en expresión cuando desee una evaluación eficaz de consultas que
| impliquen una expresión de columna. A diferencia de los índices simples, en los
| que la clave de índice consta de una concatenación de una o más columnas de
| tabla especificadas, los valores de clave de índice no son exactamente iguales que
| los valores de las columnas de tabla. Las expresiones especificadas transforman los
| valores.
| Puede crear el índice utilizando la sentencia CREATE INDEX. Si se crea un índice

| con la opción UNIQUE, la exclusividad se impone en los valores almacenados en
| el índice, no en los valores de columna originales.
| Referencia relacionada
| Compresión de índices
| Puede reducir la cantidad de espacio que ocupa un índice en disco comprimiendo
| el índice.
| La cláusula COMPRESS YES/NO de la sentencias ALTER INDEX y CREATE

| INDEX le permite comprimir los datos de un índice y reducir el tamaño del índice
| en el disco. Sin embargo, la compresión de índices depende mucho de los datos y
| algunos índices pueden contener datos que no producen un ahorro de espacio
| significativo. Los índices comprimidos también pueden utilizar más
| almacenamiento real y virtual que los índices sin comprimir. La cantidad de
| almacenamiento real y virtual adicional necesario depende de la proporción de
| compresión que se utiliza para las claves comprimidas, la cantidad de espacio libre
| y la cantidad de espacio utilizado por la correlación de claves.

| Puede elegir entre tamaños de página de agrupación de almacenamientos
| intermedios de 8 KB a 16 KB para el índice. Utilice el programa de utilidad
| DSN1COMP en los índices existentes para calcular el tamaño de página apropiado
| para índices nuevos. La elección de una agrupación de almacenamientos
| intermedios de 16 KB en lugar de una agrupación de almacenamientos intermedios
| de 8 KB ofrece una proporción de compresión potencialmente más elevada, pero
| esta opción también aumenta la posibilidad de utilizar más almacenamiento. Las
| estimaciones del ahorro de espacio de índice del programa de utilidad
| DSN1COMP, tanto en los datos de índice verdaderos o en datos de índice
| similares, no son exactas.
| Si se necesitan E/S para leer un índice, es probable que la degradación de CPU

| para una exploración de índice sea relativamente pequeña, pero la degradación de
| CPU para un acceso aleatorio es probable que sea muy significativa.
| La degradación de CPU para supresiones y actualizaciones es significativa incluso

| si no es necesaria ninguna E/S.
| Referencia relacionada
| Atributos de índices XML

| Puede crear un índice en cualquier columna XML para una evaluación eficaz de
| expresiones Xpath con el fin de mejorar el rendimiento durante consultas en
| documentos XML.
| A diferencia de los índices relacionales simples en los cuales las claves de índice
| están formadas por una o más columnas de tabla especificadas, un índice XML
| utiliza una expresión Xpath determinada para indexar vías de acceso y valores en
| documentos XML almacenados en una única columna XML.
| En un índice XML, en realidad tan solo se indexan los nodos de atributo, los nodos
| de texto o los nodos de elemento que coinciden con la expresión de vía de acceso
| XML. Debido a que un índice XML tan solo indexa los nodos que coinciden con la
| Xpath específica y no el mismo documento, se añaden dos campos de clave más al
| índice para formar la clave de índice compuesto. Los campos de clave adicionales,
| que identifican el documento XML y la posición del nodo en el documento, se
| visualizan en el catálogo. Estos campos no están implicados en la comprobación de
| exclusividad para índices exclusivos.
| Utilice la sentencia CREATE INDEX con la palabra clave XMLPATTERN

| para crear un índice XML. También debe especificar la vía de acceso XML que
| debe indexarse. A continuación se forma una clave de índice concatenando los
| valores extraídos del nodo del documento XML que cumple la vía de acceso XML
| especificada con el ID de nodo y documento.
| Cuando indexa una columna XML con XMLPATTERN, tan solo se indexan las
| partes del documento que cumplen la expresión de vía de acceso XML. Dado que
| varias partes del documento pueden cumplir con la Xpath especificada en
| XMLPATTERN, se pueden generar varias entradas de clave de índice e insertarlas
| en el índice durante la inserción de un único documento.
| Sólo se permite una especificación de índice XML para cada sentencia CREATE
| INDEX. Sin embargo, puede crear varios índices XML en una columna XML.

| Restricción: Los índices XML particionados no están soportados actualmente
| Ejemplo 1: Si desea buscar el apellido (name/last) de un empleado específico en

| los elementos de empleado, puede crear un índice en la vía de acceso XML
| ’/department/emp/name/last’ utilizando la sentencia CREATE INDEX siguiente:
| CREATE INDEX EMPINDEX ON DEPARTMENT (DEPTDOCS)
| GENERATE KEYS USING XMLPATTERN '/department/emp/name/last'
| AS SQL VARCHAR(20)
| Una vez el índice EMPINDEX se ha creado satisfactoriamente, se llenarán varias

| entradas en las tablas de catálogo.
| Ejemplo 2: Puede crear dos índices XML con la misma expresión de vía de acceso
| utilizando diferentes tipos de datos para cada uno de ellos. Los índices XML
| soportan los tipos de datos VARCHAR y DECFLOAT. Esto le permite seleccionar
| cómo quiere interpretar el resultado de la expresión según varios tipos de datos.
| Por ejemplo, el valor ’12345’ tiene una representación de tipo carácter pero también
| se puede interpretar como el número 12 345. Si desea indexar la vía de acceso
| ’/department/emp/@id’ como una serie de caracteres y como un número, debe
| crear dos índices, uno para el tipo de datos VARCHAR y uno para el tipo de datos
| DECFLOAT. Los valores del documento se convierten al tipo de datos especificado
| para el índice.
Atributos de índices de tablas particionadas

Un índice particionado es un índice que está físicamente particionado. Los índices de
particionamiento y los índices secundarios pueden estar particionados.
Antes de la Versión 8, cuando se creaba una tabla en un espacio de tablas

particionado, se definía un índice de particionamiento y uno o más índices
secundarios. El índice de particionamiento también era el índice de agrupación en
clúster y el único índice particionado. Los índices sin particionamiento, referidos
como índices secundarios, no estaban particionados.
| En un particionamiento controlado por índice, la estructura física de un índice

| depende de si hay implicado un índice de particionamiento. Sin embargo, cuando
| se calcula el almacenamiento para un índice, el factor más importante es si el
| índice es o no exclusivo. Al considerar el orden en que se almacenan las filas, debe
| considerarse qué índice es el índice de agrupación en clúster. En un
| particionamiento controlado por índice, un índice de particionamiento también es
| el índice de agrupación en clúster. En un particionamiento controlado por índice,
| utilice un índice de particionamiento para indicar a DB2 cómo debe dividir los
| datos de un espacio de tablas particionado entre las particiones.
| En un particionamiento controlado por tabla, defina el esquema de

| particionamiento para la tabla utilizando la cláusula PARTITION BY de la
| sentencia CREATE TABLE.
Para tablas particionadas, se aplican las características siguientes:

v Los índices definidos en una tabla particionada se clasifican según sus atributos
lógicos y sus atributos físicos.

– El atributo lógico de un índice de una tabla particionada es apropiado si el
índice se puede ver como un índice de particionamiento lógico.
– El atributo físico de un índice de una tabla particionada es apropiado si el
índice está físicamente particionado.
v Un índice de particionamiento puede estar particionado o no particionado.
| v Cualquier índice, con la excepción de un índice de una expresión o un índice
| XML, puede ser un índice de agrupación en clúster. Tan solo puede definir un
| índice de agrupación en clúster en una tabla.
La figura siguiente muestra la diferencia entre un índice particionado y un índice

no particionado.
Figura 41. Comparación entre un índice particionado y un índice no particionado
Los índices de una tabla particionada se pueden categorizar, basándose en

atributos de índices lógicos, en índices de particionamiento e índices secundarios.
“Creación de una tabla con particionamiento controlado por tabla” en la página
183
Índices de particionamiento
En un particionamiento controlado por índices, un índice de particionamiento es un
índice que define el esquema de particionamiento de un espacio de tablas basado
en la cláusula PARTITION para cada partición de la sentencia CREATE INDEX. En
un particionamiento controlado por tabla, un índice de particionamiento es
opcional.
Las columnas que se especifican para el índice de particionamiento son las

columnas de clave. La cláusula PARTITION para cada partición define los rangos
de valores para las columnas de clave. Estos rangos particionan el espacio de
tablas y el espacio de índice de particionamiento correspondiente.

Antes de DB2 Versión 8, cuando se definía un índice de particionamiento en una
tabla de un espacio de tablas particionado, se especificaban los valores de clave de
particionamiento y de clave límite en la cláusula PART VALUES de la sentencia
CREATE INDEX. Este tipo de particionamiento recibe el nombre de
particionamiento controlado por índice. A partir de DB2 Versión 8, se puede definir
un particionamiento controlado por tabla con la sentencia CREATE TABLE. El
particionamiento controlado por tabla está diseñado para sustituir con el tiempo el
particionamiento controlado por índice.
Ejemplo: Suponga que una tabla contiene códigos de área de estado y que
necesita crear un índice de particionamiento para secuenciar los códigos de área
entre particiones. Puede utilizar las siguientes sentencias de SQL para crear la tabla
y el índice de particionamiento:
CREATE TABLE AREA_CODES
(AREACODE_NO INTEGER NOT NULL,
STATE CHAR (2) NOT NULL,
...
PARTITION BY (AREACODE_NO ASC)
...
CREATE INDEX AREACODE_IX1 ON AREA_CODES (AREACODE_NO)
CLUSTER (...
PARTITION 2 ENDING AT (400),
PARTITION 3 ENDING AT (500),
PARTITION 4 ENDING AT (600)),
...);
La figura siguiente ilustra el índice de particionamiento en la tabla AREA_CODES.
Figura 42. Índice de particionamiento en la tabla AREA_CODES
| Restricción: No se puede crear un índice de particionamiento en un espacio de

| tablas de partición por crecimiento.

Índices secundarios
En un particionamiento basado en tabla, un índice que no es un índice de
particionamiento es un índice secundario. Un índice puede estar particionado o no
particionado. Puede crear un índice en una tabla para imponer una restricción de
exclusividad, para agrupar datos en clústeres o para proporcionar vías de acceso a
datos para consultas.
La utilidad de un índice depende de las columnas de su clave y de la cardinalidad

de la clave. Las columnas que se utilizan con frecuencia en operaciones de
selección, unión, agrupación y ordenación son unas candidatas de clave adecuadas.
Además, el número de valores diferenciados de una clave de índice para una tabla
grande debe ser suficiente para que DB2 utilice el índice para recuperación de
datos; de lo contrario, DB2 podría optar por realizar una exploración de espacio de
tablas.
| Restricción: Un índice XML no se puede particionar.
DB2 da soporte a dos tipos de índices secundarios: índices secundarios

particionados de datos (DPSI) e índices secundarios no particionados (NPSI).
Índices secundarios particionados de datos:
Un índice secundario particionado de datos (DPSI) es un índice sin partición

físicamente particionado según el esquema de particionamiento de la tabla.
| Sólo puede crear un índice secundario particionado de datos en una tabla que
| resida en un espacio de tablas particionado. El índice secundario particionado de
| datos se particiona según el esquema de particionamiento de los datos
| subyacentes. Es decir, las entradas de índice que hacen referencia a datos de la
| partición física 1 de una tabla residen en la partición física 1 del índice, etc.
| Restricción: No puede crear un DPSI para un espacio de tablas de partición por

| crecimiento ni para un índice XML.
| Las características de los DPSI incluyen:

v Un DPSI tiene tantas particiones como número de particiones del espacio de
tablas.
v Cada partición de DPSI contiene claves únicamente para las filas de la partición
de espacio de tablas correspondiente. Por ejemplo, si el espacio de tablas tiene
tres particiones, las claves de la partición de DPSI 1 tan solo hacen referencia a
las filas de la partición de espacio de tablas 1; las claves de la partición de DPSI
2 tan solo hacen referencia a las filas de la partición de espacio de tablas 2, etc.
| Para definir un DPSI utilice la palabra clave PARTITIONED. Si las columnas más a
| la izquierda del índice que especifica con la palabra clave PARTITIONED coinciden
| con las columnas de particionamiento, DB2 tan solo crea el índice como un DPSI si
| la secuencia de clasificación de las columnas coincidentes es diferente.
La utilización de índices secundarios particionados de datos aumenta la

independencia de partición y, por lo tanto, proporciona las siguientes ventajas de
rendimiento, entre otras:
v Elimina la contención entre trabajos LOAD PART paralelos que tienen como
destino particiones diferentes de un espacio de tablas
v Facilita las operaciones en el nivel de partición como, por ejemplo, añadir una
partición nueva o rotar la primera partición para que sea la última partición

v Mejora el tiempo de recuperación de índices secundarios en espacios de tablas
particionados
Sin embargo, la utilización de índices secundarios particionados de datos no

siempre mejora el rendimiento de las consultas. Por ejemplo, para consultas con
predicados que tan solo hacen referencia a las columnas de la clave del DPSI, DB2
debe comprobar que los valores para cada partición del índice cumplan el
predicado.
| Los índices secundarios particionados de datos proporcionan ventajas de

| rendimiento en consultas que cumplen los criterios siguientes:
v La consulta tiene predicados en las columnas de DPSI.
v La consulta contiene predicados adicionales en las columnas de particionamiento
de la tabla que limitan la consulta a un subconjunto de las particiones de la
tabla.
Ejemplo: Considere la sentencia SELECT siguiente:

SELECT STATE FROM AREA_CODES
WHERE AREACODE_NO *<= 300 AND STATE = 'CA';
Esta consulta utiliza de forma eficaz el índice secundario particionado de datos. El

número de valores de clave que es necesario buscar está limitado a los valores de
clave de las particiones calificadoras. En el caso de una consulta secundaria no
particionada, es posible que se lleve a cabo una exploración de índice más
completa de los valores de clave.
Índices secundarios no particionados:
Un índice secundario no particionado (NPSI) es cualquier índice que no esté

definido como un índice de particionamiento o como un índice particionado. Un
NPSI tiene un espacio de índice que contiene las claves para las filas de todas las
particiones del espacio de tablas.
| Puede crear un índice secundario no particionado en una tabla que resida en un

| espacio de tablas particionado, sin embargo, esto no es posible en espacios de
| tablas no particionados.
Los índices secundarios no particionados proporcionan ventajas de rendimiento en

consultas que cumplen los criterios siguientes:
v La consulta no contiene predicados en las columnas de particionamiento de la
tabla que limiten la consulta a un subconjunto muy pequeño de las particiones
de la tabla.
v Las calificaciones de consulta coinciden con las columnas de índice.
v Las columnas de la lista SELECT se incluyen en el índice (para acceso de sólo
índice).
Ejemplo: Considere la sentencia SELECT siguiente:

SELECT STATE FROM AREA_CODES
WHERE AREACODE_NO <= 300 AND STATE > 'CA';

Esta consulta utiliza de forma eficaz el índice secundario no particionado en las
columnas AREACODE_NO y STATE, particionado por STATE. El número de
valores de clave que es necesario buscar está limitado a los valores de clave de
índice inferiores o iguales a 300.
Ejemplo de índices secundarios particionados de datos y no particionados:
El ejemplo incluido le puede ayudar a comprender las ventajas de utilizar índices

secundarios particionados de datos y no particionados.
| Este ejemplo crea un índice secundario particionado de datos (DPSIIX2) y un

| índice secundario no particionado (NPSIIX3) en la tabla AREA_CODES.
Importante: La tabla AREA_CODES debe estar particionada en una columna que

no sea la columna STATE para que los índices sean secundarios.
Puede utilizar las siguientes sentencias de SQL para crear estos índices
secundarios:
CREATE INDEX DPSIIX2 ON AREA_CODES (STATE) PARTITIONED;
CREATE INDEX NPSIIX3 ON AREA_CODES (STATE);
La figura siguiente ilustra cómo aparece el índice secundario particionado de datos

y el índice secundario no particionado en la tabla AREA_CODES.
Figura 43. Índice secundario particionado de datos e índice secundario no particionado en la tabla AREA_CODES
Los índices secundarios particionados de datos proporcionan ventajas sobre los

índices secundarios no particionados para el proceso de programas de utilidad. Por
ejemplo, los programas de utilidad tales como COPY, REBUILD INDEX y
RECOVER INDEX pueden operar en particiones físicas en lugar de particiones

lógicas debido a que las claves para una partición de datos concreta residen en una
sola partición de DPSI (índice secundario particionado de datos). Esto puede
proporcionar una mayor disponibilidad.
Creación de vistas
Al diseñar la base de datos, puede que necesite proporcionar a los usuarios
únicamente acceso a determinadas partes de los datos. Puede proporcionar acceso
a los usuarios mediante el diseño y la utilización de vistas.
Utilice la sentencia CREATE VIEW para definir y nombrar una vista. A menos que
liste específicamente diferentes nombres de columna después del nombre de vista,
los nombres de columna de la vista son iguales que los de la tabla subyacente.
Cuando cree diferentes nombres de columna para la vista, tenga en cuenta los
convenios de denominación que ha establecido al diseñar la base de datos
relacional.
Una sentencia SELECT describe la información en la vista. La sentencia SELECT

puede nombrar otras vistas y tablas, y puede utilizar las cláusulas WHERE,
GROUP BY y HAVING. No puede utilizar la cláusula ORDER BY ni nombrar una
variable de lenguaje principal.
“Utilización de vistas para personalizar los datos que ve un usuario” en la
página 85
“Vistas de DB2” en la página 31
Vista de una única tabla

Esta información proporciona ejemplos sobre cómo crear una vista de una única
tabla.
Ejemplo: Suponga que desea crear una vista de la tabla DEPT. De las cuatro
columnas de la tabla, la vista sólo necesita tres: DEPTNO, DEPTNAME y MGRNO.
El orden de las columnas que se especifican en la cláusula SELECT es el orden en
que aparecen en la vista:
CREATE VIEW MYVIEW AS
SELECT DEPTNO,DEPTNAME,MGRNO
FROM DEPT;
Ejemplo: En el ejemplo anterior, ninguna lista de columnas sigue al nombre de

vista, MYVIEW. Por lo tanto, las columnas de la vista tienen los mismos nombres
que las de la tabla DEPT en la que se basa. Puede ejecutar la sentencia SELECT
siguiente para ver el contenido de la vista:
SELECT * FROM MYVIEW;

DEPTNO DEPTNAME MGRNO
====== ===================== ======
A00 CHAIRMANS OFFICE 000010
B01 PLANNING 000020
C01 INFORMATION CENTER 000030
D11 MANUFACTURING SYSTEMS 000060
E21 SOFTWARE SUPPORT ------

Vista que combina información de varias tablas
Puede crear una vista que contenga una combinación de más de una tabla. La
combinación de más de una tabla se denomina unión.
DB2 proporciona dos tipos de uniones: una unión externa y una unión interna.
Una unión externa incluye las filas en las que los valores de las columnas de unión
no coinciden y las filas en las que los valores coinciden. Una unión interna incluye
sólo las filas en las que se devuelven valores coincidentes en las columnas de
unión.
Ejemplo: El ejemplo siguiente es una unión interna de columnas de las tablas

DEPT y EMP. La cláusula WHERE limita la vista a tan solo las columnas en las
que MGRNO de la tabla DEPT coincide con EMPNO de la tabla EMP:
CREATE VIEW MYVIEW AS
SELECT DEPTNO, MGRNO, LASTNAME, ADMRDEPT
FROM DEPT, EMP
WHERE EMP.EMPNO = DEPT.MGRNO;
El resultado de ejecutar esta sentencia CREATE VIEW es una vista de unión

interna de dos tablas como se muestra a continuación:
DEPTNO MGRNO LASTNAME ADMRDEPT
====== ====== ======== ========
A00 000010 HAAS A00
B01 000020 THOMPSON A00
C01 000030 KWAN A00
D11 000060 STERN D11
Ejemplo: Suponga que desea crear la vista del ejemplo anterior, pero tan solo
desea incluir los departamentos que informan al departamento A00. Suponga
también que prefiere utilizar un conjunto diferente de nombres de columna. Utilice
la sentencia CREATE VIEW siguiente:
CREATE VIEW MYVIEWA00
(DEPARTMENT, MANAGER, EMPLOYEE_NAME, REPORT_TO_NAME)
AS
SELECT DEPTNO, MGRNO, LASTNAME, ADMRDEPT
FROM EMP, DEPT
WHERE EMP.EMPNO = DEPT.MGRNO
AND ADMRDEPT = 'A00';
Puede ejecutar la sentencia SELECT siguiente para ver el contenido de la vista:

SELECT * FROM MYVIEWA00;
Al ejecutar esta sentencia SELECT, el resultado es una vista de un subconjunto de

los mismos datos, pero con nombres de columna diferentes, como se muestra a
continuación:
DEPARTMENT MANAGER EMPLOYEE_NAME REPORT_TO_NAME
========== ======= ============= ==============
A00 000010 HAAS A00
B01 000020 THOMPSON A00
C01 000030 KWAN A00
“Modos de fusionar listas de valores” en la página 108
Inserciones y actualizaciones de datos mediante vistas

| Si define una vista en una sola tabla, puede hacer referencia al nombre de una
| vista en operaciones de inserción, actualización o supresión. Si la vista es compleja

| o implica varias tablas, debe definir un desencadenante INSTEAD OF para poder
| hacer referencia a esta vista en una sentencia INSERT, UPDATE, MERGE o
| DELETE. Esta información explica cómo se trata el caso simple, en el que DB2
| realiza una inserción o actualización en la tabla base.
Para asegurarse de que la inserción o actualización se ajusta a la definición de

vista, especifique la cláusula WITH CHECK OPTION. El ejemplo siguiente ilustra
algunos resultados no deseables al omitir esta comprobación.
Ejemplo: Suponga que define una vista, V1, del modo siguiente:
CREATE VIEW V1 AS
SELECT * FROM EMP
WHERE DEPT LIKE 'D
Un usuario con el privilegio SELECT sobre la vista V1 puede ver la información de

la tabla EMP para los empleados de los departamentos cuyos ID empiezan con D.
La tabla EMP únicamente tiene un departamento (D11) con un ID que cumple la
condición.
Suponga que un usuario tiene el privilegio INSERT sobre la vista V1. Un usuario
con los privilegios SELECT e INSERT puede insertar una fila para el departamento
E01, quizás erróneamente, pero no puede seleccionar la fila que se acaba de
insertar.
En el ejemplo siguiente se muestra un modo alternativo para definir la vista V1.
Ejemplo: Puede evitar la situación en que un valor que no coincide con la

definición de vista se inserta en la tabla base. Para ello, en su lugar defina la vista
V1 para incluir la cláusula WITH CHECK OPTION:
CREATE VIEW V1 AS SELECT * FROM EMP
WHERE DEPT LIKE 'D%' WITH CHECK OPTION;
Con la nueva definición, cualquier inserción o actualización en la vista V1 debe

cumplir el predicado contenido en la cláusula WHERE: DEPT LIKE ’D%’. La
comprobación puede ser útil, pero también tiene un coste de proceso; cada
inserción o actualización potencial debe comprobarse en la definición de vista. Por
lo tanto, debe sopesar la ventaja de proteger la integridad de los datos y la
desventaja de la degradación del rendimiento.
Tareas relacionadas
″Inserción, actualización y supresión de datos en vistas utilizando
desencadenantes INSTEAD OF″ (DB2 Application Programming and SQL
Guide)
″CREATE VIEW″ (Consulta de DB2 SQL)
Creación de objetos grandes

La definición de objetos grandes para DB2 es diferente de la definición de otros
tipos de datos y objetos.
A continuación se proporcionan los pasos básicos para definir los LOB y mover los
datos a DB2:
1. Defina una columna del tipo LOB adecuado.
Cuando crea una tabla con una columna LOB, o modifica una tabla para añadir
una columna LOB, la definición de una columna ROWID es opcional. Si no
define una columna ROWID, DB2 define automáticamente una columna
ROWID oculta. Defina sólo una columna ROWID, incluso si existen varias
columnas LOB en la tabla.
La columna LOB contiene información sobre el LOB, no sobre los datos del
LOB. La tabla que contiene la información del LOB se denomina tabla base, que
es diferente de la tabla base común. DB2 utiliza la columna ROWID para
localizar los datos del LOB. Puede definir la columna LOB y la columna
ROWID en una sentencia CREATE TABLE o ALTER TABLE. Si añade una
columna LOB y una columna ROWID a una tabla existente, debe utilizar dos
sentencias ALTER TABLE. Si añade la columna ROWID después de añadir la
columna LOB, la tabla tiene dos ROWID; una oculta y la que ha creado. DB2
asegura que los valores de las dos columnas ROWID sean siempre iguales.
2. Cree un espacio de tablas y una tabla para contener los datos del LOB.
Para datos de LOB, el espacio de tablas se denomina espacio de tabla de LOB y
una tabla se denomina tabla auxiliar. Si la tabla base no está particionada, debe
crear una espacio de tablas de LOB y una tabla auxiliar para cada columna
LOB. Si la tabla base está particionada, debe crear un espacio de tablas de LOB
y una tabla auxiliar para cada columna LOB de cada partición. Por ejemplo,
debe crear tres espacios de tablas de LOB y tres tablas auxiliares para cada
columna de LOB si la tabla base tiene tres particiones. Cree estos objetos
utilizando las sentencias CREATE LOB TABLESPACE y CREATE AUXILIARY
TABLE.
3. Cree un índice en la tabla auxiliar.
Cada tabla auxiliar debe tener exactamente un índice en el que cada entrada de
índice haga referencia a un LOB. Utilice la sentencia CREATE INDEX para esta
tarea.
4. Ponga los datos del LOB en DB2.
Si la longitud total de una columna LOB y la fila de tabla base es inferior a 32
KB, puede utilizar el programa de utilidad LOAD para poner los datos en DB2.
De lo contrario, debe utilizar una de las sentencias de SQL que cambian datos.
Aunque los datos residan en la tabla auxiliar, la sentencia del programa de
utilidad LOAD o la sentencia de SQL que cambia datos especifica la tabla base.
La utilización de las sentencias INSERT o MERGE puede ser difícil debido a
que la aplicación necesita suficiente almacenamiento para contener el valor total
que va a la columna LOB.
Ejemplo: Suponga que necesita definir un espacio de tablas de LOB y una tabla
auxiliar para contener los currículums de los empleados. También necesita definir
un índice en la tabla auxiliar. Debe definir el espacio de tablas de LOB en la misma
base de datos que la tabla base asociada. Suponga que EMP_PHOTO_RESUME es
una tabla base. Esta tabla base contiene una columna LOB denominada
EMP_RESUME. Puede utilizar sentencias como ésta para definir el espacio de
tablas de LOB, el espacio de tablas auxiliar y el índice:
CREATE LOB TABLESPACE RESUMETS
IN MYDB
LOG NO;
COMMIT;
CREATE AUXILIARY TABLE EMP_RESUME_TAB
IN MYDB.RESUMETS
STORES EMP_PHOTO_RESUME
COLUMN EMP_RESUME;
CREATE UNIQUE INDEX XEMP_RESUME
ON EMP_RESUME_TAB;
COMMIT;

Puede utilizar la cláusula LOG para especificar si deben registrarse los cambios
realizados en una columna LOB del espacio de tablas. La cláusula LOG NO de la
sentencia CREATE LOB TABLESPACE anterior indica que no deben registrarse los
cambios realizados en el espacio de tablas RESUMETS.
Creación de bases de datos

Cuando defina una base de datos de DB2, nombre una colección eventual de
tablas, índices asociados y los espacios de tablas en los que deben residir.
Cuando decida si va a definir una nueva base de datos para un nuevo conjunto de
objetos o va a utilizar una base de datos existente, considere los hechos siguientes:
v Puede iniciar y detener una base de datos completa como una unidad. Puede
visualizar el estado de todos los objetos de la base de datos utilizando un único
mandato que nombre únicamente la base de datos. Por lo tanto, coloque un
conjunto de tablas relacionadas en la misma base de datos. (La misma base de
datos contiene todos los índices en dichas tablas.)
v Si desea mejorar la simultaneidad y la utilización de la memoria, mantenga el
número de tablas de una única base de datos relativamente pequeño (un
máximo de 20 tablas). Por ejemplo, con menos tablas DB2 realiza una
reorganización en un periodo de tiempo más corto.
v La existencia de bases de datos separadas permite ejecutar simultáneamente
definiciones de datos y también utiliza menos espacio para los bloques de
control.
Para crear una base de datos, utilice la sentencia CREATE DATABASE. Un nombre
para una base de datos es un identificador no calificado con un máximo de ocho
caracteres. Un nombre de base de datos de DB2 no debe ser igual que el nombre
de cualquier otra base de datos de DB2.
| En modalidad de función nueva, si no especifica la cláusula IN en la sentencia

| CREATE TABLE, DB2 crea implícitamente una base de datos. La lista siguiente
| muestra los nombres para una base de datos implícita:
| DSN00001, DSN00002, DSN00003, ..., DSN10000
Ejemplo: El ejemplo siguiente muestra un nombre de base de datos válido:

Nombre de
objeto
Base de datos
MYDB
Esta sentencia CREATE DATABASE crea la base de datos MYDB:

CREATE DATABASE MYDB
STOGROUP MYSTOGRP
BUFFERPOOL BP8K4
INDEXBP BP4;
Las cláusulas STOGROUP, BUFFERPOOL e INDEXBP que aparecen en este

ejemplo establecen valores por omisión. Puede alterar temporalmente estos valores
en las definiciones del espacio de tablas o del espacio de índice.
No es necesario definir una base de datos para que utilice DB2; para el desarrollo
y la prueba, puede utilizar la base de datos por omisión, DSNDB04. Esto significa

que puede definir tablas e índices sin definir específicamente una base de datos. La
tabla de catálogo SYSIBM.SYSDATABASE describe la base de datos por omisión y
todas las otras bases de datos.
Recomendación: No utilice la base de datos por omisión para trabajo de

producción.
″CREATE DATABASE″ (Consulta de DB2 SQL)
Creación de relaciones con restricciones de referencia

La integridad de referencia es una condición en la que todas las referencias de
datos de una columna de tabla a datos de otra columna de tabla son válidos.
Mediante la utilización de restricciones de referencia puede definir relaciones entre
entidades que define en DB2.
Las organizaciones que optan por imponer restricciones de referencia tienen como
mínimo una cosa en común. Necesitan asegurar que los valores de una columna de
una tabla son válidos respecto a otros valores de datos de la base de datos.
Ejemplos:
v Una empresa de fabricación desea asegurar que cada componente de una tabla
PARTS identifica a un número de producto que equivale a un número de
producto válido en la tabla PRODUCTS.
v Una empresa desea asegurar que cada valor de DEPT en la tabla EMP equivale
a un valor de DEPTNO válido en la tabla DEPT.
Si DBMS no da soporte a integridad de referencia, sería necesario escribir y

mantener un código de aplicación que valide la relación entre las columnas y es
posible que algunos programas no impongan reglas empresariales, aunque
debieran hacerlo.
Esta tarea de programación puede ser muy compleja debido a la necesidad de

asegurarse de que tan solo se inserten o actualicen valores válidos en las columnas.
Si DBMS da soporte a integridad de referencia, como es el caso de DB2, los
programadores pueden omitir algunas tareas complejas de programación y pueden
ser más productivos en sus otras tareas.
″Utilización de integridad de referencia para coherencia de los datos″ (DB2
Cómo DB2 impone restricciones de referencia

Esta información describe qué hace DB2 para mantener la integridad de referencia.
Se definen restricciones de referencia entre una clave foránea y su clave padre.

Antes de empezar a definir las relaciones de restricciones de referencia, debería
comprender qué hace DB2 para mantener la integridad de referencia. Debería
comprender las reglas que sigue DB2 cuando los usuarios intentan modificar la
información de columnas implicadas en restricciones de referencia.
Para mantener la integridad de referencia, DB2 impone restricciones de referencia

en respuesta a cualquiera de los sucesos siguientes:
v Una inserción en una tabla dependiente

v Una actualización en una tabla padre o una tabla dependiente
v Una supresión de una tabla padre
v La ejecución del programa de utilidad CHECK DATA o LOAD en una tabla
dependiente con la opción ENFORCE CONSTRAINTS
Al definir restricciones, dispone de las opciones siguientes:

CASCADE
DB2 difunde la acción a dependientes de la tabla padre.
NO ACTION
Se produce un error y DB2 no realiza ninguna acción.
RESTRICT
Se produce un error y DB2 no realiza ninguna acción.
SET NULL
DB2 coloca un valor nulo en cada columna anulable de la clave foránea
que existe en cada dependiente de la tabla padre.
| DB2 no impone restricciones de referencia en un orden previamente definido. Sin

| embargo, el orden en que DB2 impone las restricciones puede afectar al resultado
| de la operación. Por lo tanto, debería tener en cuenta las restricciones en la
| definición de reglas de supresión y en el uso de determinadas sentencias. Las
| restricciones están relacionadas con las siguientes sentencias de SQL: CREATE
| TABLE, ALTER TABLE, INSERT, UPDATE, MERGE y DELETE.
Puede utilizar la opción NOT ENFORCED de la definición de restricción de

referencia en una sentencia CREATE TABLE o ALTER TABLE para definir una
restricción de referencia de información. Debería utilizar este tipo de restricción de
referencia únicamente cuando un proceso de aplicaciones comprueba los datos en
una relación de integridad de referencia.
″Restricciones de referencia″ (Consulta de DB2 SQL)
Reglas de inserción
Las reglas de inserción para integridad de referencia se aplican a tablas padre y
dependientes.
Las siguientes reglas de inserción para integridad de referencia se aplican a tablas

padre y dependientes:
v Para tablas padre: Puede insertar una fila en cualquier momento en una tabla
padre sin realizar ninguna acción en la tabla dependiente. Por ejemplo, puede
crear un nuevo departamento en la tabla DEPT sin realizar ningún cambio en la
tabla EMP. Si inserta filas en una tabla padre que está implicada en una
restricción de referencia, se aplican las siguientes restricciones:
– Debe existir un índice exclusivo en la clave padre.
– No se pueden entrar valores duplicados para la clave padre.
– No se puede insertar ningún valor nulo para cualquier columna de la clave
padre.
v Para tablas dependientes: No se puede insertar una fila en una tabla
dependiente a menos que una fila de la tabla padre tenga un valor de clave
padre que sea igual al valor de clave foránea que se desea insertar. Puede
insertar una clave foránea con un valor nulo en una tabla dependiente (si la
restricción de referencia lo permite), pero no existe ninguna conexión lógica si
realiza esta acción. Si inserta filas en una tabla dependiente, se aplican las
siguientes restricciones:
– Cada valor no nulo que se inserta en una columna de clave foránea debe ser
igual a algún valor de la clave padre.
– Si algún campo de la clave foránea es nulo, la clave foránea completa es nula.
– Si se descarta el índice que impone la clave padre de la tabla padre, no se
pueden insertar filas ni en la tabla padre ni en la tabla dependiente.
Ejemplo: La empresa no desea tener una fila en la tabla PARTS a menos que el
valor de la columna PROD# de dicha fila coincida con un PROD# válido en la
tabla PRODUCTS. La tabla PRODUCTS tiene una clave primaria en PROD#. La
tabla PARTS tiene una clave foránea en PROD#. La definición de restricción
especifica una restricción RESTRICT. Cada fila insertada de la tabla PARTS debe
tener un PROD# que coincida con un PROD# en la tabla PRODUCTS.
Reglas de actualización
Las reglas de actualización para integridad de referencia se aplican a tablas padre y
dependientes.
Las siguientes reglas de actualización para integridad de referencia se aplican a

tablas padre y dependientes:
v Para tablas padre: No se puede cambiar una columna de clave padre de una fila
que tenga una fila dependiente. Si se cambia, la fila dependiente deja de cumplir
la restricción de referencia y, por lo tanto, DB2 prohíbe la operación.
v Para tablas dependientes: No se puede cambiar el valor de una columna de
clave foránea de una tabla dependiente a menos que el valor nuevo exista en la
clave padre de la tabla padre.
Ejemplo: Cuando un empleado se transfiere de un departamento a otro, debe

cambiarse el número de departamento para este empleado. El valor nuevo debe ser
el número de un departamento existente o debe ser nulo. No debería poderse
asignar un empleado a un departamento que no existe. Sin embargo, en el caso de
una reorganización de una empresa, es posible que de forma temporal los
empleados no informen a un departamento válido. En este caso, un valor nulo es
una posibilidad.
Si falla una actualización de una tabla con una restricción de referencia, DB2
retrotrae todos los cambios realizados durante la actualización.
Reglas de supresión
Las reglas de supresión, que se aplican a tablas padre y dependientes, constituyen
una parte importante de la integridad de referencia de DB2.
Las siguientes reglas de supresión para integridad de referencia se aplican a tablas

padre y dependientes:
Para tablas padre
En cualquier relación concreta, DB2 impone reglas de supresión basadas en
las opciones que se especifican al definir la restricción de referencia.
Para tablas dependientes
En cualquier momento, puede suprimir filas de una tabla dependiente sin
realizar ninguna acción en la tabla padre.

Para suprimir una fila de una tabla que tiene una clave padre y tablas
dependientes, debe cumplir las reglas de supresión para dicha tabla. Para que la
acción sea satisfactoria, DELETE debe cumplir todas las reglas de supresión de
todas las relaciones afectadas. DELETE falla si viola alguna restricción de
referencia.
Ejemplo 1: Considere la tabla padre de la relación departamento-empleado.

Suponga que suprime la fila para el departamento C01 de la tabla DEPT. Esta
decisión debería afectar a la información de la tabla EMP sobre Sally Kwan,
Heather Nicholls y Kim Natz, que trabajan en el departamento C01.
Ejemplo 2: Considere la tabla dependiente en la relación departamento-empleado.

Suponga que un empleado se jubila y que un programa suprime la fila para dicho
empleado de la tabla EMP. La tabla DEPT no se ve afectada.
Construcción de una estructura de referencia

Cuando crea una estructura de referencia, debe crear un conjunto de tablas e
índices en el orden correcto.
Durante un diseño lógico, se expresan relaciones de uno con uno y relaciones de

uno con varios como si las relaciones fueran bidireccionales. Por ejemplo:
v Un empleado tiene un currículum y un currículum pertenece a un empleado
(relación de uno con uno).
v Un departamento tiene varios empleados y cada empleado informa a un
departamento (relación de uno con varios).
Durante un diseño físico, se expone de nuevo la relación de modo que sea

unidireccional; una entidad pasa a ser el padre implicado del otro. En este caso, el
empleado es el padre del currículum y el departamento es el padre de los
empleados asignados.
Durante un diseño lógico, se expresan relaciones de varios con varios como si las
relaciones fueran bidireccionales y de varios valores. Durante un diseño físico, los
diseñadores de bases de datos determinan relaciones de varios con varios
utilizando una tabla asociativa. La relación entre empleados y proyectos es un
buen ejemplo de cómo se crea la integridad de referencia. Se trata de una relación
de varios con varios ya que los empleados trabajan en más de un proyecto y un
proyecto puede tener asignado más de un empleado.
Ejemplo: Para determinar la relación de varios con varios entre empleados (en la
tabla EMP) y proyectos (en la tabla PROJ), los diseñadores crean una nueva tabla
asociativa, EMP_PROJ, durante el diseño físico. EMP y PROJ son tablas padre de la
tabla hijo, EMP_PROJ.
| Cuando establece restricciones de referencia, debe crear tablas padre que tengan
| como mínimo una clave exclusiva y los índices correspondientes antes de definir
| las claves foráneas correspondientes en las tablas dependientes.
“Desnormalización para mejorar el rendimiento” en la página 83

Tablas de una estructura de referencia

En una estructura de referencia puede crear espacios de tablas en cualquier orden.
La utilización de un modelo para la estructura puede ser útil.
Puede crear espacios de tabla en cualquier orden. Sin embargo, primero debe crear
los espacios de tablas para poder realizar los pasos siguientes. (Este procedimiento
utiliza las tablas DEPT y EMP.)
1. Cree la tabla DEPT y defina su clave primaria en la columna DEPTNO. La
cláusula PRIMARY KEY de la sentencia CREATE TABLE define la clave
primaria.
Ejemplo:
CREATE TABLE DEPT
.
.
.
PRIMARY KEY (DEPTNO);
2. Cree la tabla EMP y defina su clave primaria como EMPNO y su clave foránea
como DEPT. La cláusula FOREIGN KEY de la sentencia CREATE TABLE define
la clave foránea.
Ejemplo:
CREATE TABLE EMP
.
.
.
PRIMARY KEY (EMPNO)
FOREIGN KEY (DEPT)
REFERENCES DEPT (DEPTNO)
ON DELETE SET NULL;
| 3. Modifique la tabla DEPT para añadir la definición de su clave foránea,
| MGRNO.
| Ejemplo:
| ALTER TABLE DEPT
| FOREIGN KEY (MGRNO)
| REFERENCES EMP (EMPNO)
| ON DELETE RESTRICT;
| Conceptos relacionados
Creación de tablas de excepción

Para poder cargar tablas implicadas en una restricción de referencia o en una
restricción de comprobación, debe crear tablas de excepción. Una tabla de excepción
contiene las filas detectadas por el programa de utilidad CHECK DATA que violan
las restricciones de referencia o las restricciones de comprobación.
″Creación de tablas de excepción″ (DB2 Utility Guide and Reference)

Creación de desencadenantes
Puede utilizar desencadenantes para definir e imponer reglas empresariales que
impliquen diferentes estados de los datos. De forma automática, los
desencadenantes ejecutan un conjunto de sentencias de SQL cada vez que se
produce un suceso especificado. Estas sentencias validan y editan cambios
realizados en la base de datos, leen y modifican la base de datos e invocan
funciones que realizan varias operaciones.
Los desencadenantes son opcionales. Para definir desencadenantes utilice la

sentencia CREATE TRIGGER.
Ejemplo: Suponga que la mayoría de los aumentos de salario de la organización

son inferiores o iguales al 10 por ciento. Suponga también que necesita recibir una
notificación de cualquier intento de un aumento de un valor de la columna de
salario superior a esta cantidad. Para imponer este requisito, DB2 compara el valor
de un salario antes de un aumento de salario con el valor que existiría después de
un aumento de salario. En este caso puede utilizar un desencadenante. Cada vez
que un programa actualiza la columna de salario, DB2 activa el desencadenante.
En la acción desencadenada, puede especificar que DB2 debe realizar las acciones
siguientes:
v Actualizar el valor de la columna de salario con un valor válido, en lugar de
impedir completamente la actualización.
v Notificar a un administrador el intento de realizar una actualización no válida.
Como resultado de utilizar un desencadenante, el administrador notificado puede

decidir si desea alterar temporalmente el aumento de salario original y permitir un
aumento de salario más grande que el normal.
Recomendación: Para reglas que implican únicamente una condición de los datos,
considere la utilización de restricciones de referencia y restricciones de
comprobación en lugar de desencadenantes.
Los desencadenantes también mueven la lógica de aplicación necesaria para

imponer reglas empresariales a la base de datos, lo cual puede tener como
resultado un desarrollo de aplicaciones más rápido y un mantenimiento más fácil.
En el ejemplo anterior, que limita los aumentos de salario, la lógica está en la base
de datos, en lugar de estar en la aplicación. DB2 comprueba la validez de los
cambios que realiza cualquier aplicación en la columna de salario. Además, si
alguna vez la lógica cambia (por ejemplo, para permitir aumentos del 12 por
ciento), no es necesario cambiar los programas de aplicaciones.
“Desencadenantes” en la página 46
Creación de funciones definidas por el usuario

Las funciones definidas por el usuario pueden ser funciones fuente, externas o
SQL. Fuente significa que se basan en funciones existentes. Externas significa que
las desarrollan usuarios. SQL significa que la función está definida para la base de
datos mediante el uso de únicamente sentencias de SQL.
Las funciones definidas por el usuario externas pueden devolver un valor único o
una tabla de valores.
v Las funciones externas que devuelven un valor único se denominan funciones
escalares definidas por el usuario.
v Las funciones externas que devuelven una tabla se denominan funciones de tabla
definidas por el usuario.
Las funciones definidas por el usuario como, por ejemplo, funciones u operaciones
incorporadas, permiten la manipulación de tipos diferenciados.
Los dos ejemplos siguientes muestran cómo definir y utilizar una función definida
por el usuario y un tipo diferenciado.
Ejemplo 1: Suponga que define una tabla denominada EUROEMP. Una columna
de esta tabla, EUROSAL, tiene un tipo diferenciado de EURO, basado en
DECIMAL(9,2). No puede utilizar la función AVG incorporada para buscar el valor
medio de EUROSAL puesto que AVG opera únicamente en tipos de datos
incorporados. Sin embargo, puede definir una función AVG que tiene como fuente
la función AVG incorporada y acepta argumentos de tipo EURO:
CREATE FUNCTION AVG(EURO)
RETURNS EURO
SOURCE SYSIBM.AVG(DECIMAL);
Ejemplo 2: A continuación, puede utilizar esta función para buscar el valor medio
de la columna EUROSAL:
SELECT AVG(EUROSAL) FROM EUROEMP;
Los dos ejemplos siguientes muestran cómo definir y utilizar una función definida
por el usuario externa.
Ejemplo 3: Suponga que define y escribe una función, denominada REVERSE,

para invertir los caracteres de una serie. La definición es similar a la siguiente:
| CREATE FUNCTION REVERSE(VARCHAR(100))
| RETURNS VARCHAR(100)
| EXTERNAL NAME 'REVERSE'
| PARAMETER STYLE SQL
| LANGUAGE C;
Ejemplo 4: A continuación, puede utilizar la función REVERSE en una sentencia

de SQL siempre que utilice una función incorporada que acepte un argumento de
tipo carácter, como se muestra en el ejemplo siguiente:
SELECT REVERSE(:CHARSTR)
FROM SYSDUMMY1;
Aunque no puede escribir funciones de totales definidas por el usuario, puede

definir funciones de totales definidas por el usuario fuente basadas en funciones de
totales incorporadas. Esta posibilidad es útil en los casos en que desea hacer
referencia a una función definida por el usuario existente utilizando otro nombre o
desea pasar un tipo diferenciado.
Los dos ejemplos siguientes muestran cómo definir y utilizar una función de tabla
definida por el usuario.
Ejemplo 5: Puede definir y escribir una función de tabla definida por el usuario
que los usuarios pueden invocar en la cláusula FROM de una sentencia SELECT.
Por ejemplo, suponga que define y escribe una función denominada BOOKS. Esta
función devuelve una tabla de información sobre libros relacionados con un tema
especificado. La definición es similar a la siguiente:
| CREATE FUNCTION BOOKS (VARCHAR(40))
| RETURNS TABLE (TITLE_NAME VARCHAR(25),
| AUTHOR_NAME VARCHAR(25),

| PUBLISHER_NAME VARCHAR(25),
| ISBNNO VARCHAR(20),
| PRICE_AMT DECIMAL(5,2),
| CHAP1_TXT CLOB(50K))
| LANGUAGE COBOL
| PARAMETER STYLE SQL
| EXTERNAL NAME BOOKS;
Ejemplo 6: A continuación, puede incluir la función BOOKS en la cláusula FROM

de una sentencia SELECT para recuperar la información sobre libros, tal como se
muestra en el ejemplo siguiente:
SELECT B.TITLE_NAME, B.AUTHOR_NAME, B.PUBLISHER_NAME, B.ISBNNO
FROM TABLE(BOOKS('Computers')) AS B
WHERE B.TITLE_NAME LIKE '%COBOL%';
“Funciones definidas por el usuario” en la página 96

Capítulo 8. Gestión del rendimiento de DB2
La gestión del rendimiento de un subsistema DB2 implica la comprensión de una
amplia gama de componentes del sistema. Es necesario que comprenda el
rendimiento de dichos componentes, cómo supervisar los componentes y cómo
identificar las áreas problemáticas.
| Los recursos del sistema, el diseño de base de datos y el rendimiento de consultas

| son algunas de las cuestiones de rendimiento que deben considerarse y cada uno
| de estos factores influye en los demás. Por ejemplo, una consulta bien diseñada no
| se ejecuta eficazmente si los recursos del sistema no están disponibles cuando
| necesita ejecutarlos.
Para gestionar el rendimiento de DB2, debe establecer los objetivos de rendimiento

y determinar si los objetos, recursos y procesos cumplen las expectativas de
rendimiento. Las sugerencias y directrices le ayudan a ajustar el subsistema DB2
para mejorar el rendimiento. Existen varias herramientas disponibles para hacer
que el análisis del rendimiento le resulte más fácil.
Pasos iniciales para la gestión del rendimiento

El primer paso para la gestión del rendimiento de DB2 es la comprensión de las
cuestiones sobre rendimiento. Necesita saber cómo reconocer diferentes tipos de
problemas de rendimiento y saber de qué herramientas dispone para resolver los
problemas.
Objetivos de rendimiento
La comprensión de los objetivos de rendimiento establecidos puede ayudarle a
realizar las selecciones adecuadas cuando trabaje con DB2. Aunque los objetivos de
rendimiento varían para cada empresa, el modo en que su sitio define un buen
rendimiento de DB2 depende de las necesidades y prioridades del proceso de
datos.
En todos los casos, los objetivos de rendimiento deben ser realistas, comprensibles
y medibles. Los objetivos típicos incluyen valores para:
v Tiempo de respuesta aceptable (duración dentro del cual un porcentaje de todas
las aplicaciones ha finalizado)
v Rendimiento medio (número total de transacciones o consultas completadas
dentro de un tiempo determinado)
v Disponibilidad del sistema, incluido el tiempo medio de anomalías y las
duraciones de tiempos de inactividad
Objetivos como estos definen la carga de trabajo para el sistema y determinan los
requisitos para los recursos, entre los que se incluye la velocidad del procesador, la
cantidad de almacenamiento, software adicional, etc.
Ejemplo: Un objetivo podría ser que el 90% de todos los tiempos de respuesta en
una red local durante un turno principal esté por debajo de dos segundos. Otro
objetivo podría ser que el tiempo de respuesta medio no exceda de seis segundos,
incluso durante horas punta. (En redes remotas, los tiempos de respuesta son
considerablemente superiores.)

Sin embargo, con frecuencia los recursos disponibles limitan la carga de trabajo
máxima aceptable, lo cual hace que deban revisarse los objetivos.
″Establecimiento de objetivos de rendimiento razonables″ (DB2 Performance
Monitoring and Tuning Guide)
Diseño de las aplicaciones para el rendimiento

El diseño de la base de datos y las aplicaciones para que sean lo más eficaces
posible es un primer paso importante para obtener un rendimiento correcto del
sistema y las aplicaciones. Cuando codifique las aplicaciones, tenga en cuenta los
objetivos de rendimiento en el diseño de las aplicaciones.
Algunos de los factores que afectan al rendimiento de las aplicaciones incluyen

cómo utiliza el programa las variables de lenguaje principal y qué opciones de
vinculación se eligen. A su vez, estos factores afectan al tiempo que tarda DB2 en
determinar una vía de acceso para las sentencias de SQL de la aplicación.
Más adelante en esta información puede leer sobre bloqueos y simultaneidad,

incluyendo recomendaciones para un diseño de base de datos y aplicaciones que
mejore el rendimiento.
Después de ejecutar una aplicación, debe decidir si cumple sus objetivos de

rendimiento. Es posible que deba probar y depurar la aplicación para mejorar su
rendimiento.
″Diseño del sistema para el rendimiento″ (DB2 Performance Monitoring and
Tuning Guide)
Origen de problemas de rendimiento

Si, después de ejecutar una aplicación, determina que no cumple los objetivos de
rendimiento, debe determinar el origen del problema. Esta información describe
cómo identificar problemas de rendimiento y las herramientas que pueden
ayudarle.
Para identificar un problema de rendimiento, empiece por observar el sistema

global antes de decidir que existe un problema en DB2. En general, observe
detenidamente para descubrir por qué los procesos de aplicaciones progresan con
lentitud o por qué un recurso determinado se está utilizando excesivamente.
En DB2, el problema de rendimiento suele ser un tiempo de respuesta lento o una

inexplicable utilización elevada de recursos. Compruebe factores como, por
ejemplo, la utilización total de procesador, la actividad de disco y la transferencia
de páginas.
En primer lugar, obtenga una descripción de la actividad de las tareas, de las clases
1, 2 y 3 del rastreo de contabilidad. DB2 proporciona un recurso de rastreo que le
permite supervisar y recopilar información detallada sobre DB2, que incluye
información de rendimiento y estadística. A continuación, céntrese en actividades
específicas, tales como procesos de aplicaciones específicos o un intervalo de
tiempo específico. Puede observar problemas como los siguientes:
v Tiempo de respuesta lento. Puede recopilar información detallada sobre una
única tarea lenta, un problema que puede ocurrir por varios motivos. Por

ejemplo, los usuarios pueden intentar realizar demasiado trabajo con
determinadas aplicaciones y el sistema simplemente no puede realizar todo el
trabajo que los usuarios desean.
v Restricciones de almacenamiento reales. Las aplicaciones progresan más
lentamente de lo esperado debido a interrupciones por transferencia de páginas.
Las restricciones producen retrasos entre peticiones sucesivas que se registran en
el rastreo de DB2 trace.
Si identifica un problema de rendimiento en DB2, puede ver informes específicos.

Los informes le proporcionan información sobre lo siguiente:
v Si las aplicaciones pueden leer de agrupaciones de almacenamientos intermedios
en lugar de leer desde disco
v Si las aplicaciones deben esperar para escribir en disco o para un bloqueo y
cuánto tiempo
v Si las aplicaciones utilizan una mayor cantidad de recursos que lo habitual
DB2 también proporciona varias herramientas que le ayudan a analizar el

rendimiento.
“Rol de las agrupaciones de almacenamientos intermedios en la puesta en
antememoria de datos” en la página 248
“Modos de mejorar el rendimiento para varios usuarios” en la página 255
“Herramientas para análisis del rendimiento”
″Planificación para la supervisión del rendimiento″ (DB2 Performance
Herramientas para análisis del rendimiento

| DB2 proporciona varias herramientas de estación de trabajo para simplificar el
| análisis del rendimiento.
Las herramientas de estación de trabajo para el análisis de rendimiento incluyen:

| v IBM Optimization Service Center for DB2 for z/OS
| v IBM DB2 Optimization Expert for z/OS
| v Tivoli OMEGAMON XE for DB2 Performance Expert on z/OS
v DB2 Buffer Pool Analyzer
v DB2 SQL Performance Analyzer
v DB2 Query Monitor
DB2 también proporciona una herramienta de supervisión, EXPLAIN.
| OMEGAMON DB2 Performance Expert
| IBM Tivoli OMEGAMON XE for DB2 Performance Expert on z/OS integra

| supervisión de rendimiento, informe, análisis de agrupación de almacenamientos
| intermedios y una función de almacén de rendimiento en una herramienta.
| Proporciona una visión general de un único sistema que supervisa todos los
| subsistemas e instancias entre numerosas plataformas distintas de un modo
| coherente.
Capítulo 8. Gestión del rendimiento de DB2 247

| OMEGAMON DB2 Performance Expert incluye la función de OMEGAMON DB2
| Performance Monitor (DB2 PM). Entre las características de la herramienta se
| incluyen:
| v Información combinada de EXPLAIN y del catálogo de DB2.
| v Visualización de vías de acceso, índices, tablas, espacios de tablas, planes,
| paquetes, DBRM, definiciones de variable de lenguaje principal, orden,
| secuencias de acceso a tabla, secuencias de unión y tipos de bloqueos.
| v Una vista ″instantánea″ de las actividades de DB2 for z/OS que proporciona el
| supervisor en línea. El supervisor permite el proceso de excepciones mientras el
| sistema está operativo.
| DB2 Performance Expert tiene ofertas que dan soporte a DB2 for z/OS, System z y
| entornos multiplataforma (Microsoft Windows, HP-UX, Sun’s Solaris, IBM AIX y
| Linux).
“Herramientas que ayudan a mejorar el rendimiento de las consultas” en la
página 263
“Rol de las agrupaciones de almacenamientos intermedios en la puesta en
antememoria de datos”
″Utilización de herramientas para supervisar el rendimiento″ (DB2 Performance
Modos de mover datos eficazmente en el sistema

A medida que los datos progresa a través de un subsistema DB2, se mueven del
disco a la memoria y al usuario final o a aplicaciones. Es necesario ajustar los
recursos y objetos del sistema tales como agrupaciones de almacenamientos
intermedios, espacios de tablas e índices que contienen datos para mantener la
eficacia del flujo de datos.
Rol de las agrupaciones de almacenamientos intermedios en

la puesta en antememoria de datos
Las agrupaciones de almacenamientos intermedios son áreas de almacenamiento virtual
que almacenan temporalmente páginas de datos que se han captado de espacios de
tablas o índices. Las agrupaciones de almacenamientos intermedios son un
elemento clave en el rendimiento de DB2.
DB2 puede recuperar una página desde una agrupación de almacenamientos

intermedios mucho más rápido que desde disco. Cuando los datos ya están en un
almacenamiento intermedio, un programa de aplicación evita el retraso de la
espera a que DB2 recupere los datos desde disco.
DB2 le permite utilizar un máximo de 50 agrupaciones de almacenamientos

intermedios que contengan páginas de 4 KB y un máximo de 10 agrupaciones de
almacenamientos intermedios que contengan páginas de 8 KB, 16 KB y 32 KB.
La figura siguiente muestra agrupaciones de almacenamientos intermedios con

páginas de 4 KB y 8 KB. El número de páginas que una agrupación de
almacenamientos intermedios contiene depende del tamaño de la agrupación de
almacenamientos intermedios.

Figura 44. Agrupaciones de almacenamientos intermedios con páginas de 4 KB y 8 KB
En cualquier momento, las páginas de una agrupación de almacenamientos

intermedios virtual puede estar en uso, actualizadas o disponibles.
v Las páginas en uso se están leyendo o actualizando actualmente. Los datos que
contienen están disponibles para que los utilicen otras aplicaciones.
v Las páginas actualizadas contienen datos que se han cambiado pero todavía no
se han escrito en disco.
v Las páginas disponibles están listas para utilizarse. Una página de entrada de
datos nuevos puede sobreescribir las páginas disponibles.
Para evitar E/S de disco, puede utilizar páginas actualizadas y disponibles que
contengan datos.
Cuando los datos del almacenamiento intermedio cambian, finalmente estos datos
deben volverse a escribir en disco. Debido a que DB2 no necesita escribir los datos
en disco inmediatamente, los datos pueden permanecer en la agrupación de
almacenamientos intermedios para otras utilizaciones. Los datos permanecen en la
agrupación de almacenamientos intermedios hasta que DB2 decide utilizar el
espacio para otra página. Hasta este momento, las aplicaciones pueden leer o
cambiar los datos sin ninguna operación de E/S de disco.
El factor clave que afecta al rendimiento de las agrupaciones de almacenamientos

intermedios es su tamaño. El método que DB2 utiliza para acceder a las
agrupaciones de almacenamientos intermedios también afecta al rendimiento.
Tamaño de agrupación de almacenamientos intermedios
El tamaño de las agrupaciones de almacenamientos intermedios es decisivo para

las características de rendimiento de una aplicación o un grupo de aplicaciones que
accede a los datos de dichas agrupaciones de almacenamientos intermedios.
El ajuste de las agrupaciones de almacenamientos intermedios pueden mejorar el

tiempo de respuesta y el rendimiento de las aplicaciones y proporcionar una
utilización óptima de los recursos. Por ejemplo, las aplicaciones que realizan
proceso en línea es más probable que necesiten agrupaciones de almacenamientos
intermedios grandes debido a que a menudo necesitan volver a acceder a los

datos. En este caso, el almacenamiento de grandes cantidades de datos en una
agrupación de almacenamientos intermedios permite a las aplicaciones acceder a
los datos más eficazmente.
Al hacer que las agrupaciones de almacenamiento sean lo más grandes posible

puede conseguir las ventajas siguientes:
v Menos operaciones de E/S como resultado, lo que significa un acceso más
rápido a los datos.
v La contención de E/S se reduce para las tablas e índices que se utilizan con más
frecuencia.
v La velocidad de clasificación aumenta debido a la reducción de la contención de
E/S para archivos de trabajo.
Puede utilizar el mandato ALTER BUFFERPOOL para cambiar el tamaño y otras

características de una agrupación de almacenamientos intermedios en cualquier
momento mientras DB2 está en ejecución. Utilice los mandatos DISPLAY
BUFFERPOOL y ALTER BUFFERPOOL para reunir información de agrupación de
almacenamientos intermedios y cambiar los tamaños de agrupación de
almacenamientos intermedios.
DB2 Buffer Pool Analyzer for z/OS ayuda a los administradores de bases de datos
a gestionar las agrupaciones de almacenamientos intermedios más eficazmente al
proporcionar información sobre el comportamiento actual de la agrupación de
almacenamientos intermedios y al utilizar simulación para anticipar el
comportamiento futuro. Utilizando esta herramienta puede aprovechar las ventajas
siguientes:
v Recopilación de datos sobre la actividad de la agrupación de almacenamientos
intermedios virtual
v Informe completo de la actividad de la agrupación de almacenamientos
intermedios
v Utilización de la agrupación de almacenamientos intermedios simulada
v Informes y resultados de simulación
v Análisis experto disponible mediante un asistente de fácil utilización
Las posibilidades de DB2 Buffer Pool Analyzer se incluyen en OMEGAMON DB2

Performance Expert.
Acceso a páginas eficaz
DB2 determina cuándo debe utilizarse un método secuencial denominado

precaptación secuencial para leer páginas de datos con más rapidez. Con el método
de precaptación secuencial, DB2 determina por adelantado que se va a utilizar un
conjunto de páginas de datos. A continuación, DB2 lee el conjunto de páginas en
un almacenamiento intermedio con una única operación de E/S. El método de
precaptación se utiliza siempre para exploraciones de espacio de tablas y algunas
veces se utiliza para exploraciones de índice. La precaptación se realiza
simultáneamente con otras operaciones de E/S de aplicaciones.
Además de una precaptación secuencial predeterminada, DB2 también da soporte a

una precaptación dinámica. Una precaptación dinámica es un método más eficaz y
flexible que se basa en detección secuencial.
“Agrupaciones de almacenamientos intermedios” en la página 42
“Herramientas para análisis del rendimiento” en la página 247

Efecto de la compresión de datos en el rendimiento
En muchos casos, la compresión de datos en un espacio de tablas reduce
considerablemente la cantidad de espacio de disco necesario para almacenar datos
y también puede ayudar a mejorar el rendimiento de la agrupación de
almacenamientos intermedios. Por ejemplo, puede almacenar más datos en una
agrupación de almacenamientos intermedios y DB2 puede explorar más fácilmente
cantidades elevadas de datos.
Con datos comprimidos, las mejoras en el rendimiento dependen de la carga de

trabajo de SQL y la cantidad de compresión. Puede ver algunas de las ventajas
siguientes:
v Proporción más elevada de coincidencias de agrupación de almacenamientos
intermedios. La proporción de coincidencias determina la frecuencia con que se
accede a una página sin necesidad de una operación de E/S.
v Menos operaciones en las que DB2 accede a una página de datos.
La proporción de compresión que se consigue depende de las características de los

datos. La compresión puede funcionar muy bien con espacios de tablas grandes.
En espacios de tablas pequeños, el proceso de compresión de datos puede anular el
ahorro de espacio que proporciona la compresión.
Considere estos factores cuando decida si va a comprimir datos o no:

v DB2 comprime datos de una fila cada vez. Si DB2 determina que la compresión
de la fila no produce ningún ahorro, la fila no se comprime. Cuanto más se
acerca la longitud de fila media al tamaño de página real, menos eficaz es la
compresión.
v La compresión de datos cuesta tiempo de proceso. Aunque la descompresión de
datos cuesta menos que la compresión de datos, el coste global depende de los
patrones de los datos.
Si la proporción de compresión es inferior al 10%, la compresión no resulta

provechosa y, por lo tanto, no es recomendable. Puede utilizar el programa de
utilidad DSN1COMP para determinar la eficacia probable de la compresión de los
datos.
| Utilice la cláusula COMPRESS de las sentencias CREATE TABLESPACE y ALTER

| TABLESPACE para comprimir datos en un espacio de tablas, datos en una
| partición de un espacio de tablas particionado o datos en índices. No puede
| comprimir dato en espacios de tablas LOB o en espacios de tablas XML.
″Cómo ahorrar espacio mediante la compresión de datos″ (DB2 Administration
Guide)
″Determinación de la eficacia de la compresión″ (DB2 Performance Monitoring
and Tuning Guide)
Cómo puede afectar al rendimiento la organización de los

datos
| Para conseguir un rendimiento óptimo para los espacios de tablas e índices
| necesita mantener los datos organizados de forma eficaz. La utilización del espacio
| y la organización de los datos en un espacio de tablas y los índices asociados a
| veces afecta al rendimiento.

″Cuándo deben reorganizarse los índices y espacios de tablas″ (DB2
Performance Monitoring and Tuning Guide)
Utilización de espacio libre en almacenamiento de datos e

índices
| Un factor importante que influye en hasta qué punto los espacios de tablas e
| índices se ejecutan adecuadamente es la cantidad de espacio libre. Espacio libre hace
| referencia a la cantidad de espacio que DB2 deja en un espacio de tablas o índice
| cuando se cargan o reorganizan datos.
La liberación de páginas o de fragmentos de páginas puede mejorar el

rendimiento, en especial para aplicaciones que realizan inserciones de gran
volumen o que actualizan columnas de longitud variable. Cuando especifica una
cantidad suficiente de espacio libre, está negociando la cantidad de espacio de
disco utilizado para el rendimiento de determinadas sentencias de SQL. Por
ejemplo, la inserción de filas nuevas en espacio libre es más rápida que la división
de páginas de índices.
Utilice las cláusulas FREEPAGE y PCTFREE de las sentencias CREATE, ALTER

TABLESPACE e INDEX para establecer valores de espacio libre.
″Cuándo debe reservarse espacio libre″ (DB2 Performance Monitoring and
Tuning Guide)
Directrices para la reorganización de datos

Esta información proporciona directrices para determinar cuándo debería
considerar la reorganización de datos.
Únicamente debería ejecutar el programa de utilidad REORG para determinar qué

datos es necesario reorganizar. Si el rendimiento de las aplicaciones no se degrada,
no debería reorganizar datos. Incluso cuando algunas estadísticas indican que
existen datos que se están desorganizando, no siempre es necesario un trabajo del
programa de utilidad REORG, a menos que la desorganización exceda un umbral
especificado.
En las situaciones siguientes, es aconsejable la reorganización de datos:
Datos con el estado pendiente de REORG
Cuando existen espacios de tablas o particiones con el estado de pendiente de

REORG (REORP), no pueden seleccionar, insertar, actualizar o suprimir datos.
Debería reorganizar los espacios de tablas o particiones cuando el estado de
pendiente de REORG impone esta restricción.
Puede utilizar el mandato DISPLAY DATABASE RESTRICT para identificar los

espacios de tablas y particiones que es necesario reorganizar.
Datos con el estado de pendiente de REORG aconsejable
Después de cambiar definiciones de tabla o índice, debería considerar la

reorganización de datos para mejorar el rendimiento. Después de cambiar tipos de
datos o longitudes de columna utilizando sentencias ALTER TABLE, DB2 sitúa el
espacio de tablas que contiene los datos modificados en estado de pendiente de
REORG aconsejable (AREO*). El espacio de tabla está en estado de AREO* debido

a que los datos existentes no se convierten inmediatamente a su nueva definición.
La reorganización del espacio de tablas evita una posible degradación del
rendimiento.
Recomendación: Cuando los datos están en estado de pendiente de REORG o

AREO*, utilice el programa de utilidad REORG con la opción SCOPE PENDING
para reorganizar automáticamente particiones. Con esta opción, no es necesario
identificar primero qué particiones deben reorganizarse ni personalizar la sentencia
de control REORG.
Datos desviados
Cuando se utilizan espacios de tablas particionados, a veces puede encontrarse con

datos no equilibrados o desviados. Cuando existen datos desviados, el rendimiento
se puede ver afectado negativamente debido a la contención para E/S y otros
recursos. También puede producirse una situación en la que algunas particiones
están alcanzando su tamaño máximo y otras particiones tienen espacio sobrante.
Puede corregir los datos desviados de dos formas:

| v La versión actual proporciona un método más eficaz para reequilibrar
| particiones: Utilice la palabra clave REBALANCE del programa de utilidad
| REORG para reorganizar las particiones seleccionadas sin afectar la
| disponibilidad de los datos.
v El método más manual: Utilice las sentencias ALTER TABLE VALUES o ALTER
INDEX VALUES, seguidas de un trabajo de programa de utilidad REORG para
desplazar datos entre las particiones afectadas. Al redefinir los límites de
particiones de esta forma, las particiones de ambos lados del límite se sitúan en
estado de pendiente de REORG, con lo cual los datos dejan de estar disponibles
hasta que se ha reorganizado el espacio de tablas particionado.
Puede reequilibrar los datos cambiando los valores de clave límite de todas o la
mayoría de las particiones. La clave límite es el valor más alto de la clave de índice
para un partición. Se pueden aplicar uno o más cambios a la vez en las particiones,
lo cual hace que algunas partes relativamente pequeñas de los datos no estén
disponibles en un momento determinado.
Por ejemplo, suponga que un espacio de tablas contiene datos de ventas

particionados por año. El volumen de ventas puede ser muy alto algunos años y
muy bajo otros años. Cuando sucede esto, puede mejorar el rendimiento
reequilibrando las particiones para redistribuir los datos.
Con el método más eficaz, puede reorganizar las particiones 9 y 10 utilizando la

palabra clave REBALANCE del modo siguiente:
REORG TABLESPACE SALESDB.MONTHLYVOLUME PART(9:10) REBALANCE;
Ahora las particiones no están en un estado de REORP y los datos permanecen

disponibles.
Ejemplo: Suponga que la partición 9 contiene datos para el año 2002 en el cual el
volumen de ventas fue bajo y la partición 10 contiene datos para el año 2003 en el
cual volumen de ventas fue alto. Como resultado, decide cambiar el límite entre las
particiones 9 y 10. Utilizando el método más manual ALTER TABLE, puede
cambiar el límite del modo siguiente:
ALTER TABLE ALTER PARTITION 9 ENDING AT ("03/31/2003");

Las particiones de ambos lados del límite se sitúan en estado de REORP, con lo
cual dejan de estar disponibles hasta que se reorganizan las particiones.
Datos desorganizados o fragmentados
Cuando los datos se desorganizan o fragmentan, debería considerar la

reorganización de los espacios de tablas y los espacios de índice.
Debe considerar las situaciones siguientes para evaluar cuándo es necesaria la

reorganización de datos:
Espacio sin utilizar
En espacios de tablas simples, las tablas descartadas utilizan espacio que
no se reclama hasta que se reorganiza el espacio de tablas. Considere
ejecutar REORG si el porcentaje de espacio ocupado por filas de tablas
descartadas es superior al 10%. El valor de PERCDROP en la tabla de
catálogo SYSIBM.SYSTABLESPART identifica este porcentaje.
Espacios de páginas
Los índices pueden tener varios niveles de páginas. Una página de índice
que contiene pares de claves e identificadores y que apunta directamente a
datos recibe el nombre de página final.
| La supresión de claves de índice puede producir como resultado espacios
| de páginas con páginas finales. Los espacios también se pueden producir
| cuando DB2 inserta una clave de índice que no cabe en una página
| completa. A veces DB2 detecta inserciones secuenciales y divide las
| páginas de índice asimétricamente para mejorar la utilización y reducir el
| proceso de división. Puede mejorar el rendimiento todavía más
| seleccionando el tamaño de página adecuado para las páginas de índice. Si
| se producen espacios de páginas, considere ejecutar el programa de
| utilidad REORG.
Las columnas LEAFNEAR y LEAFFAR de SYSIBM.SYSINDEXPART
almacenan información sobre la desorganización de páginas finales físicas
indicando el número de páginas que no están en una posición óptima.
Actividad de E/S
Puede determinar cuándo puede estar aumentando la actividad de E/S en
un espacio de tablas. Un número elevado (relativo a valores anteriores que
ha recibido) para la opción NEARINDREF o FARINDREF indica un
aumento de la actividad de E/S. Considere una reorganización cuando la
suma de valores de NEARINDREF y FARINDREF supera el 10%.
Los valores de NEARINDREF y FARINDREF de las tablas de catálogo
SYSIBM.SYSTABLEPART y SYSIBM.SYSTABLEPART_HIST identifican el
número de filas reasignadas.
Recomendación: Cuando se produce un aumento de la actividad de E/S,

utilice un valor distinto de cero para la cláusula PCTFREE de la definición
de espacio de tablas. La cláusula PCTFREE especifica el porcentaje de cada
página de un espacio de tablas o índice queda libre cuando se cargan o
reorganizan datos. PCTFREE es una opción mejor que FREEPAGE.
Agrupación en clúster
Puede determinar si la agrupación en clústeres se está degradando. La
agrupación en clústeres se degrada cuando las filas de una tabla no se
almacenan en el mismo orden que las entradas de su índice de agrupación
en clúster. Un valor alto para la opción FAROFFPOSF puede indicar una

agrupación en clústeres inadecuada. La reorganización del espacio de
tablas puede mejorar el rendimiento. Aunque es menos crítico, un valor
alto para la opción NEAROFFPOSF también puede indicar que la
reorganización puede mejorar el rendimiento. Los valores de FAROFFPOSF
y NEAROFFPOSF de las tablas de catálogo SYSIBM.SYSINDEXPART y
SYSIBM.SYSINDEXPART_HIST identifican el número de filas que están
lejos y cerca de la posición óptima.
Umbrales de REORG
Puede utilizar los programas de utilidad RUNSTATS, REORG, REBUILD
INDEX y LOAD para recopilar estadísticas que describan la fragmentación
de espacios de tablas e índices. Estas estadísticas pueden ayudarle a
decidir cuándo debe ejecutar el programa de utilidad REORG para mejorar
el rendimiento o reclamar espacio.
Puede configurar el trabajo de REORG de acuerdo con los límites de
umbral establecidos para estadísticas pertinentes del catálogo. Las opciones
OFFPOSLIMIT e INDREFLIMIT especifican cuándo debe ejecutarse
REORG en espacios de tablas. Cuando un trabajo de REORG se ejecuta con
estas opciones, consulta en el catálogo las estadísticas pertinentes. El
trabajo de REORG no se produce a menos que se exceda uno de los
umbrales especificados. También puede especificar la opción
REPORTONLY para producir un informe que le indique si es
recomendable un trabajo de REORG.
″Cuándo deben reorganizarse los índices y espacios de tablas″ (DB2
Performance Monitoring and Tuning Guide)
Modos de mejorar el rendimiento para varios usuarios

Los bloqueos, si se utilizan para asegurar la integridad o la exactitud de los datos,
a veces pueden ser demasiado restrictivos y pueden causar un rendimiento lento y
un nivel bajo de coherencia. La comprensión del funcionamiento de los bloqueos
puede ayudarle a seleccionar las opciones adecuadas y a y mejorar el rendimiento.
Esta información describe cómo funcionan los bloqueos, por qué son críticos y
proporciona recomendaciones para aumentar la simultaneidad.
DB2 utiliza bloqueos en los datos del usuario. El principal motivo para utilizar
bloqueos es la integridad o la exactitud de los datos. Sin bloqueos, un usuario
podría recuperar un elemento de datos específico mientras otro usuario puede
estar cambiando esos datos. El resultado sería que el primer usuario recuperaría
datos inexactos. En el entorno DB2 for z/OS, que incluye cantidades elevadas de
datos y un gran número de usuarios y transacciones, la probabilidad de datos
inexactos es inaceptable. Por lo tanto, DB2 for z/OS proporciona bloqueos amplios
para asegurar la integridad de los datos.
A pesar de la importancia de la integridad de los datos, a veces los bloqueos

pueden ser demasiado restrictivos. Si un proceso de aplicaciones bloquea
demasiados datos, otros usuarios, programas de utilidad y procesos de aplicaciones
deben esperar para los datos bloqueados. Esta situación puede tener como
resultado una simultaneidad baja. Simultaneidad es la capacidad que tienen más de
un proceso de aplicaciones para acceder a los mismos datos esencialmente al
mismo tiempo. DB2 for z/OS maneja la negociación entre simultaneidad e
integridad de datos para maximizar la simultaneidad sin perjudicar la integridad
de los datos.

″Ajuste del rendimiento de DB2 para z/OS″ (DB2 Performance Monitoring and
Tuning Guide)
Rendimiento mejorado mediante la utilización de bloqueos

| DB2 utiliza bloqueos sobre varios objetos de datos, entre los que se incluyen filas,
| páginas, tablas, segmentos de espacio de tablas, particiones de espacio de tablas,
| espacios de tablas enteros y bases de datos. Cuando una aplicación adquiere un
| bloqueo, la aplicación “mantiene” o “posee” el bloqueo.
| Las siguientes modalidades de boqueo proporcionan distintos grados de

| protección:
Bloqueo de compartimiento (bloqueo S)
El propietario del bloqueo y cualquier proceso simultáneo puede leer, pero
no cambiar, el objeto bloqueado. Otros procesos simultáneos pueden
adquirir bloqueos de compartimiento o actualización para el objeto de DB2.
Bloqueo de actualización (bloqueo U)
El propietario del bloqueo puede leer, pero no cambiar, el objeto de DB2.
Los procesos simultáneos pueden adquirir bloqueos de compartimiento y
pueden leer el objeto de DB2, pero ningún otro proceso puede adquirir un
bloqueo de actualización. Antes de realizar realmente el cambio en los
datos, DB2 aumenta los bloqueos de actualización a bloqueos de
exclusividad.
Bloqueo de exclusividad (bloqueo X)
El propietario del bloqueo puede leer o cambiar los datos bloqueados. Un
proceso simultáneo no puede adquirir bloqueos de compartimiento, de
actualización o de exclusividad sobre los datos. Sin embargo, el proceso
simultáneo puede leer los datos sin adquirir un bloqueo sobre el objeto de
DB2.
Las modalidades de bloqueo determinan si un bloqueo es compatible con otro.
Ejemplo: Suponga que un proceso de aplicaciones A mantiene un bloqueo sobre

un espacio de tablas al cual también desea acceder el proceso B. DB2 solicita, en
nombre de B, un bloqueo de alguna modalidad en particular. Si la modalidad de
bloqueo de A permite la petición de B, los dos bloqueos (o modalidades) son
compatibles. Si los dos bloqueos no son compatibles, B no puede continuar; debe
esperar hasta que A libere su bloqueo. (En realidad, B debe esperar hasta que se
liberen todos los bloqueos incompatibles existentes.)
La compatibilidad para bloqueos de páginas y filas es fácil de definir. La tabla

siguiente muestra si los bloqueos de páginas o los bloqueos de filas de dos
modalidades cualquiera son compatibles. Los bloqueos de páginas y los bloqueos
de filas nunca son compatibles entre sí debido a que un espacio de tablas no puede
utilizar a la vez bloqueos de páginas y bloqueos de filas.
Tabla 38. Matriz de compatibilidad de modalidades de bloqueo de páginas y bloqueo de filas
Modalidad de Compartimiento Actualización Exclusividad
bloqueo (bloqueo S) (bloqueo U) (bloqueo X)
Compartimiento Sí Sí No
(bloqueo S)
Actualización Sí No No
(bloqueo U)

Tabla 38. Matriz de compatibilidad de modalidades de bloqueo de páginas y bloqueo de
filas (continuación)
Modalidad de Compartimiento Actualización Exclusividad
bloqueo (bloqueo S) (bloqueo U) (bloqueo X)
Exclusividad No No No
(bloqueo X)
Los bloqueos de compartimiento, actualización y de exclusividad se aplican a

bloqueos de filas o páginas. Estos hechos se aplican únicamente a procesos de
aplicaciones que adquieren un bloqueo de intención sobre el espacio de tablas y la
tabla, si la tabla está un espacio de tablas segmentado.
Un bloqueo de intención indica el plan que el proceso de aplicaciones tiene para

acceder a los datos. Los dos tipos de bloqueos de intención son de intención de
compartimiento e intención de exclusividad.
La compatibilidad para bloqueos de espacios de tablas es más compleja.
A pesar de la importancia de los bloqueos en el entorno DB2, pueden producirse

algunos problemas de bloqueo, tal como muestra la lista siguiente:
Suspensión
Un proceso de aplicaciones se suspende cuando solicita un bloqueo que ya
mantiene otro proceso de aplicaciones, si dicho bloqueo no es un bloqueo
compartido. El proceso suspendido detiene temporalmente su ejecución y
reanuda la ejecución en las circunstancias siguientes:
v Todos los procesos que mantienen el bloqueo conflictivo lo liberan.
v El proceso peticionario experimenta un tiempo de espera excedido o un
punto muerto y el proceso se reanuda y maneja una condición de error.
Tiempo de espera excedido
Un proceso de aplicaciones excede el tiempo de espera cuando termina debido
a una suspensión que excede un intervalo preestablecido. DB2 termina el
proceso, emite mensajes y devuelve códigos de error. Las operaciones de
confirmación y de retrotracción no exceden el tiempo de espera. Sin
embargo, el mandato STOP DATABASE puede exceder el tiempo de espera
y en este caso DB2 envía mensajes a la consola; el mandato STOP
DATABASE se puede reintentar un máximo de 15 veces.
Punto muerto
Un punto muerto se produce cuando dos o más procesos de aplicaciones
mantienen bloqueos sobre recursos que otros usuarios necesitan y sin los
cuales no pueden proseguir. Después de un intervalo de tiempo
preestablecido, DB2 puede retrotraer la unidad de trabajo actual o solicitar
a un proceso que termine. Por ello DB2 libera los bloqueos y permite que
los procesos restantes continúen.
Aunque se pueden producir algunos problemas de bloqueo, puede evitar

problemas de bloqueo del sistema y de aplicaciones.
Los siguientes casos de ejemplo ilustran porqué el bloqueo es crítico.
Caso de ejemplo: Evitación de la pérdida de datos actualizados
Dos usuarios, Kathy y Frank, intentan acceder a la misma tabla de DB2. Se

produce lo siguiente:
1. Kathy lee el valor de datos, 100, en una variable de lenguaje principal.
2. Frank lee el mismo valor de columna en una variable de lenguaje principal.
3. Kathy añade 10 al valor de variable de lenguaje principal y guarda el valor
nuevo, 110, en la columna de la tabla de DB2.
4. Frank añade 20 al valor de variable de lenguaje principal y guarda el valor
nuevo, 120, en la columna de la tabla de DB2.
Este caso de ejemplo no utiliza bloqueo. Muestra que el valor actualizado de la

columna depende de qué usuario confirme los datos primero. Si Kathy confirma
primero, el valor de la columna actualizado es 120 y se pierde la actualización de
Kathy. Si Frank confirma primero, el valor de la columna actualizado es 110 y se
pierde la actualización de Frank.
El caso de ejemplo cambia si incluye bloqueo. Cuando lea el proceso siguiente,

suponga que se utiliza un cursor actualizable. Se produce lo siguiente:
1. Kathy lee el valor de columna 100 en una variable de lenguaje principal con la
intención de actualizar el valor. A continuación, DB2 otorga un bloqueo de
actualización a Kathy.
2. Frank quiere leer el mismo valor de columna en una variable de lenguaje
principal con la intención de actualizar el valor. De acuerdo con la matriz de
compatibilidad de la tabla anterior, DB2 no otorga a Frank un bloqueo de
actualización (bloqueo U) sobre el objeto de DB2 que contiene el valor de
columna 100. Por lo tanto, Frank deberá esperar para leer el valor de columna
hasta que Kathy libere el bloqueo.
3. Kathy añade 10 al valor de variable de lenguaje principal y quiere guardar el
valor nuevo, 110, en la columna de la tabla de DB2. En este punto, DB2 cambia
el bloqueo U por un bloqueo de exclusividad (bloqueo X) sobre el objeto de
DB2 que contiene el valor de columna.
4. Kathy confirma el cambio. A continuación, DB2 libera el bloqueo X sobre el
objeto de DB2 que contiene el valor de columna. Después, DB2 otorga el
bloqueo U a Frank sobre el mismo objeto (a menos que Frank haya excedido el
tiempo de espera de acceso). La variable de lenguaje principal que Frank ha
especificado ahora contiene el valor actualizado de 110.
5. Frank añade 20 al valor de variable de lenguaje principal y quiere guardar el
valor nuevo, 130, en la columna de la tabla. DB2 cambia el bloqueo U por un
bloqueo X sobre el objeto de DB2 que contiene el valor de columna.
6. Frank confirma el cambio. A continuación, DB2 libera el bloqueo X sobre el
objeto de DB2 que contiene el valor de columna.
Si este caso de ejemplo no incluyera cursores actualizables, DB2 otorgaría un

bloqueo de compartimiento (bloqueo S) a Kathy en lugar de un bloqueo U en el
paso 1. DB2 también otorgaría un bloqueo S a Frank en el paso 2. Si Kathy y Frank
intentaran actualizar el valor de columna a la vez, se produciría un punto muerto.
Cuando se produce un punto muerto, DB2 decide si debe retrotraer el trabajo de
Kathy o el trabajo de Frank. Una retrotracción se produce cuando DB2 invierte un
cambio que un proceso de aplicaciones individual ha intentado realizar. Si DB2
retrotrae los cambios de Kathy, Kathy libera los bloqueos y Frank puede completar
el proceso. A la inversa, si DB2 retrotrae los cambios de Frank, Frank libera los
bloqueos y Kathy puede completar el proceso.
Los programas de aplicaciones pueden minimizar el riesgo de situaciones de punto

muerto utilizando la cláusula FOR UPDATE OF de la sentencia DECLARE
CURSOR. En realidad el programa no adquiere el bloqueo U hasta que se libera
cualquier otro bloqueo U o X sobre el objeto de datos.

Caso de ejemplo: Evitación del acceso de lectura a datos sin
confirmar
Dos usuarios, Kathy y Frank, intentan acceder a la misma tabla de DB2.

1. Kathy actualiza el valor de 100 a 0 en la columna de la tabla de DB2.
2. Frank lee el valor actualizado de 0 y toma decisiones de programa basándose
en este valor.
3. Kathy cancela el proceso y cambia el valor de 0 de nuevo a 100 para la
columna de la tabla de DB2.
Este caso de ejemplo no incluye bloqueos. Muestra que Frank ha tomado una
decisión de programa incorrecta. Como resultado, los datos de la empresa de la
base de datos pueden ser inexactos.
Cuando este caso de ejemplo incluye bloqueo, se produce lo siguiente:

1. Kathy intenta actualizar el valor de 100 a 0 en la columna de la tabla. DB2
otorga un bloqueo X a Kathy sobre el objeto de DB2 que contiene el valor de
columna que debe actualizarse.
2. Frank intenta leer el valor de columna actualizado para poder tomar decisiones
de programa basándose en este valor. DB2 no permite que Frank lea el valor de
columna actualizado de 0. Frank intenta adquirir un bloqueo S sobre el objeto
de DB2 que actualmente tiene el bloqueo X. Frank debe esperar hasta que
Kathy confirme o retrotraiga el trabajo.
3. Kathy cancela el proceso y cambia el valor de 0 de nuevo al valor original de
100 para la columna de la tabla de DB2. DB2 realiza el cambio real en los datos
y libera el bloqueo X para Kathy. A continuación, DB2 otorga el bloqueo S a
Frank sobre el objeto de DB2 que contiene el valor de columna. Después, Frank
lee el valor de 100.
Cuando el caso de ejemplo incluye bloqueos, Frank lee los datos correctos y, por lo
tanto, puede tomar la decisión de programa correcta. Como resultado, los datos de
la empresa de la base de datos son exactos.
Caso de ejemplo: Evitación de actualizaciones entre varias

lecturas dentro de una unidad de trabajo
En este caso de ejemplo, Kathy quiere leer los mismos datos dos veces. Ningún
otro programa ni usuario puede cambiar los datos entre las dos lecturas.
Suponga que Kathy utiliza la siguiente sentencia de SQL:

SELECT * FROM EMP
WHERE SALARY>
(SELECT AVG(SALARY) FROM EMP);
Esta sentencia de SQL lee la tabla EMP dos veces:

1. Calcula el promedio de los valores de la columna SALARY de todas las filas de
la tabla.
2. Busca todas las filas de la tabla EMP que tienen un valor en la columna
SALARY que excede el valor de promedio.
Si Kathy no bloquea los datos entre los dos procesos de lectura, otro usuario puede
actualizar la tabla EMP entre los dos procesos de lectura. Esta actualización puede
hacer que Kathy obtenga un resultado incorrecto.

Kathy podría utilizar bloqueos de DB2 para asegurarse de que no se produzca
ningún cambio en la tabla entre los dos procesos de lectura. Kathy puede elegir
entre estas opciones:
v Utilizar el paquete o nivel de aislamiento de plan de lectura repetible (RR) o
utilizar la cláusula WITH RR en la sentencia SQL SELECT.
v Bloquear la tabla en modalidad de compartimiento o de exclusividad utilizando
una de estas sentencias:
– LOCK TABLE EMP IN SHARE MODE
– LOCK TABLE EMP IN EXCLUSIVE MODE
Tuning Guide)
″Supervisión del bloqueo de DB2″ (DB2 Performance Monitoring and Tuning
Guide)
Rendimiento mejorado mediante control de simultaneidad

El control de simultaneidad se basa, en parte, en niveles de aislamiento, que
determinan hasta qué punto debe aislarse una aplicación de los efectos de otras
aplicaciones que se ejecutan.
DB2 proporciona los siguientes niveles de aislamiento:

Lectura repetible (RR)
El aislamiento de RR proporciona la mayor protección contra otras
aplicaciones. Con RR, las filas a las que hace referencia una aplicación no
pueden ser actualizadas por otras aplicaciones antes de que la aplicación
alcance un punto de confirmación.
Estabilidad de lectura (RS)
El aislamiento de RS permite que una aplicación pueda leer las mismas
páginas o filas más de una vez mientras que se impide que otro proceso
pueda cambiar las filas. Sin embargo, otras aplicaciones pueden insertar o
actualizar filas que no cumplían la condición de búsqueda de la aplicación
original.
Estabilidad del cursor (CS)
El aislamiento de CS permite la máxima simultaneidad con integridad de
datos. Con CS, una transacción sólo mantiene bloqueos para los cambios
no confirmados y para la fila actual de cada uno de sus cursores.
Lectura no confirmada (UR)
El aislamiento de UR permite que la aplicación pueda leer datos sin
confirmar.
DB2 utiliza bloqueos y depende de ellos debido al requisito de integridad de datos.

Sin embargo, los bloqueos a veces causan problemas como, por ejemplo, puntos
muertos, tiempos de espera excedidos y suspensiones. Para minimizar estos
problemas y aumentar la simultaneidad, los diseñadores de bases de datos y los
diseñadores de aplicaciones pueden realizar varias acciones.
Recomendaciones para diseñadores de bases de datos
Los diseñadores de bases de datos pueden realizar las acciones generales siguientes
para aumentar la simultaneidad sin comprometer la integridad de los datos:

v Mantener juntos los elementos iguales en la base de datos. Por ejemplo, intente
agrupar en clúster tablas pertinentes a la misma aplicación en la misma base de
datos.
v Mantener separados los elementos diferentes en la base de datos. Por ejemplo,
suponga que el usuario A posee la tabla A y el usuario B posee la tabla B. Al
mantener la tabla A y la tabla B en bases de datos separadas se pueden crear o
descartar índices en estas dos tablas al mismo tiempo sin causar contención de
bloqueo.
v Utilizar la cláusula LOCKSIZE ANY de la sentencia CREATE TABLESPACE, a
menos que se haga otra cosa, resulta preferible.
v Examinar tablas pequeñas, en busca de oportunidades para mejorar la
simultaneidad reorganizando datos o cambiando el método de bloqueo.
v Particionar los datos.
v Particionar índices secundarios. El uso de índices secundarios particionados de
datos aumenta la independencia de partición y, por lo tanto, puede reducir la
contención de bloqueo.
v Minimizar la actividad de actualización que mueve filas entre particiones.
v Almacenar menos filas de datos en cada página de datos.
Recomendaciones para diseñadores de aplicaciones
Los diseñadores de aplicaciones pueden realizar las acciones generales siguientes

para aumentar la simultaneidad sin comprometer la integridad de los datos:
v Acceder a los datos en un orden coherente. Por ejemplo, las aplicaciones
deberían acceder generalmente a los mismos datos en el mismo orden.
v Confirmar el trabajo tan pronto como se realiza resulta práctico, para evitar
contenciones de bloqueo innecesarias.
v Reintentar una aplicación después de un punto muerto o un tiempo de espera
excedido para intentar recuperarse de la situación sin ayuda.
v Cerrar los cursores para liberar los bloqueos y liberar los recursos retenidos por
los bloqueos.
v Vincular planes con la cláusula ACQUIRE(USE), que es la mejor opción para
simultaneidad.
v Vincular con ISOLATION(CS) y CURRENTDATA(NO) en la mayoría de casos.
ISOLATION(CS) normalmente permite que DB2 libere los bloqueos adquiridos
en cuanto es posible. CURRENTDATA(NO) normalmente permite que DB2 evite
adquirir bloqueos lo más frecuente posible.
v Utilizar transacciones globales, lo cual permite que DB2 y otros gestores de
transacciones participen en una única transacción y, de este modo, compartan los
mismos bloqueos y accedan a los mismos datos.
Tuning Guide)
Modos de mejorar el rendimiento de las consultas

Las vías de acceso son un factor significativo en el rendimiento de DB2. DB2 elige
las vías de acceso, pero el usuario puede utilizar herramientas para comprender
cómo las vías de acceso influyen en el rendimiento en determinadas situaciones.
Una vía de acceso es la vía que DB2 utiliza para localizar datos que se especifican en
sentencias de SQL. Una vía de acceso puede ser indexada o secuencial.

Dos factores importantes en el rendimiento de una sentencia de SQL son la
cantidad de tiempo que DB2 utiliza para determinar la vía de acceso durante el
tiempo de ejecución y la eficacia de la vía de acceso. DB2 determina la vía de
acceso para una sentencia cuando se vincula el plan o paquete que contiene la
sentencia de SQL o cuando se ejecuta la sentencia de SQL.
El momento en que DB2 determina la vía de acceso depende de si la sentencia se

ejecuta de forma estática o dinámica y de si la sentencia contiene variables de
lenguaje principal de entrada.
La vía de acceso que DB2 elige determina cuánto tardará la ejecución de la

sentencia de SQL. Por ejemplo, para ejecutar una consulta de SQL que une dos
tablas, DB2 dispone de varias opciones. DB2 puede elegir cualquiera de las
opciones siguientes para procesar estas uniones:
v Explorar la tabla PARTS para encontrar cada fila que coincida con una fila de la
tabla PRODUCTS.
v Explorar la tabla PRODUCTS para encontrar cada fila que coincida con una fila
de la tabla PARTS.
v Clasificar ambas tablas por orden de PROD# y, a continuación, fusionar las
tablas ordenadas para procesar la unión.
La selección de la mejor vía de acceso para una sentencia de SQL depende de

varios factores. Estos factores incluyen el contenido de cualquier tabla que la
sentencia de SQL consulte y los índices de dichas tablas.
DB2 también utiliza información estadística amplia sobre la utilización de bases de

datos y recursos para seleccionar las mejores opciones de acceso.
Además, la organización física de los datos del almacenamiento influye en el nivel

de eficacia de DB2 al procesar una consulta.
Tuning Guide)
Utilización de EXPLAIN para comprender la vía de acceso

La utilización primaria de EXPLAIN consiste en visualizar las vías de acceso para
las partes SELECT de las sentencias. Esta información describe lo que proporciona
EXPLAIN y cómo puede obtener información de EXPLAIN.
La información de la tabla de planes puede ayudarle cuando necesite realizar las

tareas siguientes:
v Determinar la vía de acceso que DB2 elige para una consulta
v Diseñar bases de datos, índices y programas de aplicaciones
v Determinar cuándo debe volverse a vincular una aplicación
Para cada acceso a una única tabla, EXPLAIN indica si DB2 utiliza acceso de índice
o una exploración de espacio de tablas. Para índices, EXPLAIN indica cuántos
índices y columnas de índice se utilizan y qué métodos de E/S se utilizan para leer
las páginas. Para uniones de tablas, EXPLAIN indica el método y tipo de unión, el
orden en que DB2 une las tablas y las ocasiones en que clasifica filas y los motivos.
Los pasos siguientes resumen cómo obtener información de EXPLAIN:

1. Cree una tabla de planes.

Para poder utilizar EXPLAIN, primero debe crear una tabla de planes para que
contenga los resultados de EXPLAIN.
2. Llene la tabla de planes.
Puede llenar la tabla de planes ejecutando la sentencia EXPLAIN de SQL.
También puede llenar una tabla de planes al vincular o volver a vincular un
plan o paquete especificando la opción EXPLAIN(YES). EXPLAIN obtiene
información sobre las vías de acceso para todas las sentencias de SQL
explicables de un paquete o de los DBRM de un plan.
3. Seleccione la información de la tabla de planes.
Varios procesos pueden insertar filas en la misma tabla de planes. Para
comprender las vías de acceso, debe recuperar las filas de una consulta
determinada en el orden adecuado.
EXPLAIN le ayuda a responder a preguntas sobre rendimiento; las respuestas le

proporcionan la información que necesita para mejorar el rendimiento. EXPLAIN
indica si DB2 ha utilizado un índice para acceder a los datos, si se han realizado
clasificaciones, si se ha utilizado proceso paralelo, etc.
A medida que gana experiencia al trabajar con DB2, puede utilizar la tabla de
planes para proporcionar sugerencias de optimización a DB2 que influyan en la
selección de vía de acceso.
″Utilización de EXPLAIN para capturar información sobre sentencias de SQL″
(DB2 Performance Monitoring and Tuning Guide)
Tuning Guide)
Herramientas que ayudan a mejorar el rendimiento de las

consultas
Existen varias herramientas de análisis de rendimiento que pueden ayudarle a
mejorar el rendimiento de SQL.
Estas herramientas incluyen:

v Optimization Service Center for DB2 for z/OS (OSC), una herramienta de
estación de trabajo adecuada para el análisis de la salida de EXPLAIN
v OMEGAMON DB2 Performance Expert, una herramienta que puede ayudarle
con el rendimiento de SQL
v EXPLAIN, una herramienta de supervisión de DB2
v DB2 SQL Performance Analyzer, una herramienta que proporciona un análisis
amplio de consultas de SQL sin ejecutarlas.
| Optimization Service Center for DB2 for z/OS
| IBM Optimization Service Center for DB2 for z/OS (DB2 OSC) es una herramienta
| de estación de trabajo para supervisar y ajustar las sentencias de SQL que se
| ejecutan como parte de una carga de trabajo en el subsistema DB2 para z/OS.
| Puede utilizar DB2 OSC para identificar y analizar sentencias problemáticas y
| recibir consejo experto sobre las sentencias que puede reunir para mejorar el
| rendimiento de una sentencia individual o de toda una carga de trabajo.
| Utilizando DB2 OSC puede reunir información de EXPLAIN para sentencias de

| SQL y ver dicha información de EXPLAIN en un formato gráfico, aclarando al

| instante las relaciones entre objetos (por ejemplo, tablas e índices) y operaciones
| (por ejemplo, exploraciones de espacio de tablas y clasificaciones).
| También puede utilizar DB2 OSC para diseñar gráficamente sugerencias de plan
| para sugerir mejores vías de acceso a DB2 y desplegar estas sugerencias de plan en
| el subsistema DB2 para z/OS.
| Después de ajustar el rendimiento de una sentencia o de una carga de trabajo,

| puede crear perfiles de supervisión para realizar un seguimiento e informar del
| estado de las sentencias de SQL en una carga de trabajo durante un proceso
| normal y para avisarle de los problemas de desarrollo cuando una sentencia
| excede los umbrales de excepción.
| DB2 OSC se ofrece en DB2 Accessories Suite for z/OS. Puede utilizar DB2 OSC en
| una estación de trabajo Windows 2000, Windows XP o Windows 2003 que tenga
| instalado DB2 Connect Enterprise Edition o DB2 Connect Personal Edition, Versión
| 8.1.7.
| DB2 Optimization Expert for z/OS
| IBM DB2 Optimization Expert for z/OS es una herramienta de estación de trabajo
| basada en información experta para la supervisión y el ajuste de sentencias de SQL
| y cargas de trabajo. Además de Optimization Service Center, la creación de
| Optimization Expert amplía las herramientas de ajuste con consejeros basados en
| información experta que pueden recomendarle cómo puede reescribir sentencias de
| SQL, crear índices o reconfigurar recursos del sistema para mejorar el rendimiento
| de sentencias de SQL individuales y de cargas de trabajo completas que se ejecutan
| en el subsistema DB2 para z/OS.
EXPLAIN de DB2
EXPLAIN de DB2 es una herramienta de supervisión que produce la información

siguiente:
v Un plan, un paquete o una sentencia de SQL cuando se vincula. La salida
aparece en una tabla que crea el usuario, llamada tabla de plan.
v El coste estimado de la ejecución de una sentencia SELECT, INSERT, UPDATE o
DELETE. La salida aparece en una tabla que crea el usuario, llamada tabla de
sentencia.
v Las funciones definidas por el usuario a las que se hace referencia en una
sentencia de SQL, incluidos el nombre y esquema específicos de la función. La
salida aparece en una tabla que crea el usuario, llamada tabla de función.
DB2 SQL Performance Analyzer
DB2 SQL Performance Analyzer le proporciona un análisis amplio de consultas de

SQL sin ejecutarlas. Este análisis le ayuda a ejecutar las consultas para conseguir el
máximo rendimiento. DB2 SQL Performance Analyzer le ayuda a reducir los costes
cada vez mayores de consultas de bases de datos mediante la estimación de su
coste antes de su ejecución.
La utilización de DB2 SQL Performance Analyzer le ayuda a:

v Estimar la posible duración de las consultas
v Evitar que las consultas tarden demasiado tiempo en ejecutarse
v Analizar nuevas vías de acceso

v Codificar eficazmente la utilización de las sugerencias y los consejos que
proporciona la herramienta
Tuning Guide)
Análisis del rendimiento de consultas y aplicaciones

El análisis del rendimiento de consultas y aplicaciones se inicia realizando algunas
preguntas básicas.
Para mejorar el rendimiento de las consultas y aplicaciones es necesario responder

a algunas preguntas básicas para determinar hasta qué punto las consultas y
aplicaciones se ejecutan adecuadamente.
¿Están al día las estadísticas del catálogo?
| Mantener las estadísticas de objetos actualizadas es una actividad importante. DB2

| necesita estas estadísticas para elegir la vía de acceso óptima a los datos.
El programa de utilidad RUNSTATS recopila estadísticas sobre objetos de DB2.

Estas estadísticas se almacenan en el catálogo de DB2. DB2 utiliza esta información
durante el proceso de vinculación para elegir una vía de acceso. Si el usuario no
utiliza RUNSTATS y a continuación vuelve a vincular los paquetes o planes, DB2
no tiene la información que necesita para elegir la vía de acceso más eficaz. La
falta de información estadística puede dar como resultado operaciones de E/S
innecesarias y un consumo excesivo del procesador.
Recomendación: Ejecute RUNSTATS como mínimo una vez para cada tabla y sus
índices asociados. La frecuencia con la que debe volver a ejecutar el programa de
utilidad depende de hasta qué punto necesita que el catálogo esté actualizado. Si
las características de los datos de una tabla varían significativamente con el tiempo,
debería mantener el catálogo actualizado con estos cambios. RUNSTATS es más
provechoso cuando se ejecuta en los objetos siguientes:
v Espacios de tablas que contienen tablas a las que se accede con frecuencia
v Tablas que están implicadas en operaciones de clasificación
v Tablas con muchas filas
v Tablas consultadas por sentencias SELECT que incluyen muchos argumentos de
búsqueda
v Tablas con índices
| Una herramienta que puede ayudarle a mantener las estadísticas actualizadas es

| Optimization Service Center for DB2 for z/OS (OSC). OSC es una herramienta de
| estación de trabajo para supervisar y ajustar las sentencias de SQL que se ejecutan
| como parte de una carga de trabajo en el subsistema de DB2 para z/OS. Puede
| utilizar OSC para identificar y analizar sentencias problemáticas y recibir consejo
| experto sobre las estadísticas que puede reunir para mejorar el rendimiento de una
| sentencia individual o de toda una carga de trabajo.
¿Se ha codificado la consulta de la manera más simple?
Asegúrese de que la consulta de SQL se haya codificado de la manera más simple

y eficaz posible. Asegúrese de que:
v No se seleccionen columnas no utilizadas.
v No existan cláusulas ORDER BY o GROUP BY innecesarias en la consulta.

v No existan predicados innecesarios en la consulta.
¿Está utilizando tablas de consultas materializadas?
Defina tablas de consultas materializadas para mejorar el rendimiento de las

consultas dinámicas que operan en cantidades muy grandes de datos e implican
varias uniones. DB2 genera los resultados de todas las consultas o parte de ellas de
antemano y almacena los resultados en tablas de consultas materializadas. DB2
determina cuándo la utilización de los resultados previamente calculados es
probable que optimice el rendimiento de las consultas dinámicas.
¿Se accede mediante un índice?
Un índice proporciona un acceso eficaz a los datos. DB2 utiliza diferentes tipos de
exploraciones de índice, cada uno de los cuales afecta de forma diferente al
rendimiento. Algunas veces DB2 puede evitar una clasificación utilizando un
índice.
Si una consulta se satisface utilizando únicamente el índice, DB2 utiliza un método

denominado acceso de sólo índice.
v Para una operación SELECT, si todas las columnas necesarias para la consulta se
encuentran en el índice, DB2 no necesita acceder a la tabla.
v Para una operación UPDATE o DELETE, se puede realizar una exploración de
sólo índice para buscar filas calificadoras para actualizarlas o suprimirlas. Una
vez identificadas las filas calificadoras, DB2 primero debe recuperar estas filas
del espacio de tablas para poderlas actualizar o suprimir.
Otros tipos de exploraciones de índice que DB2 puede utilizar son exploraciones
de índice coincidentes o no coincidentes.
v En una exploración de índice coincidente, la consulta utiliza predicados que
coinciden con las columnas de índice. Los predicados proporcionan filtrado; DB2
tan solo necesita acceder a determinadas páginas de datos e índices.
v En una exploración de índice no coincidente, DB2 lee todas las claves de índice
y sus filas de datos. Este tipo de exploración es menos probable que proporcione
una vía de acceso eficaz que una exploración de índice coincidente.
Además de proporcionar un acceso selectivo a los datos, los índices también

pueden ordenar datos y a veces eliminan la necesidad de clasificaciones. Se pueden
evitar algunas clasificaciones si las claves de índice están en el orden necesario
para ORDER BY, GROUP BY, una operación de unión o DISTINCT en una función
de totales. Si desea evitar una clasificación, considere la creación de un índice en
las columnas necesarias para proporcionar dicho orden.
¿Se utiliza una exploración de espacio de tablas?
Cuando no es posible un acceso de índice, DB2 utiliza una exploración de espacio

de tablas. DB2 generalmente utiliza el método de precaptación secuencial para
explorar espacios de tablas.
Ejemplo: Suponga que la tabla T no tiene ningún índice en la columna C1. En el

ejemplo siguiente DB2 utiliza una exploración de espacio de tablas:
SELECT * FROM T WHERE C1 = VALUE;
En este caso, cada fila de la tabla T debe examinarse para determinar si el valor de
C1 coincide con el valor proporcionado.

Una exploración de espacio de tablas en un espacio de tablas particionado puede
ser más eficaz que una exploración en un espacio de tablas no particionado. DB2
puede beneficiarse de las particiones limitando la exploración de datos en un
espacio de tablas particionado a una o más particiones.
¿Se realizan clasificaciones?
El hecho de minimizar la necesidad de que DB2 utilice clasificaciones para

procesar una consulta puede tener como resultado un mejor rendimiento. En
general, intente crear índices que coincidan con los predicados de las consultas
antes de intentar evitar clasificaciones en las consultas.
¿Se accede a los datos o se procesan los datos en paralelo?

El proceso en paralelo se aplica a consultas de sólo lectura. DB2 puede utilizar
operaciones de CPU y E/S paralelas para mejorar el rendimiento. Por ejemplo,
DB2 puede utilizar varias operaciones paralelas para acceder a datos de una tabla
o de un índice. El tiempo de respuesta para consultas intensivas de datos o
intensivas de procesador pueden reducirse significativamente.
¿Se utilizan variables de lenguaje principal?
Cuando se especifica la opción de vinculación REOPT(VARS), DB2 determina las

vías de acceso durante el tiempo de vinculación y el tiempo de ejecución para
sentencias que contienen una o más variables de lenguaje principal, marcadores de
parámetros o registros especiales. Durante el tiempo de ejecución, DB2 utiliza los
valores de estas variables para determinar vías de acceso.
DB2 dedica un tiempo adicional a determinar la vía de acceso para sentencias

durante el tiempo de ejecución. Pero si DB2 encuentra una vía de acceso
significativamente mejor utilizando valores de variables, puede observarse una
mejora global del rendimiento.
Para aplicaciones de SQL estático con variables de lenguaje principal, si se

especifica REOPT(VARS), DB2 determina la vía de acceso durante el tiempo de
vinculación y de nuevo durante el tiempo de ejecución, utilizando los valores de
las variables de entrada.
Para aplicaciones de SQL estático sin variables de lenguaje principal, DB2

determina la vía de acceso cuando se vincula el plan o paquete. Esta situación
obtiene el mejor rendimiento debido a que la vía de acceso ya está determinada
cuando se ejecuta el programa.
Para aplicaciones que contienen sentencias de SQL dinámico con variables de

lenguaje principal, se recomienda utilizar REOPT(VARS) como método de
vinculación.
¿Se utilizan sentencias de SQL dinámico?
Para sentencias de SQL dinámico, DB2 determina la vía de acceso durante el

tiempo de ejecución, cuando se prepara la sentencia.
Cuando una aplicación realiza una operación de confirmación, debe emitir otra
sentencia PREPARE si esta sentencia de SQL debe volverse a ejecutar. Para una
sentencia SELECT, la posibilidad de declarar un cursor WITH HOLD proporciona
algunas ventajas pero requiere que el cursor esté abierto en el punto de

confirmación. La utilización de la opción WITH HOLD también hace que se
mantengan algunos bloqueos para los objetos de los que depende la sentencia
preparada. Además, la opción WITH HOLD no ofrece ninguna ventaja para
sentencias de SQL que no sean sentencias SELECT.
Puede utilizar la antememoria de sentencias dinámicas para disminuir el número

de veces que deben prepararse estas sentencias dinámicas. La utilización de la
antememoria de sentencias dinámicas es particularmente útil cuando se ejecuta con
frecuencia la misma sentencia de SQL.
DB2 puede guardar sentencias dinámicas preparadas en una antememoria. La

antememoria es una antememoria para todo DB2 que todos los procesos de
aplicaciones pueden utilizar para almacenar y recuperar sentencias dinámicas
preparadas. Después de preparar una sentencia de SQL y de que se almacene
automáticamente en la antememoria, las peticiones de preparación posteriores para
la misma sentencia pueden utilizar la sentencia de la antememoria para evitar un
proceso de preparación costoso. Diferentes hebras, planes o paquetes pueden
compartir sentencias que se han colocado en la antememoria.
Las sentencias SELECT, UPDATE, INSERT y DELETE se pueden elegir para

colocarlas en antememoria.
″Análisis de los datos de rendimiento″ (DB2 Performance Monitoring and
Tuning Guide)

Capítulo 9. Gestión de operaciones de DB2
La gestión de un subsistema DB2 diariamente requiere realizar una gran
diversidad de tareas como, por ejemplo, gestionar autorizaciones y prepararse para
la recuperación de cualquier error o problema potencial.
Cuando se gestiona un entorno DB2 diariamente es necesario emitir mandatos de

DB2, ejecutar programas de utilidad de DB2, gestionar autorizaciones y prepararse
para la recuperación de errores o problemas potenciales. Además, probablemente
deseará aprovechar las posibilidades de alta disponibilidad relacionadas con DB2,
entre las que se incluyen las siguientes:
v Puede vincular planes y paquetes de aplicaciones en línea. Utilizando paquetes,
puede cambiar y revincular unidades más pequeñas. Utilizando versiones de
paquetes puede vincular mientras las aplicaciones siguen en ejecución.
v Puede definir y cambiar bases de datos y autorizaciones en línea.
v Puede cambiar tamaños de agrupación de almacenamientos intermedios en
línea.
v Puede utilizar programas de utilidad para reorganizar índices, espacios de tablas
o particiones de índices o espacios de tablas.
v Puede utilizar las funciones de compartimiento de datos de DB2, que permiten
que varios subsistemas DB2 procesen aplicaciones en datos compartidos.
Aunque son subsistemas diferentes los que comparten datos, aparecen como un
único subsistema DB2 para los usuarios finales. Se pueden redireccionar
aplicaciones para evitar interrupciones si uno de los subsistemas debe extraerse
por motivos de mantenimiento.
Hay disponibles varias herramientas de gestión para ayudarle a llevar a cabo de

forma fácil muchas de las tareas asociadas con las operaciones diarias de un
subsistema DB2.
Herramientas que le ayudan a gestionar DB2

DB2 proporciona diversas herramientas que simplifican las tareas necesarias para
gestionar DB2.
Centro de control de DB2 y herramientas relacionadas

Esta información describe cómo el Centro de control de DB2 y otras herramientas
relacionadas pueden ayudarle a gestionar DB2.
El Centro de control de DB2 es una herramienta que le ayuda a realizar una

amplia variedad de actividades diarias. Puede utilizar el Centro de control para
gestionar bases de datos de DB2 en sistemas operativos diferentes. Es necesario
que el Servidor de administración de DB2 soporte las funciones seleccionadas en el
Centro de control.
Puede utilizar el Centro de control para administrar instancias de DB2 subsistemas,

bases de datos y objetos de base de datos de DB2 for z/OS. Estos objetos se
visualizan en la ventana principal del Centro de control. Puede utilizar el Centro
de control para crear, modificar y eliminar objetos. Una función de réplica de
subsistema le ayuda a crear y editar trabajos de JCL cuando necesita copiar un

subsistema. También puede ejecutar programas de utilidad que reorganizan o
cargan los daos en las bases de datos de DB2 for z/OS existentes.
Puede iniciar las siguientes herramientas de DB2 desde el Centro de control:

v DB2 Developer Workbench
v El Centro de mandatos de DB2, que le permite ejecutar mandatos de DB2,
sentencias de SQL y mandatos de consola z/OS.
El Centro de réplica forma parte del conjunto de herramientas del Centro de

control de DB2, pero se inicia por separado. El Centro de réplica permite
administración para entornos de réplica de DB2 a DB2 y para réplica entre bases
de datos relacionales de DB2 y no DB2. Puede utilizar esta herramienta para
configurar y administrar el entorno de réplica, para ejecutar el programa de
captura para capturar cambios en los datos y para ejecutar el programa de
aplicación para procesar los datos capturados.
| El Centro de servicio de optimización para DB2 para z/OS (OSC) es una

| herramienta de estación de trabajo que le ayuda a ajustar las consultas. Puede
| obtener de forma rápida recomendaciones sobre el ajuste personalizado o realizar
| el propio análisis en profundidad creando un gráfico del plan de acceso para una
| consulta. También puede capturar un conjunto de consultas que se ejecutan en un
| subsistema DB2, analizarlas como un grupo utilizando consejeros de carga de
| trabajo y supervisar las cargas de trabajo de sentencias mientras se ejecutan.
DB2 Administration Tool

DB2 Administration Tool, una de las herramientas de IBM DB2, simplifica muchas
de las tareas administrativas necesarias para mantener el subsistema DB2.
DB2 Administration Tool

DB2 Administration Tool para z/OS le ayuda a realizar las tareas que mantienen la
ejecución de DB2 en niveles máximos. Utilizando esta herramienta puede:
v Gestionar los entornos DB2 de forma eficaz con un conjunto amplio de
funciones
v Visualizar e interpretar objetos del catálogo de DB2 y realizar tareas de
administración de catálogo
v Realizar cambios y actualizaciones de forma rápida y fácil en los datos
presentados
v Utilizar funciones de modificación y migración
″DB2 Administration Tool″ (DB2 Administration Tool User’s Guide and
Reference)
DB2 Interactive
DB2 para z/OS DB2 proporciona paneles de Interactive System Productivity
Facility (ISPF) que se pueden utilizar para realizar de forma interactiva la mayor
parte de las tareas de DB2. Estos paneles forman un recurso de DB2 denominado
DB2 Interactive (DB2I).
Tareas relacionadas

″Sometimiento de trabajo utilizando DB2I″ (DB2 Administration Guide)
Utilización de mandatos y programas de utilidad para controlar las

operaciones de DB2
Puede controlar la mayoría de operaciones utilizando mandatos de DB2 y
realizando tareas de mantenimiento mediante programas de utilidad de DB2.
Mandatos de DB2
Puede utilizar mandatos para realizar las tareas necesarias para controlar y
mantener el subsistema DB2.
Puede entrar mandatos en un terminal, una consola z/OS mediante un programa

autorizado para APF o una aplicación que utilice la interfaz del recurso de
instrumentación (IFI).
Para entrar un mandato de DB2 desde una consola z/OS autorizada, utilice un
prefijo de mandato de subsistema (que contenga entre uno y ocho caracteres) al
principio del mandato. El prefijo de mandato de subsistema por omisión es -DSN1,
que puede cambiar al instalar o migrar DB2.
Ejemplo: El mandato siguiente inicia el subsistema DB2 asociado con el prefijo de

mandato -DSN1:
-DSN1 START DB2
Además de los mandatos de DB2, es posible que necesite utilizar otros tipos de
mandatos de las categorías siguientes:
v Mandatos de CICS, que controlan las conexiones de CICS y le permiten iniciar y
detener conexiones con DB2 y visualizar la actividad de las conexiones
v Mandatos de IMS, que controlan las conexiones de IMS y le permiten iniciar y
detener conexiones con DB2 y visualizar la actividad de las conexiones
| v Mandatos de TSO, que le permiten realizar tareas de TSO
v Mandatos de IRLM, que le permiten iniciar, detener y cambiar el gestor de
bloqueo de recursos interno (IRLM)
Para entrar un mandato de DB2 desde una consola z/OS autorizada, utilice un
prefijo de mandato de subsistema (que contenga entre 1 y 8 caracteres) al principio
del mandato. El prefijo de mandato de subsistema por omisión es -DSN1, que
puede cambiar al instalar o migrar DB2.
Ejemplo: El mandato siguiente inicia el subsistema DB2 asociado con el prefijo de

mandato -DSN1:
-DSN1 START DB2
″-START DB2″ (Consulta de mandatos de DB2)
″Mandatos de DB2″ (Consulta de mandatos de DB2)
Programas de utilidad de DB2

Puede utilizar programas de utilidad para realizar las tareas necesarias para
controlar y mantener el subsistema DB2.
Capítulo 9. Gestión de operaciones de DB2 271

Puede utilizar programas de utilidad de DB2 para realizar muchas de las tareas
necesarias para mantener datos de DB2. Entre estas se incluyen cargar una tabla,
copiar un espacio de tablas o recuperar una base de datos a un punto anterior en
el tiempo.
Los programas de utilidad fuera de línea se ejecutan como trabajo por lotes
independientes de DB2. Para ejecutar programas de utilidad fuera de línea, utilice
z/OSJCL (lenguaje de control de trabajos). DB2 interactive (DB2I) proporciona un
modo simple de preparar el lenguaje de control de trabajos (JCL) para estos
trabajos y de realizar muchas otras operaciones especificando valores en paneles.
DB2I se ejecuta bajo TSO utilizando servicios ISPF.
Una sentencia de control de programa de utilidad indica la tarea que debe realizar
un programa de utilidad concreto. Para ejecutar un trabajo de programa de
utilidad, especifique la sentencia de control en un conjunto de datos que utilice
para la entrada. A continuación, invoque DB2I y seleccione UTILITIES en DB2I
Primary Option Menu. En algunos casos, puede que necesite otros conjuntos de
datos; por ejemplo, el programa de utilidad LOAD necesita un conjunto de datos
de entrada que contenga los datos que se deben cargar.
| También puede utilizar las siguientes herramientas de IBM DB2 para gestionar
| programas de utilidad:
DB2 Automation Tool
Herramienta que permite que los administradores de bases de datos se
centren en más en la optimización de base de datos, automatiza las tareas
de mantenimiento y proporciona informes históricos estadísticos para
análisis de tendencias y previsiones.
DB2 High Performance Unload
Programa de utilidad de DB2 de alta velocidad que descarga tablas de DB2
desde un espacio de tablas o una copia de seguridad de la base de datos.
DB2 Cloning Tool
Herramienta que clona de forma rápida un subsistema DB2, creando el
equivalente de un entorno de producción que se puede utilizar para probar
nuevas características y funciones.
″Introducción a los programas de utilidad de DB2″ (DB2 Utility Guide and
Reference)
Herramientas de DB2 en ibm.com
Gestión de conjuntos de datos

En DB2 para z/OS, una forma de gestionar conjuntos de datos es utilizando
Storage Management Subsystem (SMS).
Los espacios de tablas o índices con un tamaño superior a 4 GB necesitan

conjuntos de datos gestionados por SMS. Otros espacios de tabla e índices se
pueden almacenar en conjuntos de datos gestionados por el usuario o en grupos
de almacenamiento gestionados por DB2.
“DB2 y DFSMS” en la página 57
“Asignación de espacios de tablas a almacenamiento físico” en la página 212

Mecanismos de autorización y seguridad para el acceso a datos
La autorización es una parte integral del control de DB2. Los mecanismos de
seguridad y autorización que controlan el acceso a datos de DB2 son directos e
indirectos.
DB2 realiza comprobaciones de seguridad directas de los ID de usuario y las

contraseñas antes de permitir que los usuarios accedan a un subsistema DB2. Los
mecanismos de seguridad de DB2 incluyen objetos específicos, privilegios sobre
estos objetos y algunos privilegios que proporcionan una autoridad más amplia.
DB2 también controla el acceso a datos indirectamente mediante comprobaciones
de autorización durante el tiempo de vinculación y el tiempo de ejecución para
planes y paquetes de aplicaciones.
Autorización
Probablemente habrá observado que existen referencias a la autorización en esta

información. Por ejemplo, debe tener autorización para ejecutar sentencias de SQL
que creen y modifiquen objetos de DB2. Incluso cuando los usuarios ejecutan una
sentencia SELECT para consultar la información de una tabla, su autorización
puede limitar lo que ven. El usuario puede ver únicamente los datos de un
subconjunto de columnas definidas en una vista. Las vistas proporcionan una gran
variedad de controles de seguridad.
Antes de emitir mandatos de DB2, ejecutar programas de utilidad, ejecutar

paquetes y planes de aplicaciones o utilizar la mayoría de las demás funciones de
DB2 necesita tener la autorización o el privilegio adecuados. Por ejemplo, para
realizar cambios en una tabla necesita tener autorización para acceder a dicha
tabla. Un privilegio permite una acción sobre un objeto. Por ejemplo, para insertar
datos en una tabla se necesita el privilegio para insertar datos.
Las sentencias GRANT y REVOKE proporcionan control de accesos para objetos de

DB2. Los privilegios y autoridades se pueden otorgar a ID de autorización en
numerosas combinaciones y también se pueden revocar.
Puede utilizar el componente RACF o un producto equivalente para controlar el

acceso a objetos de DB2.
| Seguridad
| Debido a la necesidad de una mayor seguridad de los datos y la demanda de una

| contabilidad corporativa mejorada, el gobierno federal y determinadas industrias
| han desarrollado leyes y regulaciones para guiar numerosos procesos corporativos.
| La expectativa de que se cumplan estas leyes y regulaciones probablemente
| aumentará en el futuro. El soporte de DB2 para z/OS a roles y los contextos de
| confianza sirven de ayuda en el área de conformidad al imponer contabilidad de
| datos en el nivel de los datos. En lugar de utilizar un único ID de usuario para
| todas las peticiones de base de datos, los servidores de aplicaciones pueden
| proporcionar un ID de usuario final que no implique una desventaja en el
| rendimiento asociada con la petición.

Cómo controlan el acceso a datos los ID de autorización
Uno de los modos en que DB2 controla el acceso a datos es mediante la utilización
de identificadores. Un conjunto de uno o más identificadores de DB2, denominado
ID de autorización, representa cada proceso que se conecta o inicia una sesión en
DB2.
Los ID de autorización se clasifican en tres tipos:

ID de autorización primario
Como resultado de asignar ID de autorización, cada proceso tiene
exactamente un ID que se denomina ID de autorización primario.
Generalmente, el ID de autorización primario identifica un proceso. Por
ejemplo, los registros de rastreo de estadísticas y rendimiento utilizan un
ID de autorización primario para identificar un proceso.
ID de autorización secundario
Todos los demás ID son los ID de autorización secundarios. Un ID de
autorización secundario, que es opcional, puede tener privilegios
adicionales disponibles para el proceso. Por ejemplo, se puede utilizar un
ID de autorización secundario para un grupo de z/OS Security Server.
CURRENT SQLID
Se designa un ID (primario o secundario) como CURRENT SQLID.
CURRENT SQLID tiene los privilegios que se ejercen cuando se ejecutan
determinadas sentencias de SQL dinámico. Se puede establecer CURRENT
SQLID en el ID primario o en cualquiera de los ID secundarios. Si un ID
de autorización de un proceso tiene la autoridad de administración del
sistema (SYSADM), el proceso puede establecer CURRENT SQLID en
cualquier ID de autorización. Se puede cambiar el valor de CURRENT
SQLID durante la sesión.
Ejemplo: Si ALPHA es el ID de autorización primario o uno de los ID de

autorización secundarios, puede hacer que sea CURRENT SQLID
emitiendo la sentencia de SQL siguiente:
SET CURRENT SQLID = 'ALPHA';
“Cómo mantienen privilegios y autoridades los ID de autorización”
“Modos de controlar el acceso a los datos” en la página 278
“Modos de controlar el acceso a objetos de DB2 mediante autoridades y
privilegios explícitos” en la página 279
Cómo mantienen privilegios y autoridades los ID de

autorización
DB2 controla el acceso a sus objetos mediante un conjunto de privilegios. Cada
privilegio permite una acción sobre un objeto.
La figura siguiente muestra los principales modos en DB2 para proporcionar

acceso a datos a un ID.

Figura 45. Otorgamiento de acceso a datos en DB2
Los ID pueden mantener privilegios que les permitan realizar determinadas

acciones o que les prohíban realizarlas. Los privilegios de DB2 proporcionan un
control sumamente estricto.
Privilegios relacionados
DB2 define conjuntos de privilegios relacionados que se denominan
autoridades administrativas. Al otorgar una autoridad administrativa a un ID,
se otorgan todos los privilegios asociados con ésta, en una sentencia.
Privilegios de objeto
La propiedad de un objeto conlleva un conjunto de privilegios relacionados
sobre el objeto. Un ID puede ser el propietario de un objeto que crea o
puede crear un objeto que pertenecerá a otro ID. La creación y propiedad
de los objetos se controlan de forma separada.
Privilegios de plan de aplicación y paquete
El privilegio para ejecutar un plan de aplicación o un paquete requiere
atención especial. La ejecución de un plan o un paquete ejerce
implícitamente todos los privilegios que el propietario del plan o paquete
ha necesitado para vincularlo. Por lo tanto, el otorgamiento del privilegio
para ejecutar puede proporcionar un conjunto detallado de privilegios y
puede eliminar la necesidad de otorgar otros privilegios por separado.
Ejemplo: Suponga que un plan de aplicación emite las sentencias INSERT

y SELECT en varias tablas. Tan solo será necesario otorgar los privilegios
INSERT y SELECT al propietario del plan. Cualquier ID de autorización al
que se otorgue posteriormente el privilegio EXECUTE sobre el plan puede

ejecutar las mismas sentencias INSERT y SELECT mediante el plan. No es
necesario otorgar explícitamente a este ID el privilegio para realizar estas
sentencias.
| Etiquetas de seguridad
| La seguridad de varios niveles limita el acceso a un objeto o a una fila
| basándose en la etiqueta de seguridad del objeto o fila y en la etiqueta de
| seguridad del usuario.
| Rol Un rol es una entidad de base de datos que agrupa uno o más privilegios.
| Un rol sólo está disponible cuando el proceso se ejecuta en un contexto de
| confianza. Un contexto de confianza es una entidad de base de datos basada
| en un ID de autorización del sistema y en un conjunto de atributos de
| fiabilidad de conexión. Puede crear y utilizar un contexto de confianza
| para establecer una conexión de confianza entre DB2 y una entidad externa
| como, por ejemplo, un servidor de middleware.
| Los usuarios se asocian a un rol en la definición de un contexto de
| confianza. Un contexto de confianza puede tener un rol por omisión, roles
| específicos para usuarios individuales o ningún rol.
“Modos de controlar el acceso a los datos” en la página 278
privilegios explícitos” en la página 279
Modos de controlar el acceso a subsistemas DB2

DB2 for z/OS realiza comprobaciones de seguridad para autenticar a los usuarios
antes de otorgarles acceso a datos de DB2. Existen varios mecanismos de
autenticación soportados por peticionarios de DB2 y aceptados por servidores de
DB2.
La autenticación se produce cuando la sentencia CONNECT se emite para conectar

el proceso de aplicaciones al servidor designado. El servidor o el subsistema DB2
local comprueba el ID de autorización y la contraseña para verificar que el usuario
tiene autorización para conectarse al servidor.
Puede utilizar RACF o z/OS Security Server para autenticar los usuarios que
acceden a una base de datos de DB2.
Acceso local a DB2

Un usuario de DB2 local está sujeto a varias comprobaciones de seguridad.
Por ejemplo, cuando DB2 se ejecuta bajo TSO y utiliza el ID de inicio de sesión de
TSO como ID de autorización primario de DB2, dicho ID se verifica con una
contraseña cuando el usuario inicia la sesión.
Cuando el servidor es el subsistema DB2 local, RACF verifica la contraseña y

comprueba si el ID de autorización tiene permiso para utilizar los recursos de DB2
definidos para RACF. Si se define una rutina de salida, RACF o z/OS Security
Server realizan comprobación de seguridad adicional.

Acceso remoto a DB2
Cuando el servidor no es el subsistema DB2 local se realizan varias
comprobaciones de seguridad.
v El gestor de seguridad local del servidor verifica el ID y la contraseña de
autorización primaria de DB2. Una verificación posterior determina si el ID de
autorización tiene permiso para acceder a DB2.
v Las opciones de seguridad para los protocolos SNA o TCP/IP se comprueban en
la base de datos de comunicaciones (CDB).
DDF da soporte a los protocolos de comunicaciones TCP/IP y SNA en un entorno

distribuido. Como peticionario o servidor, DB2 elige cómo enviar o aceptar
mecanismos de autenticación, basándose en el protocolo de red que se utiliza. DB2
utiliza mecanismos de seguridad de SNA para conexiones de red SNA y
mecanismos de seguridad de DRDA para conexiones de red TCP/IP o Kerberos.
Las opciones de seguridad de DRDA proporcionan el siguiente soporte para cifrar

datos sensibles:
v Los servidores de DB2 for z/OS pueden proporcionar cifrado y descifrado de
datos de alta velocidad seguros.
v Los peticionarios de DB2 for z/OS disponen de la opción de cifrar ID de usuario
y, opcionalmente, sus contraseñas cuando los peticionarios se conectan a
servidores remotos. Los peticionarios también pueden cifrar datos sensibles de
seguridad cuando se comunican con servidores de modo que los datos estén
seguros cuando se transmiten por la red.
Puede utilizar RACF o un subsistema de seguridad similar para realizar

autenticación. RACF puede:
v Verificar un ID de autorización remoto asociado a una conexión mediante la
comprobación del ID con su contraseña.
v Verificar si el ID de autorización tiene permiso para acceder a DB2 a través de
una conexión remota.
v Verificar si el ID de autorización tiene permiso para acceder a DB2 desde un
sitio remoto específico.
v Generar pases, una alternativa a las contraseñas, en el lado transmisor. Un pase
permite a los usuarios acceder a un sistema principal sin enviar la contraseña de
RACF a través de la red.
Seguridad de Kerberos
Como servidor, DB2 da soporte a seguridad de Kerberos para autenticar usuarios

remotos. Los mecanismos de autenticación son tiquets de Kerberos cifrados en
lugar de ID de usuario y contraseñas.
Puede establecer soporte de DB2 for z/OS para autenticación de Kerberos

mediante z/OS Security Server. Kerberos también es una opción de seguridad de
red para clientes de DB2 Connect.
Base de datos de comunicaciones
La base de datos de comunicaciones de DB2 contiene un conjunto de tablas de

catálogo de DB2 que le permite controlar aspectos de peticiones remotas. DB2
utiliza esta base de datos para obtener información sobre conexiones con sistemas
remotos.

Acceso de estación de trabajo
Cuando un cliente de estación de trabajo accede a un servidor de DB2 for z/OS,

DB2 Connect pasa toda la información de autenticación desde el cliente al servidor.
Los clientes de estación de trabajo pueden cifrar los ID de usuario y contraseñas
cuando emiten una sentencia CONNECT. La autenticación de Database connection
services (DCS) debe establecerse en DCS_ENCRYPT.
Un tipo de autenticación para cada instancia determina la verificación del usuario.

El tipo de autenticación se almacena en el archivo de configuración del gestor de
bases de datos en el servidor. Están permitidos los siguientes tipos de autenticación
con DB2 Connect:
CLIENT
El ID de usuario y la contraseña se validan en el cliente.
SERVER
El ID de usuario y la contraseña se validan en el servidor de bases de
datos.
SERVER_ENCRYPT
El ID de usuario y la contraseña se validan en el servidor de bases de
datos y las contraseñas se cifran en el cliente.
KERBEROS
El cliente se registra en el servidor utilizando autenticación de Kerberos.
Modos de controlar el acceso a los datos

DB2 le permite controlar el acceso a los datos. El acceso a los datos incluye, pero
sin limitarse a ello, un usuario que participa en una sesión de terminal interactiva.
Por ejemplo, el acceso puede ser desde un servidor remoto, desde una transacción
IMS o CICS, o desde un programa que se ejecuta en modalidad de proceso por
lotes.
Esta información describe los distintos métodos de control de acceso a datos en

DB2. En esta información, el término proceso se utiliza para representar todos los
modos de acceder a datos.
La figura siguiente sugiere varias rutas desde un proceso hasta datos de DB2 con
controles en cada ruta.

Figura 46. Control de acceso a datos de DB2
El primer método, control de acceso dentro de DB2, utiliza identificadores (ID)

para controlar el acceso a objetos de DB2. En primer lugar el proceso debe cumplir
los requisitos de seguridad para acceder al subsistema DB2. Cuando el proceso está
dentro del subsistema DB2, DB2 comprueba varios ID para determinar si el
proceso puede acceder a objetos de DB2. Se describen estos ID (ID de autorización
primario, ID de autorización secundario e ID de SQL). Si el proceso tiene el ID o
los ID necesarios, puede acceder a objetos de DB2, incluyendo datos de DB2.
El segundo método, protección de conjunto de datos, no se controla desde dentro

de DB2. Se aplica protección de conjunto de datos al proceso desde fuera de DB2.
Si el proceso cumple los criterios de protección, puede llegar a los datos de DB2.
“Cómo mantienen privilegios y autoridades los ID de autorización” en la
página 274
privilegios explícitos”
″Gestión del acceso mediante ID o roles de autorización″ (DB2 Administration
Guide)
Modos de controlar el acceso a objetos de DB2 mediante

autoridades y privilegios explícitos
Puede controlar el acceso a DB2 otorgando, no otorgando o revocando autoridades
y privilegios explícitos.
Un privilegio explícito es un privilegio con nombre que se otorga con la sentencia

GRANT o se revoca con la sentencia REVOKE. Una autoridad administrativa es un
conjunto de privilegios, que a menudo incluye un conjunto de objetos relacionado.
Las autoridades suelen incluir privilegios que no son explícitos, no tienen nombre
y no se pueden otorgar específicamente como, por ejemplo, la capacidad de
terminar un trabajo de programa de utilidad.

Privilegios explícitos
Los privilegios explícitos proporcionan un control muy detallado. Por ejemplo,

suponga que un usuario necesita seleccionar, insertar y actualizar datos de una
tabla. Para realizar estas acciones, el usuario necesita los privilegios SELECT,
INSERT y UPDATE sobre la tabla.
Existen privilegios explícitos disponibles para los objetos siguientes:

v Agrupaciones de almacenamientos intermedios
v Colecciones
v Bases de datos
v Tipos diferenciados
v JAR (Java Archive, con formato de archivo para agregar muchos archivos en un
archivo)
v Paquetes
v Planes
v Rutinas (funciones y procedimientos)
v Esquemas
v Secuencias
v Grupos de almacenamiento
v Sistema
v Tablas
v Espacios de tablas
v Vistas
Autoridades administrativas
Los privilegios se agrupan en autoridades administrativas. Estas autoridades

forman una jerarquía. Cada autoridad incluye un grupo específico de privilegios.
Las autoridades administrativas se clasifican en las categorías de autoridades del
sistema, de base de datos y de colección. La autoridad administrativa de más alto
nivel es SYSADM. Cada nivel de autoridad incluye los privilegios de todas las
autoridades de nivel más bajo.
Las autoridades del sistema que se describen a continuación se clasifican de más

alta a más baja:
SYSADM
La autoridad de administración del sistema incluye todos los privilegios de
DB2 (salvo unos pocos reservados para instalación), los cuales se pueden
otorgar todos a otros.
SYSCTRL
La autoridad de control del sistema incluye la mayoría de privilegios
SYSADM; excluye los privilegios para leer o modificar datos del usuario.
SYSOPR
La autoridad de operador del sistema incluye los privilegios para emitir la
mayoría de mandatos de DB2 y terminar cualquier trabajo de programa de
utilidad.
Las autoridades de base de datos que se describen a continuación se clasifican de

más alta a más baja:
DBADM
La autoridad de administración de base de datos incluye los privilegios
para controlar una base de datos específica. Los usuarios con autoridad

DBADM pueden acceder a tablas y modificar o descartar espacios de
tablas, tablas o índices de la base de datos.
DBCTRL
La autoridad de control de base de datos incluye los privilegios para
controlar una base de datos específica y ejecutar programas de utilidad que
pueden modificar datos de dicha base de datos.
DBMAINT
La autoridad de mantenimiento de base de datos incluye los privilegios
para trabajar con determinados objetos y emitir determinados programas
de utilidad y mandatos en una base de datos específica.
PACKADM tiene autoridad de administrador de paquetes para colecciones

determinadas.
“Cómo mantienen privilegios y autoridades los ID de autorización” en la
página 274
Utilización de seguridad de varios niveles para controlar el

acceso
DB2 proporciona un esquema de seguridad de gran capacidad denominado
seguridad de varios niveles. La seguridad de varios niveles es una política de
seguridad que clasifica los datos y usuarios según un sistema de niveles de
seguridad jerárquicos y categorías de seguridad no jerárquicas.
La seguridad de varios niveles evita que usuarios no autorizados accedan a

información de una clasificación superior a su autorización y evita que los usuarios
desclasifiquen información.
Con la seguridad de varios niveles puede definir la seguridad para objetos de DB2
y realizar otras comprobaciones, incluidas las comprobaciones de seguridad de
nivel inferior. Las comprobaciones de seguridad de nivel inferior controlan qué
usuarios tienen autorización para ver, modificar o realizar acciones en filas de
tablas. Con la seguridad de varios niveles no necesita utilizar vistas especiales ni
variables de base de datos para controlar la seguridad en el nivel inferior.
Puede crear una etiqueta de seguridad para una fila de tabla definiendo una
columna de la sentencia CREATE TABLE o ALTER TABLE como la etiqueta de
seguridad. Cuando se accede a cada fila, DB2 utiliza RACF para comparar la
etiqueta de seguridad de la fila y el usuario para determinar si el usuario tiene la
autorización adecuada para acceder a la fila. Las comprobaciones de seguridad de
nivel de fila se producen cada vez que un usuario emite una sentencia SELECT,
INSERT, UPDATE o DELETE para acceder a una tabla con una columna de
etiqueta de seguridad o ejecuta una petición de programa de utilidad para datos
de una fila protegida mediante una etiqueta de seguridad.
″Implementación de seguridad de varios niveles con DB2″ (DB2 Administration
Guide)
Utilización de vistas para controlar el acceso

| Los privilegios de tabla DELETE, INSERT, SELECT y UPDATE también se pueden
| otorgar para una vista. Al crear una vista y otorgar privilegios sobre ésta, sólo
| puede proporcionar a un ID el acceso a un subconjunto específico de datos. Esta
| posibilidad a veces se denomina control de acceso de nivel de campo o sensibilidad de
| nivel de campo.
Ejemplo: Suponga que desea que un ID concreto como, por ejemplo MATH110,
pueda extraer determinados datos de la tabla EMP para una investigación
estadística. Para ser exactos, suponga que desea permitir el acceso a datos como los
siguientes:
v De las columnas HIREDATE, JOB, EDL, SALARY, COMM (pero no un nombre o
un número de identificación de empleado)
v Sólo para empleados contratados después del 15 de diciembre de 1996
v Sólo para empleados con un nivel de formación 14 o superior
v Sólo para empleados cuya ocupación no es MGR o PRS
Puede crear y nombrar una vista que muestre exactamente esta combinación de
datos:
| CREATE VIEW SALARIES AS
| SELECT HIREDATE, JOB, EDL, SALARY, COMM
| FROM EMP
| WHERE HIREDATE> '1996-12-15' AND EDLEVEL>= 14
| AND JOB IS DISTINCT FROM 'MGR' AND JOB IS DISTINCT FROM 'PRS';
A continuación, puede utilizar la sentencia GRANT para otorgar el privilegio

SELECT a la vista SALARIES to MATH110:
GRANT SELECT ON SALARIES TO MATH110;
Ahora, MATH110 puede ejecutar sentencias SELECT que únicamente consultan el

conjunto restringido de datos.
“Vista que combina información de varias tablas” en la página 232
Utilización de otorgamiento y revocación de privilegios para

controlar el acceso
La sentencia GRANT de SQL le permite otorgar privilegios explícitamente a los ID
de autorización. La sentencia REVOKE le permite revocarlos. Tan solo se puede
revocar un privilegio que se haya otorgado explícitamente.
El otorgamiento de privilegios es muy flexible. Por ejemplo, considere los

privilegios de tablas. Puede otorgar todos los privilegios de una tabla a un ID. De
forma alternativa, puede otorgar privilegios separados específicos que permitan
que este ID recupere datos de la tabla, inserte filas, suprima filas o actualice
columnas específicas. Al otorgar o no otorgar estos privilegios en vistas de la tabla,
puede determinar de forma eficaz y exacta qué acción un ID puede realizar o no
en la tabla.
Puede utilizar la sentencia GRANT para asignar privilegios como se indica a

continuación:
v Otorgar privilegios a un único ID o a varios ID en una sentencia.
v Otorgar un privilegio específico sobre un objeto en una única sentencia, otorgar
una lista de privilegios u otorgar privilegios sobre una lista de objetos.
v Otorgar ALL, para todos los privilegios de acceso a una única tabla o para todos
los privilegios asociados con un paquete específico.

Ejemplos de otorgamiento de privilegios
Los ejemplos siguientes muestran cómo otorgar algunos privilegios del sistema,
utilizar privilegios y privilegios de tablas.
Ejemplo de otorgamiento 1: Para otorgar los privilegios de autoridad de operador

del sistema al usuario NICHOLLS, el administrador del sistema utiliza la sentencia
siguiente:
GRANT SYSOPR TO NICHOLLS;
Suponga que su empresa decide asociar tareas de trabajos con ID de autorización.
Ejemplo de otorgamiento 2: En los ejemplos siguientes, PKA01 es el ID de un

administrador de paquetes y DBA01 es el ID de un administrador de base de
datos. Suponga que el administrador del sistema utiliza el ID de autorización
ADMIN, que tiene la autoridad SYSADM, para emitir las siguientes sentencias
GRANT:
v GRANT PACKADM ON COLLECTION GOLFS TO PKA01 WITH GRANT OPTION;
Esta sentencia otorga la autoridad PACKADM a PKA01. PKA01 adquiere
privilegios de paquete sobre todos los paquetes de la colección denominada
GOLFS y el privilegio CREATE IN sobre dicha colección. Además, al especificar
WITH GRANT OPTION se proporciona a PKA01 la capacidad de otorgar dichos
privilegios a otros.
v GRANT CREATEDBA TO DBA01;
CREATEDBA otorga a DBA01 el privilegio de crear bases de datos y DBA01
adquiere la autoridad DBADM sobre dichas bases de datos.
v GRANT USE OF STOGROUP SG1 TO DBA01 WITH GRANT OPTION;
Esta sentencia permite a DBA01 utilizar el grupo de almacenamiento SG1 y
otorgar dicho privilegio a otros.
v GRANT USE OF BUFFERPOOL BP0, BP1 TO DBA01 WITH GRANT OPTION;
Esta sentencia permite a DBA01 utilizar las agrupaciones de almacenamientos
intermedios BP0 y BP1 y otorgar dicho privilegio a otros.
Ejemplo de otorgamiento 3: Los ejemplos siguientes muestran privilegios de tabla

específicos que se pueden otorgar a usuarios.
v GRANT SELECT ON DEPT TO PUBLIC;
Esta sentencia otorga privilegios SELECT sobre la tabla DEPT. El otorgamiento
del privilegio select a PUBLIC proporciona el privilegio a todos los usuarios del
servidor actual.
v GRANT UPDATE (EMPNO,DEPT) ON TABLE EMP TO NATZ;
Esta sentencia otorga privilegios UPDATE sobre las columnas EMPNO y DEPT
de la tabla EMP al usuario NATZ.
v GRANT ALL ON TABLE EMP TO KWAN,ALONZO WITH GRANT OPTION;
Esta sentencia otorga todos los privilegios sobre la tabla EMP a los usuarios
KWAN y ALONZO. La cláusula WITH GRANT OPTION permite a estos dos
usuarios otorgar los privilegios de tabla a otros.
Ejemplos de revocación de privilegios
El mismo ID que otorga un privilegio puede revocarlo emitiendo la sentencia

REVOKE. Si dos o más otorgantes otorgan el mismo privilegio a un ID, la

ejecución de una única sentencia REVOKE no elimina el privilegio de dicho ID.
Para eliminar el privilegio, cada ID que ha otorgado explícitamente el privilegio
debe revocarlo explícitamente.
A continuación se proporcionan algunos ejemplos de revocación de privilegios que

se han otorgado previamente.
Ejemplo de revocación 1:
v REVOKE SYSOPR FROM NICHOLLS;
Esta sentencia revoca la autoridad SYSOPR del usuario NICHOLLS.
v REVOKE UPDATE ON EMP FROM NATZ;
Esta sentencia revoca el privilegio UPDATE sobre la tabla EMP del usuario
NATZ.
v REVOKE ALL ON TABLE EMP FROM KWAN,ALONZO;
Esta sentencia revoca todos los privilegios sobre la tabla EMP de los usuarios
KWAN y ALONZO.
Un ID con la autoridad SYSADM o SYSCTRL puede revocar privilegios otorgados

por otros ID.
Ejemplo de revocación 2: Un usuario con la autoridad SYSADM o SYSCTRL

puede emitir las sentencias siguientes:
v REVOKE CREATETAB ON DATABASE DB1 FROM PGMR01 BY ALL;
En esta sentencia, el privilegio CREATETAB que tiene el usuario PGMR01 se
revoca independientemente de quién o cuántas personas hayan otorgado
explícitamente este privilegio a este usuario.
v REVOKE CREATETAB, CREATETS ON DATABASE DB1 FROM PGMR01 BY DBUTIL1;
Esta sentencia revoca los privilegios otorgados por DBUTIL1 y deja intactos los
mismos privilegios si los ha otorgado cualquier otro ID.
La revocación de privilegios puede ser más complicada. Los privilegios se pueden

revocar como resultado de una revocación en cascada. En este caso, la revocación
de un privilegio de un usuario también puede hacer que se revoque este privilegio
de otros usuarios.
″GRANT″ (Consulta de DB2 SQL)
″REVOKE″ (Consulta de DB2 SQL)
Copia de seguridad, recuperación y reinicio

Aunque la alta disponibilidad de los datos es un objetivo para todos los
subsistemas DB2, es difícil evitar totalmente interrupciones no planificadas. Sin
embargo una estrategia correcta de copia de seguridad, recuperación y reinicio
puede reducir el tiempo transcurrido de una interrupción no planificada.
Para reducir la probabilidad y la duración de interrupciones no planificadas, debe

realizar copias de seguridad de los datos y reorganizar los datos periódicamente
para maximizar la disponibilidad de los datos para usuarios y programas.
Existen muchos factores que afectan a la disponibilidad de las bases de datos. A

continuación se proporcionan algunos puntos que debe tener en cuenta:
v Debe comprender las opciones de programas de utilidad como COPY y REORG.

– Puede recuperar en línea estructuras como, por ejemplo, espacios de tablas,
particiones, conjuntos de datos, un rango de páginas, una única página e
índices.
– Puede recuperar espacios de tablas e índices al mismo tiempo para reducir el
tiempo de recuperación.
– Con algunas opciones del programa de utilidad COPY, puede leer y actualizar
un espacio de tablas mientras se copia.
v Los errores de E/S tienen los siguientes efectos:
– Los errores de E/S en un rango de datos no afectan a la disponibilidad del
resto de los datos.
– Si se produce un error de E/S mientras DB2 escribe en el registro, DB2 sigue
funcionando.
– Si un error de E/S está en el registro activo, DB2 pasa al siguiente conjunto
de datos. Si el error está en el registro de archivado, DB2 asigna
dinámicamente otro conjunto de datos.
v Los métodos de recuperación tras desastre documentados son cruciales en el
caso de desastres que puedan causar una conclusión completa del subsistema
DB2 local.
v Si se impone a DB2 una única modalidad de operaciones para el conjunto de
datos o registros del programa de arranque, normalmente puede restaurar la
operación dual mientras DB2 sigue en ejecución.
DB2 proporciona métodos amplios para recuperar datos tras errores, anomalías o
incluso desastres. Puede recuperar datos a su estado actual o a un estado anterior.
Las unidades de datos que se pueden recuperar son espacios de tablas, índices,
espacios de índices, particiones y conjunto de datos. También puede utilizar
funciones de recuperación para realizar una copia de seguridad de un subsistema
DB2 o un grupo de compartimiento de datos completos.
El desarrollo de procedimientos de copia de seguridad y de recuperación es crítico

para evitar pérdidas de datos costosas y que consumen tiempo. En general,
asegúrese de que existan los procedimientos siguientes:
v Creación de un punto de coherencia.
v Restauración del sistema y objetos de datos en un punto de coherencia.
v Copia de seguridad y recuperación del catálogo de DB2 y los datos.
v Recuperación de condiciones de sin espacio.
v Recuperación de una anomalía de hardware o alimentación.
v Recuperación de una anomalía de componente de z/OS.
Además, el sitio debe tener un procedimiento para recuperación en un sitio remoto

en caso de un desastre.
Los problemas específicos que necesitan recuperación pueden ser desde un error
inesperado del usuario hasta la anomalía de un subsistema entero. Puede
producirse un problema en el hardware o software; los daños pueden ser físicos o
lógicos. A continuación se proporcionan algunos ejemplos:
v Si se produce una anomalía del sistema, un reinicio de DB2 restaura la
integridad de los datos. Por ejemplo, puede fallar un subsistema DB2 o un
subsistema conectado. En ambos casos, DB2 se reinicia de forma automática,
restituye los cambios no confirmados y finaliza el proceso de los cambios
confirmados.

v Si se produce una anomalía del soporte (por ejemplo, un daño físico en un
dispositivo de almacenamiento de datos), puede recuperar los datos en el punto
actual.
v Si los datos están dañados lógicamente, el objetivo es recuperar los datos en un
punto en el tiempo anterior a cuando se ha producido el daño lógico. Por
ejemplo, si DB2 no puede escribir una página en disco debido a un problema de
conectividad, la página es lógicamente errónea.
v Si un programa de aplicación finaliza de manera anómala, puede utilizar
programas de utilidad, registros y copias de imágenes para recuperar los datos a
un punto anterior en el tiempo.
La recuperación de objetos de DB2 requiere las copias de imágenes adecuadas y

conjuntos de datos de registro de confianza. Puede utilizar varios programas de
utilidad y algunas estructuras del sistema para realizar una copia de seguridad y
una recuperación. Por ejemplo, el programa de utilidad REPORT puede
proporcionar parte de la información necesaria durante la recuperación. También
puede obtener información del inventario del conjunto de datos del programa de
arranque (BSDS) de los conjuntos de datos de registro.
Tareas relacionadas
″Procedimientos de recuperación″ (DB2 Administration Guide)
″COPY″ (DB2 Utility Guide and Reference)
″REORG TABLESPACE″ (DB2 Utility Guide and Reference)
″REPORT″ (DB2 Utility Guide and Reference)
″RECOVER″ (DB2 Utility Guide and Reference)
″Operación y recuperación″ (DB2 Administration Guide)
Recursos y herramientas de copia de seguridad y

recuperación
DB2 se basa en el registro y el BSDS para realizar un seguimiento de los cambios
en los datos a medida que se producen. Estos recursos proporcionan información
crítica durante la recuperación. Otras herramientas importantes necesarias para la
copia de seguridad y la recuperación de datos son varios de los programas de
utilidad de DB2.
Utilización de registros
El registro de DB2 registra los cambios en los datos y los sucesos significativos a
medida que se producen. DB2 escribe cada registro del archivo de registro en el
registro activo, que es un conjunto de datos de disco. Cuando el conjunto de datos
de registro activo se llena, DB2 copia su contenido en el registro de archivado, que
es un conjunto de datos de disco o cinta. Este proceso se denomina descarga.
El registro de archivado puede estar formado por un máximo de 10000 conjuntos

de datos. Cada registro de archivado es un conjunto de datos secuencial (secuencial
físico) que reside en un disco o volumen de cinta magnética.
Con DB2, puede elegir entre registro cronológico único y registro cronológico dual.
Un único registro activo contiene un máximo de 93 conjuntos de datos de registro
activo. Con el registro cronológico dual, DB2 mantiene dos copias idénticas de los

registros del archivo de registro. El registro cronológico dual es la mejor opción
para aumentar la disponibilidad.
Utilización del conjunto de datos del programa de arranque
El conjunto de datos del programa de arranque (BSDS) es un repositorio de

información sobre los conjuntos de datos que contienen el registro. El BSDS
contiene la información siguiente:
v Un inventario de todos los conjuntos de datos activos y de archivado conocidos
en DB2.
DB2 registra los datos sobre el conjunto de datos de registro en el BSDS cada
vez que se define un nuevo conjunto de datos de registro de archivado o se
reutiliza un conjunto de datos de registro activo. El inventario de BSDS incluye
la fecha y hora en que se ha creado el registro, el nombre del conjunto de datos,
su estado y otra información. DB2 utiliza esta información para realizar un
seguimiento de los conjuntos de datos de registro activo y de archivado. DB2
también utiliza esta información para localizar registros del archivo de registro
para peticiones de lectura de registro que se producen durante la actividad
normal del subsistema DB2 y durante el proceso de reinicio y recuperación.
v Un inventario de toda la actividad de punto de comprobación reciente que DB2
utiliza durante el proceso de reinicio.
v Un registro de comunicaciones del recurso de datos distribuidos (DDF).
v Información sobre agrupaciones de almacenamientos intermedios.
Debido a que el BSDS es esencial para la recuperación en el caso de una anomalía

de subsistema, DB2 crea automáticamente dos copias del BSDS durante la
instalación. Si es posible, DB2 coloca las copias en volúmenes separados.
Programas de utilidad que dan soporte a copia de seguridad y

recuperación
Los siguientes programas de utilidad se utilizan frecuentemente para copia de

seguridad y recuperación:
v COPY, QUIESCE, MERGECOPY y BACKUP SYSTEM para copia de seguridad
v RECOVER, REBUILD INDEX, REPORT y RESTORE SYSTEM para recuperación
En general, estos programas de utilidad se utilizan para preparar para la

recuperación y restaurar los datos. Cada programa de utilidad tiene un rol en el
proceso de copia de seguridad y recuperación.
COPY El programa de utilidad COPY crea un máximo de cuatro copias de
imagen de espacios de tablas, índices y conjuntos de datos.
Los dos tipos de copias de imagen son los siguientes:
v Copia de imagen completa: una copia de todas las páginas de un espacio
de tablas, partición, conjunto de datos o espacio de índice.
v Copia de imagen incremental: una copia de únicamente las páginas del
espacio de tablas que han cambiado desde la última utilización del
programa de utilidad COPY.
Mientras se ejecuta COPY, puede utilizar la opción SHRLEVEL para
controlar si otros programas pueden acceder al espacio de tablas o índice o
actualizarlo.
v SHRLEVEL REFERENCE proporciona acceso de sólo lectura a otros
programas.

v SHRLEVEL CHANGE permite a otros programas cambiar el espacio de
tablas o el espacio de índice.
En general, cuanto mayor sea la frecuencia de copias de imagen, menor
será el tiempo de recuperación. Sin embargo, si realiza copias de imagen
frecuentes, también pasa más tiempo realizando copias.
El programa de utilidad RECOVER utiliza estas copias cuando se recupera
un espacio de tablas o un espacio de índice al punto más reciente en el
tiempo o a un punto anterior en el tiempo. La tabla de catálogo
SYSIBM.SYSCOPY registra información sobre copias de imagen.
QUIESCE
El programa de utilidad QUIESCE establece un único punto de coherencia,
denominado punto de inmovilidad, para uno o más conjuntos de páginas.
Para establecer puntos de recuperación regulares para una recuperación de
un punto en el tiempo posterior, debe ejecutar QUIESCE con frecuencia
entre ejecuciones regulares de COPY.
MERGECOPY
El programa de utilidad MERGECOPY fusiona copias de imagen que el
programa de utilidad COPY ha producido o copias incorporadas que los
programas de utilidad LOAD o REORG han producido. MERGECOPY
puede fusionar varias copias incrementales de un espacio de tablas para
crear una copia incremental. También puede fusionar copias incrementales
con una copia de imagen completa para crear una nueva copia de imagen
completa.
BACKUP SYSTEM
El programa de utilidad BACKUP SYSTEM en línea invoca z/OS
DFSMShsm (Versión 1 Release 5 o superior). BACKUP SYSTEM copia los
volúmenes en los que residen los datos de DB2 y la información de
registro de DB2 para un subsistema DB2 sin compartimiento de datos o
para un grupo de compartimiento de datos de DB2.
RECOVER
El programa de utilidad RECOVER recupera datos al estado actual o a un
punto en el tiempo anterior restaurando una copia y, a continuación,
aplicando registros del archivo de registro.
REBUILD INDEX
El programa de utilidad REBUILD INDEX vuelve a construir índices de la
tabla a la que hacen referencia.
REPORT
El programa de utilidad REPORT proporciona la información necesaria
para recuperar un espacio de tablas, un índice o un espacio de tablas y
todos sus índices. También puede utilizar el programa de utilidad REPORT
para obtener información de recuperación sobre el catálogo.
RESTORE SYSTEM
El programa de utilidad RESTORE SYSTEM en línea invoca z/OS
DFSMShsm (Versión 1 Release 5 o superior). RESTORE SYSTEM utiliza
datos el programa de utilidad BACKUP SYSTEM ha copiado.
También puede utilizar las siguientes herramientas de IBM DB2 e IMS en distintas
situaciones de copia de seguridad y recuperación:
IBM Application Recovery Tool for IMS and DB2 Databases
Herramienta que simplifica y coordina la recuperación de datos de IMS y

DB2 en un punto común, reduciendo de este modo el tiempo y coste de
recuperación y disponibilidad de los datos.
DB2 Archive Log Accelerator
Herramienta que reduce la sobrecarga asociada con la gestión del registro
de base de datos para equilibrar los aumentos del crecimiento del registro
de archivado.
DB2 Change Accumulation Tool
Herramienta que restaura de forma rápida objetos de base de datos con
precisión y la mínima interrupción, estableciendo el ámbito y la
especificidad de la creación de copia de imagen mediante la utilización de
tarjetas de control.
DB2 Log Analysis Tool
Herramienta que proporciona una herramienta muy útil para asegurar una
alta disponibilidad y el control completo sobre la integridad de datos. Esta
herramienta le permite supervisar los cambios en los datos mediante la
creación automática de informes de los cambios que se realizan en las
tablas de base de datos.
DB2 Object Restore
Herramienta que le permite recuperar activos de datos valiosos mediante
la restauración rápida de objetos descartados sin tiempo de inactividad,
incluso si ya no existen en el catálogo de DB2. Estos objetos descartados
pueden incluir bases de datos, espacios de tablas, tablas, índices, datos y
autorizaciones de tabla.
Reinicio de DB2
Una clave de la idea de alta disponibilidad consiste en ser capaz de reiniciar
rápidamente el subsistema DB2 después de una interrupción no planificada.
v Se puede producir algún proceso de reinicio simultáneamente con trabajo nuevo.
Además, puede optar por posponer algún proceso.
v Durante un reinicio, DB2 aplica los cambios en los datos de su registro que no se
habían escrito durante el tiempo de anomalía. Parte de este proceso se puede
ejecutar en paralelo.
v Puede registrar DB2 en Automatic Restart Manager de OS/390. Este recurso
reinicia automáticamente DB2 en caso de que se detenga como resultado de una
anomalía.
Copias de seguridad y comprobaciones de datos regulares

La planificación de copias de seguridad y comprobaciones de datos de forma
regular es importante. Cada sitio debe tener una planificación en el lugar adecuado
para comprobar de forma periódica si existen daños en los datos y su coherencia,
comprobar la utilización eficaz de las estructuras de almacenamiento y recopilar
información para ajustar el subsistema DB2 para obtener un rendimiento óptimo.
Específicamente, planifique las actividades siguientes:

v Realice copias de seguridad frecuentes para prepararse para situaciones de
recuperación potenciales. Debe realizar de forma regular copias de imagen
completas o incrementales de las estructuras de datos de DB2 y de las
estructuras de subsistemas DB2.
v Utilice el programa de utilidad CHECK periódicamente o después de un reinicio
condicional o una recuperación para asegurar la coherencia de los datos y
asegurar que los datos no están dañados. Un reinicio condicional le permite
omitir una parte del proceso de registro durante el reinicio de DB2.
– El programa de utilidad CHECK DATA comprueba los espacios de tablas
para ver si existen violaciones de restricciones de referencia o de
comprobación y notifica esta información. Debe ejecutar CHECK DATA
después de un reinicio condicional o en una recuperación puntual en el
tiempo en todos los espacios de tablas en los que es posible que las tablas
padre y dependientes no estén sincronizadas. También puede ejecutar CHECK
DATA para un espacio de tablas base y el correspondiente espacio de tablas
LOB.
– El programa de utilidad CHECK INDEX prueba si los índices son coherentes
con los datos que indexan. Debe ejecutar CHECK INDEX después de un
reinicio condicional o una recuperación puntual en el tiempo en todos los
espacios de tablas en los que es posible que los índices no sean coherentes
con los datos. También debe utilizar CHECK INDEX antes de ejecutar
CHECK DATA para asegurarse de que los índices que CHECK DATA utiliza
son válidos.
v Ejecute el programa de utilidad REORG cuando es necesario organizar y
equilibrar los datos en espacios de índice y espacios de tablas.
v Utilice el programa de utilidad RUNSTATS para recopilar estadísticas sobre
objetos de DB2. DB2 utiliza estas estadísticas para seleccionar la vía de acceso a
los datos más eficaz.
“Directrices para la reorganización de datos” en la página 252
Control de los cambios en las bases de datos y de la

coherencia de los datos
Para poder comprender por completo cómo funciona la copia de seguridad y la
recuperación, primero debe estar familiarizado con el modo en que DB2 mantiene
los datos coherentes cuando se producen cambios en los datos. Los procesos que
aseguran la coherencia de los datos incluyen operaciones de confirmación y de
retrotracción y bloqueos. Este tema proporciona una visión general sobre cómo las
operaciones de confirmación y de retrotracción consiguen un punto de coherencia
en los datos. También explica cómo DB2 mantiene la coherencia cuando se
intercambian datos entre servidores.
Confirmación y retrotracción de transacciones

En cualquier momento, un proceso de aplicaciones puede estar formado por una
única transacción. Sin embargo, en la duración de un proceso de aplicaciones
pueden intervenir muchas transacciones como resultado de operaciones de
confirmación o retrotracción.

Una transacción se inicia cuando le leen o escriben datos. Una transacción finaliza
con una sentencia COMMIT o ROLLBACK o con el final de un proceso de
aplicaciones.
v La sentencia COMMIT confirma los cambios realizados en la base de datos
durante la transacción actual y hace que los cambios sean permanentes.
DB2 retiene o libera bloqueos adquiridos en nombre de un proceso de
aplicaciones, según el nivel de aislamiento que se utiliza y la causa del bloqueo.
v La sentencia ROLLBACK restituye, o cancela, los cambios realizados en la base
de datos por la transacción actual y restaura los datos cambiados al estado que
tenían antes de iniciarse la transacción.
El inicio y la terminación de una transacción definen puntos de coherencia dentro de

un proceso de aplicaciones. Un punto de coherencia es un momento en que todos
los datos recuperables a los que accede un programa de aplicación son coherentes
con otros datos. La figura siguiente ilustra estos conceptos.
Figura 47. Transacción con una operación de confirmación
Cuando una operación de retrotracción es satisfactoria, DB2 restituye los cambios

sin confirmar para restaurar la coherencia de datos que existía cuando se inició la
unidad de trabajo. Es decir, DB2 deshace el trabajo, tal como muestra la figura
siguiente. Si la transacción falla, se inicia la operación de retrotracción.
Figura 48. Restitución de los cambios de una transacción
Una alternativa a la cancelación de una transacción es restituir los cambios a un

punto de salvaguarda. Un punto de salvaguarda es una entidad con nombre que
representa el estado de los datos en un determinado momento durante una
transacción. Puede utilizar la sentencia ROLLBACK para restituir los cambios
únicamente a un punto de salvaguarda dentro de la transacción sin finalizar la
transacción.

El soporte de punto de salvaguarda simplifica la codificación de lógica de
aplicación para controlar la gestión de una colección de sentencias de SQL dentro
de una transacción. La aplicación puede establecer un punto de salvaguarda dentro
de una transacción. Sin afectar al resultado global de la transacción, la lógica de
aplicación puede deshacer los cambios que se han realizado en los datos desde que
la aplicación ha establecido el punto de salvaguarda. La utilización de puntos de
salvaguarda hace que la codificación de aplicaciones sea más eficaz puesto que no
es necesario incluir lógica de contingencia y de ″qué ocurriría si″ en las
aplicaciones.
Tras comprender el proceso de confirmación y retrotracción, la necesidad de

confirmaciones frecuentes en el programa es evidente.
“Procesos de aplicaciones y transacciones” en la página 47
Actualizaciones coordinadas para mantener la coherencia entre

servidores
En un sistema distribuido, una transacción se puede producir en más de un
servidor. Para asegurar la coherencia de los datos, cada subsistema que participa
en una única transacción debe coordinar las operaciones de actualización; debe
realizar una confirmación o una copia de seguridad.
DB2 utiliza un proceso de confirmación en dos fases con una amplia variedad de
recursos como, por ejemplo, bases de datos relacionales a las que se accede
mediante DRDA. El soporte de DB2 para confirmación en dos fases también se
puede utilizar desde diferentes entornos de aplicaciones. DB2 puede trabajar con
otros entornos de gestión de transacciones z/OS, tales como aplicaciones IMS y
CICS y en entornos UNIX, aplicaciones Microsoft Windows y WebSphere
Application Server.
Utilizando la confirmación en dos fases puede actualizar una tabla y datos de DB2
de bases de datos no DB2 dentro de la misma transacción. El proceso está bajo el
control de uno de los subsistemas denominado coordinador. Los otros sistemas
implicados son los participantes. Por ejemplo, IMS, CICS o RRS siempre es el
coordinador en interacciones con DB2 y DB2 siempre es el participante. DB2
siempre es el coordinador en interacciones con TSO y, en este caso, controla por
completo el proceso de confirmación. En interacciones con otros DBMS, incluidos
otros subsistemas DB2, los subsistemas DB2 locales pueden ser el coordinador o un
participante.
“Cómo se coordinan las actualizaciones entre sistemas distribuidos” en la
página 315
Sucesos del proceso de recuperación

DB2 puede recuperar un conjunto de páginas utilizando una copia de seguridad.
Además, el registro de recuperación de DB2 contiene un registro de todos los
cambios que se han realizado en el conjunto de páginas. Si es necesario recuperar
los datos, DB2 restaura la copia de seguridad y aplica los cambios del registro al
conjunto de páginas a partir del momento de la copia de seguridad.

Para recuperar un conjunto de páginas, el programa de utilidad RECOVER suele
utilizar estos elementos:
v Una copia de imagen completa; que es una copia completa del conjunto de
páginas.
v Sólo para espacios de tablas, cualquier copia de imagen incremental posterior
que resuma todos los cambios que se han realizado en el espacio de tablas desde
el momento en que se ha realizado la copia de imagen anterior.
v Todos los registro del archivo de registro para el conjunto de páginas que se han
creado desde la copia de imagen más reciente.
La figura siguiente muestra una visión general de un proceso de recuperación que

incluye un ciclo completo de copias de imágenes.
Figura 49. Visión general de la recuperación de DB2
La tabla de catálogo SYSIBM.SYSCOPY puede registrar muchos ciclos completos.

El programa de utilidad RECOVER utiliza la información de la tabla de catálogo
SYSIBM.SYSCOPY para las siguientes finalidades:
v Restaurar el conjunto de páginas con los datos de la copia de imagen completa
más reciente
v Sólo para espacios de tablas, aplicar todos los cambios que se resumen en
cualquier copia de imagen incremental posterior
v Aplicar al conjunto de páginas todos los cambios registrados en el registro,
empezando por la copia de imagen más reciente
Si el registro se ha dañado o descartado, o si se han cambiado datos de forma

errónea y, a continuación, se han confirmado, puede realizar una recuperación a un
punto en el tiempo determinado. Este tipo de recuperación limita el rango de
registro del archivo de registro que el programa de utilidad RECOVER debe
aplicar.
Optimización de la disponibilidad durante la copia de

seguridad y la recuperación
Debido a que la copia de seguridad y la recuperación afectan a la disponibilidad
de los datos, debe comprender las implicaciones de varias actividades, que
incluyen los programas de utilidad en ejecución, el registro cronológico, el
archivado, la recuperación después de un desastre y el reinicio de DB2.
Ejecución de programas de utilidad
v Para reducir el tiempo de recuperación puede utilizar el programa de
utilidad RECOVER para recuperar una lista de objetos en paralelo.
v Para reducir el tiempo de copia, utilice el programa de utilidad COPY
para crear copias de imagen de una lista de objetos en paralelo.

Registro cronológico
v Para acelerar la recuperación, coloque los registros activos o de
archivado en disco. Si tiene espacio suficiente, utilice más registros
activos y registros activos más grandes.
v Haga que las agrupaciones de almacenamientos intermedios y los
almacenamientos intermedios de registro sean suficientemente grandes.
v Si se impone a DB2 una única modalidad de operación para el conjunto
de datos o registros del programa de arranque, normalmente puede
restaurar la operación dual mientras DB2 sigue en ejecución. El registro
cronológico activo dual mejora la posibilidad de recuperación en el caso
de una anomalía de disco. Puede colocar copias de los conjuntos de
datos de registro activo y de los conjuntos de datos del programa de
arranque en diferentes unidades de disco.
v Si se produce un error de E/S mientras DB2 escribe en el registro, DB2
sigue funcionando. Si el error está en el registro activo, DB2 pasa al
siguiente conjunto de datos. Si el error está en el registro de archivado,
DB2 asigna dinámicamente otro conjunto de datos de registro de
archivado.
Reinicio
Muchos procesos de recuperación implican un reinicio de DB2. Puede
minimizar el tiempo de reinicio de DB2 después de una interrupción para
que el subsistema de DB2 se active y ejecute de forma rápida.
v Para sistemas sin compartimiento de datos puede limitar la actividad de
restitución durante el reinicio de DB2. Puede aplazar la restitución de las
transacciones de ejecución larga hasta que el subsistema DB2 esté
operativo.
v Se puede producir algún proceso de reinicio simultáneamente con
trabajo nuevo. Puede optar por posponer algún proceso para que DB2
vuelva a estar en ejecución más rápidamente.
v Durante un reinicio, DB2 aplica cambios en los datos desde el registro.
Esta técnica asegura que los cambios en los datos no se pierdan, incluso
si no se han escrito algunos datos durante la anomalía. Parte del trabajo
de aplicar cambios del registro se puede ejecutar en paralelo.
v Puede registrar DB2 con Automatic Restart Manager de z/OS. Este
recurso reinicia automáticamente DB2 en caso de una anomalía.
Archivado
Si archiva en cinta, asegúrese de que tiene suficientes unidades de cintas. A
continuación, DB2 no necesita esperar para una unidad disponible en la
que montar una cinta de archivado durante la recuperación.
Recomendación: Para una recuperación rápida, mantenga como mínimo 24
horas de registros en los registros activos y mantenga en disco tantos
registros de archivado como sea posible (por ejemplo, 48 horas de
registros). Un archivado en disco y permitir que HSM (Hierarchical Storage
Management) migre en cinta es una práctica correcta.
Recuperación tras desastre
En el caso de un desastre que produce una conclusión completa del
subsistema DB2 local, el sitio necesita asegurar que los procedimientos
documentados están disponibles para una recuperación tras desastre. Por
ejemplo, un procedimiento para una recuperación externa mantiene el sitio
preparado.

Opcionalmente, puede utilizar DFSMShsm para gestionar de forma automática la
disponibilidad de espacio y datos entre los dispositivos de almacenamiento del
sistema. Por ejemplo, DFSMShsm gestiona espacio de disco trasladando conjuntos
de datos que no se han utilizado recientemente a un almacenamiento menos
costoso. DFSMShsm hace que estén disponibles los datos para la recuperación al
copiar de forma automática los conjuntos de datos nuevos o cambiados en cinta o
disco.

Capítulo 10. DB2 y la web
Esta información proporciona una visión general de alto nivel sobre los conceptos
y componentes para el entorno web en el que actúa DB2. Destaca una de las
herramientas basadas en la web de la familia de productos de WebSphere:
WebSphere Studio Application Developer.
La web ha cambiado el modo en que las empresas dirigen sus negocios. Las
corporaciones tanto grandes como pequeñas, utilizan sitios web para describir los
servicios y productos que proporcionan. Las empresas de entrega permiten a los
clientes realizar un seguimiento del progreso de sus entregas en línea. Los clientes
de bancos pueden ver sus cuentas e iniciar transacciones en línea cómodamente
desde su casa. Las empresas distribuyen información sobre los programas, las
políticas y las noticias de la empresa utilizando intranets de la empresa. Los
accionistas individuales realizan pedidos de compra y venta en línea mediante sus
corredurías cada día. La venta al por menor en línea sigue aumentando su
popularidad. Los compradores utilizan software especializado para los siguientes
tipos de transacciones entre empresas:
v Seguimiento de la actividad de adquisición
v Selección inteligente de proveedores preferidos
v Inicio electrónico de transacciones entre empresas con proveedores
Estos tan solo son unos cuantos ejemplos de las numerosas formas en que las
empresas se benefician de la gran utilidad de la web transformándose a sí mismos
en negocios bajo demanda.
El mundo de los negocios bajo demanda puede parecer un poco como un puzzle.
Antes de trabajar en un puzzle, necesita saber cómo es la imagen del puzzle una
vez acabado. Del mismo modo, antes de crear o trabajar en una aplicación de
negocio bajo demanda, debería tener un alto nivel de conocimiento del entorno
global. También debería tener información sobre los distintos productos y
herramientas de dicho entorno. Probablemente el desarrollo y la implementación
de la aplicación implica productos y herramientas en más de un sistema operativo
(por ejemplo, los sistemas operativos z/OS, Linux y Windows).
| Puede utilizar los siguientes productos, herramientas y lenguajes en un entorno de

| e-business:
v Familia de productos de Rational
v DB2 Developer Workbench
v IMS
v Navegador web
v Familia de productos de DB2
v CICS
v Servicios web
v Familia de productos de WebSphere, incluidos los productos de WebSphere
Information Integration
v DB2 Database Add-Ins for Visual Studio 2005
v Lenguajes: C, C++, C#, COBOL, Java, .NET, PHP, Perl, PL/I, Ruby on Rails,
TOAD y Visual Basic

El acceso a los datos es central en la gran mayoría de aplicaciones de negocio bajo
demanda. Del mismo modo, la lógica empresarial, que transforma datos en
información o que define una transacción empresarial, es otro componente clave.
Muchas organizaciones ya almacenan una gran cantidad de datos críticos en DB2
for z/OS. Por lo general también realizan una inversión considerable en programas
de aplicaciones que acceden y manipulan estos datos. Las empresas que tienen
intención de trasladar partes de su empresa a la web se enfrentan al reto de
determinar cómo basarse en su base de datos y lógica empresarial existentes y
cómo ampliar la utilidad de esta base utilizando la web.
El principal servidor de aplicaciones de IBM, WebSphere Application Server, ayuda

a que las empresas ″habiliten para la web″ sus datos y lógica empresarial.
WebSphere Application Server da soporte a programación del servidor, sobre la
que aprenderá más en esta información.
Utilizando productos y herramientas basados en la web, las empresas pueden

crear, desplegar y gestionar aplicaciones empresariales bajo demanda móviles.
Entorno de aplicaciones web

Las aplicaciones basadas en la web se ejecutan en un servidor de aplicaciones web
y acceden a los datos de un sistema de información empresarial como, por
ejemplo, un servidor de bases de datos de DB2. Los componentes de las
aplicaciones basadas en la web se dividen entre varios niveles o capas.
Esta información describe los distintos componentes y características

arquitectónicas de las aplicaciones web y la función que tiene DB2 en el entorno de
aplicaciones web.
En general, la interfaz de usuario está en el primer nivel, los programas de

aplicaciones están en el nivel medio y los orígenes de datos disponibles para los
programas de aplicaciones están el nivel del sistema de información empresarial. El
desarrollo de aplicaciones basadas en la web en una arquitectura de varios niveles
se denomina programación del servidor.
La escritura de programas del servidor es complicada y requiere una comprensión

detallada de las interfaces de servidor web. Afortunadamente, existen servidores
de aplicaciones como, por ejemplo, WebSphere Application Server, que están
disponibles para simplificar esta tarea. Cada uno de estos servidores de
aplicaciones define un entorno de desarrollo para aplicaciones web y proporciona
un entorno de tiempo de ejecución en el que se pueden ejecutar las aplicaciones
web. El código de servidor de aplicaciones, que proporciona el entorno de tiempo
de ejecución, da soporte a la interfaz adecuada para interactuar con el servidor
web. Con servidores de aplicaciones se pueden escribir programas para el entorno
de tiempo de ejecución del servidor de aplicaciones. Los desarrolladores de estos
programas pueden centrarse en la lógica empresarial de la aplicación web, en lugar
de hacer que la aplicación trabaje con un servidor web.
Componentes de aplicaciones basadas en la web

Todas las aplicaciones de base de datos basadas en la web tienen tres componentes
primarios: un navegador web (o cliente), un servidor de aplicaciones web y un
servidor de bases de datos.
Las aplicaciones de base de datos basadas en la web se basan en un servidor de

bases de datos, que proporciona los datos para la aplicación. El servidor de bases

de datos a veces también proporciona lógica empresarial en forma de
procedimientos almacenados. Los procedimientos almacenados pueden
proporcionar ventajas de rendimiento significativas, en especial en una arquitectura
de varios niveles. Además de servidores de bases de datos, otros componentes del
sistema de información empresarial incluyen bases de datos de IMS, mensajes de
WebSphere MQ y registros de CICS.
Los clientes manejan la lógica de presentación, que controla el modo en que los
usuarios interactúan con la aplicación. En algunos casos, el cliente valida la entrada
proporcionada por el usuario. Las aplicaciones web a veces integran applets Java
en la lógica del cliente para mejorar el nivel de presentación.
Applet
Programa Java que forma parte de una página HMTL (Hypertext Markup
Language). (HTML es el método estándar para presentar datos web a los
usuarios.) Los applets funcionan con navegadores habilitados para Java
como, por ejemplo, Microsoft Internet Explorer; se cargan cuando se
procesa la página HTML.
Los servidores de aplicaciones web gestionan la lógica empresarial. La lógica

empresarial, generalmente escrita en Java, da soporte a aplicaciones de varios
niveles. El servidor de aplicaciones web puede gestionar peticiones de varios
clientes remotos. El nivel de aplicación web puede incluir archivos JSP (JavaServer
Pages), servlets Java, componentes de Enterprise JavaBeans (EJB) o servicios web.
JSP Tecnología que proporciona un modo coherente para ampliar la
funcionalidad del servidor web y crear contenido web dinámico. Las
aplicaciones web que se desarrollan con tecnología JSP son independientes
del servidor y la plataforma.
Servlet
Programa Java que responde a las peticiones de cliente y genera respuestas
dinámicamente.
EJB Arquitectura de componentes para crear aplicaciones distribuidas con el
modelo de programación de Java. Los componentes de transacciones de
servidor se pueden volver a utilizar y proporcionan portabilidad entre
servidores de aplicaciones.
Servicios web
Aplicaciones modulares independientes que proporcionan una interfaz
entre el proveedor y el consumidor de recursos de aplicaciones. Puede leer
más sobre servicios web más adelante en esta información.
Características arquitectónicas de aplicaciones basadas en la

web
Algunas aplicaciones basadas en la web utilizan una arquitectura de dos niveles y
otras utilizan una arquitectura de n niveles formada por tres o más niveles.
Arquitectura de dos niveles
En una arquitectura de dos niveles, el cliente está en el primer nivel. El
servidor de bases de datos y el servidor de aplicaciones web residen en la
misma máquina servidor, que es el segundo nivel. El segundo nivel
proporciona los datos y ejecuta la lógica empresarial para la aplicación
web. Las organizaciones que optan por esta arquitectura normalmente
prefieren consolidar las posibilidades de las aplicaciones y las posibilidades
de las bases de datos en un único nivel. El segundo nivel es el responsable
Capítulo 10. DB2 y la web 299

de proporcionar las características de disponibilidad, escalabilidad y
rendimiento para el entorno web de la organización.
Arquitectura de n niveles
En una arquitectura de n niveles, los objetos de aplicaciones están
distribuidos entre varios niveles lógicos, generalmente tres o cuatro.
En una arquitectura de tres niveles, el servidor de bases de datos no
comparte una máquina servidor con el servidor de aplicaciones web. El
cliente está en el primer nivel, igual que en una arquitectura de dos
niveles. En el tercer nivel, el servidor de bases de datos proporciona los
datos. Por motivos de rendimiento, el servidor de bases de datos suele
utilizar procedimientos almacenados para manejar parte de la lógica
empresarial. El servidor de aplicaciones reside en el segundo nivel. El
servidor de aplicaciones maneja la parte de la lógica empresarial que no
necesita la funcionalidad que proporciona el servidor de bases de datos. En
esta opción, los componentes de hardware y software del segundo y tercer
nivel comparten la responsabilidad de las características de disponibilidad,
escalabilidad y rendimiento del entorno web.
En una arquitectura de cuatro niveles, puede existir más de un nivel lógico
dentro del nivel medio o dentro del nivel del sistema de información
empresarial. Por ejemplo:
v El nivel medio está formado por más de un servidor web. Como
alternativa, un cortafuegos intermedio puede separar el servidor web del
servidor de aplicaciones en el nivel medio.
v Un servidor de bases de datos del tercer nivel puede ser la fuente de los
datos para un servidor web del nivel medio y otro servidor de bases de
datos del cuarto nivel es la fuente de datos para un servidor de bases de
datos del tercer nivel.
Si examina todas las aplicaciones web disponibles en la actualidad, encontraría

muchas variaciones. Por ejemplo, los servidores de bases de datos se pueden
ejecutar en diversas plataformas, al igual que los clientes. Los diseñadores de
aplicaciones web utilizan una diversidad de herramientas, que repercuten en el
funcionamiento y el aspecto de las aplicaciones. Empresas diferentes eligen
herramientas diferentes. Las piezas del puzle que forman los puzles de una
empresa terminan siendo muy diferentes de las de otras empresas.
En muchos casos, el cliente y el servidor para una aplicación web están en sistemas
operativos diferentes. Por ejemplo, el cliente puede estar en un sistema operativo
basado en estación de trabajo como, por ejemplo, Windows XP o UNIX. El servidor
para la aplicación también puede estar en un servidor basado en estación de
trabajo o puede estar en un servidor empresarial como, por ejemplo, z/OS. La
figura siguiente muestra la conectividad de dos niveles entre un cliente basado en
estación de trabajo y ambos tipos de servidores.

Figura 50. Conectividad de dos niveles entre un cliente basado en estación de trabajo y
diferentes servidores de bases de datos
El navegador utiliza Hypertext Transfer Protocol (HTTP) para reenviar peticiones de

usuario a una máquina servidor del segundo nivel. (HTTP es un protocolo de
comunicación que se utiliza en la web.) El servidor web del segundo nivel invoca
el servidor de bases de datos local para satisfacer los requisitos de datos de la
aplicación.
La figura siguiente ilustra la utilización de una arquitectura de n niveles. En este

ejemplo, hay dos servidores web instalados en el nivel medio: un servidor HTTP,
como por ejemplo IBM HTTP Server, y un servidor de aplicaciones web, como por
ejemplo WebSphere Application Server. El servidor de aplicaciones da soporte a los
distintos componentes que pueden ejecutarse en el nivel medio (archivos JSP,
servlets, EJBs y servicios web). Cada uno de estos componentes realiza funciones
que dan soporte a aplicaciones cliente.
En el entorno WebSphere Application Server, un dispositivo del primer nivel, como

por ejemplo un navegador, puede utilizar HTTP para acceder al servidor HTTP en
el nivel medio. A continuación, el servidor HTTP puede reproducir la salida
producida por JSP, servlets y otros componentes que se ejecutan en un entorno
WebSphere Application Server. Los JSP o servlets pueden utilizar JDBC, SQLJ o
EJBs (indirectamente) para acceder a los datos de un servidor de bases de datos
DB2 del tercer nivel.

Figura 51. Conectividad de n niveles con un cliente basado en estación de trabajo, dos
servidores web y diferentes servidores de bases de datos
Ventajas de DB2 para z/OS como servidor

Para cada tipo de arquitectura, DB2 for z/OS proporciona una solución eficaz para
aplicaciones web.
De manera específica, la utilización de DB2 for z/OS como servidor de bases de

datos para una aplicación web proporciona las siguientes ventajas:
v Escalabilidad excepcional. El volumen de transacciones en cualquier aplicación
web varía. Las cargas de transacciones pueden aumentar, o alcanzar mayor
actividad, en diferentes horas del día, en diferentes días del mes o en diferentes
momentos del año. Las cargas de transacciones también tienden a aumentar con
el tiempo. En un entorno Sysplex paralelo, DB2 for z/OS puede manejar el
rango completo de cargas de transacciones con muy poco o ningún impacto en
el rendimiento. Generalmente un usuario individual no se da cuenta de lo
ocupado que está el sistema en un punto en el tiempo determinado.
v Alto grado de disponibilidad. Cuando DB2 for z/OS se ejecuta en un entorno
Sysplex paralelo, la disponibilidad de los datos y las aplicaciones es muy alta. Si
un subsistema DB2 no está disponible, por ejemplo, debido a mantenimiento,
otros subsistemas DB2 del Sysplex toman el relevo de la carga de trabajo. Los
usuarios no se dan cuenta de que parte del sistema no está disponible porque
tienen acceso a los datos y aplicaciones que necesitan.
v Capacidad de gestionar una carga de trabajo mixta. DB2 for z/OS gestiona de
forma eficaz y con un buen rendimiento las prioridades de una carga de trabajo
mixta como resultado de su estrecha integración con z/OS Workload Manager.
v Protección de la integridad de los datos. Los usuarios de DB2 for z/OS pueden
beneficiarse de la eficacia conocida del producto en las áreas de seguridad y
fiabilidad.

Aplicaciones basadas en la web y WebSphere Studio Application
Developer
WebSphere Studio Application Developer ofrece características que los
desarrolladores pueden utilizar para crear aplicaciones basadas en la web.
WebSphere Studio Application Developer es una herramienta diseñada para

desarrolladores de aplicaciones Java y J2EE que requieren soporte de servicios web,
XML y web integrado. Esta herramienta incluye varios recursos y conectores
incorporados que facilitan la tarea de acceso a los datos almacenados en bases de
datos de DB2. (Un conector es la unidad más pequeña de función que se puede
desarrollar y transmitir de forma independiente.)
| Cada producto de WebSphere Studio ofrece los mismos entornos de desarrollo

| integrados y una base común de herramientas. Cada producto se basa en la
| función de otro producto con herramientas de conector adicionales. Por ejemplo,
| WebSphere Studio Application Developer incluye toda la función de WebSphere
| Studio Site Developer además de conectores para una función adicional como, por
| ejemplo, soporte de Enterprise JavaBean.
WebSphere Studio Site Developer
Ofrece un entorno de desarrollo visual que facilita la colaboración en
equipos de desarrollo de webs.
Proporciona un entorno de desarrollo para desarrolladores de aplicaciones
Java y añade herramientas para el desarrollo de aplicaciones EJB.
WebSphere Studio Application Developer Integrated Edition
Incluye la función de WebSphere Studio Application Developer y añade
herramientas para la integración con sistemas de fondo.
WebSphere Studio Enterprise Developer
Incluye la función de WebSphere Studio Application Developer Integrated
Edition y una función adicional como, por ejemplo, herramientas de
desarrollo de aplicaciones z/OS.
WebSphere Studio Application Developer proporciona un IDE para crear, probar,

depurar e implementar muchos componentes diferentes. Estos componentes
incluyen bases de datos, web, XML y componentes Java. Los componentes Java
incluyen aplicaciones Java J2EE, archivos JSP, EJB, servlets y applets.
Debido a que WebSphere Studio Application Developer se puede trasladar entre

sistemas operativos, las aplicaciones que se desarrollan con WebSphere Studio
Application Developer son muy escalables. Esto significa que se pueden desarrollar
aplicaciones en un sistema (por ejemplo, AIX) y ejecutarlas en sistemas mucho más
grandes (por ejemplo, z/OS).
WebSphere Studio Application Developer da soporte al modelo de servidor de Java

2 Enterprise Edition (J2EE). J2EE es un conjunto de especificaciones para trabajar
con aplicaciones de varios niveles en la plataforma J2EE. La plataforma J2EE
incluye servicios, API y protocolos para desarrollar aplicaciones basadas en la web
de varios niveles. La figura siguiente muestra un entorno de desarrollo de
aplicaciones de varios niveles que da soporte a aplicaciones web y a aplicaciones
J2EE.

Figura 52. Entorno de desarrollo de aplicaciones web
Cada producto de WebSphere Studio utiliza perspectivas. Una perspectiva es un

conjunto de vistas, editores y herramientas que los desarrolladores utilizan para
manipular recursos. Puede utilizar algunas de estas perspectivas para acceder a
bases de datos de DB2.
Perspectiva de datos
Los desarrolladores utilizan la perspectiva de datos para gestionar
definiciones y conexiones de bases de datos que necesitan para el
desarrollo de aplicaciones. Puede conectarse a bases de datos de DB2 e
importar definiciones de bases de datos, esquemas, tablas, procedimientos
almacenados, funciones definidas por el usuario de SQL y vistas.
WebSphere Studio Application Developer proporciona un editor de SQL
que le ayuda a crear y modificar sentencias de SQL.
Mediante la perspectiva de datos, los desarrolladores pueden crear los
siguientes tipos de rutinas de DB2:
v Procedimientos almacenados de SQL y Java
v Funciones definidas por el usuario de SQL
v Funciones definidas por el usuario que leen o reciben mensajes de colas
de mensajes de WebSphere MQ
Cuando los desarrolladores escriben procedimientos almacenados que
utilizan JDBC o SQL, a continuación pueden crear un derivador para el
procedimiento almacenado como un bean de Java o como un método
dentro de un EJB de sesión. La derivación de un procedimiento
almacenado evita la duplicación de su lógica empresarial en otros
componentes y puede dar como resultado una mejora en el rendimiento.
(Un derivador encapsula un objeto y modifica la interfaz o el
comportamiento del objeto de algún modo. Los beans de sesión son beans de
empresa que solamente existen durante una sesión de cliente/servidor.)
Perspectiva de J2EE
Los desarrolladores trabajan con la perspectiva de J2EE para crear
aplicaciones de EJB para acceder a DB2. La perspectiva de J2EE da soporte
a EJB 1.1 y EJB 2.0. Esta perspectiva proporciona herramientas gráficas
para visualizar y editar esquemas de DB2 que ayudan a los desarrolladores
a correlacionar los EJB de entidad con tablas de DB2. Los beans de entidad
son beans de empresa que contienen datos permanentes.
WebSphere Studio Application Developer también proporciona una
característica que automáticamente genera un método de EJB de sesión
para invocar un procedimiento almacenado de DB2.
Perspectiva de web
Los desarrolladores utilizan la perspectiva de web para generar páginas
web a partir de sentencias de SQL. WebSphere Studio Application
Developer proporciona una biblioteca de códigos de acciones de JSP para
acceder a bases de datos. Una biblioteca de códigos define los códigos
personalizados que se utilizan en un documento. Mediante las bibliotecas
de códigos de JSP, los desarrolladores pueden ejecutar sentencias de SQL y
procedimientos almacenados. Pueden actualizar o suprimir con facilidad
los conjuntos de resultados que las sentencias de SQL o los procedimientos
almacenados devuelven.
Perspectiva de servicios web
Los desarrolladores utilizan un editor de XML incorporado para crear
archivos XML para construir aplicaciones de servicios web de DB2 basadas
en sentencias de SQL.
“Desarrollo de aplicaciones de DB2 en entornos de desarrollo integrados” en la
página 147
XML y DB2
Puede utilizar XML en una base de datos de DB2. XML, que significa Extensible
Markup Language, es un lenguaje de códigos basado en texto. Su estilo es similar
al de HTML, salvo que los usuarios de XML pueden definir sus propios códigos.
El crecimiento explosivo de Internet ha sido un catalizador para el desarrollo de

XML y su aceptación en la industria. Debido al aumento drástico de aplicaciones
de negocio bajo demanda, las organizaciones deben intercambiar datos en un
formato abierto y eficaz. Las opciones disponibles antes del desarrollo de XML
eran Standard Generalized Markup Language (SGML) y HTML. SGML es
demasiado complejo para una utilización generalizada en la web. HTML es
adecuado para la presentación de páginas web, pero no está diseñado para un
intercambio de información sencillo. XML ha surgido como una simplificación útil
y flexible de SGML que permite la definición y el proceso de documentos para
intercambiar datos entre empresas, entre aplicaciones y entre sistemas.
Puede imaginar HTML como un medio para comunicar información entre sistemas
y personas. Puede imaginar XML como un medio para comunicar información
entre sistemas. Puede convertir XML en HTML para que las personas puedan ver
la información.
″Programación para XML″ (DB2 for z/OS XML Guide)
Ventajas de utilizar XML con DB2 para z/OS

Las organizaciones pueden disfrutar de numerosas ventajas utilizando XML con
DB2 para z/OS, que incluyen relaciones de clientes mejoradas, operaciones
internas optimizadas, sociedades maximizadas y opciones en herramientas y
software.
Con XML, las organizaciones pueden conseguir las siguientes ventajas:

Relaciones de clientes mejoradas
XML le permite entregar información personalizada a los clientes, habilitar
nuevos canales de distribución y responder más rápidamente a las
necesidades de los clientes.

Operaciones internas optimizadas
Con XML puede dirigir datos empresariales desde los sistemas existentes a
la web. XML le permite automatizar transacciones que no requieren
interacción humana.
Sociedades maximizadas
Debido a la utilización extendida de XML en la industria, puede compartir
información con facilidad con proveedores, compradores y socios.
Herramientas y software
Puede beneficiarse de muchas herramientas y software XML como, por
ejemplo, WebSphere Studio, analizadores y procesadores XML , la función
de publicación SQL/XML y DB2 XML Extender.
Existen vocabularios de XML para industrias específicas como ayuda para que las
organizaciones de dichas industrias puedan estandarizar su utilización de XML.
Un vocabulario de XML es una descripción diseñada para una finalidad específica.
La utilización extendida en la industria de XML ha tenido como resultado
transacciones entre empresas más eficaces y con mayor rendimiento.
Modos de utilizar XML con DB2 para z/OS

Las organizaciones utilizan XML para procesar documentos y publicar información
en la web. Esta información proporciona una visión general de las distintas
funciones herramientas de publicación que le ayudan a integrar XML con datos de
DB2.
| Para integrar XML con datos de DB2 puede utilizar las funciones de publicación de
| SQL/XML y los recursos de DB2 XML Extender que están específicamente
| diseñados para trabajar con DB2. El soporte de XML nativo, o pureXML, en DB2
| proporciona unas posibilidades versátiles para gestionar los datos XML. DB2
| almacena y procesa XML en su formato jerárquico inherente, evitando de este
| modo las limitaciones de rendimiento y flexibilidad que se producen cuando se
| almacena XML como texto en varios CLOB o se correlaciona con tablas
| relacionales.
Las funciones de publicación de SQL/XML permiten a las aplicaciones generar

datos XML a partir de datos relacionales. Con DB2 XML Extender puede publicar
XML a partir de datos relacionales, almacenar datos XML intactos o descompuestos
(fragmentados) en tablas de DB2 o manipular y transformar documentos XML. Por
ejemplo, XML es una opción popular cuando se desea enviar datos de DB2 a otro
sistema o a otra aplicación en un formato común. Puede elegir uno de los distintos
modos de publicar documentos XML:
v Utilizar funciones de SQL/XML integradas con DB2.
DB2 integra funciones de publicación de SQL/XML en el producto DB2. Un
conjunto de funciones incorporadas de SQL permite a las aplicaciones generar
datos XML a partir de datos de DB2 con un alto rendimiento. Las funciones de
publicación de SQL/XML pueden reducir los esfuerzos de desarrollo de
aplicaciones en la generación de XML para integración de datos, intercambio de
información y servicios web.
v Beneficiarse del soporte de Servicios web de DB2.
Los Servicios web proporcionan un medio para que los programas puedan
invocar a otros programas, generalmente en Internet, que transmiten parámetros
de entrada y generan resultados como XML.

v Utilizar una herramienta para codificar XML.
WebSphere Studio proporciona un entorno de desarrollo para publicar
documentos XML a partir de datos relacionales.
| Las funciones de DB2 XML Extender le permiten almacenar documentos XML en

| DB2, de forma intacta o como datos relacionales. DB2 XML Extender proporciona
| métodos para transformaciones automáticas entre datos XML y relacionales. Puede
| almacenar documentos XML enteros en bases de datos de DB2 como datos de tipo
| carácter o en archivos externos que DB2 gestiona. Específicamente, DB2 XML
| Extender proporciona:
v Tipos de datos que le permiten almacenar documentos XML en bases de datos
de DB2
v Funciones que le ayudan a trabajar con estos documentos estructurados
v Funciones de recuperación, que le permiten recuperar un documento XML
entero o elementos o atributos individuales
“Visión general de pureXML” en la página 24
“SOA, XML y servicios web”
SOA, XML y servicios web

| Los datos XML son un ingrediente clave para soluciones basadas en Service
| Oriented Architecture (SOA). Puede utilizar aplicaciones SOA basadas en XML
| para crear servicios web basados en XML.
Los servicios web son conjuntos de funciones empresariales que las aplicaciones u
otros servicios web pueden invocar a través de Internet. Un servicio web realiza un
servicio útil en nombre de un peticionario. Dicho servicio puede incluir varias
empresas e industrias.
Ejemplo: Suponga que un sistema de reservas de una línea aérea es un servicio

web. Al ofrecer este servicio, la línea aérea hace que sea más fácil para sus clientes
integrar el servicio en sus aplicaciones de planificación de viajes. Un proveedor
también puede utilizar el servicio para que sus compradores puedan acceder a su
información de inventario y precios.
Los servicios web le permiten acceder a datos de diversas base de datos y

ubicaciones de Internet. DB2 puede actuar como un peticionario de servicios web
al permitir que las aplicaciones de DB2 invoquen servicios web mediante SQL.
DB2 también puede actuar como un proveedor de servicios web mediante WORF
(infraestructura de tiempo de ejecución de objeto de servicios web) de DB2 en
combinación con WebSphere Application Server, lo cual le permite acceder a
procedimientos almacenados y datos de DB2 como servicios web.
Las funciones que los servicios web realizan pueden ser desde peticiones simples a
procesos empresariales complicados. Puede definir un servicio web básico
utilizando sentencias de SQL estándar y procedimientos almacenados de DB2 XML
Extender.
Con la utilización de XML para intercambio de datos, los servicios web dan
soporte a una interacción entre un proveedor de servicios y un peticionario de

servicios que es independiente de las plataformas y de los lenguajes de
programación. La infraestructura de servicios web incluye los siguientes elementos
básicos:
v Simple Object Access Protocol (SOAP) utiliza mensajes XML para intercambiar
información entre proveedores de servicios y peticionarios de servicios. SOAP
define componentes de servicios web, entre los que se incluyen mensajes XML,
tipos de datos que utilizan las aplicaciones y llamadas y respuestas de
procedimientos remotos.
v Web Services Description Language (WSDL) describe qué puede hacer un
servicio web, dónde reside el servicio y cómo invocar el servicio. WSDL
especifica un vocabulario de XML que contiene toda la información necesaria
para la integración y que automatiza la comunicación entre aplicaciones de
servicios web.
v Universal Description, Discovery, and Integration (UDDI) proporciona un
registro de información empresarial, similar a una guía telefónica, que los
usuarios y aplicaciones utilizan para buscar los servicios web necesarios.
Puede utilizar productos de WebSphere para crear aplicaciones de servicios web.

WebSphere Studio proporciona herramientas para crear servicios web que incluyen
interfaces WSDL y publicarlos directamente en un registro de UDDI.

Capítulo 11. Acceso a datos distribuidos
Los entornos de informática distribuida generalmente implican peticiones de
usuarios en un DBMS, a los que se hace referencia como clientes, que son
procesadas por otros DBMS, a los que se hace referencia como servidor. El DBMS
servidor suele ser remoto para el cliente. A los entornos de informática distribuida
les corresponden unas técnicas de programación e implicaciones de rendimiento
determinadas.
El entorno distribuido DB2 da soporte a una arquitectura de de dos niveles y de

múltiples niveles.
Un DBMS, tanto local como remoto, se conoce en el subsistema DB2 por su

nombre de ubicación. Los sistemas remotos utilizan el nombre de ubicación, o un
nombre de ubicación de alias, para acceder a un subsistema DB2. Puede definir un
máximo de ocho nombres de ubicación para un subsistema DB2.
El nombre de ubicación del subsistema DB2 se define en el BSDS durante la

instalación de DB2. La base de datos de comunicaciones (CDB) registra el nombre
de ubicación y la dirección de red de un DBMS remoto. La CDB es un conjunto de
tablas del catálogo de DB2.
El método primario que DB2 utiliza para acceder a los datos de un servidor
remoto se basa en DRDA (Distributed Relational Database Architecture).
| Si la aplicación realiza actualizaciones en dos o más DBMS, cada DBMS garantiza

que las unidades de trabajo se confirmen o retrotraigan de forma coherente. Los
protocolos de confirmación distribuida que se utilizan en la conexión de red
imponen si los DBMS pueden realizar actualizaciones o si las actualizaciones están
restringidas a un único DBMS.
Los ejemplos siguientes muestran sentencias que se pueden utilizar para acceder a
datos distribuidos.
Ejemplo 1: Puede escribir sentencias como las siguientes para acceder a los datos
de un servidor remoto:
EXEC SQL
CONNECT TO CHICAGO;
SELECT * FROM IDEMP01.EMP
También puede escribir una consulta como la siguiente para realizar la misma
tarea:
SELECT * FROM CHICAGO.IDEMP01.EMP
Para poder ejecutar cualquier consulta en la ubicación CHICAGO, primero debe

vincular un paquete en el servidor CHICAGO.
Ejemplo 2: Puede llamar a un procedimiento almacenado para acceder a los datos

de un servidor remoto. El programa ejecuta estas sentencias:

EXEC SQL
CONNECT TO ATLANTA;
EXEC SQL
CALL nombre_procedimiento (lista_parámetros);
La lista de parámetros es una lista de variables de lenguaje principal que se pasa al

procedimiento almacenado y en la que devuelve los resultados de su ejecución. El
procedimiento almacenado ya debe existir en la ubicación ATLANTA.
“Datos distribuidos” en la página 51
“Entorno de aplicaciones web” en la página 298
“Distribución de datos y acceso de web” en la página 6
“Efectos de los datos distribuidos en la preparación de programas” en la página
314
″Mejoras de DRDA″ (DB2 Installation Guide)
Modos de implementar datos distribuidos en programas

Puede conectarse a un servidor remoto de varios modos. Puede codificar una
aplicación que utiliza DRDA para acceder a datos de una ubicación remota
utilizando sentencias CONNECT o nombres en tres partes y alias.
Con cualquier método que utilice, deberá vincular los DBRM para las sentencias de
SQL que deben ejecutarse en el servidor con paquetes que residan en el servidor.
v En el subsistema DB2 local, utilice el mandato BIND PLAN para crear un plan
de aplicación.
v En la ubicación remota, utilice el mandato BIND PACKAGE para crear un
paquete de aplicación que utilice el plan de aplicación local.
″Programación para DRDA″ (DB2 Reference for Remote DRDA Requesters and
Servers)
Sentencias CONNECT explícitas

La utilización de sentencias CONNECT proporciona portabilidad de aplicaciones
entre todos los clientes de IBM y requiere que la aplicación gestione conexiones.
Mediante la sentencia CONNECT, un programa de aplicación se conecta

explícitamente a cada servidor. Debe vincular los DBRM para las sentencias de
SQL que deben ejecutarse en el servidor con paquetes que residan en dicho
servidor.
La aplicación se conecta a cada servidor basándose en el nombre de ubicación de

la sentencia CONNECT. Puede especificar explícitamente un nombre de ubicación
o puede especificar un nombre de ubicación en una variable de lenguaje principal.
La emisión de la sentencia CONNECT cambia el registro especial CURRENT
SERVER para que muestre la ubicación del nuevo servidor.
Ejemplo: Suponga que una aplicación incluye un bucle de programa que lee un
nombre de ubicación, se conecta a la ubicación y ejecuta una sentencia INSERT. La
aplicación inserta un nuevo nombre de ubicación en una variable de lenguaje
principal, :LOCATION_NAME, y ejecuta las sentencias siguientes:

EXEC SQL
CONNECT TO :LOCATION_NAME;
EXEC SQL
INSERT INTO IDP101.PROJ VALUES (:PROJNO, :PROJNAME, :DEPTNO,
:RESPEMP, :MAJPROJ);
Las variables de lenguaje principal coinciden con la declaración para la tabla PROJ.
DB2 garantiza la coherencia de los datos en una transacción distribuida. Para

mantener la coherencia de los datos en todas las ubicaciones, la aplicación
confirma el trabajo únicamente después de ejecutarse el bucle de programa para
todas las ubicaciones. Tanto si cada ubicación confirma INSERT como si una
anomalía impide la inserción a cualquier ubicación, todas las demás ubicaciones
retrotraen INSERT.
″CONNECT″ (Consulta de DB2 SQL)
Servers)
Nombres en tres partes

La utilización de nombres de objetos en tres partes y alias proporciona a la
aplicación transparencia de ubicación; los objetos se pueden mover a una ubicación
nueva sin necesidad de realizar cambios en la aplicación. En lugar de ello, el
DBMS gestiona las conexiones subyacentes.
Puede utilizar nombres en tres partes para acceder a datos de una ubicación
remota, incluidas tablas y vistas. Con la utilización de un nombre en tres partes, o
un alias, un programa de aplicación conecta implícitamente a cada servidor. Con
estos métodos de acceso, el servidor de bases de datos controla dónde se ejecuta la
sentencia.
Un nombre de tres partes está formado por:

v Un nombre de UBICACIÓN que identifica exclusivamente el servidor remoto al
que desea acceder
v Un ID de AUTORIZACIÓN que identifica el propietario del objeto (la tabla o
vista) en la ubicación a la que desea acceder
v Un nombre de OBJETO que identifica el objeto en la ubicación a la que desea
acceder
Ejemplo: Este ejemplo muestra cómo una aplicación utiliza un nombre en tres
partes en sentencias INSERT, PREPARE y EXECUTE. Suponga que la aplicación
obtiene un nombre de ubicación, ’SAN_JOSE’. A continuación, crea la siguiente
serie de caracteres:
INSERT INTO SAN_JOSE.IDP101.PROJ VALUES (?,?,?,?,?)
La aplicación asigna la serie de caracteres a la variable INSERTX y, a continuación,

ejecuta estas sentencias:
EXEC SQL
PREPARE STMT1 FROM :INSERTX;
EXEC SQL
EXECUTE STMT1 USING :PROJNO, :PROJNAME, :DEPTNO, :RESPEMP, :MAJPROJ;
Las variables de lenguaje principal coinciden con la declaración para la tabla PROJ.
Capítulo 11. Acceso a datos distribuidos 311

Recomendación: Si tiene intención de mover su aplicación de un servidor z/OS a
otro servidor, no debe utilizar nombres en tres partes. Por ejemplo, una aplicación
cliente puede conectarse a un servidor z/OS y, a continuación, emitir un nombre
en tres partes para un objeto que reside en un servidor Linux. DB2 for z/OS es el
único servidor que automáticamente reenvía peticiones de SQL que hacen
referencia a objetos que no residen en el servidor conectado.
Un método alternativo útil consiste en utilizar alias al crear serie de caracteres que
se convierten en sentencias preparadas, en lugar de utilizar nombres completos en
tres partes.
Servers)
Alias
Un alias es un sustituto para el nombre en tres partes de una tabla o vista. Un alias
puede estar definido en un servidor local y puede hacer referencia a una tabla o
vista que esté en el servidor actual o en un servidor remoto. El nombre de alias se
puede utilizar dondequiera que se pueda utilizar el nombre de tabla o el nombre
de vista para hacer referencia a la tabla o vista en una sentencia de SQL.
Suponga que de vez en cuando se trasladan datos de un subsistema DB2 a otro.

Idealmente, los usuarios que consultan estos datos no se ven afectados cuando se
produce esta actividad. Los usuarios desean iniciar la sesión en el mismo sistema y
acceder a la misma tabla o vista, independientemente de donde residan los datos.
Este resultado se puede conseguir utilizando un alias para un nombre de objeto.
Un alias puede tener como máximo 128 caracteres, calificado por un ID de

propietario. Utilice las sentencias CREATE ALIAS y DROP ALIAS para gestionar
los alias.
Nota: Suponga que crea un alias del modo siguiente:

CREATE ALIAS TESTTAB FOR USIBMSTODB22.IDEMP01.EMP;
Si un usuario con el ID JONES crea dinámicamente el alias, el alias pertenece a

JONES y la tabla se consulta del modo siguiente:
SELECT SUM(SALARY), SUM(BONUS), SUM(COMM)
FROM JONES.TESTTAB;
El objeto para el cual está definiendo un alias no es necesario que exista al ejecutar
la sentencia CREATE ALIAS. Sin embargo, el objeto debe existir cuando se ejecute
una sentencia que haga referencia al alias.
Si desea que una aplicación acceda a un servidor que no sea el servidor

especificado en un nombre de ubicación, no es necesario que cambie el nombre de
ubicación. En lugar de ello, puede utilizar un alias de ubicación para alterar
temporalmente el nombre de ubicación que la aplicación utiliza para acceder a un
servidor. Como resultado, un peticionario de DB2 for z/OS puede acceder a varias
bases de datos de DB2 que tienen el mismo nombre pero diferentes direcciones de
red. Los alias de ubicación permiten migrar más fácilmente a un servidor de DB2 y
minimizan los cambios en la aplicación.
Una vez creado un alias, cualquier usuario con autoridad sobre el objeto al que
hace referencia el alias puede utilizar este alias. Un usuario no necesita ningún
privilegio separado para utilizar el alias.

″CREATE ALIAS″ (Consulta de DB2 SQL)
Servers)
Comparación de nombres en tres partes y alias

Los nombres en tres partes y los alias tienen sus propias ventajas exclusivas. La
comprensión de las diferencias y las ventajas le ayuda a realizar decisiones
correctas para el entorno distribuido.
Puede utilizar siempre nombres en tres partes para hacer referencia a datos de otro
servidor remoto. La ventaja de los nombres en tres partes es que permiten ejecutar
código de aplicaciones en diferentes ubicaciones de DB2 sin la sobrecarga adicional
del mantenimiento de alias. Sin embargo, si las ubicaciones de las tablas cambian,
también debe cambiar las aplicaciones afectadas.
La ventaja de los alias es que le permiten mover datos sin necesidad de modificar
el código de aplicaciones o consultas interactivas. Sin embargo, si mueve una tabla
o vista, debe descartar los alias que hacen referencia a estas tablas o vistas. A
continuación, puede volver a crear los alias con los nuevos nombres de ubicación.
Servers)
Modos en que los datos distribuidos afectan a otras tareas

Cuando trabaja en un entorno distribuido, debe considerar cómo afecta el entorno
a las actividades de planificación y programación.
Efectos de los datos distribuidos en la planificación

Al trabajar en un entorno distribuido es necesario considerar cómo funciona la
autorización y el coste de la ejecución de sentencias de SQL.
El ID de autorización adecuado debe tener autorización en un servidor remoto

para conectarse a él y utilizar los recursos de dicho servidor.
Puede utilizar el recurso de límite de recursos en el servidor para controlar las

sentencias de SQL dinámico distribuidas. Mediante este recurso, un servidor puede
controlar cuántos de sus recursos puede consumir un paquete determinado
utilizando acceso DRDA.
Efectos de los datos distribuidos en la programación

Esta información explica algunas consideraciones sobre programación para la
utilización del acceso DRDA.
Tenga en cuenta las consideraciones siguientes al escribir programas que se utilizan

en un entorno distribuido:
v Procedimientos almacenados
Si utiliza acceso DRDA, el programa puede llamar a procedimientos
almacenados. Los procedimientos almacenados se comportan como subrutinas
que pueden contener sentencias de SQL y otras operaciones.
v Nombres de tres partes y varios servidores

| Suponga que una sentencia se ejecuta en un servidor remoto (servidor 1). Esta
| sentencia utiliza un nombre de tres partes o un alias que se resuelve en un
| nombre de tres partes. La sentencia incluye un nombre de ubicación de un
| servidor diferente (servidor 2). Para asegurarse de que el acceso al segundo
| servidor remoto es mediante acceso DRDA, vincule el paquete que contiene el
| nombre de tres partes del segundo servidor.
v Diferencias de SQL en servidores que no son DB2 for z/OS
Mediante conexiones explícitas, un programa que utiliza acceso DRDA puede
utilizar sentencias de SQL que estén soportadas por un servidor remoto, aunque
no estén soportadas por el servidor local. Un programa que utiliza nombres de
objetos de tres partes no puede ejecutar SQL que no sea z/OS.
Efectos de los datos distribuidos en la preparación de

programas
En un entorno distribuido, existen consideraciones especiales que afectan a las
opciones de precompilación y vinculación que se utilizan para acceso DRDA y
resolución de paquetes.
La tabla siguiente lista las opciones de precompilador de z/OS pertinentes para

preparar un paquete que debe ejecutarse utilizando acceso DRDA.
Tabla 39. Opciones de precompilador de z/OS para acceso DRDA
Opciones de precompilador de z/OS Utilización
CONNECT Utilice CONNECT(2) para permitir que el programa
de aplicación realice actualizaciones en más de un
DBMS.
SQL Utilice SQL(ALL) para vincular un paquete a un
servidor no z/OS; de lo contrario, utilice SQL(DB2).
Mayoritariamente, la vinculación de un paquete para que se ejecute en una

ubicación remota es similar a la vinculación de un paquete para que se ejecute en
el subsistema DB2 local. La vinculación de un plan para ejecutar el paquete es
similar a la vinculación de cualquier otro plan. La tabla siguiente le proporciona
directrices para saber qué opciones de vinculación de z/OS debe elegir al vincular
un paquete y planificar la ejecución utilizando acceso DRDA.
| Tabla 40. Opciones de vinculación de z/OS para acceso DRDA
| Opciones de vinculación de z/OS Utilización
| DEFER(PREPARE) Para SQL dinámico, utilice DEFER(PREPARE) para
| enviar sentencias PREPARE y EXECUTE juntas a
| través de la red para mejorar el rendimiento.
| SQLERROR Utilice SQLERROR(CONTINUE) para crear un
| paquete aunque el proceso de vinculación encuentre
| errores de SQL.
| SQLRULES Utilice SQLRULES(DB2) para una mayor flexibilidad
| al codificar las aplicaciones, en especial para datos
| LOB, y mejorar el rendimiento.
|
JDBC, SQLJ y ODBC utilizan métodos diferentes para vincular paquetes que
implican menos preparación para acceder a un servidor de z/OS.

El registro especial CURRENT PACKAGE PATH proporciona ventajas a las
aplicaciones que utilizan DRDA desde un peticionario de z/OS. El ID de colección
de paquetes se resuelve en el servidor. Las aplicaciones del servidor pueden
beneficiarse de la lista de colecciones y el tráfico de la red es mínimo.
Ejemplo: Suponga que existen cinco paquetes y que desea invocar el primer
paquete en el servidor. Los nombres de paquete son SCHEMA1.PKG1,
SCHEMA2.PKG2, SCHEMA3.PKG3, SCHEMA4.PKG4 y SCHEMA5.PKG5. En
lugar de emitir una sentencia SET CURRENT PACKAGESET para invocar cada
paquete, puede utilizar una única sentencia SET si el servidor da soporte al
registro especial CURRENT PACKAGE PATH:
SET CURRENT PACKAGE PATH = SCHEMA1, SCHEMA2, SCHEMA3, SCHEMA4, SCHEMA5;
“Proceso de preparación para un programa de aplicación” en la página 150
Cómo se coordinan las actualizaciones entre sistemas distribuidos

Existe una variedad de productos para trabajar con DB2 para coordinar las
actualizaciones en una transacción distribuida. DB2 coordina las actualizaciones en
servidores que permiten diferentes tipos de conexiones.
Servers)
Soporte de gestor de transacciones de DB2

DB2 da soporte a una amplia gama de productos de gestor de transacciones para
coordinar actualizaciones entre una transacción distribuida. Una transacción
distribuida normalmente implica varios recursos recuperables como, por ejemplo,
tablas de DB2, mensajes de MQSeries y bases de datos de IMS.
Los entornos de aplicaciones que utilizan DB2 Connect para acceder de forma
remota a DB2 pueden utilizar los siguientes productos de gestor de transacciones:
v WebSphere Application Server
v CICS
v IBM TXSeries (CICS y Encina)
v WebSphere MQ
v Microsoft Transaction Server (MTS)
v Aplicaciones Java que dan soporte a Java Transaction API (JTA) y Enterprise
JavaBeans (EJB)
v BEA (Tuxedo y WebLogic)
v Otros productos de gestor de transacciones que dan soporte a protocolos XA
estándar
La interfaz XA es una interfaz bidireccional entre un gestor de transacciones y
gestores que recursos que proporciona actualizaciones coordinadas a través de
una transacción distribuida. The Open Group ha definido protocolos XA
basándose en la especificación Distributed TP: The XA Specification.
Entornos de aplicaciones que acceden localmente a DB2 pueden utilizar los

siguientes productos de gestor de transacciones:
v WebSphere Application Server
v CICS transaction server
v IMS

En entornos de aplicaciones que no utilizan ningún gestor de transacciones, DB2
coordina las actualizaciones a través de una transacción distribuida utilizando
conexiones protegidas mediante DRDA.
Servers)
Servidores que dan soporte a confirmación en dos fases

Las actualizaciones en una situación de confirmación en dos fases se coordinan si
todas deben confirmarse o retrotraerse en la misma unidad de trabajo.
Ejemplo: Puede actualizar una base de datos de IMS y una tabla de DB2 dentro de
la misma unidad de trabajo. Suponga que se produce una anomalía en algún
sistema o comunicación mientras se confirma el trabajo en IMS y en DB2. En este
caso, los dos programas restauran los dos sistemas en un punto coherente cuando
se reanuda la actividad.
DB2 coordina las confirmaciones incluso cuando una conexión utiliza confirmación
en una fase en una transacción distribuida. Sin embargo, en este caso sólo una
ubicación puede realizar una actualización.
“Actualizaciones coordinadas para mantener la coherencia entre servidores” en
la página 292
Servers)
Servidores que no dan soporte a confirmación en dos fases

En una transacción distribuida, DB2 puede coordinar una combinación de
conexiones de una fase y de dos fases. No se pueden realizar actualizaciones
coordinadas con un DBMS que no implementa confirmación en dos fases. Sin
embargo, puede conseguir el efecto de actualizaciones coordinadas al acceder a un
servidor que no implementa confirmación en dos fases; este servidor recibe el
nombre de sistema restringido.
DB2 le impide actualizar un sistema restringido y cualquier otro sistema en la

misma unidad de trabajo. En este contexto, la actualización incluye las sentencias
INSERT, DELETE, UPDATE, CREATE, ALTER, DROP, GRANT, REVOKE y
RENAME.
Puede conseguir el efecto de actualizaciones coordinadas con un sistema

restringido. Primero debe actualizar un sistema y confirmar dicho trabajo y, a
continuación, debe actualizar el segundo sistema y confirmar su trabajo. Sin
embargo, suponga que se produce una anomalía después de confirmar la primera
actualización y antes de confirmar la segunda actualización. No hay disponible
ninguna medida automática para devolver los dos sistemas a un punto coherente.
el programa debe manejar la tarea.
Cuando accede a una mezcla de sistemas, algunos de los cuales pueden ser
restringidos, puede realizar las acciones siguientes para asegurar la integridad de
los datos:
v Leer desde cualquiera de los sistemas en cualquier momento.
v Actualizar cualquiera de los sistemas muchas veces en una unidad de trabajo.

v Actualizar muchos sistemas, incluyendo CICS o IMS, en una unidad de trabajo
si ningún sistema es un sistema restringido. Si el primer sistema que actualiza
no es un sistema restringido, cualquier intento de actualizar un sistema
restringido dentro de una unidad de trabajo tiene como resultado un error.
v Actualizar un sistema restringido en una unidad de trabajo; sin embargo, sólo
puede hacerlo si no intenta actualizar ningún otro sistema en la misma unidad
de trabajo. Si el primer sistema que actualiza es un sistema restringido, cualquier
intento de actualizar otro sistema dentro de dicha unidad de trabajo tiene como
resultado un error.
Servers)
Modos de reducir el tráfico de la red

La clave para mejorar el rendimiento en un entorno informático de red es
minimizar el tráfico de la red.
Los procedimientos almacenados son un método excelente para enviar muchas

sentencias de SQL en un único mensaje de red y, como resultado de ello, ejecutar
muchas sentencias de SQL en el servidor DB2. Este tema presenta otros modos de
mejorar el rendimiento cuando se accede a servidores remotos.
″Ajuste de aplicaciones distribuidas″ (DB2 Performance Monitoring and Tuning
Guide)
Mejoras en la eficacia de las consultas

Una consulta que se envía a un servidor remoto casi siempre tarda más en
ejecutarse que la misma consulta que accede a tablas del mismo tamaño en un
servidor local. Para aumentar la eficacia al acceder a servidores remotos, intente
escribir consultas que envíen pocos mensajes a través de la red.
Por ejemplo:
v Reduzca el número de columnas y filas de la tabla de resultados que se
devuelve a la aplicación. Mantenga las listas de SELECT lo más cortas posibles.
Una utilización creativa de las cláusulas WHERE, GROUP BY y HAVING puede
eliminar datos no deseados en el servidor remoto.
v >Utilice FOR READ ONLY. Por ejemplo, recuperar miles de filas como una serie
continua es razonable. Enviar un mensaje separado para cada una puede ser
considerablemente más lento.
| v Si es posible, no vincule planes de aplicación y paquetes con ISOLATION(RR). Si
| la aplicación no necesita volver a consultar las filas que lee una vez, otro nivel
| de aislamiento podría reducir la contención de bloqueos y la sobrecarga de
| mensajes durante el proceso de COMMIT.
v Minimice la utilización de marcadores de parámetros.
| Cuando el programa utiliza acceso DRDA, DB2 puede agilizar el proceso de
| consultas dinámicas que no contienen marcadores de parámetros. Sin embargo,
| se necesitan marcadores de parámetros para poner en antememoria sentencias
| dinámicas de forma eficaz.
Cuando un peticionario de DB2 encuentra una sentencia PREPARE para una
consulta de este tipo, considera con anticipación que la aplicación abrirá un
cursor. Por lo tanto, el peticionario envía al servidor un único mensaje que
contiene una petición combinada de PREPARE, DESCRIBE y OPEN. Un servidor

de DB2 que recibe esta secuencia de mensajes devuelve una única secuencia de
mensajes de contestación que incluye la salida de las operaciones PREPARE,
DESCRIBE y OPEN. Como resultado, el número de mensajes de la red que se
envían y reciben para estas operaciones se reduce de dos a uno.
Guide)
Reducción del volumen de mensajes

Las posibilidades de DB2 que combinan varias filas de datos durante las
operaciones de captación e inserción pueden reducir significativamente el número
de mensajes que se envían por la red. Estas posibilidades incluyen la captación en
bloque y captaciones e inserciones de conjuntos de filas.
Guide)
Captación en bloque
DB2 utiliza captación en bloque para agrupar las filas que una consulta de SQL
recupera en un “bloque” de filas tan grande como quepa en un almacenamiento
intermedio de mensajes y, a continuación, transmite el bloque a través de la red. Al
enviar varias filas en un bloque, DB2 evita el envío de un mensaje para cada fila.
Una captación en bloque sólo se utiliza con cursores que no actualizan datos. El
tamaño de un bloque de consulta DRDA en z/OS está limitado a 32 KB.
DB2 puede utilizar dos tipos diferentes de captación en bloque:

Captación en bloque limitada
Operación que optimiza la transferencia de datos al garantizar la
transferencia de una cantidad mínima de datos en respuesta a cada
petición desde el sistema peticionario.
Captación en bloque continua
Operación que envía una única petición desde el peticionario al servidor.
El servidor llena un almacenamiento intermedio con datos que recupera y
los vuelve a transmitir al peticionario. El proceso en el peticionario es
asíncrono con el servidor; el servidor sigue enviando bloques de datos al
peticionario con las mínimas solicitudes o ninguna más.
Para utiliza una captación en bloque, DB2 debe determinar que el cursor no se
utiliza para actualizar ni suprimir. Puede indicar esto en el programa añadiendo la
cláusula FOR READ ONLY a la consulta. Si no especifica FOR READ ONLY, la
utilización de captación en bloque por parte de DB2 depende de cómo se define el
cursor.
Para cursores con desplazamiento bidireccional, la sensibilidad del cursor y la

opción de vinculación influyen en si se puede utilizar captación en bloque.
Guide)
Captaciones e inserciones de conjuntos de filas

Para cursores de ubicación de conjunto de filas, cuando se abre el cursor para
procesar un conjunto de filas, el conjunto de respuesta se devuelve en un único

bloque de consulta. El bloque de consulta contiene exactamente el número de filas
que se especifica para el conjunto de filas.
Debido a que un conjunto de filas se devuelve en un único bloque de consulta, el

tamaño de un conjunto de filas tiene un límite de 10 MB. Este tamaño del conjunto
de filas minimiza el impacto en la red cuando se recupera un conjunto de filas
grande con una única operación de captación.
Los cursores de ubicación de conjunto de filas también permiten inserciones de

varias filas. La sentencia INSERT, además de la cláusula FOR n ROWS, inserta
varias filas en una tabla o vista, utilizando los valores proporcionados en matrices
de variables de lenguaje principal. Con inserciones de varias filas, en lugar de
enviar sentencias INSERT para cada inserción individual, se envían todos los datos
de la inserción en un único mensaje de la red.
“Recuperación de filas con un cursor” en la página 158
Guide)
Optimización para conjuntos de resultados grandes y

pequeños
Existen varias opciones de la sentencia SELECT que le permiten limitar el número
de filas que se devuelven a un programa cliente.
El hecho de permitir que un cliente de DB2 solicite varios bloques de consulta en

cada transmisión puede reducir la actividad en la red y mejorar significativamente
el rendimiento para aplicaciones que utilizan acceso DRDA para descargar grandes
cantidades de datos.
Puede especificar un valor grande n en la cláusula OPTIMIZE FOR n ROWS de

una sentencia SELECT para aumentar el número de bloques de consulta DRDA
que un servidor de DB2 devuelve en cada transmisión de red para un cursor de
solo avance.
Si n es mayor que el número de filas que caben en un único bloque de consultas

DRDA, la cláusula OPTIMIZE FOR n ROWS permite que el cliente de DRDA
solicite varios bloques de datos de consulta en cada transmisión de red en lugar de
solicitar otro bloque cuando el primer bloque se llena. Esta utilización de esta
cláusula OPTIMIZE FOR n está destinada a aplicaciones que abren un cursor y
descargan grandes cantidades de datos. La cláusula OPTIMIZE FOR n ROWS no
tiene efecto en cursores con desplazamiento bidireccional.
Cuando un cliente no necesita todas las filas de un conjunto de resultados

potencialmente grande, el hecho de evitar que el servidor de DB2 devuelva todas
las filas para una consulta puede reducir la actividad en la red y mejorar
significativamente el rendimiento para aplicaciones DRDA. Puede utilizar tanto la
cláusula OPTIMIZE FOR n ROWS como la cláusula FETCH FIRST n ROWS ONLY
de una sentencia SELECT para limitar el número de filas que se devuelven al
programa de un cliente.
Guide)

Mejoras del rendimiento para SQL dinámico
Existen dos técnicas para ayudarle a mejorar el rendimiento de aplicaciones de
SQL dinámico.
Puede mejorar el rendimiento de aplicaciones de SQL dinámico en un entorno

distribuido de las formas siguientes:
v Especifique la opción DEFER(PREPARE).
DB2 no prepara una sentencia de SQL dinámico hasta que se ejecuta la
sentencia. Para SQL dinámico utilizado en acceso DRDA, considere especificar la
opción DEFER(PREPARE) cuando vincule o vuelva a vincular los planes o
paquetes. Cuando una sentencia de SQL dinámico accede a datos remotos, las
sentencias PREPARE y EXECUTE se pueden transmitir juntas a través de la red
y procesarse en el servidor remoto. A continuación, el servidor remoto puede
enviar juntas las respuestas de ambas sentencias al subsistema local, reduciendo
de este modo el tráfico de la red.
v Elimine la opción WITH HOLD.
Para definir un cursor WITH HOLD es necesario enviar un mensaje de red
adicional para cerrar el cursor. Puede mejorar el rendimiento eliminando la
opción WITH HOLD cuando la aplicación no necesite mantener los cursores
abiertos durante una confirmación. Esta recomendación es especialmente
aplicable en el caso de aplicaciones de SQL dinámico.
Guide)

Capítulo 12. Compartimiento de datos con los datos de DB2
La función de compartimiento de datos de DB2 for z/OS permite que las
aplicaciones que se ejecutan en más de un subsistema DB2 for z/OS puedan leer
desde y escribir en el mismo conjunto de datos simultáneamente.
Los subsistemas DB2 que comparten datos deben pertenecer a un grupo de

compartimiento de datos de DB2, que se ejecuta en un clúster Sysplex paralelo
zSeries. Un grupo de compartimiento de datos es una colección de uno o más
subsistemas DB2 que accede a datos de DB2 compartidos.
Un Sysplex paralelo es un clúster de sistemas z/OS que se comunican entre sí y

trabajan conjuntamente. Sysplex paralelo es una arquitectura de clúster muy
sofisticada. Está formada por dos tecnologías:
Recurso de acoplamiento
Proporciona hardware especializado, enlaces y adaptadores de alta
velocidad especializados, y un almacenamiento electrónico no volátil
compartido para protocolos de compartimiento rápido de datos entre
sistemas.
Temporizador Sysplex
Proporciona un origen de tiempo común para todos los sistemas del
clúster, lo cual permite un modo eficaz de proporcionar una secuencia de
registro y un orden de sucesos entre los distintos sistemas.
El recurso de acoplamiento y el Temporizador Sysplex son exclusivos del entorno

System z. Proporcionan un rendimiento y una escalabilidad eficaces en un entorno
DBMS en clúster de varios sistemas con discos compartidos.
Cada subsistema DB2 que pertenece a un grupo de compartimiento de datos

determinado es un miembro de dicho grupo. Todos los miembros de un grupo de
compartimiento de datos utilizan el mismo catálogo de DB2 compartido.
También puede utilizar algunas de las posibilidades que se describen en esta

información independientemente de si comparte datos o no. El término entorno de
compartimiento de datos hace referencia a una situación en la que se define un grupo
de compartimiento de datos que tiene un miembro como mínimo. En un entorno
de no compartimiento de datos, no se define ningún grupo.
“Disponibilidad y escalabilidad para empresas grandes” en la página 1
Ventajas del compartimiento de datos de DB2

El compartimiento de datos de DB2 mejora la disponibilidad de DB2, permite un
crecimiento escalable y proporciona unos métodos más flexibles para configurar el
entorno. No es necesario cambiar el SQL en las aplicaciones para utilizar
compartimiento de datos, aunque es posible que sea necesario realizar algunos
ajustes para obtener un rendimiento óptimo.
″Ventajas del compartimiento de datos de DB2″ (DB2 Data sharing: Planning
and Administration)

Disponibilidad mejorada de los datos
Cada vez más usuarios de DB2 solicitan acceder a datos de DB2 cada hora del día,
cada día del año. El compartimiento de datos de DB2 le ayuda a cumplir el
objetivo de servicio mejorando la disponibilidad durante las interrupciones
planificadas y no planificadas.
Como ilustra la figura siguiente, si un subsistema falla, los usuarios pueden

acceder a sus datos de DB2 desde otro subsistema. Se informa a los gestores de
transacciones de que existe una anomalía en DB2 y que pueden conmutar nuevo
trabajo de usuario a otro subsistema DB2 del grupo. Para interrupciones no
planificadas, el gestor de reinicio automático de z/OS puede automatizar el
reinicio y la recuperación.
Figura 53. Cómo el compartimiento de datos mejora la disponibilidad durante las

interrupciones. Si un subsistema DB2 o todo el complejo central de procesadores (CPC)
falla, el trabajo de puede direccionar a otro sistema.
A pesar de que el aumento de la disponibilidad de DB2 tiene algún coste de

rendimiento, la sobrecarga para la comunicación interprocesador y la puesta en
antememoria de los datos cambiados se minimiza. DB2 proporciona mecanismos
de bloqueo y de puesta en antememoria eficaces y utiliza hardware de recurso de
acoplamiento. Un recurso de acoplamiento es una partición lógica especial que ejecuta
el programa de control del recurso de acoplamiento. Proporciona antememoria de
alta velocidad, proceso de listas y funciones de bloqueo en un Sysplex. Las
estructuras de DB2 del recurso de acoplamiento se benefician de la alta
disponibilidad. El recurso de acoplamiento utiliza reconstrucción de estructuras
automática y duplicación de las estructuras que se utilizan para poner en
antememoria datos.
and Administration)
Crecimiento escalable
A medida que aumenta el proceso de datos en un entorno DB2, las necesidades de
proceso pueden superar la capacidad de un único sistema. El compartimiento de
datos puede solucionar esta restricción.

Sin compartimiento de datos
Sin compartimiento de datos de DB2, dispone de las opciones siguientes:

v Copiar los datos, dividir los datos en varios subsistemas DB2.
Para esta opción es necesario mantener copias separadas de los datos. No se
produce ninguna comunicación entre subsistemas DB2 y el catálogo de DB2 no
se comparte.
v Instalar otro subsistema DB2 y volver a escribir aplicaciones para acceder a los
datos originales como datos distribuidos.
Esta opción puede disminuir la carga de trabajo en el subsistema DB2 origina,
pero requiere cambios en las aplicaciones y tiene una sobrecarga de rendimiento
propia. Sin embargo, para subsistemas DB2 que están separados por una gran
distancia o para un subsistema DB2 que necesita compartir datos con un sistema
que está fuera del grupo de compartimiento de datos, el recurso de de datos
distribuidos sigue siendo la única opción.
v Instalar un procesador más grande y mover datos y aplicaciones a esa máquina.
Esta opción puede resultar cara. Además, esta opción requiere que se apague el
sistema mientras se mueve a la máquina más grande nueva.
Con compartimiento de datos
Con compartimiento de datos de DB2 puede aprovechar las ventajas siguientes:

Crecimiento incremental
El clúster de Sysplex paralelo puede crecer incrementalmente. Puede
añadir un nuevo subsistema DB2 a otro complejo central de procesadores y
acceder a los mismos datos a través del nuevo subsistema DB2. No es
necesario gestionar copias ni distribuir datos. Todos los subsistemas DB2
del grupo de compartimiento de datos tienen acceso de lectura-escritura
simultáneo y todos los subsistemas DB2 utilizan un único catálogo de DB2.
Equilibrio de carga de trabajo
El compartimiento de datos de DB2 proporciona flexibilidad para
equilibrio de carga de trabajo y crecimiento. Con la utilización de datos
particionados para paralelismo (a veces denominado arquitectura sin
ningún compartimiento), existe una relación de uno con uno entre un DBMS
determinado y un segmento de datos. Por el contrario, no es necesario
volver a distribuir los datos de un entorno de compartimiento de datos de
DB2 cuando se añade un nuevo subsistema o cuando la carga de trabajo se
desequilibra. El nuevo miembro de DB2 tiene el mismo acceso directo a los
datos que los otros miembros que existen en el grupo de compartimiento
de datos.
DB2 funciona conjuntamente con z/OS Workload Manager (WLM) para
asegurar que el trabajo entrante esté óptimamente equilibrado entre los
sistemas del clúster. WLM gestiona las cargas de trabajo que comparten
recursos del sistema y tienen prioridades y características de utilización de
recursos diferentes.
Ejemplo: Suponga que se ejecutan consultas grandes con una prioridad

baja en el mismo sistema que se ejecutan transacciones en línea con una
prioridad más alta. WLM puede asegurar que las consultas no
monopolicen los recursos y no impidan que las transacciones en línea
consigan obtener unos tiempos de respuesta aceptables. WLM funciona
tanto en un entorno de un solo sistema como en un entorno de varios
sistemas (compartimiento de datos).
Capítulo 12. Compartimiento de datos con los datos de DB2 323

Capacidad cuando es necesaria
Una configuración de compartimiento de datos puede manejar cargas en
periodos de máxima actividad. Puede iniciar miembros de compartimiento
de datos para que manejen cargas en periodos de máxima actividad, por
ejemplo, el proceso durante el final de trimestre y, a continuación,
detenerlos cuando termine el periodo de gran actividad.
Puede beneficiarse de todas estas ventajas, tanto si las cargas de trabajo son para
proceso de transacciones en línea (OLTP) o para una mezcla de OLTP, proceso por
lotes y consultas.
Velocidades más altas de transacciones
El compartimiento de datos le proporciona posibilidades para enviar más trabajo a

través del sistema. Como ilustra la figura siguiente, puede ejecutar la misma
aplicación en más de un subsistema DB2 para conseguir velocidades de
transacciones más altas de lo que es posible en un único subsistema.
Figura 54. Cómo permite el crecimiento el compartimiento de datos. Puede mover parte de la carga de trabajo de
DB2 existente a otro complejo central de procesadores (CPC).
Más capacidad para procesar consultas complejas
El paralelismo de consulta Sysplex permite que DB2 utilice la capacidad de proceso

del grupo de almacenamiento de datos para procesar una única consulta. Para
usuarios que se ocupan de análisis de datos complejos o del soporte de decisiones,
el paralelismo de consulta Sysplex es una solución escalable. Debido a que el
grupo de compartimiento de datos puede crecer, puede proporcionar más
capacidad a estas consultas aunque aumente su complejidad y se ejecuten en
conjuntos de datos cada vez más grandes.

La figura siguiente muestra que todos los miembros de un grupo de
compartimiento de datos pueden participar en el proceso de una única consulta.
En este ejemplo, la tabla ACCOUNT tiene diez particiones. Un miembro procesa
las particiones 1 y 2; otro miembro procesa las particiones 3, 4 y 5; un tercer
miembro procesa las particiones 6 y 7; y el cuarto miembro procesa las particiones
8, 9 y 10.
Figura 55. Consulta procesada en paralelo por los miembros de un grupo de compartimiento de datos. Diferentes
miembros de DB2 procesan diferentes particiones de los datos.
Es una simplificación del concepto—varios subsistemas DB2 pueden acceder a la

misma partición física. Para sacar el máximo partido del paralelismo, utilice
espacios de tablas particionados.
and Administration)
Configuraciones flexibles
El compartimiento de datos de DB2 le permite configurar el entorno del sistema
con mucha más flexibilidad.
Como muestra la figura siguiente, puede tener más de un grupo de

compartimiento de datos de DB2 en el mismo Sysplex z/OS. Por ejemplo, quizás
desea un grupo para la prueba y otro para los datos de producción.

Figura 56. Posible configuración de grupos de compartimiento de datos de DB2. Aunque este ejemplo muestra un
DB2 para cada sistema z/OS, el entorno puede tener más.
También puede ejecutar varios miembros en la misma imagen de z/OS (no se

muestra en esta figura).
Sistemas de operación flexibles
La figura siguiente muestra como, con compartimiento de datos, puede tener

grupos de usuarios de consultas y grupos de usuarios de transacciones en línea en
diferentes imágenes de z/OS. Esta configuración le permite adaptar cada sistema
específicamente para el conjunto de usuarios, controlar la contención de
almacenamiento y proporcionar niveles predecibles de servicio para el conjunto de
usuarios. Previamente, es posible que haya tenido que gestionar copias de datos
separadas para cumplir las necesidades de los diferentes grupos de usuarios.

Figura 57. Configuraciones flexibles con compartimiento de datos de DB2. El compartimiento de datos permite que
cada conjunto de usuarios acceda a los mismos datos, lo que significa que ya no necesita gestionar varias copias.
Sistemas de soporte de decisiones flexibles
La figura siguiente muestra dos configuraciones de soporte de decisiones

diferentes. Una configuración típica separa los datos operativos de los datos de
soporte de decisiones. Utilice esta configuración cuando el sistema operativo tenga
requisitos del entorno diferentes de los del sistema de soporte de decisiones. El
sistema de soporte de decisiones puede estar en un área geográfica diferente o los
requisitos de seguridad pueden ser diferentes para los dos sistemas.
DB2 ofrece otra opción, una configuración de combinación. Una configuración de

combinación combina los sistemas de operación y de soporte de decisiones en un
único grupo de compartimiento de datos y ofrece las ventajas siguientes:
v Puede unir ocasionalmente datos de soporte de decisiones y datos de operación
utilizando SQL.
v Puede volver a configurar el sistema dinámicamente para manejar cargas de
trabajo fluctuantes. Por ejemplo, puede optar por dedicar CPC al proceso de
soporte de decisiones o al proceso de operaciones en distintos momentos del día
o año.
v Puede reducir el coste del proceso:
– La infraestructura que se utiliza para la gestión de datos es la adecuada.
– Puede crear un prototipo de sistema de soporte de decisiones en el sistema
existente y, a continuación, añadir capacidad de proceso a medida que el
sistema crece.

Figura 58. Configuraciones flexibles para soporte de decisiones. El compartimiento de datos de DB2 le permite
configurar los sistemas del modo que mejor funcionan en su entorno.
Para configurar una configuración de combinación, separe tanto como sea posible
los datos del soporte de decisiones de los datos de operación. Las agrupaciones de
agrupación de almacenamientos intermedios, los discos y las unidades de control
que utiliza en el sistema de soporte de decisiones deberían estar separados de los
que utiliza en el sistema de operación. Esta separación minimiza
considerablemente cualquier impacto negativo en el rendimiento del sistema de
operación.
Si no puede mantener este nivel de separación o si ha separado los datos de

operación por otros motivos como, por ejemplo, la seguridad, la utilización de un
sistema de soporte de decisiones separado es la mejor opción.
Flexibilidad para gestionar datos compartidos
El compartimiento de datos puede simplificar la gestión de aplicaciones que deben

compartir algún conjunto de datos como, por ejemplo, una tabla de clientes
común. Puede que estas aplicaciones se hayan dividido en el pasado por motivos
de capacidad o disponibilidad. Pero con la arquitectura de división, los datos
compartidos deben mantenerse sincronizados en los distintos sistemas (es decir,
mediante la réplica de datos).

El compartimiento de datos le proporciona la flexibilidad para configurar estas
aplicaciones en un único grupo de compartimiento de datos de DB2 y mantener
una única copia de los datos compartidos que puede leer y actualizar varios
sistemas con un buen rendimiento. Es una opción especialmente útil cuando las
empresas experimentan fusiones o adquisiciones o cuando se consolidan los
centros de datos.
and Administration)
Inversiones protegidas en personas y habilidades

La inversión en personas y habilidades está protegida puesto que las interfaces de
SQL y conexiones existentes permanecen intactas cuando se comparten datos.
Puede vincular un paquete o plan en un subsistema DB2 y ejecutar dicho paquete

o plan en cualquier otro subsistema DB2 de un grupo de compartimiento.
and Administration)
Cómo DB2 protege la coherencia de los datos en un entorno de

compartimiento de datos
Las aplicaciones pueden acceder a datos desde cualquier subsistema DB2 el grupo
de compartimiento de datos. Potencialmente muchos subsistemas pueden leer y
escribir los mismos datos. DB2 utiliza mecanismos de compartimiento de datos
especiales para bloquear y poner en antememoria a fin de asegurar la coherencia
de los datos.
Cuando varios miembros de un grupo de compartimiento de datos tienen abierto

el mismo espacio de tablas, el mismo espacio de índice o la misma partición y
como mínimo uno de ellos lo ha abierto para escribir, se dice que los datos son de
interés de lectura-escritura interno de DB2 para los miembros. (A veces en esta
información se utiliza el término interés interno de DB2.) Para controlar el acceso a
los datos de interés interno de DB2, cada vez que se cambian los datos, DB2 los
pone en antememoria en un área de almacenamiento denominada agrupación de
almacenamientos intermedios de grupo (GBP).
DB2 detecta dinámicamente el interés interno de DB2, lo que significa que DB2
únicamente puede invocar protocolos de compartimiento de datos entre sistemas
cuando los datos se comparten activamente para lectura-escritura entre miembros.
DB2 puede detectar cuando los datos no se comparten activamente para
lectura-escritura entre sistemas. En estos casos, los protocolos de bloqueo o de
puesta en antememoria del compartimiento de datos no son necesarios, lo que
puede obtener como resultado un mejor rendimiento.
Cuando existe interés de lectura-escritura interno de DB2 en un espacio de tablas,

índice o partición determinados, este interés de lectura-escritura interno de DB2 es
dependiente de la agrupación de almacenamientos intermedios de grupo o
dependiente de la agrupación de almacenamientos intermedios de grupo.
Para definir las agrupaciones de almacenamientos intermedios de grupo utilice

políticas de gestión de recursos del recurso de acoplamiento (CFRM).

La figura siguiente muestra la correlación que existe entre una agrupación de
almacenamientos intermedios de grupo y las agrupaciones de almacenamientos
intermedios de los miembros del grupo. Por ejemplo, cada subsistema DB2 tiene
una agrupación de almacenamientos intermedios denominada BP0. Para el
compartimiento de datos, debe definir una agrupación de almacenamientos
intermedios de grupo (GBP0) en el recurso de acoplamiento que se correlacione
con la agrupación de almacenamientos intermedios BP0. GBP0 se utiliza para
poner en antememoria el espacio de tablas de catálogo de DB2 y su índice, y
cualquier otros espacios de tablas, índices o particiones que utilicen la agrupación
de almacenamientos intermedios BP0.
Figura 59. Relación entre agrupaciones de almacenamientos intermedios y agrupaciones de almacenamientos

intermedios de grupo. Existe una agrupación de almacenamientos intermedios para todas las agrupaciones de
almacenamientos intermedios con el mismo nombre.
La misma agrupación de almacenamientos intermedios de grupo no puede residir

en más de un recurso de acoplamiento (a menos que se haya realizado un dúplex
de la misma).
Cuando se cambia una página de datos determinada, DB2 pone en antememoria

esta página de la agrupación de almacenamientos intermedios. El recurso de
acoplamiento invalida cualquier imagen de la página que pueda existir en las
agrupaciones de almacenamientos intermedios asociadas con cada miembro. A
continuación, cuando otro subsistema DB2 solicita posteriormente los mismos
datos, este subsistema DB2 busca los datos en la agrupación de almacenamientos
intermedios de grupo.
Ventajas en el rendimiento
El recurso de acoplamiento proporciona operaciones de bloqueo global
rápidas para el control de simultaneidad. Sysplex paralelo ofrece las
siguientes ventajas en rendimiento y escalabilidad:
v Las páginas cambiadas se escriben de forma síncrona en el recurso de
acoplamiento, sin la conmutación de proceso asociada con E/S de disco.

v Las señales de invalidación de almacenamiento intermedio se envían y
procesan sin producir ninguna interrupción del procesador, a diferencia
de las técnicas en las que se pasan mensajes.
v Una instrucción de hardware rápida detecta los almacenamientos
intermedios invalidados y el recurso de acoplamiento puede renovar de
forma síncrona los almacenamientos intermedios invalidados sin
sobrecarga por conmutación de proceso, a diferencia de en E/S de disco.
Opciones de rendimiento para adaptarse a las necesidades de la propia
aplicación
Aunque el comportamiento por omisión es poner en antememoria
únicamente los datos actualizados, también dispone de opciones para
poner en antememoria todos los datos o ningún dato. Dispone incluso de
la opción de poner en antememoria datos de objetos grandes (LOB).
″Cómo protege DB2 la coherencia de los datos″ (DB2 Data sharing: Planning
and Administration)
Cómo se realizan actualizaciones en un entorno de compartimiento de

datos
Esta información describe el proceso de puesta al día en un entorno de
compartimiento de datos.
Puede que esté interesado en saber qué sucede en una página de datos cuando
experimenta un proceso de puesta al día. La versión más reciente de la página de
datos aparece sombreada en las ilustraciones. En este caso de ejemplo también se
supone que la agrupación de almacenamientos intermedios de grupo se utiliza
para poner en antememoria únicamente los datos cambiados (el comportamiento
por omisión) y que se duplican para obtener alta disponibilidad. La duplicación es
la capacidad de escribir datos para dos instancias de una estructura de agrupación
de almacenamientos intermedios de grupo: una agrupación primaria de
almacenamientos intermedios de grupo y una agrupación secundaria de almacenamientos
intermedios de grupo.
Suponga, tal como muestra la figura siguiente, que una aplicación emite una
sentencia UPDATE desde DB2A y que los datos no residen en la agrupación de
almacenamientos intermedios del miembro ni en la agrupación de
almacenamientos intermedios de grupo. En este caso, DB2A debe recuperar los
datos del disco y actualizar los datos en su propia agrupación de almacenamientos
intermedios. De forma simultánea, DB2A obtiene los bloqueos apropiados para
impedir que otro miembro actualice los mismos datos al mismo tiempo. Una vez
que la aplicación ha confirmado la actualización, DB2A libera los bloqueos
correspondientes. La página de datos cambiados permanece en la agrupación de
almacenamientos intermedios de DB2A. Debido a que ningún otro subsistema DB2
comparte la tabla en este momento, DB2 no utiliza proceso de compartimiento de
datos para la actualización de DB2A.

Figura 60. Los datos se leen desde disco y una aplicación ejecutada en DB2A los actualiza
A continuación, suponga que otra aplicación, que se ejecuta en DB2B, necesita

actualizar esta misma página de datos. (Vea la figura siguiente.) DB2 sabe que
existe un interés interno de DB2, por lo tanto cuando DB2A confirma la
transacción, DB2 escribe la página de datos cambiados en la agrupación primaria
de almacenamientos intermedios de grupo. La escritura en la agrupación de
almacenamientos intermedios de grupo (secundaria) de copia de seguridad se
solapa con la escritura en la agrupación primaria de almacenamientos intermedios
de grupo. A continuación, DB2B recupera la página de datos de la agrupación
primaria de almacenamientos intermedios de grupo.

Figura 61. Cómo actualiza DB2B la misma página de datos. Cuando DB2B hace referencia a la página, obtiene la
versión más reciente de los datos de la agrupación primaria de almacenamientos intermedios de grupo.
Una vez que la aplicación que se ejecuta en DB2B ha confirmado la actualización,

DB2B mueve una copia de la página de datos a la agrupación de almacenamientos
intermedios de grupo (tanto primaria como secundaria) y la página de datos se
invalida en la agrupación de almacenamientos intermedios de DB2A. (Vea la figura
siguiente.) Se produce una invalidación cruzada desde la agrupación primaria de
almacenamientos intermedios de grupo.

Figura 62. La página actualizada se escribe en la agrupación de almacenamientos intermedios de grupo. La página
de datos se invalida en la agrupación de almacenamientos intermedios de DB2A.
A continuación, como muestra la figura siguiente, cuando DB2A necesita leer los
datos, la página de datos de su propia agrupación de almacenamientos intermedios
no es válida. Por lo tanto, lee la copia más reciente de la agrupación primaria de

Figura 63. DB2A lee los datos desde la agrupación de almacenamientos intermedios de grupo
A diferencia de los sistemas de compartimiento de disco que utilizan técnicas de

E/S de disco y de transferencia de mensajes tradicionales, el recurso de
acoplamiento ofrece las ventajas siguientes:
v Las interacciones de agrupaciones de almacenamientos intermedios de grupo
tienen sincronicidad de CPU. Las interacciones con sincronicidad de CPU
proporcionan un buen rendimiento al evitar la sobrecarga por conmutación de
proceso y al mantener tiempos de respuesta adecuados.
v Las señales de invalidación cruzada no crean interrupciones del procesador en
los sistemas receptores; el hardware las maneja. Las señales evitan una
sobrecarga por conmutación de proceso y las interrupciones de antememoria de
CPU que se pueden producir si se necesitan interrupciones del procesador para
manejar las invalidaciones cruzadas de entrada.
″Cómo se produce una actualización″ (DB2 Data sharing: Planning and
Administration)
Cómo escribe DB2 los datos cambiados en disco en un entorno de

De manera periódica, DB2 debe escribir las páginas cambiadas de una agrupación
de almacenamientos intermedios de grupo en disco. Este proceso se denomina
conversión. El proceso de conversión se ejecuta en segundo plano sin interferir con
transacciones.
Suponga que DB2A es el responsable de convertir los datos cambiados. En primer

lugar estos datos deben pasar por el espacio de direcciones de DB2A porque no
existe ninguna conexión directa entre el recurso de acoplamiento y el disco. (Vea la
figura siguiente.) Estos datos pasan a través de una agrupación de

almacenamientos intermedios privada, no a través de agrupaciones de
almacenamientos intermedios de DB2.
Figura 64. Escritura de los datos en disco
Cuando se duplica una agrupación de almacenamientos intermedios de grupo, los

datos no se convierten desde la agrupación de almacenamientos intermedios de
grupo secundario al disco. Cuando un conjunto de páginas se escribe en disco
desde la agrupación de almacenamientos intermedios de grupo primario, DB2
suprime estas páginas de la agrupación de almacenamientos intermedios de grupo
secundario.
″Cómo escribe DB2 los datos cambiados en el disco″ (DB2 Data sharing:
Planning and Administration)
Modos en que el compartimiento de datos afecta a otras tareas

Debido a que el compartimiento de datos no cambia la interfaz de aplicación, los
programadores de aplicaciones y los usuarios finales no tienen tareas nuevas. Sin
embargo, algunas tareas de programación, de operación y administrativas son
exclusivas del entorno de compartimiento de datos.
Las tareas siguientes son exclusivas del entorno de compartimiento de datos:

v Establecimiento de un convenio de denominación para grupos, miembros de
grupos y recursos
v Asignación de nuevos miembros a un grupo de compartimiento de datos
v Fusión de información de catálogo cuando se mueven datos de subsistemas DB2
existentes a un grupo de compartimiento de datos
Debido a que el catálogo de DB2 está compartido, la definición, la autorización y el

control de datos es igual que en entornos que no son de compartimiento de datos.
Un administrador necesita asegurar que cada objeto tiene un nombre exclusivo,
teniendo en cuenta que los datos existentes se pueden fusionar en un grupo. Es
necesario que los datos residan en discos compartidos.

Modos en que el compartimiento de datos afecta a la disponibilidad
Algunas de las ventajas de disponibilidad y consideraciones en un entorno de
compartimiento de datos son la capacidad de mantener la disponibilidad durante
una interrupción, mantener la disponibilidad del recurso de acoplamiento y
duplicar agrupaciones de almacenamientos intermedios de grupo.
Disponibilidad durante una interrupción
Una ventaja de disponibilidad significativa durante una interrupción planificada o

no planificada de un miembro de grupo de DB2 es que los datos de DB2
permanecen disponibles a través de otros miembros del grupo. Algunas situaciones
comunes en las que puede planificarse una interrupción incluyen la aplicación de
mantenimiento de software, la modificación de un parámetro del sistema o la
migración a un release nuevo. Por ejemplo, durante el mantenimiento de software
puede aplicar el mantenimiento a un miembro a la vez, lo cual deja disponibles
otros miembros de DB2 para trabajar.
Disponibilidad del recurso de acoplamiento
Cuando se planifica la configuración de compartimiento de datos para la máxima

disponibilidad, el principal interés debe ser la protección física del recurso de
acoplamiento y las estructuras del recurso de acoplamiento.
Para obtener la máxima disponibilidad debe tener como mínimo dos recursos de
acoplamiento. Uno de ellos debe estar físicamente aislado. El recurso de
acoplamiento aislado debe residir en un CPC que no contenga ningún miembro de
DB2 que esté conectado a estructuras de dicho recurso de acoplamiento. Con dos
recursos de acoplamiento como mínimo se puede evitar un único punto de
anomalía.
Duplicación de agrupaciones de almacenamientos intermedios

de grupo
Con más de un recurso de acoplamiento también se puede considerar la

duplicación de las agrupaciones de almacenamientos intermedios de grupo. Con la
duplicación, una agrupación secundaria de almacenamientos intermedios de grupo
está disponible como reserva en otro recurso de acoplamiento, preparada para
actuar como relevo si la estructura de la agrupación primaria de almacenamientos
intermedios de grupo falla o si se produce una anomalía de conectividad.
La ejecución de parte o todas las agrupaciones de almacenamientos intermedios de

grupo en modalidad de duplicación es un modo de conseguir una disponibilidad
alta para las agrupaciones de almacenamientos intermedios de grupo en varios
tipos de anomalías, que incluyen conexiones perdidas y estructuras dañadas.

Glosario
terminación anómala | desencadenante definido (una operación
Véase terminación anómala de tarea. | de inserción, actualización o supresión en
| la tabla especificada en una definición de
código de razón de terminación anómala
| desencadenante). Compárese con
Código hexadecimal de 4 bytes que
| desencadenante BEFORE y
identifica de modo exclusivo un problema
| desencadenante INSTEAD OF.
de DB2.
agente En DB2, estructura que asocia todos los
finalización anormal de una tarea (terminación
procesos que intervienen en una unidad
anormal)
de trabajo de DB2. Véase también agente
Finalización de una tarea, trabajo o
aliado y agente del sistema.
subsistema debido a una condición de
error que los recursos de recuperación no función de totales
pueden solucionar durante la ejecución. Operación que obtiene su resultado
utilizando valores procedentes de una o
servicios de método de acceso
más filas. Compárese con función escalar.
| Recurso que se utiliza para definir,
| modificar, imprimir y reproducir archivos | alias Nombre alternativo que puede utilizarse
| en secuencia por clave VSAM. | en sentencias de SQL para especificar una
| tabla o vista situada en un subsistema
vía de acceso
| local o remoto de DB2. Un alias se puede
Vía que se utiliza para localizar datos que
| calificar con un calificador de esquema y
se especifican en sentencias de SQL. Una
| por lo tanto los otros usuarios pueden
vía de acceso puede ser indexada o
| hacer referencia al mismo. Compárese con
secuencial.
| sinónimo.
archivo de registro activo
espacio de direcciones aliado
Parte del archivo de registro de DB2
Área de almacenamiento que es externa a
donde se escriben registros de anotaciones
DB2 y que está conectada a DB2. Un
a medida que se generan. El archivo de
espacio de direcciones aliado puede
registro activo contiene siempre los
solicitar servicios de DB2. Véase también
registros de anotaciones más recientes.
espacio de direcciones.
Véase también archivo de registro de
archivar. agente aliado
Agente que representa peticiones de
espacio de direcciones
trabajo que se originan en espacios de
| Rango de páginas de almacenamiento
direcciones aliados. Véase también agente
| virtual que se identifica mediante un
del sistema.
| número (ASID) y una colección de tablas
| de segmento y página que correlaciona las hebra aliada
| páginas virtuales con las páginas reales Hebra que se origina en el subsistema
| de la memoria del sistema. local de DB2 y que puede acceder a los
datos de un subsistema remoto de DB2.
conexión del espacio de direcciones
El resultado de conectar un espacio de cursor asignado
direcciones aliado a DB2. Véase también Cursor que se define para conjuntos de
espacio de direcciones aliado y bloque de resultados de procedimientos
control de tareas. almacenados utilizando la sentencia
ALLOCATE CURSOR de SQL.
identificador del espacio de direcciones (ASID)
Identificador exclusivo asignado por el cursor ambiguo
sistema para un espacio de direcciones. Cursor de base de datos para el que DB2
no puede determinar si se utiliza con
| desencadenante AFTER (posterior)
fines de actualización o sólo de lectura.
| Desencadenante especificado para
| activarse después de un suceso
APAR Véase informe autorizado de análisis de ASCII Esquema de cifrado que se utiliza para
programa. representar series en muchos entornos,
normalmente en sistemas PC y estaciones
APF Véase programa autorizado.
de trabajo. Compárese con EBCDIC y
API Véase interfaz de programación de Unicode.
aplicaciones.
ASID Véase identificador de espacio de
APPL Sentencia de definición de red de VTAM direcciones.
que se utiliza para definir DB2 para
recurso de conexión
VTAM como programa de aplicación que
Interfaz entre DB2 y TSO, IMS, CICS o
utiliza protocolos LU 6.2 de SNA.
espacios de direcciones de proceso por
aplicación lotes. El recurso de conexión permite que
Programa o conjunto de programas que los programas de aplicación accedan a
realiza una tarea; por ejemplo, una DB2.
aplicación de nóminas.
atributo
plan de aplicación Característica de una entidad. Por
Estructura de control que se produce ejemplo, en el diseño de bases de datos, el
durante el proceso de vinculación. DB2 número de teléfono de un empleado es
utiliza el plan de aplicación para procesar un atributo de dicho empleado.
sentencias de SQL que encuentra durante
ID de autorización
la ejecución de sentencias.
| Serie de caracteres que se puede verificar
proceso de aplicación | para la conexión a DB2 y que tiene
Unidad a la que se asignan recursos y | asignado un conjunto de privilegios. Un
bloqueos. Un proceso de aplicación | ID de autorización puede representar un
implica la ejecución de uno o más | individuo o un grupo organizativo.
programas.
informe autorizado de análisis de programa
Interfaz de programación de aplicaciones (API) (APAR)
Interfaz funcional facilitada por el sistema Informe sobre un problema ocasionado
operativo o por medio de un programa por un presunto defecto en un release
bajo licencia que puede pedirse por actual de un programa proporcionado por
separado y que permite a un programa de IBM.
aplicación escrito en un lenguaje de alto
recurso de programa autorizado (APF)
nivel utilizar funciones o datos específicos
| Recurso que permite que una instalación
del programa bajo licencia o del sistema
| identifique programas del sistema o del
operativo.
| usuario que pueden utilizar funciones
peticionario de aplicaciones | sensibles del sistema.
Componente situado en un sistema
vinculación automática
remoto que genera peticiones de datos de
(Más correctamente, revinculación
DRDA en nombre de una aplicación.
automática.) Proceso por el que las
servidor de aplicaciones sentencias de SQL se vinculan
Destino de una petición procedente de automáticamente (sin que el usuario
una aplicación remota. En el entorno DB2, emita un mandato BIND) cuando un
el recurso de datos distribuidos proceso de aplicación comienza la
proporciona la función de servidor de ejecución y el plan o paquete de
aplicaciones y se utiliza para acceder a aplicación vinculado necesario para ese
datos de DB2 desde aplicaciones remotas. proceso no es válido.
archivo de registro de archivar reescritura automática de consultas
Parte del archivo de registro de DB2 que Proceso por el que se examina una
contiene registros de anotaciones que se sentencia de SQL donde se especifican
han copiado del archivo de registro una o más tablas base o tablas de
activo. Véase también archivo de registro consultas materializadas y, si es necesario,
activo. vuelve a escribir la consulta para mejorar
su rendimiento.

índice auxiliar | desencadenante). Compárese con
| Índice de una tabla auxiliar en la que | desencadenante AFTER y desencadenante
| cada entrada de índice hace referencia a | INSTEAD OF.
| un LOB o documento XML.
objeto grande binario (BLOB)
tabla auxiliar | Tipo de datos de serie binaria que
Tabla que contiene columnas situadas | contiene una secuencia de bytes que
fuera de la tabla en la que se han | puede estar entre 0 bytes y 2 GB, menos 1
definido. Las tablas auxiliares pueden | byte. Esta serie no tiene una página de
contener datos LOB o XML. | códigos y juego de caracteres asociados.
| Los BLOB pueden contener, por ejemplo,
restituir
| datos de imagen, audio o vídeo. En
Proceso de deshacer los cambios no
| general, se utilizan valores de BLOB
confirmados que realizó un proceso de
| siempre que una serie binaria puede
aplicación. La restitución a menudo se
| exceder los límites del tipo VARBINARY.
realiza en el caso de un error en un
proceso de aplicación o como resultado serie binaria
de una situación de punto muerto. | Secuencia de bytes que no está asociada a
| un CCSID. El tipo de datos de serie
recuperación inversa del registro
| binaria se puede clasificar además como
Fase final del proceso de reinicio durante
| BINARY, VARBINARY o BLOB.
la cual DB2 examina el archivo de registro
en sentido inverso para aplicar registros vinculación
UNDO para todos los cambios | Proceso por el que se genera una
terminados anormalmente. | estructura de control utilizable con
| sentencias de SQL; la estructura a
tabla base
| menudo se denomina plan de acceso,
Tabla que se crea por medio de la
| plan de aplicación o paquete. Durante
sentencia de CREATE TABLE de SQL y
| este proceso de vinculación, se
que contiene datos persistentes.
| seleccionan las vías de acceso a los datos
Compárese con tabla de réplica, tabla de
| y se realizan algunas comprobaciones de
consultas materializadas, tabla de
| autorización. Véase también vinculación
resultados, tabla temporal y tabla de
| automática.
transición.
datos de bit
espacio de tablas base
Espacio de tablas que contiene tablas | v Datos con tipo de carácter CHAR o
base. | VARCHAR definido con la cláusula
| FOR BIT DATA. Tenga en cuenta que
| formato de fila básico | se recomienda encarecidamente utilizar
| Formato de fila en el que se almacenan | BINARY o VARBINARY en lugar de
| valores para las columnas en la fila en el | FOR BIT DATA.
| orden en el que la sentencia CREATE
| v Datos con tipo de carácter CHAR o
| TABLE define las columnas. Compárese
| VARCHAR definido con la cláusula
| con formato de fila reordenado.
| FOR BIT DATA.
método de acceso secuencial básico - BSAM | v Forma de datos de tipo carácter.
Método de acceso para almacenar o | Normalmente los datos binarios son
recuperar bloques de datos en una | mucho más recomendables que los
secuencia continua, utilizando un | datos carácter-para-bit.
dispositivo de acceso secuencial o de
acceso directo. BLOB Véase objeto grande binario.
| desencadenante BEFORE (anterior) captación en bloque

| Desencadenante especificado para | Capacidad de DB2 para recuperar o
| activarse antes de un suceso | captar un conjunto grande de filas juntas.
| desencadenante definido (una operación | La captación en bloque puede disminuir
| de inserción, actualización o supresión | significativamente el número de mensajes
| especificada en una definición de | que se envían por la red. La captación en
Glosario 359
| bloque sólo es aplicable a cursores que no DSN y proporciona un mayor control
| son de conjunto de filas que no actualizan sobre el entorno de ejecución. Compárese
| los datos. con recurso de conexión de los servicios
del gestor de recursos recuperables.
archivo de arranque (BSDS)
Archivo VSAM que contiene información interfaz de nivel de llamada (CLI)
de nombre y estado para DB2 y Interfaz de programación de aplicaciones
especificaciones de rangos de RBA para (API) invocable, que se utiliza para
todos los archivos de datos activos y de acceder a bases de datos como alternativa
archivado. BSDS también contiene al uso de SQL incorporado.
contraseñas para el directorio y catálogo
supresión en cascada
de DB2 y listas de registros de punto de
Proceso mediante el que DB2 aplica
control y rearranque condicionales.
restricciones de referencia cuando
BSAM suprime todas las filas descendientes de
Véase método de acceso secuencial básico. una fila padre suprimida.
BSDS Véase archivo de arranque. expresión CASE
Expresión que se selecciona de acuerdo
agrupación de almacenamientos intermedios
con la evaluación de una o más
| Área de memoria en la que se leen,
condiciones.
| modifican y mantienen páginas de datos
| durante el proceso. función de conversión
Función que se utiliza para convertir
tipo de datos incorporado
instancias de un tipo de datos (fuente) en
| Tipo de datos proporcionado por IBM.
instancias de un tipo de datos diferente
| Entre los tipos de datos incorporados para
(destino).
| DB2 para z/OS se encuentran los
| siguientes: string, numeric, XML, ROWID conversión
| y datetime. Compárese con tipo Proceso de DB2 por el que las páginas
| diferenciado. cambiadas de una agrupación de
almacenamiento intermedio de grupo se
función incorporada
graban en disco.
| Función generada por DB2 y que está
| contenida en el esquema SYSIBM. propietario de la conversión
| Compárese con función definida por el Miembro de DB2 encargado de convertir
| usuario. Véase también función, función un conjunto de páginas o una partición
| de conversión, función externa, función determinados.
| derivada y función de SQL.
catálogo
dimensión de negocio En DB2, colección de tablas que contiene
Categoría de datos, tales como productos descripciones de objetos tales como tablas,
o períodos de tiempo, que una empresa vistas e índices.
puede desear analizar.
tabla de catálogo
estructura de antememoria Cualquier tabla del catálogo de DB2.
Estructura del recurso de acoplamiento
CCSID
que almacena datos que pueden estar
Véase identificador de juego de caracteres
disponibles para todos los miembros de
codificados.
un Sysplex. Un grupo de compartimiento
de datos de DB2 utiliza estructuras de CDB Véase base de datos de comunicaciones.
antememoria como agrupaciones de
CDRA
almacenamiento intermedio de grupo.
Véase Arquitectura de representación de
CAF Véase recurso de conexión de llamada. datos de tipo carácter.
recurso de conexión de llamada (CAF) CEC Véase complejo central de procesadores.
Recurso de conexión de DB2 para
complejo electrónico central (CEC)
programas de aplicación que se ejecutan
Véase complejo central de procesadores.
en TSO o z/OS por lotes. El CAF es una
alternativa al procesador de mandatos de

complejo central de procesadores (CPC) integridad de comprobación
Colección física de hardware que consta Condición que existe cuando cada fila de
de almacenamiento principal, uno o más una tabla cumple las restricciones de
procesadores centrales, temporizadores y comprobación que se han definido en esa
canales. tabla.
procesador central (CP) pendiente de comprobación
Parte del sistema que contiene los Estado de un espacio de tablas o partición
recursos de ordenación y proceso para la que impide su utilización por parte de
ejecución de instrucciones, la carga inicial algunos programas de utilidad y de
del programa y otras operaciones de algunas sentencias de SQL debido a filas
máquina. que violan restricciones de referencia,
restricciones de comprobación o ambas
CFRM Véase gestión de recursos del recurso de
restricciones.
acoplamiento.
punto de control
política de CFRM
Punto en el que DB2 registra información
Normas de asignación para una
de estado en el archivo de registro de
estructura del recurso de acoplamiento
DB2; el proceso de recuperación utiliza
que son declaradas por un administrador
esta información si DB2 finaliza de forma
de z/OS.
anómala.
conversión de caracteres
bloqueo hijo
Proceso de cambiar caracteres desde un
En un bloqueo jerárquico explícito,
sistema de codificación a otro.
bloqueo que se mantiene sobre una tabla,
Arquitectura de representación de datos de tipo página, fila u objeto grande (LOB). Cada
carácter (CDRA) bloqueo hijo tiene un bloqueo padre.
Arquitectura que se utiliza para Véase también bloqueo padre.
representar de forma coherente, procesar
CI Véase intervalo de control.
e intercambiar datos de tipo carácter.
CICS En el contexto presente, este término
objeto grande de caracteres (CLOB)
corresponde a: CICS Transaction Server
| Tipo de datos de serie de caracteres que
for z/OS: Customer Information Control
| contiene una secuencia de bytes que
System Transaction Server for z/OS.
| representa caracteres (byte único,
| multibyte, o ambos) que puede estar entre recurso de conexión CICS
| 0 bytes y 2 GB de tamaño, menos 1 byte. | Recurso que proporciona una conexión
| En general, los valores de CLOB se | multihebra a DB2 para permitir que las
| utilizan cuando una serie de caracteres | aplicaciones que se ejecutan en el entorno
| puede superar los límites del tipo | CICS ejecuten sentencias de DB2.
| VARCHAR.
reclamación
juego de caracteres Notificación que se hace a DB2 para
Juego definido de caracteres. informarle de que se está accediendo a un
objeto. Las reclamaciones impiden que se
serie de caracteres
produzcan consumos hasta que se libera
| Secuencia de bytes que representan datos
la reclamación, lo cual suele ocurrir en un
| binarios, caracteres de un solo byte o una
punto de confirmación. Compárese con
| mezcla de caracteres de un solo byte y de
consumo.
| varios bytes. Los datos de tipo carácter se
| pueden clasificar además como clase de reclamación
| CHARACTER, VARCHAR o CLOB. Tipo específico de acceso a objeto, que
puede ser uno de los niveles de
restricción de comprobación
aislamiento siguientes:
Restricción definida por el usuario que
especifica los valores que pueden v Estabilidad del cursor (CS)
contener columnas especificas de una v Lectura repetida (RR)
tabla base. v Escritura
Glosario 361
clase de servicio funciones de miembro de los objetos de
Término de VTAM que designa una lista su clase. A las funciones de miembro
de rutas de una red, dispuestas por orden también se las denomina métodos.
de preferencia para su utilización.
objeto C++
cláusula Región de almacenamiento. Objeto que se
En SQL, parte diferenciada de una crea cuando se define una variable o se
sentencia, tal como una cláusula SELECT invoca una nueva función.
o una cláusula WHERE.
Instancia de una clase.
CLI Véase interfaz de nivel de llamada.
juego de caracteres codificados
cliente Conjunto de normas no ambiguas que
Véase peticionario. definen un juego de caracteres y las
relaciones ″de uno a uno″ entre los
CLOB Véase objeto grande de caracteres.
caracteres del conjunto y sus
| objeto de réplica representaciones codificadas.
| Objeto asociado con una tabla de réplica,
identificador de juego de caracteres codificados
| incluida la propia tabla de réplica y las
(CCSID)
| restricciones de comprobación, índices y
Número de 16 bits que identifica
| desencadenantes BEFORE en la tabla de
exclusivamente una representación
| réplica.
codificada de caracteres gráficos. Designa
| tabla de réplica un identificador de esquema de
| Tabla estructuralmente idéntica a una codificación y uno o más pares que
| tabla base. La tabla base y la tabla de constan de un identificador del juego de
| réplica tienen archivos VSAM distintos, caracteres y un identificador de la página
| identificados por sus números de de códigos asociada.
| instancia de archivo. Compárese con tabla
página de códigos
| base.
Conjunto de asignaciones de caracteres a
aplicación cerrada puntos de código. Dentro de una página
Aplicación que requiere la utilización de códigos, cada elemento de código tiene
exclusiva de determinadas sentencias en un solo significado específico. En
ciertos objetos de DB2, por lo que los EBCDIC, por ejemplo, el carácter A tiene
objetos únicamente se gestionan a través asignado el elemento de código X’C1’, y
de la interfaz externa de la aplicación. el carácter B tiene asignado el elemento
de código X’C2’.
índice de clúster
Índice que determina cómo las filas se elemento de código
ordenan físicamente (agrupan en clústeres) En CDRA, patrón de bits exclusivo que
en un espacio de tablas. Si un índice de representa un carácter de una página de
clúster en una tabla particionada no es un códigos.
índice de particionamiento, las filas se
unidad de código
ordenan en la secuencia de clúster en
Ancho binario fundamental en una
cada partición de datos en lugar de
arquitectura de sistemas utilizado para
dividirse entre las particiones.
representar datos de tipo carácter, tales
| CM Véase modalidad de compatibilidad. como 7 bits, 8 bits, 16 bits, o 32 bits. En
función de la forma de codificación de
| CM* Véase modalidad de compatibilidad*.
caracteres que se utiliza, cada punto de
miembro C++ código en un juego de caracteres
Función u objeto de datos contenido en codificado puede estar representado por
una estructura, unión o clase. una o varias unidades de código.
función de miembro C++ coexistencia
Operador o función que se ha declarado Durante la migración, período de tiempo
como miembro de una clase. Una función en el que dos releases existen en el mismo
de miembro tiene acceso a los miembros grupo de compartimiento de datos.
de datos privados y protegidos y a las

arranque en frío área de servicio común (CSA)
Proceso por el que DB2 rearranca sin | En z/OS, parte del área común que
procesar ningún registro del archivo de | contiene áreas de datos que son
registro. Compárese con arranque en | direccionables por todos los espacios de
caliente. | direcciones. La mayor parte del uso de
| DB2 se realiza en el CSA ampliado, que
colección
| está situado sobre la línea de 16 MB.
Grupo de paquetes que tienen el mismo
calificador. base de datos de comunicaciones (CDB)
Conjunto de tablas del catálogo de DB2
columna
que se utilizan para establecer
Componente vertical de una tabla. Una
conversaciones con sistemas de gestión de
columna tiene un nombre y un tipo de
bases de datos remotos.
datos determinado (por ejemplo,
CHARACTER, DECIMAL o INTEGER). operador de comparación
Símbolo (tal como =, > o < ) que se utiliza
función de columna
para especificar una relación entre dos
Véase función de agregación.
valores.
comprobación de la procedencia (″come from″)
| modalidad* de compatibilidad (CM*)
Opción de seguridad de LU 6.2 que
| Etapa del proceso de migración de
define una lista de los ID de autorización
| versión a versión que se aplica a un
que pueden conectarse a DB2 desde una
| grupo de compartimiento de datos o
LU asociada.
| subsistema de DB2 que estaba en
mandato | modalidad de habilitación de nueva
Mandato de operador o submandato de | función (ENFM), modalidad* de
DSN de DB2. Un mandato es diferente de | habilitación de nueva función (ENFM*) o
una sentencia de SQL. | modalidad de nueva función (NFM) en
| un momento dado. No se permite volver
prefijo de mandato
| a una versión anterior. Cuando está en
Identificador de mandatos de 1 a 8
| modalidad* de compatibilidad, un grupo
caracteres. El prefijo de mandato
| de compartimiento de datos de DB2 no
distingue el mandato como perteneciente
| puede coexistir con miembros que aún se
a una aplicación o subsistema en lugar de
| encuentran en el nivel de versión anterior.
pertenecer a z/OS.
| Compárese con modalidad de
carácter de reconocimiento de mandatos (CRC) | compatibilidad, modalidad de habilitación
Carácter que permite que un operador de | de nueva función, modalidad de
consola z/OS o un usuario de un | habilitación de nueva función* y
subsistema de IMS direccione mandatos | modalidad de nueva función.
de DB2 hacia subsistemas de DB2
| modalidad de compatibilidad (CM)
específicos.
| Primera etapa del proceso de migración
ámbito del mandato | de versión a versión. En un grupo de
Ámbito de actuación de un mandato en | compartimiento de datos de DB2, pueden
un grupo de compartimiento de datos. | coexistir miembros en modalidad de
| compatibilidad con miembros que aún se
confirmar
| encuentran en el nivel de versión anterior.
Operación por la que finaliza una unidad
| También se permite volver a la versión
de trabajo mediante la liberación de
| anterior. Cuando está en modalidad de
bloqueos para que los cambios de base de
| compatibilidad, el subsistema de DB2 no
datos hechos por esa unidad de trabajo
| puede utilizar ninguna función nueva de
puedan ser percibidos por otros procesos.
| la nueva versión. Compárese con
Compárese con retrotraer.
| modalidad de compatibilidad*, modalidad
punto de confirmación | de habilitación de nueva función,
Punto en el tiempo en el que los datos se | modalidad de habilitación de nueva
consideran coherentes. | función* y modalidad de nueva función.
Glosario 363
clave compuesta restricción
| Conjunto ordenado de columnas clave o Norma que limita los valores que se
| expresiones de la misma tabla. pueden insertar, eliminar o actualizar en
una tabla. Véase restricción de referencia,
diccionario de compresión
restricción de comprobación y restricción
El diccionario que controla el proceso de
de exclusividad.
compresión y descompresión. Este
diccionario se crea a partir de los datos contexto
del espacio de tablas o de la partición del Conexión lógica de una aplicación con la
espacio de tablas. fuente de datos e información de
conexión ODBC de DB2 asociada que
simultaneidad
permite a la aplicación dirigir sus
Utilización compartida de recursos por
operaciones a una fuente de datos. Un
parte de más de un proceso de aplicación
contexto ODBC de DB2 representa una
al mismo tiempo.
hebra de DB2.
reinicio condicional
conversión con contracción
Reinicio de DB2 que ha sido dirigido por
Proceso que se produce cuando la
un registro de control de reinicio
longitud de una serie de caracteres
condicional definido por el usuario
convertida es menor que la serie original.
(CRCR).
Por ejemplo, este proceso ocurre cuando
conexión una serie mixta de caracteres EBCDIC que
En SNA, existencia de una vía de contiene caracteres DBCS se convierte a
comunicación entre dos LU asociadas que datos ASCII mixtos; la serie convertida es
permite el intercambio de información más corta debido a la supresión de los
(por ejemplo, dos subsistemas de DB2 que códigos de desplazamiento.
están conectados y se comunican
intervalo de control (control interval, CI)
mediante una conversación).
v Unidad de información que VSAM
contexto de conexión transfiere entre almacenamiento virtual
En SQLJ, objeto de Java que representa y auxiliar.
una conexión con una fuente de datos.
v En un archivo en secuencia por clave,
cláusula de declaración de conexión conjunto de registros al que apunta una
En SQLJ, sentencia que declara una entrada en el registro de índice de
conexión con una fuente de datos. conjuntos de secuencia.
descriptor de conexión conversación
Objeto de datos que contiene información Comunicación, basada en LU 6.2 o APPC
asociada con una conexión gestionada por (Advanced Program-to-Program
DB2 ODBC. Incluye información general Communication), entre una aplicación y
de estado, de estado de transacción e un programa de transacciones remoto a
información de diagnóstico. través de una sesión SNA de unidad
lógica a unidad lógica (LU-LU) que
ID de conexión
permite la comunicación mientras se
Identificador que proporciona el recurso
procesa una transacción.
de conexión y que está asociado a una
conexión de espacio de direcciones coordinador
específico. Componente del sistema que coordina la
confirmación o retrotracción de una
símbolo de coherencia
unidad de trabajo que incluye el trabajo
Indicación horaria que se utiliza para
que se realiza en uno o más sistemas
generar el identificador de versión para
diferentes.
una aplicación. Véase también versión.
coprocesador
constante
Véase coprocesador de sentencias de SQL.
Elemento de lenguaje que especifica un
valor no variable. Las constantes pueden agrupación de copia
ser constantes de tipo serie o constantes | Colección de nombres de grupos de
numéricas. Compárese con variable.

| almacenamiento que se procesan externaliza en la columna
| colectivamente para operaciones rápidas COST_CATEGORY de
| de réplica. DSN_STATEMNT_TABLE cuando se
explica una sentencia.
destino de copia
Conjunto con nombre de grupos de recurso de acoplamiento
almacenamiento de SMS que se utilizarán | Partición lógica (LPAR) especial de
como contenedores para las copias de los | PR/SM que ejecuta el programa de
volúmenes de una agrupación de copia. | control del recurso de acoplamiento y
Un destino de copia es una construcción | proporciona puesta en antememoria de
de SMS que permite definir los grupos de | alta velocidad, proceso de listas y
almacenamiento que deben utilizarse | funciones de bloqueo en Parallel Sysplex.
como contenedores para los volúmenes
gestión de recursos del recurso de acoplamiento
que se copian utilizando la función
(CFRM)
FlashCopy.
Componente de z/OS que proporciona
versión de copia los servicios para gestionar recursos del
Copia de FlashCopy de punto en el recurso de acoplamiento en un Parallel
tiempo gestionada por HSM. Cada Sysplex. Esta gestión incluye la aplicación
agrupación de copias tiene un parámetro de políticas de CFRM para asegurar que
de versión que especifica cuántas se cumplan los requisitos del recurso de
versiones de copia se mantienen en el acoplamiento y de estructura.
disco.
CP Véase procesador central.
columnas correlacionadas
CPC Véase complejo central de procesadores.
Relación entre el valor de una columna y
el valor de otra columna. CRC Véase carácter de reconocimiento de
mandatos.
subconsulta correlacionada
Subconsulta (parte de una cláusula tabla temporal creada
WHERE o HAVING) aplicada a una fila o Tabla permanente que contiene datos
grupo de filas de una tabla o vista temporales y se define mediante la
nombrada en una sentencia subselect sentencia CREATE GLOBAL
externa. TEMPORARY TABLE de SQL. En el
catálogo de DB2 se almacena información
ID de correlación
sobre tablas temporales creadas, que
Identificador asociado a una hebra
puede ser compartida por procesos de
específica. En TSO, es un ID de
aplicación. Compárese con tabla temporal
autorización o el nombre de trabajo.
declarada. Véase también tabla temporal.
nombre de correlación
recurso de acoplamiento entre sistemas (XCF)
| Identificador que se especifica y utiliza
Componente de z/OS que proporciona
| dentro de una sentencia individual de
funciones para permitir la cooperación
| SQL como nombre expuesto para objetos
entre programas autorizados que se
| tales como una tabla, una vista, una
ejecutan en un Sysplex.
| referencia de función de tabla, una
| expresión de tabla anidada o el resultado servicios ampliados entre sistemas (XES)
| de una sentencia de cambio de datos. Los Conjunto de servicios de z/OS permiten
| nombres de correlación son útiles en una que varias instancias de una aplicación o
| sentencia de SQL para permitir dos subsistema, que se ejecutan en diferentes
| referencias distintas a la misma tabla base sistemas en un entorno Sysplex, apliquen
| y para permitir que se utilice un nombre un compartimiento de datos de alto
| alternativo para representar un objeto. rendimiento y alta disponibilidad
utilizando un recurso de acoplamiento.
categoría de coste
Categoría en la que DB2 coloca las CS Véase estabilidad del cursor.
estimaciones de coste para sentencias de
CSA Véase área de servicio común.
SQL en el momento en que se vincula la
sentencia. La categoría de coste se CT Véase tabla de cursor.
Glosario 365
datos actuales distinto del nombre de ubicación. El alias
Datos de la estructura de sistema de base de datos se utiliza para
principal que es actual (idéntica) respecto proporcionar el nombre del servidor de
a los datos de la tabla base. bases de datos tal como es conocido en la
red.
reconstrucción del estado actual
Segunda fase del proceso de reinicio descriptor de base de datos (DBD)
durante la cual el estado del subsistema Representación interna de la definición de
se reconstruye a partir de la información una base de datos de DB2, que refleja la
del registro. definición de los datos encontrados en el
catálogo de DB2. Los objetos que se
cursor Estructura de control que un programa de
definen en un descriptor de base de datos
aplicación utiliza para apuntar a una o
son espacios de tabla, tablas, índices,
varias filas dentro de un conjunto
espacios de índices, relaciones,
ordenado de filas de una tabla de
restricciones de comprobación y
resultados. Un cursor puede utilizarse
desencadenantes. Un DBD también
para recuperar, actualizar o suprimir filas
contiene información sobre las tablas de
de una tabla de resultados.
acceso de la base de datos.
sensibilidad del cursor
estado de excepción de la base de datos
Grado en el que las actualizaciones de la
En un entorno de compartimiento de
base de datos pueden ser percibidas por
datos, indicación de que hay algo mal en
las sentencias FETCH subsiguientes en un
una base de datos.
cursor.
identificador de base de datos (DBID)
estabilidad del cursor (CS)
Identificador interno de la base de datos.
Nivel de aislamiento que proporciona el
máximo nivel de simultaneidad sin la sistema de gestión de bases de datos (DBMS)
posibilidad de leer datos no confirmados. Sistema de software que controla la
Con la estabilidad del cursor, una unidad creación, organización y modificación de
de trabajo sólo mantiene bloqueos para una base de datos y el acceso a los datos
los cambios no confirmados y para la fila que están almacenados en ella.
actual de cada uno de sus cursores. Véase
módulo de solicitud de la base de datos
también estabilidad de lectura, lectura
(DBRM)
repetible y lectura no confirmada.
Miembro de archivo creado por el
tabla de cursor (CT) precompilador de DB2 y que contiene
| Representación interna de un cursor. información sobre sentencias de SQL. Los
DBRM se utilizan en el proceso de
ciclo Conjunto de tablas que pueden ordenarse
vinculación.
de modo que cada tabla descienda de la
precedente y la primera descienda de la servidor de bases de datos
última tabla. Una tabla de autorreferencia Destino de una petición procedente de
es un ciclo con un único miembro. Véase una aplicación local o un servidor de
también ciclo referencial. bases de datos intermedio remoto.
base de datos vigencia de los datos
Colección de tablas o colección de Estado en el que los datos recuperados en
espacios de tablas y de espacios de índice. una variable de lenguaje principal de un
programa son una copia de los datos de
hebra de acceso a base de datos (DBAT)
la tabla base.
Hebra que accede a datos del subsistema
local a petición de un sistema remoto. diccionario de datos
Depósito de información sobre los
administrador de la base de datos (DBA)
programas de aplicación, bases de datos,
Persona encargada de diseñar, desarrollar,
modelos lógicos de datos, usuarios y
dirigir, proteger, mantener y utilizar una
autorizaciones existentes en una empresa.
base de datos.
alias de base de datos
Nombre del servidor de destino, si es

partición de datos que contienen descripciones de objetos de
Archivo VSAM que se halla en un espacio DB2, tales como tablas, vistas e índices.
de tablas particionado.
DBCLOB
índice secundario de datos particionados (DPSI) Véase objeto grande de caracteres de
El índice secundario que está particionado doble byte.
según los datos subyacentes. Compárese
mandato de DB2
con índice secundario no particionado.
Instrucción para el subsistema de DB2
| número de instancia de archivo que un usuario debe entrar para iniciar o
| Número que indica el archivo que detener DB2, visualizar información sobre
| contiene los datos para un objeto. usuarios actuales, iniciar o detener bases
de datos, visualizar información sobre el
estado de las bases de datos, etc.
Función de DB2 para z/OS que permite
que aplicaciones situadas en subsistemas DBCS Véase juego de caracteres de doble byte.
DB2 diferentes lean y escriban en los
DBD Véase Descripción de base de datos.
mismos datos concurrentemente.
DB2I Véase DB2 Interactivo.
grupo de compartimiento de datos
Colección de uno o más subsistemas DB2 DBID Véase identificador de base de datos.
que acceden directamente y cambian los
DB2 Interactivo (DB2I)
mismos datos al tiempo que mantienen la
Servicio interactivo de DB2 que facilita la
integridad de los datos.
ejecución de sentencias de SQL, mandatos
miembro de compartimiento de datos de DB2 (operador) y mandatos de
Subsistema de DB2 asignado por los programador, así como la invocación de
servicios de XCF a un grupo de programas de utilidad.
compartimiento de datos.
DBMS
fuente de datos Véase sistema de gestión de bases de
Gestor de datos relacionales o no datos.
relacionales local o remoto que puede dar
DBRM
soporte al acceso de datos por medio de
Véase módulo de petición de base de
un controlador de ODBC que da soporte
datos.
a las API de ODBC. En el caso de DB2
para z/OS, las fuentes de datos son hebra de DB2
siempre gestores de bases de datos | Estructura del gestor de bases de datos
relacionales. | que describe una conexión de aplicación,
| rastrea su progreso, procesa las funciones
tipo de datos
| de recursos y delimita su accesibilidad a
Atributo de columnas, constantes,
| los recursos y servicios del gestor de
variables, parámetros, registros especiales
| bases de datos. La mayoría de las
y los resultados de funciones y
| funciones de DB2 para z/OS se ejecutan
expresiones.
| de acuerdo con una estructura de hebras.
depósito de datos
DCLGEN
Sistema que proporciona información
Véase generador de declaraciones.
comercial crítica a una empresa. El
depósito de datos depura los datos para DDF Véase recurso de datos distribuidos.
que sean exactos y actuales y luego los
punto muerto
presenta al proceso de toma de decisiones
Conflicto irresoluble por la utilización de
para que se puedan interpretar y utilizar
un recurso, tal como una tabla o un
de forma efectiva y eficiente.
índice.
DBA Véase administrador de la base de datos.
generador de declaraciones (DCLGEN)
DBAT Véase hebra de acceso a base de datos. Subcomponente de DB2 que genera
declaraciones de tabla de SQL y
catálogo de DB2
declaraciones de estructura de datos de
Colección de tablas mantenidas por DB2
COBOL, C o PL/I que se adaptan a la
Glosario 367
tabla. Las declaraciones se generan desde supresión incluyen CASCADE,
la información de catálogo de sistema de RESTRICT, SET NULL o NO ACTION.
DB2.
desencadenante de supresión
tabla temporal declarada tablas temporales Desencadenante que se define con la
declaradas operación de SQL de desencadenante de
Tabla no permanente que contiene datos supresión.
temporales y se define mediante la
identificador delimitado
sentencia DECLARE GLOBAL
| Secuencia de caracteres que están
TEMPORARY TABLE de SQL. La
| encerrados entre caracteres de escape.
información sobre tablas temporales
declaradas no se almacena en el catálogo símbolo delimitador
de DB2 y sólo puede ser utilizada por el Constante de tipo carácter, identificador
proceso de aplicación que emitió la delimitado, símbolo de operador o
sentencia DECLARE. Compárese con tabla cualquiera de los caracteres especiales que
temporal creada. Véase también tabla aparecen en los diagramas de sintaxis de
temporal. DB2.
valor por omisión denormalización
| Valor, atributo u opción predeterminados Duplicación intencionada de columnas en
| que se presupone cuando no se especifica varias tablas para aumentar la
| explícitamente ningún otro. Se puede redundancia de datos. La
| definir un valor por omisión para datos denormalización es a veces necesaria para
| de columna contenidos en tablas de DB2 minimizar los problemas de rendimiento.
| especificando la palabra clave DEFAULT Compárese con normalización.
| en una sentencia de SQL que cambie
dependiente
| datos (tal como INSERT, UPDATE y
Objeto (fila, tabla o espacio de tablas) que
| MERGE).
tiene como mínimo un padre. También se
SQL incorporado diferido dice que el objeto (fila, tabla o espacio de
Sentencias de SQL que no son tablas) es dependiente de su padre. Véase
completamente estáticas ni también fila padre, tabla padre y espacio
completamente dinámicas. Estas de tablas padre.
sentencias están incluidas dentro de una
fila dependiente
aplicación y se preparan durante la
Fila que contiene una clave externa que
ejecución de la aplicación.
coincide con el valor de una clave
escritura diferida primaria en la fila padre.
Proceso de escribir de forma asíncrona
tabla dependiente
páginas de datos modificadas en el disco
Tabla que es dependiente como mínimo
duro.
en una restricción de referencia.
grado de paralelismo
descendiente
Número de operaciones ejecutadas de
Objeto que es dependiente de un objeto o
modo simultáneo que se inician para
de un descendiente de un objeto.
procesar una consulta.
fila descendente
hueco por supresión
Fila que es dependiente de otra fila o fila
Ubicación en la que se encuentra un
que desciende de una fila dependiente.
cursor cuando se vuelve a leer una fila en
una tabla de resultados y la fila ya no tabla descendente
existe en la tabla base. Véase también Tabla que es dependiente de otra tabla o
hueco por actualización. tabla que es descendiente de una tabla
dependiente.
norma de supresión
Norma que indica a DB2 lo que ha de función determinista
hacer en una fila dependiente cuando se Función definida por el usuario cuyo
suprime una fila padre. Las normas de resultado depende de los valores de los
argumentos de entrada. Es decir, las

sucesivas invocaciones a los mismos bases de datos relacionales. Véase
valores de entrada producen la misma también acceso DRDA.
respuesta. A veces conocida como función
DNS Véase servidor de nombre de dominio.
no variante. Compárese con función no
determinista (a veces denominada función | DOCID
variante). | Véase ID de documento
dimensión | ID de documento
Categoría de datos como por ejemplo | Valor que identifica exclusivamente una
tiempo, productos o mercados. Se hace | fila que contiene una columna XML. Este
referencia a los elementos de una | valor se almacena con la fila y no cambia
dimensión como miembros. Véase | nunca.
también tabla de dimensión.
dominio
tabla de dimensión Conjunto de valores válidos para un
Representación de una dimensión en un atributo.
esquema en estrella. Cada fila de una
nombre de dominio
tabla de dimensión representa todos los
Nombre mediante el que las aplicaciones
atributos de un miembro específico de la
de TCP/IP hacen referencia a un sistema
dimensión. Véase también dimensión,
principal de TCP/IP dentro de una red
esquema en estrella y unión en estrella.
TCP/IP.
directorio
servidor de nombres de dominio (DNS)
Base de datos del sistema DB2 que
Servidor de red de TCP/IP especial que
contiene objetos internos, como los
gestiona un directorio distribuido que se
descriptores de base de datos y tablas de
utiliza para correlacionar nombres de
cursor esquemáticas.
sistema principal TCP/IP con direcciones
disco Dispositivo de almacenamiento de acceso de IP.
directo que registra los datos de forma
objeto grande de carácter de doble byte
magnética.
(DBCLOB)
tipo diferenciado | Tipo de datos de serie gráfica en la que
Tipo de datos definido por el usuario que | una secuencia de bytes representa
se representa internamente como un tipo | caracteres de doble byte que van de 0
existente (su tipo de fuente), pero que se | bytes a 2 GB, menos 1 byte. En general,
considera como un tipo separado e | los valores DBCLOB se utilizan cuando es
incompatible para finalidades semánticas. | posible que una serie de caracteres de
| doble byte supere los límites del tipo
datos distribuidos
| VARGRAPHIC.
Datos que residen en un DBMS distinto
del sistema local. juego de caracteres de doble byte (DBCS)
Juego de caracteres utilizado por algunos
recurso de datos distribuidos (DDF)
idiomas, tales como el japonés o el chino,
Conjunto de componentes de DB2 a
que tienen más símbolos que los que
través de los cuales DB2 se comunica con
pueden representarse por medio de un
otro sistema de bases de datos relacional.
solo byte. Cada carácter tiene 2 bytes de
Distributed Relational Database Architecture longitud. Compárese con juego de
(DRDA) caracteres de un solo byte y juego de
Protocolo de conexión para el proceso de caracteres de múltiples bytes.
bases de datos relacionales distribuidas
número de coma flotante de doble precisión
que es utilizado por los productos de
Representación aproximada de 64 bits de
bases de datos relacionales de IBM.
un número real.
DRDA incluye los protocolos para las
comunicaciones entre una aplicación y un DPSI Véase índice secundario de datos
sistema de gestión de bases de datos particionados.
relacionales remotas y para la
consumo
comunicación entre sistemas de gestión de
Acto de adquirir un recurso bloqueado
Glosario 369
mediante la inmovilización del acceso a interchange code (código de intercambio
ese objeto. Compárese con reclamación. decimal ampliado codificado en binario).
Sistema de codificación que se utiliza para
bloqueo de consumo
representar datos de tipo carácter en los
Bloqueo sobre una clase de reclamación
entornos z/OS, VM, VSE e iSeries.
que impide que se produzca una
Compárese con ASCII y Unicode.
reclamación.
SQL incorporado
DRDA
Sentencias de SQL codificadas dentro de
Véase Distributed Relational Database
un programa de aplicación. Véase SQL
Architecture.
estático.
acceso a DRDA
| modalidad* de habilitación de nueva función
Método abierto de acceder a datos
| (ENFM*)
distribuidos que pueden utilizarse para
| Etapa de transición del proceso de
conectarse con otro servidor de bases de
| migración de versión a versión que se
datos a fin de ejecutar paquetes que se
| aplica a un grupo de compartimiento de
han vinculado anteriormente en la
| datos o subsistema de DB2 que estaba en
ubicación del servidor.
| modalidad de nueva función (NFM) en
DSN | un momento dado. Cuando está en
v Nombre del subsistema de DB2 por | modalidad* de habilitación de nueva
omisión. | función, un grupo de compartimiento de
| datos o subsistema de DB2 se está
v Nombre del procesador de mandatos
| preparando para utilizar las nuevas
de TSO de DB2.
| funciones de la nueva versión pero no
v Los tres primeros caracteres del módulo | puede utilizarlas aún. Un grupo de
de DB2 y nombre de macro. | compartimiento de datos que se encuentra
cursor dinámico | en modalidad* de habilitación de nueva
Estructura de control con nombre que un | función no puede coexistir con miembros
programa de aplicación utiliza para | que se encuentran aún en el nivel de
cambiar el tamaño de la tabla de | versión anterior. No se permite volver a
resultados y el orden de sus filas después | una versión anterior. Compárese con
de abrir el cursor. Compárese con cursor | modalidad de compatibilidad, modalidad
estático. | de compatibilidad*, modalidad de
| habilitación de nueva función y
vuelco dinámico | modalidad de nueva función.
Vuelco que se emite durante la ejecución
de un programa, normalmente bajo el | modalidad de habilitación de nueva función
control de dicho programa. | (ENFM)
| Estado de transición del proceso de
SQL dinámico | migración de versión a versión durante el
| Sentencias de SQL que se preparan y se | cual el grupo de compartimiento de datos
| ejecutan en tiempo de ejecución. En el | o subsistema de DB2 se está preparando
| SQL dinámico, la sentencia de SQL está | para utilizar las nuevas funciones de la
| contenida como serie de caracteres en una | nueva versión. Cuando está en modalidad
| variable de lenguaje principal o como una | de habilitación de nueva función, un
| constante, y no se precompila. | grupo de compartimiento de datos de
espacio de tablas habilitado para EA | DB2 no puede coexistir con miembros que
Espacio de tablas o de índice habilitado | aún se encuentran en el nivel de versión
para la direccionabilidad ampliada (EA) y | anterior. No se permite volver a una
que contiene particiones individuales (o | versión anterior y las nuevas funciones de
piezas, para espacios de tablas LOB) que | la nueva versión no están disponibles
son mayores que 4 GB. | para ser utilizadas en modalidad de
| habilitación de nueva función. Compárese
EB Véase exabyte. | con modalidad de compatibilidad,
EBCDIC | modalidad de compatibilidad*, modalidad
Extended binary coded decimal

| de habilitación de nueva función* y físicamente dañadas. DB2 no permitirá a
| modalidad de nueva función. los usuarios el acceso a las páginas que se
encuentran dentro de este rango.
enclave
En Language Environment, colección carácter de escape
independiente de rutinas, una de las Símbolo, un símbolo de comillas dobles
cuales se ha designado como rutina (″), por ejemplo, que se utiliza para
principal. Un enclave es similar a un contener un identificador delimitado de
programa o unidad de ejecución. Véase SQL.
también enclave de WLM.
exabyte
sistema de codificación Unidad de medida para procesadores,
Conjunto de normas para representar capacidades de almacenamiento real y
datos de tipo carácter (ASCII, EBCDIC o virtual, y volúmenes de canal cuyo valor
Unicode). es 1.152.921.504.606.846.976 bytes, lo que
equivale a 260.
| ENFM Véase modalidad de habilitación de
| nueva función. excepción
| Operación de SQL que implica al
ENFM*
| operador de conjunto EXCEPT, que
| Véase modalidad de habilitación de
| combina dos tablas de resultados. El
| nueva función*.
| resultado de una operación de excepción
entidad | consta de todas las filas que están sólo en
| Persona, objeto o concepto sobre los que | una de las tablas de resultados.
| se almacena información. En una base de
tabla de excepción
| datos relacional, las entidades se
Tabla que contiene filas que violan las
| representan como tablas. Una base de
restricciones de referencia o las
| datos incluye información sobre las
restricciones de comprobación de tabla
| entidades de una organización o negocio,
que encuentra el programa de utilidad
| y sus relaciones entre ellas.
CHECK DATA.
lista enumerada
bloqueo de exclusividad
Conjunto de objetos de DB2 definidos por
Bloqueo que impide que los procesos de
una sentencia de control del programa de
aplicación que se ejecutan
utilidad LISTDEF en la que no se utilizan
simultáneamente lean o cambien datos.
caracteres de comparación de patrones (*,
Compárese con bloqueo de
%, _ ni ?).
compartimiento.
entorno
sentencia ejecutable
Colección de nombres de recursos lógicos
Sentencia de SQL que puede incorporarse
y físicos que se utilizan para dar soporte
en un programa de aplicación, prepararse
al rendimiento de una función.
y ejecutarse dinámicamente o emitirse de
descriptor de entorno forma interactiva.
| Descriptor de contexto que identifica el
contexto de ejecución
| contexto global para el acceso a la base de
En SQLJ, objeto de Java que se puede
| datos. Todos los datos pertinentes a todos
utilizar para controlar la ejecución de
| los objetos en el entorno están asociados
sentencias de SQL.
| con este descriptor de contexto.
rutina de salida
unión de equivalencia
Programa escrito por el usuario (o
Operación de unión en la que la
programa por omisión proporcionado por
condición de unión tiene el formato
IBM) que recibe el control de DB2 para
expresión = expresión. Véase también
realizar funciones determinadas. Las
unión, unión externa completa, unión
rutinas de salida se ejecutan como
interna, unión externa izquierda, unión
extensiones de DB2.
externa y unión externa derecha.
conversión con expansión
rango de páginas de error
Proceso que se produce cuando la
Rango de páginas que se consideran
Glosario 371
longitud de una serie de caracteres | Asociación de la función con la aplicación
convertida es mayor que la serie original. | de código externo especificada por la
Por ejemplo, este proceso ocurre cuando | cláusula EXTERNA de la sentencia
una serie mixta ASCII que contiene | CREATE FUNCTION. Las funciones
caracteres DBCS se convierte a una serie | externas se pueden clasificar como
de datos mixta EBCDIC; la serie | funciones escalares externas y funciones
convertida es más larga debido a la | de tabla externas. Compárese con función
adición de caracteres de control. | derivada, función incorporada y función
| de SQL.
bloqueo jerárquico explícito
Bloqueo utilizado para hacer que la procedimiento externo
relación padre/hijo entre recursos resulte | Procedimiento que tiene su lógica de
conocida para IRLM. Esta clase de | procedimiento implementada en una
bloqueo evita la actividad global | aplicación de lenguaje de programación
resultante del bloqueo cuando no existe | externo. Asociación del procedimiento con
ningún interés dentro de DB2 para un | la aplicación externa se especifica
recurso. | mediante una sentencia CREATE
| PROCEDURE con una cláusula
privilegio explícito
| LANGUAGE que tiene un valor distinto
| Privilegio que tiene un nombre y se
| de SQL y una cláusula EXTERNAL que
| mantiene como resultado de una
| implícita o explícitamente especifica el
| sentencia GRANT de SQL y se revoca
| nombre de la aplicación externa.
| como resultado de una sentencia
| Compárese con procedimiento externo de
| REVOKE de SQL. Por ejemplo, el
| SQL y procedimiento nativo de SQL.
| privilegio de SELECT.
rutina externa
nombre expuesto
Función definida por el usuario o
Nombre de correlación o nombre de vista
procedimiento almacenado que está
o tabla para la que no se especifica un
basado en código escrito en un lenguaje
nombre de correlación.
de programación externo.
expresión
| procedimiento de SQL externo
Operando o colección de operadores y
| Procedimiento de SQL que se procesa
operandos que proporciona un único
| utilizando un programa C generado que
valor.
| es una representación del procedimiento.
Extended Recovery Facility (XRF) | Cuando se llama a un procedimiento SQL
Recurso que minimiza el efecto de los | externo, la representación del programa C
errores en z/OS, VTAM, el procesador | del procedimiento se ejecuta en un
principal o en las aplicaciones de alta | espacio de direcciones de procedimientos
disponibilidad durante las sesiones entre | almacenados. Compárese con
aplicaciones de alta disponibilidad y | procedimiento externo y procedimiento
terminales designados. Este recurso | de SQL nativo.
proporciona un subsistema alternativo
estado de miembro anómalo
para tomar el control de las sesiones del
Estado de un miembro de un grupo de
subsistema anómalo.
compartimiento de datos en el que la
Extensible Markup Language (XML) tarea del miembro, el espacio de
Metalenguaje estándar para definir direcciones o el sistema z/OS termina
lenguajes de marcación que es un antes de que el estado cambie de activo a
subconjunto de Standardized General inmovilizado.
Markup Language (SGML).
retroceder
función externa | Proceso de volver a un release anterior de
| Función que tiene su lógica funcional | DB2 después de intentar o completar la
| implementada en una aplicación de | migración a un release actual. Se permite
| lenguaje de programación que reside | volver a un release anterior sólo desde un
| fuera de la base de datos, en el sistema de | subsistema que esté en modalidad de
| archivos del servidor de bases de datos. | compatibilidad.

contención de bloqueo global falso evalúa la proporción de filas de una tabla
Indicación de disputa procedente del para las que se cumple un predicado.
recurso de acoplamiento que se produce
serie de caracteres de longitud fija
cuando varios nombres de bloqueo dan
| Serie de caracteres, gráfica o binaria cuya
lugar al mismo indicador y cuando no
| longitud se especifica y no se puede
hay ninguna disputa real.
| cambiar. Compárese con serie de
conjunto de abanico | caracteres de longitud variable.
Vía de acceso física directa a los datos,
FlashCopy
proporcionada por un índice, función de
| Función de IBM Enterprise Storage Server
cálculo aleatorio o enlace; un conjunto de
| que, en combinación con el programa de
abanico es el método mediante el que el
| utilidad BACKUP SYSTEM, puede crear
DB2 da soporte a la ordenación de datos.
| una copia de punto en el tiempo de los
base de datos federada | datos mientras una aplicación se está
Combinación de un servidor DB2 (en los | ejecutando.
entornos Linux, UNIX, y Windows) con
clave externa
varias fuentes de datos a las que el
Columna o conjunto de columnas de una
servidor envía consultas. En un sistema
tabla dependiente de una relación de
de bases de datos federadas, una
restricción. La clave debe tener el mismo
aplicación cliente puede utilizar una
número de columnas, con las mismas
sentencia de SQL para unir datos que
descripciones, que la clave primaria de la
están repartidos entre varios sistemas de
tabla padre. Cada valor de clave externa
gestión de bases de datos y puede
debe coincidir con un valor de clave
visualizar los datos como si fueran
padre situado en la tabla padre asociada o
locales.
ser nulo.
sentido de captación
bosque
| Especificación de la ubicación deseada del
Conjunto ordenado de subárboles de
| cursor como parte de una sentencia
nodos XML.
| FETCH. La especificación se puede
| realizar antes o después de las filas de la recuperación de registro hacia adelante
| tabla de resultados (con BEFORE o La tercera fase del proceso de reinicio
| AFTER). La especificación también puede durante la cual DB2 procesa el registro
| tener un sentido de lectura para una sola hacia adelante para aplicar todos los
| fila (por ejemplo, NEXT, LAST o registros REDO.
| ABSOLUTE n) o un sentido de lectura
espacio libre
| para conjuntos de filas (por ejemplo,
Cantidad total de espacio no utilizado de
| NEXT ROWSET, LAST ROWSET o
una página; es decir, espacio que no se
| ROWSET STARTING AT ABSOLUTE n).
utiliza para almacenar registros ni
procedimiento de campo información de control.
Rutina de salida escrita por el usuario
unión externa completa
diseñada para recibir un único valor y
El resultado de una operación de unión
transformar (codificar o decodificar) la
que incluye las filas coincidentes de las
misma en la forma que pueda especificar
dos tablas que se unen y conserva las filas
el usuario.
no coincidentes de ambas tablas. Véase
| variable de referencia a archivo también unión, unión de equivalencia,
| Variable de lenguaje principal declarada unión interna, unión externa izquierda,
| con uno de los tipos de datos derivados unión externa y unión externa derecha.
| (BLOB_FILE, CLOB_FILE,
| selección completa
| DBCLOB_FILE); las variables de
| Una subselección, una selección completa
| referencia a archivo gobiernan la lectura o
| en paréntesis o una serie de ambos
| escritura de un LOB en un archivo.
| combinados mediante operadores set. Una
factor de filtro | selección completa especifica una tabla de
Número comprendido entre 0 y 1 que | resultados. Si no se utiliza un operador
| set, el resultado de la selección completa
Glosario 373
| es el resultado de la subselección o intermedios de grupo que todavía no se
| selección completa especificada. han convertido al disco.
correlación con escape completo recurso de rastreo generalizado (GTF)
Correlación entre un identificador de SQL Programa de servicio de z/OS que
y un nombre de XML cuando el registra sucesos significativos del sistema,
identificador de SQL es un nombre de como por ejemplo interrupciones de E/S,
columna. interrupciones de SVC, interrupciones de
programa o interrupciones externas.
función
Correlación que está integrada dentro de nombre de recurso genérico
un programa (el cuerpo de la función) Nombre que VTAM utiliza para
que obtiene un valor individual (el representar diversos programas de
resultado) a partir de cero o más valores aplicación que proporcionan la misma
de entrada (argumentos). Véase también función, para gestionar el equilibrado y
función de agregación y función escalar. distribución de sesiones en un entorno
Sysplex.
Las funciones pueden ser funciones
definidas por el usuario, incorporadas o | característica geográfica
generadas por DB2. (Véase también | Objeto de la superficie terrestre (como
función incorporada, función de | una ciudad o un río), espacio (como una
conversión, función externa, función | zona de seguridad que rodea un lugar
derivada, función de SQL y función | peligroso) o suceso que se produce en una
definida por el usuario.) | ubicación (como un accidente de tráfico
| que se produce en un determinado cruce).
definidor de función
ID de autorización del propietario del | sistema de información geográfica
esquema de la función que se especifica | Completo de objetos, datos y aplicaciones
en la sentencia CREATE FUNCTION. | que se utiliza para crear y analizar la
| información espacial sobre características
paquete de función
| geográficas.
Paquete que resulta de vincular DBRM
para un programa de función. getpage
Operación en la que DB2 accede a una
propietario de paquete de función
página de datos.
El ID de autorización del usuario que
vincula el DBRM del programa de bloqueo global
función en un paquete de función. Bloqueo que proporciona control de
concurrencia dentro de subsistemas DB2 y
firma de función
entre ellos. El ámbito del bloqueo abarca
La concatenación lógica de un nombre de
todos los subsistemas de DB2 de un
función calificado al completo con los
tipos de datos de todos sus parámetros.
contención de bloqueo global
GB Gigabyte. Valor equivalente a 1 073 741
Conflictos debidos a peticiones de
824 bytes.
bloqueo entre diferentes miembros de
GBP Véase agrupación de almacenamientos DB2 de un grupo de compartimiento de
intermedios de grupo. datos cuando dichos miembros intentan
serializar recursos compartidos.
dependiente de GBP
Estado de un conjunto de páginas o de rutina de gobierno
una partición de un conjunto de páginas Véase recurso de límite de recursos.
que es dependiente de la agrupación de
serie gráfica
| Secuencia de caracteres de DBCS. Los
El interés de lectura/escritura es activo
| datos gráficos se pueden clasificar además
entre subsistemas de DB2 para este
| como GRAPHIC, VARGRAPHIC o
conjunto de páginas o el conjunto de
| DBCLOB.
páginas ha cambiado páginas de la
agrupación de almacenamientos | GRECP
| Véase recuperación pendiente de la

| agrupación de almacenamientos después de la pérdida de los bloqueos o
| intermedios de grupo. de un área de comunicaciones
compartida.
bloqueo general
Bloqueo en la modalidad de GTF Véase recurso de rastreo generalizado.
compartimiento, actualización o de
descriptor de contexto
exclusividad, que se mantiene sobre una
En ODBC de DB2, variable que hace
tabla, partición o espacio de tablas.
referencia a una estructura de datos y a
duplicación de agrupación de almacenamientos sus recursos asociados. Véase también
intermedios de grupo descriptor de sentencia, descriptor de
Capacidad de grabar datos para dos conexión, y descriptor de entorno.
instancias de una estructura de
panel de ayuda
agrupación de almacenamientos
Pantalla de información que presenta
intermedios de grupo: una agrupación de
texto de guía para ayudar a un usuario
almacenamientos intermedios de grupo
que se encuentre en la estación de trabajo
primaria y una agrupación de
o el terminal.
secundaria. Las publicaciones de z/OS daño heurístico
hacen referencia a estas instancias como Incoherencia en los datos entre uno o más
estructuras “antiguas” (para la primaria) participantes que está implícita cuando
y “nuevas” (para la secundaria). una decisión heurística para solucionar
una LUW dudosa en uno o más
agrupación de almacenamientos intermedios de
participantes difiere de la decisión que se
grupo (GBP)
registra en el coordinador.
Estructura de antememoria del recurso de
acoplamiento que es utilizada por un decisión heurística
grupo de compartimiento de datos para Decisión que implanta la resolución
poner en antememoria datos y asegurar la dudosa en un participante por un medio
coherencia de los datos para todos los diferente a la resincronización automática
miembros. entre el coordinador y el participante.
| recuperación de agrupación de almacenamientos | estadísticas de histograma
| intermedios de grupo pendiente (GRECP) | Forma de resumen la distribución de
| Estado que existe después de que la | datos. Esta técnica divide el rango de
| agrupación de almacenamientos | valores posibles en un archivo en
| intermedios para un grupo de | intervalos, de tal forma que cada intervalo
| compartimiento de datos se pierde. | contiene aproximadamente el mismo
| Cuando un conjunto de páginas está en | porcentaje de los valores. Para cada
| este estado, los cambios que se registran | intervalo se recopila un conjunto de
| en el registro se deben aplicar al conjunto | estadísticas.
| de páginas afectado antes de que se
hueco Fila de la tabla de resultados a la que no
| pueda utilizar el conjunto de páginas.
se puede acceder debido a que se ha
nivel de grupo realizado una supresión o una
Nivel de release de un grupo de actualización en la fila. Véase también
compartimiento de datos, que se establece hueco por supresión y hueco por
cuando el primer miembro migra a un actualización.
nuevo release.
espacio de direcciones inicial
nombre de grupo Área de almacenamiento que z/OS
Identificador XCF de z/OS para un grupo reconoce actualmente como despachada.
de compartimiento de datos.
sistema principal
reinicio de grupo Conjunto de programas y recursos que
Un reinicio de al menos un miembro de están disponibles en una determinada
un grupo de compartimiento de datos instancia de TCP/IP.
expresión de sistema principal
Variable o expresión de Java a la que se
Glosario 375
hace referencia en un programa de | columna de identidad. Una tabla no
aplicación de SQLJ mediante cláusulas de | puede tener más de una columna de
SQL. | identidad.
identificador de sistema principal IFCID Véase identificador de componente de
Nombre que se declara en el programa de recurso de instrumentación.
sistema principal.
IFI Véase interfaz de recurso de
lenguaje principal instrumentación.
Lenguaje de programación en el que
llamada IFI
puede incorporar sentencias de SQL.
Invocación de la interfaz del recurso de
programa de sistema principal instrumentación (IFI) por medio de una
Programa de aplicación escrito en un de sus funciones definidas.
lenguaje de sistema principal y que
copia de imagen
contiene sentencias de SQL incorporado.
Reproducción exacta de la totalidad o
estructura de sistema principal parte de un espacio de tablas. DB2
En un programa de aplicación, estructura proporciona programas de utilidad para
a la que se hace referencia por medio de crear copias de imagen completa (para
sentencias de SQL incorporado. copiar todo el espacio de tablas) o copias
de imágenes incrementales (para copiar
variable de lenguaje principal
sólo las páginas que se han modificado
En un programa de aplicación escrito en
desde la última copia de imagen).
un lenguaje de sistema principal, variable
de aplicación a la que se hace referencia recurso de conexión de IMS
mediante sentencias de SQL incorporado. Subcomponente de DB2 que utiliza
protocolos de la interfaz del subsistema
matriz de variables de lenguaje principal
(SSI) de z/OS y la edición cruzada de
Matriz de elementos, cada uno de los
enlaces para procesar peticiones de IMS a
cuales se corresponde con un valor para
DB2 y para coordinar la asignación de
una columna. La dimensión de la matriz
recursos.
determina el número máximo de filas
para el que es posible utilizar la matriz. en cancelación anómala
Estado de una unidad de recuperación. Si
Procesador integrado IBM System z9 (zIIP)
DB2 falla una vez, comienza a retrotraerse
| Procesador especializado que se puede
una unidad de recuperación, pero antes
| utilizar para algunas funciones de DB2.
de que finalice el proceso, DB2 continúa
IDCAMS restituyendo los cambios durante el
Programa de IBM que se utiliza para reinicio.
procesar mandatos de los servicios de
en confirmación
método de acceso. Puede invocarse como
Estado de una unidad de recuperación. Si
trabajo o paso de trabajo, desde un
DB2 falla después de comenzar el proceso
terminal TSO o desde un programa de
de confirmación de la fase 2, DB2 ″sabe″,
aplicación del usuario.
al reiniciarse, que los cambios efectuados
IDCAMS LISTCAT en los datos son coherentes. Estas
Recurso para obtener la información que unidades de recuperación se denominan
se encuentra en el catálogo de servicios de en confirmación.
método de acceso.
independiente
columna de identidad Objeto (fila, tabla o espacio de tablas) que
| Columna que proporciona una forma para no es padre ni es dependiente de otro
| que DB2 genere automáticamente un objeto.
| valor numérico para cada fila. Las
índice Conjunto de punteros que ordenan
| columnas de identidad se definen
lógicamente los valores de una clave. Los
| mediante la cláusula AS IDENTITY. Para
índices pueden proporcionar un acceso
| asegurar la exclusividad de los valores
más rápido a los datos y pueden asegurar
| puede definirse un índice de exclusividad
la exclusividad en las filas de una tabla.
| de una sola columna que sólo contenga la

particionamiento controlado por índice restituye las actualizaciones de su unidad
Tipo de particionamiento en el que los de recuperación durante el reinicio. Estas
límites de la partición de una tabla unidades de recuperación se denominan
particionada están controlados por los en vuelo.
valores especificados en la sentencia
herencia
CREATE INDEX. Los límites de la
Transferencia, en sentido descendente, de
partición se guardan en la columna
atributos o recursos de clase desde una
LIMITKEY de la tabla de catálogos
clase padre de la jerarquía de clases a una
SYSIBM.SYSINDEXPART.
clase hija.
clave de índice
archivo de inicialización
Conjunto de columnas de una tabla que
Para las aplicaciones ODBC de DB2,
se utilizan para determinar el orden de
archivo que contiene valores que se
las entradas del índice.
pueden definir para ajustar el rendimiento
partición del índice del gestor de bases de datos.
Archivo VSAM que se halla en un espacio
copia incorporada
de índice de particionamiento.
Copia que se produce por medio del
espacio de índice programa de utilidad LOAD o REORG. El
Conjunto de páginas que se utiliza para archivo que la copia incorporada produce
almacenar las entradas de un índice. es equivalente de modo lógico a una
copia de imagen completa producida al
columna indicadora
ejecutar el programa de utilidad COPY
Valor de 4 bytes que se almacena en una
con acceso de sólo lectura (SHRLEVEL
tabla base en lugar de una columna LOB.
REFERENCE).
variable indicadora
unión interna
Variable que se utiliza para representar el
Resultado de una operación de unión que
valor nulo en un programa de aplicación.
incluye sólo las filas coincidentes de las
Si el valor para la columna seleccionada
dos tablas que se unen. Véase también
es nulo, se coloca un valor negativo en la
unión, unión de equivalencia, unión
variable indicadora.
externa completa, unión externa
dudoso izquierda, unión externa y unión externa
Estado de una unidad de recuperación. Si derecha.
DB2 falla después de haber acabado el
paquete no operativo
proceso de confirmación de la fase 1 y
Paquete que no puede utilizarse debido a
antes de comenzar la fase 2, únicamente
la eliminación de una o más funciones
el coordinador de confirmación sabe si
definidas por el usuario o de
una unidad de recuperación va a
procedimientos de los que depende el
confirmarse o retrotraerse. En el reinicio,
paquete. Dicho paquete debe volverse a
si DB2 no tiene la información que
vincular de modo explícito. Compárese
necesita para tomar esta decisión, el
con paquete no válido.
estado de la unidad de recuperación es
dudoso hasta que DB2 obtiene esta cursor insensible
información del coordinador. Más de una Cursor que no es sensible a las
unidad de recuperación puede ser dudosa inserciones, actualizaciones ni supresiones
durante el reinicio. hechas en las filas subyacentes de una
tabla de resultados una vez creada ésta.
resolución dudosa
El proceso de resolver el estado de una desencadenante de inserción
unidad de trabajo lógica dudosa al estado Desencadenante que se define con la
de retrotraer o confirmar. operación de SQL de desencadenante, una
inserción.
en vuelo
Estado de una unidad de recuperación. Si instalar
DB2 falla antes de que su unidad de Proceso de preparar un subsistema de
recuperación haya completado la fase 1 DB2 para que funcione con un subsistema
del proceso de confirmación, simplemente de z/OS.
Glosario 377
| desencadenante INSTEAD OF (en lugar de) | intersección
| Desencadenante asociado con una única | Operación de SQL que implica al
| vista y activado por una operación de | operador de conjunto INTERSECT, que
| inserción, actualización o supresión en la | combina dos tablas de resultados. El
| vista y que puede definir para propagar | resultado de una operación de
| la operación de inserción, actualización o | intersección consta de todas las filas que
| supresión en la vista a las tablas | están en ambas tablas de resultados.
| subyacentes de la vista. Compárese con
paquete no válido
| desencadenante BEFORE y
Paquete que depende de un objeto (que
| desencadenante AFTER.
no sea una función definida por el
identificador del componente de recurso de usuario) que se ha eliminado. Dicho
instrumentación (IFCID) paquete se vuelve a vincular
Valor que designa e identifica un registro implícitamente durante la invocación.
de rastreo de un suceso que se puede Compárese con paquete no operativo.
rastrear. Como parámetro de los
dirección IP
mandatos START TRACE y MODIFY
| Valor que identifica exclusivamente un
TRACE, especifica que el suceso
| sistema principal de TCP/IP.
correspondiente debe rastrearse.
IRLM Véase gestor interno de bloqueo de
interfaz de recurso de instrumentación (IFI)
recursos.
Interfaz de programación que permite a
los programas obtener datos de rastreo en nivel de aislamiento
línea sobre DB2, para enviar mandatos de El grado en el que una unidad de trabajo
DB2 y pasar datos a DB2. está aislada de las operaciones de
actualización de otras unidades de
Interactive System Productivity Facility (ISPF)
trabajo. Véase también estabilidad del
Programa bajo licencia de IBM que
cursor, estabilidad de lectura, lectura
proporciona servicios de diálogo
repetible y lectura no confirmada.
interactivo en un entorno z/OS.
ISPF Véase Interactive System Productivity
interés de lectura/escritura entre DB2
Facility.
Propiedad de los datos de un espacio de
tablas, índice o partición que ha sido iterador
abierto por más de un miembro de un En SQLJ, objeto que contiene el conjunto
grupo de compartimiento de datos para de resultados de una consulta. Un
que escriba en él al menos uno de esos iterador equivale a un cursor en otros
miembros. lenguajes de sistema principal.
servidor de bases de datos intermedio cláusula de declaración de iterador
Destino de una petición procedente de En SQLJ, declaración que genera una
una aplicación local o peticionario de clase de declaración de iterador. Un
aplicación remoto que se reenvía a otro iterador es un objeto de una clase de
servidor de bases de datos. declaración de iterador.
gestor interno de bloqueo de recursos (IRLM) JAR Véase Java Archive.
Subsistema de z/OS que DB2 utiliza para
Java Archive (JAR)
controlar el bloqueo de comunicaciones y
Formato de archivo que se utiliza para
bases de datos.
combinar muchos archivos en uno solo.
internacionalización
JDBC Interfaz de programación de aplicaciones
Soporte a un esquema de codificación que
(API) para bases de datos de Sun
es capaz de representar los caracteres
Microsystems para Java que permite que
codificados correspondientes a muchas
los programas accedan a sistemas de
zonas geográficas e idiomas diferentes.
gestión de bases de datos mediante SQL
Para dar soporte a todos los países, el
invocable.
estándar Unicode necesita más de 1 byte
para representar un carácter individual. unión Operación relacional que permite la
Véase también Unicode. recuperación de datos de dos o más tablas

basándose en valores de columna enclavamiento
coincidentes. Véase también unión de Mecanismo de DB2 para controlar sucesos
equivalencia, unión externa completa, concurrentes o la utilización de recursos
unión interna, unión externa izquierda, del sistema.
unión externa y unión externa derecha.
LCID Véase definición del intervalo de control
KB Kilobyte. Valor de 1024 bytes. del registro.
Kerberos LDS Véase archivo lineal.
Protocolo de autentificación de red que
página final
está diseñado para proporcionar un
Página de índice que contiene pares de
servicio potente de autentificación para
claves e identificadores de registro (RID)
aplicaciones cliente/servidor mediante el
y que apunta a datos propiamente dichos.
cifrado por clave secreta.
Compárese con página no final.
certificado de acceso Kerberos
unión externa izquierda
Mecanismo de aplicación transparente
Resultado de una operación de unión que
que transmite la identidad de un usuario
incluye las filas coincidentes de las dos
emisor a su destino. Un certificado de
tablas que se unen y conserva las filas no
acceso simple contiene la identidad del
coincidentes de la primera tabla. Véase
usuario, una clave de sesión, una
también unión, unión de equivalencia,
indicación de fecha y hora y otros datos,
unión externa completa, unión interna,
todo lo cual se sella utilizando la clave
unión externa y unión externa derecha.
secreta del destino.
clave límite
| clave Columna, colección ordenada de
Valor más alto de la clave de índice de
| columnas o expresión identificada en la
una partición.
| descripción de una tabla, índice o
| restricción de referencia. La misma archivo lineal (LDS)
| columna o expresión puede formar parte Archivo VSAM que contiene datos pero
| de más de una clave. no contiene información de control.
Archivo lineal al que se puede acceder
archivo en secuencia por clave (KSDS)
como serie de bytes direccionables en el
Archivo VSAM cuyos registros se cargan
almacenamiento virtual.
en secuencia por clave y son controlados
por un índice. editor de enlaces
Programa de software para crear módulos
KSDS Véase archivo en secuencia por clave.
de carga a partir de uno o más módulos
objeto grande (LOB) objeto o módulos de carga mediante la
Secuencia de bytes que representan datos resolución de referencias cruzadas entre
de bit, caracteres de un solo byte, los módulos y, si es necesario, el ajuste de
caracteres de doble byte o una mezcla de direcciones.
caracteres de un solo byte y de doble
edición de enlaces
byte. Un LOB puede tener una longitud
Acción de crear un programa de software
máxima de 2 GB menos 1 byte. Véase
cargable utilizando un editor de enlaces.
también objeto grande binario, objeto
grande de tipo carácter y objeto grande lista Tipo de objeto, que puede ser procesado
de tipo carácter de doble byte. por programas de utilidad de DB2, que
identifica varios espacios de tablas, varios
última optimización de agente
espacios de índice o ambas cosas. Las
Flujo de confirmación optimizado para
listas se definen mediante la sentencia de
protocolos de cancelación anormal
control LISTDEF.
asumidos o nada asumido, en la que el
último agente o el participante final, se estructura de lista
convierte en el coordinador de Estructura del recurso de acoplamiento
confirmación. Este flujo guarda al menos que permite que se compartan datos y se
un mensaje. manejen como elementos de una cola.
Glosario 379
bloqueo L bases de datos. Una aplicación utiliza el
Véase bloqueo lógico. nombre de ubicación para acceder a un
servidor de bases de datos de DB2. Es
módulo de carga
posible utilizar un alias de la base de
Unidad de programa que resulta
datos para alterar temporalmente el
apropiada para la carga en el
nombre de ubicación al acceder a un
almacenamiento principal para la
servidor remoto.
ejecución. La salida de un editor de
enlaces. alias de ubicación
Otro nombre por el que se identifica en la
LOB Véase objeto grande.
red un servidor de bases de datos. Las
localizador de LOB aplicaciones pueden utilizar este nombre
Mecanismo que permite a un programa para acceder a un servidor de bases de
de aplicación manipular un valor de datos de DB2.
objeto grande en el sistema de base de
bloqueo
datos. Un localizador de LOB es un valor
Forma de controlar sucesos simultáneos o
de entero de palabra completa que
el acceso a datos. El bloqueo de DB2 lo
representa un único valor de LOB. Un
realiza IRLM.
programa de aplicación recupera un
localizador de LOB en una variable de duración de bloqueo
lenguaje principal y a continuación El intervalo en el que se mantiene el
pueden aplicarse funciones de SQL al bloqueo de DB2.
valor de LOB asociado utilizando el
reajuste de bloqueos
localizador.
Promoción de un bloqueo desde un
bloqueo LOB bloqueo de fila, de página o de LOB a un
Bloqueo sobre un valor de LOB. bloqueo de espacio de tablas debido a que
el número de bloqueos de página que se
espacio de tablas de LOB
mantienen de modo simultáneo en un
Espacio de tablas que contiene todos los
determinado recurso supera un límite
datos para una columna de LOB
predefinido.
determinada en la tabla base asociada.
bloqueo
local Forma de hacer referencia a cualquier
El proceso por el que se asegura la
objeto que el subsistema local de DB2
integridad de los datos. El bloqueo
mantiene. Una tabla local, por ejemplo, es
impide a los usuarios simultáneos acceder
una tabla mantenida por un subsistema
a datos incoherentes. Véase también
local de DB2. Compárese con remoto.
reclamación, consumo y enclavamiento.
entorno local
modalidad de bloqueo
Definición de un subconjunto del entorno
Representación del tipo de acceso que los
de un usuario que combina un CCSID y
programas que se están ejecutando
caracteres definidos para un idioma y un
simultáneamente pueden tener a un
país específicos.
recurso que mantiene un bloqueo de DB2.
bloqueo local
objeto de bloqueo
Bloqueo que proporciona control de
Recurso controlado por un bloqueo de
concurrencia dentro de DB2, pero no
DB2.
control de concurrencia entre DB2; es
decir, su ámbito es un DB2 individual. promoción de bloqueo
Proceso de cambiar el tamaño o la
subsistema local
modalidad de un bloqueo de DB2 a un
DBMS relacional exclusivo al que está
nivel superior, más restrictivo.
directamente conectado el usuario o el
programa de aplicación (en el caso de tamaño de bloqueo
DB2, por medio de uno de los recursos de Cantidad de datos controlada por un
conexión de DB2). bloqueo de DB2 sobre los datos de una
tabla; el valor puede ser una fila, una
ubicación
Nombre exclusivo de un servidor de

página, un LOB, una partición, una tabla índice sin particionamiento que están
o un espacio de tablas. asociados a una partición determinada.
estructura de bloqueo pendiente de recuperación lógica (LRECP)
Estructura de datos del recurso de El estado en el que los datos y las claves
acoplamiento que está formada por una de índice que hacen referencia a los
serie de entradas de bloqueo para mismos son incoherentes.
permitir el bloqueo de compartimiento y
unidad lógica (LU)
el bloqueo exclusivo para recursos
Punto de acceso a través del cual un
lógicos.
programa de aplicación accede a la red
registro SNA para comunicarse con otro programa
Colección de registros que describen los de aplicación. Véase también nombre de
sucesos que se producen durante la LU.
ejecución de DB2 y que indican su
unidad de trabajo lógica
secuencia. La información registrada de
Proceso que un programa ejecuta entre
este modo se utiliza para la recuperación
puntos de sincronización.
en caso de un error durante la ejecución
de DB2. identificador de unidad de trabajo lógica
(LUWID)
definición del intervalo de control del registro
Nombre que identifica una hebra de
Sufijo del registro físico que indica cómo
modo exclusivo en una red. Este nombre
registrar los segmentos que se colocan en
consta de un nombre de red LU calificado
el intervalo de control físico.
al completo, un número de instancia de
reclamación lógica LUW y un número de secuencia de LUW.
Reclamación de una partición lógica de
inicialización del archivo de registro
un índice de no particionamiento.
Primera fase del proceso de reinicio
partición de índice lógica durante la cual DB2 intenta localizar el
Conjunto de todas las claves que hacen final actual del archivo de registro.
referencia a la misma partición de datos.
cabecera de registro (LRH)
bloqueo lógico (bloqueo L) Prefijo, en cada registro, que contiene
Tipo de bloqueo que las transacciones información de control.
utilizan para controlar el acceso
número de secuencia de registro de anotaciones
concurrente a los datos en y entre DB2.
(LRSN)
Compárese con bloqueo físico (enlace P).
Identificador de un registro de
lógicamente completo anotaciones que está asociado a un
Estado en que el proceso de copia miembro de compartimiento de datos.
simultánea finaliza con la inicialización de DB2 utiliza el LRSN para realizar el
los objetos de destino que se copian. Los entorno de compartimiento de datos.
objetos destino están disponibles para su
truncamiento del registro
actualización.
Proceso por el que se establece una RBA
lista de páginas lógicas (LPL) inicial explícita. Esta RBA es el punto en
Lista de páginas erróneas a las que no el que deberá grabar el siguiente byte de
pueden hacer referencia las aplicaciones datos del registro.
hasta que se recuperen las páginas. La
LPL Véase lista de páginas lógicas.
página tiene un error lógico, pues el
soporte de almacenamiento (recurso de LRECP
acoplamiento o disco) puede que no Véase pendiente de recuperación lógica.
contenga errores. Normalmente
LRH Véase cabecera de registro de anotaciones.
corresponde a la pérdida de conexión con
el soporte de almacenamiento. LRSN Véase número de secuencia de registro de
anotaciones.
partición lógica
Conjunto de pares de claves o RID de un LU Véase unidad lógica.
Glosario 381
nombre de LU actual o actualizado. En este proceso, el
Nombre de unidad lógica, que es el usuario puede obtener las funciones del
nombre por el cual VTAM reconoce a un release actual o actualizado sin perder los
nodo en una red. datos creados en el release anterior.
LUW Véase unidad de trabajo lógica. serie de datos mixta
Serie de caracteres que puede contener
LUWID
tanto caracteres de un solo byte como
Véase identificador de unidad de trabajo
caracteres de doble byte.
lógica.
nombre de modalidad
tabla de correlación
En VTAM, nombre que designa la
Tabla que el programa de utilidad
colección de características físicas y
REORG utiliza para correlacionar las
lógicas y atributos de una sesión.
asociaciones entre los RID de los registros
de datos de la copia original y la copia de bloqueos de modificación
sombra. Esta tabla la crea el usuario. Bloqueo L o bloqueo P con un atributo
MODIFY. En todo momento se conserva
supresión masiva
una lista de estos bloqueos activos en la
Supresión de todas las filas de una tabla.
estructura de bloqueo del recurso de
materializar acoplamiento. Si el subsistema solicitante
v Proceso de colocar filas de una vista o de DB2 falla, esos bloqueos de
expresión de tabla anidada en un modificación del subsistema DB2 se
archivo de trabajo para su proceso convierten en bloqueos retenidos.
adicional por parte de una consulta. juego de caracteres de varios bytes (MBCS)
v Colocación de un valor de LOB en Juego de caracteres en el que cada
almacenamiento contiguo. Puesto que carácter está representado por más de un
los valores de LOB pueden ser muy byte. UTF-8 es un ejemplo de un MBCS.
grandes, DB2 evita materializar los Los caracteres de UTF-8 pueden tener de
datos de LOB hasta que llega a ser 1 a 4 bytes en DB2. Compárese con juegos
absolutamente necesario. de caracteres de un solo byte y juego de
caracteres de doble byte. Véase también
tabla de consultas materializadas
Unicode.
Tabla que se utiliza para contener
información derivada de una o más tablas análisis multidimensional
fuente y que puede resumirse a partir de Proceso de evaluar una empresa a más de
las mismas. Compárese con tabla base. un nivel.
MB Megabyte (1 048 576 bytes). Multiple Virtual Storage (MVS)
Elemento del sistema operativo z/OS.
MBCS Véase juego de caracteres de múltiples
Este elemento también se denomina Base
bytes.
Control Program (BCP).
nombre de miembro
actualización múltiple
Identificador XCF de z/OS para un
Proceso de bases de datos relacionales
subsistema de DB2 determinado en un
distribuidas en el que los datos se
actualizan en más de un lugar dentro de
menú Lista visualizada de funciones disponibles una única unidad de trabajo individual.
para su selección por parte del operador.
ejecución simultánea de procesos
A veces un menú recibe el nombre de
Varios TCB que ejecutan una copia del
panel de menú.
código ODBC de DB2 de forma
metalenguaje concurrente (compartiendo un
Lenguaje que se utiliza para crear otros procesador) o en paralelo (en
lenguajes especializados. procesadores centrales separados).
migración MVS Véase Multiple Virtual Storage.
Proceso de convertir un subsistema con
| procedimiento nativo de SQL
un release anterior de DB2 a un release
| Procedimiento de SQL que se procesa

| convirtiendo las sentencias de sean páginas finales o no finales). Las
| procedimiento a una representación páginas no finales nunca apuntan a datos
| nativa almacenada en el directorio de propiamente dichos. Compárese con
| base de datos, como se realiza con otras página final.
| sentencias de SQL. Cuando se invoca un
índice no particionado
| procedimiento de SQL nativo, se carga la
Índice que no está particionado
| representación nativa contenida en el
físicamente. Los índices de
| directorio y DB2 ejecuta el procedimiento.
particionamiento y los índices secundarios
| Compárese con procedimiento externo y
pueden no estar particionados.
| procedimiento externo de SQL.
índice secundario no particionado (NPSI)
expresión de tabla anidada
Índice de un espacio de tablas
Selección completa en una cláusula FROM
particionado que no es el índice de
(encerrada entre paréntesis).
particionamiento ni está particionado.
identificador de red (NID) Compárese con índice secundario de
ID de red asignado por IMS o CICS, o si datos particionados.
el tipo de conexión es RRSAF, el ID de la
índice de no particionamiento
unidad de recuperación de RRS (URID).
Véase índice secundario.
| modalidad de nueva función (NFM)
cursor no desplazable
| Modalidad normal de funcionamiento que
Cursor que sólo se puede mover en el
| existe después de una finalización
sentido de avance. También llamados a
| satisfactoria de una migración de versión
veces cursores sólo de avance o cursores
| a versión. En esta página están
serie.
| disponibles para su utilización todas las
| nuevas funciones de la nueva versión. Un normalización
| grupo de compartimiento de datos de Paso básico en la tarea de crear un diseño
| DB2 no puede coexistir con miembros que lógico para las bases de datos
| aún se encuentran en el nivel de versión relacionales. La normalización ayuda a
| anterior, y no se permite volver a una evitar redundancias e incoherencias en los
| versión anterior. Compárese con datos. Una entidad está normalizada si
| modalidad de compatibilidad, modalidad cumple un conjunto de restricciones para
| de compatibilidad*, modalidad de una forma normal determinada (primera
| habilitación de nueva función y forma normal, segunda forma normal,
| modalidad de habilitación de nueva etc.). Compárese con denormalización.
| función*.
función no variable
| NFM Véase modalidad de nueva función. Véase función determinista.
NID Véase identificador de red. NPSI Véase índice secundario no particionado.
| índice de ID de nodo NUL El carácter nulo (’\0’), que está
| Véase índice de ID de nodo XML. representado por el valor X’00. En el
lenguaje C, este carácter indica el final de
función no determinista
una serie de caracteres.
Función definida por el usuario cuyo
resultado no sólo depende de los valores nulo Valor especial que denota ausencia de
de los argumentos de entrada. Es decir, información.
sucesivas invocaciones con los mismos
terminador nulo
valores de argumento pueden producir un
| En el lenguaje C, valor que indica el final
resultado diferente. Este tipo de función
| de una serie de caracteres. Para series de
en ocasiones recibe el nombre de función
| caracteres de EBCDIC, ASCII y Unicode
variable. Compárese con función
| UTF-8, el terminador nulo es un valor de
determinista (a veces denominada función
| un solo byte (X’00’). Para series de
no variante).
| caracteres de Unicode UTF-16 o UCS-2
página no final | (ancho), el terminador nulo es un valor de
Página que contiene claves y números de | doble byte (X’0000’).
página de otras páginas del índice (ya
Glosario 383
ODBC incluye las filas coincidentes de las dos
Véase Open Database Connectivity. tablas que se están uniendo y preserva la
totalidad o parte de las filas no
controlador de ODBC
coincidentes de las tablas que se están
Biblioteca de enlace dinámico (DLL) que
uniendo. Véase también unión, unión de
utiliza llamadas de función de ODBC e
equivalencia, unión externa completa,
interacciona con una fuente de datos.
unión interna, unión externa izquierda y
| OLAP Véase proceso analítico en línea. unión externa derecha.
| proceso analítico en línea (OLAP) función sobrecargada
| Proceso de recopilar datos de una o varias Nombre de función para el que existen
| fuentes; transformar y analizar los datos varias instancias de función.
| consolidados de forma rápida e
paquete
| interactiva; y examinar los resultados
Objeto que contiene un conjunto de
| entre distintas dimensiones de los datos
sentencias de SQL que se han vinculado
| buscando patrones, tendencias y
estáticamente y que está disponible para
| excepciones en relaciones complejas de
su proceso. Un paquete en ocasiones
| esos datos.
recibe también el nombre de paquete de
Open Database Connectivity (ODBC) aplicación.
Interfaz de programación de aplicaciones
lista de paquetes
(API) de base de datos de Microsoft para
Lista ordenada de nombres de paquetes
el lenguaje C que permite acceder a
que pueden utilizarse para ampliar un
sistemas de gestión de bases de datos
plan de aplicación.
utilizando SQL invocable. ODBC no
requiere la utilización de un nombre de paquete
preprocesador de SQL. Además, ODBC | Nombre de un objeto utilizado para un
proporciona una arquitectura que permite | paquete de aplicación o un paquete de
a los usuarios añadir módulos, llamados | procedimiento de SQL. Un paquete de
controladores de base de datos, los cuales | aplicación es una versión vinculada de un
enlazan la aplicación con sistemas | módulo de petición de base de datos
seleccionados de gestión de bases de | (DBRM) creado mediante el mandato
datos durante la ejecución. Esto significa | BIND PACKAGE o REBIND PACKAGE.
que las aplicaciones ya no necesitan estar | Un paquete de lenguaje de procedimiento
enlazadas directamente con los módulos | de SQL creado por un mandato CREATE
de todos los sistemas soportados de | o ALTER PROCEDURE para un
gestión de bases de datos. | procedimiento de SQL nativo. El nombre
| de un paquete consta de un nombre de
identificador ordinario
| ubicación, un ID de colección, un ID de
Letra mayúscula seguida de cero o más
| paquete y un ID de versión.
caracteres, cada uno de los cuales es una
letra mayúscula, un dígito o el carácter de página
subrayado. Un identificador ordinario no | Unidad de almacenamiento dentro de un
debe ser una palabra reservada. | espacio de tablas (4 KB, 8 KB, 16 KB o 32
| KB) o espacio de índice (4 KB, 8 KB, 16
símbolo ordinario
| KB o 32 KB). En un espacio de tablas, una
Constante numérica, identificador
| página contiene una o más filas de una
ordinario, identificador del lenguaje
| tabla. En un espacio de tablas de LOB o
principal o palabra clave.
| XML, un valor de LOB o XML puede
tarea de origen | abarcar más de una página, pero no hay
En un grupo paralelo, agente primario | más de un valor de LOB o XML
que recibe datos de otras unidades de | almacenado en una página.
ejecución (denominadas tareas paralelas)
conjunto de páginas
que son partes en ejecución de la consulta
Forma alternativa de aludir a un espacio
en paralelo.
de tablas o espacio de índice. Cada
unión externa conjunto de páginas consta de una
Resultado de una operación de unión que colección de archivos VSAM.

conjunto de páginas pendiente de recuperación | de SQL dinámica. El signo de
(PSRCP) | interrogación puede aparecer donde
Estado restrictivo de un espacio de índice. | podría aparecer una variable si la serie de
En este caso, debe recuperarse todo el | sentencia fuese una sentencia de SQL
conjunto de páginas. Se prohíbe la | estático.
recuperación de una parte lógica.
nombre-parámetro
panel Imagen de pantalla predefinida que | Identificador de SQL que designa un
define las posiciones y características de | parámetro en una rutina escrita por un
los campos de pantalla en una superficie | usuario. Los nombres de parámetro son
de visualización (por ejemplo, un panel de | necesarios para procedimientos de SQL y
menú). | funciones de SQL, y se utilizan en el
| cuerpo de la rutina para referirse a los
complejo paralelo
| valores de los parámetros. Los nombres
Grupo de máquinas que trabajan juntas
| de parámetro son opcionales para las
para manejar varias transacciones y
| rutinas externas.
aplicaciones.
clave padre
grupo paralelo
Clave primaria o exclusiva de la tabla
Conjunto de operaciones consecutivas que
padre de una restricción de referencia. Los
se ejecutan en paralelo y que tienen el
valores de una clave padre determinan los
mismo número de tareas paralelas.
valores válidos de la clave externa en la
proceso de E/S paralela restricción de referencia.
Forma de proceso de E/S en el que DB2
bloqueo padre
inicializa varias peticiones simultáneas
En el bloqueo jerárquico explícito,
para una única consulta de usuario y
bloqueo que se mantiene sobre un recurso
realiza el proceso de E/S de modo
que puede tener bloqueos hijo que están
simultáneo (en paralelo) sobre varias
más abajo en la jerarquía. Un bloqueo
particiones de datos.
padre suele ser el bloqueo de espacio de
asistente de paralelismo tablas o el bloqueo de intención de
En el paralelismo de consultas de Sysplex, partición. Véase también bloqueo hijo.
subsistema de DB2 que ayuda a procesar
fila padre
partes de una consulta paralela que se
Fila cuyo valor de clave primaria es el
originó en otro subsistema de DB2 en el
valor de clave externa de una fila
dependiente.
coordinador de paralelismo
tabla padre
En el paralelismo de consultas de Sysplex,
Tabla a cuya clave primaria se hace
subsistema de DB2 en el que se origina la
referencia por medio de la clave externa
consulta paralela.
de una tabla dependiente.
Sysplex paralelo
espacio de tablas padre
Conjunto de sistemas z/OS que se
Espacio de tablas que contiene una tabla
comunican entre sí y trabajan
padre. Un espacio de tablas que contiene
conjuntamente mediante ciertos servicios
un dependiente de dicha tabla es un
de software y componentes de hardware
espacio de tablas dependiente.
para procesar cargas de trabajo de cliente.
participante
tarea paralela
Una entidad que no sea el coordinador de
La unidad de ejecución que se crea
confirmación que toma parte en el
dinámicamente para procesar una
proceso de confirmación. El término
consulta en paralelo. Una tarea paralela la
participante es sinónimo de agente en
implanta un bloque de peticiones de
SNA.
servicio de z/OS.
partición
marcador de parámetro
| Porción de un conjunto de páginas. Cada
| Signo de interrogación (?) que aparece en
| partición se corresponde con un único
| una serie de sentencia de una sentencia
| archivo ampliable de modo
Glosario 385
| independiente. El tamaño máximo de una unidad lógica asociada
| partición depende del número de Punto de acceso de la red SNA que está
| particiones en el conjunto de páginas conectado al subsistema DB2 local por
| particionado. Todas las particiones de un medio de una conversación VTAM.
| determinado conjunto de páginas tienen
vía de acceso
| el mismo tamaño máximo.
Véase vía de SQL.
| espacio de tablas de crecimiento por partición
PDS Véase archivo particionado.
| Espacio de tablas cuyo tamaño puede
| aumentar para acomodar el crecimiento coherencia física
| de los datos. DB2 para z/OS gestiona El estado de una página que no está en
| espacios de tablas de crecimiento por un estado cambiado parcialmente.
| partición añadiendo automáticamente
bloqueo físico (bloqueo P)
| nuevos archivos cuando la base de datos
Tipo de bloqueo que DB2 adquiere para
| necesita más espacio para satisfacer una
proporcionar la coherencia de los datos
| operación de inserción. Compárese con
que se guardan en diferentes subsistemas
| espacio de tablas particionado por rangos.
de DB2. Los bloqueos físicos se utilizan
| Véase también espacio de tablas
sólo en entornos de compartimiento de
| universal.
datos. Compárese con bloqueo lógico
archivo particionado (PDS) (bloqueo L).
| Archivo de almacenamiento en disco que
físicamente completo
| está dividido en particiones, denominadas
Estado existente cuando el proceso de
| miembros. Cada partición puede contener
copia simultánea ha finalizado y se ha
| un programa, parte de un programa o
creado el archivo de salida.
| datos. Una biblioteca de programa es un
| ejemplo de un archivo particionado. fragmento
archivo de un conjunto de páginas no
índice particionado
particionado.
Índice que está particionado físicamente.
Los índices de particionamiento y los plan Véase plan de aplicación.
índices secundarios pueden estar
asignación del plan
particionados.
Proceso de asignar recursos de DB2 a un
conjunto de páginas particionado plan en preparación para la ejecución.
Espacio de índice o espacio de tablas
miembro de plan
particionado. Las páginas de cabecera, las
Copia vinculada de un DBRM que está
páginas de mapa de espacio, las páginas
identificado en la cláusula de miembro.
de datos y las páginas de índice hacen
referencia únicamente a los datos dentro nombre de plan
del ámbito de la partición. El nombre de un plan de aplicación.
espacio de tablas particionado bloqueo P
| Espacio de tablas basado en una única Véase bloqueo físico.
| tabla y que está subdividido en
punto de coherencia
| particiones, cada una de las cuales puede
Momento en el que todos los datos
| ser procesada independientemente por
recuperables a los que accede una
| programas de utilidad. Compárese con
aplicación son coherentes con otros datos.
| espacio de tablas segmentado y espacio
El término punto de coherencia es
| de tablas universal.
sinónimo de punto de sincronización o
índice de particionamiento punto de confirmación.
Índice en el que las columnas situadas
política
más a la izquierda son las columnas de
Véase política de CFRM.
particionamiento de la tabla. El índice
puede estar particionado o no UR de cancelación anómala aplazada
particionado. Unidad de recuperación que estaba
pendiente o en cancelación anómala, se

interrumpió por una cancelación o error intermedios de grupo replicada,
del sistema y no finalizó la restitución estructura que se utiliza para mantener la
durante el reinicio. coherencia de los datos de la
antememoria. Esta estructura se utiliza
precisión
para el registro de páginas e invalidación
En SQL, número total de dígitos de un
cruzada. El equivalente de z/OS es la
número decimal (llamado tamaño en el
estructura antigua. Compárese con
lenguaje C). En el lenguaje C, número de
agrupación secundaria de
dígitos situados a la derecha de la coma
decimal (en SQL se denomina escala). La
información de DB2 utiliza los términos índice primario
de SQL. Índice que asegura la exclusividad de una
clave primaria.
precompilación
Proceso de los programas de aplicación clave primaria
que contienen sentencias de SQL que En una base de datos relacional, clave
tienen lugar antes de la compilación. Las exclusiva, no nula que forma parte de la
sentencias de SQL se sustituyen por definición de una tabla. Una tabla no
sentencias que son reconocidas por el puede definirse como padre a menos que
compilador del lenguaje principal. La tenga una clave exclusiva o una clave
salida de esta precompilación incluye el primaria.
código fuente que puede someterse al
principal
compilador y el módulo de petición de
Entidad que puede comunicarse de modo
base de datos (DBRM) que es la entrada
seguro con otra entidad. En Kerberos, los
al proceso de vinculación.
principales se representan como entradas
predicado en la base de datos de registro de
Elemento de una condición de búsqueda Kerberos e incluyen usuarios, servidores,
que expresa o implica una operación de sistemas y otros.
comparación.
nombre de principal
prefijo El nombre por el que un principal resulta
Código situado al comienzo de un conocido para los servicios de seguridad
mensaje o registro. de DCE.
preformatear privilegio
| Proceso de preparar un archivo lineal de Capacidad de realizar una función
| VSAM para su utilización por DB2, específica, a veces en un objeto específico.
| mediante la escritura de patrones de Véase también privilegio explícito
| datos específicos.
juego de privilegios
preparación | v Con respecto al ID de SYSADM de
La primera fase de un proceso de | instalación, conjunto de todos los
confirmación en dos fases en la que se | privilegios posibles.
pide a todos los solicitantes que se
| v Para cualquier otro ID de autorización,
preparen para la confirmación.
| incluido el ID de autorización PUBLIC,
sentencia de SQL preparada | conjunto de todos los privilegios
Objeto con nombre que es la forma | registrados para ese ID en el catálogo
ejecutable de una sentencia de SQL que | de DB2.
ha procesado la sentencia PREPARE.
proceso
ID de autorización primaria En DB2, unidad a la que DB2 asigna
ID de autorización que se utiliza para recursos y bloqueos. En ocasiones recibe
identificar el proceso de aplicación para el nombre de proceso de aplicación, un
DB2. proceso implica la ejecución de uno o más
programas. La ejecución de una sentencia
agrupación primaria de almacenamientos
de SQL siempre se asocia a algún proceso.
intermedios de grupo
El método para iniciar y terminar un
Para una agrupación de almacenamientos
proceso depende del entorno.
Glosario 387
programa secuencial básico (BSAM). Cuando se
Única colección compilable de sentencias utiliza este método, se forma una cola de
ejecutables de un lenguaje de bloque de datos. Los bloques de datos de
programación. entrada esperan a ser procesados y los
bloques de datos de salida se transfieren a
arreglo temporal de programa (PTF)
almacenamiento auxiliar o a un
Solución o modo de eludir un problema
dispositivo de salida.
que se diagnostica como resultado de un
defecto en el release actual no modificado punto de inmovilización
de un programa bajo licencia. Un arreglo Punto en el que los datos son coherentes
de informe autorizado de análisis de como resultado de ejecutar el programa
programa (APAR) es un servicio de de utilidad QUIESCE de DB2.
corrección para un problema existente. Un
RACF Recurso de control de acceso de recursos.
PTF es un servicio preventivo para los
Componente del servidor de seguridad de
problemas que pudieran encontrar otros
z/OS.
usuarios del producto. Un PTF es
temporal, ya que un arreglo permanente | espacio de tablas particionado por rangos
normalmente no se incorpora al producto | Tipo de espacio de tablas universal
hasta el siguiente release. | basado en rangos de particionamiento y
| que contiene una única tabla. Compárese
conversación protegida
| con espacio de tablas de crecimiento por
Conversación de VTAM que es
| partición. Véase también espacio de tablas
compatible con la confirmación en dos
| universal.
fases.
RBA Véase dirección relativa de byte.
PSRCP
Véase conjunto de páginas pendiente de RCT Véase tabla de control de recursos.
recuperación.
| RDO Véase definición de recursos en línea.
PTF Véase arreglo temporal de programa.
estabilidad de lectura (RS)
QSAM Nivel de aislamiento que es similar a la
Véase método de acceso secuencial por lectura repetible, pero que no aísla
colas. completamente un proceso de aplicación
de todos los demás procesos de aplicación
consulta
que se están ejecutando simultáneamente.
Componente de determinadas sentencias
Véase también estabilidad del cursor,
de SQL que especifica una tabla de
lectura repetible y lectura no confirmada.
resultados.
revincular
bloque de consulta
Creación de un nuevo plan de aplicación
Parte de una consulta que se representa
para un programa de aplicación que se ha
por medio de una de las cláusulas FROM.
vinculado previamente. Si, por ejemplo,
Cada cláusula FROM puede tener
ha añadido un índice a una tabla a la que
múltiples bloques de consulta,
la aplicación accede, debe revincular la
dependiendo del proceso de DB2 de la
aplicación para sacar partido a dicho
consulta.
índice.
paralelismo de CP de consulta
reconstruir
Ejecución en paralelo de una única
Proceso de reasignar una estructura del
consulta, que se consigue utilizando
recurso de acoplamiento. Para la
varias tareas. Véase también paralelismo
estructura del área de comunicaciones
de consulta de Sysplex.
compartida (SCA) y de bloqueo, la
paralelismo de E/S de consulta estructura se vuelve a completar; para la
Acceso paralelo a datos, que se consigue agrupación de almacenamientos
al desencadenar varias peticiones de E/S intermedios de grupo, las páginas
en una única consulta. cambiadas suelen convertirse en un disco
y la nueva estructura sólo se completa
método de acceso secuencial por colas (QSAM)
Versión ampliada del método de acceso

con páginas cambiadas que no se hayan mecanismos de recuperación de otros
convertido de modo satisfactorio. subsistemas (por ejemplo, IMS) actuando
como participante en el proceso del otro
registro
subsistema para proteger los datos que
Representación en el almacenamiento de
han alcanzado un punto de coherencia.
una fila u otros datos.
Coordinador o participante (o ambos), en
identificador de registro (RID)
la ejecución de una confirmación en dos
Identificador exclusivo que DB2 utiliza
fases, que puede acceder a un registro de
para identificar una fila de datos en una
recuperación que mantiene el estado de la
tabla. Compárese con identificador de fila.
unidad de trabajo lógica y da nombre al
agrupación de identificadores de registros (RID) coordinador de comunicaciones en
Área de almacenamiento principal que se sentido inverso inmediato y a los
utiliza para ordenar los identificadores de participantes de comunicaciones en
registros durante el proceso de sentido directo.
precaptación de listas.
pendiente de recuperación (RECP)
longitud de registro Condición que impide a SQL acceder a un
Suma de la longitud de todas las espacio de tablas que debe recuperarse.
columnas de una tabla, que es la longitud
símbolo de recuperación
de los datos tal como están almacenados
Identificador para un elemento que se
físicamente en la base de datos. Los
utiliza en la recuperación (por ejemplo,
registros pueden ser de longitud fija o
NID o URID).
variable, dependiendo de cómo estén
definidas las columnas. Si todas las RECP Véase pendiente de recuperación.
columnas son de longitud fija, el registro
rehacer
es de longitud fija. Si una o más columnas
Estado de una unidad de recuperación
son de longitud variable, el registro es de
que indica que los cambios deben volver
longitud variable.
a aplicarse al soporte en disco para
recurso de conexión de los servicios del gestor asegurar la integridad de los datos.
de recursos recuperables (RRSAF)
código reentrante
Subcomponente de DB2 que hace uso de
Código ejecutable que puede residir en la
RRS (servicios de recuperación de
memoria como copia individual
recursos) para coordinar la asignación de
compartida por todas las hebras. El
recursos entre DB2 y todos los demás
código reentrante no se modifica a sí
gestores de recursos que también utilizan
mismo y proporciona áreas de
RRS en un sistema z/OS.
almacenamiento independientes para cada
recuperación hebra. Véase también seguridad de
Proceso de reconstruir bases de datos hebras.
después de un error del sistema.
restricción de referencia
archivo de registro de recuperación Requisito por el que los valores no nulos
Colección de registros que describe los de una clave externa designada sólo son
sucesos que se producen durante la válidos si son iguales a valores de la clave
ejecución de DB2 e indica su secuencia. primaria de una tabla designada.
La información registrada se utiliza para
| ciclo referencial
la recuperación en caso de error durante
| Conjunto de restricciones referenciales de
la ejecución de DB2.
| tal forma que cada tabla base en el
gestor de recuperación | conjunto es un descendiente de sí misma.
Subcomponente que proporciona servicios | Las tablas implicadas en un ciclo
de coordinación que controlan la | referencial están ordenadas de tal forma
interacción de gestores de recursos de | que cada tabla es un descendiente de la
DB2 durante los procesos de | tabla anterior, y la primera tabla es un
confirmación, cancelación anormal, punto | descendiente de la última tabla.
de control y reinicio. El gestor de
recuperación también da soporte a los
Glosario 389
integridad de referencia nivel anterior. Este procedimiento
Estado de una base de datos en el que constituye otro proceso de migración.
son válidos todos los valores de todas las
remoto
claves externas. Para mantener la
Cualquier objeto mantenido por medio de
integridad de referencia es necesario
un subsistema DB2 remoto (es decir, por
aplicar restricciones de referencia para
medio de un subsistema de DB2 que no
todas las operaciones que modifican los
sea el local). Una vista remota, por
datos de una tabla sobre la que se han
ejemplo, es una vista mantenida por un
definido las restricciones de referencia.
subsistema remoto de DB2. Compárese
estructura de referencia con local.
Conjunto de tablas y relaciones que
subsistema remoto
incluye al menos una tabla y para cada
Cualquier DBMS relacional, excepto el
tabla del conjunto, todas las relaciones en
subsistema local, con el que puede
las que participa dicha tabla y todas las
comunicarse el usuario o aplicación. No
tablas con las que está relacionado.
es necesario que el subsistema sea remoto
edad de renovación en sentido físico e incluso puede operar
La duración entre la hora actual y la hora en el mismo procesador bajo el mismo
en que se renovó por última vez una tabla sistema z/OS.
de consultas materializada.
reoptimización
registro Proceso de DB2 de reconsiderar la vía de
Véase base de datos de registro. acceso de una sentencia de SQL en
tiempo de ejecución; durante la
base de datos de registro
reoptimización DB2 utiliza los valores de
Base de datos de información de
variables de sistema principal, los
seguridad sobre principales, grupos,
marcadores de parámetros o los registros
organizaciones, cuentas y políticas de
especiales.
seguridad.
| formato de fila reordenado
base de datos relacional
| Formato de fila que facilita el rendimiento
Base de datos que puede percibirse como
| mejorado en recuperación de filas que
conjunto de tablas y manipularse con
| tienen columnas de longitud variable.
arreglo al modelo de datos relacional.
| DB2 reorganiza el orden de las columnas,
sistema de gestión de bases de datos | tal como está definido en la sentencia
relacionales (RDBMS) | CREATE TABLE, de forma que las
Colección de hardware y software que | columnas de longitud fija se almacenan al
organiza y proporciona acceso a una base | principio de la fila y las columnas de
de datos relacional. | longitud variable se almacenan al final de
| la fila. Compárese con formato de fila
| esquema relacional
| básico.
| Véase esquema de SQL.
pendiente de REORG (REORP)
relación
Condición que restringe el acceso de SQL
Conexión definida entre las filas de una
y la mayoría de los programas de utilidad
tabla o las filas de dos tablas. Una
a un objeto que debe reorganizarse.
relación es la representación interna de
una restricción de referencia. REORP
Véase pendiente de REORG.
dirección relativa de byte (RBA)
Desplazamiento de un registro de datos o lectura repetible (RR)
intervalo de control desde el principio del Nivel de aislamiento que proporciona la
espacio de almacenamiento que se asigna máxima protección respecto a la ejecución
al archivo (dataset) o archivo al que de otros programas de aplicación. Cuando
pertenece. un programa de aplicación se ejecuta con
la protección de lectura repetible, otros
remigración
programas no pueden cambiar las filas a
Proceso de volver a un release actual de
las que el programa hace referencia hasta
DB2 después de una retrotracción a un

que el programa llegue a un punto de | definición de recursos en línea en lugar
confirmación. Véase también estabilidad | de la tabla de control de recursos. Véase
del cursor, estabilidad de lectura y lectura | también definición de recursos en línea.
no confirmada.
definición de recursos en línea (RDO)
grupo repetitivo | Método recomendado para definir
Situación en la que una entidad incluye | recursos en CICS mediante la creación
varios atributos que son intrínsecamente | definiciones de recursos de forma
el mismo. La presencia de un grupo | interactiva o utilizando un programa de
repetitivo viola el requisito de la primera | utilidad, y luego guardar las definiciones
forma normal. En una entidad que | en el archivo de definiciones de CICS. En
cumpla el requisito de la primera forma | versiones anteriores de CICS, los recursos
normal, cada atributo es independiente y | se definían utilizando la tabla de control
exclusivo en su significado y en su | de recursos (RCT), que ya no está
nombre. Véase también normalización. | soportada.
mecanismo de detección de reproducción recurso de límite de recursos (RLF)
Método que permite a un principal Parte del código de DB2 que impide que
detectar si una petición es una petición las sentencias de SQL de manipulación
válida procedente de una fuente en la que dinámica superen los límites de tiempo
puede confiarse o si una entidad fiable ha especificados. El recurso de límite de
capturado información procedente de un recursos a veces recibe el nombre de
intercambio previo y está reproduciendo gobernador.
el intercambio de información para
tabla de especificación de límite de recursos
obtener acceso al principal.
(RSLT)
confirmación de petición Tabla definida por el emplazamiento que
Voto que se somete a la fase de especifica los límites que ha de implantar
preparación si el participante ha el recurso de límite de recursos.
modificado datos y está preparado para
gestor de recursos
confirmar o retrotraer.
v Función que es responsable de
peticionario gestionar un determinado recurso y que
Fuente de una petición para acceder a los garantiza la coherencia de todas las
datos que hay en un servidor remoto. En actualizaciones efectuadas en recursos
el entorno DB2, el recurso de datos recuperables dentro de una unidad de
distribuidos proporciona la función de trabajo lógica. El recurso que se está
peticionario. gestionando puede ser físico (por
recurso ejemplo, un disco o un almacenamiento
El objeto de un bloqueo o reclamación, principal) o lógico (por ejemplo, un
que puede ser un espacio de tablas, un determinado tipo de servicio de
espacio de índice, una partición de datos, sistema).
una partición de índice o una partición v Participante, en la ejecución de una
lógica. confirmación en dos fases, que tiene
recursos recuperables que pudieran
asignación de recursos
haberse modificado. El gestor de
La parte de la asignación de planes que
recursos tiene acceso a un registro de
trata específicamente con los recursos de
recuperación para que pueda confirmar
base de datos.
o retrotraer los efectos de la unidad de
tabla de control de recursos trabajo lógica en los recursos
| Construcción de versiones anteriores del recuperables.
| recurso de conexiones de CICS que define
pendiente de reinicio (RESTP)
| los parámetros de autorización y acceso
Estado restrictivo de un conjunto de
| para las transacciones o grupos de
páginas o partición que indica que el
| transacciones. A partir de CICS
trabajo de reinicio (restitución) debe
| Transaction Server Versión 1.3, los
efectuarse en el objeto.
| recursos se definen utilizando la
Glosario 391
RESTP página raíz
Véase pendiente de reinicio. Página de índice que se encuentra en el
nivel más alto (o punto inicial) de un
conjunto de resultados
índice.
Conjunto de filas que un procedimiento
almacenado devuelve a una aplicación | rutina Un objeto de base de datos que incluye
cliente. | lógica de procedimiento y sentencias de
| SQL se almacena en el servidor de bases
localizador de conjunto de resultados
| de datos y se puede invocar desde una
Valor de 4 bytes que DB2 utiliza para
| sentencia de SQL o utilizando la sentencia
identificar de modo exclusivo un conjunto
| CALL. Las clases principales de rutinas
de resultados de consulta que un
| son procedimientos y funciones.
procedimiento almacenado devuelve.
fila El componente horizontal de una tabla.
tabla de resultados
Una fila consta de una secuencia de
Conjunto de filas especificadas por medio
valores, uno por cada columna de la
de una sentencia SELECT.
tabla.
bloqueo retenido
identificador de fila (ROWID)
Bloqueo MODIFY que un subsistema de
Valor que identifica exclusivamente una
DB2 estaba reteniendo en el momento en
fila. Este valor se almacena con la fila y
que se ha producido una anomalía del
no cambia nunca.
subsistema. El bloqueo se mantiene en la
estructura de bloqueo del recurso de bloqueo de fila
acoplamiento después de un error de DB2 Bloqueo sobre una fila de datos
para z/OS. individual.
RID Véase identificador de registro. sentido de lectura posicionado en fila
| Especificación de la ubicación deseada del
agrupación de RID
| cursor como parte de una sentencia
Véase agrupación de identificadores de
| FETCH, respecto a una única fila (por
registro.
| ejemplo, NEXT, LAST o ABSOLUTE n).
unión externa derecha | Compárese con sentido de lectura
Resultado de una operación de unión que | posicionado en conjunto de filas.
incluye las filas coincidentes de las dos
conjunto de filas
tablas que se están uniendo y preserva las
Conjunto de filas para el que se ha
filas no coincidentes del segundo
establecido una posición del cursor.
operando de unión. Véase también unión,
unión de equivalencia, unión externa cursor de conjunto de filas
completa, unión interna, unión externa Cursor que se ha definido para que sea
izquierda y unión externa. posible devolver una o más filas como un
conjunto de filas en una sola sentencia
RLF Véase recurso de límite de recursos.
FETCH. El cursor está situado en el
RLST Véase tabla de especificación de límite de conjunto de filas que se capta.
recursos.
sentido de lectura posicionado en conjunto de
| rol Entidad de base de datos que agrupa | filas Especificación de la ubicación deseada del
| conjuntamente uno o más privilegios y | cursor como parte de una sentencia
| que puede ser asignada a un ID de | FETCH, con respecto a un conjunto de
| autorización primario o a PUBLIC. El rol | filas (por ejemplo, NEXT ROWSET, LAST
| está disponible sólo en un contexto fiable. | ROWSET o ROWSET STARTING AT
| ABSOLUTE n). Compárese con sentido de
retrotraer
| lectura posicionado en fila.
Proceso de restaurar datos, cambiados por
sentencias de SQL, al estado que tenían desencadenante de fila
en su último punto de confirmación. Se Desencadenante que se define con la
liberan todos los bloqueos. Compárese granularidad de desencadenante FOR
con confirmar. EACH ROW.

RRSAF ID de autorización secundaria
Véase Recurso de conexión de los ID de autorización que se ha asociado a
servicios del gestor de recursos un ID de autorización primaria por medio
recuperables. de una rutina de salida de autorización.
RS Véase estabilidad de lectura. agrupación secundaria de almacenamientos
intermedios de grupo
punto de rescate
Para una agrupación replicada de
Entidad, con nombre, que representa el
almacenamientos intermedios de grupo,
estado de los datos y esquemas en un
estructura que se utiliza para copiar
determinado momento dentro de unidad
páginas cambiadas que se graban en la
de trabajo.
agrupación primaria de almacenamientos
SBCS Véasesingle-byte character set. intermedios de grupo. No se produce
ningún registro de páginas ni invalidación
SCA Véase área de comunicaciones
cruzada al utilizar la agrupación
compartidas.
secundaria de almacenamientos
función escalar intermedios de grupo. El equivalente de
Operación de SQL que produce un valor z/OS es la estructura nueva.
individual a partir de otro valor y se
índice secundario
representa por un nombre de función
Índice no particionado que sirve para
seguido de una lista de argumentos
aplicar una restricción de exclusividad,
encerrados entre paréntesis.
agrupar datos en clústeres o proporcionar
escala En SQL, número de dígitos existentes a la vías de acceso a datos para realizar
derecha de la coma decimal (en el consultas. Un índice secundario puede
lenguaje C este número se denomina estar particionado o no particionado.
precisión). La información de DB2 utiliza Véase también índice secundario de datos
la definición de SQL. particionados (DPSI) e índice secundario
no particionado (NPSI).
esquema
Organización o estructura de una base de sección
datos. Segmento de un plan o paquete que
contiene las estructuras ejecutables para
Colección de, y una forma de calificar,
una sentencia de SQL individual. Para la
objetos de base de datos tales como
mayoría de las sentencias de SQL, hay
tablas, vistas, rutinas, índices o
una sección del plan para cada sentencia
desencadenantes que definen una base de
de SQL del programa fuente. Sin
datos. Un esquema de base de datos
embargo, para sentencias relacionadas con
proporciona una clasificación lógica de
el cursor, las sentencias DECLARE,
objetos de base de datos.
OPEN, FETCH y CLOSE hacen referencia
capacidad de desplazamiento a la misma sección ya que cada una de
Capacidad de un cursor para leer en la estas hace referencia a la sentencia
dirección de avance y de retroceso. La SELECT nombrada en la sentencia
sentencia FETCH (buscar) permite varios DECLARE CURSOR. Las sentencias de
sentidos de captación para indicar la SQL, como por ejemplo, COMMIT,
nueva posición del cursor. Véase también ROLLBACK y algunas sentencias SET no
sentido de lectura. utilizan una sección.
cursor desplazable | etiqueta de seguridad
Cursor que se puede mover tanto en el | Clasificación del acceso de los usuarios a
sentido de avance como en el de | objetos o filas de datos en un entorno de
retroceso. | seguridad de varios niveles.
condición de búsqueda segmento
Criterio para seleccionar filas en una Grupo de páginas que contiene filas de
tabla. Una condición de búsqueda consta una tabla individual. Véase también
de uno o más predicados. espacio de tablas segmentado.
Glosario 393
espacio de tablas segmentado clase de servicio
Espacio de tablas que está dividido en Identificador de ocho caracteres que
grupos de páginas de igual tamaño Workload Manager de z/OS utiliza para
llamados segmentos. Los segmentos se asociar los objetivos de rendimiento de
asignan a tablas de modo que las filas de usuario con una determinada hebra o un
tablas diferentes no se guarden nunca en procedimiento almacenado de DDF.
el mismo segmento. Compárese con También se utiliza una clase de servicio
espacio de tablas particionado y espacio para clasificar el trabajo en los asistentes
de tablas universal. de paralelismo.
restricción de autorreferencia bloque de petición de servicio
Restricción de referencia que define una | Unidad de trabajo planificada para
relación en la que una tabla depende de sí | ejecutarse.
misma.
sesión Enlace entre dos nodos de una red
tabla de autorreferencia VTAM.
Tabla con una restricción de
protocolos de sesión
autorreferencia.
El conjunto disponible de peticiones y
cursor sensible respuestas de comunicación de SNA.
Cursor que es sensible a los cambios que
| operador de conjunto
se efectúan en la base de datos una vez
| Operadores UNION, EXCEPT y
creada la tabla de resultados.
| INTERSECT de SQL correspondientes a
secuencia | los operadores relacionales de unión,
Objeto definido por el usuario que genera | diferencia e intersección. Un operador set
una secuencia de valores numéricos de | deriva una tabla de resultados
acuerdo con las especificaciones del | combinando otras dos tablas de
usuario. | resultados.
archivo secuencial área de comunicaciones compartida (SCA)
Archivo no perteneciente a DB2 cuyos Estructura de lista del recurso de
registros se organizan de acuerdo con sus acoplamiento que un grupo de
sucesivas posiciones físicas, tal como compartimiento de datos de DB2 utiliza
ocurre en una cinta magnética. Varios para la comunicación entre sistemas DB2.
programas de utilidad de base de datos
bloqueo de compartimiento
de DB2 requieren archivos secuenciales.
Bloqueo que impide que los procesos de
precaptación secuencial aplicación que se ejecutan
Mecanismo que desencadena operaciones simultáneamente cambien datos, pero que
de E/S asíncronas consecutivas. Las no impide que lean datos. Compárese con
páginas se leen antes de ser solicitadas y bloqueo exclusivo.
se leen varias páginas con una sola
carácter de desplazamiento a teclado estándar
operación de E/S.
Carácter de control especial (X’0F’) que se
perfil serializado utiliza en sistemas EBCDIC para denotar
Objeto de Java que contiene sentencias de que los bytes subsiguientes representan
SQL y descripciones de variables de caracteres SBCS. Véase también carácter
sistema principal. El conversor de SQLJ de desplazamiento a teclado ideográfico.
produce un perfil serializado para cada
carácter de desplazamiento a teclado ideográfico
contexto de conexión.
Carácter de control especial (X’0E’) que se
servidor utiliza en sistemas EBCDIC para denotar
Destino de una petición procedente de un que los bytes subsiguientes, hasta el
peticionario remoto. En el entorno de siguiente carácter de desplazamiento a
DB2, el recurso de datos distribuido teclado estándar, representan caracteres
proporciona la función de servidor, que se DBCS. Véase también carácter de
utiliza para acceder a datos de DB2 desde desplazamiento a teclado estándar.
aplicaciones remotas.

inicio de sesión función derivada
Petición hecha en nombre de un proceso | Función que se implementa por medio de
de aplicación de CICS o IMS por un | otra función incorporada o definida por el
recurso de conexión para permitir que | usuario que ya es conocida por el gestor
DB2 verifique que ese proceso de | de bases de datos. Esta función puede ser
aplicación está autorizado para utilizar | una función escalar o una función de
recursos de DB2. | totales; devuelve un valor único a partir
| de un conjunto de valores (por ejemplo,
conjunto de páginas simple
| MAX o AVG). Compárese con función
Conjunto de páginas no particionado. Un
| incorporada, función externa, y función
conjunto de páginas simple inicialmente
| de SQL.
consta de un único archivo (fragmento del
conjunto de páginas). Si se amplía ese programa fuente
archivo a 2 GB, en ese momento se crea Conjunto de sentencias de lenguaje
otro archivo y así sucesivamente, hasta un principal y sentencias de SQL que es
máximo de 32 archivos. DB2 considera procesado un precompilador de SQL.
que los archivos son un único espacio de
tabla fuente
direcciones contiguo lineal que contiene
Tabla que puede ser una tabla base, una
un máximo de 64 GB. Los datos se
vista, una expresión de tabla o una
almacenan en la siguiente ubicación
función de tabla definida por el usuario.
disponible dentro de este espacio de
direcciones sin tener en cuenta ningún tipo fuente
esquema de particionamiento. Tipo existente que DB2 utiliza para
representar un tipo diferenciado.
espacio de tablas simple
Espacio de tablas que no está ni espacio
particionado ni segmentado. La creación Secuencia de uno o más caracteres en
de espacios de tablas simples no está blanco.
soportada en DB2 Versión 9.1 para z/OS.
| columna espacial
Compárese con espacio de tablas
| Columna de una tabla que se define
particionado, espacio de tablas
| utilizando uno de los tipos de datos
segmentado y espacio de tablas universal.
| espaciales que proporciona IBM Spatial
juego de caracteres de un solo byte (SBCS) | Support para DB2 para z/OS.
Juego de caracteres en el que cada
| datos espaciales
carácter está representado por un solo
| Datos formados por coordenadas que
byte. Compárese con juego de caracteres
| identifican una ubicación o región
de doble byte o juego de caracteres de
| geográfica.
varios bytes.
| función espacial
número de coma flotante de precisión simple
| Función que proporciona IBM Spatial
Representación aproximada de 32 bits de
| Support para DB2 para z/OS y que
un número real.
| realiza varias operaciones sobre datos
SMP/E | espaciales.
Véase System Modification
| sistema de referencia espacial
Program/Extended.
| Conjunto de parámetros que incluye
SNA Véase Systems Network Architecture. | coordenadas que definen la extensión
| máxima posible de espacio a la que hace
red SNA
| referencia un determinado rango de
La parte de una red que se ajusta a los
| coordenadas, un identificador del sistema
formatos y protocolos de la Arquitectura
| de coordenadas a partir del que se
de red de sistemas (SNA).
| derivan coordenadas y números que
socket Interfaz de programación invocable de | convierten coordenadas en enteros
TCP/IP que utilizan las aplicaciones de | positivos a fin de mejorar el rendimiento
red de TCP/IP para comunicarse con | cuando se procesan las coordenadas.
sistemas TCP/IP remotos.
Glosario 395
registro especial función de SQL
| Área de almacenamiento que DB2 define | Función definida por el usuario en la que
| para que un proceso de aplicación la | la sentencia CREATE FUNCTION
| utilice para almacenar información a la | contiene el código fuente. El código
| que se puede hacer referencia en | fuente es una expresión individual de
| sentencias de SQL. Ejemplos de registros | SQL cuya evaluación da como resultado
| especiales son SESSION_USER y | un solo valor. La función de SQL definida
| CURRENT DATE. | por el usuario puede devolver el
| resultado de una expresión. Véase
nombre de función específico
| también función incorporada, función
Función definida por el usuario que el
| externa y función derivada.
gestor de bases de datos conoce por su
nombre específico. Muchas funciones ID de SQL
definidas por el usuario pueden tener el Véase ID de autorización de SQL.
mismo nombre de función. Cuando se
SQLJ SQL (lenguaje de consulta estructurada)
define una función definida por el
que está incorporado en el lenguaje de
usuario para la base de datos, a cada
programación Java.
función se le asigna un nombre específico
que es exclusivo dentro del esquema de la vía de acceso de SQL
función. El usuario puede proporcionar Lista ordenada de nombres de esquema
este nombre o bien se utiliza un nombre que se utilizan en la resolución de
por omisión. referencias no calificadas a funciones
definidas por el usuario, tipos
SPUFI Véase SQL Processor Using File Input.
diferenciados y procedimientos
SQL Véase Lenguaje de consulta estructurada. almacenados. En el SQL dinámico, la vía
de acceso de SQL se encuentra en el
ID de autorización de SQL (ID de SQL)
registro especial CURRENT PATH. En el
ID de autorización que se utiliza para
SQL estático, la vía de acceso de SQL se
comprobar sentencias de SQL dinámico
define en la opción de vinculación PATH.
en algunas situaciones.
procedimiento de SQL
SQLCA
| Programa de aplicación, escrito por un
Véase área de comunicaciones de SQL.
| usuario, que se puede invocar mediante la
área de comunicaciones de SQL (SQLCA) | sentencia CALL de SQL. Un
Estructura que se utiliza para | procedimiento de SQL se escribe en el
proporcionar información a un programa | lenguaje de procedimiento de SQL. Están
de aplicación sobre la ejecución de sus | soportados dos procedimientos de SQL:
sentencias de SQL. | procedimientos de SQL externos y
| procedimientos de SQL nativos. Véase
conexión de SQL
| también procedimiento externo y
Asociación entre un proceso de aplicación
| procedimiento nativo de SQL.
y un servidor de aplicaciones o de bases
de datos local o remoto. conversación de proceso de SQL
Cualquier conversación que requiera
SQLDA
acceder a datos de DB2, ya sea a través
Véase área de descriptores de SQL.
de una aplicación o mediante peticiones
área de descriptores de SQL (SQLDA) de consulta dinámica.
Estructura que describe variables de
SQL Processor Using File Input (SPUFI)
entrada, variables de salida o las
Recurso del subcomponente de conexión
columnas de una tabla de resultados.
de TSO que permite al usuario de DB2I
carácter de escape de SQL ejecutar sentencias de SQL sin
Símbolo que se utiliza para delimitar un intercalarlas en un programa de
identificador delimitado de SQL. Este aplicación.
símbolo es el signo de comilla doble (″).
código de retorno de SQL
Véase también carácter de escape.
SQLCODE o SQLSTATE.

rutina de SQL vinculaciones para argumentos dinámicos
Función definida por el usuario o y columnas, información de cursor,
procedimiento almacenado que están valores de resultado e información de
basados en un código escrito en SQL. estado. Cada descriptor de sentencia está
asociado al descriptor de conexión.
| esquema de SQL
| Colección de objetos de base de datos serie de sentencia
| tales como tablas, vistas, índices, Para una sentencia de SQL dinámica, el
| funciones, tipos diferenciados, esquemas o formato de serie de caracteres de la
| desencadenantes que definen una base de sentencia.
| datos. Un esquema de SQL proporciona
desencadenante de sentencia
| una clasificación lógica de objetos de base
Desencadenante que se define con la
| de datos.
granularidad de desencadenante FOR
coprocesador de sentencias de SQL EACH STATEMENT.
Alternativa al precompilador de DB2 que
cursor estático
permite al usuario procesar sentencias de
Estructura de control con nombre que no
SQL durante la compilación. Para invocar
cambia el tamaño de la tabla de
un coprocesador de sentencias de SQL se
resultados ni el orden de sus filas después
debe especificar una opción de
de que una aplicación abra el cursor.
compilador.
Compárese con cursor dinámico.
delimitador de series de caracteres de SQL
SQL estático
Símbolo que se utiliza para delimitar una
| Sentencias de SQL, incorporadas en un
constante de tipo carácter de SQL. El
| programa, que se preparan durante el
delimitador de series de caracteres del
| proceso de preparación de programa
SQL es el apóstrofe (’), excepto en las
| (antes de que se ejecute el programa).
aplicaciones COBOL, en las que el usuario
| Después de prepararse, la sentencia de
asigna el símbolo, que puede ser un
| SQL no cambia (aunque los valores de
apóstrofe o un signo de comilla doble (″).
| variables especificados por la sentencia
SRB Véase bloque de petición de servicio. | pueden cambiar).
autónomo grupo de almacenamiento
Atributo de un programa que significa | Conjunto de objetos de almacenamiento
que puede ejecutarse de modo | en el que se pueden almacenar los datos
independiente de DB2, sin utilizar | de DB2 para z/OS. Un objeto de
servicios de DB2. | almacenamiento puede tener una clase de
| datos SMS, una clase de gestión, una clase
unión en estrella
| de almacenamiento y una lista de
Método para unir una columna de
| números de serie de volumen.
dimensión de una tabla de hechos con la
columna de clave de la tabla de procedimiento almacenado
dimensión correspondiente. Véase Programa de aplicación, escrito por el
también unión, dimensión y esquema en usuario, que se puede invocar mediante la
estrella. sentencia CALL de SQL. Los
procedimientos almacenados a veces se
esquema en estrella
denominan procedimientos.
Combinación de una tabla de hechos (que
contiene la mayoría de los datos) y varias serie Véase serie de caracteres binaria, serie de
tablas de dimensión. Véase también unión caracteres o serie de caracteres gráfica.
en estrella, dimensión y tabla de
tipificación estricta
dimensión.
Proceso que asegura que sólo las
descriptor de sentencia funciones definidas por el usuario y las
En ODBC de DB2, objeto de datos que operaciones que están definidas en un
contiene información sobre una sentencia tipo diferenciado pueden aplicarse a ese
de SQL gestionada por ODBC de DB2. tipo. Por ejemplo, no puede comparar
Esto incluye información como por directamente dos tipos de divisa, tales
ejemplo argumentos dinámicos, como los dólares americanos y los dólares
Glosario 397
canadienses. Pero puede proporcionar una | cláusula GROUP BY, cláusula HAVING,
función definida por el usuario para | cláusula ORDER BY o cláusula FETCH
convertir una divisa a la otra y después | FIRST.
efectuar la comparación.
carácter de sustitución
estructura Carácter exclusivo que se utiliza como
v Nombre que designa colectivamente los sustituto durante la conversión de
diferentes tipos de objetos de DB2, tales caracteres para los caracteres del
como tablas, bases de datos, vistas, programa fuente que no tienen una
índices y espacios de tablas. correspondencia en la representación
codificada de destino.
v Construcción que hace uso de z/OS
para correlacionar y gestionar subsistema
almacenamiento en un recurso de Instancia diferenciada de un sistema de
acoplamiento. Véase también estructura gestión de bases de datos relacionales
de antememoria, estructura de lista o (RDBMS).
estructura de bloqueo.
par sustituto
Lenguaje de consulta estructurada (SQL) Representación codificada de un carácter
Lenguaje estandarizado para definir y individual que consta de una secuencia
manipular datos en una base de datos de dos unidades de código de 16 bits; el
relacional. primer valor del par está dentro del rango
U+D800 - U+DBFF y el segundo valor
propietario de la estructura
está dentro del rango U+DC00 - U+DFFF.
En relación a las agrupaciones de
Los pares sustitutos proporcionan una
almacenamientos intermedios de grupo,
forma de codificación ampliada para
miembro de DB2 que se encarga de las
917.476 caracteres sin necesidad de
actividades siguientes:
utilizar caracteres de 32 bits.
v Coordinar el proceso de reconstrucción,
puntos de control y valoración de vuelco de SVC
daños Vuelco que se emite cuando una rutina de
recuperación funcional de z/OS o DB2
v Supervisar el umbral de agrupación de
detecta un error.
y notificar a los propietarios de la punto de sincronización
conversión el momento en que se Véase punto de confirmación.
alcanza el umbral.
árbol de punto de sincronización
subcomponente Árbol de gestores de recuperación y de
Grupo de módulos de DB2 estrechamente gestores de recursos que están implicados
relacionados que funcionan en una unidad de trabajo lógica,
conjuntamente para proporcionar una comenzando por el gestor de
función general. recuperación, que adoptan la decisión de
confirmación final.
tabla sujeto
Tabla para la que se crea un sinónimo
desencadenante. Cuando se produce el | En SQL, nombre alternativo para una
suceso desencadenante definido en esta | tabla o vista. Los sinónimos sólo pueden
tabla, se activa el desencadenante. | utilizarse para hacer referencia a objetos
| en el subsistema donde está definido el
subconsulta
| sinónimo. Un sinónimo no puede estar
Sentencia SELECT dentro de la cláusula
| cualificado y por lo tanto no puede ser
WHERE o HAVING de otra sentencia de
| utilizado por otros usuarios. Compárese
SQL; una sentencia de SQL anidada.
| con alias.
subselección
Sysplex
| Forma de una consulta que incluye sólo
Véase Sysplex paralelo.
| una cláusula SELECT, una cláusula FROM
| y opcionalmente una cláusula WHERE, paralelismo de consulta de Sysplex
Ejecución en paralelo de una única

consulta que se consigue utilizando varias función de tabla
tareas en más de un subsistema de DB2. Función que recibe un conjunto de
Véase también paralelismo de CP de argumentos y devuelve una tabla a la
consulta. sentencia de SQL que hace referencia a la
función. Las funciones de tabla sólo
administrador del sistema
pueden invocarse en la cláusula FROM de
Persona que, en la instalación de un
una subselección.
sistema, diseña, controla y gestiona el uso
del sistema. localizador de tablas
| Mecanismo que permite acceder a tablas
agente del sistema
| de desencadenante en SQL o desde dentro
Petición de trabajo que DB2 crea, tal como
| de funciones definidas por el usuario. Un
un proceso de precaptación, escrituras
| localizador de tablas es un valor entero de
diferidas y tareas de servicio. Véase
| palabra completa que representa una tabla
también agente aliado.
| de transición.
| ID de autorización del sistema
espacio de tablas
| ID de autorización principal de DB2 que
Conjunto de páginas que se utiliza para
| se utiliza para establecer una conexión
almacenar registros en una o más tablas.
| fiable. ID de autorización del sistema
Véase también espacio de tablas
| derivado del ID de usuario del sistema
particionado, espacio de tablas
| proporcionado por una entidad externa,
segmentado y espacio de tablas universal.
| como por ejemplo un servidor
| middleware. conjunto de espacios de tablas
Conjunto de espacios de tablas y
conversación del sistema
particiones que deben recuperarse
Conversación que dos subsistemas de
conjuntamente por una de las razones
DB2 deben establecer para procesar
siguientes:
mensajes del sistema antes de que pueda
comenzar cualquier proceso distribuido. v Cada uno de ellos contiene una tabla
que es padre o descendiente de otra
System Modification Program/Extended (SMP/E) tabla que se encuentra en uno de los
Herramienta de z/OS para efectuar demás.
cambios en el software de sistemas de
v El conjunto contiene una tabla base y
programación (por ejemplo DB2) y para
tablas auxiliares asociadas.
controlar estos cambios.
Un conjunto de espacios de tablas puede
Arquitectura de red de sistemas (SNA)
contener ambos tipos de relaciones.
La descripción de la estructura lógica,
formatos, protocolos y secuencias bloque de control de tareas (TCB)
operacionales para transmitir información Bloque de control de z/OS que se utiliza
y controlar la configuración y para comunicar información sobre las
funcionamiento de redes. tareas de un espacio de direcciones que
están conectado a un subsistema. Véase
tabla Objeto de datos con nombre que consta
también conexión del espacio de
de un número específico de columnas y
direcciones.
un cierto número de filas sin ordenar.
Véase también tabla base o tabla TB Terabyte. Valor equivalente a 1 099 511
temporal. Compárese con tabla auxiliar, 627 776 bytes.
tabla de réplica, tabla de consultas
TCB Véase bloque de control de tareas.
materializadas, tabla de resultados y tabla
de transición. TCP/IP
Protocolo de comunicaciones de red
particionamiento de tabla controlado
utilizado por sistemas informáticos para
Tipo de particionamiento en el que los
intercambiar información a través de
límites de la partición de una tabla
enlaces de telecomunicaciones.
particionada están controlados por los
valores definidos en la sentencia CREATE puerto de TCP/IP
TABLE. Valor de 2 bytes que identifica un usuario
Glosario 399
final o una aplicación de red de TCP/IP compartimiento de tiempo interactivo
en un sistema principal de TCP/IP. desde terminales remotos.
plantilla indicación de fecha y hora
Descriptor de archivos de programas de Valor formado por siete partes que consta
utilidad de DB2 que se utiliza para la de una fecha y una hora. La indicación de
asignación dinámica. Las plantillas se fecha y la hora se expresa en años, meses,
definen mediante la sentencia de control días, horas, minutos, segundos y
de programa de utilidad TEMPLATE. microsegundos.
tabla temporal rastreo
Tabla que contiene datos temporales. Las Recurso de DB2 que facilita la capacidad
tablas temporales son útiles para contener de supervisar y recopilar datos de
o clasificar resultados intermedios supervisión, auditoría, rendimiento,
procedentes de consultas que contienen contabilidad, estadísticas y servicio
un gran número de filas. Existen dos tipos (globales) de DB2.
de tablas temporales: la tabla temporal
| transacción
creada y la tabla temporal declarada, las
| Serie atómica de sentencias de SQL que
cuales son creadas por sentencias de SQL
| componen una unidad lógica de trabajo.
diferentes. Compárese con tabla de
| Todas las modificaciones de datos
resultados. Véase también tabla temporal
| realizadas durante una transacción se
creada y tabla temporal declarada.
| confirman conjuntamente como una
hebra Véase hebra de DB2. | unidad o se retrotraen como una unidad.
líneas de proceso seguras bloqueo de transacciones
Característica del código de programación Bloqueo que se utiliza para controlar la
que permite la ejecución simultánea de ejecución simultánea de sentencias de
hebras al proporcionar áreas de SQL.
almacenamiento privadas para cada hebra
nombre de programa de transacciones
y serializar debidamente las áreas de
En conversaciones de SNA LU 6.2,
almacenamiento compartido (globales).
nombre del programa en la unidad lógica
nombre de tres partes remota que deberá ser la otra mitad de la
Nombre completo de una tabla, vista o conversación.
alias. Consta de un nombre de asignación,
tabla de transición
un nombre de esquema y un nombre de
Tabla temporal que contiene todas las
objeto, separados por un punto.
filas afectadas de la tabla en cuestión en
hora Valor de tres partes que designa una hora su estado anterior o posterior al suceso
del día en horas, minutos y segundos. desencadenante. Las sentencias de SQL
desencadenadas en la definición de
tiempo de espera excedido
desencadenante que hacen referencia a la
Terminación anormal del subsistema de
tabla de filas cambiadas en el estado
DB2 o de una aplicación debido a la no
antiguo o en el nuevo. Compárese con
disponibilidad de recursos. Las
tabla auxiliar, tabla base, tabla de réplica
especificaciones de instalación se
y tabla de consultas materializadas.
establecen para determinar tanto el
espacio de tiempo que DB2 deberá variable de transición
esperar servicios de IRLM después del Variable que contiene un valor de
inicio como el espacio de tiempo que columna de la fila afectada de la tabla en
IRLM deberá esperar si no está disponible cuestión en su estado anterior o posterior
un recurso solicitado por la aplicación. Si al suceso desencadenante. Las sentencias
se supera cualquiera de estas de SQL desencadenadas en la definición
especificaciones de tiempo, se declara un de desencadenante pueden hacer
tiempo de espera excedido. referencia al conjunto de valores antiguos
o al conjunto de valores nuevos.
Time-Sharing Option (TSO)
Opción de z/OS que proporciona estructura en árbol
Estructura de datos que representa las

entidades como nodos, la mayoría con un para determinar si deben ejecutarse las
nodo padre para cada nodo y sólo un sentencias de SQL desencadenadas.
nodo raíz.
sentencias de SQL desencadenadas
desencadenante El conjunto de sentencias de SQL que se
| Objeto de base de datos asociado con una ejecuta cuando se activa un
| única tabla base o vista que define una desencadenante y se evalúa como
| norma. La norma consta de un conjunto verdadera su condición de acción
| de sentencias de SQL que se ejecutan desencadenada. Las sentencias de SQL
| cuando se realiza una operación de base desencadenadas también reciben el
| de datos de inserción, actualización o nombre de cuerpo desencadenante.
| supresión en la tabla base o vista
granularidad desencadenante
| asociada.
En SQL, característica de un
activación de desencadenante desencadenante, que determina si se
El proceso que se produce cuando se activa el desencadenante:
ejecuta el suceso desencadenante que se v Sólo una vez para la sentencia de SQL
define en una definición de desencadenante
desencadenante. La activación del
v Una vez para cada fila que la sentencia
desencadenante consta de la evaluación
de SQL modifica
de la condición de acción desencadenada
y la ejecución condicional de las suceso desencadenante
sentencias de SQL desencadenadas. | La operación especificada en una
| definición del desencadenante que
tiempo de activación de desencadenante
| ocasiona la activación de dicho
Indicación en la definición de
| desencadenante. El suceso
desencadenante de si debe activarse o no
| desencadenante está compuesto por una
el desencadenante antes o después del
| operación desencadenante (insert, update
suceso desencadenante.
| o delete) y una tabla sujeto en la que se
cuerpo desencadenante | efectúa la operación.
El conjunto de sentencias de SQL que se
operación de SQL desencadenante
ejecuta cuando se activa un
| Operación de SQL que hace que se active
desencadenante y se evalúa como
| un desencadenante cuando la operación
verdadera su condición de acción
| se efectúa en la vista o tabla sujeto.
desencadenada. Un cuerpo
desencadenante también se denomina paquete desencadenante
sentencias de SQL desencadenadas. Paquete que se crea cuando se ejecuta una
sentencia CREATE TRIGGER. El paquete
desencadenante en cascada
se ejecuta cuando se activa el
El proceso que se produce cuando la
desencadenante.
acción desencadenada de un
desencadenante ocasiona la activación de | atributo fiable
otro desencadenante. | Atributo en el que establecer la confianza.
| Una relación fiable se estable en base a
acción desencadenada
| uno o varios atributos fiables.
Lógica de SQL que se realiza cuando se
activa un desencadenante. La acción | conexión fiable
desencadenada consta de una condición | Conexión de base de datos cuyos
de acción desencadenada y de un | atributos coinciden con los atributos de
conjunto de sentencias de SQL | un contexto fiable exclusivo definido en el
desencadenadas que sólo se ejecutan si se | servidor de bases de datos de DB2.
evalúa como verdadera la condición.
| reutilización de conexión fiable
condición de acción desencadenada | Capacidad de conmutar el ID de usuario
Parte opcional de la acción | actual en una conexión fiable a un ID de
desencadenada. Esta condición Booleana | usuario distinto.
aparece como una cláusula WHEN y
| contexto fiable
especifica una condición que DB2 evalúa
| Objeto de seguridad de base de datos que
Glosario 401
| permite el establecimiento de una relación UDT Tipo de datos definido por el usuario. En
| fiable entre un sistema de gestión de DB2 para z/OS, se utiliza el término tipo
| bases de datos de DB2 y una entidad diferenciado en lugar de tipo de datos
| externa. definido por el usuario. Véase tipo
diferenciado.
| rol por omisión de contexto fiable
| Rol asociado con un contexto fiable. Los lectura no confirmada (UR)
| privilegios otorgados al rol por omisión Nivel de aislamiento que permite que una
| de contexto fiable se pueden adquirir sólo aplicación lea datos sin confirmar. Véase
| cuando se establece o reutiliza una también estabilidad del cursor, estabilidad
| conexión fiable basada en el contexto de lectura y lectura repetible.
| fiable.
vista subyacente
| usuario de contexto fiable Vista en la que está definida otra vista de
| ID de usuario al que está permitido modo directo o indirecto.
| conmutar el ID de usuario actual en una
deshacer
| conexión fiable.
Estado de una unidad de recuperación
| rol específico de usuario de contexto fiable que indica que los cambios que la unidad
| Rol asociado con un usuario específico de de recuperación ha efectuado en recursos
| contexto fiable. Altera temporalmente el de DB2 recuperables deben retrotraerse.
| rol por omisión de contexto fiable si el ID
Unicode
| de usuario actual en la conexión fiable
Estándar análogo al estándar ISO-10646.
| coincide con el ID del usuario de contexto
Existen varias implementaciones del
| fiable específico.
estándar Unicode y todas pueden
| relación fiable representar un porcentaje elevado de los
| Relación privilegiada entre dos entidades caracteres pertenecientes a muchos
| tales como un servidor middleware y un alfabetos utilizados en el mundo.
| servidor de bases de datos. Esta relación
| unión Operación de SQL que implica el
| permite un conjunto exclusivo de
| operador de conjunto UNION, que
| interacciones entre dos entidades que
| combina los resultados de dos sentencias
| sería imposible de otra forma.
| SELECT. Las uniones suelen utilizarse
TSO Véase Time-Sharing Option. | para fusionar listas de valores
| procedentes de dos tablas.
Recurso de conexión de TSO
Recurso de DB2 que consta del restricción de exclusividad
procesador de mandatos de DSN y de Norma de SQL por la que dos valores de
DB2I. Las aplicaciones no escritas para los una clave primaria o clave de un índice
entornos CICS o IMS pueden ejecutarse de exclusividad no pueden ser iguales.
desde el recurso de conexión de TSO.
índice de exclusividad
marcador de parámetros tipificado Índice que asegura que no se almacenen
Marcador de parámetros que se especifica valores de clave iguales en una tabla.
junto con su tipo de datos de destino. Su
unidad de recuperación (UOR)
formato general es:
Secuencia recuperable de operaciones
CAST(? AS tipo-datos) dentro de gestor de recursos individual,
índices de tipo 2 tal como una instancia de DB2.
Índices que se han creado en un release Compárese con unidad de trabajo.
de DB2 posterior a la Versión 7 o que se unidad de trabajo (UOW)
especifican como índices de tipo 2 en la Secuencia recuperable de operaciones
Versión 4 o posterior. dentro de un proceso de aplicación. En
UCS-2 Juego de caracteres universal, codificado cualquier momento, un proceso de
en 2 octetos, lo que significa que cada aplicación es una unidad de trabajo
carácter está representado por 16 bits. individual, pero la vida de un proceso de
aplicación puede abarcar muchas
UDF Véase función definida por el usuario. unidades de trabajo como resultado de

operaciones de confirmación o función derivada o una función de SQL.
retrotracción. En una operación de Compárese con función incorporada.
actualización múltiple, una unidad de
vista de usuario
trabajo individual puede incluir varias
En la creación de modelos lógicos de
unidades de recuperación. Compárese con
datos, modelo o representación de
unidad de recuperación.
información crítica que es necesaria para
| espacio de tablas universal una empresa.
| Espacio de tablas que está segmentado y
UTF-16
| particionado. Compárese con espacio de
(Unicode Transformation Format).
| tablas particionado, espacio de tablas
Formato de codificación de 16 bits que
| segmentado, espacio de tablas de
está diseñado para codificar más de un
| crecimiento por partición y espacio de
millón de caracteres y es un
| tablas particionado por rangos.
superconjunto de UCS-2. El valor de
desbloquear CCSID para los datos en formato UTF-16
Acto de liberar un objeto o recurso del es 1200. DB2 para z/OS da soporte a
sistema que estaba bloqueado UTF-16 en campos de datos gráficos.
anteriormente y devolverlo a la condición
UTF-8 (Unicode Transformation Format).
de disponibilidad general dentro de DB2.
Formato de codificación de 8 bits que está
marcador de parámetros sin tipo pensado para su fácil utilización con los
Marcador de parámetros que se especifica sistemas actuales basados en ASCII. El
sin su tipo de datos de destino. Se valor de CCSID para los datos en formato
representa mediante un signo final de UTF-8 es 1208. DB2 para z/OS da soporte
interrogación (?). a UTF-8 en campos de datos mixtos.
actualizable valor Unidad de datos más pequeña que se
Capacidad de un cursor para realizar manipula en SQL.
actualizaciones y supresiones
variable
posicionadas. La naturaleza actualizable
Elemento de datos que especifica un valor
de un cursor se puede modificar mediante
que puede cambiarse. Un elemento de
la sentencia SELECT y la opción de
datos elementales de COBOL constituye
sensibilidad de cursor que se especifica en
un ejemplo de una variable de sistema
la sentencia DECLARE CURSOR.
principal. Compárese con constante.
hueco por actualización
función variable
Ubicación en la que se encuentra un
Véase función no determinista.
cursor cuando se lee de nuevo una fila de
una tabla resultante y los nuevos valores serie de longitud variable
ya no cumplen la condición de búsqueda. | Serie de caracteres, gráfica o binaria cuya
Véase también hueco por supresión. | longitud varía dentro de límites definidos.
| Compárese con serie de caracteres de
desencadenante de actualización
| longitud fija.
Desencadenante que se define con la
operación activadora update de SQL. versión
| Miembro de un conjunto de programas,
UR Véase lectura no confirmada.
| módulos de petición de base de datos
tipo de datos definido por el usuario (UDT) | (DBRM), paquetes u objetos grandes
Véase tipo diferenciado. | (LOB) similares.
función definida por el usuario (UDF) | v Una versión de un programa es el
Función que se define para DB2 | código fuente producido al precompilar
utilizando la sentencia CREATE | el programa. La versión del programa
FUNCTION y a la que puede hacerse | se identifica por medio del nombre del
referencia posteriormente en sentencias de | programa y de una indicación de
SQL. Una función definida por el usuario | horaria (símbolo de coherencia).
puede ser una función externa, una | v Una versión de una rutina de lenguaje
| de procedimiento de SQL se produce
Glosario 403
| emitiendo la sentencia CREATE o arranque en caliente
| ALTER PROCEDURE para un Proceso de reinicio normal de DB2, que
| procedimiento de SQL nativo. comprende la lectura y el proceso de
| v Una versión de DBRM es el DBRM registros de anotaciones para que los
| que se produce al precompilar un datos bajo el control de DB2 sean
| programa. La versión de DBRM se coherentes. Compárese con arranque en
| identifica por medio del mismo nombre frío.
| de programa e indicación de la hora entorno de aplicación de WLM
| que una versión de programa Atributo de Workload Manager para
| correspondiente. z/OS que está asociado con uno o varios
| v Una versión de un paquete de procedimientos almacenados. El entorno
| aplicación es el resultado de vincular de aplicación de WLM determina el
| un DBRM en un sistema de base de espacio de direcciones en el que se ejecuta
| datos determinado. La versión de un determinado procedimiento
| paquete de aplicación se identifica por almacenado de DB2.
| medio del mismo nombre de programa
| enclave de WLM
| y símbolo de coherencia que el DBRM.
| Construcción que puede abarcar varias
| v Una versión de un LOB es una copia | unidades susceptibles de envío (tareas y
| de un valor de LOB en un momento en | bloqueos de petición de servicio) en
| el tiempo. El número de versión de un | varios espacios de direcciones,
| LOB se almacena en la entrada de | permitiendo que se informe sobre las
| índice auxiliar para el LOB. | mismas y sean gestionadas por WLM
| v Una versión de un registro es una | como parte de una única petición de
| copia del registro en un momento en el | trabajo.
| tiempo.
grabación para el operador (WTO)
| vista Tabla lógica que consta de datos Servicio opcional codificado por el
| generados por una consulta. Una vista se usuario que permite la grabación de un
| puede basar en una o varias tablas base o mensaje en la consola del sistema
| vistas subyacentes y los datos de una informando al operador acerca de errores
| vista se determinan mediante una y condiciones anormales del sistema que
| sentencia SELECT que se ejecuta en tablas pueden precisar correcciones (en z/OS).
| base o vistas subyacentes.
WTO Véase write to operator.
Virtual Storage Access Method (VSAM)
WTOR
| Método de acceso para proceso directo o
Mensaje Write to Operator (WTO) con
| secuencial de registros de longitud fija y
contestación.
| de longitud variable en dispositivos de
| disco. XCF Véase recurso de acoplamiento entre
sistemas.
Virtual Telecommunications Access Method
(VTAM) XES Véase servicios ampliados entre sistemas.
Programa bajo licencia de IBM que
XML Véase Extensible Markup Language.
controla la comunicación y el flujo de
datos en una red SNA (en z/OS). atributo de XML
Par nombre-valor contenido en un
tabla volátil
elemento de XML con identificadores que
Tabla para la que las operaciones de SQL
modifica ciertas características del
eligen el acceso de índice siempre que es
elemento.
posible.
| Columna XML
VSAM
| Columna de una tabla que almacena XML
Véase Método de acceso de
| y se define utilizando el XML de tipo de
almacenamiento virtual.
| datos. Los valores de XML que están
VTAM | almacenados en columnas XML son
Véase Virtual Telecommunications Access | representaciones internas de documentos
Method. | XML correctamente formados.

| Tipo de datos XML | esquemas de XML son una alternativa a
| Tipo de datos con valores XML. | las definiciones de tipo de documentos
| (las DTD) y se pueden utilizar para
elemento de XML
| ampliar la funcionalidad en las áreas de
Estructura lógica de un documento en
| especificación de datos, herencia y
XML que está delimitada por un
| presentación.
identificador de inicio y un identificador
de fin. Cualquier elemento entre el código | repositorio de esquema XML (XSR)
de inicio y el código de finalización es el | Repositorio que permite que el sistema de
contenido del elemento. | base de datos de DB2 almacene esquemas
| de XML. Cuando están registrados con el
| índice XML
| XSR, estos objetos tienen un identificador
| Índice en una columna XML que
| exclusivo y se puede utilizar para validar
| proporciona acceso eficaz a nodos en un
| documentos de instancia de XML.
| documento XML proporcionado claves de
| índice basadas en patrones XML. | Función de serialización de XML
| Función que devuelve una serie de XML
| Bloqueo XML
| serializada de un valor XML.
| Bloque a nivel de columna para datos
| XML. La operación de bloqueos XML es | Tabla de XML
| similar al funcionamiento de bloqueos de | Tabla auxiliar que se crea implícitamente
| LOB. | cuando una columna XML se añade a una
| tabla base. Esta tabla almacena los datos
Nodo de XML
| XML y la columna en la tabla base apunta
La unidad más pequeña de estructura
| a la misma.
completa válida de un documento. Por
ejemplo, un nodo puede representar un | Espacio de tablas XML
elemento, un atributo una serie de texto. Espacio de tablas que se crea
implícitamente cuando una columna XML
| índice de ID de nodo XML
se añade a una tabla base. El espacio de
| Índice creado implícitamente, en una tabla
tablas almacena la tabla XML. Si la tabla
| de XML que proporciona acceso eficaz a
base está particionada, existe un espacio
| documentos XML y navegación entre
de tablas particionadas para cada
| varias filas de datos XML en el mismo
columna XML de datos.
| documento.
X/Open
| Patrón XML
Organización de sistemas abiertos,
| Lista de nombres de elemento, separados
internacionales e independientes, que está
| por barras inclinadas, un nombre de
soportada por la mayoría de los mayores
| atributo opcional (al final) o pruebas de
proveedores de sistemas de información,
| clase, que describen una vía de acceso en
organizaciones de usuario y compañías de
| un documento XML en una columna
software. El objetivo de X/Open es
| XML. El patrón es una forma restrictiva
aumentar la portabilidad de las
| de expresiones de vía de acceso y
aplicaciones combinando estándares
| seleccionada nodos que coinciden con las
existentes y emergentes.
| especificaciones. Los patrones XML se
| especifican para crear índices en columnas XRF Véase Recurso de recuperación ampliado.
| XML en una base de datos.
| XSR Véase repositorio de esquema XML
Función de publicación de XML
| zIIP Véase Procesador integrado IBM System
| Función que devuelve un valor XML de
| z9.
| los valores de SQL. Una función de
| publicación de XML también se denomina z/OS Sistema operativo para la línea de
| constructor de XML. productos System z que da soporte al
almacenamiento real y virtual de 64 bits.
| Esquema XML
| En XML, mecanismo que describe y Entorno de proceso distribuido z/OS (z/OS DCE)
| restringe el contenido de los archivos Conjunto de tecnologías proporcionadas
| XML indicando qué elementos están por Open Software Foundation para
| permitidos y en qué combinaciones. Los implementar el proceso distribuido.
Glosario 405

Introducion DB2 - Version9 - Z - Español1

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Introducion DB2 - Version9 - Z - Español1

Загружено:

Авторское право:

Доступные форматы

DB2 versión 9.

Introducción a DB2 para z/OS

Capítulo 1. Visión general de DB2 y gestión de información . . . . . . . . . . . . . 1

Capítulo 2. Conceptos de DB2 . . . . . . . . . . . . . . . . . . . . . . . . . 23

© Copyright IBM Corp. 2001, 2008 iii

Capítulo 3. Arquitectura de DB2 para z/OS . . . . . . . . . . . . . . . . . . . . 53

Capítulo 4. Objetos de DB2 y sus relaciones . . . . . . . . . . . . . . . . . . . 67

Capítulo 5. SQL: lenguaje de DB2 . . . . . . . . . . . . . . . . . . . . . . . . 87

iv Introducción a DB2 para z/OS

Capítulo 6. Programación de aplicaciones para DB2 . . . . . . . . . . . . . . . 147

Capítulo 7. Implementación del diseño de base de datos . . . . . . . . . . . . . 177

Capítulo 8. Gestión del rendimiento de DB2 . . . . . . . . . . . . . . . . . . . 245

Capítulo 9. Gestión de operaciones de DB2 . . . . . . . . . . . . . . . . . . . 269

vi Introducción a DB2 para z/OS

Capítulo 10. DB2 y la web . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Capítulo 11. Acceso a datos distribuidos . . . . . . . . . . . . . . . . . . . . 309

Capítulo 12. Compartimiento de datos con los datos de DB2 . . . . . . . . . . . . 321

Recursos de información para DB2 for z/OS y productos relacionados . . . . . . . 339

Cómo obtener información de DB2 . . . . . . . . . . . . . . . . . . . . . . . 345

viii Introducción a DB2 para z/OS

Después de leer esta información, el usuario adquiere una comprensión de los

Esta información asume que el subsistema de DB2 se está ejecutando en la versión

A quién va dirigido este manual

Si va a trabajar con DB2 para z/OS y ya conoce la tarea específica que va a

Esta información se ha escrito suponiendo que la mayoría de lectores son

Conjunto de programas de utilidad de DB2

El conjunto de programas de utilidad de DB2 se ha diseñado para trabajar con el

© Copyright IBM Corp. 2001, 2008 ix

Los términos siguientes se utilizan de la forma indicada:

Características de accesibilidad para DB2 Version 9.1 for z/OS

x Introducción a DB2 para z/OS

La lista siguiente incluye las principales características de accesibilidad en

Consejo: Centro de información de Information Management Software for z/OS

Navegación mediante el teclado

Información relacionada con la accesibilidad

Consulte IBM Accessibility Center en http://www.ibm.com/able para obtener más

Cómo enviar comentarios

Acerca de esta información xi

xii Introducción a DB2 para z/OS

Una buena forma de empezar a aprender sobre un producto de software es

Además de comprender cómo las organizaciones dependen de DB2 para conseguir

Casos de ejemplo para utilizar DB2

¿Qué tienen en común las siguientes situaciones?

| Si es nuevo en DB2, quizás se pregunte cómo estas y otras organizaciones utilizan

Disponibilidad y escalabilidad para empresas grandes

© Copyright IBM Corp. 2001, 2008 1

Una disponibilidad y escalabilidad superiores en un entorno Sysplex paralelo son

Son empresas que procesan volúmenes muy grandes de transacciones que

Considere algunos ejemplos.

2 Introducción a DB2 para z/OS

Los casos de ejemplo siguientes describen cómo un banco internacional grande se

Caso de ejemplo 1: Con frecuencia se producen fusiones de bancos. Cuando dos

El compartimiento de datos de DB2 for z/OS en un entorno Sysplex paralelo

La tecnología de clúster Sysplex paralelo en DB2 es la respuesta a la disponibilidad

El diseño de compartimiento de datos de DB2 proporciona a las empresas la

| Sysplex paralelo puede crecer incrementalmente sin perjudicar el rendimiento. La

| Un componente integral de Sysplex paralelo es el recurso de acoplamiento, un

Cuando se utiliza la tecnología de Sysplex paralelo, las aplicaciones de cada banco

| DB2 trabaja estrechamente con el componente z/OS Workload Manager (WLM).

La tecnología de Sysplex paralelo está diseñada para manejar eficazmente cargas

Capítulo 1. Visión general de DB2 y gestión de información 3

El compartimiento de datos funciona con WLM para proporcionar al banco la

El compartimiento de datos y la tecnología Sysplex paralelo proporcionan al banco