Presentacin de la asignatura

Justificacin

La informacin es el centro de las actividades de nuestros tiempos. Las

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

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

disear y edificar sistemas de datos y de bases de datos correctos y completos en
trminos de las exigencias y estndares de la Ingeniera de Software y las buenas
prcticas.

Descripcin de la asignatura

En los captulos de la asignatura se abordan varios aspectos esenciales para la

gestin de Bases de Datos y Recursos de Informacin:

- Se revisan las caractersticas de la Informacin, La Gestin del Conocimiento y

La informacin como recurso principal de las Organizaciones.

- Se define la Administracin 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

Instalacin, los tipos de actualizaciones y la definicin de estndares requeridos
en un ambiente de Bases de datos.

- Se describen los componentes de un Modelo de Datos, las fases del Diseo de

Bases de datos y el Proceso de Normalizacin.

- Se realiza una descripcin del lenguaje SQL, el control de transacciones y

bloqueos.
- Se define la Integridad semntica 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 informacin.

Objetivos

Objetivo general

La asignatura tiene como objetivo general realizar una introduccin a los

conceptos y soluciones que un Administrador de Tecnologas de la Informacin
debe conocer para lograr una gestin adecuada de la informacin en su
Organizacin como parte de un proyecto de Ingeniera de Software.

Objetivos especficos

- Identificar la necesidad de las organizaciones de gestionar adecuadamente su

informacin.

- Describir adecuadamente el mbito de trabajo del DBA.

- Indicar la forma adecuada de gestionar la instalacin 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
informacin libre de errores.

- Identificar los riesgos que tienen los Sistemas de almacenamiento de

informacin, as como su mitigacin.

Organizacin del contenido y estructura del documento

A continuacin se hace una presentacin resumida de los contenidos junto a sus

objetivos especficos y a su valor aadido en el contexto de la asignatura:

CAPTUL OBJETIVOS RESUMEN DEL CAPTULO APORTACIN Y

O RESULTADO
CONSEGUIDO
Captulo 1 Identificar la Revisin de las Se reconoce el impacto
necesidad de las caractersticas de la de la gestin adecuada
 organizaciones de Informacin, La Gestin del de la informacin en las
gestionar Conocimiento y La organizaciones.
adecuadamente su informacin como recurso
informacin. principal de las
Organizaciones.
Captulo 2 Describir Definicin de la Se identifican las tareas
adecuadamente el Administracin de Bases de especficas que debe
mbito de trabajo del Datos, los tipos de DBA, las tener un DBA, para
DBA. tareas del DBA y su mbito distinguirlo de otros
en las organizaciones. miembros de un equipo
de IT.
Captulo 3 Indicar la forma Indicacin de las Se reconoce que un
adecuada de gestionar consideraciones para DBMS debe ser escogido
la instalacin de un escoger un DBMS, las fases en base a criterios
DBMS. de una Instalacin, los tipos tcnicos, por el personal
de actualizaciones y la de IT de la organizacin.
definicin de estndares
requeridos en un ambiente
de Bases de datos.
Captulo 4 Definir el proceso de Descripcin de los Se identifican los factores
Modelamiento de componentes de un Modelo crticos del modelamiento
datos. de Datos, las fases del de datos y su influencia
Diseo de Bases de datos y en la estructura de la
el Proceso de informacin
Normalizacin. organizacional.
Captulo 5 Definir los elementos Descripcin del lenguaje Se reconocer al DBA
de las Aplicaciones SQL, el control de como promotor de las
que tienen incidencia transacciones y bloqueos. buenas prcticas de
en el rendimiento de programacin utilizando
las Bases de datos. Bases de datos, para
asegurar el correcto
rendimiento de las
aplicaciones.
Captulo 6 Definir las condiciones Definicin de la Integridad Se reconoce la integridad
que deben asegurar semntica y estructural, as de la informacin como
los DBMS para como los mecanismos para un factor crtico de la
mantener la su control. gestin de Bases de
informacin libre de datos.
errores.
Captulo 7 Identificar los riesgos Definicin del Downtime, los Se reconoce la criticidad
que tienen los problemas comunes de de la disponibilidad de los
Sistemas de disponibilidad, y los DBMS's para el desarrollo
almacenamiento de mecanismos para el de las actividades de las
informacin, as como aseguramiento de la organizaciones.
su mitigacin. informacin.
Captulo 1.- Gestin Tecnolgica de la Informacin
 OBJETIVOS
- Definir la Informacin como recurso estratgico de las organizaciones.
- Identificar las caractersticas y funciones de la Informacin.
- Identificar los principios de la Gestin del conocimiento.
1.1. Introduccin

En nuestros das, que vivimos en un mundo globalizado, con alta incertidumbre y

competencia, la gestin de la informacin se ha convertido en elemento que sirve
para marcar diferencias y lograr ventaja competitiva. En este sentido, las
Tecnologas de la Informacin ofrecen herramientas propicias para salvaguardar el
conocimiento.

El objetivo general de los Sistemas de Gestin de base de datos (DBMS, por sus
siglas en ingls) es el de administrar de forma clara, sencilla y ordenada un
conjunto de datos que en lo posterior se convertirn en informacin relevante para
una organizacin.

Los DBMS's son la herramienta de software ms idnea para manejar informacin

debido a que cumplen los siguientes objetivos:

- Abstraccin de la informacin: los DBMS's abstraen a los usuarios de detalles

acerca del almacenamiento fsico 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 fsico o lgico 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 informacin siempre obtendrn el mismo resultado.

- Seguridad: la informacin 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 informacin almacenada. Los DBMS's
proveen elementos para garantizar la recuperacin de la base de datos hasta el
ltimo estado consistente conocido, de forma automtica.
- Respaldo: los DBMS's proporcionan una manera eficaz de realizar copias de
respaldo de la informacin 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 ms habitual

es que sean muchas las personas que intentan ingresar a una base de datos,
tanto para recuperar informacin, como para guardarla o modificarla. Y es tambin
frecuente que dichos accesos se realicen de forma concurrente. As pues, un
DBMS debe controlar este acceso simultneo a la informacin, que podra dar
lugar a inconsistencias.

- Manejo de Transacciones: una Transaccin es un programa que se ejecuta como

una sola operacin. Esto quiere decir que el estado luego de una ejecucin en la
que se produce un error es el mismo que se obtendra 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 ms simple que si
no se dispusiera de ellos.

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

darnos la informacin requerida, y en guardar los cambios realizados.

1.2. La informacin

La informacin proporciona significado y sentido a las cosas, e indica mediante

cdigos y grupos de datos, los modelos del pensamiento humano. La informacin
permite generar el conocimiento. Aunque otros seres vivos son capaces de
comunicarse transmitiendo informacin para su supervivencia, los seres humanos
en su capacidad de generar y perfeccionar cdigos y smbolos 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
comunicacin.

La informacin es un grupo organizado y coherente de datos procesados, que

constituyen un mensaje sobre una determinada entidad o fenmeno. Cuando
tenemos que resolver un problema o hay que tomar una decisin, se emplean
diferentes fuentes de informacin, y se construye lo que en general se denomina
conocimiento o informacin organizada, que permite resolver problemas o tomar
decisiones.

Los datos se renen de fuentes diversas, y mediante su procesamiento se crea la

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

1.2.1. Caractersticas de la Informacin

La informacin tiene las siguientes caractersticas:

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

- Su importancia es relativa en quien la recibe.

- Tiene vigencia en la dimensin espacio-tiempo.

- Tiene valor intrnseco.

- Polimorfismo.

1.2.2. Funciones de la Informacin

La generacin y obtencin de informacin 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 eleccin final.

- Proporcionar reglas de evaluacin y decisin con fines de control.

La Informacin, como va para llegar al Conocimiento, tiene que ser elaborada

para ser utilizada y estar disponible. Este procedimiento se llama Documentacin,
y cuenta con mtodos y herramientas propios.
1.3. La Gestin del Conocimiento

A partir de los aos Ochenta, las Organizaciones empezaron a darse cuenta de la

importancia de su informacin y de tratar de lograr la mejor gestin de este
conocimiento. El conocimiento es reconocido como el activo ms valioso de la
Organizacin, como el nico recurso econmico significativo y por lo tanto se
hacen esfuerzos por definir formas de adquirirlo, representarlo, retenerlo y
administrarlo.

Dentro del objetivo de la administracin y gerencia del conocimiento est lo que la

organizacin sabe sobre sus productos, procesos, mercados, clientes, empleados,
y sobre el cmo combinar estos elementos para lograr que una Organizacin sea
competitiva. En este aspecto, esta disciplina parece replicar al propsito de la
Gestin Tecnolgica de la Organizacin, pero por ser de mayor alcance parece
contenerla.

1.3.1. Ventajas competitivas del Conocimiento en la Organizacin

El desafo de aplicar el conocimiento en una Organizacin para crear ventajas

competitivas se hace an ms importante debido a:

- El mercado se vuelve cada vez ms competitivo, por lo que se demanda mayor

innovacin en los productos y servicios. El conocimiento debe desarrollarse y ser
asimilado con mayor velocidad.

- Las Organizaciones estn enfocando sus esfuerzos en lograr mayor valor

agregado para sus clientes. Las funciones del personal administrativo se han ido
reduciendo, as como tambin los mismos niveles de administracin. Existe la
necesidad de sustituir la manera informal de manejar el conocimiento en las
funciones administrativas por mtodos cientficos, dentro de procesos de negocios
con orientacin al cliente.

- La presin de la competencia reduce el tamao de los grupos de colaboradores

que poseen el conocimiento de la organizacin.

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

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 pequeas,
medianas y transnacionales.

- Los cambios en la Direccin estratgica de la organizacin pueden causar

prdida de conocimiento en un rea especfica. Una decisin posterior que retome
la anterior orientacin puede necesitar ese conocimiento, pero el funcionario que
lo posee puede ya no estar en la organizacin.

1.3.2. Principios de la Gestin del Conocimiento

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

gerencia del conocimiento desde un punto de vista pragmtico al describir diez
principios generales para la Gestin del conocimiento. Una vez que una
organizacin 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 gestin

efectiva requiere inversiones en otros activos, principalmente en Tecnologa.

2. La gerencia efectiva del conocimiento requiere soluciones hbridas de personal

y tecnologa: pese a los avances de la Informtica, no puede decirse an que se
tenga una computadora que pueda reemplazar a los humanos por completo. Los
hechos comprueban que las organizaciones que desean una efectiva gestin 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 gestin del conocimiento es altamente poltica: no resulta un secreto que el

conocimiento es poder y por lo tanto, no es una sorpresa que la gestin del
conocimiento tenga un trasfondo altamente poltico. Si el conocimiento est
asociado con el poder, el dinero y el xito, entonces tambin est asociado con las
intrigas y tratos velados que tienen lugar en las organizaciones.

4. La gestin del conocimiento requiere gerentes del conocimiento: los recursos

primarios de un negocio como el trabajo y el capital, tienen funciones
organizacionales dedicadas a su administracin y gerencia. El conocimiento no
puede ser bien administrado hasta que algn grupo en la organizacin 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
utilizacin.
5. La gestin del conocimiento brinda ms beneficios a partir de mapas que a
partir de modelos, ms a partir de mercados que a partir de jerarquas.

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

7. La Gestin del conocimiento implica mejorar los procesos del negocio que se
basan en conocimiento: es primordial dar direccin y mejorar el proceso genrico
de la gestin del conocimiento, pero se debe hacer donde el conocimiento es
generado, utilizado y compartido con intensidad, en la organizacin.

8. El acceso al conocimiento es slo el principio: el acceso es muy importante,

pero la gestin exitosa del conocimiento tambin requiere control y compromiso.
Se dice que el control es el dinero efectivo de la era de la informacin.

9. La gestin 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 gestin del conocimiento requiere un contrato de conocimiento: es probable

que en muchas organizaciones no se sepa con certeza quin es el dueo o quin
tiene el derecho de uso del conocimiento de sus funcionarios.

1.4. La Informacin como recurso

A fines de los aos Sesenta, los sistemas de computacin cambiaron el paradigma

del procesamiento de los datos por el del procesamiento de la informacin. Este
cambio reflej una conciencia de que la informacin era mucho ms que simples
archivos relacionados con el negocio. Poco a poco en las Organizaciones
comenzaron a darse cuenta del valor de la informacin y del enorme potencial que
los Sistemas informticos representaban para organizar y administrar este
recurso.

En los aos siguientes, el impacto trascendental que tuvo la informacin sobre la

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

Debido a que en las Organizaciones es comn trabajar con Activos tangibles cuyo
valor puede ser medido con mucha precisin, ha sido muy complicado determinar
el valor de la informacin. Sin embargo est claro que si los directores tienen
informacin adecuada, es ms 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 informacin
correcta y oportuna, frente al almacenamiento en Sistemas de Archivo que era
utilizado entonces.

A pesar de la introduccin 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 manipulacin de datos.

- Esfuerzo excesivo de programacin.

1.5. Los Sistemas de Gestin de Bases de Datos

Los Sistemas de Gestin de Bases de Datos (DBMS, por sus siglas en ingls)
superaron las limitaciones que tenan 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 dcadas de largo esfuerzo por

desarrollar DBMS's cada vez ms poderosos.

.5.1. Evolucin de la Arquitectura de los DBMS's

Las bases de datos aparecieron a finales de la dcada de 1960, cuando surgi la

necesidad de contar con un sistema de administracin de informacin flexible.
Existen cinco modelos de DBMS's, que se distinguen segn cmo representan los
datos almacenados:

- El modelo jerrquico: los datos se organizan de forma jerrquica, mediante un

rbol invertido. Este modelo utiliza punteros para navegar por los datos
almacenados. Este fue el primer modelo DBMS.
 Figura 1.2: Modelo Jerrquico.

- El modelo de red: al igual que el modelo jerrquico, 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 segn la teora relacional.
 Figura 1.4: Modelo Relacional.

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

- El modelo de orientacin 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 Orientacin a Objetos.

Captulo 2.- Definicin del trabajo del administrador de Bases de Datos

OBJETIVOS
- Establecer la estructura y funciones adecuadas para el trabajo del personal que maneja
informacin en las organizaciones, separando los factores tcnicos y de negocio.
- Revisar las tareas comunes de los DBA's, dependiendo de su orientacin.
2.1. Introduccin
Toda organizacin que utilice una Base de datos para organizar su informacin,
requiere de un grupo de Administracin para asegurar su adecuado
funcionamiento. A pesar de esto, la Administracin de Bases de datos no siempre
es practicada adecuadamente, para lograr resultados ptimos.

Un Administrador de Bases de Datos (DBA, por sus siglas en ingls) es un tcnico

informtico responsable de asegurar la funcionalidad operativa de las Bases de
datos de una organizacin, con el objetivo de que las aplicaciones trabajen
correctamente. En este captulo revisaremos el alcance del trabajo del DBA.

2.2. Administracin de Bases de Datos, Datos y Sistema

La tendencia en las organizaciones es separar en roles diferentes los aspectos

tcnicos y de negocio de la informacin. Los aspectos de negocio estn ligados a
la administracin de la informacin (cmo se obtiene la informacin, su flujo,
usuarios), mientras que los aspectos tcnicos se relacionan con la administracin
de las Bases de datos. Pero en la actualidad, solamente algunas grandes
organizaciones tienen estructuras funcionales para la administracin de la
informacin, por lo que generalmente se mezclan las funciones dentro del rol de
Administracin de Bases de datos.

2.2.1. Administracin de Datos

La Administracin de los Datos separa los aspectos de negocio de los aspectos

tcnicos, con relacin a la informacin.

Un Administrador de datos conoce la informacin y las necesidades de la

empresa, en un nivel gerencial superior. Su labor es decidir en primer trmino
cules datos deben almacenarse en la Base de Datos, y establecer polticas para
mantener y manejar los datos una vez almacenados. El perfil debe ser
principalmente de gestin antes que tcnico, aunque s se necesita apreciar las
posibilidades de los sistemas de Bases de Datos en un nivel tcnico.

Las principales tareas del Administrador de Datos son:

- Identificar y clasificar los requerimientos de informacin de los usuarios.

- Producir los modelos de datos conceptuales y lgicos, de acuerdo a los Procesos

de Negocio de la organizacin.
- Creacin y mantenimiento del Modelo corporativo de Informacin que considera
todos los Procesos de Negocio.

- Establecer la Poltica de acceso a la Informacin.

- Identificar a los Dueos de la informacin y a sus Usuarios.

- Establecer los estndares de control de datos.

Como se ha mencionado la Administracin de los Datos debe manejarse a nivel

ejecutivo. Lastimosamente, cuando esta tarea recae sobre personal tcnico, se
falla en concentrar los aspectos no tecnolgicos de la informacin, debido a los
siguientes aspectos:

- Las tareas para asegurar tcnicamente 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 posicin ejecutiva suficiente para la disposicin de polticas

que sean acatadas por toda la organizacin.

- El personal tcnico, por lo general, no cuenta con las habilidades de

comunicacin necesarias para transmitir ideas y lograr consensos.

Cuando los dos roles estn separados en la organizacin en estructuras

funcionales diferentes, los grupos deben trabajar en conjunto. No es necesario que
tengan un mismo Gerente, pero esto podra facilitar la comunicacin.

2.2.2. Administracin 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 tcnicos necesarios para apoyar las polticas
dictadas por el Administrador de Datos. Se encarga tambin de garantizar el
funcionamiento adecuado del sistema y de proporcionar otros servicios de ndole
tcnica relacionados. Dependiendo de la organizacin el rol lo pueden compartir
una persona o un equipo.

El DBA debe entender los modelos de datos desarrollados por la Administracin

de Datos. El modelo lgico es el mapa con el cual se crearn fsicamente las
bases de datos, teniendo en cuenta las caractersticas especficas de del DBMS
utilizado en la organizacin.
 Figura 2.1: Administrador de Datos y Administrador de Bases de datos.

2.2.3. Administracin de Sistema

Si el tamao de la organizacin lo requiere, se debe contar con un Administrador

de Sistema, para controlar la operacin del Equipo y Sistema Operativo en donde
est instalado el DBMS.

A los Administradores de Sistema se les encomienda la instalacin, soporte y

mantenimiento de los servidores u otros sistemas de cmputo, la planeacin de
respuesta a contingencias y otros problemas. Algunas otras responsabilidades
pudieran incluir la programacin de scripts o programacin de tareas
administrativas, manejo de proyectos relacionados con el sistema, supervisin o
entrenamiento de operadores de cmputo y ser el consultor para los problemas
que se encuentran ms all del conocimiento tcnico del personal de soporte.

2.3. Tareas del Administrador de Bases de Datos

Las principales tareas del DBA son:

- Diseo de Bases de datos

- Monitoreo y Afinamiento

- Asegurar la disponibilidad de las Bases de datos

- Seguridad

- Respaldos

- Integridad de datos

2.3.1. Diseo de Bases de Datos

Los diseadores entrevistan a los futuros usuarios de la base de datos para

recoger y documentar sus necesidades de informacin. En forma paralela, es
conveniente definir los requerimientos funcionales que consisten en operaciones
que se aplicarn 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 descripcin detallada
de los requerimientos de informacin que poseen los usuarios, y contiene
descripciones de los tipos de datos, relaciones entre ellos y restricciones. Para el
diseo de esquemas conceptuales es muy utilizado el Modelo E-R (entidad
relacin), que describe los datos como entidades, que tiene vnculos (relaciones) y
atributos.

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

Fsico, de acuerdo a las caractersticas 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 slo uno de los elementos que determinan la experiencia de los usuarios
en lnea, 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 operacin. Es recomendable contar con herramientas que
cuenten con las siguientes caractersticas:

- Indicadores de rendimiento: CPU, Memoria y Disco.

- Identificacin de Usuarios Activos y Usuarios bloqueados por contencin.

- Capacidad de identificar segmentos de cdigo con problemas.

- Almacenamiento de planes de ejecucin.

- Almacenar historias de rendimiento.

- Disponer de Informes de Gestin.

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

combinacin de transacciones en lnea, 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 da. Las sobrecargas son el factor que ms afectan al
rendimiento.

2. Throughput: este trmino define a la capacidad del Servidor para procesar

datos, en trminos 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. Optimizacin: se refiere al anlisis de los requerimientos de bases de datos

para determinar el costo de una consulta, y proceder as a generar planes de
ejecucin adecuados para acceder a los datos. Los principales factores a ser
optimizados son las Consultas SQL, parmetros de configuracin de la Base de
datos, y una programacin eficiente.

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

encuentran comprometidos todos los recursos, se genera una situacin de
Contencin. Durante una contencin dos transacciones estn en conflicto por un
recurso.

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

de Datos puede lograrse con la optimizacin de los recursos usados, para
incrementar el throughput y minimizar la contencin. As se permite que la carga
sea procesada de forma eficiente.
Cuando se encuentran problemas de rendimiento en una aplicacin 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 tcnicos 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 cachs de datos y procedimientos.

- Alinear la implementacin de las Bases de Datos con la infraestructura de IT

existente.

- Monitorear constantemente las Bases de datos y Aplicaciones.

- Implementar procedimientos de reorganizacin de Bases de datos.

- Implementar procedimientos de actualizacin de estadsticas 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 informacin est disponible
todo el tiempo (7x24, o siete das a la semana, 24 horas del da).

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 afectacin 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 afectacin al servicio, deben ser coordinadas en horarios en que
no se involucre al desempeo 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 polticas del negocio. Es responsabilidad del DBA que la
informacin est disponible solamente para usuarios autorizados.

La administracin de la seguridad en las Bases de Datos comprende los permisos

para la ejecucin de las siguientes tareas:

- Creacin de objetos como bases de datos, tablas, vistas y procedimientos

almacenados.

- Alteracin de la estructura de los objetos de bases de datos.

- Acceso a las tablas de sistema.

- Consulta y modificacin de los datos en las tablas.

- Creacin de funciones y tipos de datos.

- Ejecucin de procedimientos almacenados.

- Cambiar el estatus de las Bases de Datos: en lnea y fuera de lnea.

- Cambiar parmetros de configuracin.

- Ejecutar tareas de respaldo, recuperacin y otras administrativas.

2.3.5. Respaldos y Recuperacin

Que una Base de datos pueda ser recuperada implica que si se da algn 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 dao se
causara. Las actividades de recuperacin incluyen el hacer respaldos de la base
de datos y almacenar esos respaldos de manera que se minimice el riesgo de
dao o prdida de los mismos, tales como hacer diversas copias en medios de
almacenamiento removibles y almacenarlos fuera del rea en antelacin a un
desastre anticipado. La recuperacin es una de las tareas ms importantes de los
DBA's.

La recuperacin de desastres tiene dos componentes:

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

- Las pruebas de recuperacin: Constantemente se deben ejecutar pruebas de
recuperacin, para determinar si los respaldos se estn obteniendo de forma
adecuada. Si el DBA intenta implementar un plan de recuperacin de bases de
datos sin pruebas de recuperacin, no existe la certeza de que los respaldos sean
del todo vlidos.

2.3.6. Integridad de datos

La Integridad de datos se refiere al estado de correccin 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 tambin puede verificarse inmediatamente antes del
momento de introducir la informacin a la base de datos.

2.4. Tipos de Administradores de Bases de Datos

Dependiendo de la experiencia y de la orientacin de los DBA's, es comn que se

impongan las siguientes especializaciones:

- DBA's especializados en diseo lgico.

- DBA's especializados en diseo fsico.

- 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 pequeas un solo DBA debe ejecutar todos los
roles.

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

2.4.1. Administrador de Bases de Datos de Sistema

El DBA de Sistema se enfoca ms en la parte tcnica que en las regla de negocio,

principalmente en la Administracin de Sistema. Sus tareas se centran en la
instalacin y rendimiento del DBMS:
- Instalar nuevas versiones del DBMS y aplicar los parches liberados por el
proveedor.

- Establecer los parmetros de configuracin.

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

- Administrar los sistemas de almacenamiento para el DBMS.

- Administrar tecnologas relacionadas con las Bases de datos.

- Instalar las herramientas de administracin y monitoreo de Bases de Datos.

2.4.2. Arquitecto de Datos

Algunas organizaciones crean una funcin separada para el diseo e

implementacin de Bases de Datos: el Arquitecto de Datos. Este tipo de DBA se
dedica solamente a los nuevos diseos y desarrollos, no interviene en la
administracin de Bases de Datos de Produccin.

Sus tareas incluyen:

- Creacin de modelos lgicos.

- Trasladar los modelos lgicos a modelos fsicos.

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

adecuados.

- Analizar el acceso a datos y los requerimientos de modificacin, para generar

consultas SQL eficientes.

- Crear estrategias de respaldo y recuperacin para las nuevas Bases de datos.

2.4.3. Administrador de Bases de Datos de Aplicacin

El DBA de aplicacin se centra en el diseo de Bases de Datos y en el soporte y

administracin de aplicaciones especficas.

El DBA de Aplicacin se enfoca en el diseo 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
prcticas para incorporar los requerimientos funcionales de las aplicaciones en
una base de datos. El DBA de Aplicacin debe tambin conocer la configuracin
del motor de bases de datos y otros roles del DBA de sistema.

El trabajo del DBA de Aplicacin es determinante en el rendimiento de las

aplicaciones, pues conoce el detalle de las consultas SQL y su correcta aplicacin
en la base de datos. El DBA de Aplicacin analiza las consultas y realiza las
sugerencias apropiadas de cambios, tanto en el cdigo como en la configuracin
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 tecnologas de conexin hacia las bases de

datos.

- Conocimiento intermedio de Administracin 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 diseo 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 estndar de conexin hacia las bases de datos.

- Custodiar los modelos de datos.

- Revisin y anlisis de los procedimientos almacenados con problemas de

rendimiento.

2.5. El Administrador de Bases de Datos en la Organizacin

2.5.1. Cuntos Administradores de Bases de Datos tener?

Es importante para una organizacin determinar el nmero de DBA's que debe

tener.

Esta decisin depende de varios factores:

- Nmero de Bases de datos.

- Tamao de las Bases de datos.

- Nmero de usuarios.

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

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

organizacional

Las organizaciones difieren en cuanto a la ubicacin del DBA dentro de la

estructura organizacional del Departamento de IT. Esta ubicacin depende del tipo
de organizacin.
Cuando una organizacin entiende la importancia de la informacin, ubica al staff
de Administracin de Informacin en una posicin estelar. Es recomendable que
este Grupo de Administracin de Recursos de Informacin reporte directamente al
Gerente de IT:

Figura 2.2: El Administrador de Bases de datos en la Estructura Organizacional.

Captulo 3.- Definicin del entorno de Bases de Datos

OBJETIVOS
- Analizar los factores preponderantes para el escogimiento de un DBMS en particular,
dependiendo de las caractersticas y recursos tcnicos de la organizacin.
- Identificar los pasos necesarios para el proceso de instalacin de un DBMS.
- Analizar las ventajas de mantener las versiones actualizadas de un DBMS.
3.1. Introduccin

La instalacin y configuracin del Entorno de Bases de Datos es una de las tareas

ms 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 Tecnologas de la Informacin, y asumen que una
vez instalada la Base de Datos, todo funcionar adecuadamente. En este captulo
se revisarn los principios para una seleccin adecuada.
3.2. Definicin de la Estrategia

En la actualidad, el proceso de escoger un Motor de Bases de Datos (DBMS, por

sus siglas en ingls) adecuado ya no es tan complicado como antes, pues los
proveedores cuentan con opciones conocidas, de acuerdo a los requerimientos.

Es comn que empresas medianas o grandes cuenten con ms de dos DBMS's,

para soportar sus diferentes aplicaciones o infraestructura:

- Si la empresa cuenta con Mainframes, podra usar DB2 o Informix.

- En los Servidores Unix, podra utilizar Oracle, Sybase, Informix.

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

- Si adicionalmente se gestiona informacin 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: Quin decide el DBMS a utilizar y
en qu momento?

A veces la decisin de adquirir un nuevo DBMS es dirigida por un requerimiento

del negocio o por una nueva aplicacin. Esto sera sencillo si la empresa est
adquiriendo su primer DBMS, pero este no es un caso comn. A pesar de que ya
exista un DBMS en la organizacin, se suele adquirir otro para una nueva
aplicacin, sin verificar que sta funcione adecuadamente en el DBMS existente.

Una vez que el Servidor de Bases de Datos es instalado, un proceso de remocin

siempre es complicado, pues es necesario realizar cambios en el cdigo 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 administracin.

El DBA debe emitir un informe tcnico para asesorar la adquisicin de un

determinado DBMS, y este informe debe ser considerado por los directivos para
tomar la decisin final. Slo de esta manera se asegura que la decisin sea
determinada por motivos tcnicos, principalmente.
3.2.1. Escogiendo un DBMS

Todos los proveedores lderes de DBMS's por lo general ofrecen las mismas
caractersticas en sus productos. Si un proveedor en particular lanza una
caracterstica nueva, los otros no tardan en incorporarla, probablemente en menos
de dos aos.

Algunos proveedores principales de DBMS's son:

Proveedor Producto Plataformas compatibles

Oracle Oracle Database Apple Mac OS X Server
HP HP-UX
HP Tru64 UNIX: Alpha
HP OpenVMS
IBM AIX5L
IBM z/OS: zSeries
Linux
Microsoft Windows
Sun Solaris
IBM Informix Apple Mac OS X Server
DB2 HP HP-UX
HP Tru64 UNIX: Alpha
HP OpenVMS
IBM AIX5L
IBM z/OS: zSeries
Linux
Microsoft Windows
Sun Solaris
IRIX
IBM OS/2
Microsoft SQL Server Windows
Sybase Adaptive Server Enterprise Asianux
Adaptive Server Anywhere HP HP-UX
HP Tru64 UNIX: Alpha
IBM AIX5L
Linux
Microsoft Windows
Sun Solaris
Teradata Teradata Database HP-UX
IBM AIX5L
IBM z/OS: zSeries
Linux
Microsoft Windows
Sun Solaris
Tabla 3.1. Principales Proveedores de DBMS's.
Adicionalmente, siguiendo la tendencia del Cdigo Abierto, podemos nombrar a
las principales DBMS's de uso libre:

- MySQL

- PostgreSQL

- Ingres

- Firebird

El Grupo de Administracin de Bases de Datos debe contar con una poltica de

adquisicin de DBMS's, considerando la infraestructura de la organizacin. Esta
poltica debe procurar mantener el nmero DBMS's diferentes en el mnimo
posible: mientras mayor sea este nmero, el esfuerzo de administracin y los
conocimientos necesarios sern mayores.

Las consideraciones necesarias para la adquisicin de un DBMS son:

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

posee la organizacin? El proveedor planea dar mantenimiento a las siguientes
versiones que se lanzarn en el futuro?

- Tipo de Organizacin: se debe tomar en cuenta la cultura organizacional. Las

empresas con una tendencia conservadora tendern 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 misin 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 organizacin?

- Escalabilidad: El DBMS soporta el nmero de usuarios y el tamao de las

bases de la organizacin?

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

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

- Tcnicos: es necesario verificar si existe, en la organizacin o en el mercado

laboral, el personal tcnico con el conocimiento necesario para dar soporte en el
DBMS a implementar. Se debe tener en cuenta si el nivel de remuneracin para
este personal es compatible con el nivel adquisitivo de la organizacin.
- Costos: se deben tener en cuenta el valor de las licencias, actualizaciones,
soporte tcnico, administracin.

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

nuevas versiones, tanto para generar nuevas caractersticas, 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
operacin.

3.2.2. Arquitecturas DBMS

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

En los actuales momentos, la infraestructura de Tecnologas de la Informacin

tiende a ser distribuida y heterognea, incluyendo diferentes plataformas y
sistemas operativos. El nivel de arquitectura del DBMS se debe escoger de
acuerdo a la naturaleza de la organizacin y el tipo de procesamiento a
implementar. Los niveles de arquitectura disponibles son:

- Enterprise DBMS: Un DBMS de nivel Empresarial est diseado para ofrecer

Escalabilidad y Alto rendimiento. Debe ser capaz de soportar Bases de Datos de
gran tamao, alto nmero de usuarios concurrentes y mltiples tipos de
aplicaciones ejecutndose simultneamente. Este tipo de servidor de bases de
datos se debe ejecutar sobre Hardware de Gran escala, para poder ofrecer
caractersticas avanzadas como Soporte para multiprocesamiento, Paralelismo y
Clustering.

- Workgroup DBMS: Para empresas medianas y pequeas, los proveedores de

DBMS's ofrecen soluciones de nivel Departamental, en las cuales se suprimen las
caractersticas avanzadas, manteniendo el soporte adecuado para el correcto
desempeo de las aplicaciones, para un nmero limitado de usuarios.

- Personal DBMS: Las bases de datos personales estn diseadas para ser
utilizadas por un usuario en una estacin de trabajo.

- Mobile DBMS: Las bases de datos mviles son una versin especializada de un
DBMS Departamental o Empresarial. Estn diseadas para usuarios remotos que
generalmente no estn conectados a una red local, y pueden ser utilizadas en
dispositivos mviles. Adicionalmente, ofrecen herramientas de sincronizacin de
informacin para actualizar los cambios contra una Base de datos Centralizada de
la organizacin.

Un DBMS diseado para un tipo de procesamiento no puede ser utilizado para un

nivel distinto. Se debe asegurar la comprensin de las diferentes arquitecturas
para realizar una eleccin adecuada. Si la organizacin 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 utilizacin de varias mquinas independientes

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

Existen 2 arquitecturas predominantes para la implementacin 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 lmite al agregar ms mquinas, 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 coordinacin.
 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 informacin. 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 ms 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 dems nodos del cluster.

Si las tareas permiten dividir de forma lgica 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 opcin ms apropiada.

Los clusters con tolerancia a fallos de 2 nodos son los sistemas ms 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. Instalacin del Servidor de Bases de Datos

Una vez que se ha escogido el DBMS, se debe planificar su instalacin. Para
lograr una instalacin exitosa se deben cumplir los pre-requisitos de instalacin y
preparar el entorno.

3.3.1. Pre-requisitos de Instalacin

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

instalacin que indican los requerimientos para que su funcionamiento sea ptimo:

- Asegurarse que la versin del sistema operativo sea la apropiada.

- Verificacin 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
Gua para proceder a la instalacin.

3.3.2. Requerimientos de Hardware

Cada DBMS tiene requerimientos especficos con respecto al CPU, especificando

versiones y nmero de procesadores requeridos para la operacin.
Adicionalmente, algunos proveedores especifican en una "Gua de Compatibilidad"
los modelos de servidores soportados y no soportados.

Los DBMS's estn diseados para explotar al mximo las caractersticas de el

hardware que declaran como compatible. La organizacin 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 informacin 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
administracin de las Bases de Datos de Usuario.
- Archivos de bitcora (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 bsica y atender los procesos que se generan durante la operacin.

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

La lectura desde disco siempre es ms lenta que la lectura desde la memoria, por
lo que la configuracin apropiada del cach de datos es un factor crtico 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
caractersticas como el manejo de los bloqueos, control de los requerimientos de
datos, ordenamiento de la informacin y procesamiento de las consultas.

Debe asegurarse la correcta asignacin de memoria al DBMS, para optimizar el

procesamiento y minimizar los problemas de rendimiento.

3.3.5. Configuracin

A travs de los parmetros de Configuracin, el DBA define la forma de operacin

del DBMS. La configuracin tiene una relacin directa con los recursos
disponibles. Cada DBMS permite que los parmetros sean modificados de
diferentes formas, pero generalmente durante el proceso de instalacin se colocan
valores por defecto.
Una vez que el DBMS est operativo, los parmetros de configuracin pueden ser
modificados, ya sea a travs de comandos, o editando los archivos de
configuracin. Existen adicionalmente consolas de administracin que permiten
realizar los cambios a travs de un entorno grfico e intuitivo. Sea cual fuere la
forma de cambio de los parmetros de configuracin, el proceso debe realizarse
con precaucin y exactitud, pues se afecta directamente a la forma de operacin
del DBMS.

Los principales parmetros de configuracin son:

- Configuracin de la memoria (Cach de datos y programas).

- Nmero de procesadores a utilizar.

- Nmero de objetos abiertos (bases de datos, tablas, ndices).

- Habilitacin de caractersticas 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 caractersticas y el arreglo de los errores reportados por los usuarios.

El DBA debe procurar mantener actualizados los servidores de la organizacin,

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. Versin: un cambio de versin debe realizarse con el cuidado que requerira

una instalacin nueva. Una nueva versin suele incluir cambios radicales en el
funcionamiento interno del DBMS, as como nuevas caractersticas.

2. Release: un release representa una nueva compilacin de los binarios de una

versin de DBMS. En un release se corrigen los errores reportados por los
usuarios, y es posible que se incluyan nuevas caractersticas menores.

3.4.2. Beneficios de la actualizacin del DBMS

Una actualizacin ofrece tanto riesgos como beneficios. El procedimiento de
actualizacin debe minimizar los riesgos, con el fin de que los beneficios sean
aprovechados al mximo.

Los principales beneficios de una actualizacin de DBMS son:

- Los Programadores pueden aprovechar las caractersticas nuevas que se

incluyen en la actualizacin.

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

se reflejan en un mejor desempeo de las aplicaciones.

- Los proveedores alientan la instalacin de actualizaciones para poder ofrecer un

mejor soporte a problemas.

3.4.3. Consideraciones para la actualizacin

A pesar de que una estrategia de actualizacin adecuada pueda maximizar los

beneficios, deben contemplarse las siguientes consideraciones:

- Las actualizaciones requieren suspender la atencin del DBMS. De acuerdo a la

naturaleza de la organizacin, debe planearse la actualizacin en un horario de
mantenimiento adecuado, para minimizar el impacto.

- Antes de implementar la instalacin en Produccin, sta debe ser realizada en

los ambientes de Desarrollo, para que los programadores puedan realizar pruebas
de certificacin 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 caractersticas del DBMS.

- Al terminar el proceso de actualizacin, debe realizarse un chequeo de

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

3.5. Definicin de estndares

Los estndares son definiciones de las mejores prcticas para asegurar la

consistencia y efectividad de un entorno de Bases de Datos. El DBA debe definir
estos estndares como parte de los procedimientos a seguir en el Departamento
de IT.
3.5.1. Convenciones de nombres

El primer estndar a establecer debe ser la gua para nombrar los objetos de las
bases de datos. Sin un estndar es dificultoso identificar correctamente los
nombres de los objetos, tanto para tareas de administracin como de
programacin.

Algunas consideraciones para la definicin de este estndar:

- El nombre de un objetos debe ser lo ms 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 utilizacin de maysculas o minsculas solamente. En lo

posible no es recomendable mezclar caracteres, para evitar errores en
aplicaciones que tengan sensibilidad entre maysculas y minsculas.

- Las palabras pueden separarse con un guin bajo: detalle_factura.

3.5.2. Estndares de Administracin de Bases de Datos

El DBA debe documentar los procedimientos de administracin, para definir el

alcance de su trabajo. Los estndares de administracin de datos incluyen:

- Declaracin de las polticas de informacin de la organizacin.

- Guas para establecer la propiedad de los datos.

- Reglas de creacin de objetos de Base de datos.

- Polticas de administracin de Metadata.

- Guas para el desarrollo de modelos conceptuales, lgicos y fsicos.

- Polticas de permisos de acceso a Bases de datos.

- Polticas de Respaldo y Recuperacin de Bases de datos.

- Poltica de Pases a Produccin.

- Poltica de monitoreo y administracin.

3.5.3. Estndares de Administracin de Sistemas

Los estndares de administracin de Sistemas incluyen:

- Instalacin del DBMS y procedimientos de pruebas.

- Polticas de actualizaciones.

- Consideraciones de interfaces.

- Procedimientos de uso de almacenamiento.

3.5.4. Estndares 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:

- Descripcin de los mtodos de acceso de las Aplicaciones a las Bases de datos.

- Estndares de codificacin SQL.

- Recomendaciones para mejorar el rendimiento de las consultas SQL.

- Gua de interpretacin de los cdigos de errores del DBMS.

3.5.5. Estndares de Seguridad de Bases de Datos

Una definicin de polticas de acceso a las Bases de datos debe incluir:

- Expiracin de clave de usuario.

- Definicin de clave compleja.

- Definicin de los dueos de los objetos.

- Privilegios de acceso del usuario sobre los objetos.

- Privilegios del usuario para realizar tareas administrativas.

Captulo 4.- Modelamiento de Datos

OBJETIVOS
- Introducir el concepto de entidad como una estructura bsica del modelo relacional.
- Identificar los componentes de un modelo de datos.
- Analizar las fases del diseo de Modelos de Bases de datos.
- Analizar las reglas de Normalizacin e identificar cmo se deben aplicar.
4.1. Introduccin

A fines de los aos Sesenta, Edgar Frank Codd introdujo la Teora relacional para
las bases de datos. Este hecho determin un paso trascendental en la
investigacin de los DBMS's, pues se suministr un slido fundamento terico
para su desarrollo, dentro de este enfoque relacional. La teora de Codd propone
un modelo de datos basado en la teora de las relaciones, en donde los datos se
estructuran lgicamente en forma de entidades (tablas), siendo un principio
fundamental del modelo el mantenimiento de la independencia de esta estructura
lgica con relacin al modo de almacenamiento y a otras caractersticas de tipo
fsico.

La teora propuesta por Edgar Frank Codd present un nuevo modelo de datos
que persegua los siguientes objetivos:

- Independencia fsica: la forma en la que se almacenan los datos no influye en

su estructura lgica. Debido a esto, los usuarios que acceden a esos datos no
tienen que modificar sus programas cuando se producen cambios en el
almacenamiento fsico de la informacin.

- Independencia lgica: el aadir, 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 lgicas de la informacin presentan un formato

uniforme, lo que facilita la creacin y manipulacin de la base de datos por parte
de sus usuarios.
- Sencillez: las caractersticas nombradas anteriormente, as como unos
lenguajes de programacin 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 bsica del modelo relacional. Toda la
informacin de la Base de Datos se representa en forma de entidades cuyo
contenido vara con el tiempo.

Con respecto a la parte dinmica 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 bsico 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 estn identificadas por un
nombre. Tambin se distinguen un conjunto de filas llamadas tuplas o registros,
que son las ocurrencias de la relacin, es decir, la informacin que almacena la
tabla.

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

Al nmero de filas de una entidad se lo denomina cardinalidad y el nmero de

columnas es llamado el grado de la entidad.

- Ejemplo: Cliente

Figura 4.2: Ejemplo de Entidad Cliente.

Una entidad (tabla) tiene las siguientes caractersticas:

- 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 relacin de una fila y una columna slo puede
haber un valor (no se admiten atributos con mltiples valores).

4.2.2. Dominio y Atributos

Un dominio es un conjunto delimitado de valores homogneos y atmicos que se

definen con un nombre. Se dice que son homogneos porque todos son del
mismo tipo y atmicos 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 Pas es un conjunto de 10 caracteres
de longitud. El dominio Pas tiene valores: Ecuador, Argentina, Colombia.

Ejemplos de dominios:

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

- Nmeros de Identificacin: Conjunto de nmeros de identificacin vlidos,

formados por 12 dgitos.

- Edad: Edades posibles de personas.

Un atributo es el rol que tiene un dominio especfico en una entidad. Es muy

comn 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_fsica 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 combinacin de dominios simples que

tiene un nombre y al que se puede aplicar determinadas restricciones de
integridad. Por ejemplo, una entidad Usuario podra necesitar manejar, adems de
los tres dominios Da, Mes y Ao, un dominio compuesto llamado Fecha, que sera
la combinacin de los tres primeros atributos, y al que podramos aplicar las
adecuadas restricciones de integridad a fin de que no se presenten valores no
vlidos para la fecha final. Lo mismo ocurre con el nombre y los apellidos, que
segn 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 vaco de atributos que

identifican de forma nica y mnima a cada registro. Por la propia definicin de
entidad, siempre existe al menos una clave candidata para cada tabla, ya que al
ser la relacin 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 ms 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 caractersticas:

- 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 deberan 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 aplicacin, se
pierde control, causando problemas de datos potenciales. Por ejemplo, cuando
esto sucede, no es posible asegurar la unicidad de la informacin. Bajo este
contexto, el nmero de identificacin es una mala eleccin para clave primaria
para una entidad Cliente. Es mejor asignar un nmero dentro de la organizacin
para cada cliente, pues con esto se asegura que la clave no va a cambiar.

Se llama clave fornea de una entidad a un conjunto no vaco de atributos cuyos

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

4.2.4. Relaciones

Las relaciones definen la forma cmo diferentes entidades interactan entre s. El

nombre de una relacin describe el papel de una entidad en la asociacin con la
otra entidad. Las claves definen la relacin: la clave primaria en la entidad
principal, y la clave fornea en la entidad dependiente.

Se denomina cardinalidad de la relacin al nmero de ocurrencias que pueden

existir entre un par de tablas. Es comn utilizar tambin el trmino grado para
referirse a la cardinalidad.

4.3. Fases del Diseo de Modelos de Bases de Datos

Las fases del diseo de Modelos de Bases de datos son:

1. Recoleccin y anlisis de requerimientos.

2. Diseo conceptual.

3. Diseo lgico.

4. Diseo fsico.

4.3.1. Recoleccin y anlisis de requerimientos

Los analistas entrevistan a los futuros usuarios de la base de datos para recoger y
documentar sus requerimientos de informacin. En forma paralela, es conveniente
definir los requerimientos funcionales que consisten en transacciones que se
aplicarn a la base de datos, e incluyen la obtencin de datos y su actualizacin.

4.3.2. Diseo 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 descripcin detallada de los requerimientos

de informacin de los usuarios, y contiene las definiciones de los tipos de datos,
relaciones entre ellos y restricciones.

4.3.3. Diseo lgico de la base de datos (transformacin de modelo de

datos)

El siguiente paso en el proceso de disear 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 (jerrquico,
red o relacional).

4.3.4. Diseo fsico de la Base de Datos

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

organizacin de los archivos de la base de datos, considerando los tipos de datos
especficos que tiene el DBMS a utilizar.
4.4. Normalizacin

El proceso de Normalizacin de bases de datos consiste en aplicar una serie de

reglas a las entidades obtenidas tras el paso del modelo entidad-relacin al
modelo relacional.

Las bases de datos relacionales se normalizan para:

- Evitar la redundancia de los datos.

- Evitar problemas de actualizacin de los datos en las tablas.

- Proteger la integridad de los datos.

En el proceso de normalizacin, segn 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 definicin ms 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 mltiples y
dependencias de reunin, respectivamente.

Las formas normales, por s solas, no garantizan un buen diseo 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
normalizacin tiene que confirmar la existencia de propiedades adicionales que los
esquemas relacionales en conjunto deben poseer. Estas propiedades son:

- Reunin sin prdida, que garantiza que no se presente el problema de los

registros errneos.

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

Esto quiere decir simplemente que cada atributo slo 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 mltiples
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 primara de la entidad inicial.

- Ejemplo

Se disea una entidad para almacenar los nombres y telfonos de los clientes:

- Cliente

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

Como se observa, el atributo Telfono posee mltiples 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.

- Telfono de Cliente

Figura 4.5: Ejemplo de Entidad Telfono 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 slo de una parte de sta.

Este propsito solamente se aplica a entidades que tienen claves compuestas, es

decir, que las claves estn formadas por ms 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 disea 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 actualizacin.

Una alternativa de diseo 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 slo de la clave, y no de ningn 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 tambin
en segunda forma normal, sin embargo lo inverso no siempre es cierto.

- Ejemplo

Se disea 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, Ao}. Se
viola la 3FN porque el atributo Fecha de Nacimiento tiene una dependencia
transitiva hacia la clave candidata, de forma indirecta a travs de atributo Ganador.
Esto hace vulnerable a la entidad ante posibles inconsistencias lgicas, pues el
valor del atributo Fecha de Nacimiento podra ser diferente en algunos registros.

Para cumplir con la 3FN podramos 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 prohbe relaciones donde se tengan atributos no

atmicos o con mltiples valores. Sin embargo existen muchas situaciones en las
cuales una entidad requiere este tipo de atributos.

A una condicin que haga cumplir esta dependencia de los atributos que requieren
duplicacin de valores se le denomina una Dependencia Multivaluada. Debido a
que requieren una gran duplicacin de valores de datos, un aspecto importante del
proceso de normalizacin 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 solucin 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 acadmico, a un miembro de una facultad se le asignan

diferentes comisiones y es responsable de mltiples 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
anomalas que resultan de un tipo de restriccin llamado dependencias de unin
(en ingls, Join Dependencies). Estas dependencias son principalmente de inters
terico, por lo cual la 5FN no tiene una aplicacin prctica en modelos reales.

Captulo 5.- Diseo de aplicaciones con acceso a Bases de Datos

OBJETIVOS
- Promover el uso correcto de los principios de Diseo 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 cmo los DBMS's aseguran la integridad de la informacin mediante las
transacciones.
- Identificar los tipos de bloqueos y la forma adecuada de utilizarlos, para evitar el deadlock.
5.1. Introduccin

El diseo de Aplicaciones es un proceso que va ms 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 aplicacin, por lo que
debe ser diseada 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 Diseo de Aplicaciones. Es
inaceptable que se permita a los programadores disear y elaborar aplicaciones
sin considerar la forma como sus scripts afectan al rendimiento de la Base de
datos.

Es comn 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 cdigo, 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 cdigos
ineficientes, y que la solucin ms factible es el rediseo del cdigo. Entonces
por qu no escribir cdigos eficientes desde el principio?

Para disear correctamente aplicaciones con acceso a Bases de datos, se debe

tener un dominio adecuado de los siguientes temas:

- Cmo los datos son almacenados en una Base de Datos Relacional.

- Cmo utilizar las sentencias SQL adecuadas para acceder a la informacin y

modificarla.

- Diferencias entre los lenguajes de programacin tradicionales y SQL.

- Uso de objetos de programacin del DBMS: procedimientos almacenados y

funciones.

- Cmo 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 programacin
utilizado para examinar, reemplazar y gestionar la informacin almacenada en los
DBMS's.

Estndares de SQL han sido definidos por las siguientes entidades

internacionales:

- ANSI (American National Standards Institute)

- ISO (Internacional Organization for Standardization)

La ANSI es una organizacin de compaas industriales y comerciales que

desarrollan estndares de comunicacin 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 estndares para Estados Unidos
que se corresponden con sus respectivos estndares internacionales. En el ao
1992, la ISO e la IEC publicaron un estndar para SQL llamado SQL92. La ANSI
public un estndar 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 estndar ANSI
SQL.

El lenguaje SQL contiene instrucciones que se agrupan en las siguientes

categoras:

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

la definicin y administracin de objetos como bases de datos, tablas y vistas.

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

utilizan para la manipulacin de la informacin contenida en las base de datos.

5.2.1. Instrucciones DDL

El lenguaje de definicin de datos (DDL por sus siglas en ingls) es el que permite
la modificacin de las estructuras de los objetos de la base de datos. Existen
cuatro instrucciones DDL bsicas: 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, funcin, procedimiento o
cualquier otro que el motor de la base de datos soporte.

Ejemplo: Creacin 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, funcin, procedimiento o cualquier otro objeto
que el motor de la base de datos contenga. Es posible combinar este comando
con la sentencia ALTER.

Ejemplo: Eliminacin 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 ms rpido 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 clusula
WHERE. Aunque en un principio esta sentencia parece ser de tipo DML, es en
realidad una DDL, ya que internamente para su ejecucin, 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 manipulacin de datos (DML por sus siglas en ingls) es un

lenguaje proporcionado por los DBMS's que permite llevar a cabo las tareas de
consulta o gestin de la informacin, 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 condicin 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
condicin 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 nmero de los registros que cumplen con la

condicin indicada:

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

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

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

- INSERT: Una sentencia INSERT de SQL permite agregar uno o ms 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 omisin
indicado en la definicin de la tabla. Los valores especificados por la sentencia
INSERT tienen que satisfacer todas las restricciones aplicables a cada campo. Si
en la ejecucin 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 condicin establecida.

Sintaxis:

DELETE nombre_tabla WHERE columnaX = valorX

Ejemplo:

DELETE tabla_ejemplo WHERE campo2 = 'N'

5.3. Definicin de Transacciones

Una transaccin se define dentro del mbito de los sistemas de informacin como
una unidad de trabajo atmica, con respecto a la consistencia de los datos. Una
transaccin ejecuta un proceso de negocio completo que es solicitado por un
usuario. Una transaccin lgica puede consistir de vario pasos y requerir ms de
una transaccin fsica. El resultado de la ejecucin de una transaccin afectar los
datos almacenados en la Base, los cuales tienen que ser correctos antes y
despus de la transaccin.

Cuando todos los pasos de una transaccin son ejecutados sin problemas, se
acepta la transaccin, ejecutando la sentencia COMMIT. La ejecucin de la
sentencia COMMIT le indica al DBMS que los cambios realizados por la
transaccin pueden ser finalmente grabados en la Base de Datos.
Si alguno de los pasos de la transaccin 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 tenan antes de la ejecucin
de la transaccin.

5.3.1. ACID

Es obligatorio que una transaccin cumpla con las propiedades establecidas por el
estndar ACID: atomicity, consistency, isolation, durability. Cada una de estas
cuatro condiciones tiene que cumplirse para asegurar que una transaccin est
correctamente diseada.

- Atomicidad: esta condicin asegura que la operacin sea exitosa solamente si

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

- Consistencia: es la condicin que asegura que slo 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 condicin asegura que una operacin no puede afectar a otras.
Esto permite que la realizacin de dos transacciones simultneas sobre la misma
porcin de informacin nunca generar ningn tipo de error.

- Durabilidad: es la condicin que asegura que una vez realizada la operacin, el

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

Los DBMS aseguran el cumplimiento de las propiedades ACID a travs de

mecanismos como los bloqueos.

5.3.2. Gua para la programacin de Transacciones

Para el diseo de las transacciones se debe considerar:

- Una transaccin debe ser corta en duracin, porque sta bloquea recursos
compartidos para otras transacciones.

- Una transaccin debe estar diseada para que no espere una decisin, para que
no haya retrasos por una respuesta en medio de su ejecucin.

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 operacin 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
transaccin 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 ms transacciones estn interconectadas entre s, lo que ocurre con
ms frecuencia dentro de un ambiente multiusuario.

Generalmente las solicitudes se ejecutan en la base de datos por una instruccin 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 dems usuarios.

Cuando dos usuarios concurrentes ejecutan en el mismo instante una transaccin

que afecta a la misma informacin, es cuando se puede presentar el problema de
la actualizacin perdida. Esto consiste en que los dos usuarios quieren actualizar
al mismo tiempo el mismo rango de datos.

Una solucin 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 mtodo es
conocido como bloqueo de recursos.

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

registros recuperados para su actualizacin no deben ser compartidos entre
diferentes usuarios.
Los bloqueos pueden colocarse de forma automtica 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
implcitos. Los bloqueos que son colocados por comando se llaman bloqueos
explcitos.

Los bloqueos pueden ser colocados en distintos niveles: registro, pgina, tabla o
base de datos. Al tamao del bloqueo se lo conoce como granularidad del
bloqueo. Los bloqueos con granularidad mayor son adecuados para el DBMS en
cuanto a su administracin, porque consumen menos recursos de memoria. Sin
embargo, con frecuencia causan conflictos. Los bloqueos con pequea
granularidad son difciles de administrar, porque consumen mucha memoria.
Cuando se colocan bloqueos con granularidad fina existen muchos ms 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 transaccin 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 ms transacciones se realizan concurrentemente, los resultados en

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

Los lmites de una transaccin deben corresponder a la definicin 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 efectan 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 continuacin 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 simultneamente la misma informacin. 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
informacin.

- 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 simultneamente la misma informacin, cuando est
colocado un bloqueo exclusivo. Esto permite que los usuarios consulten
informacin consistente.

- Bloqueo de actualizacin (update lock): El DBMS coloca este tipo de bloqueo

cuando la informacin primero tiene que ser leda para luego ser cambiada o
eliminada. El bloqueo de actualizacin indica que la informacin va a ser
modificada posteriormente. Cuando la actualizacin se produce, el DBMS hace
una promocin hacia un bloqueo exclusivo.

5.4.2. Timeouts

Cuando los datos estn bloqueados por un proceso, otro proceso tiene que
esperar hasta que se libere el bloqueo, para poder acceder a la informacin. Un
bloqueo colocado por demasiado tiempo se convierte en un potencial problema
para el rendimiento de la aplicacin. Si la aplicacin no ha sido diseada de forma
apropiada, el bloqueo no se liberar hasta que el programa falle o se realice una
accin por parte del DBA.

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

liberacin de un proceso indefinidamente. Cada DBMS provee un parmetro de
configuracin para el valor de timeout de bloqueos. Este parmetro puede ser
configurado a nivel de DBMS, proceso o conexin. 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 prctica 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 ejecucin, un
proceso est utilizando algn recurso; y en el estado de bloqueo, el proceso est
parado y no se ejecutar mientras no tenga los recursos que necesita.

Una condicin comn no deseable es el deadlock o interbloqueo, que se

presenta cuando dos procesos estn en un estado de ejecucin, y requieren
intercambiar recursos entre s para poder continuar. Los dos procesos estn
esperando por la liberacin del recurso requerido, pero esta nunca se presentar;
como no hay ningn resultado, se toma un camino que lleva a una situacin de
deadlock.

Muchos escenarios han sido construidos para ilustrar las condiciones de deadlock,
siendo el ms popular el Problema de Comida de los Filsofos:

Cinco filsofos tienen cinco platos de fideos enfrente y cinco tenedores, uno a cada lado
del plato. Los filsofos requieren ambos tenedores (derecha e izquierda) para comer.
Durante la comida realizarn solo dos operaciones mutuamente excluyentes, pensar o
comer. El problema es un paralelismo simplista entre procesos (los filsofos) tratando de
obtener recursos (tenedores); mientras estn en estado de ejecucin (comiendo) o de
lectura (pensando). Una condicin posible de deadlock puede ocurrir, si todos los filsofos
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 estn esperando por condiciones que
nunca se cumplirn. Tambin se puede definir un deadlock como el estado
permanente de bloqueo de un conjunto de procesos que estn compitiendo entre
s por recursos del sistema.

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

- Condicin de exclusin mutua: Existe al menos un recurso compartido por los

procesos, al cual slo puede acceder uno de forma simultnea.
- Condicin de Posesin 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.

- Condicin de no expropiacin: Los recursos no pueden ser tomados por los

procesos. Es decir, los recursos slo pueden ser liberados voluntariamente por
quienes los poseen.

- Condicin 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 condicin implica la condicin de
retencin y espera.

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

condiciones necesarias nombradas anteriormente:

- Eliminando la exclusin mutua: ningn proceso puede tener acceso de forma

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

- La condicin de retencin y espera puede ser eliminada haciendo que los

procesos soliciten todos los recursos que van a necesitar antes de empezar su
ejecucin. 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 tambin es poco prctico en la realidad.

- La condicin de no expropiacin puede ser imposible de eliminar debido que un

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

- La condicin de espera circular es la ms fcil de controlar. Se le permite a un

proceso poseer slo un recurso en un determinado momento, o una jerarqua
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 cmo y cundo los cambios realizados por una transaccin son visibles por
otras operaciones concurrentes, influyendo en las siguientes anomalas:
- Dirty Reads: Ocurre cuando una transaccin lee datos modificados por otros
procesos concurrentes que an no han realizado COMMIT.

- Nonrepeatable Reads: Se presenta cuando dentro de una transaccin se lee el

mismo registro ms de una vez y los datos obtenidos son diferentes, seguramente
porque otro proceso concurrente los actualiz.

- Phantom Reads: Se presenta cuando en una transaccin se ejecuta la misma

consulta ms de una vez y se obtienen distintos resultados. Por ejemplo, si otra
transaccin agreg nuevos registros que satisfacen el criterio de bsqueda de la
consulta.

El estndar ANSI SQL define cuatro niveles de aislamiento:

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

Reads y PhantomReads. Esta es la opcin 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 opcin ms restrictiva y

costosa.

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

ya sea a travs de un administrador grfico o por lnea de comandos. Por otro lado
tambin es necesario aclarar que los DBMS's difieren en los valores por defecto
de los niveles de aislamiento.

Captulo 6.- Integridad de Datos

OBJETIVOS
- Establecer la diferencia entre la integridad semntica 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 semntica que proveen los DBMS's.
- Analizar los tipos de relaciones entre las entidades y la forma de mantener la integridad
referencial.
6.1. Introduccin

El aseguramiento de la Integridad de las Bases de Datos de la organizacin 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 semntica de los datos.

El objetivo de la integridad estructural es salvaguardar la forma cmo 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 daos en estas estructuras, que el DBA debe identificar y corregir cuando
se produzcan, antes de que causen problemas serios.

En cambio, la Integridad semntica se refiere al significado en s de la informacin

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

6.2. Integridad Estructural

La integridad estructural es un elemento importante de la Administracin 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 ms comunes que se presentan en las Bases de datos

relacionales es la corrupcin de ndices. Internamente, los DBMS's manejan a los
ndices en estructuras de rboles, siendo la "B-tree" la ms comn. Bsicamente,
las pginas de hojas de un ndice son los punteros a la localizacin fsica de los
datos en una Base. Si los punteros no dirigen a la informacin correcta, el ndice
se vuelve inutilizable.

Adems 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
imgenes, no son guardados de forma continua en los discos.

Otro tipo de corrupcin que puede presentarse es el dao de las cabeceras de

pginas. Como es conocido, la unidad de informacin de las bases de datos es la
pgina. Cada pgina fsica dentro de una base de datos guarda informacin de su
contenido en una cabecera, al inicio de la pgina. Esta cabecera permite al DBMS
leer el contenido de la pgina de forma rpida y sencilla. Si la cabecera est
daada, el DBMS no interpretar correctamente el contenido de la pgina. Este
problema constituye un dao grave, y cuando se presenta, se requiere la carga de
respaldos para la recuperacin de la informacin.

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 bsicas para el chequeo de consistencia:

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

ndices de una tabla. DBCC reporta el nmero de pginas 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 opcin 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 nmero de pginas y registros de la
tabla, as como las inconsistencias encontradas.

- DBCC CHECKALLOC (nombre_base): reporta las inconsistencias del

almacenamiento fsico de la base de datos.

6.3. Integridad Semntica

La Integridad Semntica busca asegurar que el significado de la informacin

almacenada sea coherente con las relaciones definidas en el modelo de datos.
Los DBMS proveen controles y procedimientos para definir y asegurar la
integridad semntica de la informacin.

Los niveles de integridad semntica 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 ms bsico 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 ningn campo componente de la clave primaria de una entidad puede

aceptar valores nulos.

La justificacin para la regla de integridad de las entidades es la siguiente:

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

- Por definicin, 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 tambin.

- 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 contradiccin de trminos: simplemente la

entidad no existe.

En la prctica, 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 prctica" la costumbre de crear tablas sin claves
primarias, debido a que se dificulta la identificacin 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 ms 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 definicin del tipo de dato y tamao de un campo es la aplicacin 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 sern rechazados.

Los tipos de datos para las columnas de una tabla deben ser escogidos en tiempo
de diseo con mucha precaucin, procurando realizar la eleccin adecuada al
dominio de la informacin 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 automtica 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 ms de un check

constraint. De la misma forma, una check contraint puede proteger a ms de una
columna.

6.3.6. Triggers
Un trigger (disparador) es una funcin que se ejecuta cuando se cumple una
condicin establecida, cuando se realiza una operacin de insercin, actualizacin
o eliminacin de registros en una tabla.

Los triggers son muy utilizados para mejorar la gestin de la Base de datos,
especialmente para asegurar la integridad de la informacin. Son muy tiles pues
permiten realizar una accin automtica sin necesidad de que el usuario ejecute
ninguna sentencia de SQL.

Tambin es posible utilizar un trigger para generar valores de columnas, prevenir

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

La estructura bsica de un trigger es la siguiente:

- Llamada de activacin: es la sentencia (insert, delete, update) que permite

"disparar" el cdigo a ejecutar.

- Restriccin: es la condicin que se requiere para ejecutar el cdigo.

- Accin a ejecutar: es la secuencia de instrucciones a ejecutar cuando se han

cumplido las condiciones iniciales.

Existen dos tipos de triggers que se clasifican segn 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 condicin, se ejecutan
solamente una vez.

Algunas caractersticas importantes de los triggers son:

- Los triggers no aceptan parmetros o argumentos (de entrada o salida), pero

podran 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 vlidos 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:

- Relacin Uno a Uno: Cuando un registro de una tabla slo 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 relacin
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: Relacin Uno a Uno.

- Relacin Uno a Muchos: Cuando un registro de una tabla (tabla secundaria) slo
puede estar relacionado con un nico registro de la otra tabla (tabla principal) y un
registro de la tabla principal puede tener ms 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 poblacin puede tener ms de un habitante, pero un habitante
estar empadronado en una nica poblacin.

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

de habitantes. Una poblacin puede tener varios habitantes pero un habitante
pertenece a una sola poblacin. Esta relacin 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 fornea de la tabla.

En la tabla habitantes se tiene una columna "poblacin" que contiene el cdigo de

la poblacin en la que est empadronado el habitante. Esta columna es clave
fornea de la tabla habitantes. En la tabla poblaciones tenemos una columna
"cdigo de poblacin" clave primaria de la tabla.

Figura 6.2: Relacin Uno a Muchos.

- Relacin Muchos a Muchos: Esta tipo de relacin se presenta cuando un registro

de una tabla puede estar relacionado con ms de un registro de la otra tabla. En
este caso las dos tablas no pueden estar relacionadas directamente, se tiene que
aadir 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 artculos que
se venden en la empresa. Un cliente puede realizar un pedido con varios artculos,
y un artculo podr ser vendido a ms de un cliente.

Para establecer la relacin entre clientes y artculos hace falta otra tabla, por
ejemplo una tabla de pedidos. La tabla pedidos estar relacionada con cliente por
una relacin uno a muchos y tambin estar relacionada con artculos por un
relacin uno a muchos.
 Figura 6.3: Relacin Muchos a Muchos.

Cuando se define una columna como clave fornea, las filas de la tabla pueden
contener en esa columna un valor nulo o un valor que existe en la otra tabla. Un
error sera 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 forneas) deben ser correctos. La
integridad referencial hace que el DBMS se asegure de que no haya en las claves
forneas valores que no estn en la tabla principal.

La integridad referencial se activa en cuanto creamos una clave fornea y a partir

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

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

fornea 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 travs de una
clave fornea.

- Cuando se modifica el valor de la clave fornea, el nuevo valor tambin 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:
- Actualizacin de registros en cascada: Esta opcin le indica al DBMS que
cuando se cambie un valor del campo clave de la tabla principal, automticamente
cambiar el valor de la clave fornea 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 cdigo (la clave principal), automticamente se actualizan todos los
habitantes (tabla secundaria) que tienen el valor 1 en el campo poblacin (en la
clave ajena) dejando 10 en vez de 1.

Si no se tiene definida esta opcin, 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
cdigo 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.

- Eliminacin de registros en cascada: Esta opcin le indica al DBMS que cuando

se requiera eliminar un registro de la tabla principal, automticamente se deben
borrar tambin los registros relacionados en la tabla secundaria.

Ejemplo:

Si se borra la poblacin "Guayaquil" en la tabla de poblaciones, automticamente

todos los habitantes de "Guayaquil" se borrarn de la tabla de habitantes.

Si no se tiene definida esta opcin, 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 poblacin "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.

Captulo 7.- Disponibilidad de la Informacin

OBJETIVOS
- Analizar las causas de los problemas de disponibilidad de la informacin.
- Definicin del downtime, dependiendo de los requerimientos de disponibilidad de la
informacin.
- Definir las polticas que debe ser implementadas por una organizacin para asegurar la
disponibilidad de la informacin.
7.1. Introduccin
El aseguramiento de la disponibilidad de la informacin es la tarea principal del
DBA. Si la Base de datos no est disponible, las aplicaciones no pueden trabajar,
con lo cual la Organizacin no funcionar con normalidad. Por esta razn, el DBA
pone todo su esfuerzo en asegurar que las Bases de datos se mantengan en lnea
y operativas.

La necesidad de disponibilidad de los datos en nuestros das se ha incrementado,

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

De una manera sencilla, se puede definir que la "disponibilidad" es la condicin

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

Otra definicin 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 combinacin,

aseguran que los sistemas se estn ejecutando y que la Organizacin 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

daos de la infraestructura.

- Capacidad de atender diferentes niveles de servicio.

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

crticos.

7.2. Costo del Downtime

"Downtime" es un trmino utilizado para definir el tiempo en que los sistemas no

estn disponibles para su utilizacin. El costo del downtime puede variar de una
Organizacin a otra, pues este costo depende del tipo de organizacin, sus
clientes y sus operaciones.

Para estimar el costo del downtime se deben considerar los siguientes factores:
- Posibles prdidas de negocios durante el tiempo de paralizacin.

- Costos de recuperacin de la infraestructura.

- Costos relacionados con implicaciones legales de la paralizacin.

- Impacto en la reduccin de las operaciones.

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

organizacin, lo cual muchas veces es ms difcil de recuperar que las prdidas
econmicas.

Las organizaciones de este tiempo deben considerar que muchas veces las
prdidas producidas durante un dao del sistema, suelen ser mayores que la
inversin 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 informacin.

Estos eventos son:

- Prdida del Centro de Cmputo

- Fallas de Hardware

- Fallas de Sistema Operativo

- Fallas del Servidor de Bases de datos

- Fallas de Seguridad

- Corrupcin y Prdida de datos

- Problemas de rendimiento

- Errores del Administrador de Bases de datos

7.3.1. Prdida del Centro de Cmputo

Como es obvio, la informacin no estar disponible si el Centro de Cmputo no
est operativo. Posibles causas de la prdida de un Centro de Cmputo son:

- Desastres naturales.

- Incendios.

- Atentados.

- Prdidas de energa elctrica prolongadas.

Para reestablecer la disponibilidad de la informacin 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 operacin 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 mximo 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 adems con las condiciones necesarias para que las partes se conserven
en buen estado.
- Otros equipos que podran usar un mismo repuesto.

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

contar con un Contrato de Servicio Tcnico. Estos contratos de servicios trasladan
el problema de los errores de hardware a un proveedor, liberando de esta
responsabilidad directa a la Organizacin. 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 mayora de los Contratos de cobertura se definen en trminos de las horas y

los das durante los cuales se puede enviar un tcnico. Algunas de las horas de
cobertura ms comunes son:

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

- Lunes a viernes, 12/18/24 horas cada da (con los tiempos de comienzo y de

finalizacin acordados mutuamente)

- Servicio permanente: 365 das, 7 das a la semana, las 24 horas del da.

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

cobertura.

Adems 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, cul es el tiempo que debe esperar hasta que llegue un tcnico?

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

la exposicin de la organizacin a errores de hardware. En el contexto de un
acuerdo de servicio, la disponibilidad de las partes toma otra dimensin, pues no
solamente aplica a su organizacin, sino tambin 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 interrupcin del

servicio. Las fallas del sistema operativo pueden ser:

- Cadas del sistema

- Bloqueos o Inhibiciones.

Estas fallas ocurren cuando el sistema operativo experimenta una condicin de

error desde la cual no se puede recuperar. Las razones de las cadas pueden
variar desde una incapacidad para manejar un problema de hardware hasta un
error en el cdigo a nivel del kernel. Cuando un sistema operativo falla, se debe
reiniciar el sistema para poder continuar la produccin.

7.3.4. Fallas del Servidor de Bases de datos

Si el DBMS no est operacional, no es posible acceder a la informacin. Las fallas

del DBMS pueden ocurrir por las siguientes causas:

- Inestabilidad debido a una falla de la versin del DBMS.

- Problemas en la aplicacin de nuevos parches del DBMS.

- Los recursos que el DBMS necesita no estn disponibles.

Para evitar este tipo de fallas del DBMS, es recomendable tener instalados los
ltimos parches de la versin en produccin. 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 informacin.

Antes de que los datos puedan ser accedidos, directamente por un usuario o por
una aplicacin, debe asignarse una autorizacin de acceso.

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

DBA. La asignacin de permisos es una tarea crtica que debe realizarse con el
cuidado debido. Adicionalmente, es deseable que se mantenga un inventario de
los permisos asignados.
7.3.6. Corrupcin y Prdida de datos

La corrupcin de los datos se refiere a los errores que se producen sobre stos
durante el almacenamiento, la transmisin o la recuperacin, as como durante la
introduccin de cambios no deseados a los datos originales.

La prdida 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 categora, mientras que en el
software suele producirse debido a los errores en el cdigo.

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

evaluar los bits de paridad de datos a travs de una serie de discos duros, y
pueden reconstruir los datos daados a partir de un disco o mltiples discos,
dependiente en el nivel de RAID aplicado.

Si los mecanismos adecuados se emplean para detectar y remediar la corrupcin

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

informacin. A pesar de que la base de datos est tcnicamente en lnea, el
rendimiento pobre hace que los datos no puedan ser consultados adecuadamente.

Los siguientes problemas pueden ser causa de una degradacin del rendimiento:

- Corrupcin de ndices.

- Definicin incorrecta o falta de ndices adecuados.

- Crecimiento indiscriminado del tamao de las bases de datos, de forma

imprevista.

- Concurrencia adicional de usuarios no contemplados.

- Objetos de la base de datos sin actualizacin de estadsticas.

- Problemas de contencin.

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 cmputo, las tareas que el DBA

lleva a cabo a menudo no estn 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 configuracin de un DBMS vara en gran medida: algunas veces se

requiere editar un archivo de texto, mientras que en otras ocasiones se requiere la
ejecucin de alguna utilidad de configuracin.

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

un reto adicional al hecho bsico de que cada tarea de configuracin requiere un
conocimiento diferente.

Muchas organizaciones implementan algn tipo de proceso de control de cambios,

cuando stos son producidos. La intencin 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 exposicin de la organizacin a cualquier error que pueda ocurrir.

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

diferentes, tales como los siguientes:

- Investigacin previa: La investigacin 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 evaluacin de los tipos de errores que pueden presentarse.

La investigacin 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 implementacin del cambio primero en un ambiente de prueba especial,
ejecutndose en un hardware dedicado para las evaluaciones.

- Planificacin: La planificacin incluye una descripcin de la secuencia y tiempo

del cambio, as como tambin 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 verificacin de pasos
(checklist) para que la use el ejecutante mientras est llevando a cabo el cambio.
Junto con cada paso estn 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
planificacin o no.

- Ejecucin: En este punto, la ejecucin real de los pasos necesarios para

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

- Supervisin: Bien sea que se implemente el cambio o no, se monitorea el

ambiente para asegurarse de que todo est funcionando como debera.

- Documentacin: Si se implementa el cambio, toda la documentacin existente

se actualiza para reflejar la configuracin modificada.

7.4. Aseguramiento de la disponibilidad

Con el objetivo de asegurar la disponibilidad de la informacin el DBA debe

implementar polticas que incluyen los siguientes pasos:

- Implementacin de procesos de mantenimiento, cuando los sistemas estn

operativos.

- Automatizar las tareas administrativas del DBA.

- Explorar las tecnologas de Alta disponibilidad del DBMS.

7.4.1. Mantenimiento

Las principales tareas de mantenimiento que ejecuta el DBA son:

- Reorganizacin de los objetos de la Base de datos.

- Tareas de respaldo.

- Pruebas de restauracin de respaldos.

- Actualizacin de estadsticas de los objetos.

- Chequeos de integridad de los objetos.

- Asignacin de espacio en disco para las Bases de datos.

La ejecucin 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 ejecucin de las tareas no afecte a los usuarios, por lo que
deben realizarse en los horarios en los que la afectacin sea nula, o por lo menos
mnima.

7.4.2. Tareas automticas

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 automtica 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 travs de scripts que se ejecuten
mediante tareas programadas. La calendarizacin de las tareas debe realizarse
tomando en cuenta los horarios adecuados para que la ejecucin del proceso no
afecte a los usuarios.

Adicionalmente, cuando se automatice un proceso, es necesario implementar una

alerta o reporte de ejecucin, 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 diseo del sistema y su

implementacin asociada en el DBMS, que asegura un cierto grado absoluto de
continuidad operacional durante un perodo de medicin dado.

Los diseos de alta disponibilidad se implementan para garantizar la disponibilidad

de la informacin 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 configuracin que toman efecto despus de un reinicio. En
general el tiempo de inactividad planificado es usualmente el resultado de un
evento lgico o de gestin iniciado.

- Tiempo de inactividad no planificado: Surgen de algn evento fsico o lgico que

afecta la disponibilidad.
Los proveedores de DBMS's incluyen en sus productos caractersticas de Alta
disponibilidad, que se adaptan a la infraestructura disponible en las
organizaciones.