IBM DB2
¿Qué es DB2? DB2 es uno de los principales servidores de datos empresariales con un sistema de gestión híbrida de datos para datos relacionales y XML.
¿Para qué plataformas está disponible DB2? DB2 está disponible para diversas plataformas, tales como Linux, UNIX (AIX, Solaris, HP-UX), Windows, Mac OS, i5/OS y z/OS.
¿A qué versiones y plataformas DB2 se aplican estas Preguntas frecuentes? Estas Preguntas frecuentes hacen referencia a DB2 9.x para Linux, UNIX y Windows.. Windows
¿En qué tipo de aplicaciones se puede usar DB2? DB2 se puede usar para accionar una gran variedad de soluciones: Web, Web 2.0, SOA, transaccionales, de almacenamiento de datos, ERP, CRM y otras aplicaciones de bases de datos operativas y de negocios.
¿Qué idiomas de desarrollo de aplicaciones y API soporta DB2? Es posible desarrollar aplicaciones para DB2 usando C/C++, Cobol, Java, lenguajes .NET, PHP, Perl, Python, Ruby on Rails, etc. DB2 soporta las principales interfaces de desarrollo, tales como API basadas en SQL, entre las que se incluyen ODBC, OLE DB, JDBC, SQLJ, ADO.NET, Microsoft LINQ, CLI, Ruby on Rails Active Record, PHP PDO, Python, etc. DB2 también soporta el acceso a datos a través de servicios web estándar de la industria en los que se basan tanto RESTful como SOAP/XML.
¿Qué ediciones de DB2 para Linux, UNIX y Windows se encuentran disponibles? Se encuentran disponibles diversas ediciones de DB2, entre las que se incluyen: DB2 Express-C es una edición “freeware” de DB2 fácil de usar, que cuenta con capacidades de autogestión y que se puede incluir en aplicaciones y soluciones que requieran una base de datos incrustada. Es posible acceder a una suscripción y un soporte opcionales por un precio accesible. DB2 Express Edition es una edición básica y de bajo costo del servidor de datos DB2 orientada a pequeñas y medianas empresas que utiliza hasta 4 GB de memoria.
DB2 Workgroup Server Edition es el servidor de datos preferido para entornos departamentales, de grupos de trabajo y de medianas empresas, y utiliza hasta 16 GB de memoria. DB2 Enterprise Server Edition está diseñada para satisfacer las necesidades de servidores de datos de medianas y grandes empresas y es el servidor de datos ideal para las cargas de trabajo más demandantes. Se puede implementar en servidores de cualquier tamaño, ya sea con un procesador o con cientos de procesadores, y trae una gran variedad de características de gestión avanzada de datos.
DB2 y entornos de nube
¿DB2 está habilitado para la computación en nube? Sí, DB2 está totalmente habilitado para su implementación como base de datos en la nube. Debido a la versatilidad de las interfaces y del soporte para plataformas de DB2, el producto DB2 estándar se puede implementar en la nube de la misma manera que si se implementara dentro de las instalaciones del cliente. Con la ayuda adicional para implementaciones en la nube, ser reduce el tiempo de creación de valor de nuestros clientes.
¿Cuáles son los beneficios de la ejecución de DB2 en un entorno de nube? La computación en nube proporciona un modelo de pago por uso. Con este modelo, los usuarios no tienen que pagar por adelantado la infraestructura y las licencias de software, y solo pagan los recursos que necesitan. Los entornos de nube permiten aumentar y reducir la capacidad de manera dinámica, según las necesidades de cada usuario. DB2 es ideal para los entornos de nube, y todas las capacidades disponibles en las instalaciones del cliente también están presentes en la nube. Asimismo, a través de las interfaces de servicios web estándar de la industria y XML, DB2 permite la entrega de datos como servicio (DAAS).
¿En qué tipo de entornos de nube se puede implementar DB2? DB2 se puede implementar en entornos de nube públicos y privados. Aquellos clientes que generen sus propias nubes privadas pueden utilizar diversas tecnologías de virtualización compatibles con DB2 . En cuanto a las nubes públicas, es posible ejecutar DB2 en Amazon Web Services. Además de Amazon, IBM se ha asociado con proveedores como Rightscale, Morph, Corent, xkoto, etc. para suministrar soluciones DB2 con valor agregado en la nube. En el futuro, IBM podrá soportar plataformas de nube adicionales para DB2.
¿Qué es Amazon Web Services (AWS)?
AWS ofrece un conjunto de servicios integrados que forman una plataforma informática “en la nube”. Visite aws.amazon.com para obtener más información acerca de AWS.
¿Es posible ejecutar DB2 en el entorno de nube de Amazon? Sí, es posible ejecutar DB2 en Amazon Elastic Compute Cloud (EC2) y potenciar otros servicios de AWS como Elastic Block Storage (EBS).
Productos y servicios DB2 para AWS
¿Qué modelos de implementación están disponibles para DB2 en Amazon EC2? Es posible implementar DB2 en Amazon EC2 usando una de las siguientes opciones:
1. Cree sus propias AMI basadas en DB2 utilizando las licencias DB2 de las que es titular. 2. Utilice las AMI DB2 pregeneradas por IBM. (En la tarifa por hora de uso de las AMI generadas por IBM se incluyen los costos de licencias de software para DB2). ¿Puedo crear mis propias AMI basadas en DB2 para su uso en Amazon EC2? Sí, además de la posibilidad de usar las AMI DB2 generadas por IBM, podrá crear sus propias AMI basadas en DB2 para EC2. Si opta por crear sus propias AMI, usted será responsable de obtener las licencias del software (DB2, sistema operativo, etc.) que se ejecuten en la AMI. Si todavía no dispone de una licencia para DB2, puede descargar de manera gratuita DB2 Express-C y usarlo para crear una AMI.
¿Existe algún recurso que me ayude a crear mis propias AMI DB2? Sí, IBM ofrece scripts de muestra para automatizar la creación de AMI basadas en DB2. En ChannelDB2 encontrará una breve presentación en pantalla que demuestra el uso de estos scripts, así como el código de los mismos.
¿IBM ofrece AMI DB2 para su uso en Amazon EC2? Sí, IBM se ha asociado con AWS para ofrecer AMIs DB2 preinstaladas para desarrollo y producción que vienen con DB2 y el sistema operativo Linux preinstalados.
¿Es posible ejecutar DB2 en una AMI para Windows? Sí; sin embargo IBM no ofrece, por el momento, AMI basadas en Windows. Usted cuenta con la posibilidad de crear sus propias AMI para Windows con DB2.
¿Qué ediciones de DB2 se pueden usar en Amazon EC2? Es posible usar cualquier edición de DB2 en Amazon EC2, si usted crea su propia AMI con una licencia DB2 de su titularidad. Sin embargo, si desea utilizar AMI generadas por IBM, la edición de DB2 instalada en la AMI dependerá del tipo de AMI.
¿Cuáles son los distintos tipos de AMIs preinstaladas que están disponibles para DB2? IBM y AWS ofrecen dos tipos de AMIs DB2 pregeneradas en función del uso que se les pretende dar: AMIs DB2 para desarrollo, para comenzar a usar DB2 en Amazon EC2, y AMIs DB2 listas para producción (aranceladas), para implementar soluciones DB2 en Amazon EC2
AMIs DB2 para desarrollo
¿Para qué sirven las AMI DB2 para desarrollo que provee IBM? Las AMI DB2 para desarrollo están diseñadas para explorar y comenzar a usar DB2 en Amazon EC2. Se pueden usar a efectos de demostración, evaluación, capacitación gratuita, pruebas y desarrollo, y están sujetas a las cláusulas de la licencia de uso de AMI para desarrollo de IBM.
¿Qué edición de DB2 incluyen las AMI DB2 para desarrollo? Las AMI DB2 para desarrollo incluyen DB2 Express-C, la edición gratuita de DB2.
¿Es posible usar las AMI DB2 pregeneradas para desarrollo en cargas de trabajo de producción? No; si bien el desarrollo no es el único propósito de DB2 Express-C, las licencias de las AMI DB2 para desarrollo basadas en DB2 Express-C y del sistema operativo correspondiente se otorgan a fines ajenos a la producción. Sin embargo, si usted desea usar DB2 Express-C con fines productivos en Amazon EC2, puede descargar DB2 Express-C y crear su propia AMI. Otra opción es usar una AMI DB2 preincluida lista para producción, provista por AWS e IBM.
¿Cuánto cuesta usar las AMI DB2 para desarrollo que provee IBM? Como DB2 Express-C es una edición gratuita de DB2, usted no tendrá que pagar la licencia correspondiente. Solamente deberá abonar el arancel de uso de la infraestructura de Amazon, que puede costar tan solo USD 0,10 por hora. El precio de AWS dependerá del tamaño de la instancia EC2, y se puede estimar con la calculadora Simple Monthly Calculator de AWS.
¿Es posible ejecutar las AMI DB2 para desarrollo en cualquier tamaño de instancia EC2? Sí, las AMI para desarrollo basadas en DB2 Express-C se pueden ejecutar en cualquier tamaño de instancia EC2, independientemente de la cantidad de memoria y de núcleos virtuales; sin embargo, DB2 Express-C no puede utilizar más de 2 núcleos ni más de 2 GB de memoria. Los recursos de procesador y de memoria no utilizados por DB2 en una instancia EC2 podrán ser utilizados por otras aplicaciones que se ejecuten en esa instancia EC2.
¿Existe alguna restricción en cuanto al tamaño de la base de datos o al número de usuarios en las AMI DB2 Express-C para desarrollo que provee IBM? A diferencia de otros productos y servicios gratuitos o Express, IBM no impone ningún límite en cuanto al tamaño de la base de datos, al número de usuarios o a las conexiones de DB2 Express-C. Esta edición de DB2 no tiene plazo de vencimiento y se puede usar sin ningún costo de licencia DB2 durante un período ilimitado.
¿Qué sistema operativo utilizan las AMI DB2 para desarrollo? Las AMI DB2 para desarrollo han sido generadas con SUSE Linux Enterprise Server (SLES) 10 SP2.
¿Existen AMIs DB2 para desarrollo de 64 bits? Sí, las AMI para desarrollo que provee IBM vienen en versiones de 32 y de 64 bits.
¿Desde dónde se puede acceder a las AMI DB2 para desarrollo? Puede comenzar en la página Web de IBM de AMI DB2 para desarrollo , o visitar las páginas Web de AWS que contienen las entradas de catálogo de la versión de 32 bits y de la versión de 64 bits de las AMI DB2 para desarrollo.
¿Dónde se puede encontrar información para usar y ejecutar las AMI DB2? En la Guía de introducción a AMI DB2 encontrará instrucciones detalladas.
¿Es posible personalizar una AMI DB2 para desarrollo con software y configuración propios y guardarla para su reutilización? Sí, en la Guía de reinclusión de AMI DB2 encontrará las instrucciones correspondientes.
AMIs DB2 listas para producción
¿Existen AMIs DB2 preincluidas disponibles para su uso en producción?
Sí, existen AMIs DB2 listas para producción, disponibles a través de AWS (AMIs “aranceladas”).
¿Qué ediciones y versiones de DB2 están incluidas en las AMI listas para producción? Las AMI DB2 listas para producción de 32 bits incluyen DB2 Express; las AMI listas para producción de 64 bits incluyen DB2 Workgroup.
¿Es posible usar la edición DB2 Enterprise en Amazon EC2? Sí, usted puede crear su propia AMI con la licencia DB2 Enterprise y ejecutarla en EC2. Es posible descargar una edición de prueba de 90 días de DB2 Enterprise del sitio de IBM.
¿Cuál es el precio de las AMI DB2 listas para producción? Las AMI DB2 Express y DB2 Workgroup disponibles de AWS tienen un sistema de precios por hora de uso que depende del tamaño de la instancia en que se ejecutan las AMI. Además, existen otros precios por los servicios AWS adicionales que se utilicen, como EBS para almacenamiento de datos.
¿Qué sistema operativo usan las AMI DB2 listas para producción? Las AMI listas para producción han sido generadas con SUSE Linux Enterprise Server (SLES) 10 SP2.
¿Qué sistema operativo usan las AMI DB2 listas para producción? Las AMI listas para producción han sido generadas con SUSE Linux Enterprise Server (SLES) 10 SP2.
¿Qué tipo de soporte se encuentra disponible para las AMI DB2 listas para producción? Actualmente es posible obtener asistencia comunitaria en el grupo de noticias de DB2 de IBM y en los foros de AWS. Existen planes para implementar un servicio opcional de soporte premium para las AMI listas para producción, que estará disponible durante el año en curso.
¿Desde dónde se puede acceder a las AMI DB2 listas para producción? Puede comenzar en la página Web de IBM de AMI DB2 Express y DB2 Workgroup, o visitar las páginas Web de AWS que contienen las entradas de catálogo de AMI DB2 Express de 32 bits y de AMI DB2 Workgroup de 64 bits.
¿Dónde se puede encontrar información para usar y ejecutar las AMI DB2? En la Guía de introducción a AMI DB2 encontrará instrucciones detalladas.
¿Es posible personalizar las AMI DB2 listas para producción con aplicaciones y configuración propias y guardarlas para su reutilización? Sí, en la Guía de reinclusión de AMI DB2 encontrará las instrucciones correspondientes.
Todavía me quedan algunas preguntas sobre DB2 y AWS que no están incluidas en este documento. ¿Dónde puedo hacer esas preguntas? Puede exponerlas en el Foro de DB2, en IBM developerWorks.
Introducción 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. DB2 y SQL Server tenían grandes compañías detrás con otros negocios que les permitió aguantar la política agresiva de Oracle. Recientemente IBM adquirió Informix con lo que el mercado de las bases de datos comerciales en UNIX (Linux) quedó entre IBM y Oracle. Reseña Histórica 1970: Se da el origen del DB2, y pertenece a la firma IBM.
1983: Se empezó a vender DB2 con la versión 2.0. 1994:DB2 UDB (DB2 Universal Database) fue construido en base a dos productos incluidos en el DB2 de AIX, 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 Data Warehousing y Data Mining. En la actualidad la tecnología de gestión de datos de IBM es utilizada por más de 40 millones de usuarios de 300.000 empresas en todo el mundo. Mientras que la evolución del DB2, Universal Data Base dispone de más de 6 millones de usuarios y 1.300.000 licencias instaladas. Características Permite el manejo de objetos grandes (hasta 2 GB), la definición de datos y funciones por parte del usuario, el chequeo de integridad referencial, SQL recursivo, soporte multimedia: texto, imágenes, video, audio; queries paralelos, commit de dos fases, backup/recuperación on−line y offline. Además cuenta con un monitor gráfico de performance el cual posibilita observar el tiempo de ejecución de una sentencia SQL y corregir detalles para aumentar el rendimiento. Mediante los extensores se realiza el manejo de los datos no tradicionales, por ejemplo si tengo un donde tengo almacenados los curriculums de varias personas, mediante este puedo realizar búsquedas documentos con los datos que me interesen sin tener que ver los CV uno por uno. Esta capacidad se utiliza en sistemas de búsqueda de personas por huellas digitales, en sistemas información geográfica, etc. Internet es siempre la gran estrella, con DB2 es posible acceder a los datos usando JDBC (tan potente como escribir directamente C contra la base de datos), Java y SQL (tanto el SQL estático, como complementa el SQL dinámico).
Plataformas host:
OS/390(MVS), VM & VSE, OS/400
Plataformas de servidor:
OS/2 Warp Server, Sinix, SCO Openserver, Windows NT, Aix, HP Ux, Solaris.
Plataformas Cliente:
OS/2, DOS, Sinix, SCO OpenServer, Windows 3.1/95/NT, Macintosh System 7, Aix, HP Ux, Solaris.
Ventajas
Permite agilizar el tiempo de respuestas de esta consulta
Recuperación utilizando accesos de sólo índices.
Predicados correlacionados.
Tablas de resumen
Tablas replicadas
Uniones hash
DB2 utiliza una combinación de seguridad externa y control interno de acceso a proteger datos.
DB2 proporciona un juego de datos de acceso de las interfaces para los diferentes tipos de usuarios y aplicaciones.
DB2 guarda sus datos contra la pérdida, acceso desautorizado, o entradas inválidas.
Usted puede realizar la administración de la DB2 desde cualquier puesto de trabajo.
La tecnología de replicación heterogénea (heterogeneous replication) en SQL Server permite la publicación automática de los datos en otros sistemas que no sean SQL Server, entre los que se incluyen DB2.
La mayoría de los que utilizan equipos IBM utilizan DB2 porque es confiable y tiene un muy buen soporte técnico".
El DB2 se basa en dos ejes que lo hacen fuerte en su rendimiento: utiliza un sistema multiprocesador (SMP) simétrico y un sistema de procesador paralelo masivo.
el DB2 distribuye y recuerda la ubicación de cada pista donde se encuentra la información. En el contexto de una larga base de datos, este sistema de partición hace que la administración sea mucho más fácil de manejar que una base de datos de la misma medida no particionada.
La base de datos se puede programar para tener una exacta cantidad de particiones que contienen la información del usuario, índice, clave de transacción y archivos de configuración. De esta forma, los administradores definen grupos de nodos, que son una serie de particiones de la base, lo que posteriormente facilita cualquier búsqueda. Desventajas
El DB2 - IBM es la tercera base de datos que más se vende, de acuerdo con los VARs recientemente encuestados en el número de junio de 1996 de la revista VAR Business Magazine. El Microsoft SQL Server se anotó un 38%, Oracle, 21%, IBM, 10%, Informix, 9%, y Sybase un 8%.
En sistemas grandes la base más usada es DB2 ya que corre en diferentes plataformas operativas, pero en realidad, en la mayoría de los casos la decisión para optar por un software de estas características es corporativa.
Se tiene que ver con las aplicaciones que se tienen desarrolladas y las que se van a implementar.
Influye en la elección el hardware utilizado.
Una serie de error del sistema operativo, que cae DB2. Compatibilidad Las plataformas que admite el producto son en principio OS/2, Windows NT y UNIX. Esta última versión del software del servidor, ha sido adaptado para funcionar también con OS/2 WARP, HP−UX, AIX, SCO−UNIX UE7, Windows 98, NT y Solaris. Esta nueva versión persigue inclinar la balanza hacia un producto que ha ido ganado adeptos de forma espectacular desde aquella primera versión con tecnología de Sybase. Sobre todo, por que a parte de unas consideraciones técnicas tiene todo el empuje comercial y de soporte de Microsoft. Se podría decir que en cierta medida pretende ser el servidor de bases de datos genérico para Windows. No tanto por que la causa de desarrolla sea la misma, ni siquiera porque el SQL Server, a diferencia de otros servidores solo trabaja bajo Windows, sino porque Microsoft promete integración con todos los productos suyos (por ejemplo MsOffice 2000, ya que Access 2000 traerá consigo un nuevo MSDE−DATA−Engine, como alternativa al existente y compatible con SQL Server). También será posible llamar a SQL Server desde MS− Access. DB2 es el sistema relacional de IBM y es una de las bases de datos relaciónales más antiguas en el mercado. Se usa principalmente en sistemas de computadoras mainframe como AS/400 y RS/6000. Esta base de datos proporciona características avanzadas y se usa principalmente para soluciones de base de datos a gran escala. Se dice también ser la base de datos más utilizada en el mundo. Más que Oracle. Más que Microsoft SQL. ¿Por qué? Porque es la que mejor responde a las exigencias del e−business de hoy. Detrás del e−business está siempre una base de datos. Con la versión 7.1 de DB2 Universal Database, se reduce a la mitad el tiempo de implantación de las soluciones y la velocidad de búsqueda es ahora 10 veces superior que la de sus competidores DB2 cubre todas las áreas imaginables y t odos los productos necesarios para responder a las necesidades de un e−business del futuro. Este paquete
contiene todas las herramientas que usted necesita para construir una aplicación de datos para la Web, incluyendo DB2 Extenders, DB2 Connect, Net.Data, Visual Age para Java y Websphere.
Escalabilidad
DB2 Universal Database de IBM es el primer y el único servidor de bases de datos del mundo cuya escalabilidad va desde un computador de bolsillo a una laptop, a un servidor de rango mediano, a clusters de servidores para servidores empresariales masivamente paralelos.... a través de 23 plataformas en 14 lenguajes con una sólida confiabilidad. Plataformas que soportan Windows NT en español, OS/2, y "sabores" populares de UNIX incluyendo Linux, AS/400 y OS/390. Conclusiones 1. 2. El tamaño del nombre de usuario que apoyó DB2 se ha aumentado de 8 caracteres a 30 caracteres. Esto le da flexibilidad mayor al asignarle IDS al usuario. 3. 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 interfase de OLE nativa.Además, usted puede cargar los datos en DB2 que usa OLE DB con funciones de tabla. 4. Microsoft la integración de Visual Studio. 5. 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. 6. se da a conocer la reseña histórica que dio origen a la creación de la base de datos DB2 perteneciente a IBM. 7. las características principales que describen la base de datos de DB2-IBM. 8. las ventajas que ofrece esta base de datos a los usuarios al momento de utilizarlo. 9. las desventajas que posee hacen del riesgo que corre DB2.
DB2 DB2 es una marca comercial, propiedad de IBM, bajo la cual se comercializa un sistema de gestión de base de datos. DB2 versión 9 es un motor de base de datos relacional que integra XML de manera nativa, lo que IBM ha llamado pureXML, que permite almacenar documentos completos dentro del tipo de datos xml para realizar operaciones y búsquedas de manera jerárquica dentro de éste, e integrarlo con búsquedas relacionales. La compatibilidad implementada en la última versión, hace posible la importación de los datos a DB2 en una media de 1 o 2 semanas, ejecutando PL/SQL de forma nativa en el gestor IBM DB2
La automatización es una de sus características más importantes, ya que permite eliminar tareas rutinarias y permitiendo que el almacenamiento de datos sea más ligero, utilizando menos hardware y reduciendo las necesidades de consumo de alimentación y servidores. La memoria se ajusta y se optimiza el rendimiento del sistema, con un interesante sistema que permite resolver problemas de forma automática e incluso adelantarse a su aparición, configurando automáticamente el sistema y gestión de los valores.
DB2 Express-C es la versión gratuita soportada por la comunidad de DB2 que permite desarrollar, implementar y distribuir aplicaciones que no usen las características avanzadas de las versiones comerciales de DB2. Esta versión de DB2 puede ser concebida como el núcleo de DB2, las diferentes ediciones incluyen las características de Express-C más funcionalidades específicas. DB2 para Linux, UNIX y Windows permite la automatización de tareas, reducción de las necesidades de consumo de alimentación, un alto rendimiento que reduce los servidores necesarios para ejecutar la base de datos, escalabilidad sencilla y alta disponibilidad en su arquitectura de discos de datos y otras soluciones que facilitan la colaboración entre profesionales.
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.
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.
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 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? 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. 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:
o
o
o
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.
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
o
o
o
o
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. 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: Online archived logs , que son guardados en
el directorio de la base de datos.
Offline archived logs , que no se encuentran
en el directorio de la base de datos.
III - 2. Recovery history file Un RHF (Recovery History File) es creado con cada base de datos, y se actualiza automaticamente cuando hay: o
Respaldo de una base de datos o un tablespace
o
Recuperacion de una base de datos o un tablespace
o
Roll forward de una base de datos o un tablespace
o
Alter un tablespace
o
Renombrar un tablespace
o
Cargar una tabla
o
Actualizar una tabla
o
o
o
o
o
o
o
o
o
o
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. 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:
o
o
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 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 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
o
o
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.
o
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: o
RESTRICT or NO ACTION; ocurre un error y las filas no son eliminadas.
o
CASCADE; La operación de eliminación se propaga de la fila dependiente “p” a “D”.
o
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: o
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.
o
o
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. o
Si las filas “D” son eliminadas, la operación de eliminado en “P” se dice que se ext endió 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 el iminado 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”.
Hay tres tipos de restricciones:
o
o
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
o
o
o
o
o
o
o
o
o
o
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 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)
o
o
o
o
o
o
o
o
o
o
o
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) 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 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 trigge r 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.
o
o
o
o
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 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. 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
o
o
o
o
o
o
o
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 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
Si cualquier filas existen en la tabla dependiente, entonces el registro de la llave primaria en la tabla del padre no puede ser borrada.
DELETE CASCADE
Si un registro de la tabla padre de la llave primaria es borrado, entonces, todos los registros de la tabla dependiente son borrados.
DELETE NEUTRALIZE
Si se borra un registro de la llave primaria de la tabla padre, todos los registros dependientes serán definidos como Null.
UPDATE RESTRICT
Si un registro existe en la tabla dependiente, la columna de la llave primaria en la tabla padre no puede ser modificado.
UPDATE CASCADE
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.
UPDATE NEUTRALIZE
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.
INSERT RESTRICT
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.
FK UPDATE RESTRICTION
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.
PENDANT DELETE
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.
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 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: o
Regular Tablespace
o
Long Tablespace
o
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. Se utiliza temporary tablespace para almacenar datos requeritos durante las operaciones de SQL. El temporary tablespace se llama TEMPSPACE1 por default.
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
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.
o
o
o
o
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 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,
) Not Null, nombre Varchar( 30 puesto Char( 10 ) Check( puesto In( `Vendedor', `Cajero', `Encargado' )), fecha_ing Date, salario Decimal( 7, 2 ) Check( salario >= 0 ),
o
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
o
o
o
o
o
Server servidor 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 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. o
o
o
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 tr igger debe ser activado.
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. o
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. 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 o
o
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 -long vargraphic, longitud variable de 1-16350byte -date, -time, -timestamp, CREATE USER -EjemploCREATE 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
o
o
o
REVOKE CONNECT ON DATABASE FROM usuario REVOKE SELECT ON tabla FROM usuario CREATE TABLE -EjemploCREATE 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) ) IN recurso_humano CREATE TABLE para almacenar foto y voz -EjemploCREATE 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 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: s e 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: Habi lidad 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.
Funciones de IBM DB2 db2_autocommit — Devuelve o establece el estado de AUTOCOMMIT en una conexión de bases de datos db2_bind_param — Vincula una variable PHP a un parámetro de una sentencia SQL db2_client_info — Devuelve un objeto cuyas propiedades describen cliente de una base de datos DB2 db2_close — Cierra una conexión a base de datos db2_column_privileges — Obtiene la lista de columnas y permisos asociados a una tabla db2_columns — Devuelve los campos de una tabla y sus metadatos asociados.
Requerimientos Para conectar a IBM DB2 Universal Database para Linux, Unix y Windows, o a IBM Cloudscape, o a Apache Derby, se debe instalar el cliente de IBM DB2 Universal Database en el mismo equipo en que se ejecuta PHP. Esta extensión se ha desarrollado y probado con DB2 Version 8.2. Para conectar a IBM DB2 Universal Database en z/OS o iSeries, es necesario también IBM DB2 Connect o un software enrutador DRDA equivalente.
DB2 Multiplatform Tools Ayuda a simplificar la gestión de las tareas rutinarias y complejas de las bases de datos
La solución DB2 Multiplatform Tools para Linux, Unix y Microsoft Windows simplifica la gestión de las tareas rutinarias y complejas de las bases de datos, lo que ayuda a los administradores a mantener el control incluso en los entornos de bases de datos más complejos. Dispone de los siguientes componentes de DB2 Multiplatform Tools:
DB2 Change Management Expert for Multiplatforms ofrece funciones de investigación para ayudar a los DBAs a entender las relaciones entre datos, las especificaciones de resultados y la ejecución de los mandatos de cambio.
o o
o
o o o
o
o
o o
o o
o
o
o o o
DB2 Data Archive Expert para Multiplatforms es una herramienta autónoma que permite archivar y recuperar objetos de datos DB2 de un modo rápido, flexible y eficaz. Facilita: El aumento del rendimiento de su entorno DB2 UDB. La reducción de los costes de almacenamiento en discos, mediante la transferencia de los datos poco utilizados a soportes más económicos. La disminución de los costes de administración de bases de datos al mejorar la eficacia de las aplicaciones. DB2 High Performance Unload para Multiplatforms es una herramienta que permite descargar, extraer y volver a particionar los datos de las bases de datos DB2 muy rápidamente. Ofrece: Mayor rendimiento. Nuevas opciones de extracción desde las copias de seguridad de DB2. Nuevas funciones de partición adicional. Mejor soporte para la autorización de DB2 Varios formatos de salida y soporte para varias plataformas. DB2 Performance Expert para Multiplatforms ayuda a los administradores de bases de datos (DBAs) a simplificar las tareas de ajuste y de gestión del rendimiento. Facilita a los DBAs: La creación de análisis más completos y detallados sobre el rendimiento del sistema, en función de los datos obtenidos de DB2 y del sistema operativo. La recepción rápida de avisos relacionados con los atascos de espacios de tablas. La previsión de problemas emergentes relacionados con el rendimiento de DB2 y un acceso más rápido a las condiciones de excepción. Una supervisión simplificada y mayor eficacia en las tareas. La configuración fácil y rápida de la herramienta recién adquirida, incluso en grandes entornos con varias plataformas. IBM DB2 Recovery Expert para Multiplatforms proporciona potentes funciones de diagnóstico, informes y recuperación automatizada para mantener la precisión de los datos y una alta disponibilidad. Entre las últimas mejoras se incluyen las siguientes: Función de copia de seguridad rápida mediante el hardware de disco FlashCopy (R) y Snapshot. Soporte del componente DB2 Grouper para facilitar la recuperación y realización de copias de seguridad en el ámbito de la aplicación. Soporte de recuperación para otros tipos de objetos. Soporte ampliado de análisis de registros para objetos grandes (LOBs). Capacidad de mantenimiento para reducir el depósito de versiones. DB2 Test Database Generator for Multiplatforms permite crear fácilmente subconjuntos de datos de producción DB2 y ocultar los datos confidenciales o importantes, como los números de identificación, los salarios, las direcciones o la información financiera. Permite responder rápidamente a la necesidad de realizar pruebas y, al mismo tiempo, protege los datos privados y evita la asunción innecesaria de responsabilidades.
DB2 Table Editor accede, con rapidez y facilidad, a los datos de diferentes plataformas de bases de datos DB2, como Informix Dynamic Server 9.x, y permite actualizarlos y suprimirlos. Da soporte a las funciones más importantes de DB2, así como la integridad referencial y la seguridad de DB2 existente, además de a las funciones avanzadas de DB2, como un amplio soporte a objetos. DB2 Web Query Tool conecta directamente a los usuarios con varias bases de datos empresariales, de una manera segura y simultánea, e incluye soporte para Informix Dynamic Server 9.x. Su funcionalidad SWL avanzada le permitirá obtener el máximo rendimiento de las bases de datos DB2. IBM Database Encryption Expert para Linux, UNIX y Windows, V1.1.0 protege los datos del acceso no autorizado mediante cifrado, algo requerido o muy recomendado por la mayoría de las leyes de conformidad normativa. DB2 Audit Management Expert for Multiplatforms V1.1.0 ofrece la posibilidad de auditar de forma selectiva inserciones, actualizaciones, eliminaciones y lecturas en sistemas DB2. Puede ayudar a su personal de IT a cumplir los requisitos crecientes de conformidad normativa. Además, el DB2 Toolkit for Multiplatforms combina cinco herramientas DB2 seleccionadas en un único paquete. El kit de herramientas le permite adquirir las siguientes componentes de DB2 Multiplatform Tools, al adquirir una licencia, con un importante ahorro:
IBM DB2 Data Archive Expert for Multiplatforms IBM DB2 High Performance Unload for Multiplatforms IBM DB2 Performance Expert for Multiplatforms IBM DB2 Recovery Expert for Multiplatforms IBM DB2 Test Database Generator for Multiplatforms
Grandes razones para elegir DB2 Universal Database
Fácil y simple
Muchos expertos de la industria y usuarios han elogiado las nuevas herramientas que IBM desarrolló para facilitar la administración y uso del DB2 Universal Database. Utiliza una interfase gráfica, estilo browser, para acceder y manejar objetos de la base de datos. Incluye “ smart.guides ” que facilitan la tarea de configuración, guiándolo paso a paso para lograr un rendimiento óptimo
de la base de datos y para asistir al usuario en la creación de teclas con plantillas predefinidas. Las herramientas mencionadas, más otras incluidas en DB2 Universal Database, están listas para ser integradas a Tivoli.
Aplicaciones existentes existentes
Más del 70% de las empresas top del mundo confían en DB2 Universal Database para manejar aplicaciones críticas. Si su empresa es una de ellas, usted puede aprovechar su conocimiento para poner en funcionamiento todas estas aplicaciones aplicaciones de negocios:
On-line Transaction Processing (OLTP) Data Warehousing Decision Support Data Mining
Si usted está evaluando DB2 Universal Database por primera vez, considere los beneficios a corto y largo plazo al utilizar un código base unificado para todas sus aplicaciones, y para todas sus plataformas, desde laptops hasta sistemas de procesamiento paralelo.
Además, usted dispone de numerosas aplicaciones desarrolladas a nivel mundial, entre ellas las de SAP, People Soft. y Baan.
Herramientas de replicación
La replicación de datos es la tecnología clave para aprovechar todo el poder de los ambientes distribuidos ya que le permite enviar los datos a cualquier sitio para cubrir todos los requerimientos de su empresa; desde oficinas centrales a sucursales, usuarios móviles, proveedores, clientes y socios de negocios. DB2 Universal Database incluye todo lo necesario para implementar una so lución de replicación de datos en cualquier tipo de ambiente distribuido o heterogéneo.
Soporte OLAP
DB2 Universal Database ofrece nuevas capacidades para ayudarlo a realizar análisis multidimensional y procesamiento analítico en línea (OLAP). Incluye funciones de ROLLUP, CUBE y grouping sets. Soporta STAR JOINS. Estas facilidades son utilizadas normalmente en todas las aplicaciones de business intelligence.
Lista para Internet
Gracias a su alcance global y bajo costo, Internet puede ser una solución de negocios muy poderosa. Si usted quiere realmente aprovechar las oportunidades de negocios utilizando la Web, considere la mejor manera de llegar a un mercado que lo está esperando 1as 24 horas de los 7 días de la semana. La base de datos que seleccione debe estar preparada para brindar acceso rápido y alta disponibilidad a información que requiere actualización constante. DB2 Universal Database provee la capacidad de hacer backups en línea, evitando interrupciones en la disponibilidad del sistema. Permite realizar operaciones comerciales garantizando un alto nivel de seguridad y confiabilidad.
DB2 cumple con todos estos requerimientos y mucho más:
Soporta el paradigma de network-computing network-computing utilizando Java y JDBC
Permite el acceso a DB2 Universal Database desde una amplia variedad de plataformas de clientes, utilizando JDBC vía Java applets desde cualquier Web Browser. Adicionalmente, usted puede desarrollar una aplicación Fen Java y acceder a DB2 utilizando directamente JDBC. También permite codificar codificar “ stored procedures” en Java. Java.
Brinda excelente nivel de seguridad
Brinda servicios de autenticación y autorización que pueden ser fácilmente integrados a servicios de redes y sistemas operativos.
Net.Data brinda acceso a sus datos corporativos desde la Web
Ofreciendo un alto nivel de performance y escalabilidad en el acceso de datos residentes en DB2 Univcsal Database, incorporando multimedia.
Multimedia, una ventaja a tener en cuenta
DB2 Universal Database incluye la capacidad nativa de almacenar variados tipos de datos: alfanuméricos, video, imagen, audio y los que usted defina. Algunas alternativas, a veces más caras, solamente proveen una capacidad incompleta y una integración limitada. Otra gran diferencia: la escalabilidad de DB2 Universal Database permite el almacenamiento de grandes volúmenes de datos aprovechando al máximo la capacidad de las plataformas soportadas por DB2. Aunque no esté utilizando aplicaciones avanzadas basadas en multimedia, lo invitarnos a analizar los beneficios. Estos lo ayudarán a minimizar los costos y tiempos relacionados con el manejo usual de la documentación que fluye en su empresa. DB2 Universal Database permite realizar búsquedas sofisticadas e inteligentes en cualquier documento utilizando innumerables criterios.
Además, permite que el usuario defina funciones -llamadas UDFs- y tipos de datos propios llamados UDTs. Estos facilitan enormemente la tarea de administración de datos por parte de los
desarrolladores, asegurando la consistencia de los mismos y minimizando los errores por operaciones inválidas.
Formida Software Corp. ha desarrollado una solución para la industria de la salud, que incluye las capacidades multimedia de DB2 Universal Database. La aplicación maneja datos complejos, tales como: imágenes de rayos X, gráficos, video, mapas para la localización de médicos y hospitales, además de archivos de historias clínicas e información de seguros.
Introducción
DB2 UNIVERSAL DATABASE ( DB2 UDB )
DB2 (R) Universal Database, es una base de datos universal. Es completamente escalable, veloz y confiable. Corre en modo nativo en casi todas las plataformas, como Windows NT (R), Sun Solaris, HP-UX, AIX(R), OS/400 y OS/2(R).
Características y funciones:
DB2 UDB es el producto principal de la estrategia de Data Management de IBM. DB2 UDB es un sistema para administración de bases de datos relacionales (RDBMS) multiplataforma, especialmente diseñada para ambientes distribuidos, permitiendo que los usuarios locales compartan información con los recursos centrales.
Historia :
DB2 UDB no es un producto nuevo. Fue construido en base a dos productos incluidos en el DB2 de AIX en el año 1994: 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 Data Warehousing y Data Mining.
Integridad :
DB2 UDB incluye características de integridad, asegurando la protección de sus datos aún en caso de que los sistemas sufran un colapso; y de seguridad, permitiendo realizar respaldos en línea con distintos grados de granularidad, sin que esto afecte la disponibilidad de acceso a los datos por parte de los usuarios.
Múltiples usos :
Provee la capacidad de hacer frente a múltiples necesidades, desde procesamiento transaccional de misión crítica (OLTP), hasta análisis exhaustivo de los datos para el soporte a la toma de decisiones (OLAP).
Escalabilidad :
Sus características distintivas de escalabilidad le permiten almacenar información en un amplio rango de equipos, desde una PC portátil hasta un complejo ambiente de mainframes procesando en paralelo.
Web enabled para E-business :
Incluye tecnología basada en Web que permite generar aplicaciones en sus Intranets y responder a las oportunidades de negocios disponibles en Internet. Además, DB2 UDB provee soporte a Java.
Facilidad de instalación y uso :
La primera versión de DB2 para NT fue reconocida en el mercado como una base de datos muy poderosa, pero difícil de instalar y usar. En esta versión (DB2 UDB), IBM agregó muchas herramientas gráficas para facilitar el uso tanto de usuarios, como administradores y desarrolladores. Incluye guías para operaciones como instalación, configuración de performance, setup, etc. Además, se agregaron herramientas para facilitar las tareas de integración con otras bases de datos, tecnologías de networking y desarrollo de aplicaciones.
Universalidad :
DB2 UDB es, además, la única base de datos realmente universal: es multiplataforma (16 plataformas - 10 no IBM), brinda soporte a un amplio rango de clientes, soporta el acceso de los datos desde Internet y permite almacenar todo tipo de datos incluyendo texto, audio, imágenes y video o cualquier otro definido por el usuario.
Funciones complementarias
Conectividad
Las herramientas de conectividad permiten acceder a los datos más allá de donde ellos se encuentren. El slogan 'cualquier cliente, a cualquier servidor, en cualquier red' está completamente sustentado por la funcionalidad que sus herramientas ofrecen. EL DB2 Connect le permiten acceder a sus datos de DB2 en mainframe o AS/400, desde Windows NT, Windows 95 / 98, OS/2 o cualquiera de los Unix soportados. Además, el producto Datajoiner posibilita acceder de forma única y transparente a los datos residentes en Oracle, Sybase, Informix, Microsoft SQL Server, IMS, VSAM y otros.
Data Warehousing
DB2 UDB provee la infraestructura necesaria para soportar el proceso de toma de decisiones en cualquier tamaño y tipo de organización. Es el producto dirigido a resolver la problemática a nivel departamental (Data Marts), ya que un único producto provee la capacidad para acceder a datos en Oracle, Sybase, Informix, Microsoft SQL Server, VSAM o IMS, además de la familia DB2. Permite de forma totalmente gráfica acceder, transformar y distribuir los datos automáticamente y sin programar una línea de código.
Data Mining
DB2 UDB posibilita el análisis orientado al descubrimiento de información escondida en los datos, realizando modelización predictiva, segmentación de la base de datos, análisis de vínculos, o detección de desviaciones. Incluye las siguientes técnicas: clustering (segmentación), clasificación, predicción, descubrimiento asociativo, descubrimiento secuencial de patrones y secuencias temporales. Todas las técnicas mencionadas permiten realizar segmentación de clientes, detección de fraudes, retención de clientes, ventas cruzadas, etc.
Integridad Referencial
Restricciones
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.
Restricciones preferenciales
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.
Conceptos
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 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.
RULE-INSERT (Regla de 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 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:
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”.
Funciones Incorporadas Hay numerosas nuevas funciones incorporadas en el UDB de DB2. Esta sección mostrara solo unos cortos ejemplos de las funciones que están disponibles para ser usadas.
Funciones Aritméticas
Hay abundantes nuevas funciones en UDB de DB2. Las siguientes SQL demuestran muchas de las nuevas funciones matemáticas que están disponibles para el usuario.
VALUES
('SQRT(2) ',SQRT(2)), ('EXP(2) ',EXP(2)), ('SIN(.5) ',SIN(.5)), ('COS(.5) ',COS(.5)), ('TAN(1) ',TAN(1)), ('LOG(57) ',LOG(57)), ('ATAN(0) ',ATAN(0)), ('RAND() ',RAND()), ('CEIL(4.3) ',CEIL(4.3)), ('FLOOR(3.6)',FLOOR(3.6)), ('QUARTER() ',QUARTER(CURRENT DATE)), ('WEEK() ',WEEK(CURRENT DATE))
Funciones de text SELECT LASTNAME FROM EMPLOYEE
WHERE SOUNDEX(LASTNAME) = SOUNDEX('SMITH')
Funciones definidas por el usuario Las funciones definidas por el usuario son extensiones a lo que ya esta creado en las funciones del lenguaje SQL. Las funciones creadas por el usuario pueden ser:
-Función escalar, la cual devuelve un valor cada vez que se la invoca -Función columna, donde se pasa un conjunto de valores y devuelve un valor único para el conjunto -Función tabla, que devuelve una tabla
Una función definida por el usuario del tipo escalar o en columna registrada en la base de datos puede ser referenciada en el mismo contexto que cualquier función predefinida
Una función definida por el usuario del tipo de tabla registrada en la base de datos puede ser referenciada solo en el FROM de la cláusula SELECT
Una función definida por el usuario se invoca con su nombre, seguido de los argumentos entre paréntesis (if any)
Los argumentos de la función deben corresponder en numero y posición con los parámetros especificados en la función definida por el usuario como fueron registrados en la base de datos. En resumen, los argumentos deben ser del tipo de datos correspondientes a los parámetros definidos.
El resultado de la función es, como en la cláusula RETURN, especificado cuando la función definida por el usuario fue registrada. La cláusula RETURN determina si una función es del tipo tabla o no.
Si la cláusula NOT NULL CALL fue especificada (o esta por defecto) cuando la función fue registrada, y si algún argumento es nulo, entonces el resultado es nulo. Para las funciones del tipo tabla, esto significa el retorno de una tabla sin registros (tabla vacía).
Ejemplos:
Supongamos que una función escalar llamada ADDRESS fue escrita para extraer la dirección de un formato de script. La función ADDRESS recibe un argumento CLOB y devuelve un VARCHAR(4000). El siguiente ejemplo muestra la llamada a la función ADDRESS SELECT EMPNO, ADDRESS(RESUME) FROM EMP_RESUME
WHERE RESUME_FORMAT = 'SCRIPT'
Supongamos que tenemos una tabla T2 con una columna numérica A y la función ADDRESS del ejemplo anterior. El siguiente ejemplo demuestra la intención de invocar a la función ADDRESS con un argumento incorrecto. SELECT ADDRESS(A) FROM T2
Un error (SQLSTATE 42884) aparece porque no hay una función con el mismo nombre y con un parámetro correcto desde el argumento.
Supongamos que una función del tipo tabla WHO fue escrita para devolver información sobre las sesiones en la maquina del servidor que estaban activas en el momento de la ejecución. El siguiente ejemplo muestra la llamada de WHO en una cláusula FROM. SELECT ID, START_DATE, ORIG_MACHINE FROM TABLE( WHO() ) AS QQ WHERE START_DATE LIKE 'MAY%'
Los nombres de columna de la tabla WHO() están definidos en el estado de CREAR FUNCION
Tablas de Funciones
Una función de tabla es una UDF externa la cual entrega en una tabla del SQL en la cual ese es referenciado. Una tabla de función referenciada es solo valida en una cláusula FROM de un SELECT. Donde usando la tabla de funciones, se observa lo siguiente:
Aun cuando una tabla de función entrega una tabla, la interfase física entre el DB2 y la UDF es one-row-at-a-time (una fila a la vez). Hay tres tipos de formas de llamar una tabla de función: OPEN, FETCH y CLOSE. El mismo mecanismo call-type que puede ser usado para funciones escalares es usado para distinguir estos llamados.
La interfase estándar usada entre DB2 y las funciones escalares definidas por usuarios se extiende hasta acomodarse en la tabla de funciones. El SQL-result se repite por tabla de función, en cualquier instancia correspondiendo a una columna que puede ser retornada con lo que definimos una cláusula RETURNS TABLE de la CREATE FUNCTION. El argumento SQLresult-ind asimismo se repite, cualquiera de las instancias relatadas se corresponden con la instancia SQL-result . No todos los resultados de las columnas definidas en la cláusula RETURN de la CREATE FUNCTION de la tabla de función tienen que ser retornadas. La clave DBINFO de CREATE FUNCTION, y correspondiendo al argumento habilitado dbinfo, la optimización que solo estas columnas necesitan para una tabla en particular referenciada ser retornada.
Los valores de las columnas individuales retornadas conformen con el formato a los valores retornados para funciones escalares.
La CREATE FUNCTION para una tabla de función tiene una CARDINALITY n especifica. Esta especificación se define para informar al optimizador del DB2 del tamaño aproximado del resultado de modo que el optimizador pueda tomar mejores decisiones cuando la función es referenciada.
Anidar o Establecer Tablas de Expresión Tablas de Expresión Una tabla de expresión crea una tabla de resultados temporales desde una simple consulta. Además de estas refinan la tabla de resultados.
Tablas de Expresión Común Una tabla de estas características se relaciona con querer tener una vista temporal dentro de una consulta compleja y puede ser referenciada en otros lugares dentro de la misma consulta.
Por ejemplo, en lugar de la vista, se evita creando una vista. Cualquier uso de una tabla específica de expresión común dentro de una consulta compleja comparte la misma vista temporal.
El uso recursivo de la tabla común de expresión dentro de una consulta pueden ser usadas para soportar aplicaciones tales como conteo de materiales, sistemas de reservación aéreo y planeamiento de una red.
Usando la recursividad del nombre de una tabla común de expresión podremos usar la misma tabla de resultados en cualquier momento. Estos son diferentes desde una vista, con la cual podemos determinar el resultado de la tabla para cualquier referencia con posibilidad de diferentes resultados.
El aprovechamiento del uso y una mejor performance son equivalentes a aquellas con tablas de expresión anidadas. La performance puede ser mejorada por la reutilización del resultado del set de una tabla de expresión común cuando las referencias múltiples son hechas dentro del fullselect. Por ejemplo, en el seguimiento de consultas se utiliza el mismo resultado de la tabla dos veces.
WITH DTSUM (WORKDEPT, AVGSAL) AS ( SELECT WORKDEPT, AVG(SALARY) FROM EMPLOYEE
WHERE EDLEVEL > :hv1 GROUP BY WORKDEPT ) D1, SELECT D1.WORKDEPT, D1.AVGSAL, D2.WORKDEPT, D2.AVGSALDTSUM D2 WHERE D1.AVGSAL > 1.1 * D2.AVGSAL;
En esta consulta se lista un par de departamentos, donde los empleados considerados en cualquier departamento han logrado algún mínimo nivel de educación, y donde el salario promedio del primer departamento sea mimo el 10% mayor que el salario promedio del segundo departamento.
En cualquier ejecución de la consulta se puede especificar diferentes niveles de educación mínimo. Para ejecutar cualquier resultado utilizando vistas, una vista diferente podría haber sido creada para cualquier nivel de educación requerida.
OUTER JOIN Existen 3 tipos de outer join:
El outer join izquierdo incluyendo las filas de la tabla izquierda que no están macheadas con valores de la tabla derecha. A estas filas se le asigna el valor nulo por la información perdida.
El outer join derecho incluye filas de la tabla derecha que no estan macheadas con valores de la tabla izquierda. A estas filas se le asigna el valor nulo por la información perdida.
El outer join completo incluye ambas clases de filas.
El inner join puede lograrse como tablas cruzadas de producto (combinando cada fila de la tabla izquierda con todas las filas de la tabla derecha) manteniendo solamente las filas donde la condición de join es verdadera.
La tabla resultante puede perder filas de una o ambas tablas utilizadas. Outer joins incluye el inner join y preserva esas filas perdidas.
Los join pueden estar anidados dentro de otros joins. El orden generalmente va de izquierda a derecha, pero depende de las condiciones requeridas por los joins.
Resultados de operaciones entre T1 y T2:
El resultado de T1 INNER JOIN T2 consiste en los pares de filas donde la condición del join es verdadera.
El resultado de T1 LEFT OUTER JOIN T2 consiste en los pares de filas donde la condición del join es verdadera y por cada fila sin par de T1, la concatenación de esa fila con la fila nula de T2.
El resultado de T1 RIGHT OUTER JOIN T2 consiste en las filas pares donde la condición del join es verdadera y, por cada fila sin par de T2 la concatenación de esas filas con las filas nulas de T1.
El resultado de T1 FULL OUTER JOIN T2 consiste en las filas pares y por cada fila sin par de T2, la concatenación de esas filas con las filas nulas de T1, y por cada fila sin par de T1, la concatenación de esas filas con las filas nulas de T2.
Todas las columnas de T1 y T2 permiten valores nulos
COURSES
QUARTER
SUBJECT
TEACHER
ENROLLMAN
Fall 96
Math 101
Mr.Glenn
40
Fall 96
English 280
Ms.Redding
30
Fall 96
Science 580
Ms.Redding
33
Fall 96
Physics 405
Mrs.Plummer
28
Fall 96
Latin 237
Mr.Glenn
20
Fall 96
German 130 Staff
Winter 96 French 140
Ms. Barnes
31 (null)
WITH Innerjoin(name, rank, subject, enrollment) AS (SELECT t.name, t.rank, c.subject, c.enrollment FROM teachers AS t, courses AS c WHERE t.name =c.teacher AND c.quarter = ´Fall 96´), Teacher_only(name, rank) AS (SELECT name, rank FROM teachers EXCEPT ALL SELECT name, rank FROM innerjoin), Course_only(subject, enrollment) AS (SELECT subject, enrollment FROM courses WHERE quarter = ´Fall 96´ EXCEPT ALL SELECT subject, enrollment FROM innerjoin)
SELECT name, rank, subject, enrollment
FROM innerjoin
UNION ALL
SELECT name, rank, CAST(NULL AS Varchar(20)) AS subject, CAST(NULL AS Interger) AS enrollment FROM teacher_only UNION ALL
SELECT CAST(NULL AS Varchar(20)) AS name, CAST(NULL AS Interger) AS rank, subject, enrollment FROM course_only
TRIGGERS EN DB2
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 t rigger debe ser activado.
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 realiza rá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.
La activación de in Trigger puede generar una cascada de Triggers. Esto sucede si el resultado de ejecutar algún Trigger produce que se active otro o incluso se active a si mismo.
Distintos SQL Hay algunos comandos adicionales de SQL que hacen mucho más fácil la codificación. A continuación mostraremos algunos ejemplos:
1. 1. 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.
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 COMPENSATION_LEVEL FROM EMPLOYEE ORDER BY SALARY
2. 2. Cláusula AS La cláusula AS se usa cuando se asigna un nombre a un calculo. Puede ser usada para dar un nombre significativo a un calculo en una columna de SQL, pero también puede ser usada para evitar errores. Para ordenar un calculo, se necesitaba dar el número relativo de la columna en la cláusula ORDER BY. Ej: SELECT SALARIO + COMISION FROM EMPLEADOS ORDER BY 1
Ahora se puede asignar un nombre a este cálculo y usar este nombre en el ORDER BY:
SELECT SALARIO + COMISION AS PAGO P AGO FROM EMPLEADOS ORDER BY PAGO
Esto puede permitir muchos errores en el SQL
SELECT APELLIDO, SALARIO + PREMIO AS PAGO FROM EMPLEADOS ORDER BY PAGO
Hardware Soportado en DB2
En esta sección veremos los siguientes entornos de hardware sobre los cuales funciona DB2 :
Partición simple sobre un único procesador ( uniprocesador ) Partición simple con múltiples procesadores ( SMP : Single Partition with Multiple Processors ) Distintas configuraciones de Partición múltiple : Particiones con un procesador ( MPP : Múltiple Partitions with one Processor ) Particiones con múltiples procesadores ( cluster of SMPs ) Particiones lógicas de base de datos, también conocidas como Nodos Lógicos Múltiples ( MLN: Multiple Logical Nodes ) en la edición paralela de DB2 para la versión 1 de AIX.
A continuación en cada ambiente de hardware, se describen las consideraciones respecto de la capacidad y escalabilidad :
La 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. almacenamiento. La Escalabilidad se refiere a la habilidad que posee la base base de datos de expandirse y continuar exhibiendo las mismas características operacionales y t iempos de respuesta.
Partición Simple sobre un Único Procesador
Este entorno se basa en memoria y disco, conteniendo una única CPU. Este ambiente ha sido denominado de diversas maneras : base de datos aislada ( standalone database ), base de datos cliente/servidor ( client/server database ), base de datos serial ( serial database ), sistema uniprocesador ( uniprocessor system ), y entorno nodo simple/ no paralelo ( single node/non-parallel ). La base de datos en este ambiente sirve para cubrir todas las necesidades de un departamento o de una pequeña oficina de una empresa donde los datos y los recursos del sistema ( incluyendo un único procesador o CPU ) son administrados por un único administrador de la base.
Capacidad y Escalabilidad A este ambiente se le pueden agregar mas discos. Al tener uno o más servidores de entrada-salida para mas de un disco permite que más de una operación de entrada-salida ocurra al mismo tiempo. Un sistema de procesador único esta limitado por la cantidad de espacio en disco que pueda manejar dicho procesador. Sin embargo, como la carga de trabajo aumenta, una sola CPU puede llegar a ser insuficiente para satisfacer las peticiones solicitadas por los usuarios, aun sin importar cuantos discos y/o memoria adicional hayan sido agregados. Si se ha alcanzado la máxima capacidad o escalabilidad, se podría considerar cambiarse a un sistema de partición única con múltiples procesadores. A continuación se describe esta configuración.
Partición Simple con Múltiples Procesadores Este entorno se compone de varios procesadores de igual potencia dentro de la misma máquina, llamándose a este ambiente Sistema Simétrico Multiprocesador ( symmetric multi-processor o SMP ). Los recursos tales como espacio de disco y memoria son compartidos. En esta máquina se encuentran más discos y memoria en comparación a una base de datos de partición simple, en el ambiente de procesador único. Este entorno es de fácil administración, debido a que todo esta ubicado en una sola maquina y además los discos y memoria están compartidos. Con varios procesadores disponibles, diferentes operaciones de la base de datos pueden ser completadas significativamente más rápido que en bases de datos asignadas a un solo procesador. DB2 también puede dividir el trabajo de una consulta simple entre los procesadores disponibles para mejorar la velocidad de procesamiento. Otras operaciones de la base de datos, tales como el resguardo ( backup ) y creación de índices sobre datos existentes pueden también aprovechar la ventaja de trabajar con múltiples procesadores.
Capacidad y Escalabilidad En este entorno se pueden agregar mas procesadores. Sin embargo, es posible que los distintos procesadores traten de acceder al mismo dato en el mismo tiempo, lo cual generara la aparición de limitaciones a medida que las operaciones de su negocio se incrementen. Con discos y memoria compartidos, se puede efectivamente compartir todos los datos de la base.
Una aplicación en un procesador puede estar accediendo un dato al mismo tiempo que otra aplicación lo hace en otro procesador, causando así que la segunda aplicación espere para acceder a ese dato. Se puede incrementar la capacidad de entrada-salida de la partición de la base de datos asociada a un procesador, así como también el numero de discos. También se p ueden establecer servidores de entrada-salida para repartir las solicitudes de entrada-salida. Al tener uno o mas servidores de entrada-salida para cada disco permite que una o mas operaciones de entrada-salida tengan lugar al mismo tiempo. Si se ha alcanzado la máxima capacidad o escalabilidad, se puede considerar la idea de cambiar la base a un sistema de partición múltiple, descrito a continuación.
Distintas Configuraciones de Particiones Múltiples Además de los entornos antes mencionados, se puede dividir la base de datos en particiones múltiples, cada una en su propia maquina. Y además varias maquinas con particiones múltiples de una base de datos pueden ser agrupadas.
Esta sección describe las siguientes configuraciones de particiones posibles :
Particiones en sistemas cada uno con un procesador. Particiones en sistemas cada uno con múltiples procesadores. Particiones lógicas de base de datos.
Particiones
con
un
Procesador
En este entorno existen varias particiones de base de datos, cada una de las cuales sobre su propia maquina y con su propio procesador, memoria y discos. Una maquina consiste de una CPU, memoria, y disco con todas las maquinas conectadas mediante una instalación de comunicación. Otros nombres dados a este entorno son los siguientes : cúmulo ( cluster ), cúmulo de uniprocesadores ( cluster of uniprocessors ), entorno de procesamiento masivo en paralelo ( massively parallel procesing o MPP ), o configuración compartido-nada ( shared-nothing configuration ). El último nombre refleja exactamente el arreglo de recursos en este ambiente. A diferencia de un entorno SMP ( Sistema Simétrico Multiprocesador ), un entorno MPP ( Particiones Múltiples con un procesador ) no tiene discos ni memoria compartidos. El entorno MPP elimina las limitaciones introducidas al compartir memoria y disco. Un entorno de base de datos particionado permite que una base de datos continué siendo un conjunto lógico mientras que físicamente esta dividida a través de más de una partición. Para los usuarios y/o aplicaciones, la base de datos puede ser utilizada como un todo y el hecho de que los datos están particionados es transparente. El trabajo a ser realizado con los datos puede ser
dividido para cada administrador de base de datos, de esta forma cada administrador de la base de datos en cada partición, trabaja sobre su propia parte de la base de datos.
Capacidad y Escalabilidad En este entorno se pueden agregar mas particiones de base de datos ( nodos ) a la configuración. En algunas plataformas, por ejemplo RS/6000, el máximo es de 512 nodos. Sin embargo, podría existir un problema practico relacionado con la administración de tal numero de maquinas e instancias. Si se ha llegado a la máxima escalabilidad y capacidad, se puede considerar la opción de migrar a un sistema donde cada partición posea múltiples procesadores. A continuación describimos esta configuración.
Particiones con Múltiples Procesadores Como alternativa de una configuración en la cual cada partición tiene un procesador único, se puede utilizar una en la cual una partición posea múltiples procesadores. A esto se lo denomina Cúmulo SMP ( SMP Cluster). Esta configuración combina las ventajas de un SMP y el paralelismo de un MPP. Esto significa que una consulta ( query ) puede ser realizada en una partición simple a través de múltiples procesadores. Además esto implica que una consulta ( query ) puede ser hecha en paralelo a través de particiones múltiples.
Capacidad y Escalabilidad En este entorno se pueden adicionar mas particiones a la base de datos, como vimos en la sección anterior. También se pueden agregar mas procesadores a las particiones existentes en la base de datos.
Particiones Lógicas de Base de Datos La partición lógica de una base de datos se diferencia de una partición física en que no se logra el control de la máquina entera. A pesar de que la maquina comparte sus recursos, la partición no lo hace. Esto significa que los procesadores son compartidos pero no lo son el/los discos y la memoria. Una razón lógica para utilizar particiones lógicas es la de brindar escalabilidad. El administrador de base de datos múltiple que se ejecuta en particiones lógicas múltiples, puede hacer un uso más completo de los
recursos disponibles que un administrador de una base simple de datos. Se gana mayor escalabilidad sobre una maquina SMP mediante la adición de particiones, particularmente en aquellas maquinas con varios procesadores. Mediante la partición de la base de datos, se puede administrar y recuperar cada partición por separado. Nótese también que la habilidad de tener dos o mas particiones coexistiendo en la misma maquina ( sin importar el numero de procesadores) permite una mayor flexibilidad al diseñar configuraciones avanzadas de disponibilidad y estrategias para hacer frente a caídas del sistema.
Resumen del Paralelismo mejor Adaptable a cada Entorno de Hardware La siguiente tabla resume los tipos de paralelismo que mejor se adaptan a los diferentes entornos de hardware.
Entorno de Hardware
Partición Simple, Único Procesador
Partición Simple, Múltiples Procesadores ( SMP )
Particiones Múltiples, Un Procesador ( MPP )
Particiones Múltiples, Múltiples Procesadores ( cúmulos de SMPs o cluster of SMPs )
Paralelismo InterConsulta
Paralelismo InterConsulta
Paralelismo IntraPartición
Paralelismo Inter.Partición
Si
No
No
Si
Si
No
Si
No
Si
Si
Si
Si
Paralelismo I/O
Particiones Lógicas de Base de Datos
Si
Si
Si
Herramientas de Administración Desde el punto de vista del administrador de base de datos, el DB2 incluye una larga lista de herramientas DBA. Además de esto hay: utilidades para B/R, reorganizador, importar/exportar y alta velocidad de llamadas, están incluidas y pueden ser ejecutadas a través de un objeto GUI Browser.
DB2 Administración de Servidores
El DB2 administración de servidores (DAS) es una instancia de DB2 que habilita administración remota de servidores DB2. Esta instancia es creada y usada en una forma similar a cualquier instancia de DB2. Puede tener una sola DAS sobre su maquina.
Asistente para la Configuración de clientes
El asistente de configuración de clientes nos ayuda a manejar las conexiones de las bases de datos con servidores de base de datos remotas.
Este puede correr bajo servidores OS/2 y Windows NT, así como el cliente corre bajo OS/2, Windows NT y Windows 95. Con el asistente de configuración de clientes usted podrá :
Definir conexiones a base de datos de modo que éstas pueden ser utilizadas por aplicaciones. Existen 3 métodos:
o
o
o
Examinar la red por base de datos disponibles y seleccionar una. El cliente automáticamente se configura para esa base de datos. Usar los perfiles de acceso a base de datos que provee el administrador para definir automáticamente las conexiones. Configuración manual de conexiones a base de datos para modificar algunos parámetros de conexión requeridos.
Remover base de datos catalogadas o modificar sus propiedades.
Testear la conexión con la base de datos identificada en su sistema para asegurarse que puede establecerse la conexión con el servidor que necesita.
Enlazar aplicaciones a una base de datos seleccionando utilidades o enlazar archivos de una lista.
Establecer conexiones con servidores DRDA si la conexión DB2 está instalada.
Administrador
El administrador es usado para monitorear y cambiar el mejoramiento de aplicaciones que corren a través de la base de datos.
Consiste en dos partes:
Una utilidad de frente-final
Un dominio
Cuando arranca el administrador, se ejecuta el comando de inicio de el administrador de utilidades de front-end , quienes ejecutan el dominio. Por default, el dominio es iniciado sobre toda partición en una base de datos particionada, pero se puede también usar la utilidad front-end para iniciar un dominio simple de una partición específica para monitorear la actividad a través de la partición de base de datos encontradas allí. O un dominio puede monitorear la actividad sobre una particiónsimple de base de datos.
Además un administrador de dominio colecciona estadísticas sobre las aplicaciones que corren a través de la base de datos.
Estas son chequeadas a través de reglas que pueden ser especificadas en el archivo de configuración del administrador aplicadas a esa base de datos específica. El administrador actúa de acuerdo a éstas reglas. Por Ej.: una regla puede indicar que la aplicación esta usando demasiados recursos.
En éste caso el administrador puede cambiar las prioridades de la aplicación o forzarla a dejar la base de datos, de acuerdo con las instrucciones específicas en el archivo de configuración del administrador.
Si la acción asociada con ésta regla cambia las prioridades de la aplicación, el administrador cambia las prioridades del solicitante sobre la partición de la base de datos en la que el administrador detecta la violación de recurso.
Si la acción asociada con la regla es de forzar la aplicación, ésta será forzada siempre que el administrador que ha detectado la violación del recurso esté corriendo sobre el nodo coordinador de la aplicación o en un entorno particionado de la base de datos.
El administrador también almacena (logs) cualquier acción que tome, se pueden consultar éstos archivos log para rever las acciones tomadas por el administrador.
SmartGuides
Éstas son parte de las herramientas de administración de DB2 y nos guían a través de las tareas de administración. Las siguientes están habilitadas:
Creación de base de datos : ayuda sobre la creación de base de datos, asignación de
almacenamientos y selección de las opciones básicas más optimas. Para invocarla, chiquear sobre el icono de database en el Control Center y seleccionar Create- new .
Creación de espacio de tablas : ayuda a crear nuevos espacios de tablas y configurar las
opciones básicas de almacenamiento óptimo. Para invocarlo chiquear sobre el icono de Table Space en el Control Center , y seleccionar Create ->Table Space usando Smartguide.
Creación de Tablas: ayuda a diseñar columnas (usando planillas de columnas pre-
definidas si se desea), crear una clave primaria para la tabla y asignar la tabla a uno o más espacios. Para invocarla chiquear sobre el icono de Table en el Control Center y seleccionar Create ->Table usando Smartguide.
Backup de Base de datos : hace preguntas básicas sobre la información de las bases de
datos la disponibilidad de las bases de datos, las restricciones de baja horaria y requisitos de recuperabilidad. Esto sugiere un plan de backup, creación de scripts de trabajo y su schedules. Para invocarlo chiquear el icono que representa alguna de sus base de datos en el Control Center y seleccionar Backup -> database usando Smartguide.
Recupero de base de datos : ayuda sobre el proceso de recuperación de base de datos.
Para invocarlo chiquear sobre el icono que representa una de sus base de datos en el Control Center y seleccionar Backup -> database usando Smartguide.
Optimización de la configuración: hace preguntas sobre la base de datos, su
información y los propósitos del sistema y entonces sugiere nuevos parámetros de configuración para la base de datos y automáticamente las aplica a las base de datos si se desea. Para invocarlo chiquear en el icono que representa una de su base de datos en el Control Central y seleccione optimización de la configuración.
Estándares Soportados en DB2
La UDB DB2 se adapta muy bien a los estándares industriales haciéndola muy integrable con otros productos IBM y también con aquellos que no lo son. La UDB DB2 soporta estándares API incluyendo ANSI SQL92E, Microsoft OBDC y JAVA/JDBC.
Con respecto a las aplicaciones de tipo cliente, se tienen procedimientos almacenados y funciones definidas por el usuario a través de VisualAge. Esto nos da una amplia elección de desarrollo de aplicaciones y herramientas finales para ser elegidas por los usuarios. La UDB DB2 también puede ser integrada con servicios de seguridad para administrar servidores de nombre y direcciones. DB2 también soporta SNMP y puede ser moni toreada desde cualquier Sistema de Administración de Servers de IBM. Para poder establecer una comunicación con otras bases de datos relacionales, la UDB DB2 soporta la Arquitectura de Base de Datos Relacional ( DRDA ). Esta arquitectura también incluye el Servidor de Aplicaciones ( AS ) y gracias a ella DB2 puede correr sobre TCP/IP en forma nativa, haciendo más fácil la implementación de un entorno abierto de redes.
La UDB DB2 también incluye las siguientes innovaciones en SQL, que satisfacen los requerimientos:
SOPORTE DE AUTORIZACION ADICIONAL
Las siguientes funciones han sido agregadas para soportar autorizaciones:
Privilegio de ACTUALIZACION ( UPDATE ) del nivel de columna. Privilegio de REFERENCIAS ( REFERENCES ) del nivel de columna. Comando WITH GRANT OPTION en GRANT ( para tablas, vistas y columnas). Privilegios PUBLICOS ( PUBLIC ) para SQL estático y vistas.
SOPORTE DE TIPOS DE DATOS REALES
Un dato de precisión simple con coma flotante utilizando el comando REAL es soportado por DB2.
DECLARACIONES DE CREACION DE ESQUEMA ( CREATE SCHEMA ) Y ELIMINACION DE ESQUEMA ( DROP SCHEMA )
Una declaración de CREACION DE ESQUEMA ( CREATE SCHEMA ) y de ELIMINACIONA ( DSOPORTE PARA RESTRICCIONES UNICAS DB2 también soporta restricciones únicas ( unique constraints ), las cuales se indican a continuación :
Soporte para uno o mas restricciones UNICAS sobre las tablas, en adición a las CLAVES PRIMARIAS. -Las claves foráneas pueden referirse a restricciones únicas. El chequeo de las restricciones únicas se realiza en diferido al finalizar la declaración. Los nombres de las restricciones especificadas pueden ser utilizados como nombre índices ( también aplicable a las claves primarias). Las RESTRICCIONES UNICAS y las CLAVES PRIMARIAS de tablas de partición múltiple incluyen la CLAVE DE PARTICION.
CONVERSION NUMERICA Y ARITMETICA AMIGABLE Una aritmética y conversión numérica amigable para asignar variables, permite que una consulta sea llevada a cabo y pro
30 de abril de 2012
IBM tienta a usuarios de Oracle con su nueva DB2 9.7 ´Cobra´. Anunciada hace unas cuantas semanas, hace su aparición la versión 9.7 de DB2 y lo hace junto con InfoSphere Warehouse 9.7 como propuesta para la construcción de plataformas de análisis de datos en forma más integrada con sus fuentes.
Más Noticias de Noticias IT ----- CARGAR EN TI Lantares incorpora el Análisis Predictivo a su oferta de Soluciones de Negocio.
El mayor atractivo de Cobra sería, según lo explicó Fátima Díaz, brand manager de Information Management de IBM, el de permitir una migración casi indolora desde bases de datos Oracle. Cobra es una versión de DB2 completamente diferente que permite pasar aplicaciones desde Oracle sin tocar su estructura al menos en un 95%. Corre sobre los sistemas operativos Windows, Linux y todos los sabores de Unix del mercado. Respecto a mainframes z/OS, en siguientes versiones se liberaría, según Fátima Díaz, una versión para esa plataforma. Mientras tanto, se pueden virtualizar máquinas Linux en sus particiones. DB2 9.7 toma los store procedures tal como vienen del entorno Oracle y los administradores pueden seguir utilizando sus conocimientos Oracle sobre DB2. Cobra reduce el requerimiento de almacenamiento de datos y en consecuencia sus costos y consumo de energía. Esto se debe a un nuevo algoritmo de compresión que permite comprimir tanto tablas como índices y tablas temporarias. Respecto a su comportamiento en entornos donde se utilizan recursos de deduplicación, Fátima Díaz nos dice que no se han producido conflictos en los numerosos beta realizados en empresas usuarias. El producto soporta interoperabilidad absoluta con plataformas de virtualización como Citrix y VMware, además del hypervisor de Microsoft.
El modelo de licenciamiento ha sido adaptado a la creciente tendencia a los procesadores multicore y, al abandonar el concepto de nodo, se proyecta como apto para ambientes on-demand o cloud computing. DB2 tiene una función que detecta los procedimientos no compatibles de Oracle para que puedan ser modificados, debiendo destacarse que se trata de una compatibilidad nativa y no a través de emulación. No tiene overhead. Mediciones realizadas con la plataforma SAP mostraron un 20% de ganancia en performance respecto a versiones anteriores de DB2 que, según Fátima Díaz, ya eran más veloces que las bases de datos de Oracle. La compatibilidad con Oracle PL/SQL ha sido licenciada por IBM del producto open source Enterprise DB. Dicha compatibilidad también está disponible en el producto Postgres Plus Advanced Server de EnterpriseDB. En momentos en que MySQL va a pasar a manos de Oracle a través de la compra de Sun Microsystems, queda claro que a IBM le conviene promocionar a otra base en el mundo open source. IBM DB2 9.7 dispone de mecanismos de auto ajuste (tuning) y de administración de memoria, además de almacenamiento a través de herramientas como Configuration Assitant y asistentes de software. La capacidad de compresión, que ahorra un 30% de storage respecto a Oracle según la gente de IBM, incluye compresión inteligente de grandes objetos y de XML. Las funciones de auditoría fueron rediseñadas y se perfeccionó el control de acceso. Control de precisión, encriptado y LBAC (Label Based Access Control), son algunos factores para la reducción del riesgo de acceso no autorizado. Cuando se definen roles y sus privilegios, los objetos de la base de datos son dominados por los roles y no por el usuario, lo cual contribuye a la imposición de políticas internas y al auditado de accesos. La carga de trabajo es administrada en capas para evitar que la demanda de recursos lesione a alguna aplicación en particular. DB2 9.7 utiliza clases de prioridad de servicio Alta, Media y Baja para las cargas de trabajo.
1.
Para modificar el script de un artículo y suministrarlo como un script de creación personalizado a. Una vez generada la instantánea para la publicación, navegue a la carpeta de instantáneas de la publicación. b. Busque el archivo .sch que tiene el mismo nombre que el artículo; por ejemplo, miArtículo.sch. c. Abra este archivo en el Bloc de notas o en otro editor de texto. d. Modifique el archivo y guárdelo en un directorio distinto. e. Ejecute sp_changearticle, especificando la ruta de acceso del archivo y el nombre de la propiedad creation_script . Para obtener más información, vea sp_changearticle (Transact-SQL). Para crear un script de un artículo y suministrarlo como un script de creación personalizado f.
Cree un script de artículo con el dialecto DB2 SQL. Asegúrese de que la primera línea del archivo sea bypass_translation y de que no haya nada más en la línea.
g.
Ejecute sp_changearticle, especificando la ruta de acceso del archivo y el nombre de la propiedad creation_script .
Consideraciones para los suscriptores de IBM DB2
Además de las consideraciones planteadas en el tema Suscriptores que no son de SQL Server, tenga en cuenta los siguientes problemas al replicar en suscriptores de DB2:
Los datos y los índices para cada tabla replicada se asignan a un espacio de tablas de DB2. El tamaño de la página de un espacio de tablas de DB2 controla el número máximo de columnas y el tamaño máximo de las filas de las tablas que pertenecen al espacio de tablas. Asegúrese de que el espacio de tablas asociado con las tablas replicadas es apropiado para el número de columnas replicadas y el tamaño máximo de las filas de las tablas. No publique tablas en suscriptores de DB2 con la replicación transaccional si una o más columnas de clave principal en la tabla tienen un tipo de datos DECIMAL(32-38, 0-38) o NUMERIC(32-38, 038). La replicación transaccional identifica las filas con la clave principal y esto puede producir errores, ya que estos tipos de datos se asignan a VARCHAR(41) en el suscriptor. Las tablas con claves principales que utilicen estos tipos de datos se pueden publicar con la replicación de instantáneas. Si desea crear previamente las tablas en el suscriptor en lugar de crearlas por medio de la replicación, use la opción replication support only. Para obtener más información, vea Inicializar una suscripción transaccional sin una instantánea. SQL Server permite utilizar nombres de tabla y de columna más largos que DB2: Si la base de datos de publicación incluye tablas con nombres más largos que los admitidos por la versión de DB2 en el suscriptor, especifique otro nombre para la propiedad destination_table. Para obtener más información acerca de cómo configurar propiedades al crear una publicación, vea Crear una publicación y Definir un artículo. No es posible especificar otros nombres de columnas. Debe asegurarse de que las tablas publicadas no incluyan nombres de columna más largos que lo permitido por la versión de DB2 en el suscriptor.
Asignar tipos de datos de SQL Server a IBM DB2
En la tabla siguiente se muestran las asignaciones de tipos de datos que se utilizan cuando se replican datos en un suscriptor que ejecuta IBM DB2.
Tipo de datos de SQL Server
Tipo de datos de IBM DB2
bigint
DECIMAL(19,0)
binary(1-254)
CHAR(1-254) FOR BIT DATA
binary(255-8000)
VARCHAR(255-8000) FOR BIT DATA
bit
SMALLINT
char(1-254)
CHAR(1-254)
char(255-8000)
VARCHAR(255-8000)
date
DATE
datetime
TIMESTAMP
datetime2(0-7)
VARCHAR(27)
datetimeoffset(0-7)
VARCHAR(34)
decimal(1-31, 0-31)
DECIMAL(1-31, 0-31)
decimal(32-38, 0-38)
VARCHAR(41)
float(53)
DOUBLE
float
FLOAT
geography
IMAGE
geometry
IMAGE
hierarchyid
IMAGE
image
VARCHAR(0) FOR BIT DATA1
into
INT
money
DECIMAL(19,4)
nchar(1-4000)
VARCHAR(1-4000)
ntext
VARCHAR(0) 1
numeric(1-31, 0-31)
DECIMAL(1-31,0-31)
numeric(32-38, 0-38)
VARCHAR(41)
nvarchar(1-4000)
VARCHAR(1-4000)
nvarchar(max)
VARCHAR(0) 1
real
REAL
smalldatetime
TIMESTAMP
smallint
SMALLINT
smallmoney
DECIMAL(10,4)
sql_variant
N/D
sysname
VARCHAR(128)
text
VARCHAR(0) 1
time(0-7)
VARCHAR(16)
timestamp
CHAR(8) FOR BIT DATA
tinyint
SMALLINT
uniqueidentifier
CHAR(38)
varbinary(1-8000)
VARCHAR(1-8000) FOR BIT DATA
varchar(1-8000)
VARCHAR(1-8000)
varbinary(max)
VARCHAR(0) FOR BIT DATA1
varchar(max)
VARCHAR(0) 1
xml
VARCHAR(0) 1
1
Para obtener más información acerca de las asignaciones a VARCHAR(0), vea la siguiente sección.
Consideraciones acerca de la asignación de tipos de datos Tenga en cuenta los siguientes problemas de asignación de tipos de datos al replicar en suscriptores de DB2:
Al asignar SQL Server char, varchar, binary y varbinary a CHAR, VARCHAR, CHAR FOR BIT DATA y VARCHAR FOR BIT DATA de DB2, respectivamente, la replicación establece la longitud del tipo de datos de DB2 de forma que sea igual a la del tipo de datos de SQL Server. Esto permite crear correctamente la tabla generada en el suscriptor, siempre que la restricción del tamaño de página de DB2 sea suficientemente grande como para admitir el tamaño máximo de la fila. Asegúrese de que el nombre de inicio de sesión que utiliza para obtener acceso a la base de datos de DB2 tiene permisos de acceso a espacios de tabla de tamaño suficiente para las tablas que se van a replicar en DB2.
