Anda di halaman 1dari 395

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

4 Introducción a DB2 para z/OS


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

Capítulo 1. Visión general de DB2 y gestión de información 5


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.
Conceptos relacionados
“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.

6 Introducción a DB2 para z/OS


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.

Capítulo 1. Visión general de DB2 y gestión de información 7


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

8 Introducción a DB2 para z/OS


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 1. Visión general de DB2 y gestión de información 9


Conceptos relacionados
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.

10 Introducción a DB2 para z/OS


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 Database para Linux, UNIX y Windows
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
Conceptos relacionados
“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.

Capítulo 1. Visión general de DB2 y gestión de información 11


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
v DB2 Database para Linux, UNIX y Windows

| 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

12 Introducción a DB2 para z/OS


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

Capítulo 1. Visión general de DB2 y gestión de información 13


| 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.

14 Introducción a DB2 para z/OS


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.
Información relacionada
″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.

Capítulo 1. Visión general de DB2 y gestión de información 15


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.
Conceptos relacionados
“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

16 Introducción a DB2 para z/OS


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

Capítulo 1. Visión general de DB2 y gestión de información 17


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.
Conceptos relacionados
“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.
Conceptos relacionados
“Aplicaciones basadas en la web y WebSphere Studio Application Developer”
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.

18 Introducción a DB2 para z/OS


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.

Capítulo 1. Visión general de DB2 y gestión de información 19


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:

20 Introducción a DB2 para z/OS


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:

Capítulo 1. Visión general de DB2 y gestión de información 21


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
Conceptos relacionados
“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
almacenado” en la página 168
“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

22 Introducción a DB2 para z/OS


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.

© Copyright IBM Corp. 2001, 2008 23


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.
Conceptos relacionados
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″
Información relacionada
″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

24 Introducción a DB2 para z/OS


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.

26 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“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
Conceptos relacionados
“Creación de tablas” en la página 177
“Tipos de tablas” en la página 178

Capítulo 2. Conceptos de DB2 27


Í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.
Conceptos relacionados

28 Introducción a DB2 para z/OS


“Creación de índices” en la página 214
Referencia relacionada
″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.

Capítulo 2. Conceptos de DB2 29


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.

30 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“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.

Capítulo 2. Conceptos de DB2 31


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

32 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“Creación de vistas” en la página 231
Referencia relacionada
“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)

Capítulo 2. Conceptos de DB2 33


| Tabla 1. Calificador de esquema y propietario para objetos (continuación)
| Especificación del nombre
| para un objeto nuevo que se Calificador de esquema de
| crea objeto nuevo Propietario del objeto nuevo
| ......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
| 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 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

34 Introducción a DB2 para z/OS


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.

Capítulo 2. Conceptos de DB2 35


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.

36 Introducción a DB2 para z/OS


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.
Conceptos relacionados
″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

Capítulo 2. Conceptos de DB2 37


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

38 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“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.
Conceptos relacionados
“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.

Capítulo 2. Conceptos de DB2 39


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.
Referencia relacionada
″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.

40 Introducción a DB2 para z/OS


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.

Capítulo 2. Conceptos de DB2 41


v DB2 da soporte a conjuntos de datos de registro activo separados.
Conceptos relacionados
″Lectura de registros del archivo de registro″ (DB2 Administration Guide)
Información relacionada
″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.


Información relacionada
″Gestión del registro y del conjunto de datos del programa de arranque″ (DB2
Administration Guide)

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.

42 Introducción a DB2 para z/OS


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.

Capítulo 2. Conceptos de DB2 43


| 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.
Conceptos relacionados
“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

44 Introducción a DB2 para z/OS


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

Capítulo 2. Conceptos de DB2 45


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.
Referencia relacionada
“Tabla de departamentos (DSN8910.DEPT)” en la página 125
“Tabla de empleados (DSN8910.EMP)” en la página 127
“Tabla de actividades de proyectos (DSN8910.PROJACT)” en la página 133
Información relacionada
″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.

46 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“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

Capítulo 2. Conceptos de DB2 47


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.
Conceptos relacionados
Capítulo 6, “Programación de aplicaciones para DB2”, en la página 147

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

48 Introducción a DB2 para z/OS


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.
Conceptos relacionados
Capítulo 6, “Programación de aplicaciones para DB2”, en la página 147
“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

Capítulo 2. Conceptos de DB2 49


| 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.
Conceptos relacionados
“Creación de funciones definidas por el usuario” en la página 241
Referencia relacionada
″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.

50 Introducción a DB2 para z/OS


| 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.


Conceptos relacionados
“Utilización de un programa de aplicación como un procedimiento
almacenado” en la página 168

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.
Conceptos relacionados
Capítulo 11, “Acceso a datos distribuidos”, en la página 309

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.

Capítulo 2. Conceptos de DB2 51


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.

52 Introducción a DB2 para z/OS


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

© Copyright IBM Corp. 2001, 2008 53


| 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.

54 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“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.
Conceptos relacionados
“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.

56 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“Mecanismos de autorización y seguridad para el acceso a datos” en la página
273
Información relacionada
″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.
Información relacionada

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.

Capítulo 3. Arquitectura de DB2 para z/OS 57


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.

58 Introducción a DB2 para z/OS


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

Capítulo 3. Arquitectura de DB2 para z/OS 59


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.

60 Introducción a DB2 para z/OS


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.

Capítulo 3. Arquitectura de DB2 para z/OS 61


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.

62 Introducción a DB2 para z/OS


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.
Conceptos relacionados
Capítulo 11, “Acceso a datos distribuidos”, en la página 309
Información relacionada
″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.

Capítulo 3. Arquitectura de DB2 para z/OS 63


| 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.
Conceptos relacionados

64 Introducción a DB2 para z/OS


Capítulo 12, “Compartimiento de datos con los datos de DB2”, en la página 321
Información relacionada
″Compartimiento de datos″ (DB2 Data Sharing: Planning and Administration)

Capítulo 3. Arquitectura de DB2 para z/OS 65


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.
Conceptos relacionados
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.
Conceptos relacionados
“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
© Copyright IBM Corp. 2001, 2008 67
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

68 Introducción a DB2 para z/OS


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.


Conceptos relacionados
“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

70 Introducción a DB2 para z/OS


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

Capítulo 4. Objetos de DB2 y sus relaciones 71


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.
Referencia relacionada
“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.
Conceptos relacionados
“Entidades para diferentes tipos de relaciones” en la página 71

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

72 Introducción a DB2 para z/OS


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.
Capítulo 4. Objetos de DB2 y sus relaciones 73
| 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.
Conceptos relacionados
“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:

74 Introducción a DB2 para z/OS


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.
Conceptos relacionados
Capítulo 7, “Implementación del diseño de base de datos”, en la página 177

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.

Capítulo 4. Objetos de DB2 y sus relaciones 75


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

Conceptos relacionados
“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.

76 Introducción a DB2 para z/OS


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

Conceptos relacionados
“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

Capítulo 4. Objetos de DB2 y sus relaciones 77


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.

78 Introducción a DB2 para z/OS


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.

Capítulo 4. Objetos de DB2 y sus relaciones 79


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.

80 Introducción a DB2 para z/OS


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,

Capítulo 4. Objetos de DB2 y sus relaciones 81


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.
Conceptos relacionados
“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.
Conceptos relacionados
“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

82 Introducción a DB2 para z/OS


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.

Capítulo 4. Objetos de DB2 y sus relaciones 83


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.
Conceptos relacionados
“Normalización para evitar redundancias” en la página 75

84 Introducción a DB2 para z/OS


“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.
Conceptos relacionados
“Mecanismos de autorización y seguridad para el acceso a datos” en la página
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.

Capítulo 4. Objetos de DB2 y sus relaciones 85


| 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.

86 Introducción a DB2 para z/OS


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.
Conceptos relacionados
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

© Copyright IBM Corp. 2001, 2008 87


| 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;

La tabla de resultados es similar a la siguiente:


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:

88 Introducción a DB2 para z/OS


SELECT EMPNO, (SALARY + COMM)
FROM EMP;

La tabla de resultados es similar a la siguiente:


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;

La tabla de resultados es similar a la siguiente:


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;

La tabla de resultados es similar a la siguiente:


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;

La tabla de resultados es similar a la siguiente:


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.
Conceptos relacionados
“Modos de filtrar el número de filas devueltas” en la página 97
“Valores nulos” en la página 99
Capítulo 6, “Programación de aplicaciones para DB2”, en la página 147
“Modos de ordenar filas” en la página 104
Referencia relacionada
″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.

90 Introducción a DB2 para z/OS


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;
Referencia relacionada
″Sentencia select″ (Consulta de DB2 SQL)

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.

Ejemplo: Considere esta consulta:


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.
Referencia relacionada
″Sentencia select″ (Consulta de DB2 SQL)
″CONCAT″ (Consulta de DB2 SQL)

Capítulo 5. SQL: lenguaje de DB2 91


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.

Ejemplo: Considere esta consulta:


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

La tabla de resultados es similar a la siguiente:


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;

La tabla de resultados es similar a la siguiente:


DEPT EMPNO SALARY COMM
==== ====== ======== =======
A00 000010 52750.00 4220.00
A00 200010 46500.00 4220.00
Conceptos relacionados
“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.

92 Introducción a DB2 para z/OS


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.
Referencia relacionada
″DECIMAL o DEC″ (Consulta de DB2 SQL)

Capítulo 5. SQL: lenguaje de DB2 93


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';

La tabla de resultados es similar a la siguiente:


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;

| La tabla de resultados es similar a la siguiente:


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

94 Introducción a DB2 para z/OS


| 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;

| La tabla de resultados es similar a la siguiente:


| 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.
Referencia relacionada
″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';

La tabla de resultados es similar a la siguiente:


=====
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';

Capítulo 5. SQL: lenguaje de DB2 95


La tabla de resultados es similar a la siguiente:
=======
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';

La tabla de resultados es similar a la siguiente:


====
2002
Conceptos relacionados
“Tipos de datos de fecha, hora e indicaciones de fecha y hora” en la página 188
Referencia relacionada
″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.
Conceptos relacionados
“Creación de funciones definidas por el usuario” en la página 241
Referencia relacionada
″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.

96 Introducción a DB2 para z/OS


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';

La tabla de resultados es similar a la siguiente:


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.
Referencia relacionada
″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.

Capítulo 5. SQL: lenguaje de DB2 97


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.
|

98 Introducción a DB2 para z/OS


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:

Capítulo 5. SQL: lenguaje de DB2 99


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')

100 Introducción a DB2 para z/OS


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:
SELECT DEPTNO, DEPTNAME
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:

Capítulo 5. SQL: lenguaje de DB2 101


SELECT DEPTNO, DEPTNAME
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’.
Conceptos relacionados
“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.

102 Introducción a DB2 para z/OS


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.

Capítulo 5. SQL: lenguaje de DB2 103


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.
Referencia relacionada
″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.

104 Introducción a DB2 para z/OS


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.
Referencia relacionada
″Cláusula order by″ (Consulta de DB2 SQL)

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;

La tabla de resultados es similar a la siguiente:


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.
Referencia relacionada
″Cláusula order by″ (Consulta de DB2 SQL)

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;

La tabla de resultados es similar a la siguiente:


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

Capítulo 5. SQL: lenguaje de DB2 105


″Cláusula order by″ (Consulta de DB2 SQL)

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.

Ejemplo: Considere esta consulta:


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

La tabla de resultados es similar a la siguiente:


JOB EDL LASTNAME
==== === ==========
PRES 18 HAAS
SLS 14 CONNOR
SLS 18 HEMMMINGER
Referencia relacionada
″Cláusula order by″ (Consulta de DB2 SQL)

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;

La tabla de resultados es similar a la siguiente:


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
Referencia relacionada
″Cláusula order by″ (Consulta de DB2 SQL)

Modos de resumir valores de grupo


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

106 Introducción a DB2 para z/OS


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;

La tabla de resultados es similar a la siguiente:


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);
Referencia relacionada
″Cláusula group by″ (Consulta de DB2 SQL)

Capítulo 5. SQL: lenguaje de DB2 107


″Cláusula order by″ (Consulta de DB2 SQL)
″Sentencia select″ (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

La tabla de resultados es similar a la siguiente:


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:

108 Introducción a DB2 para z/OS


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

La tabla de resultados es similar a la siguiente:


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’.
Referencia relacionada
″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.

Ejemplo: Considere esta consulta:


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

La tabla de resultados es similar a la siguiente:


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):

Capítulo 5. SQL: lenguaje de DB2 109


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;

La tabla de resultados es similar a la siguiente:


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.
Conceptos relacionados
“Modos de resumir valores de grupo” en la página 106
Referencia relacionada
″Cláusula having″ (Consulta de DB2 SQL)
″Cláusula where″ (Consulta de DB2 SQL)
″Sentencia select″ (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:

110 Introducción a DB2 para z/OS


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.

Capítulo 5. SQL: lenguaje de DB2 111


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.
Referencia relacionada
″Sentencia select″ (Consulta de DB2 SQL)

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:

112 Introducción a DB2 para z/OS


SELECT PART, SUPPLIER, PARTS.PROD#, PRODUCT
FROM PARTS, PRODUCTS
WHERE PARTS.PROD# = PRODUCTS.PROD#;
SELECT PART, SUPPLIER, PARTS.PROD#, PRODUCT
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.

Ejemplo: Considere esta consulta:


SELECT PART, SUPPLIER, PARTS.PROD#, PRODUCT
FROM PARTS INNER JOIN PRODUCTS
ON 1=1;

El número de filas de la tabla de resultados es el producto del número de filas


de cada tabla:
PART SUPPLIER PROD# PRODUCT
======= ============ ===== ===========
WIRE ACWF 10 SCREWDRIVER
WIRE ACWF 10 RELAY
WIRE ACWF 10 SAW
WIRE ACWF 10 GENERATOR
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:

Capítulo 5. SQL: lenguaje de DB2 113


SELECT PART, SUPPLIER, PARTS.PROD#, PRODUCT
FROM PARTS INNER JOIN PRODUCTS
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:
PART SUPPLIER PROD# PRODUCT
======= ============ ===== =========
MAGNETS BATEMAN 10 GENERATOR
PLASTIC PLASTIK_CORP 30 RELAY

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.

La tabla de resultados es similar a la siguiente:


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.
Conceptos relacionados
“Subconsultas” en la página 117
“Modos de acceder a datos” en la página 87
Referencia relacionada
″Sentencia select″ (Consulta de DB2 SQL)

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:

114 Introducción a DB2 para z/OS


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

La tabla de resultados es similar a la siguiente:


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.
Conceptos relacionados
“Subconsultas” en la página 117
Referencia relacionada
″Sentencia select″ (Consulta de DB2 SQL)

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;

La tabla de resultados es similar a la siguiente:


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.

Capítulo 5. SQL: lenguaje de DB2 115


Referencia relacionada
″Sentencia select″ (Consulta de DB2 SQL)

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:
SELECT PART, SUPPLIER, PARTS.PROD#, PRODUCT
FROM PARTS FULL OUTER JOIN PRODUCTS
ON PARTS.PROD# = PRODUCTS.PROD#;

La tabla de resultados es similar a la siguiente:


PART SUPPLIER PROD# PRODUCT
======== ============ ===== ===========
WIRE ACWF 10 GENERATOR
MAGNETS BATEMAN 10 GENERATOR
OIL WESTERN_CHEM 160 -----------
BLADES ACE_STEEL 205 SAW
PLASTIC PLASTIK_CORP 30 RELAY
------- ------------ ----- 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
ON PARTS.PROD# = PRODUCTS.PROD#;

Esta sentencia produce el resultado siguiente:


PART SUPPLIER PRODNUM PRODUCT
======= ============ ======= ===========
WIRE ACWF 10 GENERATOR
MAGNETS BATEMAN 10 GENERATOR
OIL WESTERN_CHEM 160 -----------
BLADES ACE_STEEL 205 SAW
PLASTIC PLASTIK_CORP 30 RELAY
------- ------------ 505 SCREWDRIVER

116 Introducción a DB2 para z/OS


La cláusula AS, AS PRODNUM, proporciona un nombre para el resultado de la
función COALESCE.
Referencia relacionada
″Sentencia select″ (Consulta de DB2 SQL)

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:
SELECT EMPNO, LASTNAME, COMM
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

Capítulo 5. SQL: lenguaje de DB2 117


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:
SELECT EMPNO, LASTNAME, COMM
FROM EMP
WHERE EMPNO IN
('000140', '000030');
La tabla de resultados es similar a la siguiente:
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;
Conceptos relacionados
“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.

118 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“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

Capítulo 5. SQL: lenguaje de DB2 119


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.
Conceptos relacionados
Capítulo 6, “Programación de aplicaciones para DB2”, en la página 147
Referencia relacionada
″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';
Referencia relacionada
″UPDATE″ (Consulta de DB2 SQL)
″MERGE″ (Consulta de DB2 SQL)
″Cláusula where″ (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
WHERE EMPNO = '000060';

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

120 Introducción a DB2 para z/OS


″Cláusula where″ (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.
Conceptos relacionados
″Diferencias entre SQL estático y dinámico″ (DB2 Application Programming and
SQL Guide)
Referencia relacionada
″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.
Conceptos relacionados
″Diferencias entre SQL estático y dinámico″ (DB2 Application Programming and
SQL Guide)
Referencia relacionada
″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.
Referencia relacionada
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.

Capítulo 5. SQL: lenguaje de DB2 121


En general, las aplicaciones de Java utilizan SQLJ para SQL estático y utilizan
JDBC para SQL dinámico.
Conceptos relacionados
“Utilización de Java para ejecutar SQL estático y dinámico” en la página 165
Información relacionada
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:

122 Introducción a DB2 para z/OS


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.

Capítulo 5. SQL: lenguaje de DB2 123


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.
Información relacionada
″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:

124 Introducción a DB2 para z/OS


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;

Capítulo 5. SQL: lenguaje de DB2 125


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
Columna columna Descripción
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
Nombre En la columna Tipo de índice
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 ----------------

126 Introducción a DB2 para z/OS


La columna LOCATION contiene valores nulos hasta que el trabajo de ejemplo
DSNTEJ6 actualiza esta columna con el nombre de ubicación.

Relación con otras tablas

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
Columna columna Descripción
1 EMPNO Número de empleado (clave primaria)

Capítulo 5. SQL: lenguaje de DB2 127


Tabla 11. Columnas de la tabla de empleados (continuación)
Nombre de
Columna columna Descripción
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
Nombre En la columna Tipo de índice
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

128 Introducción a DB2 para z/OS


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

Capítulo 5. SQL: lenguaje de DB2 129


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

Relación con otras tablas

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
(EMPNO CHAR(06) NOT NULL,
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;

130 Introducción a DB2 para z/OS


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
STORES DSN8910.EMP_PHOTO_RESUME
COLUMN PSEG_PHOTO;

CREATE AUX TABLE DSN8910.AUX_EMP_RESUME


IN DSN8D91L.DSN8S91N
STORES DSN8910.EMP_PHOTO_RESUME
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
Nombre En la columna Tipo de índice
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

Capítulo 5. SQL: lenguaje de DB2 131


Relación con otras tablas

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))
IN DSN8D91A.DSN8S91P
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
Columna Nombre de columna Descripción
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

132 Introducción a DB2 para z/OS


La tabla siguiente muestra los índices para la tabla de proyectos:
Tabla 19. Índices de la tabla de proyectos
Nombre En la columna Tipo de índice
DSN8910.XPROJ1 PROJNO Primario, ascendente
DSN8910.XPROJ2 RESPEMP Ascendente

Relación con otras tablas

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)
IN DSN8D91A.DSN8S91P
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
Columna columna Descripción
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

Capítulo 5. SQL: lenguaje de DB2 133


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

Relación con otras tablas

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

Referencia relacionada
“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
(EMPNO CHAR(6) NOT NULL,
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)
IN DSN8D91A.DSN8S91P
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
Columna Nombre de columna Descripción
1 EMPNO Número de ID del empleado
2 PROJNO ID de proyecto del proyecto

134 Introducción a DB2 para z/OS


Tabla 22. Columnas de la tabla de empleados de actividades de proyectos (continuación)
Columna Nombre de columna Descripció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

Relación con otras tablas

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.
Referencia relacionada
“Tabla de actividades de proyectos (DSN8910.PROJACT)” en la página 133
“Tabla de empleados (DSN8910.EMP)” en la página 127

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
Columna Nombre de columna Descripción
1 LOWER_A_TO_Z Matriz de caracteres, de ’a’ a ’z’

Capítulo 5. SQL: lenguaje de DB2 135


Tabla 24. Columnas de la tabla de ejemplo Unicode (continuación)
Columna Nombre de columna Descripció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.

Relación con otras tablas

Esta tabla no tiene ninguna relación con otras tablas.


Información relacionada
″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

Referencia relacionada
“Tabla de actividades (DSN8910.ACT)” en la página 124
“Tabla de departamentos (DSN8910.DEPT)” en la página 125

136 Introducción a DB2 para z/OS


“Tabla de empleados (DSN8910.EMP)” en la página 127
“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 actividades de proyectos (DSN8910.PROJACT)” en la página 133
“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

Capítulo 5. SQL: lenguaje de DB2 137


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 ;

138 Introducción a DB2 para z/OS


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.DEPTNO,D2.DEPTNAME,D2.MGRNO,D2.FIRSTNME,D2.MIDINIT,
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.DEPTNO,D1.DEPTNAME,D1.MGRNO,D1.FIRSTNME,D1.MIDINIT,
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.

Capítulo 5. SQL: lenguaje de DB2 139


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.PROJNO,P2.PROJNAME,P2.RESPEMP,P2.FIRSTNME,P2.MIDINIT,
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.PROJNO,P1.PROJNAME,P1.RESPEMP,P1.FIRSTNME,P1.MIDINIT,
P1.LASTNAME,
P1.PROJNO,P1.PROJNAME,P1.RESPEMP,P1.FIRSTNME,P1.MIDINIT,
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

140 Introducción a DB2 para z/OS


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.

Capítulo 5. SQL: lenguaje de DB2 141


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;
|
142 Introducción a DB2 para z/OS
| 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
USING STOGROUP DSN8G910
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)
LOCKSIZE PAGE LOCKMAX SYSTEM
BUFFERPOOL BP0
CLOSE NO
COMPRESS YES
CCSID EBCDIC;
CREATE TABLESPACE DSN8S91B
IN DSN8D91L
USING STOGROUP DSN8G910
PRIQTY 20
SECQTY 20
ERASE NO
LOCKSIZE PAGE
LOCKMAX SYSTEM
BUFFERPOOL BP0
CLOSE NO
CCSID EBCDIC;

Capítulo 5. SQL: lenguaje de DB2 143


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
USING STOGROUP DSN8G910
PRIQTY 160
SECQTY 80
SEGSIZE 4
LOCKSIZE TABLE
BUFFERPOOL BP0
CLOSE NO
CCSID EBCDIC;

CREATE TABLESPACE DSN8S91P


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

144 Introducción a DB2 para z/OS


PRIQTY 5
SECQTY 5
ERASE NO
LOCKSIZE PAGE LOCKMAX SYSTEM
BUFFERPOOL BP0
CLOSE NO
CCSID UNICODE;

Capítulo 5. SQL: lenguaje de DB2 145


146 Introducción a DB2 para z/OS
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

© Copyright IBM Corp. 2001, 2008 147


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.
Conceptos relacionados
“Utilización de DB2 Developer Workbench para crear un procedimiento
almacenado” en la página 173

WebSphere Studio Application Developer


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.
Conceptos relacionados
“Aplicaciones basadas en la web y WebSphere Studio Application Developer”
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.

148 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“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.
Conceptos relacionados
“Aplicaciones de SQL estático” en la página 154
“Aplicaciones de SQL dinámico” en la página 162
“Utilización de ODBC para ejecutar SQL dinámico” en la página 164
“Utilización de Java para ejecutar SQL estático y dinámico” en la página 165
“Utilización de un programa de aplicación como un procedimiento
almacenado” en la página 168
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.

150 Introducción a DB2 para z/OS


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

Capítulo 6. Programación de aplicaciones para DB2 151


ú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.

152 Introducción a DB2 para z/OS


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

Capítulo 6. Programación de aplicaciones para DB2 153


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.

154 Introducción a DB2 para z/OS


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.


Conceptos relacionados
“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

Capítulo 6. Programación de aplicaciones para DB2 155


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.
Referencia relacionada
″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.

156 Introducción a DB2 para z/OS


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
WHERE EMPNO = :EMPID
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.
Conceptos relacionados
“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)
Referencia relacionada
″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.
Capítulo 6. Programación de aplicaciones para DB2 157
EXEC SQL
SQL FETCH FIRST ROWSET FROM C1 FOR 5 ROWS
INTO :COL1 :COL1IND
END-EXEC.
Conceptos relacionados
″Variables de lenguaje principal, matrices de variables de lenguaje principal y
estructuras″ (DB2 Application Programming and SQL Guide)

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
WHERE EMPNO = :EMPID
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
WHERE EMPNO = :EMPID
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.
Conceptos relacionados
″Variables de lenguaje principal, matrices de variables de lenguaje principal y
estructuras″ (DB2 Application Programming and SQL Guide)

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.

158 Introducción a DB2 para z/OS


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.

Capítulo 6. Programación de aplicaciones para DB2 159


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.

160 Introducción a DB2 para z/OS


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.
Referencia relacionada
″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.

Capítulo 6. Programación de aplicaciones para DB2 161


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.
Referencia relacionada
″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.
Conceptos relacionados
“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.

162 Introducción a DB2 para z/OS


Conceptos relacionados
“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
“Utilización de ODBC para ejecutar SQL dinámico” en la página 164
“Utilización de Java para ejecutar SQL estático y dinámico” en la página 165
″SQL dinámico″ (DB2 Application Programming and SQL Guide)
Referencia relacionada
″SQL dinámico″ (Consulta de DB2 SQL)

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");
/*********************************************************/

Capítulo 6. Programación de aplicaciones para DB2 163


/* Aplicar PREPARE y EXECUTE a la sentencia */
/*********************************************************/
EXEC SQL PREPARE OBJSTMT FROM :stmt;
EXEC SQL EXECUTE OBJSTMT;
Conceptos relacionados
“Utilización de ODBC para ejecutar SQL dinámico”
″SQL dinámico″ (DB2 Application Programming and SQL Guide)
Referencia relacionada
″SQL dinámico″ (Consulta de DB2 SQL)

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,

164 Introducción a DB2 para z/OS


sizeof(bktitle),
&bktitle_len);
if( rc != SQL_SUCCESS ) goto dberror;

rc = SQLExecDirect( hStmt,
"SELECT TYPE FROM BOOK_TYPES WHERE TITLE=?"
SQL_NTS );
if( rc != SQL_SUCCESS ) goto dberror;

rc = SQLBindCol( hStmt,
1,
SQL_C_CHAR,
book_type,
sizeof(book_type),
&book_type_len);
if( rc != SQL_SUCCESS ) goto dberror;

rc = SQLFetch( hStmt );
if( rc != SQL_SUCCESS ) goto dberror;

rc = SQLCloseCursor( hStmt );
if( rc != SQL_SUCCESS ) goto dberror;
/*********************************************************/
/* 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 );


if( rc != SQL_SUCCESS ) goto dberror;

rc = SQLExecute( hStmt );
if( rc != SQL_SUCCESS ) goto dberror;

rc = SQLEndTran( SQL_HANDLE_DBC, hDbc, SQL_COMMIT );


if( rc != SQL_SUCCESS ) goto dberror;
Conceptos relacionados
“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

Capítulo 6. Programación de aplicaciones para DB2 165


– 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:

166 Introducción a DB2 para z/OS


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.
Conceptos relacionados
Capítulo 7, “Implementación del diseño de base de datos”, en la página 177
Información relacionada
″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 */

Capítulo 6. Programación de aplicaciones para DB2 167


| /*********************************************************/
| 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 relacionados
“Conceptos sobre programación de SQL dinámico” en la página 163
“Utilización de ODBC para ejecutar SQL dinámico” en la página 164
Información relacionada
″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.

168 Introducción a DB2 para z/OS


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.
Conceptos relacionados
″Procedimientos almacenados″ (DB2 Application Programming and SQL Guide)
Referencia relacionada
″Procedimientos almacenados″ (Consulta de DB2 SQL)
Información relacionada
″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.
Conceptos relacionados
“Utilización de Java para ejecutar SQL estático y dinámico” en la página 165
“Utilización del lenguaje de procedimiento de SQL para crear un procedimiento
almacenado” en la página 172

Capítulo 6. Programación de aplicaciones para DB2 169


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.

170 Introducción a DB2 para z/OS


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.

Conceptos relacionados
″Procedimientos almacenados″ (DB2 Application Programming and SQL Guide)

Capítulo 6. Programación de aplicaciones para DB2 171


Referencia relacionada
″Procedimientos almacenados″ (Consulta de DB2 SQL)
Información relacionada
″Implementación de procedimientos almacenados de DB2″ (DB2 Administration
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).
Conceptos relacionados
″Procedimientos almacenados″ (DB2 Application Programming and SQL Guide)
Referencia relacionada
″Procedimientos almacenados″ (Consulta de DB2 SQL)
Información relacionada

172 Introducción a DB2 para z/OS


″Implementación de procedimientos almacenados de DB2″ (DB2 Administration
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)

Capítulo 6. Programación de aplicaciones para DB2 173


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.
Información relacionada
″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.

174 Introducción a DB2 para z/OS


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.
Conceptos relacionados
″Ejemplo de un procedimiento almacenado simple″ (DB2 Application
Programming and SQL Guide)

Capítulo 6. Programación de aplicaciones para DB2 175


176 Introducción a DB2 para z/OS
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.
Conceptos relacionados
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

© Copyright IBM Corp. 2001, 2008 177


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.
Conceptos relacionados
Capítulo 4, “Objetos de DB2 y sus relaciones”, en la página 67
“Mecanismos de autorización y seguridad para el acceso a datos” en la página
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

178 Introducción a DB2 para z/OS


| 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.
Conceptos relacionados
“Creación de tablas de consultas materializadas” en la página 182
“Creación de objetos grandes” en la página 233
Referencia relacionada
“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
(EMPNO CHAR(6) NOT NULL,
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.


Conceptos relacionados
“Definición de columnas de una tabla” en la página 183
Referencia relacionada
″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

180 Introducción a DB2 para z/OS


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));

Capítulo 7. Implementación del diseño de base de datos 181


| 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.
Conceptos relacionados
″Tablas temporales″ (DB2 Application Programming and SQL Guide)
Referencia relacionada
″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.
Información relacionada
″Creación de tablas de consultas materializadas″ (DB2 Administration Guide)

182 Introducción a DB2 para z/OS


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'));
Conceptos relacionados
“Í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

Capítulo 7. Implementación del diseño de base de datos 183


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.
Conceptos relacionados
“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

184 Introducción a DB2 para z/OS


| 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

Capítulo 7. Implementación del diseño de base de datos 185


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.
Conceptos relacionados
“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.

186 Introducción a DB2 para z/OS


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.
|

Capítulo 7. Implementación del diseño de base de datos 187


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.

188 Introducción a DB2 para z/OS


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.

Capítulo 7. Implementación del diseño de base de datos 189


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.
Conceptos relacionados
“Creación de objetos grandes” en la página 233
Referencia relacionada
″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.

190 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“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.

Capítulo 7. Implementación del diseño de base de datos 191


| 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.
Conceptos relacionados
“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;

192 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“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

Capítulo 7. Implementación del diseño de base de datos 193


| 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.


Conceptos relacionados
“Mecanismos de autorización y seguridad para el acceso a datos” en la página
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

194 Introducción a DB2 para z/OS


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

Capítulo 7. Implementación del diseño de base de datos 195


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.

196 Introducción a DB2 para z/OS


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.
Conceptos relacionados
“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

Capítulo 7. Implementación del diseño de base de datos 197


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.
Conceptos relacionados
“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.

198 Introducción a DB2 para z/OS


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.

Capítulo 7. Implementación del diseño de base de datos 199


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.
Conceptos relacionados
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

200 Introducción a DB2 para z/OS


“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″
Administration Guide)
″Ejemplos de definiciones de espacio de tabla″ (DB2 Administration Guide)
Referencia relacionada
| ″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.

Capítulo 7. Implementación del diseño de base de datos 201


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.
Conceptos relacionados
Capítulo 12, “Compartimiento de datos con los datos de DB2”, en la página 321
“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
| ″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″ (DB2
Administration Guide)
″Ejemplos de definiciones de espacio de tabla″ (DB2 Administration Guide)

202 Introducción a DB2 para z/OS


Tareas relacionadas
| ″CREATE TABLESPACE″ (Consulta de DB2 SQL)
Referencia relacionada
| ″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

Conceptos relacionados
| ″Cómo crear un espacio de tabla explícitamente″ (DB2 Administration Guide)
Referencia relacionada
| ″CREATE TABLESPACE″ (Consulta de DB2 SQL)
| ″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.
Conceptos relacionados

Capítulo 7. Implementación del diseño de base de datos 203


″Factores para determinar el tamaño de página de un espacio de tabla″ (DB2
Administration Guide)
″Ejemplos de definiciones de espacio de tabla″ (DB2 Administration Guide)
Tareas relacionadas
″Cómo eliminar, volver a crear o convertir un espacio de tabla″ (DB2
Administration Guide)

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.
Conceptos relacionados
| “Espacios de tabla que se segmentan exclusivamente” en la página 198
| “Espacios de tabla que se particionan exclusivamente” en la página 201
| ″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″ (DB2
Administration Guide)
″Ejemplos de definiciones de espacio de tabla″ (DB2 Administration Guide)
Referencia relacionada
| ″CREATE TABLESPACE″ (Consulta de DB2 SQL)

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.

204 Introducción a DB2 para z/OS


| 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.
Conceptos relacionados
| ″Cómo crear un espacio de tabla explícitamente″ (DB2 Administration Guide)
Referencia relacionada
| ″CREATE TABLESPACE″ (Consulta de DB2 SQL)
| ″ALTER TABLESPACE″ (Consulta de DB2 SQL)

Espacios de tablas universales particionados por rango:

Capítulo 7. Implementación del diseño de base de datos 205


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.
Conceptos relacionados
| ″Cómo crear un espacio de tabla explícitamente″ (DB2 Administration Guide)
Referencia relacionada
| ″CREATE TABLESPACE″ (Consulta de DB2 SQL)

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

206 Introducción a DB2 para z/OS


| 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.
Conceptos relacionados
“Creación de objetos grandes” en la página 233
| ″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″ (DB2
Administration Guide)
″Ejemplos de definiciones de espacio de tabla″ (DB2 Administration Guide)
″Factores para determinar el tamaño de página de un espacio de tabla LOB″
(DB2 Administration Guide)
Referencia relacionada
| ″CREATE TABLESPACE″ (Consulta de DB2 SQL)

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.
Conceptos relacionados

Capítulo 7. Implementación del diseño de base de datos 207


| ″Cómo DB2 crea implícitamente un espacio de tabla XML″ (DB2 Administration
| Guide)
″Factores para determinar el tamaño de página de un espacio de tabla″ (DB2
Administration Guide)
″Ejemplos de definiciones de espacio de tabla″ (DB2 Administration Guide)
Referencia relacionada
| ″CREATE TABLESPACE″ (Consulta de DB2 SQL)

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.

208 Introducción a DB2 para z/OS


| 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.

Capítulo 7. Implementación del diseño de base de datos 209


| 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
|

210 Introducción a DB2 para z/OS


Í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
Partición 1 MIN_NODEID
XMLDATA
Columnas:
Tabla XML DOCID
Partición 2 MIN_NODEID
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.

Capítulo 7. Implementación del diseño de base de datos 211


| 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.

212 Introducción a DB2 para z/OS


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

Capítulo 7. Implementación del diseño de base de datos 213


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.
Conceptos relacionados
“Grupos de almacenamiento de DB2” en la página 36
″Factores para determinar el tamaño de página de un espacio de tabla″ (DB2
Administration Guide)
Referencia relacionada
″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

214 Introducción a DB2 para z/OS


| 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
| v Índices comprimidos
|| 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
| v Índices comprimidos

Capítulo 7. Implementación del diseño de base de datos 215


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.

216 Introducción a DB2 para z/OS


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'

Capítulo 7. Implementación del diseño de base de datos 217


Esta sentencia SELECT puede ejecutarse más eficazmente si se definen índices
separados en PROJNO y STDATE.
Conceptos relacionados
“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.
Conceptos relacionados
“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.

218 Introducción a DB2 para z/OS


Í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.

Capítulo 7. Implementación del diseño de base de datos 219


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.
Referencia relacionada
″CREATE INDEX″ (Consulta de DB2 SQL)

Í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.
Referencia relacionada
″CREATE INDEX″ (Consulta de DB2 SQL)

Í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

220 Introducción a DB2 para z/OS


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.

Capítulo 7. Implementación del diseño de base de datos 221


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.
Referencia relacionada
“Tabla de empleados (DSN8910.EMP)” en la página 127
″CREATE INDEX″ (Consulta de DB2 SQL)

Í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.

222 Introducción a DB2 para z/OS


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.
Referencia relacionada
″CREATE INDEX″ (Consulta de DB2 SQL)

| Í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
| ″CREATE INDEX″ (Consulta de DB2 SQL)

| 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 ut