Presentación de la asignatura

Justificación

La información es el centro de las actividades de nuestros tiempos. Las

organizaciones de hoy no pueden operar si no poseen información. De diferentes
formas, los negocios actualmente giran en torno a la información. Sin administrar
correctamente su información, las organizaciones no podrían controlar las
finanzas, efectuar transacciones o contactar con sus clientes. Las Bases de datos
fueron creadas para almacenar y gestionar la información. Por estos motivos, una
Base de datos correctamente diseñada y administrada se constituye en un puntal
importante para que una organización pueda posicionarse adecuadamente en su
mercado y con esto su dominio pasa a ser un pilar fundamental en la formación de
un Ingeniero de Software.

En este sentido la asignatura se propone aportar el conocimiento necesario para

diseñar y edificar sistemas de datos y de bases de datos correctos y completos en
términos de las exigencias y estándares de la Ingeniería de Software y las buenas
prácticas.

Descripción de la asignatura

En los capítulos de la asignatura se abordan varios aspectos esenciales para la

gestión de Bases de Datos y Recursos de Información:

- Se revisan las características de la Información, La Gestión del Conocimiento y

La información como recurso principal de las Organizaciones.

- Se define la Administración de Bases de Datos, los tipos de DBA, las tareas del
DBA y su ámbito en las organizaciones.

- Se indican las consideraciones para escoger un DBMS, las fases de una

Instalación, los tipos de actualizaciones y la definición de estándares requeridos
en un ambiente de Bases de datos.

- Se describen los componentes de un Modelo de Datos, las fases del Diseño de

Bases de datos y el Proceso de Normalización.

- Se realiza una descripción del lenguaje SQL, el control de transacciones y

bloqueos.

- Se define la Integridad semántica y estructural, así como los mecanismos para

su control.
- Se define el Downtime, los problemas comunes de disponibilidad, y los
mecanismos para el aseguramiento de la información.

Objetivos

Objetivo general

La asignatura tiene como objetivo general realizar una introducción a los

conceptos y soluciones que un Administrador de Tecnologías de la Información
debe conocer para lograr una gestión adecuada de la información en su
Organización como parte de un proyecto de Ingeniería de Software.

Objetivos específicos

- Identificar la necesidad de las organizaciones de gestionar adecuadamente su

información.

- Describir adecuadamente el ámbito de trabajo del DBA.

- Indicar la forma adecuada de gestionar la instalación de un DBMS.

- Definir el proceso de Modelamiento de datos.

- Definir los elementos de las Aplicaciones que tienen incidencia en el rendimiento

de las Bases de datos.

- Definir las condiciones que deben asegurar los DBMS para mantener la
información libre de errores.

- Identificar los riesgos que tienen los Sistemas de almacenamiento de

información, así como su mitigación.

Organización del contenido y estructura del documento

A continuación se hace una presentación resumida de los contenidos junto a sus

objetivos específicos y a su valor añadido en el contexto de la asignatura:

APORTACIÓN Y
CAPÍTULO OBJETIVOS RESUMEN DEL CAPÍTULO RESULTADO
CONSEGUIDO
Revisión de las características
Identificar la necesidad
de la Información, La Gestión Se reconoce el impacto de
de las organizaciones
del Conocimiento y La la gestión adecuada de la
Capítulo 1 de gestionar
información como recurso información en las
adecuadamente su
principal de las organizaciones.
información.
Organizaciones.
 Definición de la Administración Se identifican las tareas
Describir
de Bases de Datos, los tipos específicas que debe tener
adecuadamente el
Capítulo 2 de DBA, las tareas del DBA y un DBA, para distinguirlo de
ámbito de trabajo del
su ámbito en las otros miembros de un
DBA.
organizaciones. equipo de IT.
Indicación de las
consideraciones para escoger
Se reconoce que un DBMS
Indicar la forma un DBMS, las fases de una
debe ser escogido en base
adecuada de gestionar Instalación, los tipos de
Capítulo 3 a criterios técnicos, por el
la instalación de un actualizaciones y la definición
personal de IT de la
DBMS. de estándares requeridos en
organización.
un ambiente de Bases de
datos.
Descripción de los Se identifican los factores
Definir el proceso de componentes de un Modelo críticos del modelamiento
Capítulo 4 Modelamiento de de Datos, las fases del Diseño de datos y su influencia en
datos. de Bases de datos y el la estructura de la
Proceso de Normalización. información organizacional.
Se reconocer al DBA como
Definir los elementos promotor de las buenas
de las Aplicaciones que Descripción del lenguaje SQL, prácticas de programación
Capítulo 5 tienen incidencia en el el control de transacciones y utilizando Bases de datos,
rendimiento de las bloqueos. para asegurar el correcto
Bases de datos. rendimiento de las
aplicaciones.
Definir las condiciones
Definición de la Integridad Se reconoce la integridad
que deben asegurar los
semántica y estructural, así de la información como un
Capítulo 6 DBMS para mantener
como los mecanismos para su factor crítico de la gestión
la información libre de
control. de Bases de datos.
errores.
Definición del Downtime, los
Identificar los riesgos Se reconoce la criticidad de
problemas comunes de
que tienen los Sistemas la disponibilidad de los
disponibilidad, y los
Capítulo 7 de almacenamiento de DBMS's para el desarrollo
mecanismos para el
información, así como de las actividades de las
aseguramiento de la
su mitigación. organizaciones.
información.

Capítulo 1.- Gestión Tecnológica de la

Información

OBJETIVOS
- Definir la Información como recurso estratégico de las organizaciones.

- Identificar las características y funciones de la Información.

- Identificar los principios de la Gestión del conocimiento.

1.1. Introducción
En nuestros días, que vivimos en un mundo globalizado, con alta incertidumbre y
competencia, la gestión de la información se ha convertido en elemento que sirve
para marcar diferencias y lograr ventaja competitiva. En este sentido, las
Tecnologías de la Información ofrecen herramientas propicias para salvaguardar el
conocimiento.

El objetivo general de los Sistemas de Gestión de base de datos (DBMS, por sus
siglas en inglés) es el de administrar de forma clara, sencilla y ordenada un
conjunto de datos que en lo posterior se convertirán en información relevante para
una organización.

Los DBMS's son la herramienta de software más idónea para manejar información
debido a que cumplen los siguientes objetivos:

- Abstracción de la información: los DBMS's abstraen a los usuarios de detalles

acerca del almacenamiento físico de los datos. Es igual si una base de datos
ocupa uno o varios Megabytes, este hecho se hace transparente al usuario.

- Independencia: la independencia de los datos consiste en la capacidad de

modificar el modelo físico o lógico de una base de datos, sin tener que realizar
cambios en las aplicaciones que la consultan.

- Consistencia: los DBMS's garantizan que los datos son siempre guardados de
forma coherente con Modelo de datos. Se garantiza que diferentes consultas de
una misma información siempre obtendrán el mismo resultado.

- Seguridad: la información almacenada en una base de datos puede llegar a ser

de gran valor. Los DBMS's disponen de un complejo sistema de permisos para
usuarios y grupos de usuarios, que permiten otorgar diversos perfiles de permisos.

- Integridad: los DBMS's adoptan las medidas necesarias para garantizar la validez
de los datos almacenados. Es decir, se trata de proteger los datos ante errores de
hardware, datos introducidos por usuarios sin pericia, o cualquier otra
circunstancia en que se pueda corromper la información almacenada. Los DBMS's
proveen elementos para garantizar la recuperación de la base de datos hasta el
último estado consistente conocido, de forma automática.

- Respaldo: los DBMS's proporcionan una manera eficaz de realizar copias de

respaldo de la información almacenada, y de restaurar a partir de estas copias los
datos que se hayan podido perder durante un siniestro.

- Control de la concurrencia: en la mayor parte de los ambientes, lo más habitual

es que sean muchas las personas que intentan ingresar a una base de datos,
tanto para recuperar información, como para guardarla o modificarla. Y es también
frecuente que dichos accesos se realicen de forma concurrente. Así pues, un
DBMS debe controlar este acceso simultáneo a la información, que podría dar
lugar a inconsistencias.

- Manejo de Transacciones: una Transacción es un programa que se ejecuta como

una sola operación. Esto quiere decir que el estado luego de una ejecución en la
que se produce un error es el mismo que se obtendría si el programa no se
hubiera ejecutado (estado inicial). Los DBMS's proveen componentes para
programar las modificaciones de los datos de una forma mucho más simple que si
no se dispusiera de ellos.

- Tiempo de respuesta: es deseable minimizar el tiempo que el DBMS tarda en

darnos la información requerida, y en guardar los cambios realizados.

1.2. La información
La información proporciona significado y sentido a las cosas, e indica mediante
códigos y grupos de datos, los modelos del pensamiento humano. La información
permite generar el conocimiento. Aunque otros seres vivos son capaces de
comunicarse transmitiendo información para su supervivencia, los seres humanos
en su capacidad de generar y perfeccionar códigos y símbolos que tienen
significado, crearon lenguajes comunes que resultaron útiles para la convivencia
en sociedad, a partir del establecimiento de sistemas de signos y lenguajes para la
comunicación.

La información es un grupo organizado y coherente de datos procesados, que

constituyen un mensaje sobre una determinada entidad o fenómeno. Cuando
tenemos que resolver un problema o hay que tomar una decisión, se emplean
diferentes fuentes de información, y se construye lo que en general se denomina
conocimiento o información organizada, que permite resolver problemas o tomar
decisiones.

Los datos se reúnen de fuentes diversas, y mediante su procesamiento se crea la

información necesaria para generar el conocimiento que es lo que finalmente
permite tomar decisiones para realizar las acciones habituales que aseguran la
existencia social. El ser humano ha sido capaz de simbolizar los datos en forma
representativa (lenguaje) para hacer posible el conocimiento de algo concreto, y
ha creado las formas de almacenar y utilizar el conocimiento representado.

Figura 1.1: La información.

1.2.1. Características de la Información

La información tiene las siguientes características:

- Tiene significado, es independiente o relativo a un contexto.

- Su importancia es relativa en quien la recibe.

- Tiene vigencia en la dimensión espacio-tiempo.

- Tiene valor intrínseco.

- Polimorfismo.

1.2.2. Funciones de la Información

La generación y obtención de información persigue estos objetivos:

- Aumentar el conocimiento de quien la utiliza.

- Proporcionar a quien toma decisiones el material fundamental para el desarrollo

de opciones y la elección final.

- Proporcionar reglas de evaluación y decisión con fines de control.

La Información, como vía para llegar al Conocimiento, tiene que ser elaborada
para ser utilizada y estar disponible. Este procedimiento se llama Documentación,
y cuenta con métodos y herramientas propios.

1.3. La Gestión del Conocimiento

A partir de los años Ochenta, las Organizaciones empezaron a darse cuenta de la
importancia de su información y de tratar de lograr la mejor gestión de este
conocimiento. El conocimiento es reconocido como el activo más valioso de la
Organización, como el único recurso económico significativo y por lo tanto se
hacen esfuerzos por definir formas de adquirirlo, representarlo, retenerlo y
administrarlo.

Dentro del objetivo de la administración y gerencia del conocimiento está lo que la

organización sabe sobre sus productos, procesos, mercados, clientes, empleados,
y sobre el cómo combinar estos elementos para lograr que una Organización sea
competitiva. En este aspecto, esta disciplina parece replicar al propósito de la
Gestión Tecnológica de la Organización, pero por ser de mayor alcance parece
contenerla.

1.3.1. Ventajas competitivas del Conocimiento en la Organización

El desafío de aplicar el conocimiento en una Organización para crear ventajas

competitivas se hace aún más importante debido a:

- El mercado se vuelve cada vez más competitivo, por lo que se demanda mayor
innovación en los productos y servicios. El conocimiento debe desarrollarse y ser
asimilado con mayor velocidad.

- Las Organizaciones están enfocando sus esfuerzos en lograr mayor valor

agregado para sus clientes. Las funciones del personal administrativo se han ido
reduciendo, así como también los mismos niveles de administración. Existe la
necesidad de sustituir la manera informal de manejar el conocimiento en las
funciones administrativas por métodos científicos, dentro de procesos de negocios
con orientación al cliente.

- La presión de la competencia reduce el tamaño de los grupos de colaboradores

que poseen el conocimiento de la organización.

- Se requiere tiempo para lograr el conocimiento y adquirir experiencia a partir de

él. Los funcionarios cada vez tienen menos tiempo para hacerlo.

- Hay una tendencia creciente de los empleados a retirarse cada vez más
temprano en su vida laboral o de aumentar su movilidad entre organizaciones, lo
cual ocasiona que el conocimiento de la empresa se pierda.

- Existe la necesidad de manejar mayor complejidad en empresas pequeñas,

medianas y transnacionales.

- Los cambios en la Dirección estratégica de la organización pueden causar

pérdida de conocimiento en un área específica. Una decisión posterior que retome
la anterior orientación puede necesitar ese conocimiento, pero el funcionario que
lo posee puede ya no estar en la organización.
1.3.2. Principios de la Gestión del Conocimiento

El profesor Thomas H. Davenport, de la Universidad de Texas, encauza la

gerencia del conocimiento desde un punto de vista pragmático al describir diez
principios generales para la Gestión del conocimiento. Una vez que una
organización comprende estos principios, le pueden servir de base para generar
estrategias detalladas. Los diez principios expuestos por Davenport son los
siguientes:

1. Gestionar el conocimiento es caro: el conocimiento es un activo, pero su gestión

efectiva requiere inversiones en otros activos, principalmente en Tecnología.

2. La gerencia efectiva del conocimiento requiere soluciones híbridas de personal

y tecnología: pese a los avances de la Informática, no puede decirse aún que se
tenga una computadora que pueda reemplazar a los humanos por completo. Los
hechos comprueban que las organizaciones que desean una efectiva gestión de
su conocimiento, requieren una alta cuota de esfuerzo humano. Las personas son
muy buenas para ciertos tipos de actividades, las computadoras lo son para otras.

3. La gestión del conocimiento es altamente política: no resulta un secreto que el

conocimiento es poder y por lo tanto, no es una sorpresa que la gestión del
conocimiento tenga un trasfondo altamente político. Si el conocimiento está
asociado con el poder, el dinero y el éxito, entonces también está asociado con las
intrigas y tratos velados que tienen lugar en las organizaciones.

4. La gestión del conocimiento requiere gerentes del conocimiento: los recursos

primarios de un negocio como el trabajo y el capital, tienen funciones
organizacionales dedicadas a su administración y gerencia. El conocimiento no
puede ser bien administrado hasta que algún grupo en la organización tenga la
responsabilidad principal de realizar ese trabajo. Dentro de las tareas que este
departamento puede llevar a cabo está el recolectar y categorizar el conocimiento,
establecer una infraestructura orientada al conocimiento y monitorear su
utilización.

5. La gestión del conocimiento brinda más beneficios a partir de mapas que a

partir de modelos, más a partir de mercados que a partir de jerarquías.

6. El compartir y utilizar conocimiento no son acciones naturales, frecuentemente.

7. La Gestión del conocimiento implica mejorar los procesos del negocio que se
basan en conocimiento: es primordial dar dirección y mejorar el proceso genérico
de la gestión del conocimiento, pero se debe hacer donde el conocimiento es
generado, utilizado y compartido con intensidad, en la organización.
8. El acceso al conocimiento es sólo el principio: el acceso es muy importante,
pero la gestión exitosa del conocimiento también requiere control y compromiso.
Se dice que el control es el dinero efectivo de la era de la información.

9. La gestión del conocimiento nunca para: tal como ocurre con la gerencia de
Recursos Humanos o Administrativa, nunca llega el momento en que se pueda
decir que el conocimiento está completamente bajo control.

10. La gestión del conocimiento requiere un contrato de conocimiento: es probable

que en muchas organizaciones no se sepa con certeza quién es el dueño o quién
tiene el derecho de uso del conocimiento de sus funcionarios.

1.4. La Información como recurso

A fines de los años Sesenta, los sistemas de computación cambiaron el paradigma
del procesamiento de los datos por el del procesamiento de la información. Este
cambio reflejó una conciencia de que la información era mucho más que simples
archivos relacionados con el negocio. Poco a poco en las Organizaciones
comenzaron a darse cuenta del valor de la información y del enorme potencial que
los Sistemas informáticos representaban para organizar y administrar este
recurso.

En los años siguientes, el impacto trascendental que tuvo la información sobre la

planificación y la toma de decisiones en las Organizaciones, condujo a un
reconocimiento constante de que la información es un recurso que posee valor y
que debe estar organizada y administrada.

Debido a que en las Organizaciones es común trabajar con Activos tangibles cuyo
valor puede ser medido con mucha precisión, ha sido muy complicado determinar
el valor de la información. Sin embargo está claro que si los directores tienen
información adecuada, es más probable que puedan tomar decisiones pertinentes
y certeras con un mayor impacto positivo en el negocio. El desarrollo de los
Sistemas de Bases de Datos se convirtió en crucial para proporcionar información
correcta y oportuna, frente al almacenamiento en Sistemas de Archivo que era
utilizado entonces.

A pesar de la introducción de los archivos de acceso directo, pronto se hizo obvio

que a los sistemas de archivo de cualquier tipo era inherente un conjunto de
deficiencias:

- Redundancia de datos.

- Pobre control de los datos.

- Capacidades inadecuadas de manipulación de datos.

- Esfuerzo excesivo de programación.

1.5. Los Sistemas de Gestión de

Bases de Datos
Los Sistemas de Gestión de Bases de Datos (DBMS, por sus siglas en inglés)
superaron las limitaciones que tenían los sistemas orientados a archivos. Al tolerar
una estructura de datos centralizada e integrada, los DBMS's eliminaron los
problemas de redundancia y control de datos.

En la actualidad estamos inmersos en varias décadas de largo esfuerzo por

desarrollar DBMS's cada vez más poderosos.

1.5.1. Evolución de la Arquitectura de los DBMS's

Las bases de datos aparecieron a finales de la década de 1960, cuando surgió la

necesidad de contar con un sistema de administración de información flexible.
Existen cinco modelos de DBMS's, que se distinguen según cómo representan los
datos almacenados:

- El modelo jerárquico: los datos se organizan de forma jerárquica, mediante un

árbol invertido. Este modelo utiliza punteros para navegar por los datos
almacenados. Este fue el primer modelo DBMS.

Figura 1.2: Modelo Jerárquico.

- El modelo de red: al igual que el modelo jerárquico, usa punteros hacia los datos
almacenados. Sin embargo, no necesariamente utiliza una estructura de árbol
invertido.
 Figura 1.3: Modelo de Red.

- El modelo relacional (RDBMS, Relational database management system): los

datos se almacenan en tablas de dos dimensiones (filas y columnas). Los datos se
manipulan según la teoría relacional.

Figura 1.4: Modelo Relacional.

- El modelo deductivo: los datos se representan como una tabla, pero se operan
mediante cálculos de predicados.

- El modelo de orientación a objetos (ODBMS, object-oriented database

management system): los datos se almacenan como objetos, que son estructuras
denominadas clases que muestran los datos que contienen. Los campos son
instancias de estas clases.

Figura 1.5: Modelo de Orientación a Objetos.

Capítulo 2.- Definición del trabajo del
administrador de Bases de Datos

OBJETIVOS

- Establecer la estructura y funciones adecuadas para el trabajo del personal que maneja
información en las organizaciones, separando los factores técnicos y de negocio.

- Revisar las tareas comunes de los DBA's, dependiendo de su orientación.

2.1. Introducción
Toda organización que utilice una Base de datos para organizar su información,
requiere de un grupo de Administración para asegurar su adecuado
funcionamiento. A pesar de esto, la Administración de Bases de datos no siempre
es practicada adecuadamente, para lograr resultados óptimos.

Un Administrador de Bases de Datos (DBA, por sus siglas en inglés) es un técnico

informático responsable de asegurar la funcionalidad operativa de las Bases de
datos de una organización, con el objetivo de que las aplicaciones trabajen
correctamente. En este capítulo revisaremos el alcance del trabajo del DBA.

2.2. Administración de Bases de

Datos, Datos y Sistema
La tendencia en las organizaciones es separar en roles diferentes los aspectos
técnicos y de negocio de la información. Los aspectos de negocio están ligados a
la administración de la información (cómo se obtiene la información, su flujo,
usuarios), mientras que los aspectos técnicos se relacionan con la administración
de las Bases de datos. Pero en la actualidad, solamente algunas grandes
organizaciones tienen estructuras funcionales para la administración de la
información, por lo que generalmente se mezclan las funciones dentro del rol de
Administración de Bases de datos.
2.2.1. Administración de Datos

La Administración de los Datos separa los aspectos de negocio de los aspectos

técnicos, con relación a la información.

Un Administrador de datos conoce la información y las necesidades de la

empresa, en un nivel gerencial superior. Su labor es decidir en primer término
cuáles datos deben almacenarse en la Base de Datos, y establecer políticas para
mantener y manejar los datos una vez almacenados. El perfil debe ser
principalmente de gestión antes que técnico, aunque sí se necesita apreciar las
posibilidades de los sistemas de Bases de Datos en un nivel técnico.

Las principales tareas del Administrador de Datos son:

- Identificar y clasificar los requerimientos de información de los usuarios.

- Producir los modelos de datos conceptuales y lógicos, de acuerdo a los Procesos

de Negocio de la organización.

- Creación y mantenimiento del Modelo corporativo de Información que considera

todos los Procesos de Negocio.

- Establecer la Política de acceso a la Información.

- Identificar a los Dueños de la información y a sus Usuarios.

- Establecer los estándares de control de datos.

Como se ha mencionado la Administración de los Datos debe manejarse a nivel

ejecutivo. Lastimosamente, cuando esta tarea recae sobre personal técnico, se
falla en concentrar los aspectos no tecnológicos de la información, debido a los
siguientes aspectos:

- Las tareas para asegurar técnicamente la disponibilidad de los datos cubren toda
la jornada, e incluso se realizan en horarios fuera de oficina, para no interrumpir a
los usuarios.

- El DBA no tiene una posición ejecutiva suficiente para la disposición de políticas

que sean acatadas por toda la organización.

- El personal técnico, por lo general, no cuenta con las habilidades de

comunicación necesarias para transmitir ideas y lograr consensos.

Cuando los dos roles están separados en la organización en estructuras

funcionales diferentes, los grupos deben trabajar en conjunto. No es necesario que
tengan un mismo Gerente, pero esto podría facilitar la comunicación.
2.2.2. Administración de Bases de Datos

El Administrador de Bases de Datos (DBA) es un profesional en procesamiento de

datos. Sus tareas comprenden en crear la Base de Datos en sí y poner en
funcionamiento los controles técnicos necesarios para apoyar las políticas
dictadas por el Administrador de Datos. Se encarga también de garantizar el
funcionamiento adecuado del sistema y de proporcionar otros servicios de índole
técnica relacionados. Dependiendo de la organización el rol lo pueden compartir
una persona o un equipo.

El DBA debe entender los modelos de datos desarrollados por la Administración

de Datos. El modelo lógico es el mapa con el cual se crearán físicamente las
bases de datos, teniendo en cuenta las características específicas de del DBMS
utilizado en la organización.

Figura 2.1: Administrador de Datos y Administrador de Bases de datos.

2.2.3. Administración de Sistema

Si el tamaño de la organización lo requiere, se debe contar con un Administrador

de Sistema, para controlar la operación del Equipo y Sistema Operativo en donde
está instalado el DBMS.

A los Administradores de Sistema se les encomienda la instalación, soporte y

mantenimiento de los servidores u otros sistemas de cómputo, la planeación de
respuesta a contingencias y otros problemas. Algunas otras responsabilidades
pudieran incluir la programación de scripts o programación de tareas
administrativas, manejo de proyectos relacionados con el sistema, supervisión o
entrenamiento de operadores de cómputo y ser el consultor para los problemas
que se encuentran más allá del conocimiento técnico del personal de soporte.
2.3. Tareas del Administrador de
Bases de Datos
Las principales tareas del DBA son:

- Diseño de Bases de datos

- Monitoreo y Afinamiento

- Asegurar la disponibilidad de las Bases de datos

- Seguridad

- Respaldos

- Integridad de datos

2.3.1. Diseño de Bases de Datos

Los diseñadores entrevistan a los futuros usuarios de la base de datos para

recoger y documentar sus necesidades de información. En forma paralela, es
conveniente definir los requerimientos funcionales que consisten en operaciones
que se aplicarán a la base de datos.

Una vez recogidos todos los requerimientos, el siguiente paso es crear un

esquema conceptual para la base de datos mediante un modelo de datos
conceptual de alto nivel. El esquema conceptual tiene una descripción detallada
de los requerimientos de información que poseen los usuarios, y contiene
descripciones de los tipos de datos, relaciones entre ellos y restricciones. Para el
diseño de esquemas conceptuales es muy utilizado el Modelo E-R (entidad
relación), que describe los datos como entidades, que tiene vínculos (relaciones) y
atributos.

El siguiente paso consiste en implementar el Modelo Conceptual en un Modelo

Físico, de acuerdo a las características de DBMS que se utilizará. Este modelo
puede ser ejecutado directamente en el DBMS para crear los objetos necesarios.

2.3.2. Monitoreo y Afinamiento

El rendimiento de un DBMS es medido de acuerdo al tiempo de respuesta a las

consultas y transacciones de los usuarios. En sistemas muy complejos, la base de
datos es sólo uno de los elementos que determinan la experiencia de los usuarios
en línea, pero generalmente se le atribuyen las causas de los problemas. El
rendimiento es una de las mayores motivaciones de los DBA's para coordinarse
con los especialistas de otras áreas de Sistema (Administradores de Red,
Administradores de Sistemas, Programadores).

Para asegurar el correcto funcionamiento del DBMS, se debe monitorear

permanentemente su operación. Es recomendable contar con herramientas que
cuenten con las siguientes características:

- Indicadores de rendimiento: CPU, Memoria y Disco.

- Identificación de Usuarios Activos y Usuarios bloqueados por contención.

- Capacidad de identificar segmentos de código con problemas.

- Almacenamiento de planes de ejecución.

- Almacenar historias de rendimiento.

- Disponer de Informes de Gestión.

Existen cinco factores que determinan el rendimiento de un DBMS:

1. Carga: se refiere a la demanda a la que es sometido el DBMS. Es una

combinación de transacciones en línea, procesos batch, consultas ocasionales,
extracciones de datos para Datawarehousing y otras tareas que son ejecutadas
contra el motor en un momento determinado. La carga puede fluctuar en las
diferentes horas del día. Las sobrecargas son el factor que más afectan al
rendimiento.

2. Throughput: este término define a la capacidad del Servidor para procesar

datos, en términos de recursos de Hardware. Comprende la velocidad de I/O,
CPU, capacidades de paralelismo del Hardware y la eficiencia del Sistema
Operativo.

3. Recursos: el hardware y las herramientas de software comprenden los recursos

del sistema. Algunos ejemplos son el Kernel de la Base de Datos, Controladores
Caché y Disco.

4. Optimización: se refiere al análisis de los requerimientos de bases de datos

para determinar el costo de una consulta, y proceder así a generar planes de
ejecución adecuados para acceder a los datos. Los principales factores a ser
optimizados son las Consultas SQL, parámetros de configuración de la Base de
datos, y una programación eficiente.

5. Contención: cuando la carga a la que es sometido el DBMS es muy alta y se

encuentran comprometidos todos los recursos, se genera una situación de
Contención. Durante una contención dos transacciones están en conflicto por un
recurso.

De esta manera podemos determinar que el adecuado rendimiento de una Base

de Datos puede lograrse con la optimización de los recursos usados, para
incrementar el throughput y minimizar la contención. Así se permite que la carga
sea procesada de forma eficiente.

Cuando se encuentran problemas de rendimiento en una aplicación que tiene

acceso a una Base de datos, generalmente el DBA es el primer llamado a
resolverlo. Pero el conocimiento necesario entorno a un problema de las
aplicaciones no siempre se encuentra al alcance del DBA, por lo que las tareas de
monitoreo y afinamiento deben ser compartidas entre varios técnicos de Sistemas.
Es decir, el rendimiento de todo el Sistema es responsabilidad del Departamento
de IT.

Con respecto al afinamiento de Bases de Datos, el DBA debe:

- Identificar que las tablas tengan los índices adecuados para responder
adecuadamente a las consultas de los usuarios.

- Configurar adecuadamente la memoria y los cachés de datos y procedimientos.

- Alinear la implementación de las Bases de Datos con la infraestructura de IT

existente.

- Monitorear constantemente las Bases de datos y Aplicaciones.

- Implementar procedimientos de reorganización de Bases de datos.

- Implementar procedimientos de actualización de estadísticas de Bases de datos.

2.3.3. Disponibilidad de las Bases de Datos

La disponibilidad implica que los usuarios autorizados tengan acceso a los datos
cuando lo necesiten para atender a las necesidades del negocio. De manera
incremental los negocios han ido requiriendo que su información esté disponible
todo el tiempo (7x24, o siete días a la semana, 24 horas del día).

El primer requerimiento para que un DBMS esté disponible, es que se esté

ejecutando sin errores. Para asegurar esto, se deben implementar alertas que le
permitan al DBA identificar degradaciones en el rendimiento, antes de que se
produzcan posibles errores.

Otra afectación a la disponibilidad, son las tareas de mantenimiento necesarias

para el correcto funcionamiento del DBMS. Si es necesario que estas tareas se
ejecuten con una afectación al servicio, deben ser coordinadas en horarios en que
no se involucre al desempeño de los usuarios.

2.3.4. Seguridad

La Seguridad implica la capacidad de los usuarios para acceder y cambiar los

datos de acuerdo a las políticas del negocio. Es responsabilidad del DBA que la
información esté disponible solamente para usuarios autorizados.

La administración de la seguridad en las Bases de Datos comprende los permisos

para la ejecución de las siguientes tareas:

- Creación de objetos como bases de datos, tablas, vistas y procedimientos

almacenados.

- Alteración de la estructura de los objetos de bases de datos.

- Acceso a las tablas de sistema.

- Consulta y modificación de los datos en las tablas.

- Creación de funciones y tipos de datos.

- Ejecución de procedimientos almacenados.

- Cambiar el estatus de las Bases de Datos: en línea y fuera de línea.

- Cambiar parámetros de configuración.

- Ejecutar tareas de respaldo, recuperación y otras administrativas.

2.3.5. Respaldos y Recuperación

Que una Base de datos pueda ser recuperada implica que si se da algún error en
los datos, en el DBMS o en el Servidor, el DBA puede traer de vuelta la base de
datos al Estado consistente en que se encontraba antes de que el daño se
causara. Las actividades de recuperación incluyen el hacer respaldos de la base
de datos y almacenar esos respaldos de manera que se minimice el riesgo de
daño o pérdida de los mismos, tales como hacer diversas copias en medios de
almacenamiento removibles y almacenarlos fuera del área en antelación a un
desastre anticipado. La recuperación es una de las tareas más importantes de los
DBA's.

La recuperación de desastres tiene dos componentes:

- Los respaldos: Pueden ser completos o por estampas de tiempo.

- Las pruebas de recuperación: Constantemente se deben ejecutar pruebas de
recuperación, para determinar si los respaldos se están obteniendo de forma
adecuada. Si el DBA intenta implementar un plan de recuperación de bases de
datos sin pruebas de recuperación, no existe la certeza de que los respaldos sean
del todo válidos.

2.3.6. Integridad de datos

La Integridad de datos se refiere al estado de corrección y completitud de los

datos ingresados en una base de datos.

Los DBMS's deben encargarse de mantener la integridad de los datos

almacenados en una base de datos con respecto a las reglas predefinidas o
restricciones. La integridad también puede verificarse inmediatamente antes del
momento de introducir la información a la base de datos.

2.4. Tipos de Administradores de

Bases de Datos
Dependiendo de la experiencia y de la orientación de los DBA's, es común que se
impongan las siguientes especializaciones:

- DBA's especializados en diseño lógico.

- DBA's especializados en diseño físico.

- DBA's orientados al monitoreo de sistemas.

- DBA's especializados en afinamiento de aplicaciones.

Las grandes organizaciones pueden tener diferentes DBA's para realizar estas
tareas, pero en las organizaciones pequeñas un solo DBA debe ejecutar todos los
roles.

En este apartado observaremos los tipos más comunes de DBA's.

2.4.1. Administrador de Bases de Datos de Sistema

El DBA de Sistema se enfoca más en la parte técnica que en las regla de negocio,
principalmente en la Administración de Sistema. Sus tareas se centran en la
instalación y rendimiento del DBMS:

- Instalar nuevas versiones del DBMS y aplicar los parches liberados por el
proveedor.
- Establecer los parámetros de configuración.

- Afinar el hardware y sistema operativo donde se encuentra instalado el DBMS.

- Administrar los sistemas de almacenamiento para el DBMS.

- Administrar tecnologías relacionadas con las Bases de datos.

- Instalar las herramientas de administración y monitoreo de Bases de Datos.

2.4.2. Arquitecto de Datos

Algunas organizaciones crean una función separada para el diseño e

implementación de Bases de Datos: el Arquitecto de Datos. Este tipo de DBA se
dedica solamente a los nuevos diseños y desarrollos, no interviene en la
administración de Bases de Datos de Producción.

Sus tareas incluyen:

- Creación de modelos lógicos.

- Trasladar los modelos lógicos a modelos físicos.

- Implementar Bases de datos eficientes, que incluyan los objetos e índices

adecuados.

- Analizar el acceso a datos y los requerimientos de modificación, para generar

consultas SQL eficientes.

- Crear estrategias de respaldo y recuperación para las nuevas Bases de datos.

2.4.3. Administrador de Bases de Datos de Aplicación

El DBA de aplicación se centra en el diseño de Bases de Datos y en el soporte y

administración de aplicaciones específicas.

El DBA de Aplicación se enfoca en el diseño de bases de datos y en el soporte de

bases de datos para aplicaciones. Es un experto en la escritura y seguimiento
(debugging) de consultas SQL complejas, así como en comprender las mejores
prácticas para incorporar los requerimientos funcionales de las aplicaciones en
una base de datos. El DBA de Aplicación debe también conocer la configuración
del motor de bases de datos y otros roles del DBA de sistema.

El trabajo del DBA de Aplicación es determinante en el rendimiento de las

aplicaciones, pues conoce el detalle de las consultas SQL y su correcta aplicación
en la base de datos. El DBA de Aplicación analiza las consultas y realiza las
sugerencias apropiadas de cambios, tanto en el código como en la configuración
del motor de bases de datos.

Las habilidades de este DBA son:

- Programador senior con énfasis en la capa de base de datos (funciones de

usuario, procedimientos almacenados, disparadores).

- Conocimiento de las diferentes tecnologías de conexión hacia las bases de

datos.

- Conocimiento intermedio de Administración de bases de datos.

- Conocimiento de las opciones avanzadas de los lenguajes extendidos de SQL.

- Conocimiento de seguridades en las bases de datos.

Sus tareas son:

- Participar como consultor durante el proceso de desarrollo de nuevas

aplicaciones, para el diseño de estructuras y objetos de bases de datos:

- Durante el proceso de desarrollo, participar en las pruebas funcionales y de

carga para identificar instrucciones SQL con problemas de rendimiento.

- Durante el proceso de desarrollo, dar soporte a los programadores para optimizar

procedimientos con problemas de rendimiento.

- Definir y actualizar el estándar de conexión hacia las bases de datos.

- Custodiar los modelos de datos.

- Revisión y análisis de los procedimientos almacenados con problemas de

rendimiento.

2.5. El Administrador de Bases de

Datos en la Organización
2.5.1. ¿Cuántos Administradores de Bases de Datos tener?

Es importante para una organización determinar el número de DBA's que debe

tener.

Esta decisión depende de varios factores:

- Número de Bases de datos.

- Tamaño de las Bases de datos.

- Número de usuarios.

- Número de aplicaciones.

- Niveles de servicios.

- Requerimientos de disponibilidad.

- Impacto del downtime.

- Requerimientos de rendimiento de las aplicaciones.

- Tipo de aplicaciones.

- Frecuencia de los cambios en las Bases de datos.

- Experiencia del staff de DBA's.

- Experiencia del staff de programadores.

- Experiencia del usuario final en las aplicaciones.

- Diversidad de DBMS's en la organización

2.5.2. El administrador de Bases de Datos dentro de la estructura

organizacional

Las organizaciones difieren en cuanto a la ubicación del DBA dentro de la

estructura organizacional del Departamento de IT. Esta ubicación depende del tipo
de organización.

Cuando una organización entiende la importancia de la información, ubica al staff

de Administración de Información en una posición estelar. Es recomendable que
este Grupo de Administración de Recursos de Información reporte directamente al
Gerente de IT:
 Figura 2.2: El Administrador de Bases de datos en la Estructura Organizacional.

Capítulo 3.- Definición del entorno de

Bases de Datos

OBJETIVOS

- Analizar los factores preponderantes para el escogimiento de un DBMS en particular,

dependiendo de las características y recursos técnicos de la organización.

- Identificar los pasos necesarios para el proceso de instalación de un DBMS.

- Analizar las ventajas de mantener las versiones actualizadas de un DBMS.

3.1. Introducción
La instalación y configuración del Entorno de Bases de Datos es una de las tareas
más significativas del DBA, pues se requiere contar con el conocimiento,
experiencia y cuidado necesarios.

Desafortunadamente, el escogimiento de un determinado Motor de Bases de

Datos suele ser realizado por los ejecutivos de negocios de las empresas, que no
cuentan con las experiencia de Tecnologías de la Información, y asumen que una
vez instalada la Base de Datos, todo funcionará adecuadamente. En este capítulo
se revisarán los principios para una selección adecuada.

3.2. Definición de la Estrategia

En la actualidad, el proceso de escoger un Motor de Bases de Datos (DBMS, por
sus siglas en inglés) adecuado ya no es tan complicado como antes, pues los
proveedores cuentan con opciones conocidas, de acuerdo a los requerimientos.

Es común que empresas medianas o grandes cuenten con más de dos DBMS's,
para soportar sus diferentes aplicaciones o infraestructura:

- Si la empresa cuenta con Mainframes, podría usar DB2 o Informix.

- En los Servidores Unix, podría utilizar Oracle, Sybase, Informix.

- Si se cuenta con servicios sobre Windows, es muy probable que el DBMS sea
Microsoft SQL Server, aunque otros proveedores también promocionan sus
motores para ejecutarse en esta plataforma.

- Si adicionalmente se gestiona información en las estaciones de trabajo, se

pueden utilizar productos como Microsoft Acces o Excel, que no son DBMS's
precisamente.

Ante este panorama, la pregunta que cabe es: ¿Quién decide el DBMS a utilizar y
en qué momento?

A veces la decisión de adquirir un nuevo DBMS es dirigida por un requerimiento

del negocio o por una nueva aplicación. Esto sería sencillo si la empresa está
adquiriendo su primer DBMS, pero este no es un caso común. A pesar de que ya
exista un DBMS en la organización, se suele adquirir otro para una nueva
aplicación, sin verificar que ésta funcione adecuadamente en el DBMS existente.

Una vez que el Servidor de Bases de Datos es instalado, un proceso de remoción

siempre es complicado, pues es necesario realizar cambios en el código de las
aplicaciones, para adaptarse a un nuevo DBMS. Adicionalmente, cuando un nuevo
DBMS es instalado, generalmente no son migradas las aplicaciones antiguas, pero
se pide que el anterior DBMS permanezca, para soportar consultas. Esto complica
las tareas de administración.

El DBA debe emitir un informe técnico para asesorar la adquisición de un

determinado DBMS, y este informe debe ser considerado por los directivos para
tomar la decisión final. Sólo de esta manera se asegura que la decisión sea
determinada por motivos técnicos, principalmente.

3.2.1. Escogiendo un DBMS

Todos los proveedores líderes de DBMS's por lo general ofrecen las mismas
características en sus productos. Si un proveedor en particular lanza una
característica nueva, los otros no tardan en incorporarla, probablemente en menos
de dos años.
Algunos proveedores principales de DBMS's son:

Proveedor Producto Plataformas compatibles

Apple Mac OS X Server

HP HP-UX

HP Tru64 UNIX: Alpha

HP OpenVMS
Oracle Oracle Database
IBM AIX5L

IBM z/OS: zSeries

Linux

Microsoft Windows

Sun Solaris
Apple Mac OS X Server

HP HP-UX

HP Tru64 UNIX: Alpha

HP OpenVMS

IBM AIX5L
Informix
IBM
IBM z/OS: zSeries
DB2
Linux

Microsoft Windows

Sun Solaris

IRIX

IBM OS/2
Microsoft SQL Server Windows

Adaptive Server Enterprise

Sybase Asianux
Adaptive Server Anywhere
 HP HP-UX

HP Tru64 UNIX: Alpha

IBM AIX5L

Linux

Microsoft Windows

Sun Solaris
HP-UX

IBM AIX5L

IBM z/OS: zSeries

Teradata Teradata Database
Linux

Microsoft Windows

Sun Solaris
Tabla 3.1. Principales Proveedores de DBMS's.

Adicionalmente, siguiendo la tendencia del Código Abierto, podemos nombrar a

las principales DBMS's de uso libre:

- MySQL

- PostgreSQL

- Ingres

- Firebird

El Grupo de Administración de Bases de Datos debe contar con una política de

adquisición de DBMS's, considerando la infraestructura de la organización. Esta
política debe procurar mantener el número DBMS's diferentes en el mínimo
posible: mientras mayor sea este número, el esfuerzo de administración y los
conocimientos necesarios serán mayores.

Las consideraciones necesarias para la adquisición de un DBMS son:

- Sistema Operativo: ¿El DBMS's es compatible con el Sistema Operativo que

posee la organización? ¿El proveedor planea dar mantenimiento a las siguientes
versiones que se lanzarán en el futuro?
- Tipo de Organización: se debe tomar en cuenta la cultura organizacional. Las
empresas con una tendencia conservadora tenderán a escoger productos de
probada funcionalidad, acordes con las tendencias de la industria., frente a nuevos
productos con arquitecturas renovadoras. Por lo general, las empresas con
operaciones de misión cr161tica tienden a escoger sistemas basados en Unix.

- Benchmarks: ¿Dispone el proveedor de una prueba de rendimiento frente a los

productos competidores? ¿Las condiciones de las pruebas de rendimiento se
asemejan al entorno de la organización?

- Escalabilidad: ¿El DBMS soporta el número de usuarios y el tamaño de las

bases de la organización?

- Disponibilidad de herramientas: es necesario verificar si el proveedor incluye

herramientas adicionales como Consolas Administrativas, Medidores de
Rendimiento, Consola para consultas SQL, Respaldo y Recuperación, entre otras.

- Técnicos: es necesario verificar si existe, en la organización o en el mercado

laboral, el personal técnico con el conocimiento necesario para dar soporte en el
DBMS a implementar. Se debe tener en cuenta si el nivel de remuneración para
este personal es compatible con el nivel adquisitivo de la organización.

- Costos: se deben tener en cuenta el valor de las licencias, actualizaciones,

soporte técnico, administración.

- Nuevas versiones: se debe verificar la periodicidad en que el proveedor libera

nuevas versiones, tanto para generar nuevas características, como para corregir
errores.

- Referencia de otros usuarios: es necesario buscar opiniones imparciales de otros

usuarios de la herramienta a implementar. Se deben pedir opiniones sobre las
bondades del producto, así como los problemas presentados durante su
operación.

3.2.2. Arquitecturas DBMS

Una de las principales tareas del DBA debe ser escoger el DBMS correcto a
utilizar, cada vez que una aplicación es desarrollada. Una elección equivocada
puede causar bajo rendimiento, fallas del sistema y aplicaciones inestables.

En los actuales momentos, la infraestructura de Tecnologías de la Información

tiende a ser distribuida y heterogénea, incluyendo diferentes plataformas y
sistemas operativos. El nivel de arquitectura del DBMS se debe escoger de
acuerdo a la naturaleza de la organización y el tipo de procesamiento a
implementar. Los niveles de arquitectura disponibles son:
- Enterprise DBMS: Un DBMS de nivel Empresarial está diseñado para ofrecer
Escalabilidad y Alto rendimiento. Debe ser capaz de soportar Bases de Datos de
gran tamaño, alto número de usuarios concurrentes y múltiples tipos de
aplicaciones ejecutándose simultáneamente. Este tipo de servidor de bases de
datos se debe ejecutar sobre Hardware de Gran escala, para poder ofrecer
características avanzadas como Soporte para multiprocesamiento, Paralelismo y
Clustering.

- Workgroup DBMS: Para empresas medianas y pequeñas, los proveedores de

DBMS's ofrecen soluciones de nivel Departamental, en las cuales se suprimen las
características avanzadas, manteniendo el soporte adecuado para el correcto
desempeño de las aplicaciones, para un número limitado de usuarios.

- Personal DBMS: Las bases de datos personales están diseñadas para ser
utilizadas por un usuario en una estación de trabajo.

- Mobile DBMS: Las bases de datos móviles son una versión especializada de un
DBMS Departamental o Empresarial. Están diseñadas para usuarios remotos que
generalmente no están conectados a una red local, y pueden ser utilizadas en
dispositivos móviles. Adicionalmente, ofrecen herramientas de sincronización de
información para actualizar los cambios contra una Base de datos Centralizada de
la organización.

Un DBMS diseñado para un tipo de procesamiento no puede ser utilizado para un

nivel distinto. Se debe asegurar la comprensión de las diferentes arquitecturas
para realizar una elección adecuada. Si la organización requiere soluciones de
acuerdo a los diferentes tipos de arquitecturas, es preferible escoger un proveedor
que disponga de todos los tipos de DBMS.

3.2.3. Alta Disponibilidad

Un sistema de Clustering permite la utilización de varias máquinas independientes

trabajando como si fueran una sola, dentro de un esquema de Alta disponibilidad.
Los DBMS's modernos ya incluyen características de soporte para Clustering.

Existen 2 arquitecturas predominantes para la implementación de Alta

Disponibilidad:

1. Shared Nothing: consiste en una arquitectura distribuida en la cual cada nodo

es independiente y autosuficiente dentro del sistema. Un sistema Shared Nothing
completo puede crecer casi sin límite al agregar más máquinas, ya que no hay un
único cuello de botella dentro del sistema. Los datos pueden ser repartidos entre
varios nodos, o se puede requerir que cada nodo mantenga su propia copia de los
datos del sistema, utilizando una clase de protocolo de coordinación.
 Figura 3.1: Modelo de Cluster Shared Nothing.

2. Shared Disk: este tipo de cluster es usado para sistemas de alta disponibilidad
orientados a procesar un gran volumen de información. Estos sistemas consisten
en un dispositivo de almacenamiento compartido y nodos del cluster que se
distribuyen el acceso a los datos compartidos, desde diversas fuentes.
 Figura 3.2: Modelo de Cluster Shared Disk.

Cuando nos encontramos frente a dispositivos de almacenamiento de gran

capacidad y con tareas dirigidas a su procesamiento, la Arquitectura Shared Disk
resulta ser más efectiva, porque no es necesario almacenar muchas copias de los
datos. De igual manera, si un nodo falla, las tareas y los datos a procesar quedan
inmediatamente disponibles para los demás nodos del cluster.

Si las tareas permiten dividir de forma lógica los datos de manera que los pedidos
de ciertos subgrupos puedan ser procesados usando parte de los datos, el
sistema Shared Nothing puede ser la opción más apropiada.

Los clusters con tolerancia a fallos de 2 nodos son los sistemas más populares
comercialmente, pudiendo implementarse modelos Activo-Activo (los 2 nodos
pueden ser utilizados) y Activo-Pasivo (un nodo trabaja y el otro solamente espera,
en caso de falla).

3.3. Instalación del Servidor de Bases

de Datos
Una vez que se ha escogido el DBMS, se debe planificar su instalación. Para
lograr una instalación exitosa se deben cumplir los pre-requisitos de instalación y
preparar el entorno.
3.3.1. Pre-requisitos de Instalación

Como toda herramienta de software, los DBMS's vienen con manuales de

instalación que indican los requerimientos para que su funcionamiento sea óptimo:

- Asegurarse que la versión del sistema operativo sea la apropiada.

- Verificación que los recursos de hardware (modelo de servidor, capacidad de

disco y memoria).

- Compatibilidad de otro software relacionado.

Una vez que los requisitos sean cubiertos, se deben seguir las indicaciones de la
Guía para proceder a la instalación.

3.3.2. Requerimientos de Hardware

Cada DBMS tiene requerimientos específicos con respecto al CPU, especificando

versiones y número de procesadores requeridos para la operación.
Adicionalmente, algunos proveedores especifican en una "Guía de Compatibilidad"
los modelos de servidores soportados y no soportados.

Los DBMS's están diseñados para explotar al máximo las características de el

hardware que declaran como compatible. La organización debe asegurarse de
escoger un DBMS acorde con los servidores que posee o que planea adquirir.

3.3.3. Requerimientos de Almacenamiento

Los DBMS's requieren recursos de almacenamiento para funcionar, obviamente

para guardar la información de las bases de datos e índices, pero adicionalmente
para las siguientes estructuras:

- Archivos binarios y ejecutables del DBMS.

- Bases de datos y Tablas de sistema que son usadas por el DBMS para la
administración de las Bases de Datos de Usuario.

- Archivos de bitácora (logs).

- Scripts de inicio y de control.

- Archivos de procesamiento de errores (dump).

3.3.4. Requerimientos de Memoria

Un DBMS, como cualquier software, requiere de memoria para ejecutar su

funcionalidad básica y atender los procesos que se generan durante la operación.

Los DBMS generalmente utilizan los recursos de memoria asignados en 2

estructuras:

1. Caché de datos: Es la estructura en donde se almacenan los datos que son

requeridos por las aplicaciones. Mientras mayor sea la cantidad de memoria
asignada, se minimiza la necesidad de realizar operaciones de entrada/salida (I/O)
contra los discos, para obtener información.

La lectura desde disco siempre es más lenta que la lectura desde la memoria, por
lo que la configuración apropiada del caché de datos es un factor crítico en el
rendimiento de las aplicaciones.

2. Caché de programas: Los DBMS requieren de un segmento de memoria para

guardar las compilaciones de los procedimientos almacenados (Stored
Procedures, SP's) que ejecutan los usuarios. Al mantener en memoria estas
compilaciones, se reducen las operaciones de I/O.

Los recursos de memoria son requeridos por los DBMS's para soportar otras
características como el manejo de los bloqueos, control de los requerimientos de
datos, ordenamiento de la información y procesamiento de las consultas.

Debe asegurarse la correcta asignación de memoria al DBMS, para optimizar el

procesamiento y minimizar los problemas de rendimiento.

3.3.5. Configuración

A través de los parámetros de Configuración, el DBA define la forma de operación

del DBMS. La configuración tiene una relación directa con los recursos
disponibles. Cada DBMS permite que los parámetros sean modificados de
diferentes formas, pero generalmente durante el proceso de instalación se colocan
valores por defecto.

Una vez que el DBMS está operativo, los parámetros de configuración pueden ser
modificados, ya sea a través de comandos, o editando los archivos de
configuración. Existen adicionalmente consolas de administración que permiten
realizar los cambios a través de un entorno gráfico e intuitivo. Sea cual fuere la
forma de cambio de los parámetros de configuración, el proceso debe realizarse
con precaución y exactitud, pues se afecta directamente a la forma de operación
del DBMS.

Los principales parámetros de configuración son:

- Configuración de la memoria (Caché de datos y programas).

- Número de procesadores a utilizar.

- Número de objetos abiertos (bases de datos, tablas, índices).

- Habilitación de características del DBMS.

3.4. Actualizaciones del Servidor de

Bases de Datos
Los proveedores de DBMS's liberan actualizaciones en un ciclo que puede ir
desde 12 a 18 meses. Las actualizaciones incluyen mejoras en el producto,
nuevas características y el arreglo de los errores reportados por los usuarios.

El DBA debe procurar mantener actualizados los servidores de la organización,

considerando minimizar los riesgos y no interrumpir los procesos de negocio.

3.4.1. Tipos de actualizaciones

Las actualizaciones pueden ser de 2 tipos:

1. Versión: un cambio de versión debe realizarse con el cuidado que requeriría

una instalación nueva. Una nueva versión suele incluir cambios radicales en el
funcionamiento interno del DBMS, así como nuevas características.

2. Release: un release representa una nueva compilación de los binarios de una

versión de DBMS. En un release se corrigen los errores reportados por los
usuarios, y es posible que se incluyan nuevas características menores.

3.4.2. Beneficios de la actualización del DBMS

Una actualización ofrece tanto riesgos como beneficios. El procedimiento de

actualización debe minimizar los riesgos, con el fin de que los beneficios sean
aprovechados al máximo.

Los principales beneficios de una actualización de DBMS son:

- Los Programadores pueden aprovechar las características nuevas que se

incluyen en la actualización.

- Las actualizaciones implementan mejoras en el funcionamiento del DBMS, que

se reflejan en un mejor desempeño de las aplicaciones.
- Los proveedores alientan la instalación de actualizaciones para poder ofrecer un
mejor soporte a problemas.

3.4.3. Consideraciones para la actualización

A pesar de que una estrategia de actualización adecuada pueda maximizar los

beneficios, deben contemplarse las siguientes consideraciones:

- Las actualizaciones requieren suspender la atención del DBMS. De acuerdo a la

naturaleza de la organización, debe planearse la actualización en un horario de
mantenimiento adecuado, para minimizar el impacto.

- Antes de implementar la instalación en Producción, ésta debe ser realizada en

los ambientes de Desarrollo, para que los programadores puedan realizar pruebas
de certificación de las aplicaciones.

- Las nuevas versiones por lo general requieren mayores recursos (especialmente

memoria) para funcionar adecuadamente. De ser necesario, se deben contemplar
cambios en el hardware, para aprovechar las nuevas características del DBMS.

- Al terminar el proceso de actualización, debe realizarse un chequeo de

consistencia a las Bases de datos, para asegurar que no existen errores físicos en
los objetos.

3.5. Definición de estándares

Los estándares son definiciones de las mejores prácticas para asegurar la
consistencia y efectividad de un entorno de Bases de Datos. El DBA debe definir
estos estándares como parte de los procedimientos a seguir en el Departamento
de IT.

3.5.1. Convenciones de nombres

El primer estándar a establecer debe ser la guía para nombrar los objetos de las
bases de datos. Sin un estándar es dificultoso identificar correctamente los
nombres de los objetos, tanto para tareas de administración como de
programación.

Algunas consideraciones para la definición de este estándar:

- El nombre de un objetos debe ser lo más descriptivo posible. Se debe considerar

las limitaciones de longitud que tiene cada DBMS.

- Para disminuir el uso de caracteres, pueden utilizarse convenciones que deben

ser descritas en el diccionario de datos.
- Los nombres de las entidades (tablas) deben escribirse en singular.

- Debe definirse la utilización de mayúsculas o minúsculas solamente. En lo

posible no es recomendable mezclar caracteres, para evitar errores en
aplicaciones que tengan sensibilidad entre mayúsculas y minúsculas.

- Las palabras pueden separarse con un guión bajo: detalle_factura.

3.5.2. Estándares de Administración de Bases de Datos

El DBA debe documentar los procedimientos de administración, para definir el

alcance de su trabajo. Los estándares de administración de datos incluyen:

- Declaración de las políticas de información de la organización.

- Guías para establecer la propiedad de los datos.

- Reglas de creación de objetos de Base de datos.

- Políticas de administración de Metadata.

- Guías para el desarrollo de modelos conceptuales, lógicos y físicos.

- Políticas de permisos de acceso a Bases de datos.

- Políticas de Respaldo y Recuperación de Bases de datos.

- Política de Pases a Producción.

- Política de monitoreo y administración.

3.5.3. Estándares de Administración de Sistemas

Los estándares de administración de Sistemas incluyen:

- Instalación del DBMS y procedimientos de pruebas.

- Políticas de actualizaciones.

- Consideraciones de interfaces.

- Procedimientos de uso de almacenamiento.

3.5.4. Estándares de Desarrollo de Aplicaciones de Bases de Datos

Se deben documentar las consideraciones para el desarrollo de aplicaciones que

accedan a las Bases de datos, que incluyen:

- Descripción de los métodos de acceso de las Aplicaciones a las Bases de datos.

- Estándares de codificación SQL.

- Recomendaciones para mejorar el rendimiento de las consultas SQL.

- Guía de interpretación de los códigos de errores del DBMS.

3.5.5. Estándares de Seguridad de Bases de Datos

Una definición de políticas de acceso a las Bases de datos debe incluir:

- Expiración de clave de usuario.

- Definición de clave compleja.

- Definición de los dueños de los objetos.

- Privilegios de acceso del usuario sobre los objetos.

- Privilegios del usuario para realizar tareas administrativas.

Capítulo 4.- Modelamiento de Datos

OBJETIVOS

- Introducir el concepto de entidad como una estructura básica del modelo relacional.

- Identificar los componentes de un modelo de datos.

- Analizar las fases del diseño de Modelos de Bases de datos.

- Analizar las reglas de Normalización e identificar cómo se deben aplicar.

4.1. Introducción
A fines de los años Sesenta, Edgar Frank Codd introdujo la Teoría relacional para
las bases de datos. Este hecho determinó un paso trascendental en la
investigación de los DBMS's, pues se suministró un sólido fundamento teórico
para su desarrollo, dentro de este enfoque relacional. La teoría de Codd propone
un modelo de datos basado en la teoría de las relaciones, en donde los datos se
estructuran lógicamente en forma de entidades (tablas), siendo un principio
fundamental del modelo el mantenimiento de la independencia de esta estructura
lógica con relación al modo de almacenamiento y a otras características de tipo
físico.

La teoría propuesta por Edgar Frank Codd presentó un nuevo modelo de datos
que perseguía los siguientes objetivos:

- Independencia física: la forma en la que se almacenan los datos no influye en

su estructura lógica. Debido a esto, los usuarios que acceden a esos datos no
tienen que modificar sus programas cuando se producen cambios en el
almacenamiento físico de la información.

- Independencia lógica: el añadir, eliminar o modificar objetos de la base de

datos no tiene influencia en los programas y usuarios que acceden a subconjuntos
parciales de los mismos.

- Flexibilidad: para lograr presentar a cada usuario los datos de la forma en que
éste requiera.

- Uniformidad: las estructuras lógicas de la información presentan un formato

uniforme, lo que facilita la creación y manipulación de la base de datos por parte
de sus usuarios.

- Sencillez: las características nombradas anteriormente, así como unos

lenguajes de programación muy sencillos, producen como resultado que el modelo
de datos relacional sea sencillo de comprender y de utilizar por parte del usuario
final.

Para conseguir los objetivos indicados, Edgar Frank Codd introduce el concepto
de entidad (tabla) como una estructura básica del modelo relacional. Toda la
información de la Base de Datos se representa en forma de entidades cuyo
contenido varía con el tiempo.

Con respecto a la parte dinámica del modelo relacional, se propusieron un

conjunto de operadores que se aplican a las relaciones entre entidades. Tanto las
entidades como los operadores conforman el Álgebra Relacional.
4.2. Componentes de un Modelo de
Datos
Un modelo de datos es construido utilizando diferentes componentes que
representan abstracciones del mundo real. Un modelo de datos consiste de
entidades y relaciones.

4.2.1. Entidades

La entidad es el elemento básico en el modelo relacional y se puede representar

como una tabla:

Nombre de la tabla

Figura 4.1: Entidad.

En una entidad se puede distinguir un conjunto de columnas, llamadas atributos,

que representan propiedades de la entidad y que están identificadas por un
nombre. También se distinguen un conjunto de filas llamadas tuplas o registros,
que son las ocurrencias de la relación, es decir, la información que almacena la
tabla.

Existen también los dominios de donde los atributos toman sus valores. Estos
dominios se denominan "Tipos de Datos".

Al número de filas de una entidad se lo denomina cardinalidad y el número de

columnas es llamado el grado de la entidad.

- Ejemplo: Cliente

Figura 4.2: Ejemplo de Entidad Cliente.

Una entidad (tabla) tiene las siguientes características:

- No pueden existir filas duplicadas, es decir, todos los registros tienen que ser
distintos.

- El orden de almacenamiento de los registros es irrelevante.

- La tabla es plana, es decir, en la relación de una fila y una columna sólo puede
haber un valor (no se admiten atributos con múltiples valores).

4.2.2. Dominio y Atributos

Un dominio es un conjunto delimitado de valores homogéneos y atómicos que se

definen con un nombre. Se dice que son homogéneos porque todos son del
mismo tipo y atómicos porque no pueden ser divididos.

Un dominio siempre tiene un nombre por el cual es identificado y un tipo de datos.

En el ejemplo, el tipo de datos del dominio País es un conjunto de 10 caracteres
de longitud. El dominio País tiene valores: Ecuador, Argentina, Colombia.

Ejemplos de dominios:

- Colores: Conjunto de los colores {rojo, verde, azul}.

- Números de Identificación: Conjunto de números de identificación válidos,

formados por 12 dígitos.

- Edad: Edades posibles de personas.

Un atributo es el rol que tiene un dominio específico en una entidad. Es muy

común dar el mismo nombre tanto al atributo como al dominio. En el caso de que
los atributos de una misma entidad definidos sobre el mismo dominio sean varios,
se debe otorgarles nombres distintos, pues una tabla no puede tener dos atributos
con el mismo nombre.

Por ejemplo los atributos edad_física y edad_mental pueden estar definidos sobre
el mismo dominio edad; o los atributos valor_compra y valor_venta pueden estar
definidos sobre el mismo dominio de enteros de longitud 10.

Un dominio compuesto se define como una combinación de dominios simples que

tiene un nombre y al que se puede aplicar determinadas restricciones de
integridad. Por ejemplo, una entidad Usuario podría necesitar manejar, además de
los tres dominios Día, Mes y Año, un dominio compuesto llamado Fecha, que sería
la combinación de los tres primeros atributos, y al que podríamos aplicar las
adecuadas restricciones de integridad a fin de que no se presenten valores no
válidos para la fecha final. Lo mismo ocurre con el nombre y los apellidos, que
según sus aplicaciones puede ser conveniente tratarlos en conjunto o por
separado. De la misma forma, es posible definir un atributo compuesto Fecha que
tome sus valores del dominio compuesto de igual nombre.

4.2.3. Claves

La clave candidata de una entidad es un conjunto no vacío de atributos que

identifican de forma única y mínima a cada registro. Por la propia definición de
entidad, siempre existe al menos una clave candidata para cada tabla, ya que al
ser la relación un conjunto, no existen registros repetidos y por tanto, el conjunto
de todos los atributos identificará de forma única a los registros. Una entidad
puede tener más de una clave candidata, entre las cuales se debe distinguir:

- Clave primaria: es aquella clave candidata que el usuario escogerá para

identificar a los registros de una entidad.

- Clave alternativa: son aquellas claves candidatas que no han sido finalmente
elegidas.

Una buena clave primaria debe tener las siguientes características:

- Garantiza la unicidad de cada registro dentro de la entidad.

- Los atributos que componen la clave primaria no pueden tener valores nulos
(null).

- Los valores de las claves primarias no deberían ser cambiados, para no alterar la
unicidad de los registros.

Se necesita siempre tener siempre el control de los valores de las claves

primarias. Cuando los valores son asignados desde fuera de la aplicación, se
pierde control, causando problemas de datos potenciales. Por ejemplo, cuando
esto sucede, no es posible asegurar la unicidad de la información. Bajo este
contexto, el número de identificación es una mala elección para clave primaria
para una entidad Cliente. Es mejor asignar un número dentro de la organización
para cada cliente, pues con esto se asegura que la clave no va a cambiar.

Se llama clave foránea de una entidad a un conjunto no vacío de atributos cuyos

valores coinciden con los de la clave primaria de otra entidad. La clave foránea y
la correspondiente clave primaria tienen que estar definidas sobre los mismos
dominios.

4.2.4. Relaciones

Las relaciones definen la forma cómo diferentes entidades interactúan entre sí. El
nombre de una relación describe el papel de una entidad en la asociación con la
otra entidad. Las claves definen la relación: la clave primaria en la entidad
principal, y la clave foránea en la entidad dependiente.

Se denomina cardinalidad de la relación al número de ocurrencias que pueden

existir entre un par de tablas. Es común utilizar también el término grado para
referirse a la cardinalidad.

4.3. Fases del Diseño de Modelos de

Bases de Datos
Las fases del diseño de Modelos de Bases de datos son:

1. Recolección y análisis de requerimientos.

2. Diseño conceptual.

3. Diseño lógico.

4. Diseño físico.

4.3.1. Recolección y análisis de requerimientos

Los analistas entrevistan a los futuros usuarios de la base de datos para recoger y
documentar sus requerimientos de información. En forma paralela, es conveniente
definir los requerimientos funcionales que consisten en transacciones que se
aplicarán a la base de datos, e incluyen la obtención de datos y su actualización.

4.3.2. Diseño conceptual

Una vez que se ha recogido todos los requerimientos, el siguiente paso es crear
un esquema para la base de datos mediante un modelo de datos conceptual.

El esquema conceptual presenta una descripción detallada de los requerimientos

de información de los usuarios, y contiene las definiciones de los tipos de datos,
relaciones entre ellos y restricciones.

4.3.3. Diseño lógico de la base de datos (transformación de modelo de

datos)

El siguiente paso en el proceso de diseñar una base de datos consiste en

implementarla de hecho con un DBMS comercial, transformando el modelo
conceptual al modelo de datos empleado por el DBMS propiamente (jerárquico,
red o relacional).
4.3.4. Diseño físico de la Base de Datos

En este paso son especificadas las estructuras de almacenamiento internas y la

organización de los archivos de la base de datos, considerando los tipos de datos
específicos que tiene el DBMS a utilizar.

4.4. Normalización
El proceso de Normalización de bases de datos consiste en aplicar una serie de
reglas a las entidades obtenidas tras el paso del modelo entidad-relación al
modelo relacional.

Las bases de datos relacionales se normalizan para:

- Evitar la redundancia de los datos.

- Evitar problemas de actualización de los datos en las tablas.

- Proteger la integridad de los datos.

En el proceso de normalización, según la propuesta original de Edgar Frank Codd,

se somete un modelo de datos a una serie de pruebas para certificar si pertenece
o no a las formas normales. En un principio, Edgar Frank Codd propuso tres
formas normales (1FN, 2FN, 3FN).

Posteriormente Edgar Codd y Boyce propusieron una definición más estricta de la

Tercera forma normal, a la que se conoce como forma normal de Boyce Codd
(FNBC). Todas estas formas normales se basan en las dependencias funcionales
entre los atributos de una tabla.

Luego se propusieron la cuarta forma normal (4FN) y la quinta (5FN), con

fundamento en los conceptos de dependencias con valores múltiples y
dependencias de reunión, respectivamente.

Las formas normales, por sí solas, no garantizan un buen diseño de Base de

Datos. En general, no basta con comprobar separadamente que cada modelo de
entidades esté en una forma normal determinada. En su lugar, el proceso de
normalización tiene que confirmar la existencia de propiedades adicionales que los
esquemas relacionales en conjunto deben poseer. Estas propiedades son:

- Reunión sin pérdida, que garantiza que no se presente el problema de los

registros erróneos.
- Conservación de las dependencias, que garantiza que todas las dependencias
funcionales sean representadas en alguna de las relaciones individuales que son
resultantes.

4.4.1. Primera forma Normal

Una entidad está en primera forma normal (1FN) si los valores para cada uno de
sus atributos son atómicos.

Esto quiere decir simplemente que cada atributo sólo puede pertenecer a un
dominio (que no puede ser dividido) y que tiene un valor único para cada registro.

La primera forma normal fue creada para no permitir los atributos con múltiples
valores, compuestos y sus combinaciones.

Cuando una entidad no está en primera forma normal, se divide en otras

entidades, repartiendo sus atributos entre las resultantes. Normalmente la idea es
eliminar el atributo que viola la 1FN de la entidad original y colocarlo en una
entidad aparte junto con la clave primaría de la entidad inicial.

- Ejemplo

Se diseña una entidad para almacenar los nombres y teléfonos de los clientes:

- Cliente

Figura 4.3: Ejemplo de Entidad Cliente que no cumple con la 1FN.

Como se observa, el atributo Teléfono posee múltiples valores, por lo que no

cumple la 1FN. Para cumplir con esta forma normal, se debe dividir la entidad de
la siguiente manera:

- Cliente
 Figura 4.4: Ejemplo de Entidad Cliente que cumple con la 1FN.

- Teléfono de Cliente

Figura 4.5: Ejemplo de Entidad Teléfono de Cliente que cumple con la 1FN.

4.4.2. Segunda forma Normal

Una entidad está en segunda a normal si está en la 1FN y todos los atributos que
no son clave, dependen de la clave completa y no sólo de una parte de ésta.

Este propósito solamente se aplica a entidades que tienen claves compuestas, es

decir, que las claves están formadas por más de un atributo. Si un esquema de
entidad no está en 2FN, se lo puede normalizar a varias entidades en 2FN en las
que los atributos que dependen de una parte de la clave formen una nueva
entidad que tenga esa parte de la clave como clave primaria.

- Ejemplo

Se diseña una entidad para determinar la tarea de los empleados y su lugar de

trabajo:

- Tarea del Empleado

 Figura 4.6: Ejemplo de Entidad Tarea del Empleado que no cumple con la 2FN.

La clave candidata de la entidad es {Empleado, Tarea}. El atributo Lugar de

Trabajo solamente es dependiente de una parte de la clave, en este caso, del
atributo Empleado. Adicionalmente, el valor de este atributo es redundante en la
entidad, lo cual causa un problema potencial de actualización.

Una alternativa de diseño para cumplir con la 2FN es:

Figura 4.7: Ejemplo de Entidad Empleado que cumple con la 2FN.

- Tarea del Empleado

Figura 4.8: Ejemplo de Entidad Tarea del Empleado que cumple con la 2FN.

4.4.3. Tercera forma Normal

Una entidad está en tercera forma normal si está en 2FN y todos sus atributos
dependen funcionalmente sólo de la clave, y no de ningún otro atributo.

Esto significa que en una entidad en 3FN, para toda DF: X → Y, X es una clave.
Podemos observar que si una entidad está en tercera forma normal, está también
en segunda forma normal, sin embargo lo inverso no siempre es cierto.

- Ejemplo

Se diseña una entidad para registrar los ganadores de diferentes torneos de Tenis:

- Ganadores de Torneos

Figura 4.9: Ejemplo de Entidad Ganadores de Torneos que no cumple con la 3FN.

Se puede observar que la clave candidata para esta entidad es {Torneo, Año}. Se
viola la 3FN porque el atributo Fecha de Nacimiento tiene una dependencia
transitiva hacia la clave candidata, de forma indirecta a través de atributo Ganador.
Esto hace vulnerable a la entidad ante posibles inconsistencias lógicas, pues el
valor del atributo Fecha de Nacimiento podría ser diferente en algunos registros.

Para cumplir con la 3FN podríamos dividir la entidad en 2, de la siguiente forma:

- Ganadores de Torneos

Figura 4.10: Ejemplo de Entidad Ganadores de Torneos que cumple con la 3FN.

- Jugadores de Tenis
 Figura 4.11: Ejemplo de Entidad Jugadores de Tenis que cumple con la 3FN.

4.4.4. Cuarta forma Normal

La Primera forma normal prohíbe relaciones donde se tengan atributos no

atómicos o con múltiples valores. Sin embargo existen muchas situaciones en las
cuales una entidad requiere este tipo de atributos.

A una condición que haga cumplir esta dependencia de los atributos que requieren
duplicación de valores se le denomina una Dependencia Multivaluada. Debido a
que requieren una gran duplicación de valores de datos, un aspecto importante del
proceso de normalización es eliminar las Dependencias Multivaluadas. Esto se
hace con la Cuarta Forma normal.

Una entidad está en 4FN si está en 3FN y no tiene atributos multivaluados.

Debido a que el problema de las dependencias multivaluadas surge a partir de los

atributos multivaluados, se puede encontrar una solución colocando todos los
atributos multivaluados en entidades formadas por ellos mismos, junto con la clave
a la cual se aplican los valores de los atributos.

- Ejemplo

En un escenario académico, a un miembro de una facultad se le asignan

diferentes comisiones y es responsable de múltiples cursos.

- Facultad
 Figura 4.12: Ejemplo de Entidad Facultad que no cumple con la 4FN.

Aplicando la 4FN, se debe separar la entidad en 2, de la siguiente forma:

- Comité

Figura 4.13: Ejemplo de Entidad Comité que cumple con la 4FN.

- Curso

Figura 4.14: Ejemplo de Entidad Curso que cumple con la 4FN.

4.4.5. Quinta forma Normal

Las restricciones de las dependencias funcional y multivaluada resultan

necesarias para las 2FN, 3FN y 4FN. La Quinta Forma Normal (5FN) elimina las
anomalías que resultan de un tipo de restricción llamado dependencias de unión
(en inglés, Join Dependencies). Estas dependencias son principalmente de interés
teórico, por lo cual la 5FN no tiene una aplicación práctica en modelos reales.

Capítulo 5.- Diseño de aplicaciones

con acceso a Bases de Datos

OBJETIVOS

- Promover el uso correcto de los principios de Diseño de Aplicaciones, para lograr que los
programadores consideren la forma como sus scripts afectan al rendimiento de la Base de datos.

- Introducir las definiciones del lenguaje SQL y sus instrucciones principales.

- Explicar la forma cómo los DBMS's aseguran la integridad de la información mediante las
transacciones.

- Identificar los tipos de bloqueos y la forma adecuada de utilizarlos, para evitar el deadlock.

5.1. Introducción
El diseño de Aplicaciones es un proceso que va más allá de escribir sentencias
eficientes para realizar requerimientos a una Base de datos. Cada parte de un
programa afecta a la efectividad y facilidad de uso de la aplicación, por lo que
debe ser diseñada para asegurar la integridad de los datos que modifica, cuidando
siempre que el rendimiento sea óptimo.

Basado en el dominio que posee sobre el control de un DBMS, el DBA debe

promover el uso correcto de los principios de Diseño de Aplicaciones. Es
inaceptable que se permita a los programadores diseñar y elaborar aplicaciones
sin considerar la forma como sus scripts afectan al rendimiento de la Base de
datos.

Es común que las organizaciones prioricen el tiempo en el Proceso de desarrollo

de aplicaciones, haciendo que los programadores atiendan únicamente los
requerimientos funcionales: es decir, si el programa muestra lo que el usuario
quiere ver, es correcto.

Es ideal que durante el proceso de desarrollo de aplicaciones se apliquen pruebas

de la calidad del código, para asegurar la eficiencia de los programas.
Lastimosamente se asume que cualquier problema de rendimiento posterior será
resuelto por el DBA. Para un DBA experimentado es claro que los mayores
causantes de afectaciones de rendimiento son las aplicaciones con códigos
ineficientes, y que la solución más factible es el rediseño del código. Entonces
¿por qué no escribir códigos eficientes desde el principio?

Para diseñar correctamente aplicaciones con acceso a Bases de datos, se debe

tener un dominio adecuado de los siguientes temas:

- Cómo los datos son almacenados en una Base de Datos Relacional.

- Cómo utilizar las sentencias SQL adecuadas para acceder a la información y

modificarla.

- Diferencias entre los lenguajes de programación tradicionales y SQL.

- Uso de objetos de programación del DBMS: procedimientos almacenados y
funciones.

- Cómo optimizar los accesos a las Bases de Datos mediante el uso de índices.

5.2. SQL
El SQL (Structured Query Language) es un lenguaje de consulta y programación
utilizado para examinar, reemplazar y gestionar la información almacenada en los
DBMS's.

Estándares de SQL han sido definidos por las siguientes entidades

internacionales:

- ANSI (American National Standards Institute)

- ISO (Internacional Organization for Standardization)

La ANSI es una organización de compañías industriales y comerciales que

desarrollan estándares de comunicación y negocio para los Estados Unidos. La
ANSI es a su vez miembro de la ISO y de la IEC (Intemational Electrotechnical
Commission). La ANSI constantemente publica estándares para Estados Unidos
que se corresponden con sus respectivos estándares internacionales. En el año
1992, la ISO e la IEC publicaron un estándar para SQL llamado SQL92. La ANSI
publicó un estándar equivalente llamado ANSI SQL92. ANSI SQL92 es conocido
simplemente como ANSI SQL.

Aunque los fabricantes de DBMS's han introducido en sus productos

optimizaciones en las instrucciones SQL, todos cumplen con el estándar ANSI
SQL.

El lenguaje SQL contiene instrucciones que se agrupan en las siguientes

categorías:

- Instrucciones DDL (Data Definition Lenguage): Son instrucciones se utilizan para

la definición y administración de objetos como bases de datos, tablas y vistas.

- Instrucciones DML (Data Manipulation Languages): Son instrucciones que se

utilizan para la manipulación de la información contenida en las base de datos.

5.2.1. Instrucciones DDL

El lenguaje de definición de datos (DDL por sus siglas en inglés) es el que permite
la modificación de las estructuras de los objetos de la base de datos. Existen
cuatro instrucciones DDL básicas: CREATE, ALTER, DROP y TRUNCATE.
- CREATE: Este comando crea un objeto dentro de la base de datos. Estos
objetos pueden ser una tabla, vista, índice, trigger, función, procedimiento o
cualquier otro que el motor de la base de datos soporte.

Ejemplo: Creación de una tabla

CREATE TABLE TABLA_NOMBRE (

CAMPO1 INT,
CAMPO2 CHAR(10)
)

- ALTER: Este comando permite cambiar la estructura de los objetos de la base de

datos. Es posible agregar o quitar campos a una tabla, modificar el tipo de datos
de un campo, agregar o quitar índices a una tabla, alterar un trigger, etc.

Ejemplo: Agregar columna a una tabla.

ALTER TABLE TABLA_NOMBRE (

ADD CAMPO_NUEVO INT
)

- DROP: Este comando permite eliminar un objeto de la base de datos, que puede
ser una tabla, vista, índice, trigger, función, procedimiento o cualquier otro objeto
que el motor de la base de datos contenga. Es posible combinar este comando
con la sentencia ALTER.

Ejemplo: Eliminación de una tabla:

DROP TABLE TABLA_NOMBRE

- TRUNCATE: Este comando se utiliza para borrar todo el contenido de una tabla.
La ventaja de este comando sobre DELETE, es que es mucho más rápido si se
quiere borrar todo el contenido de la tabla, especialmente si la tabla es muy
grande. La desventaja es que TRUNCATE solamente sirve cuando se quiere
eliminar absolutamente todos los registros, ya que no es permitida la cláusula
WHERE. Aunque en un principio esta sentencia parece ser de tipo DML, es en
realidad una DDL, ya que internamente para su ejecución, el comando borra la
tabla y la vuelve a crear. Este comando no genera transacciones en el área de log.

Ejemplo: Truncar una tabla.

TRUNCATE TABLE "TABLA_NOMBRE"

5.2.2. Instrucciones DML

El lenguaje de manipulación de datos (DML por sus siglas en inglés) es un
lenguaje proporcionado por los DBMS's que permite llevar a cabo las tareas de
consulta o gestión de la información, organizados por el modelo de datos
adecuado.

- SELECT: Esta sentencia sirve para hacer una consulta de los datos que se
encuentren en una tabla. Una consulta realizada con este comando devuelve los
registros que cumplan con la condición indicada.

Sintaxis:

SELECT Columna1, Columna 2....Columna N FROM "nombre_tabla"

Ejemplos:

La siguiente sentencia devuelve todos los registros de una tabla:

Select * from facturas

La siguiente sentencia devuelve solamente los registros que cumplen con la

condición indicada:

Select * from facturas Where codigo_ciudad = "05"

La siguiente sentencia devuelve solamente los campos indicados:

Select Cliente, Valor from facturas Where codigo_ciudad =

"05"

La siguiente sentencia devuelve el número de los registros que cumplen con la

condición indicada:

Select count(*) from facturas Where codigo_ciudad = "05"

La siguiente sentencia devuelve el valor total de los registros que cumplen con la
condición indicada:

Select sum(Valor) from facturas Where codigo_ciudad = "05"

- INSERT: Una sentencia INSERT de SQL permite agregar uno o más registros a
una tabla en una base de datos.

Sintaxis:

INSERT INTO nombre_tabla (columna1, [columna2,...])

VALUES (valor1, [valor2,...])

Las cantidades de columnas y valores tienen que ser siempre iguales. Si una
columna no se especifica en la sentencia, le será asignado el valor por omisión
indicado en la definición de la tabla. Los valores especificados por la sentencia
INSERT tienen que satisfacer todas las restricciones aplicables a cada campo. Si
en la ejecución de la sentencia ocurre un error de sintaxis o si alguna de las
restricciones es vulnerada, no se agrega el registro y se devuelve un error al
usuario.

Ejemplo:

INSERT INTO agenda_telefonica (nombre, numero) VALUES ("Juan

Aguirre", "094895623")

Cuando se especifican todos los valores de una tabla, se puede utilizar la

sentencia acortada:

INSERT INTO agenda_telefonica VALUES ("Juan Aguirre",

"094895623")

- UPDATE: Una sentencia UPDATE de SQL es utilizada para modificar los valores
de un grupo de registros existentes en una tabla.

Sintaxis:

UPDATE nombre_tabla SET columnaX = valorX [columnaX1 =

valorX2,...]

WHERE columnaN = valorN

Ejemplo:

UPDATE tabla_ejemplo SET campo1 = 'nuevo valor' WHERE campo2

= 'N'

- DELETE: Una sentencia DELETE de SQL permite borrar registros existentes en

una tabla que cumplan con la condición establecida.

Sintaxis:

DELETE nombre_tabla WHERE columnaX = valorX

Ejemplo:

DELETE tabla_ejemplo WHERE campo2 = 'N'

5.3. Definición de Transacciones
Una transacción se define dentro del ámbito de los sistemas de información como
una unidad de trabajo atómica, con respecto a la consistencia de los datos. Una
transacción ejecuta un proceso de negocio completo que es solicitado por un
usuario. Una transacción lógica puede consistir de vario pasos y requerir más de
una transacción física. El resultado de la ejecución de una transacción afectará los
datos almacenados en la Base, los cuales tienen que ser correctos antes y
después de la transacción.

Cuando todos los pasos de una transacción son ejecutados sin problemas, se
acepta la transacción, ejecutando la sentencia COMMIT. La ejecución de la
sentencia COMMIT le indica al DBMS que los cambios realizados por la
transacción pueden ser finalmente grabados en la Base de Datos.

Si alguno de los pasos de la transacción falla, se tienen que solicitar al DBMS que
deshaga los cambios realizados. Esto se realiza ejecutando una sentencia
ROLLBACK. Cuando se ejecuta la sentencia ROLLBACK, los datos almacenados
son llevados a su estado inicial, es decir, al valor que tenían antes de la ejecución
de la transacción.

5.3.1. ACID
Es obligatorio que una transacción cumpla con las propiedades establecidas por el
estándar ACID: atomicity, consistency, isolation, durability. Cada una de estas
cuatro condiciones tiene que cumplirse para asegurar que una transacción está
correctamente diseñada.

- Atomicidad: esta condición asegura que la operación sea exitosa solamente si

todas sus partes se realizaron correctamente. Si una parte falla, la transacción se
declara no exitosa.

- Consistencia: es la condición que asegura que sólo se empieza aquello que se

puede acabar. Por este motivo solamente se ejecutan aquellas operaciones que
no van a romper ninguna regla o directriz de integridad de la base de datos.

- Aislamiento: esta condición asegura que una operación no puede afectar a otras.
Esto permite que la realización de dos transacciones simultáneas sobre la misma
porción de información nunca generará ningún tipo de error.

- Durabilidad: es la condición que asegura que una vez realizada la operación, el

resultado de ésta persistirá y no se podrá deshacer aunque falle el sistema.

Los DBMS aseguran el cumplimiento de las propiedades ACID a través de

mecanismos como los bloqueos.
5.3.2. Guía para la programación de Transacciones
Para el diseño de las transacciones se debe considerar:

- Una transacción debe ser corta en duración, porque ésta bloquea recursos
compartidos para otras transacciones.

- Una transacción debe estar diseñada para que no espere una decisión, para que
no haya retrasos por una respuesta en medio de su ejecución.

5.4. Bloqueos
Una responsabilidad importante para un administrador de base de datos es la
consistencia del DBMS, es decir, asegurar que los programas y procedimientos
proporcionen la confiabilidad de los datos a pesar de que ocurran posible errores
en la operación del equipo, programas o errores humanos.

En un entorno multiusuario el control de los accesos a los datos es complicado. En

primer lugar, cuando los usuarios ingresan a la base de datos en forma
concurrente, siempre existe la posibilidad de que el trabajo de un usuario pueda
interferir con el de otro.

Resaltan dos aspectos en los que hay que tener cuidado para lograr aportar
confiabilidad a una base de datos dentro de un ambiente multiusuario:

- Control del procesamiento concurrente: Dentro de un entorno multiusuario los

requerimientos se presentan mediante transacciones. Como se ha indicado, una
transacción es una serie de pasos que deben ser ejecutados en la base de datos,
de tal forma que se ejecutan todos ellos o ninguno de ellos se ejecuta en absoluto,
en cuyo caso la base de datos no resulta modificada.

Se conoce como procesamiento concurrente a aquel procesamiento que se realiza

cuando dos o más transacciones están interconectadas entre sí, lo que ocurre con
más frecuencia dentro de un ambiente multiusuario.

Generalmente las solicitudes se ejecutan en la base de datos por una instrucción a

la vez y alternando entre los distintos procesos que compiten por el uso del tiempo
del CPU. Esto produce que aunque para cada usuario parezca que el proceso se
realiza de manera independiente y sin periodos de espera, en realidad se realizan
sus peticiones de manera entrelazada con las peticiones de los demás usuarios.

Cuando dos usuarios concurrentes ejecutan en el mismo instante una transacción

que afecta a la misma información, es cuando se puede presentar el problema de
la actualización perdida. Esto consiste en que los dos usuarios quieren actualizar
al mismo tiempo el mismo rango de datos.
Una solución para las inconsistencias producidas por el procesamiento
concurrente es impedir que varias aplicaciones obtengan copias del mismo
registro cuando el registro esté a punto de ser modificado. Este método es
conocido como bloqueo de recursos.

- Bloqueo de recursos: Para evitar el problema de procesamiento concurrente, los

registros recuperados para su actualización no deben ser compartidos entre
diferentes usuarios.

Los bloqueos pueden colocarse de forma automática por el DBMS o por medio de
un comando ejecutado en el DBMS, partiendo del programa o del usuario de la
consulta. Los bloqueos colocados por el DBMS se conocen como bloqueos
implícitos. Los bloqueos que son colocados por comando se llaman bloqueos
explícitos.

Los bloqueos pueden ser colocados en distintos niveles: registro, página, tabla o
base de datos. Al tamaño del bloqueo se lo conoce como granularidad del
bloqueo. Los bloqueos con granularidad mayor son adecuados para el DBMS en
cuanto a su administración, porque consumen menos recursos de memoria. Sin
embargo, con frecuencia causan conflictos. Los bloqueos con pequeña
granularidad son difíciles de administrar, porque consumen mucha memoria.
Cuando se colocan bloqueos con granularidad fina existen muchos más detalles
que el DBMS debe de controlar y revisar, pero los conflictos son menos comunes.

Los bloqueos tienen diferentes tipos. Un bloqueo exclusivo cierra al objeto ante un
acceso de cualquier fuente. Ninguna otra transacción puede leer o modificar los
datos. Un bloqueo compartido cierra los objetos ante modificaciones, pero no a la
consulta. Otras transacciones pueden leer al objeto, siempre que no intenten
modificarlo.

Cuando dos o más transacciones se realizan concurrentemente, los resultados en

la base de datos deben ser consistentes con los resultados que se habrían
obtenido si las transacciones se hubieran procesado de una forma arbitraria y
serial, o simplemente de forma distinta. Una función que procesa de esta forma se
dice que es serializable. Una forma de obtener la serialización es utilizar un
bloqueo de dos fases, el cual consiste en obtener todos los bloqueos según sea
necesario (fase de crecimiento) y posteriormente liberar todos los bloqueos (fase
de recogimiento).

Los límites de una transacción deben corresponder a la definición del objeto que
se está procesando. Siguiendo esta estrategia de dos fases, las hileras de cada
afinidad en el objeto se bloquean conforme se necesitan. Se realizan las
modificaciones, pero los datos no se devuelven a la base de datos hasta que todo
el objeto haya sido procesado. Ya en este punto se efectúan los cambios a la base
de datos real, y todos los bloqueos son liberados.
Aunque los bloqueos resuelve un problema, generan otro muy grave que se
denomina interbloqueo o abrazo mortal (deadlock). El deadlock consiste en que
un usuario espera un recurso que otro usuario tiene bloqueado, y este usuario a
su vez esté esperando por un recurso que el primer usuario tiene bloqueado.
Existen dos maneras comunes de resolver este problema: impidiendo que el
interbloqueo se presente o permitiendo que ocurra, y a continuación resolverlo.

5.4.1. Tipos de Bloqueos

A un nivel inicial, un DBMS coloca un bloqueo de escritura cuando escribe un
registro, o coloca un bloqueo de lectura cuando se tiene que leer un registro. Una
escritura se presenta cuando se ejecutan las instrucciones INSERT, UPDATE o
DELETE. Una lectura se presenta con una sentencia SELECT es ejecutada. En
general, los DBMS's utilizan tres tipos de bloqueos:

- Bloqueo compartido (shared lock): El DBMS coloca este bloqueo cuando se

ejecuta una sentencia para consultar datos, sin modificarlos. Este tipo de bloqueo
permite que otros usuarios consulten simultáneamente la misma información. Pero
si un usuario intenta modificar, no podrá hacerlo hasta que el bloqueo compartido
sea liberado, es decir, hasta que los otros usuarios dejen de consultar la
información.

- Bloqueo exclusivo (exclusive lock): El DBMS coloca este bloqueo cuando se

ejecuta una sentencia para modificar datos. No se permite a otros usuarios ni
consultar ni modificar simultáneamente la misma información, cuando está
colocado un bloqueo exclusivo. Esto permite que los usuarios consulten
información consistente.

- Bloqueo de actualización (update lock): El DBMS coloca este tipo de bloqueo

cuando la información primero tiene que ser leída para luego ser cambiada o
eliminada. El bloqueo de actualización indica que la información va a ser
modificada posteriormente. Cuando la actualización se produce, el DBMS hace
una promoción hacia un bloqueo exclusivo.

5.4.2. Timeouts
Cuando los datos están bloqueados por un proceso, otro proceso tiene que
esperar hasta que se libere el bloqueo, para poder acceder a la información. Un
bloqueo colocado por demasiado tiempo se convierte en un potencial problema
para el rendimiento de la aplicación. Si la aplicación no ha sido diseñada de forma
apropiada, el bloqueo no se liberará hasta que el programa falle o se realice una
acción por parte del DBA.

El mecanismo de bloqueos de un DBMS previene que las aplicaciones esperen la

liberación de un proceso indefinidamente. Cada DBMS provee un parámetro de
configuración para el valor de timeout de bloqueos. Este parámetro puede ser
configurado a nivel de DBMS, proceso o conexión. Cuando se ha llegado al tiempo
indicado, el proceso se corta y el usuario será notificado con un mensaje de error.

A pesar de esta funcionalidad que ofrecen los DBMS's, se considera como una
buena práctica que los programas controlen el timeout para reversar las
transacciones.

5.4.3. Deadlocks
Un proceso puede estar identificado con tres estados diferentes: leyendo,
ejecutando o bloqueado. En el estado de lectura, un proceso está parado,
concediendo que otro proceso sea ejecutado; en el estado de ejecución, un
proceso está utilizando algún recurso; y en el estado de bloqueo, el proceso está
parado y no se ejecutará mientras no tenga los recursos que necesita.

Una condición común no deseable es el deadlock o interbloqueo, que se

presenta cuando dos procesos están en un estado de ejecución, y requieren
intercambiar recursos entre sí para poder continuar. Los dos procesos están
esperando por la liberación del recurso requerido, pero esta nunca se presentará;
como no hay ningún resultado, se toma un camino que lleva a una situación de
deadlock.

Muchos escenarios han sido construidos para ilustrar las condiciones de deadlock,
siendo el más popular el Problema de Comida de los Filósofos:

Cinco filósofos tienen cinco platos de fideos enfrente y cinco tenedores, uno a
cada lado del plato. Los filósofos requieren ambos tenedores (derecha e izquierda)
para comer. Durante la comida realizarán solo dos operaciones mutuamente
excluyentes, pensar o comer. El problema es un paralelismo simplista entre
procesos (los filósofos) tratando de obtener recursos (tenedores); mientras están
en estado de ejecución (comiendo) o de lectura (pensando). Una condición posible
de deadlock puede ocurrir, si todos los filósofos quieren coger el tenedor de la
derecha y, a la vez, el de la izquierda: la comida terminará en estado de deadlock.

Se dice que dos procesos se encuentran en estado de deadlock (interbloqueo,

bloqueo mutuo o abrazo mortal) cuando están esperando por condiciones que
nunca se cumplirán. También se puede definir un deadlock como el estado
permanente de bloqueo de un conjunto de procesos que están compitiendo entre
sí por recursos del sistema.

Para que se presente un deadlock, deben cumplirse las siguientes condiciones:

- Condición de exclusión mutua: Existe al menos un recurso compartido por los

procesos, al cual sólo puede acceder uno de forma simultánea.
- Condición de Posesión y espera: Al menos un proceso Pi ha adquirido un
recurso Ri, y lo mantiene mientras espera al menos un recurso Rj que ya ha sido
asignado a otro proceso.

- Condición de no expropiación: Los recursos no pueden ser tomados por los

procesos. Es decir, los recursos sólo pueden ser liberados voluntariamente por
quienes los poseen.

- Condición de espera circular: Dado el conjunto de procesos P0...Pn, P0 está

esperando un recurso adquirido por P1, que está esperando un recurso adquirido
por P2, que...,que está esperando un recurso adquirido por Pn, que está
esperando un recurso adquirido por P0. Esta condición implica la condición de
retención y espera.

Los deadlocks se pueden prevenir asegurando que no suceda alguna de las

condiciones necesarias nombradas anteriormente:

- Eliminando la exclusión mutua: ningún proceso puede tener acceso de forma

exclusiva a un recurso. Esto es imposible para procesos que no pueden ser
encolados, aunque con colas también pueden presentase interbloqueos.

- La condición de retención y espera puede ser eliminada haciendo que los

procesos soliciten todos los recursos que van a necesitar antes de empezar su
ejecución. Este conocimiento por adelantado muchas veces es imposible. Otra
forma es requerir que los procesos liberen todos sus recursos antes de pedir todos
los recursos que necesitan. Esto también es poco práctico en la realidad.

- La condición de no expropiación puede ser imposible de eliminar debido que un

proceso debe tener un recurso por un cierto tiempo o el procesamiento puede
quedar inconsistente.

- La condición de espera circular es la más fácil de controlar. Se le permite a un

proceso poseer sólo un recurso en un determinado momento, o una jerarquía
puede ser impuesta de modo tal que los ciclos de espera no sean posibles.

5.4.4. Nivel de Aislamiento

El isolation level o nivel de aislamiento determina la forma en que los registros
son bloqueados o aislados de otros procesos mientras son accedidos. Es decir,
define cómo y cuándo los cambios realizados por una transacción son visibles por
otras operaciones concurrentes, influyendo en las siguientes anomalías:

- Dirty Reads: Ocurre cuando una transacción lee datos modificados por otros
procesos concurrentes que aún no han realizado COMMIT.
- Nonrepeatable Reads: Se presenta cuando dentro de una transacción se lee el
mismo registro más de una vez y los datos obtenidos son diferentes, seguramente
porque otro proceso concurrente los actualizó.

- Phantom Reads: Se presenta cuando en una transacción se ejecuta la misma

consulta más de una vez y se obtienen distintos resultados. Por ejemplo, si otra
transacción agregó nuevos registros que satisfacen el criterio de búsqueda de la
consulta.

El estándar ANSI SQL define cuatro niveles de aislamiento:

- READ UNCOMMITTED: Permite que se produzcan Dirty Reads, Nonrepeatable

Reads y PhantomReads. Esta es la opción menos restrictiva. Es recomendable si
se manejan datos de solo lectura o muy pocas actualizaciones.

- READ COMMITTED: Evita la presencia de Dirty Reads, pero permite que se

produzcan Nonrepeatable Reads y Phantom Reads.

- REPEATABLE READ: Solamente permite que se presenten Phantom Reads.

- SERIALIZABLE: Evita todos los casos anteriores. Es la opción más restrictiva y

costosa.

Cada manejador de base de datos tiene su forma de configurar el isolation level,

ya sea a través de un administrador gráfico o por línea de comandos. Por otro lado
también es necesario aclarar que los DBMS's difieren en los valores por defecto
de los niveles de aislamiento.

Capítulo 6.- Integridad de Datos

OBJETIVOS
- Establecer la diferencia entre la integridad semántica y la integridad estructural.
- Identificar los mecanismos de control de la integridad estructural que proveen los DBMS's.
- Identificar los mecanismos de control de la integridad semántica que proveen los DBMS's.
- Analizar los tipos de relaciones entre las entidades y la forma de mantener la integridad
referencial.
6.1. Introducción
El aseguramiento de la Integridad de las Bases de Datos de la organización es
una parte muy importante del trabajo del DBA. Si existen problemas de integridad,
una base de datos se vuelve poco útil. Los DBMS's proveen herramientas para
asegurar la integridad de los datos.

Con respecto a las Bases de Datos, veremos dos aspectos principales de la

integridad:

- Integridad de la estructura de las Bases de datos.

- Integridad semántica de los datos.

El objetivo de la integridad estructural es salvaguardar la forma cómo se

almacenan los objetos de una Base de datos. Cada DBMS utiliza sus propios
formatos internos para almacenar las bases de datos, tablas, índices y otros
objetos. Algunos errores inesperados del hardware o sistema operativo pueden
causar daños en estas estructuras, que el DBA debe identificar y corregir cuando
se produzcan, antes de que causen problemas serios.

En cambio, la Integridad semántica se refiere al significado en sí de la información

almacenada, basada en las relaciones del modelo de datos. Los DBMS proveen
controles y procedimientos para definir y asegurar la integridad semántica de la
información almacenada en las Bases de datos. Es una tarea del DBA
implementar los componentes de integridad semántica en los modelos de datos
que se generen.

6.2. Integridad Estructural

La integridad estructural es un elemento importante de la Administración de Bases
de datos. El DBMS utiliza estructuras internas y punteros para mantener a los
objetos en un orden correcto. Si se presenta un error en estas estructuras, el
acceso a los datos se ve seriamente comprometido.

6.2.1. Tipos de Problemas estructurales

Uno de los problemas más comunes que se presentan en las Bases de datos
relacionales es la corrupción de índices. Internamente, los DBMS's manejan a los
índices en estructuras de árboles, siendo la "B-tree" la más común. Básicamente,
las páginas de hojas de un índice son los punteros a la localización física de los
datos en una Base. Si los punteros no dirigen a la información correcta, el índice
se vuelve inutilizable.
Además de los índices, existen otras estructuras de Bases de datos que utilizan
punteros. Cuando se utilizan ciertos tipos de datos, el DBMS debe utilizar
punteros. Por ejemplo, objetos muy grandes como los tipos de datos para textos o
imágenes, no son guardados de forma continua en los discos.

Otro tipo de corrupción que puede presentarse es el daño de las cabeceras de

páginas. Como es conocido, la unidad de información de las bases de datos es la
página. Cada página física dentro de una base de datos guarda información de su
contenido en una cabecera, al inicio de la página. Esta cabecera permite al DBMS
leer el contenido de la página de forma rápida y sencilla. Si la cabecera está
dañada, el DBMS no interpretará correctamente el contenido de la página. Este
problema constituye un daño grave, y cuando se presenta, se requiere la carga de
respaldos para la recuperación de la información.

6.2.2. Control de los Problemas estructurales

Cada DBMS provee diferentes utilidades para chequera diferentes aspectos de la
consistencia estructural. Es posible investigar el estado de la integridad de los
objetos de Bases de datos utilizando estos utilitarios. Por ejemplo, Sybase y
Microsoft SQL ofrecen la utilidad DBCC, mientras que DB2 ofrece los utilitarios
CHECK y REPAIR.

Siendo este tipo de utilitarios equivalentes, exploremos las opciones del comando
DBCC, para observar los tipos de chequeos de consistencia que pueden
realizarse.

Cabe indicar que estas utilidades deben ser manejadas con cuidado, porque es
posible leer y escribir directamente en los archivos que utiliza la base de datos,
cuando se las ejecuta.

La utilidad DBCC provee dos opciones básicas para el chequeo de consistencia:

- DBCC CHECKTABLE (nombre_tabla): chequea la consistencia de los datos e

índices de una tabla. DBCC reporta el número de páginas y registros de la tabla,
así como las inconsistencias encontradas.

- DBCC REINDEX (nombre_tabla): chequea la consistencia de los índices y

ejecuta un reindexamiento (vuelve a generar el índice).

Adicionalmente, DBCC provee opciones para el chequeo de una base de datos

completa:

- DBCC CHECKDB (nombre_base): ejecuta la opción CHECKTABLE sobre cada

tabla de la Base de datos, por lo que chequea la consistencia de los datos e
índices de cada una de las tablas.
- DBCC CHECKCATALOG (nombre_base): chequea la consistencia de las tablas
de sistema de una base de datos. Reporta el número de páginas y registros de la
tabla, así como las inconsistencias encontradas.

- DBCC CHECKALLOC (nombre_base): reporta las inconsistencias del

almacenamiento físico de la base de datos.

6.3. Integridad Semántica

La Integridad Semántica busca asegurar que el significado de la información
almacenada sea coherente con las relaciones definidas en el modelo de datos.
Los DBMS proveen controles y procedimientos para definir y asegurar la
integridad semántica de la información.

Los niveles de integridad semántica que manejan los DBMS's son:

- Integridad de la entidad

- Unique Constraints

- Tipos de datos

- Valores por Defecto

- Check Constraints

- Triggers

- Integridad Referencial

6.3.1. Integridad de la entidad

La integridad de la entidad es el nivel más básico que necesita el modelo

relacional. La integridad de la entidad implica que todo registro de una entidad
pueda ser identifico de forma única.

En otras palabras la integridad de la entidad requiere:

- Que siempre se especifique una clave primaria para cada entidad del modelo de
datos.

- Que ningún campo componente de la clave primaria de una entidad puede

aceptar valores nulos.

La justificación para la regla de integridad de las entidades es la siguiente:

- Las entidades corresponden a personas, animales o cosas del mundo real

- Por definición, las entidades en el mundo real son distinguibles; es decir se les
puede identificar de alguna manera.

- Por tanto los representantes de entidades dentro de la Base de datos deben ser
distinguibles también.

- Las Claves primarias son utilizadas para otorgar identidad única dentro del
modelo relacional.

- Si tiene valor nulo y esto implica que "la propiedad no es aplicable" es evidente
que el registro no tiene sentido.

- Si significa, "el valor se desconoce", pueden aparecer problemas de varios tipos.

- Una entidad sin identidad es una contradicción de términos: simplemente la

entidad no existe.

En la práctica, la mayor parte de los DBMS's no forzan la integridad de la entidad,

porque las tablas pueden crearse sin tener una clave primaria. Pero es
considerada como una "mala práctica" la costumbre de crear tablas sin claves
primarias, debido a que se dificulta la identificación de los registros de una tabla.

6.3.2. Unique Constraints

Un "unique constraint" es similar a un constraint de clave primaria, con la

diferencia que una tabla puede tener más de un unique constraint. Esta
herramienta de integridad asegura que solamente haya un valor en la tabla para el
campo o conjunto de campos que lo componen.

El unique constraint no es utilizado para definir integridad referencial, solamente

previene la duplicidad de datos en una tabla.

6.3.3. Tipos de datos

La definición del tipo de dato y tamaño de un campo es la aplicación de integridad

fundamental que se aplica a los datos en una Base. Simplemente con definir el
tipo de dato para cada columna, el DBMS no permitirá que se ingresen valores
que no sean del tipo indicado. Los procesos que lo intenten serán rechazados.

Los tipos de datos para las columnas de una tabla deben ser escogidos en tiempo
de diseño con mucha precaución, procurando realizar la elección adecuada al
dominio de la información que se va a almacenar.
6.3.4. Valores por Defecto

Para cada columna es posible definir un valor por defecto, de forma opcional. El
valor por defecto se asignará de forma automática a una columna cuando no se
especifique un valor determinado al insertar un registro nuevo.

Si una columna puede tener un valor nulo y no se especifica un valor por defecto,
se usará NULL como valor por defecto.

Es claro que el valor por defecto asignado a un campo debe ser del mismo tipo de
dato.

6.3.5. Check Constraints

Este tipo de constraints son usadas para asegurar reglas simples de negocio
sobre el contenido de los datos en las tablas.

Los check constraints pueden referenciar a otras columnas en la fila que está
siendo chequeada, pero no pueden referenciar a otras filas o a otras tablas, o
llamar a funciones.

Es posible que una columna pueda estar protegida por más de un check
constraint. De la misma forma, una check contraint puede proteger a más de una
columna.

6.3.6. Triggers

Un trigger (disparador) es una función que se ejecuta cuando se cumple una

condición establecida, cuando se realiza una operación de inserción, actualización
o eliminación de registros en una tabla.

Los triggers son muy utilizados para mejorar la gestión de la Base de datos,
especialmente para asegurar la integridad de la información. Son muy útiles pues
permiten realizar una acción automática sin necesidad de que el usuario ejecute
ninguna sentencia de SQL.

También es posible utilizar un trigger para generar valores de columnas, prevenir

errores de datos, sincroniza tablas, cambiar valores de una vista, etc.

La estructura básica de un trigger es la siguiente:

- Llamada de activación: es la sentencia (insert, delete, update) que permite

"disparar" el código a ejecutar.

- Restricción: es la condición que se requiere para ejecutar el código.

- Acción a ejecutar: es la secuencia de instrucciones a ejecutar cuando se han
cumplido las condiciones iniciales.

Existen dos tipos de triggers que se clasifican según la cantidad de ejecuciones

pueden realizar:

- Row Triggers (Disparadores de fila): son aquellos triggers que se ejecutaran n-

veces si se llama n-veces desde la tabla asociada al trigger.

- Statement Triggers (Disparadores de secuencia): son aquellos triggers que, sin

importar la cantidad de veces que se cumpla con la condición, se ejecutan
solamente una vez.

Algunas características importantes de los triggers son:

- Los triggers no aceptan parámetros o argumentos (de entrada o salida), pero

podrían almacenar los datos afectados en tablas temporales.

- No pueden ejecutar las operaciones COMMIT o ROLLBACK por que estas son
parte de la sentencia SQL del disparador.

- Si se han escrito de manera deficiente, pueden causar errores de mutaciones en

las tablas.

6.3.7. Integridad Referencial

La integridad referencial se basa en un conjunto de reglas que utilizan los DBMS's

para asegurarse que los registros de tablas relacionadas son válidos y que no se
borren o cambien datos relacionados de forma accidental produciendo errores de
integridad.

Dentro de un modelo relacional los tipos de relaciones son:

- Relación Uno a Uno: Cuando un registro de una tabla sólo puede estar
relacionado con un único registro de la otra tabla.

- Ejemplo

Se Tiene una tabla de profesores y otra de departamentos. Se requiere saber qué

profesor es jefe de qué departamento. Para lograr esto se establece una relación
uno a uno entre las dos tablas, ya que un departamento tiene un solo jefe y un
profesor puede ser jefe de un solo departamento.
 Figura 6.1: Relación Uno a Uno.

- Relación Uno a Muchos: Cuando un registro de una tabla (tabla secundaria) sólo
puede estar relacionado con un único registro de la otra tabla (tabla principal) y un
registro de la tabla principal puede tener más de un registro relacionado en la tabla
secundaria. En este caso se suele hacer referencia a la tabla principal como tabla
"padre" y a la tabla secundaria como tabla "hijo". Entonces la regla se convierte en
"un padre puede tener varios hijos pero un hijo solo tiene un padre".

- Ejemplo:

Se tiene una tabla con los datos de diferentes poblaciones y otra con los
habitantes. Una población puede tener más de un habitante, pero un habitante
estará empadronado en una única población.

En este caso la tabla principal será la de poblaciones y la tabla secundaria será la

de habitantes. Una población puede tener varios habitantes pero un habitante
pertenece a una sola población. Esta relación se representa incluyendo en la tabla
"hijo" una columna que se corresponde con la clave principal de la tabla "padre".
Esta columna representa la clave foránea de la tabla.

En la tabla habitantes se tiene una columna "población" que contiene el código de

la población en la que está empadronado el habitante. Esta columna es clave
foránea de la tabla habitantes. En la tabla poblaciones tenemos una columna
"código de población" clave primaria de la tabla.

Figura 6.2: Relación Uno a Muchos.

- Relación Muchos a Muchos: Esta tipo de relación se presenta cuando un registro

de una tabla puede estar relacionado con más de un registro de la otra tabla. En
este caso las dos tablas no pueden estar relacionadas directamente, se tiene que
añadir una tabla entre las dos que incluya los pares de valores relacionados entre
sí.

Ejemplo: Se tiene una tabla con los datos de clientes y otra con los artículos que
se venden en la empresa. Un cliente puede realizar un pedido con varios artículos,
y un artículo podrá ser vendido a más de un cliente.

Para establecer la relación entre clientes y artículos hace falta otra tabla, por
ejemplo una tabla de pedidos. La tabla pedidos estará relacionada con cliente por
una relación uno a muchos y también estará relacionada con artículos por un
relación uno a muchos.

Figura 6.3: Relación Muchos a Muchos.

Cuando se define una columna como clave foránea, las filas de la tabla pueden
contener en esa columna un valor nulo o un valor que existe en la otra tabla. Un
error sería asignar un valor que no existe en la tabla primaria. Esto es lo que se
denomina integridad referencial y consiste en que los datos que son
referenciados desde otra tabla (claves foráneas) deben ser correctos. La
integridad referencial hace que el DBMS se asegure de que no haya en las claves
foráneas valores que no estén en la tabla principal.

La integridad referencial se activa en cuanto creamos una clave foránea y a partir

de ese momento se comprueba cada vez que se modifiquen datos que puedan
alterarla. Sin embargo, se podrían presentar errores en los siguientes casos:

- Cuando se inserta una nueva fila en la tabla secundaria y el valor de la clave

foránea no existe en la tabla principal.

- Cuando se modifica el valor de la clave principal de un registro que tiene hijos, es

decir, registros en una tabla que referencia a la clave primaria a través de una
clave foránea.

- Cuando se modifica el valor de la clave foránea, el nuevo valor también debe

existir en la tabla principal.
- Cuando se desea borrar una fila de la tabla principal y ese registro tiene registros
hijos.

Para soportar los casos de cambios en las claves primarias, los DBMS's ofrecen
las siguientes posibilidades:

- Actualización de registros en cascada: Esta opción le indica al DBMS que

cuando se cambie un valor del campo clave de la tabla principal, automáticamente
cambiará el valor de la clave foránea de los registros relacionados en la tabla
secundaria.

Ejemplo:

Si se cambia en la tabla de poblaciones (tabla principal) el valor 1 por el valor 10

en el campo código (la clave principal), automáticamente se actualizan todos los
habitantes (tabla secundaria) que tienen el valor 1 en el campo población (en la
clave ajena) dejando 10 en vez de 1.

Si no se tiene definida esta opción, no se pueden cambiar los valores de la clave

principal de la tabla principal. En el ejemplo, si se intenta cambiar el valor 1 del
código de la tabla de poblaciones, no se produce el cambio y el DBMS nos
devolverá un error indicando que los registros no se han podido modificar por
infracciones de clave.

- Eliminación de registros en cascada: Esta opción le indica al DBMS que cuando

se requiera eliminar un registro de la tabla principal, automáticamente se deben
borrar también los registros relacionados en la tabla secundaria.

Ejemplo:

Si se borra la población "Guayaquil" en la tabla de poblaciones, automáticamente

todos los habitantes de "Guayaquil" se borrarán de la tabla de habitantes.

Si no se tiene definida esta opción, no se pueden borrar registros de la tabla

principal si estos tienen registros relacionados en la tabla secundaria. En este
caso, si se intenta borrar la población "Guayaquil", no se produce el borrado y el
DBMS devuelve un error indicando que los registros no se han podido eliminar por
infracciones de clave.

Capítulo 7.- Disponibilidad de la

Información
 OBJETIVOS
- Analizar las causas de los problemas de disponibilidad de la información.
- Definición del downtime, dependiendo de los requerimientos de disponibilidad de la información.
- Definir las políticas que debe ser implementadas por una organización para asegurar la
disponibilidad de la información.

7.1. Introducción
El aseguramiento de la disponibilidad de la información es la tarea principal del
DBA. Si la Base de datos no está disponible, las aplicaciones no pueden trabajar,
con lo cual la Organización no funcionará con normalidad. Por esta razón, el DBA
pone todo su esfuerzo en asegurar que las Bases de datos se mantengan en línea
y operativas.

La necesidad de disponibilidad de los datos en nuestros días se ha incrementado,

con lo cual se ha disminuido el tiempo en que las Bases de datos pueden estar
fuera de línea.

De una manera sencilla, se puede definir que la "disponibilidad" es la condición

que se cumple cuando un recurso determinado puede ser accedido por sus
usuarios.

Otra definición alternativa es que "disponibilidad" es el porcentaje de tiempo que

un sistema puede ser usado productivamente.

La disponibilidad comprende varios componentes, los cuales en su combinación,

aseguran que los sistemas se están ejecutando y que la Organización puede
utilizarlos normalmente:

- Crear y mantener una infraestructura efectiva para satisfacer los servicios de los
usuarios.

- Capacidad de restablecer los servicios en el menor tiempo posible, en caso de

daños de la infraestructura.

- Capacidad de atender diferentes niveles de servicio.

- Habilidad de detectar pro-activamente posibles problemas, antes de que vuelvan

críticos.
7.2. Costo del Downtime
"Downtime" es un término utilizado para definir el tiempo en que los sistemas no
están disponibles para su utilización. El costo del downtime puede variar de una
Organización a otra, pues este costo depende del tipo de organización, sus
clientes y sus operaciones.

Para estimar el costo del downtime se deben considerar los siguientes factores:

- Posibles pérdidas de negocios durante el tiempo de paralización.

- Costos de recuperación de la infraestructura.

- Costos relacionados con implicaciones legales de la paralización.

- Impacto en la reducción de las operaciones.

Adicionalmente, el downtime puede impactar negativamente en la imagen de la

organización, lo cual muchas veces es más difícil de recuperar que las pérdidas
económicas.

Las organizaciones de este tiempo deben considerar que muchas veces las
pérdidas producidas durante un daño del sistema, suelen ser mayores que la
inversión necesaria para asegurar la alta disponibilidad de los sistemas.

7.3. Problemas de Disponibilidad

En este apartado revisaremos los principales eventos que pueden causar la
indisponibilidad de la información.

Estos eventos son:

- Pérdida del Centro de Cómputo

- Fallas de Hardware

- Fallas de Sistema Operativo

- Fallas del Servidor de Bases de datos

- Fallas de Seguridad

- Corrupción y Pérdida de datos

- Problemas de rendimiento

- Errores del Administrador de Bases de datos

7.3.1. Pérdida del Centro de Cómputo

Como es obvio, la información no estará disponible si el Centro de Cómputo no
está operativo. Posibles causas de la pérdida de un Centro de Cómputo son:

- Desastres naturales.

- Incendios.

- Atentados.

- Pérdidas de energía eléctrica prolongadas.

Para reestablecer la disponibilidad de la información se requiere recrear el entorno

de Bases de datos en un Centro Alterno.

Muchas organizaciones cuentan con un Plan de Continuidad del negocio, que

permite minimizar el impacto de un desastre en la operación del negocio.

7.3.2. Fallas de Hardware

Las fallas del hardware se pueden ser reducidas manteniendo repuestos
adicionales en bodega. Para asegurar este enfoque, tienen que garantizarse las
siguientes condiciones:

- Contar oportunamente con una persona con las habilidades requeridas para
diagnosticar el problema, identificar la parte defectuosa y reemplazarla.

- Que siempre esté disponible un repuesto para el hardware defectuoso.

Las consideraciones siguientes deben tomarse en cuenta para determinar el

inventario de repuestos que se debe mantener:

- Tiempo máximo que se permite estar fuera de servicio.

- Tasa de fallos proyectado por periodo.

- Tiempo estimado para el cambio del repuesto.

- El presupuesto establecido para el inventario de repuestos.

- Espacio de almacenamiento disponible para los repuestos. La bodega debe
contar además con las condiciones necesarias para que las partes se conserven
en buen estado.

- Otros equipos que podrían usar un mismo repuesto.

Una alternativa apropiada para gestionar los problemas de fallas de hardware, es

contar con un Contrato de Servicio Técnico. Estos contratos de servicios trasladan
el problema de los errores de hardware a un proveedor, liberando de esta
responsabilidad directa a la Organización. Adjunto se presentan algunas
consideraciones que se deben tener en cuenta cuando se requiera establecer un
contrato de servicios:

- Horario de cobertura.

- Tiempo de respuesta permitido.

- Partes disponibles en stock.

- Presupuesto para los repuestos.

- Equipos cubiertos en el contrato.

La mayoría de los Contratos de cobertura se definen en términos de las horas y

los días durante los cuales se puede enviar un técnico. Algunas de las horas de
cobertura más comunes son:

- Lunes a viernes desde las 09:00 hasta las 17:00

- Lunes a viernes, 12/18/24 horas cada día (con los tiempos de comienzo y de
finalización acordados mutuamente)

- Servicio permanente: 365 días, 7 días a la semana, las 24 horas del día.

Como puede esperarse, el costo de un contrato se incrementa con las horas de

cobertura.

Además de las horas de cobertura, muchos acuerdos de servicios especifican un

nivel de tiempo de respuesta. Es decir, cuando se realiza una llamada pidiendo un
servicio, ¿cuál es el tiempo que debe esperar hasta que llegue un técnico?

Es claro que la disponibilidad de los repuestos cumple un rol importante en limitar

la exposición de la organización a errores de hardware. En el contexto de un
acuerdo de servicio, la disponibilidad de las partes toma otra dimensión, pues no
solamente aplica a su organización, sino también a otros clientes del proveedor
que pueda necesitar repuestos similares. El nivel de disponibilidad de los
repuestos debe estar claramente determinado en el Contrato de servicios.

7.3.3. Fallas de Sistema Operativo

En este tipo de falla, el sistema operativo es responsable por la interrupción del
servicio. Las fallas del sistema operativo pueden ser:

- Caídas del sistema

- Bloqueos o Inhibiciones.

Estas fallas ocurren cuando el sistema operativo experimenta una condición de

error desde la cual no se puede recuperar. Las razones de las caídas pueden
variar desde una incapacidad para manejar un problema de hardware hasta un
error en el código a nivel del kernel. Cuando un sistema operativo falla, se debe
reiniciar el sistema para poder continuar la producción.

7.3.4. Fallas del Servidor de Bases de datos

Si el DBMS no está operacional, no es posible acceder a la información. Las fallas
del DBMS pueden ocurrir por las siguientes causas:

- Inestabilidad debido a una falla de la versión del DBMS.

- Problemas en la aplicación de nuevos parches del DBMS.

- Los recursos que el DBMS necesita no están disponibles.

Para evitar este tipo de fallas del DBMS, es recomendable tener instalados los
últimos parches de la versión en producción. Los parches contienen las soluciones
a los problemas conocidos.

7.3.5. Fallas de Seguridad

Los problemas de seguridad son otra causa de indisponibilidad de la información.
Antes de que los datos puedan ser accedidos, directamente por un usuario o por
una aplicación, debe asignarse una autorización de acceso.

Esta tarea es ejecutada por un Administrador de Seguridad o directamente por el

DBA. La asignación de permisos es una tarea crítica que debe realizarse con el
cuidado debido. Adicionalmente, es deseable que se mantenga un inventario de
los permisos asignados.
7.3.6. Corrupción y Pérdida de datos
La corrupción de los datos se refiere a los errores que se producen sobre éstos
durante el almacenamiento, la transmisión o la recuperación, así como durante la
introducción de cambios no deseados a los datos originales.

La pérdida de datos durante el almacenamiento tiene dos grandes causas:

hardware y software defectuoso. Accidentes generales y de desgaste de los
medios de almacenamiento entran en la primera categoría, mientras que en el
software suele producirse debido a los errores en el código.

Ciertos niveles de arreglos de disco RAID tienen la capacidad de almacenar y

evaluar los bits de paridad de datos a través de una serie de discos duros, y
pueden reconstruir los datos dañados a partir de un disco o múltiples discos,
dependiente en el nivel de RAID aplicado.

Si los mecanismos adecuados se emplean para detectar y remediar la corrupción

de los datos, la integridad de los datos se puede mantener.

7.3.7. Problemas de rendimiento

Un problema severo de rendimiento puede ser causa de indisponibilidad de la
información. A pesar de que la base de datos está técnicamente en línea, el
rendimiento pobre hace que los datos no puedan ser consultados adecuadamente.

Los siguientes problemas pueden ser causa de una degradación del rendimiento:

- Corrupción de índices.

- Definición incorrecta o falta de índices adecuados.

- Crecimiento indiscriminado del tamaño de las bases de datos, de forma

imprevista.

- Concurrencia adicional de usuarios no contemplados.

- Objetos de la base de datos sin actualización de estadísticas.

- Problemas de contención.

El DBA debe tomar acciones preventivas para evitar que este tipo de problemas
se presenten.

7.3.8. Errores del Administrador de Bases de Datos

A diferencia de los operadores de un centro de cómputo, las tareas que el DBA
lleva a cabo a menudo no están basadas en procedimientos documentados. En
consecuencia, el DBA a veces crea trabajo adicional para sí mismo cuando no
tiene cuidado en las tareas que realiza.

La tarea de configuración de un DBMS varía en gran medida: algunas veces se

requiere editar un archivo de texto, mientras que en otras ocasiones se requiere la
ejecución de alguna utilidad de configuración.

El hecho de que estas tareas son manejadas de forma diferente es simplemente

un reto adicional al hecho básico de que cada tarea de configuración requiere un
conocimiento diferente.

Muchas organizaciones implementan algún tipo de proceso de control de cambios,

cuando éstos son producidos. La intención es la de ayudar a los ejecutantes y a
todas las partes afectadas por el cambio, a administrar el proceso de cambio y
reducir la exposición de la organización a cualquier error que pueda ocurrir.

Un proceso de control de cambios normalmente desglosa el cambio en pasos

diferentes, tales como los siguientes:

- Investigación previa: La investigación previa persigue definir con claridad lo

siguiente:

- La naturaleza del cambio que se realizará.

- Impacto, si el cambio es exitoso o fallido.

- Acciones de retroceso, por si el cambio falla.

- Una evaluación de los tipos de errores que pueden presentarse.

La investigación previa puede sugerir el hecho de probar el cambio propuesto

durante el tiempo planificado fuera de servicio, o puede ir tan allá como para incluir
la implementación del cambio primero en un ambiente de prueba especial,
ejecutándose en un hardware dedicado para las evaluaciones.

- Planificación: La planificación incluye una descripción de la secuencia y tiempo

del cambio, así como también asegurarse de que el tiempo asignado para los
cambios es suficiente y no entra en conflicto con ninguna otra actividad.

El producto de este proceso a menudo es una lista de verificación de pasos

(checklist) para que la use el ejecutante mientras está llevando a cabo el cambio.
Junto con cada paso están las instrucciones a realizar para cancelar el cambio y
volver al estado anterior, en caso de que falle el paso. A menudo se incluyen los
tiempos estimados, para que el ejecutante determine si el trabajo está dentro de la
planificación o no.

- Ejecución: En este punto, la ejecución real de los pasos necesarios para

implementar el cambio debe ser directa. El cambio es implementado o se cancela,
si ocurren errores.

- Supervisión: Bien sea que se implemente el cambio o no, se monitorea el

ambiente para asegurarse de que todo está funcionando como debería.

- Documentación: Si se implementa el cambio, toda la documentación existente

se actualiza para reflejar la configuración modificada.

7.4. Aseguramiento de la
disponibilidad
Con el objetivo de asegurar la disponibilidad de la información el DBA debe
implementar políticas que incluyen los siguientes pasos:

- Implementación de procesos de mantenimiento, cuando los sistemas están

operativos.

- Automatizar las tareas administrativas del DBA.

- Explorar las tecnologías de Alta disponibilidad del DBMS.

7.4.1. Mantenimiento
Las principales tareas de mantenimiento que ejecuta el DBA son:

- Reorganización de los objetos de la Base de datos.

- Tareas de respaldo.

- Pruebas de restauración de respaldos.

- Actualización de estadísticas de los objetos.

- Chequeos de integridad de los objetos.

- Asignación de espacio en disco para las Bases de datos.

La ejecución de estas tareas de forma pro-activa es fundamental para asegurar la

disponibilidad y el rendimiento de las Bases de datos. Adicionalmente, debe
garantizarse que la ejecución de las tareas no afecte a los usuarios, por lo que
deben realizarse en los horarios en los que la afectación sea nula, o por lo menos
mínima.

7.4.2. Tareas automáticas

Automatizar los procesos de mantenimiento que ejecuta el DBA incrementa de
forma significativa el rendimiento de las Bases de datos. Cuando es implementada
de forma adecuada, una tarea automática falla con menos frecuencia que una
tarea manual.

Es recomendable documentar los procesos de mantenimiento, con el fin de

estudiar la factibilidad de automatizarlos a través de scripts que se ejecuten
mediante tareas programadas. La calendarización de las tareas debe realizarse
tomando en cuenta los horarios adecuados para que la ejecución del proceso no
afecte a los usuarios.

Adicionalmente, cuando se automatice un proceso, es necesario

implementar una alerta o reporte de ejecución, para monitorear si la tarea se
ejecutó de forma exitosa, o para tomar correctivos, si la tarea falló.

7.4.3. Alta disponibilidad

La Alta disponibilidad (High availability) es un protocolo de diseño del sistema y su
implementación asociada en el DBMS, que asegura un cierto grado absoluto de
continuidad operacional durante un período de medición dado.

Los diseños de alta disponibilidad se implementan para garantizar la disponibilidad

de la información durante dos tipos de inactividad:

- Tiempo de inactividad planificado: Los eventos que generan tiempos de

inactividad planificados incluyen parches al software del DBMS que requieran un
reinicio o cambios en la configuración que toman efecto después de un reinicio. En
general el tiempo de inactividad planificado es usualmente el resultado de un
evento lógico o de gestión iniciado.

- Tiempo de inactividad no planificado: Surgen de algún evento físico o lógico que

afecta la disponibilidad.

Los proveedores de DBMS's incluyen en sus productos características de Alta

disponibilidad, que se adaptan a la infraestructura disponible en las
organizaciones.
 Bibliografía

[1] HANSEN G.; HANSEN J. (2004). Diseño y Administración de Bases de datos

(Segunda Edición). Madrid: Prentice Hall.

[2] MANNINO M. V. (2007). Administración de bases de datos: Diseño y Desarrollo

de aplicaciones (Tercera Edición). México: McGraw-Hill.

[3] MULLINS C. (2005). Database Administration. The complete Guide to Practices

and Procedures (Cuarta Edición). Indianapolis: Addison Wesley.

[4] ROB P.; CORONEL C. (2003). Sistemas de Bases de Datos: Implementación y

Administración (Segunda Edición). Madrid: International Thomson Paraninfo.

[5] SUMATHI S.; ESAKKIRAJAN S. (2003). Fundamentals of Relational Database

Management Systems (Tercera Edición). Tamil Nadu: Springer.

[6] ZORRILLA H. (2006). La Gerencia del Conocimiento y la Gestión tecnológica.

Enlace Web:
http://www.gestiopolis.com/recursos/documentos/fulldocs/ger/kmtmuch.htm.
[Leído: 3 de Mayo del 2009, 10:00 h GMT -5].