Temario de oposiciones

INFORMÁTICA
Alexandre Dapena Mora
Jose Luis Villanueva de Matos
Eladio Rial Núñez
Temario de oposiciones de
INFORMÁTICA
Alexandre Dapena Mora
Jose Luis Villanueva de Matos
Eladio Rial Núñez
Última edición 2016
Autores: Alexandre Dapena Mora, Jose Luis Villanueva de Matos y Eladio Rial Núñez
Maquetación: Educàlia Editorial
Edita: Educàlia Editorial
Imprime: SERVICECOM
ISBN: 978-84-16663-78-1
Depósito legal: En curso
Printed in Spain/Impreso en España.
Todos los derechos reservados. No está permitida la reimpresión de ninguna parte de este libro,
ni de imágenes ni de texto, ni tampoco su reproducción, ni utilización, en cualquier forma o por
cualquier medio, bien sea electrónico, mecánico o de otro modo, tanto conocida como los que
puedan inventarse, incluyendo el fotocopiado o grabación, ni está permitido almacenarlo en un
sistema de información y recuperación, sin el permiso anticipado y por escrito del editor.

Alguna de las imágenes que incluye este libro son reproducciones que se han realizado
acogiéndose al derecho de cita que aparece en el artículo 32 de la Ley 22/18987, del 11 de
noviembre, de la Propiedad intelectual. Educàlia Editorial agradece a todas las instituciones, tanto
públicas como privadas, citadas en estas páginas, su colaboración y pide disculpas por la posible
omisión involuntaria de algunas de ellas.

Educàlia Editorial
Avda de les Jacarandes 2 loft 327 46100 Burjassot-València
Tel. 960 624 309 - 963 768 542 - 610 900 111
Email: educaliaeditorial@e-ducalia.com
www.e-ducalia.com
 TEMA 43
Administración de sistemas de bases de datos.

1. Introducción
2. Instalación
2.1. Creación de la base de datos
3. Gestión de usuarios y seguridad
4. Administración
4.1. Monitorización
4.2. Gestión de espacio
4.3. Copias de seguridad
4.4. Distribución de los datos
5. Optimización
5.1. Optimización del entorno
5.2. Optimización de objetos de BD
5.3. Optimización de consultas
5.4. Herramientas particulares de algunos SGBDs

1. INTRODUCCIÓN
Un sistema gestor de base de datos (SGBD) es un conjunto de programas que permiten el alma-
cenamiento, modificación y extracción de la información en una base de datos, además de propor-
cionar herramientas para explotar, gestionar y administrar las bases de datos.
La figura del administrador de la base de datos (DBA) será la responsable de asegurar el acceso
a los datos de manera óptima, para lo cual tendrá que llevar a cabo una serie de tareas:
- Elección del SGBD idóneo e instalación del SGBD y de las bases de datos:
o Diseñar la arquitectura y desplegar los sistemas gestores de bases de datos
o Crear, dar soporte y gestionar las bases de datos corporativas
- Explotación del SGBD:
o Arrancar y parar las BDs
o Asegurar la disponibilidad de los datos
o Asegurar la integridad de la información
o Hacer copias de seguridad periódicas de los datos y mantenerlos a salvo de la destrucción
accidental o intencional
o Diseñar un plan de recuperación para que cuando se presenten los problemas, los datos
se pueden restaurar rápidamente.
- Administración:
o Colaborar con el administrador del SO en la gestión de los archivos de almacenamiento y
gestión del espacio en disco ocupado.

Prohibida la reproducción total o parcial sin permiso escrito del editor Página 4 Tel. 963 768 542 - 960 624 309 - 610 900 111
 o Establecer estándares de uso, políticas de acceso y buenas prácticas de diseño de bases
de datos.
- Gestión de usuarios y seguridad:
o Crear y mantener las cuentas de usuarios y permisos
o Establecer auditorías del sistema para detectar anomalías, intentos de violación de la se-
guridad, accesos inadecuados, etc
- Optimización:
o Optimizar el SGBD, los objetos de base de datos y las consultas más habituales.

2. INSTALACIÓN
El primer paso para la puesta en producción de una base de datos es la instalación del gestor de
bases de datos. El proceso de instalación dependerá en gran medida el producto de que se trate y del
sistema operativo sobre el que se realizará la instalación. La práctica totalidad de sistemas de bases
de datos actuales tienen una arquitectura de cliente-servidor y proveen de sus propias herramientas y
asistentes para realizar la instalación tanto del servidor como del cliente, y establecer la conexión entre
ellos.
Los componentes básicos de la instalación son los siguientes:
- Motor del SGBD
- Herramientas de administración del SGBD
- Aplicaciones de comunicación
- Consola interactiva o herramientas de desarrollo para el acceso a las BDs
Antes de proceder a la instalación del SGBD será necesario tomar varias decisiones como:
- Tipo de sistema de bases de datos: actualmente existen tres tipos fundamentales de sistemas
de bases de datos: sistemas orientados a objetos (específicos para aplicaciones basadas en el
paradigma de la OO), relacionales (bases de datos SQL habituales) y bases de datos noSQL. Los
sistemas noSQL tienen como objetivo solventar uno de los problemas fundamentales de los SGBDs
relacionales: la escalabilidad. No requieren por lo general esquemas fijos, evitan las operaciones
join almacenando datos desnormalizados y están diseñadas para escalar horizontalmente. Son los
sistemas más adecuados para almacenamiento y procesamiento de big data.
- Ubicación de la BD: si será una BD centralizada (con un único nodo encargado de procesar todas
las peticiones de los usuarios) o distribuida (con varios nodos independientes, de forma que cada
uno de ellos puede funcionar de forma autónoma). A su vez, una BD centralizada puede imple-
mentarse en una sola máquina física o por medio de un clúster de servidores, de forma que aun-
que lógicamente se vea como un solo sistema, sea posible balancear la carga entre los distintos
servidores de la red.

2.1. CREACIÓN DE LA BASE DE DATOS

Una vez instalado el SGBD será necesario crear las bases de datos donde se almacenará la in-
formación. Existen numerosos parámetros que se pueden modificar para que el rendimiento de la BD
sea óptimo. Estos parámetros dependerán del SGBDs en cuestión que aloje la base de datos, pero hay
varios tipos de parámetros comunes:
- Idioma: idioma de los datos, mapa de caracteres utilizado,..
- Gestión de memoria: Para cada BD activa el SGBD reserva una zona de memoria donde se alma-
cenarán los procesos del servidor que se ejecutan los procesos de la BD, y una zona específica
de memoria para cada usuario conectado a la BD (con sus áreas de E/S y comunicación con el
SGBD). El tamaño de cada una de estas zonas de memoria se determina por medio de paráme-
tros de configuración de la BD.
- Gestión de ficheros: ficheros de logs, de control, de datos, temporales, de redo,...

Prohibida la reproducción total o parcial sin permiso escrito del editor Página 5 Tel. 963 768 542 - 960 624 309 - 610 900 111
 - Utilización de la BD: hay varios parámetros que dependerán del uso que se vaya a hacer de esa
base de datos: si serán bases de datos transaccionales (OLTP) o de Data warehouse (OLAP). Las
arquitecturas de ambos sistemas son completamente diferentes, por lo que hay diversos paráme-
tros que será necesario adaptar en función de la arquitectura utilizada: el tamaño por defecto del
bloque de datos, el tamaño del segmento temporal, el tipo de optimizador (existe un optimizador
específico para la arquitectura en estrella de los entornos OLAP), el modo del optimizador (para
que priorice la minimización de E/S al disco o el coste de CPU), ...
- Parámetros de restricción: destinados a aplicar límites o cuotas para evitar la acaparación de re-
cursos por parte de un usuario o limitar el número de procesos simultáneos que se ejecutan sobre
la BD.
La creación de las bases de datos y todos sus objetos asociados (esquemas, tablas, vistas, sinó-
nimos, restricciones, enlaces de bases de datos, ...) pueden llevarse a cabo por medio del lenguaje
de definición de datos (DDL), pero habitualmente los SGBDs ya proveen sus propias herramientas con
interfaz gráfica para facilitar esta labor.

3. GESTIÓN DE USUARIOS Y SEGURIDAD

La mayoría de los SGBD instalados en entornos de producción son sistemas multiusuario, por lo
que es necesario llevar a cabo una gestión del acceso a la información para garantizar la confiden-
cialidad de los datos.
El lenguaje SQL tiene un sublenguaje denominado DCL (lenguaje de control de datos) que permi-
te gestionar los recursos que se asignan. Los comandos principales de este lenguaje son “grant”, para
asignar permisos y “revoke” para quitarlos.
Existen varias opciones a considerar a la hora de definir una política de permisos de acceso:
1. Usuarios, roles y perfiles: Una base de datos puede tener un número muy elevado de usuarios con
distintos permisos y restricciones, lo que complica el mantenimiento y gestión de sus permisos de
accesos. Para simplificar esta labor existen los roles y perfiles, que permiten gestionar permisos y
restricciones de forma conjunta para varios usuarios. Cada rol se correspondería con un conjunto
de permisos, y cada perfil con una serie de restricciones, de forma que en lugar de asignar los
permisos y restricciones a los usuarios directamente, los permisos se asignarían a un rol y las restric-
ciones a un perfil, y a cada usuario se le asignaría el rol y perfil que correspondiese a su tipo de
usuario.
Por medio de los roles no solamente se puede controlar el acceso de los usuarios a la información
de la BD sino que también se puede controlar las operaciones que puede realizar ese usuario con-
tra la BD (crear objetos, modificar la información, reasignar permisos, etc).
2. Tablas, sinónimos y vistas: A la hora de asignar permisos a los usuarios o roles existen varias opcio-
nes:
o Asignar los permisos directamente sobre las tablas de la base de datos: de forma que los
usuarios podrían acceder directamente a las tablas a las que tengan permiso o bien por
medio de sinónimos a esas tablas (lo que facilitaría la monitorización y auditoría).
o Crear una vista específica para cada usuario o rol y asignar permisos sobre las vistas. Esta es
la opción propuesta en la arquitectura ANSI-SPARC de base de datos, de forma que para
cada usuario o rol se crearía un esquema externo y los permisos se asignarían a las vistas
del esquema externo de cada usuario o rol. Esta opción es más potente que la anterior ya
que no solamente permite gestionar a qué tablas accede cada usuario sino que la propia
definición de la vista puede incluir restricciones por filas y por columnas.
3. Auditoría: algunos SGBDs permiten automatizar la auditoría de acceso a determinados datos, de
modo que es posible conocer quién y cuándo accede a la base de datos, qué acciones realiza
y sobre qué objetos. Esta información se almacena en tablas del sistema, por lo que hay que pre-
ver algún plan de gestión de histórico y limitar el número de columnas auditadas. Además, llevar
control de la auditoría implica una carga adicional para el sistema (cada operación implica la
inserción de al menos un registro en la tabla de auditoría), por lo que es necesario alcanzar un

Prohibida la reproducción total o parcial sin permiso escrito del editor Página 6 Tel. 963 768 542 - 960 624 309 - 610 900 111
 compromiso entre seguridad y rendimiento. La auditoría es muy útil para implementar requisitos de
la LOPD (control de acceso a datos personales), ya que permite delegar en el SGBD el registro de
todos los accesos y las operaciones llevadas a cabo sobre los datos auditados.
4. Cifrado de la información: otra de las utilidades que ofrecen los SGBD es la posibilidad de cifrar y
descifrar automáticamente la información almacenada (columnas e incluso tablas enteras). Este
cifrado puede realizarse a varios niveles: a nivel de autenticación de usuario, cifrado de las comu-
nicaciones, cifrado de los ficheros físicos donde se almacena la información e incluso de los bac-
kups generados. La aplicación de algoritmos de cifrado y descifrado de datos en cada acceso a
la información implica una carga adicional para el sistema, por lo que no se recomienda abusar
de esta posibilidad y normalmente se reserva a datos especialmente críticos.
5. Gestión de recursos: Otra de las herramientas que proveen algunos SGBDs es la posibilidad de
gestionar los recursos del sistema: reservando recursos, limitando la disponibilidad de recursos o
impidiendo el paralelismo a grupos de usuarios determinados. Estas herramientas hacen uso del
diccionario de datos para indicar a qué grupo consumidor pertenece cada usuario y qué limita-
ciones de recursos tiene cada grupo, por lo que facilita la consulta y control de esta información.

4. ADMINISTRACIÓN
4.1. MONTORIZACIÓN
Una de las herramientas que suelen proporcionar los SGBDs actuales es el monitor del rendimiento
del servidor. Por medio de esta herramienta es posible consultar el uso que el sistema hace de los recur-
sos (CPU, memoria, red, disco, ...), y prevenir posibles problemas en el sistema. Algunas de las posibilida-
des que ofrece el monitor del SGBD son las siguientes:
- Detección de bloqueos: De forma general podríamos decir que cuando un usuario comienza
una operación de modificación de datos sobre una tabla, ésta se bloquea, y cualquier petición
de modificación de otro usuario quedaría bloqueada en espera de la finalización de esta mo-
dificación, pudiendo dar lugar a interbloqueos u otras situaciones indeseadas. Por medio de la
monitorización del SGBD es posible comprobar si se están produciendo bloqueos en un momento
dado o incluso consultar si se producen habitualmente para tratar de evitarlos (algunos bloqueos
pueden evitarse particionando la tabla, dividiendo su contenido en varios ficheros, modificando
el espacio libre en los bloques de índices o modificando parámetros del SGBD).
- Detección de procesos que acaparen recursos: en caso de que un proceso acapare recursos (de
disco, CPU, etc) penalizando el rendimiento general del SGBD, es posible detectar esta situación
y en caso de que pueda comprometer el correcto funcionamiento del sistema incluso se puede
finalizar ese proceso.
- Optimizar consultas: otra de las posibilidades que ofrece el monitor del SGBD es comprobar el
consumo de recursos producido al lanzar una consulta, por lo que de cara a la optimización de
consultas es muy útil para comprobar el impacto de una reescritura de la consulta, un cambio en
el optimizador, el impacto de la creación de un índice, etc.
- Auditoría: la auditoría de un SGBD permite registrar todas las operaciones que se lleven a cabo so-
bre un campo concreto de la base de datos, indicando el autor, la fecha, la operación realizada,
etc. El administrador únicamente tendría que indicar qué campo es susceptible de ser auditado y
el SGBD se encargaría de todo el procesamiento.

4.2. GESTIÓN DE ESPACIO

La gestión del almacenamiento físico de los datos tiene como objetivo disminuir los tiempos de
respuesta de la BD, minimizar el espacio de almacenamiento, evitar reorganizaciones (habitualmente
muy costosas) y, en definitiva, optimizar los recursos del sistema.
Existen varias tareas relativas a la gestión y administración del espacio ocupado por la base de
datos que debe llevar a cabo el DBA:

Prohibida la reproducción total o parcial sin permiso escrito del editor Página 7 Tel. 963 768 542 - 960 624 309 - 610 900 111
 1. Distribución de datos: la correcta distribución de los datos entre los ficheros que conforman la
base de datos puede incrementar considerablemente el rendimiento. Hay varias directrices que
conviene tener en cuenta para optimizar el uso de los recursos y el paralelismo:
o Dividir las tablas grandes en varios ficheros, tantos como CPUs tenga el servidor (para optimi-
zar el paralelismo), y de un tamaño similar entre ellos (para evitar que unos se llenen antes
que otros).
o Separar los ficheros de datos, de índices y temporales (de forma que mientras se escanea el
índice se pueden ir buscando los datos en la tabla y almacenándolos en el temporal).
o En tablas particionadas, separar las particiones en diferentes ficheros, de forma que puedan
ser accedidas en paralelo cuando se consultan varias particiones
2. Gestión de almacenamiento: otra de las decisiones importantes a tomar con respecto a cómo se
realizará el almacenamiento de la BD será la posibilidad de implementar algún sistema de control
de redundancia y tolerancia a fallos (sistemas RAID). Estos sistemas se basan en la replicación de
la información en varios discos de forma que si se produce algún problema en uno de los discos
el sistema podría continuar funcionando sin problema. Existen varios niveles de RAID en base al
número de réplicas utilizadas y al modo en que se distribuye la información a través de los discos.
Estas técnicas son muy apropiadas para asegurar la disponibilidad de la información, pero su cos-
te es muy elevado, ya que implican multiplicar el espacio en disco necesario, que suele ser caro,
por lo que es necesario buscar un equilibrio entre seguridad de los datos y coste.
3. Planificar capacidad: las bases de datos son sistemas muy dinámicos en los que se insertan datos
continuamente. Deben existir por tanto una planificación del espacio que ocupará cada base de
datos y una política de incremento y mantenimiento del mismo.
4. Gestionar histórico: generalmente en una base de datos los datos más críticos y más accedidos
son los datos más actuales, y a medida que pasa el tiempo esos datos dejan de ser tan relevan-
tes. Estos datos históricos suponen un problema, porque incrementan el tamaño de las tablas
(haciendo más lento el acceso incluso para los datos actuales) y porque el coste del disco de alto
rendimiento en una base de datos es muy alto. Para solucionar ambos problemas lo que se suele
hacer es definir una política de paso a histórico, de forma que los datos con determinada antigüe-
dad se pasan a un disco de menor rendimiento (y por tanto más barato), y así se evita también el
sobredimensionamiento innecesario de las tablas.
5. Compresión de tablas / particiones: una posibilidad que ofrecen los sistemas gestores de bases de
datos para optimizar el espacio ocupado por las tablas es comprimirlas (bien una tabla completa
o una partición de la misma). De esta manera se reduce considerablemente el tamaño de las ta-
blas e incluso se incrementa el rendimiento de las consultas, aunque penaliza las modificaciones
y borrados y dificulta el mantenimiento, ya que al comprimir una tabla o partición es necesario
reconstruir todos sus índices.

4.3. COPIAS DE SEGURIDAD

Una de los requisitos fundamentales de los SGBD es garantizar la disponibilidad de la información
y la recuperación ante fallos, por lo que casi todos ellos incorporan herramientas que permiten efectuar
copias de los contenidos de una BD. Estas copias de seguridad pueden realizarse exportando los datos
de todas las tablas o de tablas específicas (bien en forma de sentencias SQL de creación de tablas
e inserción de datos o bien en ficheros binarios con un formato específico). Uno de los problemas de
exportar la información es que normalmente cuando se exporta una tabla ésta se bloquea, por lo que
el sistema dejaría de estar disponible mientras se realiza la copia. Normalmente se suele parar la BD
antes de hacer la copia, pero esto no es posible en sistemas 24x7, por lo que en estos casos es nece-
sario implementar algún proceso de copia más complejo que permita realizar los backups en caliente,
como la copia en espejo (mirroring) o los BCVs, que permiten realizar una copia de la BD que puede
ser actualizada sencuencialmente por medio de los cuadernos de bitácora (archivos donde se van re-
gistrando de forma secuencial todas las operaciones que se lanzan contra la BD de forma que puedan
ser replicadas en una copia de la BD para llegar al mismo estado actual).

Prohibida la reproducción total o parcial sin permiso escrito del editor Página 8 Tel. 963 768 542 - 960 624 309 - 610 900 111
 4.4. DISTRIBUCIÓN DE LOS DATOS
Una de las decisiones más importantes que el diseñador de bases de datos distribuidas debe to-
mar es la distribución de los datos en el sistema. Existen distintas soluciones posibles:
- Centralizada: Es muy similar al modelo de Cliente/Servidor en el sentido que la BDD está centra-
lizada en un lugar y los usuarios están distribuidos. Este modelo solo tiene la ventaja de tener el
procesamiento distribuido ya que en sentido de disponibilidad y fiabilidad de los datos no se gana
nada.
- Replicadas: En una BD replicada cada nodo debe tener su copia completa de la base de da-
tos. Este esquema tiene un alto costo de almacenamiento de la información. Debido a que la
actualización de los datos debe ser realizada en todas las copias, también tiene un alto costo de
escritura, pero todo esto vale la pena si tenemos un sistema en el que se va a escribir pocas veces
y leer muchas, y dónde la disponibilidad y fiabilidad de los datos sea de máxima importancia.
- Particionadas: En este modelo solo habrá una copia de cada elemento, pero la información es-
taraá distribuida a través de los nodos. En cada nodo se aloja uno o más fragmentos disjuntos de
la base de datos. Como los fragmentos no se replican esto disminuye el costo de almacenamien-
to, pero también sacrifica la disponibilidad y fiabilidad de los datos. Algo que se debe tomar en
cuenta cuando se desea implementar este modelo es la granularidad de la fragmentación. La
fragmentación se puede realizar también de tres formas:
- Horizontal: Los fragmentos son subconjuntos de una tabla
- Vertical: Los fragmentos son subconjuntos de los atributos con sus valores
- Mixto: Se aplican fragmentación horizontal y vertical.
Una ventaja significativa de este esquema es que las consultas (SQL) también se fragmentan
por lo que su procesamiento es en paralelo y más eficiente, pero también se sacrifica en casos
que involucren varios fragmentos de la BDD.
Para que una fragmentación sea correcta, ésta debe ser completa, reconstruible y todos los
fragmentos deben ser disjuntos.
- Híbridas: Este esquema representa la combinación del esquema de partición y replicación. Se
particiona la relación y a la vez los fragmentos están selectivamente replicados a través del siste-
ma de BDD.

5. OPTIMIZACIÓN
Los lenguajes de consulta basados en el álgebra relacional son no procedimentales, ya que el
usuario dice el resultado que quiere obtener, pero no especifica cómo conseguirlo. Esto presenta una
gran ventaja para el usuario, pero delega en el sistema la toma de estas decisiones, lo que limita nota-
blemente la capacidad del usuario para asegurar que los datos se recuperan de forma óptima.
Existen, sin embargo, varias tareas que se pueden llevar a cabo para ayudar al sistema a tomar
las decisiones correctas.

5.1. OPTIMIZACIÓN DEL ENTORNO

Antes de centrarse en la optimización del servidor de bases de datos, es conveniente comprobar
que el entorno (sistema operativo, red, etc) donde está instalado ese servidor es el más adecuado.
1. Optimización del SO: existen comandos de sistema operativo (como prfmon de Windows o systat
de Linux) que contienen numerosas métricas (accesos a disco, uso de CPU, etc) que permiten
monitorizar el rendimiento del sistema operativo, y también de las aplicaciones instaladas, por lo
que pueden utilizarse para monitorizar el rendimiento del SGBD.
2. Optimización de red: en un servidor con varios procesadores y varias tarjetas de red, es posible de-
finir afinidades entre una tarjeta de red y un procesador, de forma que las peticiones que lleguen
por cada tarjeta se asignarían a una CPU distinta, y se minimizarían los bloqueos entre CPUs por
compartición de recursos.

Prohibida la reproducción total o parcial sin permiso escrito del editor Página 9 Tel. 963 768 542 - 960 624 309 - 610 900 111
 5.2. OPTIMIZACIÓN DE OBJETOS DE BD
1. Estructura interna de las tablas: internamente, las tablas se organizan en bloques o páginas. Cuan-
do se inserta una fila en una tabla, se busca un bloque con espacio libre y se inserta ahí la informa-
ción. Si no quedan bloques libres, se crea uno nuevo. Existen tres tipos de problemas relacionados
con esta estructuración interna de las tablas:
o Migrated rows: se producen cuando hacemos una modificación en los datos de una fila que
provoca que no quepa en el bloque donde estaba almacenada, por lo que se divide el
contenido de la fila y en el bloque actual se guarda un puntero al bloque donde se guar-
dará el resto de la fila. Puntualmente se puede solucionar compactando la tabla o movién-
dola, pero para solucionarlo definitivamente es necesario revisar el tamaño del bloque y el
espacio libre reservado en cada bloque.
o Chained rows: se producen cuando es habitual que una fila ocupe más de un bloque, por
lo que para consultar una fila completa de una tabla son necesarios dos accesos. Se solu-
ciona modificando el tamaño de bloque de la tabla.
o Fragmentación: se produce al eliminar registros de una tabla de forma masiva, lo que provo-
ca que queden “huecos” en los bloques que están desperdiciando espacio. Se soluciona
compactando la tabla o moviéndola.
2. Fragmentación de índices: existen dos tipos de fragmentación de índices:
o Fragmentación externa: se produce en índices con estructura de árbol cuando las ramas
del árbol quedan desniveladas debido a la realización de modificaciones sobre las colum-
nas del índice y borrados de filas.
o Fragmentación interna se produce cuando en los bloques del índice queda espacio infrau-
tilizado o están mal organizados. La fragmentación se puede solucionar reconstruyendo el
índice, reorganizándolo (solo para la interna) o compactándolo (solo para la externa).
3. Tablas con estructura de índice: en tablas con una o dos columnas que no vayan a tener una
gran variación en sus datos, es posible estructurar la tabla como si fuese un índice, de forma que
se minimiza el tiempo de acceso a los datos y se evitar tener que crear índices adicionales.
4. Particionamiento: el particionamiento de una tabla o índice consiste en dividir ésta en varios seg-
mentos (llamados particiones), de forma que se evita procesar toda la tabla cuando se accede a
datos de un segmento concreto, y permite optimizar el acceso en paralelo a los datos de distintas
particiones.
5. Paralelización de las tablas: es posible paralelizar el acceso a las tablas y también parametrizar el
grado de paralelismo deseado para cada tabla.

5.3. OPTIMIZACIÓN DE CONSULTAS

Los SGBDs proporcionan varias herramientas orientadas a optimizar el rendimiento de las consultas:
1. Diseño de las tablas y elección de tipos: el diseño adecuado de tablas y vistas puede afectar
sustancialmente a las prestaciones. La correcta elección de los tipos de datos redundará en una
menor ocupación de espacio y evitará conversiones de tipos de datos innecesarias, lo cual tam-
bién incrementará el rendimiento.
2. Campos calculados: los campos calculados obligan al sistema a realizar numerosas operaciones
durante su consulta, lo que puede afectar al rendimiento del sistema. Una forma de evitarlo sería
incorporar estos campos a la base de datos, calculándolos en el momento que se insertan, de
forma que se evitarían todas estas operaciones al realizar las consultas.
3. Desnormalización: hay ocasiones en que cuando se consultan los datos de una tabla lo habitual
es hacerlo en combinación con los datos de otra tabla que los complementan. Para evitar tener
que recuperar los datos siempre por medio de un JOIN, una opción es desnormalizar, que con-
siste en romper la 3FN (o FNBC) al insertar atributos de una tabla en otra tabla o crear una tabla
como el resultado de la unión de otras tablas. En ambos casos esto implica incorporar información

Prohibida la reproducción total o parcial sin permiso escrito del editor Página 10 Tel. 963 768 542 - 960 624 309 - 610 900 111
 redundante,aparte de hacer que la implementación sea más compleja y reducir la flexibilidad,
por lo que estas redundancias deben estar controladas.
4. Monitor de consultas: el monitor de consultas permite realizar una traza de todas las operaciones
realizadas sobre el SGBDs para localizar las operaciones más frecuentes y determinar qué consul-
tas se realizan de forma más habitual sobre la BD, que serán las consultas sobre las que se deberá
centrar la tarea de optimización.
5. Planes de ejecución: el primer paso para optimizar una consulta es revisar el plan de ejecución
de la misma para comprobar cómo se está accediendo a las tablas (en qué orden, cómo es el
acceso, qué índices se usan...). Para mejorar los resultados de un plan de ejecución existen varias
opciones:
o Actualizar las estadísticas: los planes de ejecución se basan en las estadísticas de las tablas,
por lo que si éstas no se actualizan frecuentemente es posible que los planes utilizados sean
incorrectos.
o Reescribir la consulta: hay varias modificaciones que se pueden realizar sobre las consultas
para que sus resultados sean mejores (sustituir un OR por un UNION, un IN por un EXISTS, ...).
Estas transformaciones tienen como fin simplificar y reducir el tamaño de las tablas que inter-
vienen en la consulta antes de realizar las combinaciones (JOIN), de forma que se obtenga
el mismo resultado con menos operaciones de lectura/escritura de tuplas.
o Crear, modificar o eliminar índices
o Modificar el agrupamiento físico (distribución en ficheros) y lógico (particionado) de los re-
gistros.
o Modificar los parámetros del optimizador (priorizar la E/S en lugar del coste de CPU, por
ejemplo)
6. Índices: existen dos decisiones fundamentales a la hora de crear un índice: sobre qué columnas
crear un índice y qué tipo de índice crear.
- Acerca de la primera cuestión hay varias recomendaciones genéricas: crear índices en claves
primarias y foráneas, no crear índices en tablas con muy pocos datos (si la tabla cabe entera
en memoria es más rápido un full scan que un acceso por índice), tener cuidado con la crea-
ción de índices en columnas con muchos nulos, evitar crear índices sobre muchas columnas,
crear índices en las columnas que habitualmente aparezcan en el where o incluso en el select
de las consultas, etc.
- Además de estas recomendaciones, que se deberán tener en cuenta cuando se creen inicial-
mente los índices en las tablas, hay ocasiones en que nos puede interesar crear un índice para
optimizar el rendimiento de la BD. En este caso, la decisión dependerá fundamentalmente de
las consultas que se realicen sobre la BD. Por medio de las diferentes herramientas de los SGBDs
podemos saber qué consultas son las más ejecutadas, revisar los planes de ejecución para
comprobar cómo se realiza el acceso a cada tabla en estas consultas, comprobar si es están
usando los índices correctamente, revisar si se producen bloqueos en los accesos a las tablas,
etc. En base a esta información podemos detectar si hay tablas de tamaño medio o grande a
las que siempre se acceda de forma completa, penalizando mucho los planes de consulta o
provocando problemas de bloqueos. En estos casos puede ser conveniente crear algún índice
en esas tablas para agilizar los accesos a estas tablas.
- Respecto al tipo de índices a crear, dependerá especialmente del SGBDs utilizado, ya que
cada gestor implementa sus propios tipos de índices. La filosofía detrás de cada tipo de índice
particular, sin embargo, suele ser común a todos los SGBDs:
o Implementación del índice: existen dos tipos de índices por su organización: agrupados o
no agrupados. En los índices agrupados, los campos sobre los que se define el índice deter-
minan la organización de la tabla, ya que las filas de la tabla se guardarán ordenadas en
base al valor de las columnas indexadas. No ocupan espacio adicional, pero solo se pue-
de definir un índice de este tipo por tabla. Los índices no agrupados se construyen como

Prohibida la reproducción total o parcial sin permiso escrito del editor Página 11 Tel. 963 768 542 - 960 624 309 - 610 900 111
 una estructura aparte de la tabla con punteros a los datos de la tabla. Requieren espacio
adicional pero se pueden definir tantos índices de este tipo por tabla como se quiera.
- Se recomienda utilizar índices no agrupados cuando vayan a ser usados en consultas que ac-
cedan solo a parte de una tabla, consultas con JOIN o GROUP BY, consultas que devuelven
pocos datos, consultas que usen coincidencias exactas en el WHERE o consultas sobre colum-
nas que no tengan muchos valores únicos. Los índices agrupados son más apropiados en co-
lumnas que se actualizan con frecuencia, tablas con claves amplias o consultas con grandes
conjuntos de resultados.
o Organización del índice: la estructura habitual de los índices es en forma de árbol (índices
B-tree), pero existen SGBDs que permiten otros tipos de índices, como los índices bitmap
que se implementan como vectores que contienen las columnas que toman un determina-
do valor o los índices hash. Los índices bitmaps son más adecuados para entornos de Data
Warehouse ya que las modificaciones que se realizan sobre los datos de la BD son menos
habituales, y los índices hash son muy útiles para consultas en las que se busque siempre un
valor concreto en una columna.
- Tan importante como la creación de los índices es la eliminación de índices innecesarios, ya
que los índices que no se utilizan no solo ocupan espacio sino que también consumen recursos
para su mantenimiento.

5.4. HERRAMIENTAS PARTICULARES DE ALGUNOS SGBDS

Algunos SGBDs proveen de herramientas que permite optimizar determinadas tareas habituales
en base de datos. Algunas de las más relevantes son las siguientes:
1. Inserciones masivas (SQL Server, Oracle): las inserciones masivas permiten insertar datos en blo-
ques en lugar de hacerlo fila a fila, con lo que se incrementa notablemente la velocidad.
2. Insert append (Oracle): al insertar datos en una tabla se van completando en primer lugar los
espacios libres que queden en los bloques de la tabla. Al hacer un append los datos se insertan
siempre por el final de la tabla, por lo que se evita recorrer la tabla y la inserción es más rápida.
Tiene el problema de que si se hace habitualmente puede dejar la tabla muy fragmentada.
3. Intercambio de particiones (SQL Server, Oracle, Mysql): las operaciones de inserción son mucho
más rápidas que las de modificación, por lo que en lugar de modificar los datos de una partición
de una tabla, se pueden insertar los datos en una tabla temporal y luego intercambiar la tabla
temporal por la partición (que es inmediato), con lo que además de ganar en velocidad se ac-
tualizaría la información de la tabla sin afectar a su rendimiento.
4. Vistas materializadas o indexadas (SQL Server, Oracle, PostgreSQL): se define una vista sobre una
tabla y se crea un índice sobre la vista. Al lanzar una consulta sobre la tabla que se pueda resolver
con el índice, se utilizaría la vista en lugar de la tabla. Son apropiadas para consultas con muchas
combinaciones en entornos Datawarehouse.
5. Merge (Oracle, SQL Server, Mysql, informix): la operación merge combina la inserción y modifica-
ción en una sola instrucción. Al hacer el merge de una fila se comprueba si la clave de la fila existe
en la tabla: si no existe inserta esa fila, y si existe actualiza todas las columnas de la fila existente por
los de la fila nueva. Es muy apropiada para procesos ETL en entornos datawarehouse.
6. Índices con filtro (SQL Server): son índices que aplican solamente sobre determinados valores de
una columna. Por ejemplo, en una columna con valores “SI/NO/No aplica”, se podría crear el índi-
ce solamente para las filas con valores “SI/NO”. En otros SGBD se puede hacer algo similar usando
índices con funciones.

Prohibida la reproducción total o parcial sin permiso escrito del editor Página 12 Tel. 963 768 542 - 960 624 309 - 610 900 111