DB2 de IBM (International Business Machines)

Tabla de contenido
INTRODUCCION
Muchos expertos de la industria y usuarios han elogiado las nuevas herramientas que IBM desarrollo para
facilitar la administración y uso de DB2 Universal Database, constituido en base a dos productos incluidos en
el DB2 de AIX en 1994: el DB2 Common Server, que para propósitos generales incluía funciones avanzadas
para el mercado de servidores de bases de datos con soporte de hardware SMP y OLTP; y el DB2 Parallel
Edition, que fue desarrollado para soportar aplicaciones de gran escala, como el Data Warehousing y Data
Minino y aplicaciones de negocios a nivel mundial como la SAP, People Soft y Baan.
DB2 incluye todo lo necesario para implementar una solución de replicación de datos en cualquier tipo fr
ambiente distribuido o heterogéneo, pues permite enviar los datos a cualquier sitio para cubrir todos los
requerimientos de una empresa, desde oficinas centrales a sucursales, usuarios móviles, proveedores, clientes
y socios de negocios.
Gracias a su alcance global y de bajo costo, Internet puede ser una solución de negocios muy poderosa para
realizar operaciones comerciales garantizando un nivel de seguridad y confiabilidad con sus servicios de
autorización y autenticación integrados a redes y sistema operativos, soportando el network−computing
utilizando Java y JDBC, incluyendo capacidad nativa de almacenar varios tipos de datos: alfanuméricos,
video, imagen, audio y los definidos por el usuario.
Tanto estas capacidades, un poco de su historia y sus comandos internos es lo desarrollado a continuación.
IBM® DB2® Base de datos Universal de Gira Rápida
DB2® el Banco de datos Universal Versión 7.1 es el sistema de dirección de base de datos correlativo
habilitado. Es escalable de los procesadores a los multiprocesadores simétricos a los racimos masivamente
paralelos. DB2 la Base de datos Universal ofrece la capacidad multimedia con la imagen, audio, el video, el
texto, el objeto avanzado espacial, y otro el apoyo correlativo. Con Versión 7.1, DB2 el Banco de datos
Universal ofrece un gran apoyo para los negocios a través de Java!, XML, y las soluciones móviles así como
nuevo apoyo para las soluciones de inteligencias comerciales.
Cada nueva versión de DB2 construye en la fundación fuerte del descargo anterior. Con Versión 7.1, DB2 el
Banco de datos Universal entrega el apoyo más poderoso para inteligencia comercial, dirección de los datos, y
soluciones de negocio. También es incluido el fuerte apoyo por Microsoft® los Windows® 32−bits de
sistemas operativos y la compatibilidad agregada por la familia de DB2.
1
El XML Soporte Extendido
DB2 le permite ahora guardar el Idioma de Encarecimiento extendido (XML) los documentos como un nuevo
datos de la columna. Se puede descomponer y puede guardar XML en su componente parte así como la
búsqueda en los campos descompuestos de un documento de XML. Esta función combinó con los
perfeccionamientos a Net.Data® le proporcionan una manera más simple de intercambiar y guardar los
documentos electrónicamente.
Los Perfeccionamientos de Net.Data
Net.Data que conecta las aplicaciones de Tejido a DB2 ha construido ahora en la explotación de XML. Esto le
permite generar las etiquetas de XML como el rendimiento de su macro de Net.Data, en lugar de entrar en las
etiquetas a mano. Se puede especificar un XML estilo hoja (XSL) para ser usado al estructurar y desplegar el
rendimiento generado.
Inteligencia Comercial
El poder de IBM se han unido el Almacén Visual y la simplicidad del DB2 para mantener una sola y nueva
interfase del usuario (clientes) de inteligencias comerciales. Se puede acostumbrar el Centro de Almacén de
Datos a definir y automatizar el extracto de los datos, transformación, la distribución, y la carga de proceso
para los almacenes de los datos. La visualización y manipulación de datos y metadata son hechos más simples
con los nuevos wizard. Estos wizard ayudan a construir marcas con asterisco en esquemas y archivos de texto
de importación. Ellos también proporcionan SQL Assist mejorado en los rasgos y la nueva visualización de
flujo de mando. El Centro de Almacén de Datos también influye en el poder de la repetición de los datos
integrada de IBM, mientras proporciona mayor flexibilidad
configurando los guiones de movimiento de datos.
El log cerrado después del backup
Después de que un backup en línea está completo, DB2 obligará a cerrar el log actualmente activo, y como
resultado se archivará fuera de. Esto asegura que su disco auxiliar en línea tiene un juego completo de logs
archivados y disponibles para la recuperación.
Requerimiento de Log de archivo de soporte
Usted puede obligar el log actualmente activo al cierre y puede forzar que el log sea archivado. Este rasgo le
da el mando más granular a administradores de bases de datos encima de su estrategia del backup/restore.
2
Un principio fundamental de DB2 es que los datos pueden y deben residir dondequiera que tenga más sentido:
DB2 está disponible para múltiples sistemas de operaciones, incluyendo UNIX, Microsoft Windows, OS/2,
AS/400, y OS/390. Esto significa que pueden tomarse las decisiones basado en la plataforma correcta para una
porción específica de los datos.
DB2 le permite distribuir y acceder los datos por una red de sistemas. Los usuarios pueden preguntar, agregar,
anular, y poner al día los datos en las bases de datos locales y remotos.
Las copias múltiples de DB2 servidor código pueden correr adelante en la misma computadora. Esto significa
que usted puede tener los casos múltiples de DB2 que corre concurrentemente, cada uno, con una
configuración diferente y las vistas entalladas de los datos, e incluso los datos variantes.
Pueden dividirse las bases de datos de DB2 por computadoras independientes múltiples conectadas por un
LAN o por secciones. Esto le permite que divida bases de datos grandes, o sea que son demasiado grande para
que un solo servidor trabaje eficazmente. También significa que los funcionamientos pueden correr en
paralelo en las particiones de la base de datos individuales, reduciendo el tiempo de la ejecución.
Accesos de Datos
DB2 proporciona un juego de datos de acceso de las interfaces para los diferentes tipos de usuarios y
aplicaciones:
El Centro de Control es un gráfico de uso fácil para los usuarios interactivos y para los administradores de
Bases de Datos. Mantiene las herramientas de las tareas diarias para configurar el sistema, creando las tablas y
otros objetos, fijando los trabajos, y realizando el apoyo y recuperación. Usted puede ejecutar el Centro del
Control en el puesto de trabajo dónde su base de datos se localiza o en un puesto de trabajo remoto. Una solo
Centro de Control puede manejar varias bases de datos en varios puestos de trabajo.
El Centro de Almacén de Datos es una interfase gráfica que simplifica el proceso de diseñar, mientras
construye, y mantiene los almacenes de los datos.
El Procesador de Línea de Orden es una interfase texto−orientada que usted puede usar para acceder y
manipular las bases de datos del sistema, puede emitir las declaraciones de SQL y DB2 ordenando el acceso
de las bases de datos locales y remotos, y mantiene un historial de todas las demandas.
Protección de Datos
3
Proteger los datos guardados es una función esencial del sistema de una base datos. DB2 guarda sus datos
contra la pérdida, acceso desautorizado, o entradas inválidas proporcionando:
Un juego de herramientas que lo protegen contra la pérdida de datos por el evento de un hardware o fracaso
del software. Los backups o logs periódicos para restaurar una base de datos al mismo estado que tenía antes
del fallo.
Un sistema de autoridades y privilegios que protegen los datos contra el acceso desautorizado y la
modificación. La autoridad normalmente aplica al derecho de un usuario para realizar ciertos tipos de
actividades administrativas, mientras los privilegios son asociados con la habilidad del usuario para realizar
las acciones en los objetos de la base de datos.
Un medio para controlar la entrada de los datos definiendo las reglas para que los valores sean válidos para
una columna en una tabla (los constreñimiento), o cómo se relacionan columnas en uno o más tablas a la
integridad del referencial.
Una facilidad de la auditoria que genera un sendero de eventos de la base de datos. Estos archivos pueden
usarse para supervisar aplicaciones y accesos del usuario, incluso las acciones del administrador de sistema.
Esta supervisación podría llevar a los cambios en la estrategia de su protección de datos.
Administrando Bases de Datos
Usted puede realizar la administración de la DB2 desde cualquier puesto de trabajo. No le importa si su base
de datos es local o remota. Usted puede escoger un sistema de administración especializado para todas sus
Bases de Datos. Se puede administrar la BD incluso desde un navegador (Web Browser).
DB2 incluye herramientas gráficas que le permiten poner a punto la actualización, acceso a los servidores de
DB2 remotos, manejar todos los servidores de un solo sitio, desarrollar las aplicaciones, y proceso de pregunta
SQL:
El Centro de Control proporciona una manera conveniente de ocuparse de las tareas diarias de la
administración de la base de datos. El Centro de Control lleva a una vista jerárquica de todos sus sistemas, de
las bases de datos, y de los objetos de la base de datos. Esto hace que el sistema sea fácil de configurar, crea
objetos de bases de datos y supervisa las bases de datos.
El Centro de Administración por Satélite le permite administrar los DB2 Satélite servidores. DB2 la Edición
de Satélite de Bases de datos Universal es una función múltiple de alto rendimiento de DB2 para los usuarios
que están de vez en cuando conectados (móviles) y los servidores remotos desatendidos. (Tecnología portátil)
BACKUP Y RECOVERY DE BASE DE DATOS
Desarrollar una estrategia de backup y recovery
Una base de datos puede ser fuera de servicio por la causa de las fallas de hardware o software. A veces se
encuentra problemas de almacenar, interrupciones de fuente de poder, y fallas de aplicacion. A diferentes
escenarios de falla se requieren diferentes acciones de recuperacion. Se protegen los datos de las posibles
fallas con una buena estrategia de recuperacion. Unos factores que se deben contestar en el momento de
desarrollar la estrategia de recuperacion son:
• Sera recuperable o no recuperable la base de datos?
• Que tan cerca al tiempo de falla para recuperar la base de datos (punto de recuperacion)?
• Que tan frecuente para hacer el respaldo?
4
• Cuanto tiempo se tomaria para hacer la recuperacion de la base de datos?
• Cunato tiempo se tomaria para hacer el respaldo de la base de datos?
• Cunato espacio de almacenamiento es disponibles para las copias de la base de datos y los archivos de
log?
• Seria suficiente el respaldo de tablespace, o seria necesario el respaldo de la base de datos entera?
Una estrategia de recuperacion de base de datos debe asegurar que todas las informaciones son dispoinbles
cuando son requeridos para la recuperacion de base de datos. Debe incluye una horario de respaldos y, en el
caso de sistemas de base de datos distribuidos, incluye las copias de base de datos cuando los servidores o
nodos estan agregados o eliminados. La estrategia global debe tambien incluye los procedimientos para los
scripts de comando de recuperacion, aplicaciones, funciones definidas por usuario, codigo de procedimiento
almacenado en libreria de sistema de operacion.
Base de datos no recuperable retiene ambos los parametros de configuracion de logretain* y userexit*
desactivados, y puede restaurarse unicamente en modo offline* con recuperacion de version recovery. Los
datos que son faciles a recrear, se pueden guardarlos en una base de datos no recuperable, por ejemplo:
• Tablas que tienen datos para aplicaciones de solo lectura.
• Tablas que tienen poca cantidad de datos.
• Tablas grandes que tienen pocos registros, y que no se modifican frecuentemente.
Base de datos recuperable se retiene los archivos de log activos para crash recovery, y tambien retiene los
archivos de log archivados. Se restaura base de datos recuperable a su estado del momento que la imagen de
respaldo fue tomada, solamente en modo offline. Sin embargo, con rollforward recovery, se puede regresar la
base de datos a un momento especifico o al fin de los archivos de log, con los archivos de log activados y
archivados. Los datos que no se pueden recrear facilmente, debe guardar en una base de datos recuperable, por
ejemplo:
• Datos que fueron modificado por aplicaciones o usuarios finales.
• Datos que no pueden recrear, incluyen los datos que tienen su fuente destruido, y los datos que se
cargaron manualmente.
La operacion de respaldo de una base de datos recuperable se puede realizar en ambos modo offline y modo
online*, y la restauracion y la recuperacion se realizan en solo modo offline. Cuando la operacion de respaldo
a una(s) tabla(s) esta en proceso en modo online, la(s) tabla(s) tambien esta(n) disponible(s) para actualizar, y
los cambios se registran en los archivos de log. Cuando la operacion de rollforward recovery a una(s) tabla(s)
esta en proceso en modo online, la misma tabla no sera disponible para actualizar hasta la operacion esta
completa, pero usuarios no estan prevenidos de accesar a la(s) otras tabla(s).
El concepto de una respaldo de base de datos es la misma que cualquieras otras respaldos de datos: hacer una
copia de los datos y almacenar la en un medio diferente en case que se danna el original. El respaldo mas
simple es cerrar todas las conexiones a los usuario para asegurar que no habra mas transacciones, y hacer el
respaldo. Luego reconstruir la base de datos si se danna o ocure fallas a la base de datos.
Los tres tipos diferentes de recuperacion
La reconstrucion de la base de datos se conoce como recovery. Los tres tipos diferente de recuperacion son:
• Version recovery, que es la restauracion de la base de datos a la version anterior con una imagen de la
base de datos que fue creado durante la operacion de respaldo.
• Rollforward recovery, que es la reaplicacion de transacciones registradas en los archivos de log
despues que una base de datos o una tabla esta restaurada.
5
• Crash recovery, que es la recuperacion automatica de la base de datos si una falla ocurre antes de
todas las transacciones estan completas.
II − 1. Version Recovery
Version recovery es la restauracion de la base de datos de la version anterior con una imagen de la base de
datos que fue creado durante la operacion de respaldo. Se usa version recovery con una base de datos no
recuperable. En este momento, solo quedan los archivos de log activos para crash recovery. Una operacion de
restauracion reconstruira una base de datos entera al estado identico a la base de datos en el momento que se
realizo la operacion de respaldo. Sin embargo, se perderan todas las transacciones que se realizaron despues
de la operacion de resplado. Con la base de datos distribuido, es necesario hace el respaldo y restuarar la base
de datos de cada nodo separado y en el mismo momento.
II − 2. Rollforward Recovery
Rollforward recovery es la reaplicacion de transacciones registradas en los archivos de log despues que una
base de datos o una tabla esta restaurada. Para aplicar el metodo de rollforward recovery, es necesario a hacer
un respaldo de la base de datos y los archivos de log. Hay dos tipos de rollforward recovery:
•
Database rollforward recovery. En este tipo de rollforward recovery, las transacciones registradas en
archivos de log seran aplicadas despues de la operacion de la restauracion de la base de datos. Los
archivos de log registran todos los cambios a la base de datos. Este metodo recupera la base de datos a
su estado del ultimo momento antes de la falla (que es hasta el fin de los archivos de log). Con la base
de datos distribuida, si hace una rollforward recovery para regresar la base de datos a un momento
especifico, es necesario a aplicar la recuperacion a todos los nodos para asegurarse que todos los
nodos estan en el mismo nivel de estado. Si solamente para restaurar un solo nodo, se reaplican todas
las transacciones que estan registradas en archivos de log.
6
•
Tablespace rollforward recovery. Para comenzar la operacion de table space rollforward recovery, se
neceesita la imagen de la base de datos entera (que es, todas los table spaces), o uno o mas table
spaces, y tambien los archivos de log que afectan a los table spaces que se restauraran. Se puede
restaurar las tablas con los archivos de log a dos puntos:
• Fin de los archivos de log.
• Un momento particular, que se conoce como point−in−time recovery.
II − 3. Crash Recovery
Crash recovery es la recuperacion automatica de la base de datos si una falla ocurre antes de todas las
transacciones estan completas. Una falla de transaccion se provoca por un error grave o una
comdicion que termina la base de datos anormalmente. Si las transacciones estan interrumpidas, la
base de datos estaria en un estado inconsistente y inservible. Las condiciones que resultan falla de
transaccion incluyen:
♦ Una falla de fuente de poder en la maquina, que cae la base de datos.
♦ Una serie de error del sistema operativo, que cae DB2.
♦ Crash recovery es el proceso que regresa la base de datos al estado consistente con desechar
las transacciones incompletas y completar las transacciones con commit que todavia estan en
la memoria.
III. Recovery Logs y Recovery History File
Los archivos de log y los archivos de la historia de recuperacion son creados automaticamente cuando
se crea una base de datos. No se pueden modificar directamente a los archivos de log o los archivos de
la historia de recuperacion. Sin embargo, son importantes para recuperar los datos perdidos.
7
♦ Recovery logs, que se usa para recuperar de los errores de aplicacion o sistema. En
combinacion con el respaldo de base de datos, los archivos de log son usados para recuperar
el estado consistenet de un momento antes de una falla pasa a la base de datos.
♦ Recovery history file, que contiene un resumen de informaciones del respaldo, que se puede
usar para recuperar parte o toda de la base de datos a un momento especificado. Se usa para
rastrear eventos relacionados a la recuperacion, tales como las operaciones de respaldo y
restauracion.
III − 1. Recovery log
Todas bases de datos tienen los archivos de log asociados. Los logs registran cambios de base de
datos. Si una base de dato necesita ser recuperada a un punto despues el ultimo respaldo, los logs son
requeridos para realizar la recuperacion. Los logs de DB2 tienen dos tipos de comportamiento:
♦ Circular logging, es el comportamiento default cuando se crea una nueva base de datos.
Como su nombre, circular logging usa un anillo de logs activos* en linea para registrar los
cambios de base de datos para realizar una crash recovery, pero no se permite una rollforward
recovery. Con este tipo de logs, la recuperacion de base de datos que puede realizar un
usuario es version recovery. Todas las transacciones que se han realizaos entre el ultimo
respaldo y el punto de falla de sistema, se perderan.
♦ Archived logs, son logs cerrados y guardados, y son usados especificamente para rollforward
recovery. Pueden ser uno de los dos siguiente tipos:
Offline archived logs, que no
datos.
Online archived logs, que son guardados en el directorio de la base de datos.
III − 2. Recovery history file
8
Un RHF (Recovery History File) es creado con cada base de datos, y se actualiza automaticamente
cuando hay:
♦ Respaldo de una base de datos o un tablespace
♦ Recuperacion de una base de datos o un tablespace
♦ Roll forward de una base de datos o un tablespace
♦ Alter un tablespace
♦ Renombrar un tablespace
♦ Cargar una tabla
♦ Actualizar una tabla
Un RHF contiene un resumen de informaciones del respaldo. Usuario puede consultar las
informaciones de un momento especificado. Las informaciones en RHF incluye:
♦ La parte de la base de datos que se hizo respaldo, y como se hizo.
♦ El tiempo que realizo el respaldo.
♦ La localizacion de la copia.
♦ El tiempo que realizo la ultima recuperacion.
♦ El tiempo que se renombro un tablespace, con el nombre previo y el nombre actual.
♦ El estado del respaldo: activo, inactivo, vencido, o borrado.
♦ El ultimo numero de sequencia de log guardado por el respaldo de la base de datos, o
procesado por una Rollforward Recovery.
INTEGRIDAD
Las restricciones son reglas que el administrador de la base de datos establece.
Hay tres tipos de restricciones.
♦ Restricción Única. Es una regla que prohíbe que haya valores duplicados en una o en más
columnas en una tabla. La restricción de un único valor y las claves primarias no son tomadas
como restricciones. Por ejemplo: una restricción única podría definirse para identificar a un
proveedor, y asegurarse de esta forma que no haya un mismo identificador para dos
proveedores.
♦ Restricción Referencial. Es una regla lógica sobre valores en una o en más columnas, en una
o más tablas. Por ejemplo, un conjunto de tablas que comparten información sobre los
proveedores de una empresa. Ocasionalmente, el nombre de un proveedor podría cambiar.
Este tipo de restricciones permite que se actualicen ese grupo de tablas, permitiendo
resultados que puedan ocasionar la pérdida de información del proveedor.
♦ Una tabla de Control de Restricciones: Es un grupo de restricciones que se agregan a los
datos de una tabla específica. Por ejemplo: Se podría definir el sueldo de un empleado, tal que
nunca deba ser menor a $200. −Estos tipos de integridad referencial pueden ser activados o
no.
9
La integridad referencial es el estado en el que todas las claves foráneas de una base de datos deben
ser válidas. Una clave foránea es una columna o un grupo de columnas en una tabla cuyos valores son
necesarios para poder referenciar a una clave primaria o un único valor de una fila de la tabla de la
cual se desprende. La restricción referencial es la regla que permite que una clave foránea sea válida
solamente si:
♦ Ellas se aparecen como valores de una clave de la tabla maestra o
♦ Algún componente de la clave foránea es nulo.
La tabla que contiene la clave maestra, se define como Tabla Padre de la integridad referencial, y la
tabla que contiene la clave foránea se llama dependiente. Esta restricción referencial es opcional y
puede definirse con el comando CREATE TABLE y ALTER TABLE.
Esta restricción se fuerza por el Administrador de la base de datos durante la ejecución de los
comandos INSERT, DELETE, ALTER TABLE ADD CONSTRAIST Y SET CONSTRAITS. Esto es
puesto en práctica eficazmente al realizar la declaración.
Nota: La integridad referencial, las restricciones de control y los triggers pueden combinarse durante
la ejecución.
Clave Maestra
Es la clave principal o clave única de una restricción preferencial.
Fila maestra:
Es la fila que tiene al menos una fila dependiente.
Tabla maestra o Padre:
La tabla que es Padre en por lo menos una restricción referencial. Esta tabla puede ser definida como
Padre en un número arbitrario de restricciones referenciales. Una tabla Padre puede ser también una
tabla dependiente.
Tabla dependiente.
Es aquella tabla que depende de al menos una restricción referencial. Una tabla dependiente puede ser
10
también una tabla Padre.
Tabla descendente.
Una tabla es descendente de una tabla T, si esta es dependiente de T.
Fila descendente:
Una fila descendente de una fila F, si esta es dependiente de F.
Ciclo referencial
Es un conjunto de restricciones referenciales, tal que cada tabla es descendente de si misma.
Fila Auto−referenciada:
Es la fila que es Padre de ella misma.
Tabla auto−referenciada.
Es la tabla que es padre y dependiente en la misma restricción referencial.
Inserción:
La regla de inserción en una restricción referencial significa que al colocar un
valor no nulo como clave foránea, este debe coincidir con algún valor de la
clave Padre en la tabla de la cual esta depende. El valor en una clave foránea,
es nulo si algún componente es nulo. Esta regla esta implícita cuando se
especificó la clave foránea.
UPDATE RULE. (Regla de actualización)
La regla de actualización de una restricción referencial se especifica al definir dicha restricción. Las
opciones son NO ACTION y RESTRICT. Las reglas de actualización se aplican cuando una fila de la
11
tabla Padre o una fila de la tabla dependiente se actualiza.
En caso de una fila padre, cuando un valor de la columna de la clave es actualizada
♦ Si alguna fila en la tabla dependiente concuerda con el original de la clave, esta actualización
se rechaza cuando la regla de actualización esta en RESTRICT.
♦ Si alguna fila en la tabla dependiente no tiene su correspondiente clave Padre cuando el
comando de actualización se completó, esta actualización se rechaza si la regla se encuentra
en NO ACTION.
En caso de una fila dependiente.
♦ La regla de actualización está implícita cuando la clave foránea se especifica como NO
ACTION significa que un valor no nulo que se actualice, debe corresponder a algún valor de
la clave padre o de la tabla padre, cuando el comando de actualización se ejecuta.
DELETE RULE. (Regla de eliminación.)
Esta regla se específica cuando la restricción referencial se define.
Las opciones son NO ACTION, RESTRICT, CASCADE, or SET NULL.
SET NULL puede especificarse solo si alguna columna de la clave foránea admite valores nulos.
Esta regla se aplica cuando una fila de la tabla es eliminada. Más precisamente, cuando una fila de la
tabla padre se intenta borrar y esta tiene filas dependientes en tablas dependientes.
Supongamos P es la tabla padre D sea la tabla dependiente p sea la fila padre que es objeto de
eliminar y propagar así su eliminación a las filas dependientes.
Si la regla de eliminación se determina como:
12
♦ RESTRICT or NO ACTION; ocurre un error y las filas no son eliminadas.
♦ CASCADE; La operación de eliminación se propaga de la fila dependiente p a D.
♦ SET NULL; cada valor que es factible de anular en la columna correspondiente a la clave
foránea de la tabla D es puesto como NULO.
Cada restricción referencial en el cual una tabla es padre, tiene sus propias reglas de eliminación. Y
todas las reglas de eliminación son utilizadas para determinar el resultado de una operación de
borrado.
De esta forma, una fila no puede eliminarse si tiene dependientes y se restringe con RESTRICT o NO
ACTION, o la eliminación en cascada de cualquiera de sus dependientes con las reglas RESTRICT or
NO ACTION.
Eliminar una fila de la tabla Padre P que involucra a otras tablas y puede afectar a las filas de esas
tablas se guía según el siguiente criterio:
♦ Si la tabla D que es dependiente entre P y la regla es RESTRICT or NO ACTION, D está
involucrada en la operación, pero no es afectado por la operación.
♦ Si la tabla D, que depende de P y la regla es SET NULL, D está involucrada en la operación,
y las filas D pueden actualizarse durante la operación.
♦ Si la tabla D, es dependiente de P y la regla de eliminación se indica como CASCADE, D esta
incluida en la operación y las filas de D pueden eliminarse durante la operación.
♦ Si las filas D son eliminadas, la operación de eliminado en P se dice que se extendió a D. Si
D, también es una tabla Padre, las acciones descriptas en esta lista, a su vez, se aplican a los
dependientes de D.
Cualquier tabla en la que se pueda involucrar una operación de eliminado en P, se dice que esta
conectada para eliminado a P. Así, una tabla se dice que esta conectada para eliminado a una tabla P,
si esta es dependiente de P o una tabla dependiente que se encuentra con indicación de operaciones en
cascada de P.
13
Hay tres tipos de restricciones:
Re
♦ − una fila se agrega dentro de la tabla
♦ − una fila de la tabla se modifica
El table check constraint se ve obligada por la aplicación a condiciones de búsqueda para cada fila
que es agregada o modificada. Un error ocurrirá si el resultado de la condición de búsqueda es falso
para alguna fila.
Cuando una o mas table check constraints son definidas con el comando ALTER TABLE para una
tabla con datos existentes, los datos existentes son verificados nuevamente por la nueva condición
antes que alter table suceda. La tabla puede ser puesta en estado de verificación pendiente, el que
permitirá ingresar datos sin verificarlos. El set constraint es usado para poner la tabla dentro del
estado pendiente de verificación. Esto es también usado para abreviar la verificación de cada fila de la
restricción nuevamente.
SEGURIDAD EN DB2
DB2 utiliza una combinacion de seguridad esterna y control interno de acceso a proteger datos. Para
poder accesar un servidor de base de datos, es necesario a pasar unas revisiones de seguridad. El
primar paso de seguridad se llama Autenticacion, donde usuario prueba que es quien que dice. El
segundo paso de seguridad se llama Autorizacion, donde SGBD decide que si el usuario autenticado
es permitido a realizar accion solicitada o accesar datos solicitada.
I. Autenticacion
Autenticacion de usuario es completamente fuera de DB2. El proceso puede ser en una parte del SO,
en un dispositivo separato, o, en unos casos, no existe. Por ejemplo, en sistemas basados en UNIX, el
proceso de autenticacion esta en el mismo SO; y no esiste el proceso en los SO de Windows 95 o
Windows 3.1. Se necesitan un User ID y un Password para autenticar un usuario en una de las dos
maneras:
♦ Proceso de login a SO con exito, como evidencia de identidad
♦ La combinacion de User ID y Password
El usuario tambien hay que ser identificado por DB2 con un nombre autorizado. Un nombre que
puede ser el mismo de User ID. Luego, se extrae una lista de grupos que el usuario pertenece. DB2
extraen una lista de, como el maximum, 64 grupos para cada usuario. Si un usuario pertenece a mas
que 64 grupos, solamente los primeros 64 grupos son validos. En este momento, no ocurre ningun
error, y los restos grupos son ignorados.
II. Autorizacion
Autorizacion es el proceso, con la informacion acerca de un usuario autenticado, que indica cuales
operaciones un usuario puede realizar, y cuales objetos puede accesar. Tablas y archivos de
14
configuracion son utilizados para registrar los permisos de cada nombre autorizado. Hay dos tipos de
permisos registrados por DB2:
♦ Privilegio, define un permiso para un nombre autorizado, y le permite a crear o accesar
objetos
♦ Nivel de autoridad, es un grupo de privilegios y controles sobre administracion de alto nivel.
Ambos son registrados en catalogos de base de datos.
III. Jerarquia de autoridades
Un usuario o grupo puede tener una o mas de los siguiente niveles de autorizacion:
♦ Autoridad administrativa (SYSADM o DBADM), dan privilegios total para objetos
♦ Autoridad de sistema (SYSCTRL o SYSMAINT), dan privilegios total para administrar el
sistema, pero no se permite accesar a los datos
♦ Autoridad de cargar (LOAD), da privilegios a insertar datos a tablas
III − 1. Autoridad de administracion de sistema (SYSADM)
SYSADM es el mas alto nivel de autoridad administrativa. Usuarios quienes tienen SYSADM pueden
utilizar utilidades, utilizar comandos de base de datos, accesar cualquier tabla en base de datos, y
tienen el control a todos los objetos. Solo los usuarios quienes tienen SYSADM puede realizar las
siguientes funciones:
♦ Mover una base de datos (export / import)
♦ Cambia el archivo de configuracion de administrador de base de datos (incluye dar autoridad
de SYSCTRL o SYSMAINT a grupos)
♦ Permite DBADM
Ademas, un usuario con SYSADM puede realizar las funciones de SYSCTRL, SYSMAINT, y
DBADM.
III − 2. Autoridad de control de sistema (SYSCTRL)
SYSCTRL es el mas alto nivel de autoridad de control de sistema. Permite a realizar mantenimiento,
pero no permite acceso directo a datos en la base de datos. Solo un usuario con autoridad de
SYSCTRL o superior puede realizar los siguientes:
♦ Actualiza una base de datos o nodo
♦ Forzar usuarios fuera del sistema (offline)
♦ Crear o eliminar una base de datos
♦ Crear, eliminar, o actualizar un tabla
♦ Restauracion de una nueva base de datos
III − 3. Autoridad de mantenimiento de systema (SYSMAINT)
SYSMAINT es el segundo nivel de autoridad de control de systema. Permite a realizar
mantenimiento, pero no permite acceso directo a datos en la base de datos. Solo un usuario con
autoridad de SYSMAINT o superior puede realizar los siguientes:
♦ Actualizar archivos de configuracionn de base de datos
♦ Backup un base de datos o tabla
♦ Restauracion de una base de datos que ya existe
♦ Restaracion de una tabla
♦ Realizar rollforward recovery
III − 4. Autoridad de administracion de base de datos (DBADM)
15
DBADM es el segundo nivel de autoridad administrativa. Se aplica solamente a una base de datos
especifica, y permite usuario utilizar comandos de la base de datos, accesar datos, grant privilegios a
otros, y revoke cualquier privilegios de cualquier usuario. Solo un usuario con autoridad de DBADM
o superior puede realizar los siguientes:
♦ Leer archivos log
III − 5. Autoridad de cargar (LOAD)
Usuarios quienes tienen autoridad de LOAD pueden utilizar el comando LOAD a cargar datos a una
tabla.
IMPORTACION Y EXPORTACION
El Procesador de línea de mandatos de DB2 Everyplace para Palm OS, EPOC, Windows CE,
plataformas Win32, Neutrino y Linux incorporado, permite importar datos desde un archivo a DB2
Everyplace y exportar datos de DB2 Everyplace a un archivo. La importación y exportación de datos
en Palm OS utiliza los archivos Memo en el dispositivo.
Importación de datos desde un archivo a DB2 Everyplace
Para importar datos desde un archivo a DB2 Everyplace, escriba: IMPORT FROM nombre−archivo
OF DEL INSERT INTO nombre−tabla nombre−archivo es el nombre del archivo desde el que se
importa. En Palm OS, nombre−archivo es el nombre del archivo Memo desde el que se importa. El
nombre−archivo debe aparecer en la primera línea del archivo Memo. Los archivos Memo de Palm
tienen una limitación de 4K bytes de almacenamiento de texto. nombre−tabla es el nombre de una
tabla existente a la que se importa. Por ejemplo,
para importar datos de un archivo llamado mydata.txt a una tabla existente llamada mytable, escriba:
IMPORT FROM mydata.txt OF DEL INSERT INTO mytable
Exportación de datos desde DB2 Everyplace a un archivo
Para exportar datos desde DB2 Everyplace a un archivo, escriba: EXPORT TO nombre−archivo OF
DEL sentencia nombre−archivo es el nombre del archivo en el que se escriben los datos. sentencia es
la sentencia SELECT para seleccionar los datos que se exportan. Por ejemplo, para exportar todos los
datos desde la tabla llamada mytable a un archivo llamado
myfile.txt, escriba: EXPORT TO myfile.txt OF DEL SELECT * FROM mytable
TRIGGERS
La mayoría de los sistemas de administración de la base de datos relacionales proporcionan ayuda
para los triggers La IBM está agregando la ayuda de triggers a DB2 para OS/390 en la versión 6.
Pero, ¿qué es un trigger? Si usted nunca ha tenido la oportunidad de utilizarlos, su potencia puede
eludirle al principio. Sin embargo, una vez que usted haya utilizado triggers, el vivir sin ellos puede
ser increíble!
Lo Básico
Indicado simplemente, un trigger es una parte del código que se ejecuta en respuesta a una
declaración de modificación de los datos; es decir, un insert, un update, o un delete. Para ser un poco
más exacto: los triggers son los procedimientos especializados en manejar que se salvan dentro, y son
16
manejados por el RDBMS. Cada uno se asocia a un vector solo, especificado. Los triggers se pueden
pensar en como una forma avanzada de regla o de contraint escrito usando una forma extendida de
SQL. Un trigger no puede ser llamado o ser ejecutado directamente; es ejecutado (o encendido
automáticamente) por el RDBMS como resultado a una acción − una modificación de los datos al
vector asociado.
Una vez que se crea un trigger se ejecuta siempre cuando ocurre su acontecimiento de la despedida
(update, insert, o delete). Por lo tanto los triggers son automáticos, implícitos, y no se puede ignorar.
Triggers versus Procedimientos Almacenados
Los trigger son similares a los procedimientos almacenados. Ambos consisten en la lógica procesal
que se salva en el nivel de la base de datos. Sin embargo, los procedimientos almacenados no son
accionados y no se asocian a un vector específico. Un procedimiento almacenado es ejecutado
explícitamente invocando una llamada al procedimiento (en vez implícito de ser ejecutado como
triggers). Además, un procedimiento almacenado puede tener acceso a muchos vectores sin que sea
específicamente asociado a cualquiera de ellos.
Por qué Utilice Los Triggers?
Los triggers son útiles para implementar código que deben ser ejecutados de forma regular debido a
un acontecimiento predefinido. Utilizando triggers, el programar y los problemas de la integridad de
los datos pueden ser eliminados porque el trigger será encendido siempre que ocurra el
acontecimiento que acciona. Usted no necesita recordar programar o cifrar una actividad para realizar
la lógica en el trigger. Sucede automáticamente en virtud de él que está en el trigger. Esto es verdad
del SQL estático y dinámico; SQL con fines específicos y previsto del anuncio.
Los triggers se pueden poner en ejecución para muchas aplicaciones prácticas. Es absolutamente a
menudo imposible cifrar reglas de negocio en la base de datos usando solamente DDL. Por ejemplo,
DB2 no utiliza los restricciones complejas (solamente restricciones basados en los check) o en los
diferentes tipos de constraints referenciales (tales como delete pendiente de procesar o update
cascade). El uso de triggers, genera un ambiente muy flexible para establecer las reglas y restricciones
del negocio en ejecución en el DBMS. Esto es importante porque tener las reglas de negocio en la
base de datos se asegura de que cada uno utiliza la misma lógica para lograr el mismo proceso.
Los triggers se pueden cifrar para tener acceso y/o para modificar a otros vectores, mensajes
informativos de la impresión, y especifican restricciones complejas. Por ejemplo, considere a
surtidores estándares y parte la aplicación usada en la mayoría de los textos introductorios de la base
de datos. Una pieza se puede proveer por muchos surtidores y un surtidor puede proveer muchas
piezas. Los triggers se pueden utilizar para utilizar los decorados siguientes:
♦ Qué si existe una regla de negocio especificando que no más de tres surtidores se permiten
para proveer cualquier sola parte. Un trigger se puede cifrar para controlar que las filas no
pueden ser insertadas si los datos violan este requisito.
♦ Un trigger se puede crear para permitir solamente las pedidos para las piezas que están ya en
la acción. O, quizá para las piezas que están ya en la acción o están en orden y se planean para
la disponibilidad dentro de la semana próxima.
♦ Los triggers del · se pueden utilizar para realizar cálculos tales como asegurarse de que la
cantidad de la orden para las piezas está calculada dada apropiadamente los surtidores
elegidos para proporcionar a las piezas. Esto es especialmente útil si la cantidad de la compra
de la orden se salva en la base de datos como datos redundantes.
♦ Para contener costes, una decisión económica puede ser tomada que utilizarán al surtidor del
17
bajo costo siempre. Un trigger se puede poner en ejecución rechaza cualquier orden que no
sea la orden actual del "bajo costo".
El número de las reglas de negocio que se pueden poner en ejecución usando triggers es limitado
únicamente por su imaginación (o, más apropiadamente, sus necesidades del negocio).
Además, los triggers pueden tener acceso a los recursos non−DB2. Esto puede ser lograda invocando
un procedimiento empacado o una función definida por el usuario que se aproveche de los servicios
de la recuperación del recurso OS/390 (RRS). ). Los datos almacenados en el recurso del DB2 pueden
ser a los que se ganó acceso o modificados en el procedimiento almacenado o la función definida por
usuario que es llamada.
¿Cuándo se enciende un trigger?
Dos opciones existen para cuando un trigger se puede encender: antes de que ocurra la actividad de la
despedida o después de la actividad de la despedida. El DB2 soporta ambos tipos de triggers antes y
después. Uno antes se acciona antes de que la actividad de tiroteo ocurra; y después se acciona
después de que la actividad de tiroteo ocurra. En DB2 V6, "antes de que" los triggers están
restringidos porque no pueden realizar actualizaciones.
Saber cómo funcionan los triggers en su base de datos es indispensable. Sin el conocimiento
apropiado del funcionamiento de los triggers no se pueden cifrar, utilizar, o mantener con eficacia.
Considere, por ejemplo, si ocurre la actividad de la despedida antes de que se encienda el trigger. Es
decir el update, el insert, o el delete ocurre primero como un resultado de esta acción, la lógica del
trigger se ejecuta. En caso de necesidad, se puede hacer un rollback a la modificación de los datos.
¿Qué ocurre si el trigger es disparado antes de que se de el evento? En esta situación un rollback no
sería requerido para el código del acontecimiento del trigger porque no ocurrió. Sin embargo, un
rollback se puede requerir para cualquier modificación de los datos que ocurriera antes de este
acontecimiento de la despedida dentro de la misma transacción.
Otra característica interesante de los triggers de DB2 V6 es la orden en la cual se encienden. Si
existen múltiples triggers en la misma tabla, cuál trigger que se enciende primero? Puede diferenciar
en cuanto a cómo los triggers deben ser cifrados, ser probados, y ser mantenidos. La regla para el
orden de la ejecución es básicamente simple entender, pero puede ser difícil de mantener. Para los
triggers del mismo tipo, se ejecutan en el orden en la cual fueron creados. Por ejemplo, si dos trigger
de delete se cifran en la misma tabla, el que fue creado físicamente primero, se ejecuta primero. Tenga
esto presente como usted realiza cambios a su base de datos. Si usted necesita caer a la tabla y
reconstruirla para poner un cambio del esquema en ejecución, se cerciora usted de crear los triggers
en la orden deseado (iguales) para guardar las funciones iguales.
Como puede ser visto fácilmente, la determinación de la actividad procesal se requiere que cuando los
triggers están presentes puede ser una tarea complicada. Es de importancia suprema que todos los
reveladores están enseñados en los métodos de la despedida utilizados para los triggers en DB2 V6.
Triggers Empacados
Cuando se ejecuta un trigger, DB2 crea un conjunto de triggers para las declaraciones en la acción
accionada. El conjunto del trigger se registra en SYSIBM.syspackage y tiene el mismo nombre que el
trigger. El conjunto del trigger es siempre accesible y puede ser ejecutado solamente cuando un
trigger es activado por una operación que acciona.
18
Para suprimir el conjunto del trigger, usted debe utilizar la declaración DROP TRIGGER.
Los Triggers Pueden Encender Otros Triggers
Como hemos aprendido ya, un trigger puede ser encendido por un insert, un update, o un delete. Sin
embargo, un trigger puede también contener el insert, poner al día, y suprimir lógica dentro de sí
mismo. Por lo tanto, un trigger es encendido por una modificación de los datos, pero puede también
causar otra modificación de los datos, de tal modo encendiendo otro trigger. Cuando un trigger
contiene el insert, ponga al día, y/o suprima la lógica, el trigger se dice ser un trigger jerarquizado.
La mayoría de los DBMS, sin embargo, pone un límite en el número de los triggers jerarquizados que
se pueden ejecutar dentro de un solo acontecimiento de la despedida. Si esto no fue hecha, podría ser
absolutamente posible que los triggers se dispararán de una forma desencadena hasta lo infinito hasta
que todos los datos fueron removidos de una base de datos entera.
Si la integridad de referencia está combinada con triggers, entonces los updates en cascada y/o deletes
puede ocurrir. Si uno suprima o actualice resultados en una serie de actualizaciones adicionales o
suprime esa necesidad en ser propagado para otras tablas, entonces los triggers de update o delete para
la segunda tabla también serán activados.
Esta combinación de triggers múltiples y de contraints de integridad referencial es afable de fijar un
efecto de conexión en cascada en el movimiento, que puede dar lugar a cambios múltiples de los
datos. DB2 V6 limita este efecto de conexión en cascada a 16 niveles para prevenir un ciclo infinito.
Si existieran más de 16 niveles de jerarquización, se aborta la transacción.
La capacidad de jerarquizar triggers proporciona un método eficiente para poner integridad
automática a los datos en ejecución. Debido a que los triggers no pueden ser desviados, generalmente
proporcionan una solución elegante a la aplicación haciendo cumplir de las reglas de negocio. Tenga
cuidado, sin embargo, para asegurarse de que el nivel máximo de triggers anidados no sea alcanzado.
El fracaso de prestar atención a este consejo puede causar un ambiente donde ciertos tipos de
actualizaciones no pueden ocurrir.
Limitaciones de los Triggers
Hay límites para que puedan ejecutarse los triggers. En DB2 V6, usted no puede definir triggers
encendido:
♦ Una tabla del catálogo de sistema
♦ La tabla de plan
♦ La tabla de declaración
♦ La tabla de función DSN.
♦ Una vista
♦ Alias
♦ Sinónimo
Uso de Triggers para Implementar la Integridad Referencial
Una de las aplicaciones primarias para los triggers debe utilizar la integridad de referencia (RI).
Aunque DB2 utiliza una forma muy robusta de RI declarativo, ningún DBMS actual utiliza
completamente todos los constraints de referencia posibles.
Los triggers se pueden cifrar, en lugar de RI declarativo, para utilizar todas las reglas de RI de la tabla
1. Por supuesto, cuando usted utiliza triggers, hace necesario el código de procedimientos para cada
19
regla, para cada constraint, mientras que los constraints declarativos de RI se cifran en el DDL que se
utiliza para crear las tablas relacionales.
Tabla 1. Reglas de Integridad Referencial
DELETE
RESTRICT
DELETE
CASCADE
DELETE
NEUTRALIZE
UPDATE
RESTRICT
UPDATE
CASCADE
UPDATE
NEUTRALIZE
INSERT
RESTRICT
FK UPDATE
RESTRICTION
PENDANT
DELETE
Si cualquier filas existen en la tabla dependiente, entonces el registro de la
llave primaria en la tabla del padre no puede ser borrada.
Si un registro de la tabla padre de la llave primaria es borrado, entonces, todos
los registros de la tabla dependiente son borrados.
Si se borra un registro de la llave primaria de la tabla padre, todos los registros
dependientes serán definidos como Null.
Si un registro existe en la tabla dependiente, la columna de la llave primaria en
la tabla padre no puede ser modificado.
Si un registro existe en la tabla dependiente, la columna de la llave primaria en
la tabla padre es modificado entonces todos los valores de las llaves foráneas
son modificados con el mismo valor.
Si cualquier filas existen en la tabla dependiente, entonces la fila primaria de la
llave en la tabla del padre es suprimida, y toda llave foránea aprecia en las filas
dependientes está actualizado para NULL igualmente.
Un valor foráneo de la llave puede no ser introducido en la tabla dependiente a
menos que un valor primario de la llave ya exista en la tabla del padre.
Una llave foránea puede no estar actualizada para un valor que ya no existe
como un valor primario de la llave en la tabla del padre.
Cuando el último valor foráneo de la llave en la tabla dependiente es
suprimido la fila primaria de la llave en la tabla del padre es también
suprimida.
Para utilizar triggers para utilizar reglas de RI, es a veces necesario saber los valores afectados por la
acción que encendió el trigger. Por ejemplo, considere el caso donde se enciende un trigger porque
una fila fue suprimida. La fila, y todos sus valores, se ha suprimido ya porque se ejecuta el trigger
después de que ocurra su acción de la despedida. Pero si es esto el caso, cómo podemos comprobar si
las filas referenciadas conectadas existen con esos valores? Los triggers se pueden cifrar, en lugar de
RI declarativo, para utilizar todas las reglas de RI en tabla 1. Por supuesto, cuando usted utiliza
triggers, hace necesario el código procesal de la escritura para cada regla para cada cconstraint,
mientras que los constraints declarativos de RI se cifran en el DDL que se utiliza para crear los tablas
referenciales.
La solución se proporciona en la forma de dos pseudónimos especializados disponibles solamente
dentro de triggers: NUEVO y VIEJO.
Cada trigger puede tener una NUEVA vista de la tabla y una VIEJA vista de la tabla disponible. De
nuevo, estas visiones son accesibles solamente de triggers. Proporcionan el acceso a los datos
modificados viendo la información en el registro de la transacción. El registro de la transacción es un
expediente de toda la actividad de la modificación de los datos, mantenido automáticamente por el
DBMS.
20
Figure 2. Before and After Views of Table Activity
Cuando ocurre un insert, el vector NUEVO contiene las filas que acaban de ser insertadas en el vector
al cual se asocia el trigger. Cuando ocurre una CANCELACIÓN, la VIEJA tabla contiene las filas que
acaban de ser suprimidas de la tabla a la cual se asocia el trigger. Una declaración de la
ACTUALIZACIÓN funciona lógicamente como una CANCELACIÓN seguida por un insert. Por lo
tanto, después de una ACTUALIZACIÓN, la tabla NUEVA contiene los nuevos valores para las filas
que acaban de ser modificadas en la tabla a la cual se asocia el trigger; la tabla VIEJA contiene los
viejos valores para las filas actualizadas.
Por lo tanto, el trigger puede utilizar estas NUEVAS y VIEJAS opiniones especializadas de la tabla
para preguntar los datos afectados. Recuerde, también, que la modificación de los datos del SQL
puede ocurrir un instante de tiempo. Una declaración de la CANCELACIÓN o de la
ACTUALIZACIÓN puede afectar filas múltiples. Esto debe considerarse al cifrar la lógica real del
trigger.
Además, los nombres del pseudónimo, VIEJO y NUEVO, pueden ser cambiados si están deseados
(por ejemplo, a INSERTADO y a SUPRIMIDO, los nombres utilizado por el servidor de SQL).
Granularidad en los Triggers
Debido a que el SQL es un lenguaje el fija el nivel cualquier declaración del SQL puede afectar filas
múltiples de datos. Por ejemplo, una declaración de la CANCELACIÓN puede causar realmente cero,
una, o mucha fila que se quitará. Los triggers necesitan tomar esto en cuenta.
Por lo tanto, hay dos niveles de granularidad que un trigger puede tener: nivel de la declaración o
nivel de la fila. Un trigger del nivel de la declaración se ejecuta una vez sobre la despedida, sin
importar el número real de las filas insertadas, suprimidas, o modificadas. Un trigger del nivel de la
fila, una vez que esté encendido, se ejecuta una vez para cada fila que se inserte, se suprima, o
modifique.
Diversos requisitos del negocio conducirán qué tipo de granularidad del trigger debe ser elegido.
Ejemplo de Trigger
Es una actualización trigger, codificada en la tabla EMP. Este trigger implementa una comprobación
simple para asegurar que los aumentos están menos de 50%. Cuando el sueldo nuevo excede 50 % del
21
anterior sueldo, un error es levantado.
CREATE TRIGGER SALARY_UPDATE
BEFORE UPDATE OF SALARY
ON EMP
FOR EACH ROW MODE DB2SQL
WHEN (NEW.SALARY > (OLD.SALARY * 1.5))
BEGIN ATOMIC
SIGNAL SQLSTATE '75001' ('Raise exceeds 50%');
END;
El trigger se ejecuta una vez para cada fila. Si son modificadas filas múltiples por una sola
actualización, el trigger se ejecutará en múltiples ocasiones, una vez para cada fila modificada.
También, el trigger será ejecutado ANTES DE QUE ocurra la modificación real. Finalmente, tome el
aviso especial cómo es NUEVO y VIEJO
se utilizan para controlar valores antes y después la actualización.
TABLESPACE
Un tablespace es un espacio para almacenar tablas. Cuando se crea una tabla, usuario puede decidir
que unos objetos, tales como indices y datos de objeto grande (LOB, Large OBject), se separan desde
otros datos de la tabla. Un tablespace tambien puede ser distribuido en diferentes dispositivos fisicos
de almacenamiento.
Un table space puede ser un espacio manejado por sistema (SMS, System Managed Space), o un
espacio manejado por base de datos (DMS, Database Managed Space). Para un SMS tablespace, cada
contenedor* es un directorio en el espacio de archivo del sistema operativo, y el administrador de
archivo del sistema operativo controla el espacio de almacenar. Para un DMS tablespace, cada
contenedor es un archivo de tamano fijo o un dispositivo fisico, como un disco duro, y el
administrador de la base de datos controla el espacio de almacenar.
Los tres tipos de table space son:
♦ Regular Tablespace
♦ Long Tablespace
♦ Temporary Tablespace
Las tablas que contienen datos de usuario se almacenan en regular tablespace. El tablespace de
usuario se llama USERSPACE1 por default. Los indices y las tablas de catalog de sistema tambien se
alamcenan en regular table. El tablespace de catalogo de sistema se llama SYSCATSPACE por
default.
Las tablas que tienen datos de campo largo o datos de objeto grande, tales como objetos de
multimedia, se almacenan en long tablespace.
22
Se utiliza temporary tablespace para almacenar datos requeritos durante las operaciones de SQL. El
temporary tablespace se llama TEMPSPACE1 por default.
Lista de Tipos de Dato en DB2 UDB
DB2 ademas de suporta tipo de dato definido por usuario, tambien suporta una gran cantidad de tipos
de dato, como se muestra en la siguiente figura:
♦ DATALINK, contiene una referencia logica a un archivo almacenado fuera de la base de
datos. El tipos de enlace que DB2 suporta es de URL (Uniform Resource Locator) que
suporta HTTP, FILE, UNC, y DFS.
♦ DATE, se un valor de 3 partes; anno, mes, y dia. El rango de anno es de 0001 a 9999, de 1 a
12 para el rango de mes, y de 1 a X, donde X depende de el mes para el rango de dia. Es un
dato de 4 bytes. Cada byte consiste de 2 digitos de decimal. Los primeros 2 bytes representan
el anno; el tercer byte representa el mes, y el ultimo byte representa el dia.
♦ TIME, se un valor de 3 partes; hora, minuto, y segundo. Sennala a un tiempo bajo el formato
de 24 horas. El rango de hora es de 0 a 24, de 0 a 59 para minuto y segundo. Es un dato de 3
bytes. Cada byte consiste de 2 digitos de decimal. El primer byte representa la hora, el
segundo representa el minuto, y el ultimo representa el segundo.
♦ TIMESTAMP, es un valor de 7 partes; anno, mes, dia, hora, minuto, segundo, y
microsegundo. Sennala a una fecha y hora en forma como DATE y TIME, excepto que el
tiempo incluye microsegundo. Es un dato de 10 bytes de 2 digitos de decimal. Los primeros 4
bytes representan la fecha, los siguientes 3 bytes representan el tiempo, y los ultimos 3 bytes
representan el microsegundo.
♦ CHAR, tiene la longitud fija. Su longitud maxima es de 254 bytes.
♦ VARCHAR, tiene la longitud variable. Su longitud maxima es de 4000 bytes.
♦ LONG VARCHAR, tiene la longitud variable. Su longitud maxima es de 32700 bytes.
♦ SMALLINT (Small Integer), almacena un numero de 5 digitos con un rango de −32768 a
+32767.
♦ INTEGER, almacena un numero de 10 digitos con un rango de −2147483648 a +2147483647.
♦ BIGINT (Big Integer), almacena un numero de 19 digitos con un rango de
−9223372036854775808 a +9223372036854775807.
♦ REAL, almacena un numero de 32 bit con un rango de −3.402E+38 a −1.175E−37, o un rango
de 1.175E−37 a 3.402E+38, y por supuesto el zero.
♦ DOUBLE o FLOAT, almacena un numero de 64 bit con un rango de −1.79769E+308 a
−2.225E−307, o un rango de 2.225E−307 a 1.79769E+308, y por supuesto el zero.
♦ DECIMAL o NUMERIC, tiene un rango maximo de −10**31+1 a 10**31−1.
♦ GRAPHIC, tiene su longitud fija con un rango de 1 a 127 caracteres de doble−byte.
♦ VARGRAPHIC, tiene su longitud variable hasta 2000 caracteres de doble−byte como maxima.
♦ LONG VARGRAPHI, tiene su longitud variable hasta 16350 caracteres de doble−byte como
maxima.
♦ DBCLOB (Double−Byte Character Large Object), tiene su longitud variable hasta
1073741823 caracteres de doble−byte como maxima.
♦ CLOB (Character Large Object), tiene su longitud variable hasta 214743647 caracteres de
doble−byte como maxima.
♦ BLOB (Binary Large Object), tiene su longitud variable hasta 214743647 caracteres de
doble−byte como maxima.
Create, Grant y Revoke en DB2
♦ Creacion de un tablespace:
Create Tablespace espacio
23
Managed By Database
Using (`directorio');
Donde espacio es el nombre del tablespace, y; directorio es el directorio donde el tablespace se
almacena. Por ejemplo:
Create Tablespace recuso_humano
Maganged By Database
Using(`e:\tbsp_rh', `f:\tbsp_rh', `g:\tbsp_rh');
♦ Creacion de una tabla:
Create Table tabla
(
nombre tipo restriccion,
Primary Key(llave)
) In espacio;
Donde tabla es el nombre de la tabla; nombre es el nombre del campo; tipo es el tipo de datos que
almacena el campo; restriccion es la restriccion para el campo; llave es el nombre del campo que es la
llave primaria, y; espacio es el nombre del tablespace donde la tabla se almacena. Por ejemplo:
Create Table empleado
(
cedula Varchar(15) Not Null,
nombre Varchar(30) Not Null,
puesto Char(10) Check(puesto In(`Vendedor', `Cajero', `Encargado')),
fecha_ing Date,
salario Decimal(7, 2) Check(salario >= 0),
Primary Key(cedula),
Constraint anno_sala Check(Year(fecha_ing) > 1985 Or salario > 40000),
) In recuso_humano;
♦ Creacion de un usuario:
Create User Mapping For nombre
Server servidor
24
Options
(Remote_AuthID `identificacion'
Remote_Password `contrasenna');
Donde nombre es el nombre autorizado por el sistema; servidor es el nombre del servidor donde la
base de datos esta; identificacion es el ID de usuario en cada base de datos, y; contrasenna es la
contrasenna en cada base de datos. Por ejemplo:
Create User Mapping For jose
Server svr1
Options
(Remote_AuthID `encargado'
Remote_Password `pase');
♦ Permiso de conexion:
Grant Connect On Database To User identificacion;
Donde identificacion es el ID de usuario. Por ejemplo:
Grant Connect On Database To User jose;
♦ Permiso de privilegio:
Grant privilegio On tabla To User identificacion;
Donde privilegio es el privilegio que se permite al usuario; tabla es el nombre de la tabla, y;
identificacion es el ID de usuario. Por ejemplo:
Grant Select, Insert, Update, Delete On empleado To User jose;
♦ Revocacion de conexion:
Revoke Connect On Database From User identificacion;
Donde identificacion es el ID de usuario. Por ejemplo:
Revoke Connect On Database From User jose;
♦ Revocacion de privilegio:
Revoke privilegio On tabla From User identificacion;
Donde privilegio es el privilegio que se revoca del usuario; tabla es el nombre de la tabla, y;
identificacion es el ID de usuario. Por ejemplo:
Revoke Delete On empleado From User jose;
ANEXOS
25
♦ EN CUANTO A TRIGGERS
Triggers se define como un conjunto de acciones que se ejecutan, o se disparan, como por ejemplo
eliminar, insertar o actualizar una tabla.
Cuando este tipo de operación en SQL se ejecuta, consideramos que el TRIGGER está activado.
Los triggers pueden usarse en conjunto con restricciones referenciales o restricciones de control para
dar fuerza a las reglas de integridad de los datos.
También pueden usarse TRIGGERS para actualizar otras tablas, automáticamente pueden generarse
valores, actualizar, insertar filas, e invocar funciones que realicen tareas de control.
Los TRIGGERS son un mecanismo muy utilizado para enfatizar las reglas de integridad definidas por
DBA ( por ejemplo el sueldo no puede aumentarse más de un 10%).
Usar TRIGGERS ubica a la lógica para enfatizar las reglas de negociación de datos en una base de
datos.
Esta lógica utilizada en todas las tablas implicará un fácil mantenimiento posterior, y que no sea
necesario cambiar los programas de aplicación cuando se cambie la lógica de la misma.
Los TRIGGERS son opcionales y se definen mediante la instrucción CREATE TRIGGER .
Hay varios criterios que se deben de tener en cuenta al crear un TRIGGER, que se utilizará para
determinar cuando un TRIGGER debe activarse.
♦ En una tabla se define la tabla que llamaremos objeto para la cual el TRIGGES se utilizará.
♦ El evento que se ejecutará se lo hace en SQL y esta modificará la tabla. Las operaciones
pueden ser: borrar, insertar o actualizar.
♦ El Triggers activation time define cuando el trigger debe ser activado.
26
En la declaración del trigger deberá incluir cuales serán las filas que afectará. Cuales de la tabla están
siendo borradas, insertadas o actualizadas.
El Trigger granularity define si las acciones que ejecute se realizarán una vez para la declaración, o
una vez para cada una de las filas para las cuales se definió.
La acción del Trigger consiste en una condición de búsqueda opcional y un conjunto de declaraciones
en SQL que se ejecutarán cada vez que el Trigger se active.
Las declaraciones de SQL solo se ejecutarán si la condición de búsqueda es verdadera.
Cuando el tiempo en que el Trigger debe activarse es anterior al evento mismo, la acción de activarlo
debe incluir las declaraciones de selección de las variables y las señales de condición de SQL. Cuando
el tiempo en que se debe activar el Trigger es posterior al mismo evento, el activarlo puede incluir
declaraciones de selección, borrado, actualización, insertar o señales de condición del SQL.
El activar un Trigger puede referirse a un conjunto de valores que serán afectados en ciertas filas de la
tabla. Esto es posible a través del uso de variables. Estas variables usan el nombre de las columnas de
la tabla y con un indicador que marca si se refiere a un viejo valor ( antes de modificar) o un nuevo
valor ( después de modificar) . El nuevo valor puede cambiarse utilizando el comando SET transition
variable antes de actualizar o modificar.
Otra forma de referenciarse a valores en un grupo de filas es utilizando tablas transitorias que operan
en forma similar a las variables.
Varios Trigger pueden especificarse para una combinación de tablas, eventos o tiempos en que deben
activarse. El orden en que los Triggers se ejecutarán será el mismo en el que fueron creados. Por lo
tanto, el Trigger recientemente creado será el último en activarse.
♦ CASE
Un CASE ayuda para el caso en el que tenga que cambiar valores en una entrada o salida.
Supongamos que tiene una tabla con los tamaños de las remeras (S, M, L) y quiere que se vean como
Small, Medium, Large en la salida. Ud. puede hacerlo usando el CASE para cambiar el valor de
salida. También puede usar el CASE si quisiera convertir valores (como SMALL) en S para un insert.
27
SELECT LASTNAME, SALARY,
CASE
WHEN SALARY <= 20000 THEN 'Poor'
WHEN SALARY <= 25000 THEN 'Fair'
WHEN SALARY <= 30000 THEN 'Average'
WHEN SALARY <= 35000 THEN 'Good'
WHEN SALARY <= 40000 THEN 'Excellent'
ELSE 'Outstanding'
END AS COMPENSATION_LEVEL
FROM EMPLOYEE
ORDER BY SALARY
♦ TIPOS DE DATOS
−interger, longitud maxima 11 digitos,
−smallint, longitud maxima 5 digitos,
−bigint, longitud maxima 19 digitos,
−bouble,
−real,
−decimal,
−character (char), longitud fija de 1−254byte
−varchar, longitud variable de 1−4000byte
−long varchar, longitud variable de 1−32700byte
−blob, cadena de binario de 1byte − 2gb
−clob, cadena de caracter de 1byte − 2gb
−dbclob, cadena de grafico de 1byte − 1gb
−graphic, longitud fija de 1−127byte
−vargraphic, longitud variable de 1−2000byte
28
−long vargraphic, longitud variable de 1−16350byte
−date,
−time,
−timestamp,
♦ CREATE USER −Ejemplo−
CREATE USER MAPPING FOR nombre_de_usuario
SERVER servidor
OPTIONS
(
REMOTE_AUTHID 'id_de_usuario',
REMOTE_PASSWORD 'contrasena'
)
GRANT CONNECT ON DATABASE TO USER usuario
GRANT SELECT, INSERT ON tabla TO USER usuario1, USER usuario2
REVOKE CONNECT ON DATABASE FROM usuario
REVOKE SELECT ON tabla FROM usuario
♦ CREATE TABLE −Ejemplo−
CREATE TABLE empleado
(
id SMALLINT NOT NULL,
nombre VARCHAR(9),
dept SMALLINT CHECK(dept BETWEEN 10 AND 100),
fecha_ing DATE,
salario DECIMAL(7,2),
comicion DECIMAL(7,2),
PRIMARY KEY(id),
CONSTRAINT ano_salario CHECK(YEAR(fecha_ing)>1986 OR salario>50000)
29
)
IN recurso_humano
♦ CREATE TABLE para almacenar foto y voz −Ejemplo−
CREATE DISTINCT TYPE imagen AS BLOB(10M)
CREATE DISTINCT TYPE sonido AS BLOB(1G)
CREATE TABLE persona
(
nombre CHAR(30) NOT NULL,
voz sonido,
foto imagen
)
♦ FICHA TECNICA DB2
Manejo de Objetos−datos grandes de hasta 2GB
Definición de tipos de datos y funciones por parte del usuario
Chequeo de consistencia de datos
Chequeo de integridad referencial
Triggers / ANSI
Definición − SQL recursivo
Join externo
Soporte Multimedia: texto/imágenes/video/audio
Escalabilidad
Parallel Query
Two−phase commit
Backup / recovery on line y off line
Monitor grafico de performance
Visual explain, monitor grafico de estrategias de busqueda.
Data replication
30
Visual Age for Basic
Net Data
Lotus Approach
Dominio Go Web Servers
NOTAS
1. Logretain: Indica que archivos de log sera retenidos para rollforward recovery y crash recovery o
no. Esto archivos de log se conocen como active logs, y contienen los datos de transaccion en el
momento.
2. Userexit: Indica que si los usuarios pueden accesar los archivos de log mientras la base de datos
esta abierta o no.
3. Offline: Que no hay otra aplicacion puede usar la base de datos mientras la operacion de respaldo o
la de recuperacion esta en proceso.
4. Online: Que otras aplicaciones pueden conectar a la base de datos mientras la operacion de
respaldo o la de recuperacion esta en proceso.
5. Soporte OLAP: Para realizar analisis multidimensional y procesamiento analitico en linea, con
funciones de ROLLUP, CUBE y GROUPING SETS. Sopota STARS JOINS.
6. Data Warehousing: DB2 provee la infraestructura necesaria para soportar el proceso de toma de
decisiones en cualquier tamaño y tipo de organización. Resuleve la problemática a nivel
departamental (Data Marts) y aque un unico producto provee la capacidad para acceder a datos en
Oracle, Sybase, Informix, Microsoft SQL Server, VSAM, IMS y toda la familai DB2.
7. Data Minig: Posibilita el analisis orientado al descubrimiento de informacion escondida en los
datos, con modelizacion predictiva, segmentacion de la base de datos, analisis de vinculos o deteccion
de desviaciones.
8. Capacidad: se refiere al numero de usuarios y aplicaciones accedidas a la base de datos, la cual esta
en gran parte determinada por la capacidad de memoria, agentes, locks, entradas−salidas y
administración del almacenamiento.
9. Escalabilidad: Habilidad que posee la base de datos de expandirse y continuar exhibiendo las
mismas características operacionales y tiempos de respuesta.
10. Productos DB2 disponibles actualmente: DB2 Universal Database 5.0 (Personal Edition,
Workgroup, Enterprise) Y db2 Common Server 2.0 y DB2 Rarallel Edition 1.0 (versiones previas a
UDB) DB2 para OS/400. La diferncia entre el Common Server y DB2 UDB es que este agrupa las
funciones del DB2 Common Server con el DB2 Parallel, y puede funcionar en entornos SMP, MPP y
sistemas en cluster.
CONCLUSIONES
BIBLIOGRAFIA
31
URL
http://www.transarc.ibm.com
http://www.altavista.com
http://www.mamma.com
http://www.gseukdb2.org.uk/
http://www.soltel.com.uy/db2home.html
http://www−4.ibm.com/software/data/db2/udb/winos2unix/support/
2
>8 caracteres para el nombre de usuario (ID)
El tamaño del nombre de usuario que apoyó DB2 se ha aumentado de 8 carácteres a 30 carácteres.
Esto le da flexibilidad mayor al asignarle IDs al usuario.
OLE nativo el apoyo de DB2
DB2 es ahora ambos un OLE el proveedor de DB y un OLE DB
el consumidor. Este da apoyo a clientes con OLE y las aplicaciones DB−basado en la habilidad de
extraer o consultar los datos de DB2 de la interface de OLE nativa.
Además, usted puede cargar los datos en DB2 que usa OLE DB con funciones de tabla.
Microsoft® la integración de Visual Studio®
DB2 proporciona una colección de herramientas y
los wizard para simplificar la construcción y desplagamiento de aplicaciones para DB2 para Microsoft
Windows que usa SQL incluido dentro del Microsoft® C++® Integrated Visual el Ambiente de
Desarrollo
32