Arquitectura de computadorasDiseno_de_Bases_de_Datos_en_DB2

Vista previa del material en texto

IBM – DB2 DISEÑO DE BASE DE DATOS DB2 2009 
 
Ing. Santiago Pérez - Aus Laura Noussan Lettry 
 
CAPÍTULO 1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
INDICE 
Diseño conceptual de una base de datos en DB2 1 
� Introducción 1 
� Diseño conceptual o lógico 1 
Diseño físico de una base de datos en DB2 1 
� El modelo de almacenamiento en DB2 2 
� Tablas, índices, campos largos y espacios de tabla 3 
Espacios de tabla DMS y SMS 3 
DMS vs SMS 3 
Diseño conceptual de la base de datos de Proveedores y Partes 4 
Creación de una base de datos en función del diseño lógico y físico 7 
� Introducción 7 
� El comando Create Database 7 
� Ubicación de la Base de Datos 8 
� Códigos de Páginas y Secuencias de Cotejo 8 
� Definiciones de Espacios de Tabla 9 
� Creación de la Base de Datos KnowWare 10 
� Utilización del Centro de Mandatos 11 
� Utilización del Centro de Control 13 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 1 
DISEÑO CONCEPTUAL DE UNA BASE DE DATOS EN DB2 
 
Introducción 
 
Básicamente, una Base de Datos tiene como finalidad almacenar información que desde algún 
punto de vista es importante para su propietario. Lo que diferencia a una Base de Datos de otros Sistemas 
es que justamente la organización de la misma permite que el usuario final se abstraiga de tareas técnicas. 
Ahora, mirando hacia el lado del propietario de la información, la empresa o institución, la gran ventaja de 
las Bases de Datos radica en la posibilidad de compartir y restringir los datos, y que la información esté 
disponible con muy poca redundancia (salvo por aspectos técnicos que así lo requieran) para distintas 
aplicaciones y distintos tipos de usuarios. 
 
Esto se debe a que en los Sistemas de Bases de Datos la información está integrada y el sistema 
está administrado por el DBMS (Sistema Administrador de Bases de Datos) que se encarga de consultar y 
almacenar los datos, efectuar las consultas de la forma más eficiente, etc. 
 
Justamente es el DBMS el que permite que el usuario final se abstraiga de cuestiones técnicas 
relacionadas al sistema de archivos, hardware, etc. y permite la integridad y seguridad de la información. 
 
Diseño Conceptual o lógico 
 
Si bien el DBMS es el administrador del sistema, no sería muy bueno su trabajo si la Base de Datos 
no estuviera bien diseñada en su aspecto lógico. Incluso es de hacer notar que el diseño físico puede no 
coincidir con el lógico pero es innegable que los cambios producidos en el diseño lógico deberán afectar el 
físico y que los cambios físicos no deberían afectar el diseño lógico. 
 
Los sistemas de bases de datos que actualmente existen son los Relaciones u Objeto Relacionales, 
como es DB2; motivo por el cual están basados en la lógica del álgebra relacional y por lo tanto, cualquier 
diseño físico corresponderá a un previo diseño lógico que deberá ser consistente con su sustento teórico. 
 
Para ello es necesario que se cumplan ciertos requisitos: 
 
� El diseño lógico es siempre independiente del tipo de aplicación, esto quiere decir que no 
interesa si la base de datos es operacional o es para apoyo a la toma de decisiones. Inclusive 
no debería haber mayores discrepancias entre un sistema comercial u otro. 
� Las tablas que forman la Base de Datos deben estar normalizadas ya que es el requisito 
necesario para que puedan aplicarse las operaciones relacionales. 
� Como consecuencia de ello deben poder establecerse reglas de integridad. Por integridad 
debe entenderse no sólo mantener la consistencia de los datos (el pegamento, si se quiere 
entre las tablas), sino también definir el significado de las tablas y de la base de datos en su 
totalidad. 
 
La importancia del modelo lógico es tal, que los cambios en el sistema físico deberían siempre 
amoldarse a éste. En realidad el modelo físico puede cambiar sin cambiarse el modelo lógico cuando 
cuestiones de almacenamiento y eficiencia así lo indiquen. 
 
Por ejemplo, en el caso de DB2 puede ser conveniente tener la Base de Datos particionada según 
el uso probable o ya experimentado. Por lo tanto en un servidor pueden almacenarse las tablas de mayor 
uso y en otro las de menor uso. Esta modificación en el diseño físico no altera el diseño lógico. 
 
 
DISEÑO FÍSICO DE UNA BASE DE DATOS EN DB2 
 
Una base de datos DB2 está realmente formada por una colección de objetos. Desde la perspectiva 
del usuario, una base de datos es una colección de tablas que están (felizmente) relacionadas de alguna 
manera. 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 2 
Desde la perspectiva de un administrador de base de datos (DBA – esto es usted), esto es algo un 
poco más complicado que eso. Una base de datos real contiene muchos de los siguientes objetos físicos y 
lógicos: 
• Tablas, vistas, índices, esquemas 
• Candados, triggers, procedimientos almacenados, paquetes 
• Buffer pools, log files, espacios de tabla (tablespaces) 
Algunos de estos objetos, como tablas o vistas, ayudan a determinar cómo están organizados los 
datos. Otros, como los espacios de tabla, hacen referencia a la implementación física de la base de datos. 
Finalmente, algunos objetos, como los buffer pools y otros objetos de memoria, sólo se encargan de cómo 
administrar el rendimiento de la base de datos. 
Más que discurrir sobre las posibles combinaciones de parámetros y objetos, el DBA se concentrará 
primariamente en la implementación física de la base de datos. ¿Cómo hacer para crear la base de datos y 
asignarle el espacio de almacenamiento necesario para ello? Para responder apropiadamente esta 
pregunta, necesita conocer sobre los objetos básicos de la base de datos y cómo estos son mapeados al 
almacenamiento físico en disco. 
El modelo de Almacenamiento en DB2 
DB2 tiene tanto un modelo lógico y uno físico para manipular los datos. Los datos reales con los que 
los usuarios deben trabajar se encuentran en tablas. Mientras que las tablas pueden estar formadas por 
columnas y filas, el usuario no tiene conocimiento de la representación física de los datos. Este hecho es 
algunas veces mencionado como la independencia física de los datos. 
Las tablas mismas están contenidas dentro de espacios de tabla. Un espacio de tabla es utilizado 
como una capa entre la base de datos y el contenedor de objetos que almacena los datos de la tabla real. 
Un espacio de tabla puede contener más de una tabla. Es un espacio para almacenar tablas. Cuando se 
crea una tabla es recomendable que ciertos objetos como índices y objetos largos (LOB) estén separados 
del resto de los datos de tabla. 
Un contenedor (container) es un dispositivo de almacenamiento físico. Puede ser identificado por 
un nombre de directorio, un nombre de dispositivo, o un nombre de archivo. Un contenedor es asignado a 
un espacio de tabla. Un espacio de tabla puede expandirse a varios contenedores, pero cada contenedor 
debe pertenecer sólo a un espacio de tabla. El hecho de que un espacio de tabla pueda expandirse a varios 
contenedores indica que usted como DBA, puede verse cercado por limitaciones del sistema operativo que 
pueden limitar la cantidad de datos que puede tener el contenedor. La relación entre todos estos objetos se 
ilustra en la siguiente figura. 
 
 
Si bien una tabla es el objeto básico que está almacenado en un espacio de tabla, un DBA debería 
tener conciencia de la existencia de otros objetos dentro del sistema DB2, y cómo los mismos son 
mapeados a los espacios de tabla. 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 3 
Tablas, índices, campos largos y espacios de tabla 
Tablas, índices y campos largos (algunas veces llamados objetos binarios largos o BLOBS) son 
objetos que son creados dentro de una base de datos DB2. Estos objetosson mapeados a un espacio de 
tabla de tal manera que él mismo es mapeado al almacenamiento físico en disco. 
Una tabla es un conjunto no ordenado de registros de datos. Consiste en columnas y filas que 
generalmente son conocidas como registros. Las tablas pueden ser tanto permanentes (tablas base) como 
temporales (declaradas así) o tablas temporales por derivación. Desde la perspectiva de un DBA, el espacio 
está asignado para cada uno de estos objetos de tabla, pero en diferentes espacios de tabla. 
Un índice es un objeto físico que está asociado a una tabla. Los índices son utilizados para forzar la 
unicidad en una tabla (esto es, asegurar que no existirán valores duplicados) y para mejorar el rendimiento 
cuando se recupera información. No necesita de índices para ejecutar sentencias de SQL; sin embargo, sus 
usuarios apreciarán su previsión en crear unos pocos de ellos para aumentar la rapidez en el proceso de 
consultas! 
Un campo largo (o BLOB) es un tipo de datos que se encuentra en una tabla. Este tipo de datos 
típicamente consiste en datos no estructurados (una imagen, un documento, un archivo de audio) y 
usualmente contiene una cantidad significativa de información. Almacenar este tipo de datos dentro de una 
tabla podría llevar a un excesivo gasto cuando se borra, inserta y se manipulan estos objetos. En cambio en 
lugar de almacenarlos directamente en la fila de una tabla, lo que se almacena es un puntero que apunta a 
un sitio dentro de un espacio de tabla largo (previamente conocido como un espacio de tabla para campos 
largos o BLOBs). Los DBA deben estar al tanto de este tipo de datos para poder crear los espacios de tabla 
apropiados que puedan contener estos objetos. 
Estando provistos del conocimiento de estos diferentes tipos de objetos, ahora podremos determinar 
el tipo de espacio que es necesario para poder efectuar las asignaciones. 
Espacios de tabla DMS y SMS 
Los espacios de tabla son la capa lógica entre la base de datos y las tablas almacenadas esa base 
de datos. Los espacios de tabla son creados dentro de una base de datos y las tablas son creadas dentro 
de espacios de tabla. DB2 soporta dos tipos de espacios de tabla: 
• System-Managed Space (SMS): aquí, el administrador del sistema de archivos del sistema 
operativo asigna y administra el espacio, donde la tabla tiene un tipo de espacio de tabla por 
defecto. El administrador es, por lo tanto, el sistema de archivos. 
• Database-Managed Space (DMS): en este caso, el administrador de la base de datos controla el 
espacio de almacenamiento. Este espacio de tabla es, esencialmente, una implementación de 
propósito especial del sistema de archivos diseñado para superar las demandas encontradas por el 
administrador de base de datos. 
Los espacios de tabla SMS requieren muy poco mantenimiento. Sin embargo, estos espacios de 
tabla ofrecen muy pocas opciones de optimización y no pueden manipularse tan bien como los espacios de 
tabla DMS. 
Entonces, ¿qué diseño de espacio de tabla debería elegir? 
DMS vs SMS 
A pesar de que la siguiente tabla no es exhaustiva, contiene algunos puntos para considerar cuando 
hay que decidir entre espacios de tabla tipo DMS y SMS 
 
 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 4 
Característica SMS DMS 
Intercalación SI SI 
Administración 
de objetos Sistema Operativo DB2 
Asignación de 
espacio 
Expansión/compresión 
según demanda 
Preasignado: el tamaño 
puede expandirse y 
comprimirse pero requiere 
la intervención del DBA. 
Facilidad de 
administración 
El mejor; muy pocas o casi 
ninguna tarea de 
afinamiento (tunig) 
Buena, pero requiere algo 
de tuning (por ejemplo: 
EXTENTSIZE 
PREFETCHSIZE) 
Rendimiento Muy bueno 
Es mejor; puede 
conseguirse hasta un 5 a 
10% de ventaja con 
contenedores de fila 
DISEÑO CONCEPTUAL DE LA BASE DE DATOS PROVEEDORES Y PARTES 
El diseño conceptual tiende a identificar las entidades y relaciones existentes, aplicación de las 
reglas de normalización, de nombres inequívocos para los atributos de las entidades, establecimiento de 
reglas de integridad, etc. 
Conceptualmente la Base de Datos se diseña por medio de un DER, que se lleva a un MER, y un 
Diccionario de Datos Elemental. 
Nos basaremos en el ejemplo ficticio KnowWare del libro de C. J. Date: 
 
 
 
Como puede apreciarse las entidades están representadas mediante rectángulos y las relaciones 
mediante rombos. Para el desarrollo del curso se considerará una base de datos reducida, con las 
entidades Proveedores, Proyectos y Partes y sus relaciones. Todas las relaciones deben estar 
representadas en la Base de Datos ya que todas ellas son parte de los datos como lo son las entidades 
básicas. 
 
Además, hay que tener en cuenta, que al normalizar el diseño, necesariamente las relaciones van a 
establecerse por medio de tablas y vínculos entre éstas. Por ejemplo, tener una tabla que represente la 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 5 
relación VP, PY y la relación VPY ya que esta última representa los vínculos que se dan entre las tres 
entidades. 
 
Debería detallarse conceptualmente las entidades y relaciones involucradas, siendo de suma 
importancia considerar siempre las reglas de normalización, por lo menos hasta la tercera forma normal. 
 
ENTIDADES OBJETIVO ATRIBUTOS 
Proveedores Representa a los suministradores 
de partes, teniendo un estado 
particular y una ubicación única. 
id_v 
proveedor 
Status 
id_c 
Partes Representa las partes o clases de 
partes que se necesitan en los 
distintos proyectos; una parte 
puede formar parte de otra 
id_p 
Parte 
Color 
Peso 
id_c 
Id_p2 
Proyectos Son los distintos proyectos de la 
empresa 
id_y 
proyecto 
Ii_c 
Localidades Representa las ciudades en donde 
están ubicados los proveedores y 
los departamentos 
id_c 
ciudad 
Envíos Representa los envíos o 
cantidades enviadas de partes por 
los proveedores para 
determinados proyectos 
id_v 
id_p 
id_y 
cantidad 
 
RELACIONES DESCRIPCIÓN 
Proveedores – Localidades 
 1 � 1 
 n  1 
 
 Un proveedor está ubicado en una localidad en 
particular, y una localidad en particular puede 
tener uno o más proveedores 
Proveedores – Partes 
 1 � n 
 n  1 
 
Un proveedor suministra una o más partes, una 
parte puede ser suministrada por uno o más 
proveedores 
Proyectos – Partes 
 1 � n 
 n  1 
Un proyecto utiliza una o más partes, una parte 
puede ser utilizada por uno o más proyectos 
Proyectos - Proveedores 
 1 � n 
 n  1 
Un proyecto depende de uno o más proveedores 
y un proveedor provee a uno o más proyectos. 
Proveedores – Partes - Proyectos 
 1 � n 
 n  1 � n 
 n  1 
 
Un proveedor suministra una o más partes para 
uno o mas proyectos; un proyecto requiere una o 
más partes que son provistas por uno o más 
proveedores. 
Los elementos de datos o atributos necesarios y las reglas de integridad básicas para la base de 
datos se detallan a continuación: 
ATRIBUTO DESCRIPCIÓN TIPO DE 
DATOS 
REGLA DE 
INTEGRIDAD 
ENTIDAD 
id_v Código de proveedor Carácter (5) Clave primaria Proveedores 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 6 
Clave foránea Envios 
id_p Código de parte Carácter (6) 
Clave primaria Partes 
Clave foránea Envíos 
id_p2 
Código de parte 
principal 
Carácter (6) Clave foránea Partes 
id_y Código de proyecto Carácter (5) 
Clave primaria Proyectos 
Clave foránea Envíos 
id_c Código de ciudad Carácter (3) 
Clave primaria Localidades 
Clave foráneaProveedores 
Clave foránea Partes 
Clave foránea Proyectos 
ciudad Nombre de ciudad Carácter (20) No nulo Localidades 
proveedor Nombre de proveedor Carácter (20) No nulo Proveedores 
parte Nombre de parte Carácter (20) No nulo Partes 
proyecto Nombre de proyecto Carácter (20) No nulo Proyectos 
cantidad Cantidad enviada Numérico (9) > 0 y no nulo Envíos 
status Estado de proveedor Numérico (5) > 0 y no nulo Partes 
color Color de una parte Carácter (6) No nulo Partes 
peso Peso de una parte Numérico (5,1) > 0.0 y no nulo Partes 
Basándonos en lo anterior, el Modelo de Entidad Relación es el que se muestra en la siguiente 
figura: 
 
CREACIÓN DE LA BASE DE DATOS en función del diseño lógico y físico 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 7 
Introducción 
 
La base de datos puede crearse desde el Centro de Control, desde el Centro de Mandatos o 
desde el Procesador de la Línea de Comandos. 
 
Uno podría desde el Procesador de la Línea de Comandos o desde el Centro de Mandatos emitir 
la siguiente sentencia: 
 
-CREATE DATABASE KnowWare 
 
Pero ciertamente, DB2 crearía la base de datos con configuraciones por omisión. Es por ello que 
antes vamos a ver algunos conceptos importantes y útiles. 
El comando anterior, CREATE DATABASE sólo necesita el nombre de la base de datos. Las 
reglas para un nombre de tase de datos son: 
• El nombre de la base de datos puede tener los siguientes caracteres: a-z, A-Z, 0-9, @, #, and 
$. 
• El primer carácter debe ser uno alfabético, @, #, o $; no puede ser un número o letras con la 
secuencia SYS, DBM, o IBM. 
• Un nombre de base de datos, o un alias de base de datos deben estar formados por una 
cadena única de caracteres conteniendo de una a ocho letras, números o caracteres 
especiales del conjunto descrito arriba. 
Si emitiese el comando con el nombre de la base de datos únicamente, DB2 crearía 
automáticamente un número de archivos que incluirían entre otros, archivos log, de información sobre 
configuración, archivos históricos y tres espacios de tabla. Estos espacios de tabla son: 
• SYSCATSPACE: este es donde el catálogo de sistema de DB2 aloja las rutas de todos los 
meta datos asociados con los objetos DB2. 
• TEMPSPACE1: un área temporaria de trabajo donde DB2 puede almacenar los resultados 
intermedios. 
• USERSPACE1: un lugar donde todos los objetos de usuario (tablas, índices) residen por 
defecto. 
Todos estos archivos están ubicados dentro del directorio DB2 ubicado en su drive por defecto. El 
drive por defecto es típicamente el volumen en el cual instaló el producto DB2. 
Para aplicaciones simples, la configuración por defecto puede ser suficiente para sus necesidades. 
Sin embargo, podría querer cambiar la ubicación de sus archivos de base de datos, o cambiar la forma en 
que DB2 administra estos objetos. En la siguiente sección, exploraremos con más detalle el comando 
CREATE DATABASE. 
El comando CREATE DATABASE 
La sintaxis completa del comando DB2 CREATE DATABASE puede apreciarse en el siguiente 
diagrama que ilustra la mayoría de las opciones en las que un DBA podría estar interesado. 
 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 8 
 
 
En las siguientes secciones, aprenderemos de qué se tratan estas opciones y cómo podría 
utilizarlas. 
Ubicación de la Base de Datos 
Uno de los parámetros del comando CREATE DATABASE es el ON path/drive option. Esta 
opción le dice a DB2 dónde quiere crear la base de datos. 
En los sistemas que se basan en UNIX, esta opción especifica la ruta sobre la cual se crea la base 
de datos. Si la ruta no se especifica, la base de datos se crea en la ruta por defecto especificada en el 
archivo de Configuración de Administración de Base de Datos (DBM CFG) (en el parámetro dftdbpath). 
En los sistemas operativos Windows, esta opción especifica la letra del dispositivo sobre el cual 
crear la base de datos. 
Por ejemplo, en el sistema operativo Windows, el siguiente comando CREATE DATABASE ubica la 
base de datos MYDB en el drive D CREATE DATABASE MYDB ON D: 
Además, la base de datos puede llevar un alias o nombre alternativo. 
Códigos de Páginas y Secuencias de Cotejo 
Un carácter de código de página está asociado a todos los tipos de datos carácter de DB2 (CHAR, 
VARCHAR, CLOB, DBCLOB). Un código de página puede ser pensado como una tabla de referencia usada 
para convertir datos alfanuméricos a los datos binarios que se encuentran almacenados en la base de 
datos. Una base de datos DB2 sólo puede usar códigos de página simples. El código de página se 
establece con el comando CREATE DATABASE usando las opciones CODESET y TERRITORY. El código de 
página puede usar un byte simple para representar un carácter alfanumérico (un byte simple puede 
representar 256 elementos únicos) o bytes múltiples. 
Los lenguajes como el Inglés contienen relativamente pocos caracteres únicos; entonces, un código 
de página de byte simple es suficiente para almacenar los datos. Lenguajes como el Japonés requieren más 
de 256 elementos para representar todos sus caracteres únicos; entonces, un código de página múltiple es 
necesario (generalmente un código de páginas double-byte). 
Por defecto, la secuencia de cotejo (collating sequence) de una base de datos está definida de 
acuerdo al conjunto de códigos usado en el comando CREATE DATABASE. Si especifica la opción 
COLLATE USING SYSTEM, los valores de los datos son comparados en base al territorio (TERRITORY) 
especificado para la base de datos. Si se usa la opción COLLATE USING IDENTITY, todos los valores son 
comparados utilizando sus representaciones binarias en forma byte-a-byte. 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 9 
La opción DFT_EXTENT_SZ dft extentsize especifica el tamaño de la extensión por defecto de 
los espacios de tabla de la base de datos. 
En la mayoría de los casos, un DBA podrá dejar este valor por defecto con el mismo código de 
página que el del sistema operativo sobre el que la base de datos correrá. 
Definiciones de Espacios de Tabla 
Cada uno de los tres espacios de tabla (SYSCATSPACE, TEMPSPACE1, USERSPACE1) son 
creados automáticamente en el directorio por defecto (ON keyword) a menos que usted especifique su 
ubicación. Para cada espacio de tabla, el DBA puede especificar las características del sistema de archivos 
que el espacio de tabla debería usar. 
Los tres espacios de tabla son definidos usando la siguiente sintaxis: 
 
 
Si cualquiera de estas palabras clave son omitidas, DB2 utilizará los valores por defecto para 
generar los espacio de tabla. La definición de un espacio de tabla sigue estas opciones y tiene la siguiente 
sintaxis: 
 
La opción MANAGED BY le dice a DB2 que genere estos espacios de tabla y determina cuánto 
espacio será administrado. Los espacios de tabla SMS usan la clave SYSTEM USING como se muestra 
abajo: 
SYSTEM USING ('container string'): Para un espacio de tabla SMS, el container string 
identifica uno o más contenedores que pertenecerán al espacio de tabla y dentro de los cuales los datos del 
espacio de tabla serán almacenados. Cada cadena de contenedor puede ser un nombre de directorio 
relativo o absoluto. El nombre de directorio, si no es absoluto, es relativo al directorio de la base de datos. Si 
cualquier componente del nombre de directorio no existe, es creado por el administrador de bases de datos. 
El formato de la cadena del contenedor es dependiente del sistema operativo. 
Los espacios de tabla DMS son definidos mediante la palabra clave DATABASE USING: 
DATABASE USING ( FILE/DEVICE 'container string' number of pages ) 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 10 
Para un espacio de tabla DMS, la cadena del contenedoridentifica uno o más contenedores que 
pertenecerán al espacio de tabla y dentro del cual serán almacenados los datos del espacio de tabla. El tipo 
del contenedor (bien sea FILE o DEVICE) y su tamaño (in PAGESIZE pages) son especificados. El tamaño 
puede también ser especificado como un valor entero seguido de una K (por kilobytes), M (por megabytes) 
or G (por gigabytes). Puede especificar un mixture de contenedores de tipo FILE y DEVICE. 
Para un contenedor FILE, la cadena que representa al contenedor debe ser un nombre de archivo 
absoluto o relativo. El nombre del archivo, si no es absoluto, es relativo al directorio de la base de datos. Si 
cualquier componente del nombre del directorio no existe, será creado por el administrador de base de 
datos. Si el archivo no existiese, será creado e inicializado al tamaño especificado por el administrador de 
base de datos. Para un contenedor DEVICE, la cadena que representa al contenedor deberá ser un 
nombre de dispositivo y el nombre de dispositivo debe realmente existir. 
Una nota importante: todos los contenedores deben ser únicos a lo largo de todas las bases de 
datos; un contenedor puede pertenecer sólo a un espacio de tabla. 
La opción EXTENTSIZE number of pages especifica el número de páginas PAGESIZE que 
toda la base de datos deberá escribir hacia el contenedor antes de saltar al siguiente contenedor. El valor 
EXTENSIZE puede también ser especificado como un valor entero seguido de K, M, o G. El administrador 
de bases de datos rota repetidamente en ciclos a través de los contenedores a medida que los datos se 
almacenan. 
Una extensión es una unidad de espacio dentro de un contenedor o un espacio de tabla. Los 
objetos de base de datos (excepto para los LOBs y long varchars) son almacenados en páginas dentro de 
DB2. Estas páginas están agrupadas dentro de extensiones. El tamaño de la extensión está definida a nivel 
de espacio de tabla. Una vez que la extensión está definida para un espacio de tabla, la misma no puede 
alterarse. El parámetro de configuración de la base de datos DFT_EXTENT_SZ especifica el tamaño de la 
extensión por defecto para todos los espacios de tabla de la base de datos. Este valor puede rondar entre 
las 2 a las 256 páginas; esto es, el valor absoluto de su tamaño podrá estar entre 8 KB a 1204 KB para 
páginas de 4 KB; o desde 16 KB a 2048 KB para páginas de 8 KB. 
La opción PREFETCHSIZE number of pages especifica el número de páginas de PAGESIZE 
que serán leías desde el espacio de tabla cuando la operación de carga de datos está siendo realizada. El 
valor prefetch size puede también ser especificado como un valor entero seguido de K, M, o G. 
La recopilación y carga (prefetch) secuencial es la capacidad del administrador de bases de datos 
de anticipar una consulta por adelantado, leyendo las páginas antes de que estas hayan sido referenciadas 
realmente. Esta recuperación asíncrona puede reducir los tiempos de ejecución significativamente. Usted 
puede controlar cuán agresiva es la tarea de anticipación (prefetch) cambiando el parámetro 
PREFETCHSIZE. Por defecto este valor está fijado por el parámetro de configuración de base de datos 
DFT_PREFETCH_SZ. Este valor representa cuántas páginas serán leídas de una vez cuando una petición 
(prefetch) es activada por DB2. Al fijar este valor a un múltiplo del tamaño de la extensión, múltiples 
extensiones pueden leerse en paralelo. Esta función es aún más efectiva cuando los contenedores del 
espacio de tabla están en discos separados. 
Las lecturas anticipadas de los datos necesitan de una consulta anterior que los referencie, de modo 
que la consulta no necesite esperar a las capas subyacentes del sistema operativo para realizar las 
operaciones de Entrada/Salida. 
Creación de la Base de Datos KnowWare 
El siguiente es un ejemplo del comando CREATE DATABASE que utiliza en la mayoría de las 
opciones que hemos visto en los paneles previos. 
El siguiente es un ejemplo del comando CREATE DATABASE que utiliza en la mayoría de las 
opciones que hemos visto en los paneles previos. 
1. CREATE DATABASE KNOWWARE ON C: 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 11 
2. USING CODESET IBM-1252 TERRITORY ES COLLATE 
3. USING SYSTEM USER TABLESPACE MANAGED BY DATABASE USING 
4. (FILE 'C:\DB2USER\USERTP.DAT' 1024) 
5. EXTENTSIZE 16 
6. PREFETCHSIZE 16 
7. OVERHEAD 10.50 TRANSFERRATE 0.14 
8. CATALOG TABLESPACE MANAGED BY SYSTEM USING 
9. ('E:\DB2CAT\CATALOG.DAT','C:\DB2CAT\CATALOG.DAT') 
10. EXTENTSIZE 8 
11. PREFETCHSIZE 8 
12. OVERHEAD 10.50 TRANSFERRATE 0.14 
13. TEMPORARY TABLESPACE MANAGED BY SYSTEM USING 
14. ('C:\DB2TMP\TEMPTP.DAT', 'E:\DB2TMP\TEMPTP.DAT') 
15. EXTENTSIZE 32 
16. PREFETCHSIZE 32 
17. OVERHEAD 10.50 TRANSFERRATE 0.14; 
Veamos cada línea con mayor detalle: 
1. CREATE DATABASE: esta sentencia define el nombre de la base de datos que se está creando y 
dónde se está creando. 
2. USING CODESET IBM-1252 TERRITORY ES COLLATE: este parámetro le dice a DB2 que el 
sistema coteja el código de página en base al territorio, que en este caso es español (ES). 
3. USING SYSTEM USER TABLESPACE MANAGED BY DATABASE USING: el espacio de tablas 
de usuario es manejado por la base de datos 
4. (FILE 'C:\DB2USER\USERTP.DAT' 1024): la ubicación del espacio de tabla de usuario 
está ubicado en un archivo de 1204 páginas (cada página es de 4 Kb� 4 Mb es el tamaño del 
espacio de tabla). 
5. EXTENTSIZE 16: será de 16 páginas. 
6. PREFETCHSIZE 16: Durante el proceso de consultas, serán leídas al mismo tiempo 16 páginas. 
7. OVERHEAD 10.50 TRANSFERRATE 0.14: opciones de rendimiento 
8. CATALOG TABLESPACE MANAGED BY SYSTEM USING: El espacio de tabla del catálogo usado 
por DB2 será manejado por el sistema operativo. 
9. 'E:\DB2CAT\CATALOG.DAT','C:\DB2CAT\CATALOG.DAT': el espacio de catálogo estará 
particionado en dos archivos cuyo tamaño se ajustará automáticamente durante la ejecución de 
DB2. 
10. EXTENTSIZE 8: será de 8 páginas, 8 páginas se escribirán al contenedor antes de saltar al 
siguiente contenedor. 
11. PREFETCHSIZE 8: Durante el proceso de consultas, serán leídas al mismo tiempo 8 páginas. 
12. OVERHEAD 10.50 TRANSFERRATE 0.14 
13. TEMPORARY TABLESPACE MANAGED BY SYSTEM USING: El espacio temporal será manejado 
por el sistema operativo. 
14. 'C:\DB2TMP\TEMPTP.DAT', 'E:\DB2TMP\TEMPTP.DAT': el espacio temporal estará 
particionado en dos archivos cuyo tamaño se ajustará automáticamente durante la ejecución de 
DB2 
15. EXTENTSIZE 32: será de 32 páginas. 
16. PREFETCHSIZE 32: Durante el proceso de consultas, serán leídas al mismo tiempo 32 páginas. 
17. OVERHEAD 10.50 TRANSFERRATE 0.14 
La base de datos puede crearse tanto así como con auxilio del Asistente para Creación de Base de 
Datos. 
Una vez creada, siempre hay que utilizar el Asistente de Configuración para que optimice las 
opciones de rendimiento y configure el archivo de configuración de la base de datos. La forma más fácil y 
práctica de efectuar esta tarea es mediante el Centro de Control. 
Utilización del Centro de Mandatos de DB2 para crear la Base de Datos KnowWare 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 12 
El Centro de Mandatos DB2 sirve, entre otras cosas, para ejecutar los comandos DB2 y sentencias 
SQL; así como para trabajar con scripts de comandos. Es además una herramienta visual que ha sido 
desarrollada en Java. 
Para iniciarlo puede clickear sobre el icono apropiado en la barra de tareas del Centro de Control, a 
través del Menú Inicio, en el grupo de programas IBM DB2/Herramientas de Línea de Comandos o bien 
ingresando el comando db2cctr en la línea de comandos del Procesador de Mandatos de DB2, también 
desde el Menú Inicio. 
 
En la siguiente imagen mostramos el Centro de Mandatos, y hemos seleccionado el tipo de 
mandatos CLP de DB2; esto es un mandato equivalente a usar el Procesadorde la Línea de Comandos o 
Mandatos de DB2 que es similar como la ventana de comandos que trae Windows. 
 
Las funcionalidades del Centro de Mandatos y las características del Procesador de la Línea de 
Mandatos de DB2 están descriptas en el Capítulo 6. 
 
 
 
En la solapa Scripts vamos a escribir el comando de creación de la base de datos KnowWare como 
la describimos anteriormente y luego procederemos a ejecutar el script mediante el botón correspondiente 
de la barra de tareas: 
 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 13 
 
 
 
Cuando termina la ejecución del Script, si no ha acaecido ningún error, el resultado de la ejecución 
se muestra en la ventana inferior. 
El Menú Script permite igualmente ejecutar los mismos, pero también presenta una variedad 
interesante de opciones. Los scripts son un medio para ejecutar comandos en forma masiva, pueden 
escribirse utilizando un procesador de texto común y luego importarse; así como pueden escribirse 
directamente en el Centro de Mandatos y guardarse posteriormente para su posterior importación. 
 
 
 
Ahora veremos en una forma visual, qué es lo que DB2 ha creado en base al comando que 
acabamos de ejecutar. Para ello utilizaremos la principal herramienta integrada y visual que trae DB2: el 
Centro de Control 
Utilización del Centro de Control para ver la Base de Datos recién creada 
Seguidamente se muestra el Centro de Control (CC). Como puede apreciar, si tiene experiencia con 
las herramientas Microsoft, puede utilizar fácilmente esta herramienta; el arreglo, con objetos en el lado 
izquierdo y su detalle en el derecho, debería resultarle familiar. 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 14 
 
El Centro de Control se apoya en el Servidor de Administración de Base de Datos (o DAS). El DAS 
ayuda al CCl a programar tareas para que corran junto al servidor de base de datos, a administrar objetos 
en servidores de base de datos remotos y mucho más. 
Al pulsar el botón derecho sobre cualquiera de los objetos del árbol de objetos se muestra un menú 
pop-up con todas las funciones que podría realizar sobre el objeto seleccionado. 
La siguiente imagen muestra la agregada en el árbol de objetos la Base de Datos KnowWare: 
 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 15 
En el árbol jerárquico puede apreciarse que ahora aparece la Base de Datos KnowWare y además 
pueden verse los distintos objetos que se han creado (tablas, vistas, índices, espacios de tabla, etc.) 
En la siguiente figura se muestra que las tablas que se han creado hasta el momento son las del 
Catálogo. Todavía no hemos creado las tablas de usuario. A un nivel lógico, todas las tablas, incluidas estas 
últimas, se mostrarán en este árbol jerárquico, aunque físicamente se encuentren en espacios de tabla 
distintos. 
 
Recorriendo el árbol jerárquico podemos ver también los espacios de tabla creados al ejecutar la 
sentencia de creación de la base de datos. La imagen siguiente nos muestra estos espacios de tabla y 
podemos desplazarnos a la derecha para ver los atributos generales de cada uno de ellos. 
 
Ing. Santiago Pérez - Aus Laura Noussan Lettry Capítulo 1 Calificación IBM -DB2 pág. 16 
Si queremos manipular un objeto en particular de la base de datos, seleccionarlo con el mouse y 
pulsar el botón derecho de éste. La siguiente figura muestra las distintas opciones que tenemos respecto a 
los espacios de tabla: 
 
Si seleccionamos Modificar Espacio de Tabla SYSCATSPACE, tendremos a la vista la información 
sobre el nombre, tipo y quién lo gestiona, los contenedores y las opciones de rendimiento. 
 
 
Para obtener mayor información sobre qué utilidades brinda el Centro de Control, nos remitimos al 
Capítulo 6