Capítulo 2.

Crear el entorno de la base de datos

Una de las principales tareas asociadas con el trabajo de DBA es el proceso de elegir e instalar un DBMS.
Desafortunadamente, muchos ejecutivos de negocios y profesionales de TI sin antecedentes de administración
de bases de datos suponen que una vez que el DBMS está instalado, la mayor parte del trabajo está hecho. La
verdad es que elegir e instalar el DBMS no es la parte más difícil del trabajo de un DBA. Establecer un entorno
de base de datos utilizable requiere una gran cantidad de habilidades, conocimiento y consideración. Este
capítulo describirá los principios involucrados en el establecimiento de un entorno de base de datos utilizable.

Definición de la estrategia DBMS de la organización

El proceso de elegir un DBMS adecuado para la gestión de bases de datos empresariales no es tan difícil como
solía ser. El número de proveedores principales de DBMS ha disminuido debido a la consolidación de la industria
y la dominación del sector por parte de algunos jugadores muy grandes.

Elegir un DBMS adecuado para la gestión de bases de datos empresariales no es tan difícil como solía ser.

Sin embargo, las organizaciones grandes y medianas normalmente ejecutan múltiples productos DBMS, desde
dos hasta diez. Por ejemplo, no es raro que una empresa grande use IMS o IDMS y DB2 en el mainframe, Oracle
e Informix en varios servidores UNIX diferentes, Microsoft SQL Server en servidores Windows NT, así como
también otros productos DBMS como Sybase. , Ingres, Adabas y Datacom en varias plataformas. Sin mencionar
los productos DBMS para PC de un solo usuario como Microsoft Access, Paradox o Filemaker. ¿Quién eligió
instalar todos estos DBMS y por qué?
Desafortunadamente, a menudo la respuesta es que no se pensó mucho ni se planificó el proceso de toma de
decisiones. A veces, la decisión de comprar e instalar un nuevo DBMS es impulsada por una necesidad comercial
o una nueva aplicación. Esto es razonable si su organización no tiene DBMS y debe comprar uno por primera
vez. Sin embargo, esto rara vez es el caso. Independientemente de si existe un DBMS en el sitio, a menudo se
considera un nuevo DBMS como un requisito para una nueva aplicación. A veces, un nuevo producto DBMS se
compra e instala sin examinar primero si la aplicación podría implementarse exitosamente usando un DBMS
existente. O, lo que es más probable, los DBA saben que la aplicación puede implementarse utilizando un DBMS
existente, pero carecen del poder de organización o soporte para rechazar una nueva propuesta de DBMS.
Existen otras razones para la existencia de múltiples plataformas DBMS en una sola organización. Tal vez la
compañía compró un paquete de aplicación comercial que no se ejecuta en
cualquiera de las plataformas DBMS actuales. A veces, la decisión de comprar un nuevo SGBD está impulsada
por el deseo de respaldar la última y mejor tecnología. Por ejemplo, muchas tiendas de mainframe que se
mueven desde un modelo de base de datos jerárquico (IMS) o CODASYL (IDMS) al modelo relacional
implementado DB2, dan como resultado un DBMS adicional para aprender y soportar. Luego, cuando la
informática cliente / servidor se hizo popular, se implementaron DBMS adicionales en los servidores UNIX y
Windows NT.
Una vez que se instala un DBMS, la eliminación puede ser difícil debido a las incompatibilidades entre los
diferentes DBMS y la necesidad de convertir el código de la aplicación. Además, cuando se instala un nuevo
DBMS, las aplicaciones y bases de datos antiguas generalmente no se migran a él. El viejo DBMS permanece y
debe seguir siendo compatible. Esto complica el trabajo del DBA.
¿Entonces qué debería ser hecho? Bien, el grupo de DBA debe estar facultado para tomar las decisiones de
DBMS para la organización. Ninguna unidad comercial debe poder comprar un DBMS sin el permiso del grupo
DBA. Esta es una disposición difícil de implementar y aún más difícil de aplicar. La política empresarial a menudo
trabaja en contra del grupo DBA porque el grupo DBA frecuentemente posee menos poder organizacional que
otros ejecutivos de negocios.

El grupo de DBA debe estar facultado para tomar las decisiones de DBMS para la organización.

Elegir un DBMS

El grupo de DBA debe establecer una política con respecto a los productos DBMS para ser admitidos dentro de la
1

organización. Siempre que sea posible, la política debe minimizar el número de diferentes productos DBMS. Para
Página

una tienda con múltiples sistemas operativos y múltiples tipos de hardware, elija un DBMS predeterminado para
la plataforma. Desalentar la desviación del valor predeterminado a menos que exista un caso empresarial
convincente: un caso comercial que pase la inspección técnica del grupo DBA.
La mayoría de los principales productos DBMS tienen características similares, y si la característica o
funcionalidad no existe hoy, probablemente lo hará dentro de 18 a 24 meses. Por lo tanto, tenga cuidado antes
de decidir elegir un DBMS basado únicamente en su capacidad para admitir una función específica.
Al elegir un DBMS, es aconsejable seleccionar un producto de un proveedor de nivel 1 como se detalla en la
Tabla 2-1. El nivel 1 representa los proveedores más grandes que tienen los productos más implementados y
compatibles en el mercado. No puedes equivocarte con DB2 u Oracle. Ambos son populares y admiten casi
cualquier tipo de base de datos. Otro jugador importante es Microsoft SQL Server, pero solo para plataformas
Windows. DB2 y Oracle se ejecutan en múltiples plataformas que van desde mainframe a UNIX, así como a
Windows e incluso a dispositivos portátiles. La elección de un DBMS diferente a estos tres debe hacerse solo
bajo circunstancias extremas.
Al elegir un DBMS, seleccione un producto de un proveedor de nivel 1.

Después de los tres grandes vienen Sybase e Informix. La Tabla 2-2 enumera estos proveedores DBMS de nivel
2. Ambos proveedores ofrecen productos DBMS de calidad, pero su base instalada es más pequeña y las
empresas son más pequeñas, con menos recursos, que IBM, Oracle y Microsoft, por lo que existe cierto riesgo al
elegir un DBMS del nivel 2 en lugar del nivel 1. Sin embargo, el futuro de Informix es incierto, ya que IBM lo
adquirió y el futuro de la tecnología DBMS en IBM se centrará sin duda en DB2, no en Informix.

Table 2-1. Tier-1 DBMS Vendors

DBMS vendor DBMS product
IBM Corporation New Orchard Road DB2 Universal Database
Armonk, NY 10504 Phone: (914) 499-
1900
Oracle Corporation 500 Oracle Parkway Oracle
Redwood Shores, CA 94065 Phone: (650)
506-7000
Microsoft Corporation One Microsoft Way SQL Server
Redmond, WA 98052 Phone: (425) 882-
8080

Table 2-2. Tier-2 DBMS Vendors

DBMS vendor DBMS product
Informix Software, Inc. 50 Informix Dynamic Server
Washington Street Westborough,
MA 01581 Phone: (508) 366-3888
Sybase Inc. 6475 Christie Ave. Adaptive Server Enterprise
Emeryville, CA 94608 Phone: (510)
922-3500

Por supuesto, hay otros productos DBMS en el mercado, muchos de los cuales son productos excelentes y
dignos de consideración para el procesamiento especializado, ciertas necesidades predefinidas y roles de nicho.
Por ejemplo, los proyectos de almacenamiento de datos y VLDB (base de datos muy grande) pueden encontrar
la arquitectura y la funcionalidad de Teradata de NCR como el DBMS de elección. Si su empresa está muy
interesada en el movimiento del "software de código abierto", PostgreSQL o MySQL podrían ser opciones viables.
Si un objeto DBMS es importante para un proyecto específico, puede considerar ObjectDesign o Versant.
Sin embargo, para la mayoría de sus necesidades de administración de datos, un DBMS de un proveedor de
DBMS de nivel 1, o tal vez de nivel 2, ofrecerá suficiente funcionalidad con un riesgo mínimo. Una gran cantidad
de productos DBMS están disponibles, cada uno con ciertas características que los hacen dignos de
consideración caso por caso. Elegir a cualquiera de los candidatos de nivel inferior, incluso los nombres más
importantes como Adabas de Software AG y Ingres de Computer Associates implica incurrir en riesgos
adicionales. Consulte el Apéndice B para obtener una lista de proveedores de DBMS.

Elegir cualquiera de los candidatos de nivel inferior implica incurrir en riesgos adicionales.

No quiero que suene como si la selección de un DBMS fuera obvia. Necesitará una estrategia y un plan para
seleccionar el DBMS apropiado para su situación específica. Al elegir un SGBD, asegúrese de considerar cada
uno de estos factores:
2 Página

1. Soporte del sistema operativo. ¿Admite el DBMS los sistemas operativos que se usan en su organización,
incluidas las versiones que está utilizando actualmente y que planea usar?
2. Tipo de organización. Tenga en cuenta la filosofía corporativa cuando elige un DBMS. Algunas
organizaciones son muy conservadoras y les gusta mantener un estricto control sobre sus entornos;
estas organizaciones tienden a gravitar hacia entornos de mainframe tradicionales. Las operaciones
gubernamentales, las instituciones financieras y las compañías de seguros y salud generalmente tienden
 a ser conservadoras. Las organizaciones más liberales a menudo están dispuestas a considerar
arquitecturas alternativas. No es raro que las empresas manufactureras, las puntocom y las
universidades sean menos conservadoras. Finalmente, algunas empresas simplemente no confían en
Windows como un entorno de misión crítica, y prefieren usar UNIX, esto excluye a algunos proveedores
de bases de datos (Microsoft SQL Server, en particular).
3. Puntos de referencia. ¿Qué parámetros de rendimiento están disponibles del proveedor de DBMS y de
otros usuarios del DBMS? El Transaction Processing Performance Council (TPC) publica referencias de
rendimiento de bases de datos oficiales que se pueden utilizar como guía para el rendimiento general
básico de muchos tipos diferentes de procesamiento de bases de datos. Consulte la barra lateral "El
Consejo de rendimiento del procesamiento de transacciones" para obtener más detalles. En general, los
puntos de referencia de rendimiento pueden ser útiles como un indicador amplio del rendimiento de la
base de datos, pero no debería ser el único determinante al seleccionar un DBMS. Muchos de los puntos
de referencia de TPC se ejecutan contra implementaciones de bases de datos que no son representativas
de la mayoría de los sistemas de bases de datos de producción, y por lo tanto no son indicativos del
rendimiento real de un DBMS en particular. Además, los puntos de referencia se actualizan
constantemente para mostrar mediciones de rendimiento nuevas y mejoradas para cada uno de los
principales productos DBMS, lo que hace que los "ganadores" de referencia sean obsoletos muy
rápidamente. Los puntos de referencia se actualizan constantemente para mostrar mediciones de
rendimiento nuevas y mejoradas.
4. Escalabilidad ¿Admite el DBMS la cantidad de usuarios y tamaños de bases de datos que intenta
implementar? ¿Cómo se construyen, admiten y mantienen grandes bases de datos, con facilidad o con
mucho dolor? ¿Hay usuarios independientes que puedan confirmar los reclamos de escalabilidad del
proveedor de DBMS?
5. Disponibilidad de herramientas de software de apoyo. ¿Las herramientas de soporte que necesita están
disponibles para el DBMS? Estos elementos pueden incluir herramientas de consulta y análisis,
herramientas de soporte de almacenamiento de datos, herramientas de administración de bases de
datos, herramientas de respaldo y recuperación, herramientas de monitoreo de rendimiento,
herramientas de planificación de capacidad, utilidades de bases de datos y soporte para varios lenguajes
de programación.
6. Técnicos. ¿Hay un suministro suficiente de profesionales de bases de datos calificados para el DBMS?
Considere sus necesidades en términos de DBA, personal de soporte técnico (programadores y
administradores de sistemas, analistas de operaciones, etc.) y programadores de aplicaciones.
7. Coste de propiedad. ¿Cuál es el costo total de propiedad del SGBD? Los proveedores de DBMS cobran
precios increíblemente variables por su tecnología. El costo total de propiedad debe calcularse como una
combinación del costo de la licencia del DBMS, el costo de licencia de cualquier software de soporte
requerido, el costo de los profesionales de bases de datos para programar, respaldar y administrar el
DBMS, y el costo de los recursos informáticos requeridos. para operar el DBMS.
8. Calendario de lanzamiento. ¿Con qué frecuencia el vendedor de DBMS lanza una nueva versión? Algunos
proveedores tienen ciclos rápidos de lanzamiento, con nuevas versiones que salen cada 12 a 18 meses.
Esto puede ser bueno o malo dependiendo de tu enfoque. Si desea funciones de vanguardia, un ciclo de
liberación rápida es bueno. Sin embargo, si su tienda es más conservadora, un DBMS que cambia con
frecuencia puede ser difícil de admitir. Un ciclo de lanzamiento rápido hará que las organizaciones
conservadoras actualicen con más frecuencia de lo que desearían o que vivan con un software DBMS
obsoleto que es poco probable que tenga el mismo nivel de soporte que las versiones más recientes.
9. Clientes de referencia. ¿El proveedor de DBMS suministrará referencias de usuarios actuales? ¿Puede
encontrar otros usuarios por su cuenta que puedan proporcionar respuestas más imparciales? Hable con
los usuarios actuales para obtener problemas e inquietudes que pueda haber pasado por alto. ¿Cómo
está el soporte? ¿El vendedor responde bien a los problemas? ¿Las cosas generalmente funcionan como
se anuncia? ¿Hay muchas correcciones de errores que deben aplicarse continuamente? ¿Cuál es la
calidad de los nuevos lanzamientos? Estas preguntas solo pueden ser respondidas por la gente en las
trincheras.

Al elegir un DBMS, asegúrese de tener en cuenta la complejidad de los productos. El software DBMS es muy
complejo y se está volviendo más complejo con cada nueva versión. La funcionalidad que solía ser
compatible solo con software complementario o programas independientes se agrega cada vez más como
3

características del DBMS, como se muestra en la Figura 2-1. Deberá planificar y respaldar todas las
Página

características del DBMS. Incluso si no existe un requisito actual para ciertas características, una vez que
implemente el DBMS, los programadores y desarrolladores encontrarán una razón para usar casi cualquier
cosa que los proveedores incluyan en el DBMS. Es mejor planificar y estar preparado que permitir el uso de
características sin un plan para respaldarlas.

Figura 2-1. Convergencia de características y funcionalidad en el software DBMS

 datos multimedia
consulta paralela
olap y análisis
extraer datos, transformar y cargar

El Consejo de rendimiento de procesamiento de transacciones

El Transaction Processing Performance Council (TPC) es una organización independiente sin fines de lucro que
administra y administra pruebas de rendimiento de referencia. Su misión es definir el procesamiento de
transacciones y los puntos de referencia de la base de datos para proporcionar a la industria datos de
rendimiento objetivos y verificables. Los puntos de referencia de TPC miden y evalúan las funciones y
operaciones de la computadora.
El TPC propugna una definición comercial de "transacción". Una transacción típica de TPC incluye las
actualizaciones de la base de datos para elementos tales como control de inventario (bienes), reservas de líneas
aéreas (servicios) o banca (dinero). Los puntos de referencia de TPC miden el rendimiento en términos del
número de transacciones que un sistema y una base de datos pueden realizar por unidad de tiempo, por
ejemplo, el número de transacciones por segundo. El TPC define cuatro puntos de referencia:
• TPC-C: carga de trabajo de producción planificada en un entorno de transacción
• TPC-H: procesamiento ad hoc donde las transacciones no son conocidas y predefinidas
• TPC-R: informes comerciales en un entorno de informe de decisiones
• TPC-W: procesamiento de transacciones a través de la Web
Se puede encontrar información adicional y definiciones detalladas de estos puntos de referencia en el sitio web
de TPC en [Link]

Arquitecturas DBMS

La arquitectura de soporte para el entorno DBMS es muy crítica para el éxito de las aplicaciones de bases de
datos. Una elección incorrecta o un componente mal implementado de la arquitectura general puede causar un
rendimiento deficiente, un tiempo de inactividad o aplicaciones inestables.
La arquitectura de soporte para el entorno DBMS es muy crítica para el éxito de las aplicaciones de bases de
datos.
Cuando los mainframes dominaban la informática empresarial, la arquitectura DBMS era una preocupación más
simple. Todo se ejecutó en el mainframe, y eso fue todo. Sin embargo, hoy la infraestructura de TI está
distribuida y es heterogénea. La arquitectura general, incluso para un DBMS de mainframe, probablemente
consistirá en múltiples plataformas y software de sistema inter-operativo. Un equipo formado por expertos en
negocios y TI, en lugar de una sola persona o grupo, debe tomar la decisión final de la arquitectura. Los expertos
en negocios deben incluir representantes de varios departamentos, así como de contabilidad y legales para
asuntos de contratos de software. Representantes de administración de bases de datos (DA, DBA y SA), así
como miembros del grupo de redes, expertos en sistemas operativos, operaciones
personal de control, expertos en programación y cualquier otra parte interesada debería incluirse en este
equipo.
4

Además, asegúrese de que el DBMS que seleccione sea apropiado para la naturaleza y el tipo de procesamiento
Página

que planea implementar. Están disponibles cuatro niveles de arquitectura DBMS: empresarial, departamental,
personal y móvil.
Están disponibles cuatro niveles de arquitectura DBMS: empresarial, departamental, personal y móvil.
Un DBMS empresarial está diseñado para escalabilidad y alto rendimiento. Un DBMS empresarial debe ser capaz
de soportar bases de datos muy grandes, una gran cantidad de usuarios simultáneos y múltiples tipos de
aplicaciones. El DBMS empresarial se ejecuta en una máquina a gran escala, por lo general, un mainframe o un
servidor de gama alta con UNIX, Linux o Windows NT / 2000. Además, un DBMS empresarial ofrece todos los
"detalles" disponibles del proveedor de DBMS. La compatibilidad con multiprocesadores, el soporte para
consultas en paralelo y otras características avanzadas de DBMS serán los componentes principales de un DBMS
empresarial.
Un DBMS departamental, a veces denominado DBMS de un grupo de trabajo, sirve a un término medio. El DBMS
departamental es compatible con grupos de trabajo pequeños y medianos dentro de una organización;
generalmente, se ejecuta en un servidor UNIX, Linux o Windows NT. La línea divisoria entre un servidor de base
de datos departamental y un servidor de base de datos empresarial es bastante gris. Las actualizaciones de
hardware y software pueden permitir que un DBMS departamental aborde tareas que anteriormente solo podían
ser realizadas por un DBMS empresarial. El costo cada vez menor de los componentes de hardware y software
departamentales contribuye aún más a reducir el costo total de operación y permite que el entorno de un grupo
de trabajo se amplíe para servir a la empresa.
Un DBMS personal está diseñado para un solo usuario, generalmente en una plataforma de PC de baja a
mediana potencia. Microsoft Access y Visual dBase son ejemplos de software de base de datos personal. Por
supuesto, los principales proveedores de DBMS también comercializan versiones personales de sus soluciones
más potentes, como Personal Oracle y DB2 Everyplace. A veces, el bajo costo de un SGBD personal causa un
intento equivocado de elegir un SGBD personal para una solución departamental o empresarial. Sin embargo, no
te dejes atrapar por el bajo costo. Un producto DBMS personal es adecuado solo para proyectos de muy
pequeña escala y nunca se debe implementar para aplicaciones multiusuario.
Finalmente, el DBMS móvil es una versión especializada de un DBMS departamental o empresarial. Está
diseñado para usuarios remotos que generalmente no están conectados a la red. El DBMS móvil permite
acceso y modificación de la base de datos local en una computadora portátil o dispositivo portátil. Además, el
DBMS móvil proporciona un mecanismo para sincronizar los cambios de la base de datos remota a una empresa
centralizada o servidor de base de datos departamental.
Un DBMS diseñado para un tipo de procesamiento puede ser inadecuado para otros usos. Por ejemplo, un DBMS
personal no está diseñado para múltiples usuarios, y un DBMS empresarial generalmente será demasiado
complejo para usuarios individuales. Asegúrese de comprender la diferencia entre el software DBMS
empresarial, departamental, personal y móvil, y elija el DBMS apropiado para sus necesidades específicas de
procesamiento de datos. Es posible que deba elegir varios tipos de DBMS, es decir, un DBMS para cada nivel,
con un uso determinado por las necesidades de cada proyecto de desarrollo.
Si su organización requiere soluciones DBMS en diferentes niveles, favorezca la selección de un grupo de
soluciones DBMS del mismo proveedor siempre que sea posible. Al hacerlo, se minimizarán las diferencias en el
acceso, desarrollo y administración. Por ejemplo, favorezca Personal Oracle para sus necesidades de DBMS para
un solo usuario si su organización utiliza Oracle como el DBMS empresarial de su elección.

Agrupamiento de DBMS

La agrupación en clústeres es el uso de múltiples sistemas de computación "independientes" que trabajan

juntos como un único sistema altamente disponible. Un DBMS moderno ofrece soporte de clustering para
mejorar la disponibilidad y la escalabilidad. Las dos arquitecturas predominantes para clustering son shared-disk
y shared-nothing. Estos nombres hacen un buen trabajo al describir la naturaleza de la arquitectura, al menos
en un nivel alto.
Un DBMS moderno ofrece soporte de clustering para mejorar la disponibilidad y la escalabilidad.
En la figura 2-2 se muestra la agrupación de nada compartido. En una arquitectura compartida, cada sistema
tiene sus propios recursos privados (memoria, discos, etc.). Los procesadores agrupados se comunican pasando
mensajes a través de una red que interconecta las computadoras. Además, las solicitudes de los clientes se
enrutan automáticamente al sistema que posee el recurso. Solo uno de los sistemas agrupados puede "poseer"
y acceder a un recurso en particular a la vez. En caso de que ocurra una falla, la propiedad del recurso se puede
transferir dinámicamente a otro sistema en el clúster. La principal ventaja de la agrupación compartida-nada es
la escalabilidad. En teoría, un multiprocesador compartido no puede escalar hasta miles de procesadores porque
5

no interfieren entre sí, no se comparte nada.

Página

Figura 2-2. Arquitectura de nada compartido

La principal ventaja de la agrupación compartida-nada es la escalabilidad.
En un entorno de disco compartido, todos los sistemas conectados comparten los mismos dispositivos de disco,
como se muestra en la Figura 2-3. Cada procesador todavía tiene su propia memoria privada, pero todos los
procesadores pueden direccionar directamente todos los discos. Normalmente, los clústeres de discos
compartidos no se escalan tan bien para máquinas más pequeñas como clústeres compartidos. La agrupación
en clúster compartido se adapta mejor al procesamiento de grandes empresas en un entorno de mainframe. Los
mainframes, procesadores muy grandes, son capaces de procesar enormes volúmenes de trabajo. Se pueden
obtener grandes beneficios con solo unos pocos mainframes agrupados, mientras que muchos procesadores de
PC y de rango medio tendrían que agruparse para obtener beneficios similares.

Figura 2-3. Arquitectura de disco compartido

La agrupación en clúster compartido se adapta mejor al procesamiento de grandes empresas en un entorno de

mainframe.
Generalmente, la agrupación en clúster compartido es preferible para aplicaciones y servicios que requieren solo
un acceso compartido modesto a datos y para aplicaciones o cargas de trabajo que son muy difíciles de
particionar. Es probable que las aplicaciones con requisitos de actualización de datos pesados se implementen
mejor como compartidas, nada. La Tabla 2-3 compara las capacidades de las arquitecturas de disco compartido
y de nada compartido.

Tabla 2-3. Comparación de arquitecturas de disco compartido y de nada compartido

Disco compartido Compartido-nada
Adaptabilidad rápida a cargas de Puede explotar hardware más simple y barato
trabajo cambiantes
Alta disponibilidad Escalabilidad casi ilimitada
Se desempeña mejor en un entorno de Funciona bien en un entorno de lectura y
lectura pesado escritura de alto volumen

Los datos no necesitan ser Los datos se particionan en el clúster

particionados

Los principales proveedores de DBMS brindan soporte para diferentes tipos de clustering con diferentes
capacidades y requisitos. Por ejemplo, DB2 para OS / 390 proporciona clústeres de discos compartidos con sus
capacidades para compartir datos y Parallel Sysplex; DB2 Extended Enterprise Edition en plataformas que no
6

son de marco principal utiliza clústeres compartidos. Los Real Application Clusters de Oracle9i proporcionan
Página

clústeres de discos compartidos.

Para la mayoría de los usuarios, el beneficio principal de la agrupación es la disponibilidad mejorada que se
acumula al combinar procesadores. En algunos casos, la agrupación puede ayudar a una empresa a alcanzar la
disponibilidad de cinco nueves (99,999%). Además, la agrupación en clúster se puede usar para equilibrar la
carga y conmutar por error.
Proliferación DBMS

Como regla general, cree una política (o al menos algunas pautas simples) que deben seguirse antes de que un
nuevo DBMS pueda incorporarse a la organización. De lo contrario, puede causar una proliferación de diferentes
productos DBMS que serán difíciles de admitir. También puede causar confusión con respecto a qué DBMS usar
para qué esfuerzo de desarrollo.
Una proliferación de diferentes productos DBMS puede ser difícil de soportar.
Como se mencionó anteriormente, hay una gran cantidad de proveedores DBMS, cada uno promociona sus
beneficios. Como DBA, será bombardeado con esfuerzos de marketing y ventas tratando de convencerlo de que
necesita otro DBMS. Intenta resistir a menos que se dé una razón muy convincente y se pueda demostrar un
retorno de la inversión (ROI) a corto plazo. Incluso cuando se enfrenta a razones válidas y buen retorno de la
inversión, asegúrese de
compruebe dos veces los argumentos y los cálculos de ROI. A veces, los motivos especificados están
desactualizados y las cifras de ROI no tienen en cuenta todo, como el costo adicional de administración.
Recuerde, cada DBMS requiere soporte de administración de base de datos. Además, cada DBMS usa diferentes
métodos para realizar tareas similares. Cuantos menos productos DBMS haya instalados, menos complicada se
vuelve la administración de la base de datos, y mejores serán sus posibilidades de proporcionar recursos
efectivos de administración de datos para su organización.

Problemas de hardware

Al establecer un entorno de base de datos para el desarrollo de aplicaciones, seleccionar el DBMS es solo una
parte de la ecuación. El hardware y el sistema operativo en el que se ejecutará el DBMS tendrán un gran
impacto en la confiabilidad, disponibilidad y escalabilidad (RAS) del entorno de la base de datos. Por ejemplo,
una plataforma de mainframe como IBM z900 que ejecute z / OS probablemente proporcionará un RAS más alto
que un IBM RS / 6000 de rango medio que ejecute AIX, que a su vez probablemente superará una Servidor de
COMPAQ que ejecuta Windows 2000. Eso no quiere decir que todo deba ejecutarse en un mainframe: se deben
considerar otros problemas como el costo, la experiencia, la capacidad de administración y las necesidades de
las aplicaciones que se desarrollarán. La conclusión es que debe asegurarse de tener en cuenta las restricciones
de la plataforma de hardware y del sistema operativo en los criterios de selección de DBMS. Factorizar la
plataforma de hardware y las restricciones del sistema operativo en los criterios de selección de DBMS.

Instalando el DBMS
Una vez que se haya elegido el DBMS, deberá instalarlo. Instalar un DBMS no es tan simple como abrir un CD en
una unidad y dejar que el software se instale. (O para la gente de mainframe, solo usa IEBGENER para copiarlo
de una cinta). Un DBMS es una pieza compleja de software que requiere una planificación inicial para que la
instalación sea exitosa. Deberá comprender los requisitos de DBMS y preparar el entorno para el nuevo DBMS.

Conceptos básicos de instalación de DBMS

Lo primero que debe hacer cuando instala un DBMS por primera vez es comprender los requisitos previos. Cada
DBMS viene con un manual de instalación o una guía que contiene una lista de los requisitos operativos que se
deben cumplir para que el DBMS funcione correctamente. Algunos ejemplos de requisitos previos incluyen
garantizar que se utiliza una versión adecuada del sistema operativo, verificando que existe
memoria suficiente para admitir el DBMS y garantizar que cualquier software relacionado que se use con el
DBMS sea la versión y el nivel de mantenimiento correctos.
Una vez cubiertos los conceptos básicos, lea la guía de instalación de principio a fin. Asegúrese de comprender
el proceso antes incluso de comenzar a instalar el DBMS. Deben hacerse bastantes preparativos antes de
instalar un DBMS, y leer sobre ellos antes de comenzar garantizará una instalación exitosa. Revise cómo
funciona el programa de instalación o la rutina para el DBMS y siga las instrucciones explícitas en la guía de
instalación provista con el software DBMS.
Lea la guía de instalación de principio a fin.
El resto de esta sección discutirá algunas de las preparaciones comunes que se requieren antes de que se
pueda instalar un DBMS. Si el DBMS ya está en funcionamiento y planea migrar a una nueva versión de DBMS,
consulte la sección "Actualización de versiones y versiones de DBMS" de este capítulo.
7

Requisitos de hardware
Página

Cada DBMS tiene un requisito básico de CPU, es decir, una versión de CPU y una velocidad de procesador
mínima requerida para que el DBMS funcione. Además, algunos DBMS especifican los modelos de hardware que
son necesarios o no. Por lo general, el criterio de la CPU será suficiente para un entorno Intel, pero en un entorno
de mainframe o servidor de empresa, el modelo de la máquina puede marcar una diferencia con respecto a las
características de DBMS admitidas. Por ejemplo, ciertas máquinas tienen un firmware incorporado que puede ser
explotado por el DBMS si el firmware está disponible.
Además, cada DBMS ofrece diferentes "sabores" de su software para necesidades específicas. (Utilizo "sabor" en
lugar de "versión" o "lanzamiento", que especifican diferentes iteraciones del mismo DBMS). Diferentes sabores
del DBMS (en el mismo nivel de versión) están disponibles para entornos específicos, como el procesamiento
paralelo, omnipresente informática (como dispositivos portátiles), almacenamiento de datos y / o informática
móvil. Asegúrese de elegir el DBMS correcto para sus necesidades y de adaptar su hardware a los requisitos del
DBMS.
Elija el DBMS correcto para sus necesidades y haga coincidir su hardware con los requisitos del DBMS.

Requisitos de almacenamiento

Un DBMS requiere almacenamiento en disco para ejecutarse. Y no solo por la razón obvia: para crear bases de
datos que almacenen datos. Un DBMS utilizará el almacenamiento en disco para que los índices se definan en
las bases de datos, así como para los siguientes elementos:

1. El catálogo del sistema o diccionario de datos utilizado por el DBMS para administrar y rastrear bases de
datos e información relacionada. Cuantos más objetos de base de datos planee crear, mayor será la
cantidad de almacenamiento requerida por el catálogo del sistema.
2. Cualquier otra base de datos del sistema requerida por el DBMS, por ejemplo, para admitir conexiones
distribuidas o herramientas de administración.
3. Archivos de registro que registran todos los cambios realizados en cada base de datos. Esto incluye
registros activos, registros de archivo, segmentos de reversión y cualquier otro tipo de registro de
cambios requerido por el DBMS.
4. Arranque o controle los archivos a los que el DBMS debe acceder cuando se inician o inicializan.
5. Los archivos de trabajo utilizados por el DBMS para ordenar los datos o para otras necesidades de
procesamiento.
6. Bases de datos predeterminadas utilizadas por el DBMS para las estructuras del sistema o como un
catchall predeterminado para nuevos objetos de base de datos a medida que se crean.
7. Las estructuras de bases de datos temporales utilizadas por el SGBD (o por las aplicaciones que acceden
a las bases de datos) para los datos transitorios que no son necesarios para ser persistentes pero que
requieren almacenamiento reservado durante las operaciones.
8. Sistema de volcado y error de procesamiento de archivos.
9. Las bases de datos de DBA se utilizan para la administración, la supervisión y el ajuste; por ejemplo, las
bases de datos de DBA utilizadas para probar nuevas versiones, secuencias de comandos de migración,
etc.

Asegúrese de tener en cuenta todos los requisitos de almacenamiento del DBMS y reserve el almacenamiento
adecuado para su uso. Además, tenga en cuenta que el DBMS utilizará muchas de estas bases de datos y
estructuras de archivos al mismo tiempo. Por lo tanto, es una buena idea planear el uso de varios dispositivos de
almacenamiento, incluso si no los llena a su capacidad. La correcta ubicación de la base de datos y el archivo
permitirá que el DBMS funcione de manera más eficiente porque el disco físico no restringirá las actividades
concurrentes a medida que se accede a los datos.
Factor en cada requisito de almacenamiento del DBMS y reserve el almacenamiento apropiado para su uso.
El almacenamiento en disco no es el único requisito de un DBMS. También se requieren cintas para tareas tales
como copias de seguridad de bases de datos y descarga de registros. Cuando el archivo de registro activo se
llena, los registros de registro se deben descargar a un archivo de registro ya sea en disco o en cinta, como se
muestra en la Figura 2-4. Según el DBMS utilizado y las características que se hayan activado, este proceso
puede ser automático o
manual. Los archivos de registro de archivo deben conservarse para fines de recuperación, e incluso si se
almacenaron originalmente en el disco, finalmente se deben migrar a cinta.
Figura 2-4. Descarga de registro
8 Página

Planifique el mantenimiento de varias unidades de cinta para permitir que el DBMS ejecute varios procesos
simultáneos que requieren cinta, como copias de seguridad de bases de datos simultáneas. Se pueden producir
interrupciones en la base de datos si realiza un único subproceso de las tareas de copia de seguridad de la base
de datos con una sola unidad de cinta.

Requisitos de memoria

Los DBMS relacionales, así como sus bases de datos y aplicaciones, aman la memoria. Un DBMS requiere
memoria para la funcionalidad básica y la usará para la mayoría de los procesos internos, como mantener el
área global del sistema y realizar muchas tareas de DBMS.
Un DBMS requiere una gran cantidad de memoria para almacenar en caché los datos en estructuras de memoria
para evitar E / S. Leer datos desde un dispositivo de almacenamiento en disco siempre es más caro y más lento
que mover los datos en la memoria. La Figura 2-5 muestra cómo el DBMS usa una estructura de memoria
llamada grupo de almacenamiento intermedio o memoria caché de datos para reducir las solicitudes físicas de E
/ S. Al almacenar en caché datos que se leen en un grupo de búferes, el DBMS puede evitar E / S para solicitudes
posteriores de los mismos datos, siempre que permanezca en el grupo de búferes. En general, cuanto mayor
sea el grupo de búferes, más tiempo podrán permanecer en la memoria los datos y mejor será el procesamiento
general de la base de datos.

Figura 2-5. Buffer pool (o caché de datos)

Además de los datos, el DBMS almacenará en caché otras estructuras en la memoria. La mayoría de los SGBD
reservan memoria para almacenar estructuras de programas requeridas por el SGBD para procesar solicitudes
de bases de datos. [1] La memoria caché del programa almacenará cosas como sentencias de SQL
"compiladas", autorizaciones de base de datos y bloques de estructura de base de datos que son utilizados por
los programas a medida que se ejecutan. Al almacenar en caché estas estructuras, el procesamiento de la base
de datos se puede optimizar evitando las solicitudes de E / S adicionales para acceder a ellas desde un
dispositivo de almacenamiento físico.
[1] En DB2, el área utilizada para el almacenamiento en caché de las estructuras del programa en la memoria se
conoce como grupo EDM. En SQL Server se llama SQL Cache, y en Oracle se usan dos estructuras, PGA y el
grupo compartido en SGA.
Por lo general, el DBMS requiere memoria para admitir otras funciones como el manejo de solicitudes de
bloqueo, facilitar solicitudes de datos distribuidos, clasificar datos, optimizar procesos y procesar SQL.
Asegúrese de que el DBMS tenga a su disposición un suministro de memoria más que adecuado. Esto ayudará a
optimizar el procesamiento de la base de datos y minimizar los posibles problemas.
Asegúrese de que el DBMS tenga a su disposición un suministro de memoria más que adecuado.

Configurando el DBMS

La configuración de los parámetros del sistema del DBMS controla la manera en que funciona el DBMS y los
recursos puestos a su disposición. [2] Cada DBMS permite que los parámetros de su sistema se modifiquen de
9

diferentes maneras, pero el proceso de instalación generalmente establece los parámetros del sistema DBMS
Página

por medio de botones de radio, menús o selecciones de paneles. Durante el proceso de instalación, la entrada
proporcionada al script de instalación se usará para establecer la configuración inicial de los parámetros del
sistema.
[2] En DB2, los parámetros del sistema se establecen al ensamblar el miembro DSNZPARM. SQL Server usa el
procedimiento del sistema SP_CONFIGURE para establecer los parámetros del sistema, y los parámetros de
Oracle se controlan usando [Link].
Cada DBMS también proporciona un método para cambiar los parámetros del sistema una vez que el DBMS está
operativo. Algunas veces puede usar comandos DBMS para establecer los parámetros del sistema; a veces debe
editar un archivo que contiene la configuración de parámetros del sistema actual. Si debe editar un archivo,
tenga mucho cuidado: una configuración errónea del parámetro del sistema puede ser fatal para el estado
operativo del DBMS.
Cada DBMS también proporciona un método para cambiar los parámetros del sistema una vez que el DBMS está
operativo.
¿Qué controlan los parámetros del sistema? Bueno, por ejemplo, los parámetros del sistema controlan la
autorización de DBA para el DBMS y la cantidad de registros activos de la base de datos; los parámetros del
sistema establecen la cantidad de memoria utilizada para el almacenamiento en caché de datos y programas, y
activan o desactivan las funciones de DBMS. Aunque cada DBMS tiene parámetros del sistema que controlan su
funcionalidad, cada DBMS tiene un método diferente para establecer y cambiar los valores. Y, de hecho, cada
DBMS tiene diferentes "cosas" que se pueden establecer utilizando los parámetros del sistema.
Asegúrese de comprender completamente los parámetros utilizados por su DBMS. De lo contrario, se puede
generar un entorno de base de datos configurado incorrectamente, lo que puede ocasionar problemas de
rendimiento, problemas de integridad de datos o incluso la falla del DBMS.

Conexión del DBMS al software de infraestructura de soporte

Parte del proceso de instalación de DBMS es la conexión del DBMS a otros componentes del software del
sistema que deben interactuar con el DBMS. El software de infraestructura típico que puede necesitar
configurarse para trabajar con el DBMS incluye redes, monitores de procesamiento de transacciones, colas de
mensajes, otros tipos de middleware, lenguajes de programación, software de administración de sistemas,
software de control de operaciones y operaciones, servidores web y servidores de aplicaciones.
Cada pieza de software de infraestructura de soporte tendrá diferentes requisitos para interactuar con el DBMS.
Los procedimientos de configuración típicos pueden incluir la instalación de archivos DLL, la creación de nuevos
archivos de parámetros para establecer conexiones y, posiblemente, la revisión de los procedimientos de
instalación para que el software compatible instale los componentes necesarios para interactuar con el DBMS.
Cada pieza de software de infraestructura de soporte tendrá diferentes requisitos para interactuar con el DBMS.

Verificación de instalación

Después de instalar DBMS, debe ejecutar una batería de pruebas para verificar que el DBMS se haya instalado y
configurado correctamente. La mayoría de los proveedores DBMS ofrecen programas de muestra para este
propósito. Además, puede garantizar la instalación correcta probando las interfaces estándar al DBMS. Una
interfaz estándar admitida por la mayoría de los DBMS es una interfaz SQL interactiva en la que puede enviar
declaraciones SQL directamente al DBMS. [3]
[3] En DB2, la interfaz SQL se conoce como SPUFI. SQL Server llama a la interfaz ISQL, y al usar Oracle puede
optar por enviar SQL utilizando SQL * Plus o la hoja de cálculo SQL en Oracle Enterprise Manager.
Cree un conjunto de código SQL que comprenda sentencias SELECT, INSERT, UPDATE y DELETE emitidas contra
bases de datos de muestra. Ejecutar dicho script después de la instalación le ayuda a verificar que el DBMS esté
instalado correctamente y funcionando como se espera.
Además, asegúrese de verificar que todas las conexiones requeridas al software de soporte estén operativas y
funcionen correctamente. Si el proveedor de DBMS no proporciona programas de ejemplo, es posible que deba
crear y ejecutar programas de prueba simples para cada entorno a fin de garantizar que las conexiones de
software de soporte funcionen correctamente con el DBMS.

Entornos DBMS

En general, instalar un DBMS implica más que simplemente instalar una instancia o subsistema. Para soportar el
desarrollo de bases de datos, el DBA necesita crear múltiples entornos DBMS para soportar, por ejemplo,
pruebas, aseguramiento de la calidad, integración y trabajo de producción. Por supuesto, es posible admitir
múltiples entornos en una única instancia de DBMS, pero no es prudente. Varias instalaciones de DBMS son
preferibles para admitir múltiples entornos de desarrollo para una única base de datos. Esto minimiza los
problemas de migración y no requerirá convenciones complejas para nombrar las bases de datos. Además,
segregar las instancias de la base de datos facilita la prueba, el ajuste y la supervisión.
1Página

Actualización de versiones y versiones de DBMS

El cambio es una realidad, y cada uno de los principales productos DBMS cambia con bastante rapidez. Un ciclo
de lanzamiento típico para el software DBMS es de 12 a 18 meses para las principales versiones, con
correcciones de errores constantes y actualizaciones de mantenimiento entre los principales lanzamientos. De
hecho, mantener el software DBMS actualizado puede ser un trabajo de tiempo completo. El cambio es un hecho
de la vida. El administrador de bases de datos debe desarrollar un enfoque para actualizar el software DBMS que
se ajuste a las necesidades de la organización y minimice las interrupciones del negocio debido a interrupciones
y falta de disponibilidad de la base de datos. Puede haber notado que uso la versión de términos y la versión de
manera intercambiable. Eso está bien para una discusión amplia de las actualizaciones DBMS, pero se justifica
una definición más precisa. Para una mejor discusión de las diferencias entre una versión y una versión, consulte
la barra lateral. Una actualización de la versión de DBMS se puede considerar como un caso especial de una
nueva instalación. Todos los procedimientos requeridos para una nueva instalación se aplican a una
actualización: debe planificar los recursos apropiados, reconsiderar todos los parámetros del sistema y
asegurarse de que todo el software de soporte esté conectado adecuadamente. Sin embargo, se debe planear
otro problema serio para los usuarios y las aplicaciones existentes. Es necesario planificar una actualización para
causar la menor interrupción posible a los usuarios existentes. Por lo tanto, la actualización puede ser una tarea
complicada y difícil.

Versión o lanzamiento?
Los vendedores suelen hacer una distinción entre una versión y una versión de un producto de software.
Una nueva versión de software es una gran preocupación, con muchos cambios y nuevas características.
Una versión es stipically menor, con menos cambios y no tantas nuevas características.
Por ejemplo, pasar de la Versión 7 de Oracle a Oracle8 fue un cambio importante, un cambio de versión.
Sin embargo, un punto intermedio como Oracle8.2 se consideraría un lanzamiento, que consiste en un
número menor de cambios. Por lo general, los proveedores de DBMS aumentarán los precios de las
versiones, pero no necesariamente de las versiones (pero esa no es una regla difícil).
Por lo general, se agrega una funcionalidad significativa para las actualizaciones de la versión, y menos
para las versiones puntuales. Sin embargo, la actualización de un punto a otro puede tener tantas
trampas potenciales como actualizaciones de versión. Depende de la naturaleza de las nuevas funciones
proporcionadas en cada
lanzamiento específico.
Los problemas e inquietudes discutidos en este capítulo se refieren a ambos tipos de actualizaciones de
DBMS: a una nueva versión y a una nueva versión.

En un entorno de base de datos complejo, heterogéneo y distribuido, es esencial una estrategia de actualización
coherente. A decir verdad, incluso las organizaciones con un solo DBMS deben acercarse a las actualizaciones
de DBMS con cautela y planificar en consecuencia. Si no se planifica una actualización de DBMS puede resultar
en la adopción inadecuada e ineficiente de nuevas características, la degradación del rendimiento de las
aplicaciones nuevas y existentes, y el tiempo de inactividad.
La actualización a una nueva versión de DBMS ofrece recompensas y riesgos. Los siguientes son algunos de los
beneficios de pasar a una nueva versión.
1. Los desarrolladores pueden aprovechar las nuevas características y funcionalidades entregadas solo en
la nueva versión. Si el desarrollo requiere una nueva característica, o simplemente puede beneficiarse de
una nueva característica, el tiempo de desarrollo del programa puede reducirse o hacerse más rentable.
2. Para las aplicaciones compradas, el vendedor de la aplicación puede requerir una versión o versión
específica de DBMS para versiones específicas de su aplicación para habilitar la funcionalidad específica
dentro de la aplicación.
3. Las nuevas versiones de DBMS generalmente ofrecen funciones mejoradas de rendimiento y
disponibilidad que pueden optimizar las aplicaciones existentes. A veces, se requiere una nueva versión
de DBMS para escalar las aplicaciones para admitir usuarios adicionales o grandes cantidades de datos.
4. Los proveedores de DBMS a menudo brindan un mejor soporte y responden a los problemas más
rápidamente para una nueva versión de su software. Los proveedores de DBMS son reacios a permitir
una mala publicidad sobre los errores en una versión nueva y altamente promocionada de sus productos.
5. La migración de la producción a una nueva versión de DBMS alineará los entornos de prueba y de base
de datos de producción, proporcionando así un entorno coherente para el desarrollo y la implementación.
Si una versión nueva se está ejecutando en el entorno de prueba durante demasiado tiempo, la
administración de la base de datos y las tareas de desarrollo de aplicaciones se vuelven más difíciles
porque las bases de datos de prueba operarán de manera diferente que las bases de datos de
producción.
1

Sin embargo, una estrategia efectiva de actualización de DBMS debe equilibrar los beneficios con los riesgos de
Página

la actualización para llegar a la mejor línea de tiempo para migrar a una nueva versión o lanzamiento de DBMS.
Los riesgos de actualizarse a una nueva versión de DBMS incluyen lo siguiente.
Una estrategia de actualización de DBMS efectiva debe equilibrar los beneficios con los riesgos de actualización.

1. Una actualización al DBMS generalmente implica algún nivel de interrupción en las operaciones
comerciales. Como mínimo, las bases de datos no estarán disponibles mientras se esté actualizando el
 DBMS. Esto puede ocasionar tiempo de inactividad y la pérdida de oportunidades comerciales si la
actualización del DBMS ocurre durante el horario comercial normal (o si no hay un tiempo de inactividad
planificado). Las implementaciones de bases de datos en clúster pueden permitir cierta disponibilidad de
la base de datos mientras que los clústeres de bases de datos individuales se migran a la nueva versión
del DBMS.
2. Pueden ocurrir otras interrupciones, como tener que convertir las estructuras de la base de datos o
descubrir que las características previamente compatibles se eliminaron de la nueva versión (causando
así errores de aplicación). Las demoras en los plazos de implementación de la aplicación son otra
posibilidad.
3. El costo de una actualización puede ser una barrera importante para la migración de la versión de DBMS.
En primer lugar, se debe presupuestar el costo de la nueva versión o versión (los aumentos de precio
para una nueva versión de DBMS pueden ascender a entre un 10% y un 25%). El costo de actualización
también debe tener en cuenta los costos de planificación, instalación, prueba e implementación no solo
del DBMS sino también de cualquier aplicación que utilice bases de datos. Por último, asegúrese de
incluir el costo de los recursos nuevos (como memoria, almacenamiento, CPU adicionales) necesarios
para utilizar las nuevas características entregadas por la nueva versión del DBMS.
4. Los proveedores de DBMS usualmente pregonan las ganancias de rendimiento que se pueden lograr con
una nueva versión. Sin embargo, cuando cambian las técnicas de optimización de SQL, es posible que
una nueva versión de DBMS genere rutas de acceso SQL que funcionan peor que antes. Los DBA deben
implementar un riguroso proceso de prueba para garantizar que las nuevas rutas de acceso ayuden, sin
perjudicar, el rendimiento de la aplicación. Cuando el rendimiento sufre, puede ser necesario cambiar el
código de la aplicación, un esfuerzo muy costoso y lento. Un proceso de prueba riguroso debería poder
detectar la mayoría de los cambios en la ruta de acceso en el entorno de prueba.
5. Para aprovechar las mejoras implementadas en una nueva versión de DBMS, el DBA puede tener que
aplicar algunos cambios invasivos. Por ejemplo, si la nueva versión aumenta el tamaño máximo para un
objeto de base de datos, el DBA puede tener que soltar y volver a crear ese objeto para aprovechar el
nuevo máximo. Este será el caso cuando el DBMS agregue estructuras de control interno para facilitar
tales cambios.
6. Es posible que los productos de software compatibles carezcan de soporte inmediato para una nueva
versión de DBMS. El software de soporte incluye el sistema operativo, los procesadores de transacciones,
las colas de mensajes, la aplicación comprada, las herramientas de DBA, las herramientas de desarrollo y
el software de consultas e informes.

Después de sopesar los beneficios de la actualización frente a los riesgos de una nueva versión de DBMS, el
grupo de DBA debe crear un plan de actualización que funcione para la organización. Algunas veces la decisión
será
actualice inmediatamente después de la disponibilidad, pero a menudo hay un desfase entre la disponibilidad
general de un nuevo lanzamiento y su adopción generalizada.
Cuando los riesgos de una nueva versión superan los beneficios, algunas organizaciones pueden optar por omitir
una versión intermedia si hacerlo no afecta una futura actualización. Por ejemplo, una buena cantidad de
clientes de Oracle migraron directamente de Oracle7 a Oracle8i, omitiendo Oracle8. Si el proveedor de DBMS no
permite a los usuarios omitir una versión o versión, todavía es posible "omitir" una versión esperando a
implementar esa versión hasta que la próxima versión esté disponible.
Por ejemplo, considere la siguiente situación:

ABC Corporation está utilizando DB Version 5 de DBCorp.

DBCorp anuncia la versión 6 de DB.
ABC Corporation analiza las características y riesgos y determina no actualizar de inmediato.
DBCorp luego anuncia DB Version 7 y que no se proporcionará una ruta de migración directa desde la
Versión 5 a la Versión 7.
ABC Corporation decide que DB Version 7 ofrece muchas funciones útiles y desea actualizar su versión
actual de la versión 5 de DB. Sin embargo, no tienen una razón convincente para implementar y usar la
Versión 6 por primera vez.
Para cumplir con sus requisitos, ABC Corporation primero actualiza la Versión 5 a la Versión 6 y luego
actualiza inmediatamente la Versión 6 a la Versión 7.
1Página

Aunque una actualización de lanzamiento múltiple lleva más tiempo, permite a los clientes controlar de manera
efectiva cuándo y cómo migrarán a las nuevas versiones de un DBMS en lugar de ser retenidos por el proveedor
de DBMS. Al intentar una actualización de versiones múltiples de este tipo, asegúrese de comprender
completamente las características y funcionalidades agregadas por el proveedor de DBMS para cada versión
provisional. En el caso de ABC Corporation anterior, los DBA necesitarán investigar y prepararse para las nuevas
características no solo de la Versión 7 sino también de la Versión 6.
Una actualización de lanzamiento múltiple permite a los clientes controlar de manera efectiva cuándo y cómo
migrarán a las nuevas versiones de un DBMS.
Una estrategia apropiada de actualización de DBMS depende de muchas cosas. Las siguientes secciones
describen los problemas que se deben tener en cuenta en una estrategia efectiva de actualización de la versión
de DBMS.

Características y Complejidad

Quizás el factor más importante para determinar cuándo y cómo actualizar a una nueva versión de DBMS es la
funcionalidad admitida por la nueva versión. Estrechamente unida a la funcionalidad es la complejidad inherente
involucrada en el soporte y la administración de nuevas características. Es más difícil retrasar una actualización
si los desarrolladores de aplicaciones claman por nuevas características de DBMS. Si la funcionalidad de DBMS
puede minimizar el costo y el esfuerzo del desarrollo de la aplicación, el grupo de DBA sentirá la presión de
migrar rápidamente a la nueva versión. Un factor adicional que forzará la rápida adopción de una nueva versión
es cuando los problemas DBMS se solucionan en la nueva versión (en lugar de a través de arreglos de
mantenimiento regulares). Independientemente de las "alarmas y pitidos" de una nueva versión, deben
abordarse ciertos detalles de administración e implementación antes de la actualización. El grupo de DBA debe
asegurarse de que los estándares se modifiquen para incluir las nuevas características, educar a los
desarrolladores y usuarios sobre cómo funcionan y deben usarse las nuevas características, y preparar la
infraestructura para admitir la nueva funcionalidad de DBMS. El tipo de cambios necesarios para admitir la
nueva funcionalidad debe tenerse en cuenta en la estrategia de actualización. Cuando el proveedor de DBMS
realiza cambios en estructuras internas, diseños de página de datos o espacios de direcciones, los riesgos de
actualización son mayores. Se requieren pruebas adicionales en estas situaciones para garantizar que las
utilidades de la base de datos, las herramientas de DBA y las herramientas de extracción y movimiento de datos
sigan funcionando con las estructuras internas revisadas.

Complejidad del entorno DBMS

Cuanto más complejo sea el entorno de su base de datos, más difícil será actualizar a una nueva versión de
DBMS. El primer problema de complejidad es el tamaño del entorno. Mientras mayor sea el número de
servidores de bases de datos, instancias, aplicaciones y usuarios, mayor será la complejidad. Las
preocupaciones adicionales incluyen el tipo de aplicaciones que son compatibles. Una actualización de DBMS es
más fácil de implementar si solo se trata de aplicaciones simples basadas en lotes. A medida que aumentan los
requisitos de complejidad y disponibilidad de las aplicaciones, la dificultad de actualización también aumenta.
La ubicación de los servidores de la base de datos también afecta la estrategia de actualización de la versión. Es
difícil planificar e implementar una actualización de DBMS en múltiples servidores de bases de datos en varias
ubicaciones que soportan diferentes líneas de negocios. Es probable que una estrategia de actualización
implique períodos de compatibilidad con múltiples versiones del DBMS en diferentes ubicaciones y para
diferentes aplicaciones. Si es posible, se deben evitar las diferentes versiones de producción, pero eso no
siempre es posible.
Finalmente, se debe considerar la complejidad de las aplicaciones que acceden a sus bases de datos. Cuanto
más complejas sean sus aplicaciones, más difícil será asegurar su funcionalidad ininterrumpida continua cuando
se modifique el DBMS. Los problemas de complejidad incluyen lo siguiente:
1. Uso de procedimientos almacenados y funciones definidas por el usuario.
2. Complejidad del SQL: cuantas más tablas involucradas en el SQL y más complejas sean las funciones de
SQL, más difícil será asegurar que los cambios en la ruta de acceso no afecten el rendimiento.
3. El procesamiento del cliente / servidor: el uso de la red y el uso de varios niveles complica la prueba de la
nueva versión de DBMS.
4. La integración con otro software de infraestructura, como las colas de mensajes y los procesadores de
transacciones, puede complicar la migración porque es posible que se necesiten nuevas versiones de
estos productos para admitir la nueva versión de DBMS.
5. El lenguaje utilizado por los programas también podría afectar la migración de la versión de DBMS debido
a la compatibilidad diferente para las versiones de compilación, los cambios a las API o las nuevas formas
de incorporar SQL en los programas de aplicación.
1

Reputación del proveedor DBMS

Página

Los proveedores de DBMS tienen diferentes reputaciones de soporte técnico, corrige errores y responden a
problemas, por lo que las referencias de los clientes son tan importantes al elegir una base de datos.
Cuanto mejor sea la reputación del proveedor, mayor será la probabilidad de que las organizaciones adopten
rápidamente una nueva versión. Si el proveedor de DBMS es bueno respondiendo a los problemas y apoyando a
sus clientes mientras migran a nuevos lanzamientos, entonces sus clientes participarán más activamente en las
actividades de migración. Cuanto mejor sea la reputación del proveedor, mayor será la probabilidad de que las
organizaciones adopten rápidamente una nueva versión.

Políticas de soporte del DBMS

A medida que se introducen nuevos lanzamientos, los proveedores de DBMS retirarán lanzamientos anteriores y
ya no los admitirán. El tiempo durante el cual el proveedor de DBMS admitirá una versión anterior debe tenerse
en cuenta en la estrategia de migración de la versión de DBMS. Nunca debe ejecutar una versión de DBMS en
producción que ya no sea compatible con el proveedor. Si se producen problemas, el proveedor de DBMS no
podrá resolver ningún problema para usted. A veces, un proveedor DBMS brindará soporte para una versión
retirada en una base especial y con un aumento en el costo de mantenimiento. Si absolutamente debe continuar
utilizando una versión de DBMS retirada (por cuestiones comerciales o de aplicaciones), asegúrese de investigar
las políticas del proveedor de DBMS con respecto al soporte para versiones retiradas de su software.

Estilo de organización

Cada organización muestra características que revelan su estilo cuando se trata de adoptar nuevos productos y
tecnologías. Los analistas de la industria en el Grupo Gartner clasificaron las organizaciones en tres grupos
distintos etiquetados como tipos A, B y C. Una empresa tipo A está impulsada por la tecnología y, como tal, es
más probable que arriesgue el uso de tecnologías nuevas y no probadas para tratar de obtener una ventaja
competitiva. Una organización de tipo B está menos dispuesta a asumir riesgos, pero adoptará nuevas
tecnologías una vez que otros hayan eliminado los errores. Finalmente, una empresa de tipo C, muy consciente
de los costos y reacia al riesgo, quedará rezagada con respecto a la mayoría cuando se trata de migrar a una
nueva tecnología. Solo las organizaciones de tipo A deben planear moverse de manera agresiva a las nuevas
versiones de DBMS inmediatamente después de la disponibilidad y solo si las nuevas características de la
versión le ofrecen ventajas a la compañía. Las empresas de tipo C deben adoptar una estrategia muy
conservadora para garantizar que la versión de DBMS sea estable y esté bien probada primero por las empresas
de tipos A y B. Las organizaciones de Tipo B se ubicarán en algún lugar entre los tipos A y C: casi nunca se
actualizan de inmediato, la compañía de tipo B adoptará la nueva versión después de que los primeros usuarios
hayan eliminado los mayores problemas, pero mucho antes que las empresas de tipo C.

Juego de habilidades del personal DBA

Actualizar el DBMS es más fácil si su personal de DBA es altamente calificado o experimentado. El riesgo de una
actualización aumenta a medida que disminuyen las habilidades del personal del DBA. Si sus DBA no están
altamente capacitados, o nunca han migrado un DBMS a una nueva versión, considere aumentar su personal de
DBA con consultores para la actualización. La implementación de un equipo integrado de DBA y consultores
internos garantizará que su actualización se realice de la mejor manera posible. Además, el personal del DBA
estará mejor preparado para manejar las actualizaciones futuras solo.
El riesgo de una actualización aumenta a medida que disminuyen las habilidades del personal del DBA.
Si se requieren consultores, asegúrese de incluir su costo de contratación en el presupuesto de actualización de
la versión de DBMS. El presupuesto debería permitirle retener a los consultores hasta que todos los entornos de
bases de datos de producción sean estables.

Soporte de plataforma

Cuando un proveedor de DBMS desata una nueva versión de su producto, no todas las plataformas y sistemas
operativos son compatibles inmediatamente. El proveedor de DBMS por lo general primero soportará las
plataformas y sistemas operativos para los cuales tiene la mayoría de los clientes con licencia. El orden en que
las plataformas son compatibles con una nueva versión es probable que difiera para cada proveedor de DBMS.
Por ejemplo, OS / 390 (o MVS) es más estratégico para IBM que para Oracle, por lo que es probable que una
nueva versión de DB2 sea compatible con OS / 390 muy rápidamente, mientras que esto puede no ser cierto
para Oracle. El problema es aún más espinoso para las plataformas UNIX debido a la gran cantidad de variantes
de UNIX en el mercado. Las variantes más populares son Solaris de Sun Microsystem, AIX de IBM, HP-UX de
Hewlett-Packard y Linux, la versión de código abierto de UNIX. La mayoría de los proveedores de DBMS
admitirán estas plataformas UNIX muy rápidamente con la disponibilidad general. Otras variedades menos
1

populares de UNIX tomarán más tiempo para que los proveedores de DBMS las admitan.
Página

Cuando planifique su actualización de DBMS, asegúrese de considerar las plataformas DBMS que usa e intente
calibrar la prioridad de su plataforma para su proveedor. Asegúrese de acumular cierto tiempo de retraso en su
estrategia de migración de versiones para adaptarse al cronograma de entregas del proveedor para sus
plataformas específicas.

Software de soporte
Considere cuidadosamente el impacto de una actualización de DBMS en cualquier software de soporte. El
software de soporte incluye aplicaciones compradas, herramientas de DBA, herramientas de informes y análisis,
y herramientas de consulta. Cada proveedor de software tendrá un marco de tiempo diferente para soportar y
explotar una nueva versión de DBMS. Revise la barra lateral "Soporte vs. Exploit" para comprender la diferencia
entre el soporte y la explotación de una nueva versión de DBMS.
Considere cuidadosamente el impacto de una actualización de DBMS en cualquier software de soporte.
Algunos proveedores de herramientas de terceros siguen las directrices para apoyar y explotar las nuevas
versiones de DBMS. Siempre que sea posible, solicite a sus proveedores que indiquen sus políticas para el
soporte de actualización de DBMS. Es probable que sus proveedores no se comprometan con ninguna fecha o
rango de fechas en firme para admitir versiones y lanzamientos nuevos: algunas versiones de DBMS son más
grandes y complicadas y, por lo tanto, tardan más en explotarse por completo.

Planificación de repliegue

Cada nueva versión o versión de DBMS debe venir con un manual que describe las nuevas características de la
versión y describe los procedimientos alternativos para volver a una versión anterior de DBMS. Asegúrate de
revise los procedimientos alternativos provistos por el proveedor de DBMS en su guía de publicación. Es posible
que deba volver a una versión anterior de DBMS si la actualización contiene un error, surgen problemas de
rendimiento o surgen otros problemas durante o inmediatamente después de la migración. Tenga en cuenta que
la recuperación no siempre es una opción para cada nueva versión de DBMS.

Soporte vs. Exploit

Algunos proveedores diferencian específicamente entre apoyar y explotar una nueva versión o
lanzamiento de DBMS. El software que admite una nueva versión continuará funcionando igual que antes
de que se actualizara el DBMS, pero sin nuevas capacidades. Por lo tanto, si una herramienta de DBA, por
ejemplo, admite una nueva versión de Oracle, puede proporcionar todos los servicios que hizo para la
última versión, siempre que no se utilicen las nuevas características de la nueva versión de Oracle. Por el
contrario, una herramienta de DBA que explota una nueva versión o versión proporciona la funcionalidad
requerida para operar con las nuevas características de la nueva versión de DBMS. Entonces, para usar
un ejemplo concreto, IBM agregó soporte para objetos grandes (LOB) en la Versión 6 de DB2. Una
herramienta DBA puede admitir DB2 Versión 6 sin operar en LOB, pero debe operar en LOB para explotar
DB2 Versión 6. Antes de migrar a una nueva versión o versión de DBMS, asegúrese de comprender la
diferencia entre admitir y explotar una nueva versión, y obtener un cronograma de las herramientas de
DBA que utiliza tanto de sus proveedores de herramientas de terceros.

Si es posible la recuperación, siga los procedimientos recomendados del proveedor de DBMS para habilitar la
recuperación. Es posible que deba retrasar la implementación de ciertas características nuevas para que el
recurso alternativo permanezca como una opción. Comprenda por completo las limitaciones impuestas por el
proveedor de DBMS en caso de error, y explote las nuevas características solo cuando la alternativa ya no sea
una opción para su organización.
Verificación de migración

El administrador de bases de datos debe implementar procedimientos similares a los de una instalación nueva
para verificar que la actualización del lanzamiento de DBMS sea satisfactoria. Realice los mismos pasos que con
una nueva instalación de DBMS, pero también pruebe una muestra representativa de sus aplicaciones internas
para verificar que la actualización de DBMS esté funcionando correctamente y funcionando satisfactoriamente.
El administrador de bases de datos debe implementar procedimientos para verificar que la actualización del
lanzamiento de DBMS sea
satisfactorio.
La estrategia de actualización DBMS

En general, diseñe su política de actualización de versión de DBMS de acuerdo con las pautas discutidas
anteriormente. Cada actualización específica de DBMS será única, pero las estrategias que hemos discutido lo
1

ayudarán a lograr el éxito más fácilmente. Una estrategia de actualización de DBMS bien pensada lo preparará
Página

para admitir nuevas versiones de DBMS con un impacto mínimo para su organización y en un estilo que mejor se
adapte a su empresa.

Estándares y procedimientos de la base de datos

Antes de que un DBMS recién instalado se pueda utilizar de manera efectiva, se deben desarrollar estándares y
procedimientos para el uso de la base de datos. Un estudio reciente realizado por Hackett Benchmarking &
Research mostró que las empresas con altos niveles de estandarización reducen el costo de apoyar a los
usuarios finales en un promedio de 38% en comparación con las compañías con bajos niveles de
estandarización.
Se deben desarrollar estándares y procedimientos para el uso de la base de datos.
Los estándares son prácticas comunes que aseguran la consistencia y efectividad del entorno de la base de
datos, como las convenciones de nombres de bases de datos. Los procedimientos son scripts que dirigen los
procesos necesarios para manejar eventos específicos, como un plan de recuperación de desastres. Si no se
implementan los estándares y procedimientos de la base de datos, se generará un entorno de base de datos
que es confuso y difícil de gestionar.
El DBA debe desarrollar normas y procedimientos de base de datos como un componente de los estándares y
procedimientos de TI corporativos. Deben almacenarse juntos en una ubicación central como un documento
impreso, en un formato en línea o como ambos. Varios proveedores ofrecen estándares y procedimientos
"enlatados" que se pueden comprar para productos DBMS específicos.

Convenciones de nombres de bases de datos

Uno de los primeros estándares en ser implementado debería ser un conjunto de pautas para el nombramiento
de objetos de base de datos. Sin las convenciones de nombres de objeto de base de datos estándar, será difícil
identificar objetos de base de datos correctamente y realizar las tareas de administración adecuadas.
Los estándares de nomenclatura de objetos de base de datos deben desarrollarse junto con todos los demás
estándares de nomenclatura de TI en su organización. En todos los casos, las normas de nombres de bases de
datos deben desarrollarse en
cooperación con el departamento de administración de datos (si existe) y, siempre que sea posible, coexista
pacíficamente con otros estándares de TI, pero no a costa de perjudicar el entorno de la base de datos. Por
ejemplo, muchas organizaciones tienen convenciones de tiendas para nombrar archivos, pero la coordinación
del objeto de la base de datos con el archivo del sistema operativo puede requerir un formato específico para
nombres de archivos de bases de datos que no se ajuste a los estándares de la tienda. (Ver la Figura 2-6). Por lo
tanto, puede ser necesario hacer excepciones a los estándares existentes de la tienda para nombrar los archivos
de la base de datos.

Figura 2-6. Objetos de base de datos asignados a nombres de archivo

Asegúrese de crear y publicar estándares de nombres para todos los objetos de base de datos que se pueden
crear dentro de cada DBMS utilizado por su organización. Una lista básica de objetos de base de datos admitidos
por la mayoría de los DBMS incluye bases de datos, tablas, columnas, vistas, índices, restricciones, programas,
tipos de datos definidos por el usuario, funciones definidas por el usuario, disparadores y procedimientos
almacenados. Sin embargo, esta lista es incompleta porque cada DBMS usa otros objetos de base de datos
específicos para su operación. Por ejemplo, DB2 usa planes, paquetes, espacios de tablas y grupos de
almacenamiento; Oracle usa espacios de tabla, secuencias y clusters; SQL Server usa grupos de archivos, reglas
y valores predeterminados. Asegúrese de establecer convenciones de nomenclatura para todos los objetos de la
base de datos. El estándar de nomenclatura de la base de datos debe diseñarse para minimizar los cambios de
nombre en todos los entornos. Por ejemplo, incrustar una T en el nombre para la prueba y una P para la
producción es una mala idea. Es especialmente importante evitar este enfoque para objetos de base de datos
visibles para el usuario, como columnas, tablas y vistas. Minimizar los cambios de nombre simplifica la migración
de las bases de datos de un entorno a otro. Es posible hacer todos los nombres de objeto de base de datos
iguales asignando cada entorno a una instancia o subsistema diferente. El nombre de la instancia o subsistema,
1

en lugar de los nombres de los objetos de la base de datos, diferenciará los entornos. Minimice los cambios de
Página

nombre en todos los entornos. En la mayoría de los casos, para los objetos a los que no acceden los usuarios
finales típicos, proporcione una forma de diferenciar los tipos de objetos de la base de datos. Por ejemplo, inicie
índices con I o X, y bases de datos con D. Sin embargo, para tablas y objetos similares, como se discutió
anteriormente, este enfoque es inapropiado.
En general, no imponga restricciones innecesarias a los nombres de los objetos a los que acceden los usuarios
finales. Se supone que las bases de datos relacionales son fáciles de usar. Una convención estricta de
nomenclatura de bases de datos, si no se desarrolla lógicamente, puede ser antitética a un entorno de base de
datos útil y eficaz. Algunas organizaciones imponen limitaciones de longitud arbitraria en las tablas de la base
de datos, como un límite de 8 bytes, aunque el DBMS puede admitir nombres de tabla de hasta 128 bytes. No
hay ninguna razón práctica para imponer una limitación que prohíba la longitud de los nombres de las tablas de
la base de datos.
Los nombres de las tablas deben ser tan descriptivos como sea posible, dentro de lo razonable. Además, las
mismas convenciones de nomenclatura deberían utilizarse para todos los objetos "tablelike", incluidas vistas,
sinónimos y alias, si el DBMS lo admite. Cada uno de estos objetos es básicamente una colección de datos
accesibles como filas y columnas. Desarrollar convenciones de nomenclatura separadas para cada uno no tiene
ningún valor real. Siguiendo este enfoque, los objetos de base de datos que operan como tablas se definirán de
manera similar con un nombre muy descriptivo. El tipo de objeto siempre puede determinarse consultando el
catálogo del sistema DBMS o el diccionario de datos.
La codificación de nombres de tabla para acortarlos es otro estándar de nomenclatura arbitrario que debe
evitarse. Los nombres de tabla deben incluir un prefijo de identificación de aplicación de 2 o 3 bytes, seguido de
un guión bajo y luego un nombre claro y fácil de usar. Por ejemplo, un buen nombre para la tabla que contiene
información del empleado en un sistema de recursos humanos sería HR_EMPLOYEE. Es posible que desee
eliminar el prefijo de identificación de la aplicación del nombre de la tabla para las tablas utilizadas por varias
aplicaciones.
Evite codificar nombres de tabla para hacerlos más cortos.
Tenga en cuenta, también, que algunos nombres de objetos de bases de datos, en algunos casos, se
externalizarán. Por ejemplo, la mayoría de los DBMS externalizan nombres de restricciones cuando se viola la
restricción. Hay muchos tipos de restricciones: desencadenantes, restricciones únicas, restricciones
referenciales, restricciones de verificación, cada una de las cuales puede nombrarse. Mantener los nombres
consistentes en todos los entornos permite los mensajes de error
ser consistente. Si el DBMS ofrece el mismo mensaje de error en los entornos de desarrollo, prueba, integración
y producción, la depuración y la corrección de errores serán más fáciles.

Abreviaciones estándar

Aunque debe mantener los nombres de los objetos de la base de datos lo más parecidos a los ingleses posible,
inevitablemente encontrará situaciones que requieren abreviaturas. Use abreviaturas solo cuando el texto
completo sea demasiado largo para ser admitido como un nombre de objeto o cuando haga que el nombre del
objeto sea difícil de manejar o difícil de recordar. Cree una lista de abreviaturas estándar y prohíba el uso de
abreviaturas no estándar. Por ejemplo, si "ORG" es la abreviatura estándar para "organización", no permita que
se utilicen variantes como "ORGZ". El uso de abreviaturas estándar minimizará la mal escritura y facilitará a los
usuarios recordar los nombres de los objetos de la base de datos. Adherirse a esta práctica facilitará la
comprensión de los objetos de la base de datos dentro de su entorno. Crea una lista de abreviaciones estándar.

Otros estándares y procedimientos de bases de datos

Si bien los estándares de nombres de bases de datos son importantes, deberá desarrollar y mantener otros tipos
de estándares de bases de datos. Asegúrese de desarrollar un conjunto completo de estándares y
procedimientos para cada DBMS utilizado por su organización. Cada una de las siguientes áreas debería estar
cubierta.

Funciones y responsabilidades

La operación exitosa de un SGBD requiere los esfuerzos coordinados de gestión de muchos técnicos calificados y
expertos en negocios. Se debe desarrollar una matriz de funciones de gestión y administración de bases de
datos que documente cada tarea de soporte y que dentro de la organización proporcione el soporte. La matriz
se puede crear a nivel departamental, a nivel de descripción del trabajo o incluso por nombre individual. Una
matriz de muestra se muestra en la Tabla 2-4. Una X en la matriz indica participación en el proceso, mientras
que una P indica responsabilidad principal. Por supuesto, puede crear cualquier tarea que considere necesaria
en su matriz de roles y responsabilidades. Es posible que necesite tareas adicionales, o menos que en esta
1

muestra. Por ejemplo, es posible que desee diferenciar entre el desarrollo del procedimiento almacenado, las
Página

pruebas y la administración, creando una categoría de tarea diferente para cada uno y desglosando los
requisitos de soporte de forma diferente. Sea cual sea el formato final de su matriz de roles y responsabilidades,
asegúrese de mantenerlo preciso y actualizado con las nuevas funciones y funciones de DBMS. Una matriz
actualizada facilita la definición de roles dentro de la organización y la distribución efectiva de la carga de
trabajo relacionada con la base de datos.
Estándares de administración de datos

Si existe un grupo DA dentro de su organización, deben desarrollar una guía básica de normas de administración
de datos para delinear el alcance de su función de trabajo. Si un grupo DA no existe, asegúrese de incluir los
estándares DA en los estándares DBA según corresponda.
Incluya los estándares de DA en los estándares de DBA según corresponda.
Los estándares de administración de datos deben incluir los siguientes elementos:

1. Una declaración clara de la política general de la organización con respecto a los datos, incluida su
importancia para la empresa.
2. Pautas para establecer la propiedad y la administración de los datos.
3. Reglas para la creación de datos, la propiedad de los datos y la administración de datos
4. Política de gestión de metadatos
5. Pautas de modelado de datos conceptuales y lógicos.
6. Los objetivos de la organización con respecto a la creación de un modelo de datos empresariales
7. Responsabilidad de crear y mantener modelos de datos lógicos.
8. Pautas para el uso de herramientas e instrucciones sobre cómo se deben crear, almacenar y mantener
los modelos de datos
9. Políticas de intercambio de datos organizacionales
10. Instrucciones sobre cómo documentar cuándo las bases de datos físicas se desvían del modelo de datos
lógicos
11. Directrices sobre la comunicación entre la administración de datos y la administración de bases de datos
para garantizar la creación y el uso efectivos de la base de datos

Estándares de administración de bases

Se debe establecer un conjunto básico de estándares de administración de bases de datos para garantizar el
éxito continuo de la función de DBA. Los estándares sirven como una guía para los servicios de DBA ofrecidos y
para enfoques específicos para apoyar el entorno de la base de datos. Por ejemplo, se pueden desarrollar
estándares que describan cómo se realizan las solicitudes para crear una nueva base de datos o realizar
cambios en bases de datos existentes, y que especifiquen qué tipos de objetos de base de datos y
características de DBMS se favorecen y en qué circunstancias se evitan. Los estándares pueden establecer
procedimientos de respaldo y recuperación (incluidos los planes de recuperación de desastres) y comunicar los
métodos utilizados para transformar un modelo de datos lógicos en una implementación de base de datos física.
Un conjunto adicional de estándares de DBA que cubren la base de datos la supervisión y el ajuste del
rendimiento pueden ser útiles para documentar procedimientos para superar problemas de rendimiento. Los
estándares DBA sirven como guía para enfoques específicos para respaldar el entorno de la base de datos.
Aunque los estándares de DBA serán más útiles para el personal de DBA, el personal de desarrollo de
aplicaciones los necesitará para aprender la mejor manera de trabajar con el personal de DBA. Además, todos
los trucos de ajuste de rendimiento que están documentados en los estándares de DBA se deben compartir con
los programadores. Cuanto más entiendan los programadores de aplicaciones los matices del DBMS y el rol del
DBA, mejor será la relación de trabajo entre DBA y desarrollo, lo que dará como resultado un entorno de base de
datos más eficiente.

Estándares de administración del sistema

Una vez más, los estándares para la administración del sistema o la programación de sistemas solo son
necesarios si su organización separa la función SA de la función DBA. Los estándares de administración del
sistema son necesarios por muchas de las mismas razones por las que se requieren los estándares DBA. Los
estándares para SA pueden incluir
1. Instalación de DBMS y procedimientos de prueba
2. Actualizar políticas y procedimientos
1

3. Corrección de errores y prácticas de mantenimiento

4. Una lista de verificación de departamentos para notificar cambios inminentes
Página

5. Consideraciones de interfaz
6. Almacenamiento de DBMS, uso y procedimientos de supervisión

Estándares de desarrollo de aplicaciones

El desarrollo de aplicaciones de bases de datos difiere del desarrollo de programas típico. Debe documentar las
consideraciones especiales de desarrollo requeridas al escribir programas que acceden a las bases de datos. Los
estándares de desarrollo de aplicaciones de bases de datos deben funcionar como un complemento de cualquier
procedimiento estándar de desarrollo de aplicaciones dentro de su organización. Este conjunto de estándares
debe incluir
1. Una descripción de cómo el acceso a la base de datos difiere del acceso al archivo plano
2. Estándares de codificación SQL
3. Sugerencias y técnicas de rendimiento de SQL
4. Procedimientos de preparación del programa y orientación sobre cómo incrustar SQL en un programa de
aplicación
5. Interpretaciones de SQLSTATE y códigos de error
6. Referencias a otros materiales de programación útiles para monitores de teleprocesamiento, lenguajes
de programación y estándares generales de desarrollo de aplicaciones

Estándares de seguridad

El grupo de DBA a menudo aplica y administra la seguridad de DBMS. Sin embargo, en algunas tiendas, la
unidad de seguridad de datos corporativos maneja la seguridad DBMS. Debe proporcionar un recurso que
describa los estándares y procedimientos necesarios para administrar la seguridad de la base de datos. Debe
contener la siguiente información:
1. Detalles sobre qué autoridad otorgar para tipos específicos de situaciones: por ejemplo, si un programa
se está migrando al estado de producción, ¿qué autorización DBMS se debe otorgar antes de que el
programa funcione con éxito en la producción?
2. Una lista definitiva de quién puede aprobar qué tipos de solicitudes de autorización de bases de datos.
3. Información sobre las interfaces que se utilizan para conectar la seguridad DBMS con los productos de
seguridad del sistema operativo.
4. Políticas sobre el uso de la cláusula WITH GRANT OPTION de la declaración SQL GRANT y cómo se deben
manejar los REVOKES en cascada.
5. Procedimientos para notificar al solicitante que la seguridad de la base de datos ha sido otorgada.
6. Procedimientos para eliminar la seguridad de empleados retirados, reubicados y despedidos.

Describir los estándares y procedimientos necesarios para administrar la seguridad de la base de datos.

Procedimientos de migración de aplicaciones y rotación

Como se discutió anteriormente, el número mínimo de entornos para soportar aplicaciones de bases de datos es
dos: prueba y producción. Algunas organizaciones, sin embargo, crean múltiples entornos para apoyar, por
ejemplo, diferentes fases del ciclo de vida del desarrollo, incluyendo
1. Pruebas unitarias: para desarrollar y probar programas individuales
2. Pruebas de integración: para probar cómo los programas individuales interoperan
3. Prueba de aceptación del usuario: para la prueba del usuario final antes del estado de producción
4. Aseguramiento de la calidad: para eliminar los errores del programa
5. Educación: para capacitar a los usuarios finales sobre cómo trabajar con el sistema de aplicación

Cuando existen múltiples entornos, se requieren procedimientos para migrar objetos y programas de bases de
datos de un entorno a otro. Se necesitan pautas específicas para lograr la migración de una manera que
conduzca al uso de cada entorno. Por ejemplo, ¿qué volumen de datos se requiere para cada entorno y cómo se
garantiza la integridad de los datos cuando se realiza la actividad de prueba? ¿Deben migrarse los datos, o solo
las estructuras de la base de datos? ¿Cómo deberían tratarse los datos existentes en el entorno objetivo?
¿Debería mantenerse o superponerse con datos nuevos? Se deben desarrollar procedimientos integrales de
migración para abordar este tipo de preguntas. Se requieren procedimientos para migrar objetos y programas
de base de datos de un entorno a otro. Los procedimientos de migración y rotación deben documentar la
información requerida antes de que cualquier objeto o programa de base de datos se pueda migrar de un
entorno a otro. Como mínimo, se requerirá información sobre el solicitante, cuándo y por qué se deben migrar
los objetos, y la autorización correspondiente para aprobar la migración. Para garantizar el éxito de la migración,
1

el DBA debe documentar los métodos utilizados para la migración y registrar el proceso de verificación.
Página

Pautas de revisión de diseño

Todas las aplicaciones de bases de datos deben someterse a una revisión del diseño en diversas etapas de su
desarrollo. Las revisiones de diseño son importantes para garantizar el diseño, la construcción y el rendimiento
adecuados de la aplicación. Las revisiones de diseño pueden tomar muchas formas. El Capítulo 6 ofrece una
discusión completa de las revisiones de diseño.
Estándares de soporte operacional

El soporte operativo se define como la parte de la organización de TI que supervisa el entorno de la base de
datos y asegura que las aplicaciones se ejecuten de acuerdo con el cronograma. Debe haber suficiente soporte
operacional disponible para administrar un entorno de base de datos de manera efectiva. El personal de soporte
operativo suele ser la primera línea de defensa contra los problemas del sistema. Las fallas del programa, las
fallas del hardware y otros problemas se identifican primero por el soporte operacional antes de llamar a los
especialistas para que resuelvan los problemas.
El soporte operativo garantiza que las aplicaciones se ejecuten de acuerdo con el cronograma.
Se deben desarrollar estándares para garantizar que el personal de soporte operacional comprenda los
requisitos especiales de las aplicaciones de bases de datos. Siempre que sea posible, el personal de apoyo
operativo debe ser
capacitado para resolver problemas simples relacionados con la base de datos sin involucrar a los DBA porque el
DBA es un recurso más costoso.
Educación DBMS
Las organizaciones que usan la tecnología DBMS deben comprometerse con las clases de educación técnica en
curso para DBA, programadores y administradores de sistemas. Proporcione un catálogo de cursos disponibles
que cubran todos los aspectos del uso de DBMS. Como mínimo, los siguientes cursos deberían estar disponibles:
1. Descripción general de DBMS: una clase de nivel de gestión de un día que cubre los aspectos básicos de
DBMS.
2. Modelado de datos y diseño de bases de datos: un curso completo que cubre las técnicas de diseño de
bases de datos conceptuales, lógicas y físicas para DA y DBA.
3. Administración de bases de datos: clases técnicas detalladas para DBA, SA y programadores de sistemas
4. Introducción a SQL: un curso introductorio sobre los conceptos básicos de SQL para cada usuario de
DBMS
5. SQL avanzado: un curso en profundidad sobre desarrollo de SQL complejo para DBA y programadores
6. Programación de bases de datos: un curso en profundidad para programadores de aplicaciones y
analistas de sistemas que enseña a los estudiantes a escribir programas que usan DBMS.
Cada uno de estos cursos debe estar disponible para cada DBMS instalado en su organización. Además,
proporcione capacitación para cualquier otra funcionalidad y software relacionado con la base de datos, como el
uso adecuado de las utilidades de la base de datos, las herramientas de consulta e informe y las herramientas
de DBA. Comprométase con las clases de educación técnica en curso. La educación de DBMS puede ser
entregada usando una variedad de métodos que incluyen cursos dirigidos por un instructor, capacitación basada
en computadora, capacitación basada en la Web y aprendizaje a distancia. Las fuentes para la educación de
DBMS incluyen los proveedores de DBMS, ISV, consultores (grandes y pequeños, internacionales y locales) y
especialistas en capacitación (como Themis y ProTech). Finalmente, asegúrese de que el material de referencia
DBMS esté disponible para todos los usuarios. La mayoría de los proveedores ofrecen sus manuales de
referencia DBMS en un formato en línea utilizando archivos Adobe Acrobat o la Ayuda de Windows. Asegúrese
de que a cada usuario se le entregue una copia de los manuales o que estén disponibles en una ubicación
central para minimizar la cantidad de tiempo que los DBA deberán dedicar a responder preguntas simples que
se pueden encontrar en la documentación de DBMS.
Resumen
Se requiere una planificación anticipada exhaustiva para crear un entorno de base de datos eficaz. Se debe
tener cuidado para seleccionar la tecnología correcta de DBMS, implementar una estrategia de actualización de
DBMS apropiada, desarrollar estándares de base de datos útiles y garantizar la disponibilidad continua de
educación para los usuarios de la base de datos. Al seguir las pautas de este capítulo, puede lograr un entorno
de base de datos efectivo para su organización. Sin embargo, configurar el entorno de la base de datos es solo
el comienzo. Una vez que esté configurado, deberá administrar activamente el entorno de la base de datos para
garantizar que las bases de datos se creen correctamente, se usen correctamente y se administren para el
rendimiento y la disponibilidad. Siga leyendo para descubrir cómo el DBA puede lograr estas tareas.

Capítulo 14.
2

Seguridad de la base de datos

Página

El enfoque básico de seguridad y autorización adoptado por los proveedores de DBMS para asegurar el acceso a
la base de datos es que todos los recursos de la base de datos están controlados por el DBMS. No se otorgan
autorizaciones predeterminadas a ningún usuario solo porque el usuario inicia sesión en el DBMS. Por lo tanto,
para que un usuario pueda realizar cualquier operación o función de DBMS, debe existir una de las siguientes
condiciones:
 1. Se le ha otorgado al usuario la capacidad de realizar esa función u operación
2. Esa operación o función ha sido otorgada genéricamente a todos los usuarios
Todos los recursos de la base de datos están controlados por el DBMS.

Usando las características de seguridad del DBMS, el DBA puede configurar el entorno de manera que solo
ciertos usuarios o ciertos programas de aplicación puedan realizar ciertas operaciones con ciertos datos dentro
de la base de datos. La función de cada usuario dentro de la organización debe determinar el nivel autorizado de
acceso a la base de datos. Por ejemplo, solo los programadores de contabilidad general, los trabajos por lotes y
los programas pueden acceder y modificar las bases de datos de contabilidad general. Se pueden establecer
diferentes controles para cada tipo de acceso a cada tipo de información, y diferentes usuarios pueden tener
diferentes derechos de acceso a diferentes objetos de la base de datos.
El desafío operacional de administrar de manera efectiva la seguridad de la base de datos surge porque
configurar y administrar la autorización de la base de datos requiere experiencia técnica y privilegios elevados.
Muchos aspectos de la seguridad de la base de datos requieren diferentes utilidades, procedimientos del
sistema y comandos para implementar. Cuando los usuarios requieren acceso a múltiples bases de datos, en
múltiples servidores distribuidos en diferentes ubicaciones físicas, la administración de la seguridad de la base
de datos se vuelve bastante complicada. Los comandos deben repetirse para cada base de datos, y no existe un
repositorio central para modificar y eliminar fácilmente la configuración de seguridad del usuario en múltiples
bases de datos simultáneamente.
Aunque el DBA generalmente es responsable de administrar la seguridad de la base de datos, algunas
organizaciones han transferido esta tarea a una función de administración de seguridad separada que controla
toda la seguridad de TI para la empresa. Sin embargo, incluso en muchas tiendas donde la administración de
seguridad es una entidad separada, la seguridad de la base de datos sigue siendo manejada por el grupo de
DBA porque la seguridad de la base de datos se maneja de forma diferente a un escenario típico de autorización
de TI.

Cuando el grupo de administración de seguridad maneja las políticas de seguridad, este grupo generalmente
confía en un software de seguridad de terceros como RACF de IBM o Computer Associates ACF2 y Top Secret.
Estos productos automatizan la función de seguridad y no requieren que el administrador tenga una elevada
privilegios para administrar políticas de seguridad. Sin embargo, la mayoría de estos productos de
administración de seguridad se ejecutan solo en mainframes. Además, la mayoría de los departamentos de
seguridad de TI carecen de personal y carecen de la experiencia técnica en DBMS necesaria para administrar la
seguridad de la base de datos. Conceder al personal de seguridad no capacitado los privilegios necesarios para
administrar la seguridad de la base de datos puede ocasionar la interrupción accidental del servicio de la base
de datos o problemas de rendimiento. Entonces, el DBA se ve obligado a administrar la seguridad de la base de
datos como un componente de su trabajo.
El DBA debe administrar la seguridad de la base de datos como un componente de su trabajo.
Conceptos básicos de seguridad de la base
La autenticación fuerte es la piedra angular de cualquier plan de implementación de seguridad. Es imposible
controlar la autorización y rastrear el uso sin ella. Antes de que se pueda otorgar la autorización para usar los
recursos de la base de datos, se debe establecer un inicio de sesión para cada usuario del DBMS. Los inicios de
sesión a veces se denominan cuentas o ID de usuario. El inicio de sesión tendrá una contraseña asociada, de
modo que solo aquellos que conocen la contraseña pueden usar la ID de inicio de sesión. Algunos DBMS usan el
ID de inicio de sesión del sistema operativo y la contraseña como ID de inicio de sesión de DBMS y contraseña;
otros requieren un ID de inicio de sesión y una contraseña adicional que se crearán específicamente para el
acceso a la base de datos y la seguridad.
La autenticación fuerte es la piedra angular de cualquier plan de implementación de seguridad.
Cuando el DBMS controla la adición de inicios de sesión, se requiere que el DBA proporcione cierta información
sobre el inicio de sesión cuando se crea. Normalmente, aparte del nombre de usuario o ID de inicio de sesión
real, se puede o se debe proporcionar la siguiente información:
1. Contraseña: la frase clave, palabra o cadena de caracteres asociada con el nuevo inicio de sesión que
debe ser proporcionado por el usuario antes de permitir el acceso a la base de datos.
2. Base de datos predeterminada: el nombre de la base de datos a la que el usuario se conectará
inicialmente durante el inicio de sesión.
3. Idioma predeterminado: el idioma predeterminado asignado al inicio de sesión cuando se usa DBMS si se
2

admiten varios idiomas.

Página

4. Nombre: el nombre completo real del usuario asociado a este inicio de sesión.
5. Detalles adicionales: detalles adicionales sobre el usuario para el que se ha creado el inicio de sesión:
correo electrónico, número de teléfono, ubicación de la oficina, unidad de negocios, etc. Esto es útil para
fines de documentación.

Las contraseñas deben cambiarse regularmente a lo largo del tiempo para dificultar el acceso subrepticio de los
hackers y delincuentes al DBMS. Consulte la barra lateral "Guía de contraseñas" para obtener sugerencias sobre
cómo crear contraseñas útiles. Como DBA, puede decidir configurar procedimientos automatizados, como un
sistema de notificación por correo electrónico, para obligar a los usuarios a cambiar sus contraseñas de inicio de
sesión cada mes más o menos. Los usuarios que no cambian su contraseña de inicio de sesión pueden
deshabilitarse hasta que el usuario llame para quejarse. Por supuesto, esto se suma a la carga de trabajo del
DBA, pero mejora la seguridad del DBMS. Las contraseñas deben cambiarse regularmente con el tiempo.
Cuando un usuario de DBMS ya no requiere acceso al DBMS o abandona la empresa, el DBA debe abandonar su
inicio de sesión desde el sistema lo antes posible. Sin embargo, esto podría convertirse en una tarea
complicada: un inicio de sesión no puede descartarse si la persona está utilizando actualmente una base de
datos o si el usuario posee objetos de base de datos. Por esta razón, es aconsejable limitar los usuarios de la
base de datos que pueden crear objetos de base de datos únicamente a los DBA, especialmente en un entorno
de producción. Limite los usuarios de la base de datos que pueden crear objetos de base de datos solo a los
DBA. En lugar de eliminar un inicio de sesión, el DBMS puede proporcionar una opción para bloquear el inicio de
sesión. Bloquear un inicio de sesión prohíbe al usuario acceder al DBMS, pero en realidad no deja de ingresar el
sistema. El inicio de sesión se puede desbloquear posteriormente, lo que permite el acceso al servidor. Tal
proceso es muy útil si simplemente desea prohibir el acceso, por ejemplo, a aquellos usuarios que no han
cambiado recientemente su contraseña de inicio de sesión.

Orientación de contraseña
Como DBA, usted es responsable de asegurar el DBMS y garantizar el acceso a los datos a los usuarios
autorizados. Una forma de garantizar el uso adecuado de DBMS es desarrollar y difundir sugerencias
sobre cómo crear contraseñas útiles. Una contraseña que sea útil y adecuada será difícil de adivinar.
Si las contraseñas son demasiado simplistas o están demasiado relacionadas con algún aspecto de la
persona que usa la contraseña, las personas inescrupulosas pueden adivinar la contraseña y usarla para
acceder subrepticiamente a la base de datos.
Se deben seguir las siguientes pautas para la creación correcta de contraseñas:
I. Evite las contraseñas que son demasiado cortas. Cada contraseña debe tener al menos
seis caracteres, más si es posible.
II. Cada contraseña debe consistir en al menos una combinación de caracteres alfabéticos
y caracteres numéricos. Usar otros símbolos permitidos hace que la contraseña sea
más difícil de adivinar.
III. Evite crear una contraseña que sea una palabra completa (ya sea en el idioma nativo
del usuario o en cualquier idioma extranjero).
IV. No incruste estadísticas personales en la contraseña. Las direcciones de calles, los
números de seguro social, los números de teléfono y similares se adivinan fácilmente y
no pertenecen a las contraseñas.
V. Considere concatenar dos palabras no relacionadas con un símbolo o número entre
ellas. Por ejemplo, "toe3star" es una contraseña viable.
Use dispositivos mnemotécnicos para recordar las contraseñas. Por ejemplo, use una oración como
"Moondance de Van Morrison es mi álbum favorito" para recordar que su contraseña es "mbvmimfa" (las
primeras letras de cada palabra de la oración). Sin embargo, no hagas que la oración sea demasiado
obvia, por ejemplo, usar "Mi nombre es Craig S. Mullins" para recordar "mnicsm" no es una buena idea
porque podría ser bastante fácil de adivinar.
Como DBA, debe trabajar con el equipo de administración de seguridad de su organización para crear
pautas como las anteriores y distribuirlas a los usuarios de su base de datos.

Tenga en cuenta que los inicios de sesión que se eliminan deben crearse nuevamente si alguna vez se requieren
nuevamente. Por esta razón, siga estas reglas generales con respecto a la administración de inicio de sesión:
1. Bloquear inicios de sesión que pueden necesitar ser reactivados.
2. Drop inicios de sesión que nunca será necesario reactivar.

Algunos DBMS brindan controles y parámetros adicionales en inicios de sesión y contraseñas. Por ejemplo,
algunos DBMS brindan parámetros de perfil para contraseñas que se pueden usar para limitar lo siguiente:
1. Número de intentos fallidos de inicio de sesión antes de que la cuenta se bloquee
2. Número de días que una contraseña es válida, el período de gracia para cambiar una contraseña
2

caducada
Página

3. Número de días que la cuenta puede permanecer bloqueada cuando caduca la contraseña
4. Reutilización de contraseñas (número de días antes de que se pueda reutilizar una contraseña y la
cantidad máxima de veces que se puede reutilizar una contraseña)

Cuando dichos controles estén disponibles, asegúrese de utilizarlos al asignar cuentas de inicio de sesión para
proteger mejor el entorno DBMS.
Tenga en cuenta, sin embargo, que cada DBMS es diferente, y puede que no haya capacidad para obligar a un
usuario a cambiar periódicamente una contraseña. Si una contraseña nunca cambia, la probabilidad de que se
vea comprometida aumenta con el tiempo. Si la base de datos puede obligar a un cambio de contraseña
periódico, a menudo se limita en su capacidad para aplicar completamente los estándares de contraseña
corporativa que reducen el riesgo de que adivine la contraseña. Estos estándares generalmente incluyen
requisitos mínimos de longitud y alfanuméricos. La mayoría de los DBMS ni siquiera proporcionan una interfaz
simple mediante la cual el usuario final puede cambiar su propia contraseña. El problema se agrava si el usuario
tiene una cuenta en múltiples bases de datos en varios servidores.
Aplicar los estándares de contraseña corporativa.

Usuarios de la base

Además de una cuenta de inicio de sesión, que se requiere para acceder al SGBD, algunos sistemas de bases de
datos requieren una cuenta adicional para usar bases de datos específicas. En esta situación, se crea un nombre
de usuario para la cuenta de inicio de sesión y se adjunta a cada base de datos requerida por el usuario. Como
se muestra en la Figura 14-1, se pueden requerir las siguientes cuentas:

Figura 14-1. DBMS y inicios de sesión en la base de datos

1. Un inicio de sesión, a veces llamado una cuenta, se usa para acceder al DBMS o al servidor de la base de
datos. Por este motivo, a veces también se lo conoce como ID de usuario del servidor o SUID.
2. Un nombre de usuario a veces se denomina ID de base de datos. El nombre de usuario está asociado con
la cuenta de inicio de sesión. Algunas implementaciones de DBMS requieren que los usuarios se
configuren con un nombre de usuario de base de datos para acceder a cada base de datos.

El uso como invitado de una base de datos se permite configurando un nombre de usuario especial que permite
a los usuarios acceder a la base de datos como INVITADO. Agregar un usuario GUEST para una base de datos
permite cualquier inicio de sesión con el nombre de usuario especial para acceder a la base de datos.

Autoridad de concesión y revocación

El DBA controla la seguridad y la autorización de la base de datos mediante el lenguaje de control de datos o
DCL. DCL es uno de los tres subtipos de SQL. (Los otros dos son DDL y DML.) Las sentencias DCL se usan para
controlar qué usuarios tienen acceso a qué objetos y comandos. Estas declaraciones son la forma en que se
promulga la seguridad de la base de datos. Las declaraciones DCL comprenden dos tipos básicos:

1. GRANT le asigna un permiso a un usuario de la base de datos.

2. REVOKE elimina un permiso de un usuario de base de datos.

Las declaraciones DCL comprenden dos tipos básicos: GRANT y REVOKE.

La declaración GRANT se emite con dos listas de acompañamiento: una lista de privilegios que se asignarán a
una lista de usuarios. Para usar la declaración GRANT, el usuario debe ser el propietario del objeto de la base de
datos, se le ha otorgado la autoridad del grupo de alto nivel o se le ha otorgado la opción WITH GRANT cuando
se le otorgó el privilegio.
2

La opción WITH GRANT OPTION permite a un usuario pasar la autoridad para otorgar privilegios a otros.
Página

Generalmente, el uso de esta cláusula depende de si una instalación practica la administración de privilegios
centralizada o descentralizada.
1. La administración descentralizada generalmente es más fácil de establecer, pero más difícil de controlar.
A medida que más y más usuarios obtienen la autoridad para otorgar privilegios, el alcance de la
autoridad se amplía y se vuelve poco manejable.
 2. La administración centralizada generalmente es más fácil de administrar, pero impone una carga al
administrador centralizado como único árbitro de privilegios dentro del entorno.
Evite emitir declaraciones GRANT y REVOKE desde dentro de un programa de aplicación. Idealmente, una
persona que comprende las necesidades de seguridad de la organización, generalmente la autorización de la
base de datos de DBA. Además, los programas de aplicación diseñados para otorgar privilegios de base de datos
deben ser ejecutados por un usuario que tenga la autoridad apropiada para emitir los GRANT y REVOKES
codificados en el programa de aplicación. Esto podría crear una laguna en la infraestructura de seguridad de su
base de datos.
Tipos de privilegios

Existen diferentes tipos de privilegios que pueden otorgarse y revocarse de los usuarios de la base de datos.
Cada DBMS proporciona ciertos tipos básicos de privilegios, como la capacidad de acceder a datos, crear objetos
de base de datos y realizar funciones del sistema. Cada DBMS también tendrá tipos adicionales de privilegios,
según las características que admita. Los siguientes tipos de privilegios los proporcionan habitualmente los
DBMS modernos:
1. Tabla: para controlar quién puede acceder y modificar los datos dentro de las tablas
2. Objeto de base de datos: para controlar quién puede crear nuevos objetos de base de datos y descartar
objetos de base de datos existentes
3. Sistema: para controlar quién puede realizar ciertos tipos de actividades en todo el sistema
4. Programa: para controlar quién puede crear, modificar y usar programas de base de datos
5. Procedimiento almacenado: para controlar quién puede ejecutar funciones específicas y procedimientos
almacenados

Concesión de privilegios de mesa

Los privilegios de tabla se otorgan para permitir a los usuarios acceder a tablas, vistas y columnas dentro de
tablas y vistas. Se pueden otorgar los siguientes privilegios para tablas y vistas:
1. SELECCIONAR: para permitir al usuario seleccionar de esta tabla / vista
2. INSERTAR: para permitir al usuario insertar filas en esta tabla / vista
3. ACTUALIZACIÓN: para permitir al usuario actualizar esta tabla / vista
4. ELIMINAR: para permitir al usuario eliminar filas de esta tabla / vista
5. ALL: para permitir al usuario seleccionar, insertar, actualizar y eliminar usando esta tabla / vista

Por ejemplo, para permitir que el usuario 7 elimine filas de la tabla de Títulos, se puede emitir la siguiente
declaración:
GRANT DELETE ON Títulos para usuario7;
Algunos privilegios de tabla se pueden especificar en el nivel de columna. Hacerlo puede ser deseable cuando a
ciertos usuarios se les debe permitir modificar columnas específicas de una tabla, pero no otras columnas. Los
privilegios SELECT y UPDATE pueden otorgarse para columnas específicas.
Por ejemplo, para permitir que el usuario7 actualice solo la columna au_id en la tabla de Títulos, se puede emitir
la siguiente declaración:
GRANT UPDATE ON Títulos (au_id) a usuario7;
Normalmente, el DBA otorgará privilegios de tabla a los programadores en un entorno de prueba para fines de
desarrollo. Además, los programadores y los usuarios finales pueden requerir privilegios de tabla en las tablas
de producción para ciertas tareas. Sin embargo, la mayoría del acceso a la producción debe controlarse
utilizando privilegios de programa y procedimiento almacenado, en lugar de privilegios de tabla directa.

Concesión de privilegios de objeto de base de datos

Los privilegios de objeto de base de datos controlan qué usuarios tienen permiso para crear estructuras de base
de datos. Los privilegios reales que pueden otorgarse dependerán del DBMS y de los tipos de objetos de base de
datos admitidos. En general, el DBMS proporcionará opciones para otorgar privilegios de CREAR en cada tipo de
objeto de base de datos, incluidas las bases de datos, los espacios de tabla, las tablas, los índices, los
desencadenantes, los valores predeterminados y los tipos de datos definidos por el usuario. Los privilegios de
objeto de base de datos controlan qué usuarios tienen permiso para crear estructuras de base de datos. Por
2

ejemplo, para habilitar user5 y user9 para crear tablas e índices, se puede emitir la siguiente declaración:
Página

GRANT CREATE table,

CREATE index
TO user5,
user9;
La capacidad de crear objetos de base de datos generalmente se reserva para DBA. Si estos privilegios se
otorgan a otros, la cantidad de objetos de base de datos existentes puede ser bastante difícil de controlar.
Además, se vuelve muy difícil rastrear qué objetos de la base de datos se están utilizando realmente, cuáles se
crearon y luego se abandonaron. Por estas razones, el DBA debe mantener esta autoridad para sí mismo, con
solo raras excepciones tal vez para las SA o desarrolladores muy hábiles.

Concesión de privilegios del sistema

Los privilegios del sistema controlan qué usuarios pueden usar ciertas funciones de DBMS y ejecutar ciertos
comandos de DBMS. Los privilegios del sistema disponibles variarán de DBMS a DBMS, pero pueden incluir la
capacidad de archivar registros de la base de datos, apagar y reiniciar el servidor de la base de datos, iniciar
rastreos para la supervisión, administrar el almacenamiento y administrar las cachés de la base de datos.
Los privilegios del sistema no se pueden otorgar a nivel de base de datos. Los privilegios del sistema se otorgan
a nivel de todo el sistema a través del DBMS. Por ejemplo, para permitir que el usuario6 inicie rastreos de
rendimiento, se puede emitir la siguiente declaración:

GRANT TRACE
TO user6;

Los privilegios del sistema no se pueden otorgar a nivel de base de datos. Los privilegios del sistema deben
otorgarse con cuidado y generalmente deben reservarse para el DBA y SA.

Concesión de privilegios de programa y procedimiento

La concesión del privilegio EXECUTE otorga al usuario permiso para ejecutar un programa o un procedimiento
almacenado. Por ejemplo, para habilitar user1 y user9 para ejecutar el procedimiento almacenado denominado
proc1, se puede emitir la siguiente instrucción:

GRANT EXECUTE on proc1

TO user1, user9;

Otorgar privilegios a los usuarios en programas y procedimientos es más fácil de controlar que otorgar
privilegios en tablas y columnas individuales. La lógica de procedimiento en el programa y el procedimiento
controla qué tablas y columnas específicas se pueden modificar. Además, el DBA puede mantener mejor la
integridad de los datos de producción si la única forma en que se puede cambiar es mediante programación.

Concesión a PÚBLICO

Como alternativa para otorgar acceso a un usuario de base de datos, el DBA puede optar por otorgar una
autorización particular a PUBLIC. Cuando se concede autorización a PUBLIC, el DBMS permitirá a cualquier
persona que pueda iniciar sesión en el DBMS esa autoridad en particular. Las subvenciones hechas a PUBLIC no
se pueden otorgar con la OPCIÓN WITH GRANT, ya que todos están en PÚBLICO. Por ejemplo, para otorgar a
toda la autoridad para eliminar filas de la tabla de títulos, se puede emitir la siguiente declaración:

GRANT DELETE on titles to PUBLIC;

Administrar la seguridad puede ser un deber complejo. El uso de la autoridad PÚBLICA para permitir el acceso
general a ciertos objetos y recursos de la base de datos a menudo parece más fácil que el control específico del
acceso por parte del usuario. Sin embargo, los DBA deben tener precaución al otorgar privilegios a PUBLIC.
Tenga cuidado al otorgar privilegios a PUBLIC. Cuando se concede un privilegio a PUBLIC, el DBA pierde el
control sobre ese objeto o recurso de la base de datos: cualquiera puede acceder o usar el objeto o recurso
según lo especificado por la declaración GRANT. Inevitablemente, los usuarios abusarán de los recursos
PÚBLICOS, y volver a tener el control del recurso será bastante difícil. Reserve el uso de la autoridad PÚBLICA
para esos pocos objetos y recursos de bases de datos que deberían estar disponibles para todos.
Alternativamente, la autoridad PÚBLICA puede ser un atajo útil si existe otro mecanismo de seguridad. Por
2

ejemplo, podría otorgar autorización de programa a PUBLIC para transacciones que se ejecutan bajo un
Página

procesador de transacciones y usan las facilidades de seguridad del procesador de transacciones para controlar
el acceso.

Revocando privilegios
La instrucción REVOKE se usa para eliminar privilegios que se otorgaron previamente. La sintaxis para REVOKE
es el "lado opuesto" de la sintaxis de GRANT. Además, los privilegios serán revocados automáticamente por el
DBMS cuando se descarta un objeto de base de datos. Por ejemplo, para revocar la capacidad de actualizar la
columna au_id de la tabla titles de user7.

REVOKE UPDATE on titles (au_id) from user7;

La revocación de un privilegio PUBLIC no eliminará ese privilegio de ningún usuario al que se le haya otorgado
en una declaración GRANT separada.

REVOKEs en cascada

Cuando se revocan los privilegios, el DBMS debe decidir si se necesitan revocaciones adicionales, basado en los
privilegios revocados Cuando una revocación hace que el DBMS revoque privilegios relacionados, se llama
REVOKES en cascada. Considere la jerarquía de autoridad representada en para otorgar un privilegio, digamos
X, a otros. Él otorga X a Pete y Phil con la opción GRANT. Pete a su vez otorga X a Bruce. Joe también otorga X a
Don, pero sin la opción de concesión.

Figura 14-2. REVOKEs en cascada

Ahora investiguemos el impacto de REVOKES en cascada al delinear qué sucede si revocamos el privilegio X de
Joe. En este caso, Joe no solo tendrá el privilegio X, sino que el DBMS también eliminará la autoridad de Pete,
Phil y Don. Además, dado que el privilegio X de Phil fue revocado, el efecto del revoque también se aplicará a
Bruce.
Para minimizar el impacto de REVOKES en cascada, evite otorgar privilegios utilizando la OPCIÓN WITH GRANT.
Cuantos menos usuarios puedan otorgar privilegios posteriores, más fácil será gestionar y administrar una
infraestructura de seguridad de DBMS viable.
Evite otorgar privilegios utilizando la opción WITH GRANT.

Cronología y revocaciones

El momento de una declaración GRANT o REVOKE puede influir en su impacto. Por ejemplo, en algunos DBMS es
posible otorgar un privilegio a todos los usuarios excepto a un usuario específico mediante la emisión de las
siguientes declaraciones:

GRANT DELETE on titles to public;

COMMIT;
REVOKE DELETE on titles from userx;

El momento de una declaración GRANT o REVOKE puede influir en su impacto.

La primera declaración otorga a toda la autoridad para eliminar datos de la tabla de títulos. Debido a que la
instrucción REVOKE se emite después de GRANT a público, el userx individual tiene prohibido eliminar datos de
esta tabla. Algunos DBMS (por ejemplo, DB2) no permitirán tales exclusiones, porque la autoridad PÚBLICA
anulará cualquier revocación; otros DBMS (por ejemplo, Microsoft SQL Server) permitirán tales exclusiones.
El DBA necesita comprender exactamente cómo funcionan los GRANT y REVOKES para cada DBMS que se
administra con el fin de administrar adecuadamente los privilegios sobre los objetos y recursos de la base de
datos.

Informes de seguridad
2Página

Una vez otorgado, el DBA deberá supervisar e informar sobre los privilegios que tienen los usuarios. La
seguridad de la base de datos se mantiene en el catálogo del sistema. El DBA puede usar SQL para recuperar la
información necesaria de las tablas apropiadas del catálogo del sistema. Alternativamente, algunos DBMS
brindan vistas y procedimientos almacenados en el sistema que simplifican la recuperación de la seguridad de la
base de datos. Sin embargo, como consideración adicional, asegúrese de proteger adecuadamente la seguridad
del catálogo del sistema, especialmente dentro del sistema de producción. Solo el DBA, SA y el administrador de
seguridad requieren acceso a la información de seguridad de la base de datos almacenada en el catálogo del
sistema. Asegúrese de proteger adecuadamente la seguridad del catálogo del sistema. Los requisitos y
expectativas de seguridad del usuario tienden a evolucionar con el tiempo. A medida que se agregan nuevas
aplicaciones y cambian los requisitos del negocio, la seguridad de la base de datos tendrá que cambiar. Las
revisiones de seguridad deben realizarse de forma regular para garantizar que la seguridad de la base de datos,
tal como se implementó, siga cumpliendo con los requisitos actuales del usuario. Los informes de las tablas del
catálogo del sistema se pueden usar para proporcionar la información para tales revisiones.
Roles y grupos de autorización
Además de otorgar privilegios a usuarios individuales, el DBMS puede proporcionar la capacidad de asignar
1. Privilegios específicos para un rol, que luego se otorga a otros
2. Grupos de privilegios incorporados específicos para los usuarios
Por supuesto, la terminología no es estricta entre los DBMS principales. Algunos DBMS se refieren a roles como
grupos, y viceversa. Como administrador de bases de datos, tendrá que comprender cómo cada DBMS que
administra implementa roles y grupos, y cómo cada una de estas funciones se puede utilizar para simplificar la
administración de seguridad de la base de datos.

Roles

Una vez definido, un rol se puede usar para otorgar uno o más privilegios preasignados a un usuario. Un rol es
esencialmente una colección de privilegios. El DBA puede crear un rol y asignar ciertos privilegios a ese rol.
Entonces el rol se puede asignar a uno o más usuarios. La administración de la seguridad de la base de datos se
simplifica de esta manera. Por ejemplo, considere la siguiente secuencia de declaraciones:

CREATE role MANAGER;

COMMIT;
GRANT select, insert, update, delete on employee to MANAGER;
GRANT select, insert, update, delete on job_title to MANAGER;
GRANT execute on payroll to MANAGER;
COMMIT;
GRANT MANAGER to user1;
COMMIT;

El DBA puede crear un rol y asignar ciertos privilegios a ese rol. Este script crea un nuevo rol denominado
MANAGER, otorga privilegios en ciertas tablas y procedimientos al rol y luego asigna user1 al rol de MANAGER. A
los usuarios adicionales se les puede asignar el rol de ADMINISTRADOR, y el DBA no tendrá que recordar emitir
cada una de las declaraciones GRANT individuales, porque ya han sido asignadas al rol de ADMINISTRADOR.

Grupos

La autoridad a nivel de grupo es similar a los roles. Sin embargo, cada DBMS proporciona grupos integrados que
no se pueden cambiar. Cada DBMS implementa la seguridad de la base de datos de nivel de grupo de diferentes
maneras y con diferentes nombres de grupo y privilegios. Sin embargo, hay algunas similitudes entre DBMS. Los
siguientes grupos son comunes entre los principales SGBD. Cada DBMS proporciona grupos integrados que no se
pueden cambiar.

1. Administrador de sistema. A veces abreviado SA o SYSADM, el grupo administrador del sistema es el más
poderoso dentro del DBMS. Un usuario al que se le concede autorización de nivel SA puede ejecutar
todos los comandos de base de datos y acceder a todas las bases de datos y objetos. El administrador del
sistema suele ser el responsable de instalar el DBMS y se considera el propietario de los recursos del
sistema y de las tablas del catálogo del sistema.
2. Administrador de base de datos. A veces abreviado como DBADM o DBA, el grupo administrador de la
base de datos otorga todos los privilegios sobre una base de datos específica, más la capacidad de
acceder, pero no modificar, los datos en tablas dentro de esa base de datos. Los usuarios a los que se les
ha asignado una autoridad de nivel DBA pueden colocar y modificar cualquier objeto dentro de la base de
datos (espacios de tabla, tablas e índices).
2

3. Mantenimiento de base de datos. A veces abreviado como DBMAINT, el grupo de mantenimiento de la

Página

base de datos incluye los privilegios específicos de la base de datos para mantener los objetos de la base
de datos (como la capacidad de ejecutar utilidades y emitir comandos). Al igual que el grupo DBA, el
privilegio de nivel DBMAINT se otorga base de datos por base de datos.
4. Administrador de seguridad. La función de administrador de seguridad tiene el conjunto de privilegios
que permite otorgar y revocar la seguridad de la base de datos en todo el DBMS. El administrador de
seguridad puede realizar cualquier actividad relacionada con la seguridad de la base de datos, incluida la
 administración de inicio de sesión y contraseña, auditoría, configuración de seguridad, así como GRANTs
y REVOKES. Otro nombre común para el rol de administrador de seguridad es SSO.
5. Control de operaciones. A veces denominado OPER o SYSOPR, la función de control de operaciones tiene
la autoridad para realizar tareas operativas de bases de datos, como copias de seguridad y recuperación,
o para terminar tareas desbocadas.

Limite el número de usuarios de SA

Una sola organización debe limitar el número de usuarios a los que se les asigna la función SA o la autoridad de
nivel de grupo. Un usuario con capacidades SA es muy poderoso. Solo los DBA corporativos y los programadores
de sistemas deben tener este nivel de autoridad. Los usuarios finales, los gerentes y el personal de desarrollo de
aplicaciones no necesitan la autorización de las SA para realizar su trabajo.
Un usuario con capacidades SA es muy poderoso.

Seguridad de nivel grupal y REVOKES en cascada

Según el grupo, algunos usuarios a los que se les han asignado privilegios de nivel de grupo pueden otorgar
privilegios a otros usuarios. Si la autoridad de nivel de grupo se revoca desde ese usuario, todos los privilegios
otorgados por ese usuario también serán revocados. Esto es similar a los REVOKES en cascada que ocurren
como resultado de la opción WITH GRANT.
Antes de revocar una autorización a nivel de grupo de un usuario, asegúrese de determinar el impacto de
REVOKES en cascada y prepárese para volver a aplicar los privilegios necesarios que se eliminarán debido al
efecto de cascada.

Otros mecanismos de seguridad de la base de datos

Los productos DBMS relacionales modernos admiten muchas capacidades y cualidades que pueden ayudar a
proteger los datos. Algunas de estas capacidades no son principalmente características de seguridad. Por
ejemplo, las vistas y los procedimientos almacenados se pueden usar con fines de seguridad, aunque ese no sea
su objetivo principal.

Usar vistas para seguridad

La mayoría de la seguridad de la base de datos se realiza utilizando la seguridad nativa del DBMS. Sin embargo,
es posible simplificar algunos aspectos de la seguridad de la base de datos creando vistas para proteger sus
datos. Su organización ha implementado una tabla de empleados que contiene información pertinente sobre
todos los empleados. Las columnas dentro de la tabla existen para almacenar el nombre y apellido del
empleado, la inicial del segundo nombre, la dirección, el teléfono, el salario, etc. Concesión del privilegio SELECT
en la tabla de empleados a un grupo de usuarios puede causar un problema de seguridad. Si bien la seguridad
de la aplicación se mantiene con este escenario, la seguridad personal no se debe a que el usuario pueda
acceder a los detalles personales, incluida la información salarial, de los compañeros empleados. Se podría crear
una vista que omita la información confidencial de la tabla de empleados. Al crear la vista sin las columnas
sensibles, los usuarios pueden obtener el privilegio SELECCIONAR en la vista y podrán acceder a la información
del empleado que se considere apropiada. Por ejemplo,

CREATE view emp_all

AS
SELECT first_name, last_name, middle_initial,
street_address, state, zip_code
FROM employee;

Se puede crear una vista que omite información confidencial.

Este sencillo ejemplo muestra una vista que especifica solo ciertas columnas de la tabla base. Una vez que se ha
creado la vista y se le ha otorgado al usuario el privilegio SELECT en la vista, solo se puede recuperar la
información especificada en la vista. Cuando una vista elimina columnas de una tabla base, se denomina
restricción vertical. Por supuesto, la definición de sensible variará de una organización a otra. En nuestro
2

ejemplo, el
información salarial y telefónica fueron eliminados. Es bastante simple entender por qué el salario es
Página

sensible, pero ¿y el número de teléfono? Y si el número de teléfono es sensible, quizás el

la dirección del empleado también debería ser. Las vistas le permiten especificar fácilmente la seguridad de
nivel de columna
considerado necesario para su organización.
La restricción vertical que utiliza vistas es una alternativa a la especificación de columnas cuando se otorgan
privilegios de tabla. También puede ser más fácil de implementar y administrar.
Las vistas también se pueden usar para proporcionar seguridad a nivel de fila en función del contenido de los
datos. Esto se denomina restricción horizontal y se implementa codificando las cláusulas WHERE apropiadas en
la vista. Por ejemplo,

CREATE view emp_dept20

AS
SELECT first_name, last_name, middle_initial,
street_address, state, zip_code FROM employee
WHERE deptno = 20;

Cuando los usuarios seleccionan de la vista, solo se devolverán las filas que coincidan con el predicado. Esta
vista devolverá solo a los empleados que trabajen en el departamento 20. Cuando los usuarios modifican filas de
la vista, si se ha especificado WITH CHECK OPTION, los predicados garantizarán que los valores no se puedan
actualizar o insertar fuera del rango. Además, las filas que no coinciden con el predicado no se pueden eliminar
utilizando la vista cuando se especifica WITH CHECK OPTION.

Uso de procedimientos almacenados para la seguridad

Los procedimientos almacenados se pueden usar para proporcionar un nivel adicional de seguridad. El privilegio
de ejecutar un procedimiento almacenado debe otorgarse o revocarse explícitamente, independientemente de
la seguridad implementada en las tablas base subyacentes.

El privilegio para ejecutar un procedimiento almacenado debe ser explícitamente otorgado o revocado.
Base de datos privada virtual de Oracle
Oracle9i proporciona control de acceso a nivel de fila a través de su tecnología Virtual Private Database
(VPD). VPD se habilita asociando una o más políticas de seguridad con tablas o vistas. Cuando se accede
a la tabla, ya sea directa o indirectamente, la base de datos consultará una función que implementa la
política. La política es básicamente un predicado SQL (o cláusula WHERE) que la base de datos agrega a
la declaración SQL del usuario. Esto modifica dinámicamente el acceso a los datos del usuario.
Con VPD, un usuario solo puede recuperar y manipular datos que coincidan con la cláusula WHERE de la
política. En esencia, esto funciona como crear una vista dinámica (usando WITH CHECK OPTION) que
siempre se aplica y se aplica.

Los procedimientos almacenados se pueden codificar para acceder solo a subconjuntos de datos a nivel de fila
y / o columna. La capacidad de ejecutar estos procedimientos almacenados se puede otorgar a los usuarios. Si
no se otorgan privilegios en las tablas base subyacentes, los usuarios solo podrán acceder a los datos
ejecutando el procedimiento almacenado, proporcionando así la seguridad requerida.
Además de proporcionar un nivel de seguridad, este método puede proporcionar un mejor rendimiento si los
algoritmos en el procedimiento están codificados correctamente.

Seguridad orientada a la lógica

A veces es necesario implementar seguridad basada en un algoritmo. Por ejemplo, ¿qué sucede si solo un
subconjunto de usuarios puede acceder a una tabla específica durante una hora específica del día? Este criterio
se puede codificar en el procedimiento almacenado. Cada vez que se ejecuta el procedimiento almacenado,
comprueba el usuario y la hora del día antes de permitir el acceso. Algunos productos DBMS ofrecen una
funcionalidad especial para la seguridad de la base de datos. Consulte la barra lateral "Oracle Virtual Private
Database" para ver un ejemplo de dicha funcionalidad.

Revisión de cuentas
La auditoría es una función de DBMS que permite a los DBA rastrear el uso de los recursos y privilegios de la
base de datos. Cuando la auditoría está habilitada, el DBMS generará un registro de auditoría de las operaciones
de la base de datos. Cada operación de base de datos auditada produce una pista de auditoría de información
2

que incluye qué objeto de la base de datos se vio afectado, quién realizó la operación y cuándo. Dependiendo
Página

del nivel de auditoría soportado por el DBMS, también se puede registrar un registro real de los datos realmente
cambiados. El seguimiento de quién hace qué datos es importante porque hay muchas amenazas a la seguridad
de sus datos. (Consulte la barra lateral "Amenazas a la seguridad").

La auditoría permite a los DBA rastrear el uso de los recursos y privilegios de la base de datos.
Amenazas a la seguridad
 Los agentes externos que intentan comprometer su seguridad y acceder a los datos de su empresa se
consideran correctamente una amenaza para la seguridad. Sin embargo, los estudios de la industria han
demostrado que del 60% al 80% de las amenazas de seguridad son internas, dentro de su organización.
La amenaza de seguridad más típica es un actual o ex empleado descontento o malévolo que tiene
acceso válido al DBMS. La auditoría es crucial porque es posible que necesite encontrar una instancia de
acceso no autorizado por un usuario autorizado.

Tenga en cuenta que la auditoría rastrea lo que ha hecho un usuario en particular una vez que se ha permitido
el acceso. La auditoría ocurre después de la actividad; no hace nada para prohibir el acceso. Las pistas de
auditoría ayudan a promover la integridad de los datos al permitir la detección de infracciones de seguridad,
también conocidas como detección de intrusos. Un sistema auditado puede servir como un elemento de
disuasión contra los usuarios que manipulen los datos porque ayuda a identificar a los infiltrados.
Un seguimiento de auditoría puede ser útil en muchas situaciones. Las prácticas comerciales y las políticas de
seguridad de su empresa pueden dictar una capacidad integral para rastrear cada cambio de datos hasta el
usuario iniciador. Tal vez las regulaciones gubernamentales exijan que su organización analice el acceso a los
datos y produzca informes periódicos. Es posible que se le solicite que presente informes detallados de forma
continua, o tal vez solo necesite identificar, en cada caso, la causa raíz de los problemas de integridad de los
datos. La auditoría es beneficiosa para todos estos propósitos.
Una función de auditoría típica permite la auditoría en diferentes niveles dentro del DBMS, por ejemplo, en la
base de datos, el nivel de objeto de la base de datos y los niveles de usuario. Uno de los mayores problemas con
las instalaciones de auditoría de DBMS es la degradación del rendimiento. Los registros de auditoría que se
producen deben ser lo suficientemente detallados como para capturar imágenes de antes y después de los
cambios en la base de datos. Sin embargo, capturar tanta información, particularmente en un sistema ocupado,
puede causar que el rendimiento sufra. Además, esta pista de auditoría debe almacenarse en algún lugar, lo que
es problemático cuando se produce una gran cantidad de cambios. Por lo tanto, la mayoría de las instalaciones
de auditoría permiten la creación selectiva de registros de auditoría para minimizar el rendimiento y los
problemas de almacenamiento.
La mayoría de las instalaciones de auditoría permiten la creación selectiva de registros de auditoría.

Aunque cada DBMS ofrece diferentes capacidades de auditoría, algunos elementos comunes que pueden ser
auditados por las instalaciones de auditoría de DBMS incluyen:
1. Intentos de inicio de sesión y cierre de sesión (tanto exitosos como fallidos)
2. El servidor de base de datos se reinicia
3. Comandos emitidos por usuarios con privilegios de administrador del sistema
4. Intento de violaciones de integridad (cuando los datos cambiados o insertados no coinciden con una
restricción referencial, única o de verificación)
5. Operaciones SELECT, INSERT, UPDATE y DELETE
6. Ejecuciones de procedimientos almacenados
7. intentos fallidos de acceder a una base de datos o una tabla (fallas de autorización)
8. Cambios a las tablas del catálogo del sistema
9. Operaciones a nivel de fila

Cuando el DBMS no admite el nivel o tipo de auditoría requerida, se pueden comprar herramientas de análisis de
registro de ISV de terceros para recuperar todo tipo de información del registro de transacciones de la base de
datos.

Cada DBMS proporciona diferentes medios para ver los datos auditados. Los informes formateados y las
herramientas gráficas de informes que leen y presentan la información de auditoría de manera razonable
facilitan la identificación de problemas de seguridad entre muchas operaciones de bases de datos registradas.
Como nota adicional, la auditoría también se puede usar para la recuperación de datos. Examinaremos este
aspecto de la auditoría en el Capítulo 15.
La auditoría también se puede usar para la recuperación de datos.

Si ha activado la auditoría de la base de datos en su sitio, tenga en cuenta los siguientes consejos:
1. La auditoría puede ser un gran consumidor de recursos del sistema. Cuando la cola de auditoría está
3

llena, las tareas que generan registros de auditoría esperarán hasta que se reanude la tarea de auditoría.
Página

Considere usar una cola de auditoría más grande si el rendimiento sufre. Como último recurso, suspenda
la auditoría cuando el rendimiento sea inaceptable.
2. Coloque las tablas del catálogo del sistema que almacenan la información relacionada con la seguridad
en un disco separado e inactivo. Esto mejorará el rendimiento de auditoría al disminuir la contención de
la cabeza.
 3. Asegúrese de que el conjunto de datos o la tabla utilizada para almacenar los datos de auditoría no se
llenen. Cuando el conjunto de datos de auditoría está lleno, la auditoría se desactivará, los registros en la
cola de auditoría actual se perderán y cualquier tarea del usuario que intente enviar datos a la cola de
auditoría se cancelará.

Seguridad externa
Además de la seguridad de la base de datos, el administrador de bases de datos debe garantizar que ciertos
recursos utilizados por el SGBD estén protegidos contra el acceso fuera del control del SGBD. Si no se accede a
los recursos de la base de datos utilizando comandos DBMS y sentencias de SQL, no se puede confiar en los
mecanismos de seguridad de la base de datos para imponer la autenticación de usuario adecuada.
Cuando se utilizan mecanismos de seguridad externos para proteger los recursos relacionados con la base de
datos, el DBA debe centrarse principalmente en los conjuntos de datos y archivos utilizados por el DBMS. Los
conjuntos de datos para proteger en el sistema operativo o el nivel del sistema de archivos incluyen
1. Archivos de datos del catálogo del sistema
2. Archivos de registro activo y de archivo
3. Conjuntos de datos de usuario para espacios de tabla
4. Conjuntos de datos de usuario para índices
5. Archivos de datos de auditoría
6. Archivos de seguimiento de rendimiento
7. Archivos de programa y script (tanto fuente como código ejecutable)
Enfóquese principalmente en los conjuntos de datos y archivos utilizados por el SGBD.
Los usuarios ingeniosos que intentan hacer travesuras pueden descubrir el formato de estos archivos y acceder
a los datos no autorizados si no protege estos conjuntos de datos y archivos. Se puede lograr un nivel adicional
de protección al comprimir los datos dentro del DBMS. Esto impone una carga adicional al hacker de tratar de
descomprimir los datos. Por supuesto, la compresión no es suficiente protección.
Si el software de encriptación de datos está disponible para su uso dentro de los archivos de bases de datos,
considere usarlo. El cifrado de datos es una técnica de seguridad que codifica datos legibles en un formato
codificado, por lo que los archivos no se pueden leer sin la clave de cifrado. La idea general es hacer que el
esfuerzo de descifrado sea tan difícil que supere la ventaja para el pirata informático de acceder a los datos no
autorizados.
Puede ser necesario aplicar seguridad adicional a los recursos del sistema DBMS, como el almacenamiento físico
y los espacios de direcciones utilizados para ejecutar el DBMS, la consola DBMS y los archivos utilizados para
instalar el DBMS.

Programación y seguridad de trabajo

La mayoría de las organizaciones planifica que las tareas se ejecuten en momentos predeterminados, y cuando
esas tareas implican el acceso a la base de datos, se debe otorgar autoridad al programador. La programación
generalmente se lleva a cabo utilizando un programador de tareas de terceros como CA-7, Control-M o AutoSys.
Cuando el software de programación se utiliza para controlar el envío y la programación de programas por lotes
y scripts, el DBA tendrá que determinar la mejor manera de otorgar seguridad de base de datos al programador.
No es una buena idea otorgar autoridad SYSADM al planificador de trabajos. Hacerlo permitiría que cualquier
trabajo realice cualquier tarea de base de datos, creando problemas de seguridad potencialmente severos. En
su lugar, determine cómo otorgar autorización individual a trabajos específicos utilizando las instalaciones del
paquete de programación y el DBMS. Se pueden configurar muchos planificadores de tareas para generar una
identificación de usuario para cada trabajo. La identificación generada puede recibir la autorización adecuada en
función del tipo de acciones autorizadas para ese trabajo en particular. No es una buena idea conceder
autorización SYSADM al planificador de tareas. Otro error común de seguridad cometido en algunas tiendas es
incorporar contraseñas reales en trabajos y scripts de utilidad de base de datos. Si la contraseña está codificada
en el trabajo, cualquiera puede leerla y usarla en otro lugar del sistema. Esto no protege la seguridad de sus
datos.

Seguridad de DBA no DBMS

El DBA deberá poseer un nivel bastante alto de autoridad de sistema operativo para realizar el trabajo de
3

administración y administración de las bases de datos y datos de la organización. Por ejemplo, en el entorno
Página

UNIX, algunas tareas de instalación requieren autorización raíz. Esta situación se puede manejar de dos
maneras: otorgue la autorización raíz DBA para realizar la instalación o cambie las tareas de instalación
específicas que requieren autorización de raíz al administrador del sistema UNIX. Cualquiera de las opciones es
viable. Mi preferencia es otorgar la autoridad a los DBA si el personal del DBA posee el nivel requerido de
habilidades de UNIX para comprender las ramificaciones de tener autoridad de raíz. De cualquier forma, sin
embargo, los DBA y las SA deberán cooperar para crear un enfoque de seguridad de sistema operativo efectivo
que permita al DBA realizar su trabajo mientras que al mismo tiempo protege la seguridad y la integridad de la
plataforma.

Resumen
La seguridad de la base de datos es un componente importante del trabajo de un DBA. Sin un plan de seguridad
de base de datos integral e implementación, la integridad de las bases de datos de su organización se verá
comprometida. Cada DBA debe conocer los mecanismos de seguridad a su disposición para garantizar que solo
los usuarios autorizados accedan y cambien datos en las bases de datos de la compañía.
Cada DBA debe aprender los mecanismos de seguridad a su disposición.
Además, el DBA debe implementar operaciones de auditoría para verificar que las medidas de seguridad de la
base de datos implementadas sean adecuadas

3Página