GESTION DE BASE DE DATOS

ADMINISTRACIÓN Y
GESTIÓN DE BASES DE
DATOS

Definición y tareas DBA,SA, DA

 Administrador de Base de Datos
• El administrador de bases de datos utiliza Los DBA son expertos en la materia para los
programas informáticos para almacenar y sistemas de administración de bases de
organizar datos de la empresa, como datos, incluida:
información financiera o información pedidos
de clientes. • la implementación y configuración de
DBMS;
• Se aseguran de que los datos están • diseño de bases de datos;
disponibles para la empresa, pero no son
accesibles a personas no autorizadas. • codificación SQL;
• extracción, transformación y carga de
• El DBA es responsable de comprender y datos (ETL);
administrar el entorno general de la base de • gestión de datos de prueba;
datos. Al desarrollar e implementar un plan
estratégico a seguir al implementar bases de • resolución del problema;
datos dentro de su organización • integridad de los datos;
• seguridad de la base de datos;
• Sin la supervisión del DBA, es inevitable que • mejoramiento;
se produzcan interrupciones en las
aplicaciones y el sistema, tiempo de • respaldo
inactividad y ralentizaciones. • recuperación de bases de datos.
 Administrador de Base de Datos
Funciones de un Administrador de Base de Datos (DBA)
• Asegurar el buen funcionamiento de las BBDD
– El dba suele elaborar índices de búsqueda, mantener las bases de datos actualizadas y
realizar todas las mejoras a la misma para que esté al día.

• Retención de información de la BBDD

– una función del dba es conseguir que la información esté lo más protegida posible,
haciendo copias de seguridad periódicas.
• Evitar pérdida de datos
– Además de actuar sobre la BBDD debe hacerlo sobre otros aspectos. Debe asegurarse
que hay un sistema antivirus y de protección adecuado para los sistemas informáticos, lo
que ayudará a que no se destruyan los datos como consecuencia de un ataque externo.
• Solucionar incidencias y pérdidas de datos
– Son los encargados de recuperar toda esta información lo antes posible acudiendo a la
copia de seguridad más reciente, una vez solucionado este problema, debe investigar cuál
ha sido la causa del fallo que ha ocasionado el fallo de sistema para solucionarlo o
controlarlo, para evitar futuras incidencias.
 Administrador de Base de Datos
Algunas responsabilidades de un administrador de base de datos incluyen:

• Identificar las necesidades de los usuarios para crear y administrar bases de datos.
• Asegurar que la base de datos funcione de manera eficiente y sin errores.
• Realizar y probar modificaciones a la estructura de la base de datos cuando sea necesario
• Mantener la base de datos y actualizar los permisos
• Fusionar bases de datos antiguas en nuevas
• Hacer copias de seguridad y restaurar datos para evitar la pérdida de datos
• Recuperar en caso de fallos: Una base de datos puede tener problemas en un momento
dado. Un error que haga que los datos no estén accesible o que inclusos e pierdan, un
ataque cibernético que comprometa la información, una mala instalación.
 Administrador de Base de Datos
Tipos de administradores de bases de datos
• DBA del sistema. Se centra en cuestiones técnicas, de cómo se instala, configura y modifica la
base de datos. Las tareas se centran en la instalación física y el rendimiento del software DBMS y
pueden incluir:
– Instalar nuevas versiones y aplicar correcciones;
– Configuración y ajuste de los parámetros del sistema;
– Ajustar el sistema operativo, la red y los procesadores de transacciones para que funcionen
con el DBMS;
– Asegurar que el almacenamiento y la memoria adecuados estén disponibles para el DBMS.

• Arquitecto de bases de datos. Trabaja en el diseño e implementación de nuevas bases de datos

y rara vez participa en el mantenimiento y ajuste de bases de datos y aplicaciones establecidas.
Las tareas incluyen:
– Modelado de datos lógicos;
– Traducir modelos de datos lógicos en un diseño de base de datos física;
– Analizar los requisitos de acceso a los datos para garantizar un diseño óptimo de la base de
datos y un acceso SQL eficiente; y
– Creación de estrategias de respaldo y recuperación para nuevas bases de datos.
 Administrador del Sistema

• Es el profesional responsable de configurar,

mantener, monitorizar y asegurar el perfecto
funcionamiento del sistema informático del
sitio en el que trabaja.

• Los administradores de sistemas—también

conocidos como sysadmins— aseguran de
que los sistemas informáticos de una
organización funcionen y satisfagan las
necesidades de la misma
 Administrador del Sistema
Rol del administrador de sistemas
• Mantiene la red de ordenadores y dispositivos conectados bajo su control, verificando que
todo funcione de manera correcta.
• Es responsable de vigilar la seguridad de la red y de gestionar el tráfico.
• Interactúa con los usuarios finales siempre que sea necesario y dependiendo del tipo de
empresa o de institución.
• Gestiona y administra las cuentas de los usuarios, incluyendo los permisos, derechos de
acceso y ubicaciones de almacenamiento.
• Da apoyo técnico y brinda soluciones a cualquier problema de hardware y software
relacionado con el servidor y los dispositivos de almacenamiento.
• Analiza y estudia de forma pormenorizada los diferentes productos que salen al mercado,
protocolos de servicio y normas para la adquisición de software de sistemas.
• Se asegura de que la totalidad del sistema informático funcione de manera correcta y con el
objetivo de que el trabajo de la empresa se pueda desarrollar de forma dinámica y eficaz.
 Administrador del Sistema

Tipos de administrador de sistemas

• Responsable del departamento de Informática o el de IT
• Administrador de redes.
• Técnico en mantenimiento de sistemas informáticos en entornos monousuario y
multiusuario.
• Técnico gestor de bases de datos.
• Responsable del servicio técnico y encargado de instalar equipos informáticos y de
realizar el respectivo mantenimiento.
• Técnico en desarrollo de aplicaciones web o de aplicaciones multiplataforma.
• Procesador de datos.
 Administrador del Sistema
Funciones y responsabilidades
• Instalar y configurar software y hardware para el correcto desempeño de un entorno de trabajo
• Administrar los servidores de red y herramientas tecnológicas, configurando las cuentas de todos los
usuarios e integrantes de un equipo de trabajo.
• Supervisar el rendimiento de los sistemas que administra y ocuparse del mantenimiento
correspondiente.
• Garantizar la seguridad a través de la gestión de controles de acceso, copias de seguridad,
cortafuegos y antispyware.
• Actualizar los sistemas con nuevos lanzamientos y modelos.
• Desarrollar conocimientos para dar formación e información al personal de la empresa en todo lo
referente a las nuevas tecnologías.
• Establecer procedimientos y políticas de almacenamiento, conservación, recuperación y borrado.
• Estudiar las necesidades de la empresa y decidir qué dispositivos y equipos informáticos comprará y
qué tipo de proyecto interno desarrollará.
• Gestionar las cuentas de usuarios a través del restablecimiento de contraseñas, control de
seguridad, virus, etc.
• Vigilar la seguridad del sistema informático, impidiendo la injerencia de agentes externos que
quieran acceder a la intranet y dañar la información que contiene.
• Planificar, coordinar e implementar medidas de seguridad en el sistema de conexión de la empresa.
 Administrador del Sistema
Importancia sobre la cuenta de administrador
La cuenta de root tiene acceso pleno (sin restricciones) al sistema, por lo que él / ella
puede hacer cualquier cosa con el mismo. Por ejemplo, root puede eliminar los archivos
críticos del sistema. Además, no hay ninguna manera que se pueda recuperar archivos,
excepto con las copias guardadas en cintas.

Muchas tareas para la administración del sistema se pueden automatizar usando scripts.
Por ejemplo:
• Crear nuevos usuarios
• La restauración de contraseñas de usuario
• Bloqueo / desbloqueo de cuentas de usuario
• Monitor de la seguridad del servidor
• Monitor de servicios especiales, etc
 Administrador del Sistema

Formación y especializaciones de las funciones de un administrador

de sistemas

• Ingeniero de Sistemas Certificado por Microsoft (MCSE).

• Administrador de Sistemas Certificado por Microsoft (MCSA).
• Administrador del sistema Linux de Oracle (Oracle).
• Ingeniero certificado por Red Hat (RHCE).
• Servidor CompTIA+.
• VMware Certified Professional 6- Virtualización del centro de datos.
• Administrador de Redes Certificado por Cisco (CCNA).
 Administrador de Datos
Administración de datos
Los datos se consideran un recurso valioso de las organizaciones modernas. Con acceso a
grandes volúmenes y diferentes tipos de datos, las organizaciones invierten mucho en la
infraestructura de administración y almacenamiento de datos.. A continuación algunos
beneficios
• Aumento de los ingresos y las ganancias El análisis de datos ofrece una visión más
profunda de todos los aspectos de una empresa. Puede utilizar estos conocimientos para
optimizar las operaciones comerciales y reducir los costos; también puede predecir el
futuro impacto de las decisiones.
• Reducción de la incoherencia de los datos Un silo de datos es una colección de datos
sin procesar dentro de una organización a la que solo puede acceder un departamento o
grupo
• Cumplir con las regulaciones Las leyes dan a los consumidores control sobre sus
datos. Las personas pueden solicitar un recurso legal si perciben que las organizaciones:
– Capturan datos sin consentimiento
– Ejercen un control deficiente sobre la ubicación y el uso de los datos
– Almacenan datos a pesar de que se les solicitara su eliminación
– Las organizaciones requieren un sistema de administración de datos que sea justo,
transparente y confidencial.
 Administrador de Datos
Áreas de enfoque de la administración de datos
Distribución y coherencia de los datos
• En la mayoría de las organizaciones, los datos deben distribuirse a los distintos puntos
de conexión en los que se necesitan los datos. Estos incluyen sistemas operativos,
lagos de datos y almacenamiento de datos. La distribución de datos es necesaria
debido a las latencias de la red..
• La distribución de datos también es necesaria para la consolidación de datos. El
almacenamiento de datos se utiliza para el análisis y la toma de decisiones, mientras
que los lagos de datos son un centro consolidado desde el que se pueden extraer datos
para diversos casos de uso.
• Mecanismos de replicación de datos e impacto en la coherencia. Estos tienen un
impacto potencial en la coherencia de datos, y esto es algo importante que hay que
tener en cuenta en la administración de datos..
• Diferencias entre la reproducción en streaming y las actualizaciones por lotes Las
secuencias de datos cambian en cascada los datos a medida que se producen. Este es
el enfoque preferido si se requiere acceso a datos casi en tiempo real. Los datos se
extraen, transforman y entregan a su destino tan pronto como se modifican. Las
actualizaciones por lotes son más apropiadas cuando los datos deben procesarse en
lotes antes de la entrega.. Las actualizaciones por lotes a través de un proceso de
extracción, transformación y carga (ETL o ELT)
 Administrador de Datos
Perfil de trabajo del administrador de datos
• Es un administrador especializado de sistemas informáticos que dirige o realiza todas
las tareas relacionadas para los datos seguros y mantiene un entorno de base de
datos próspero.

• El trabajo principal de un DBA es preservar la integridad de los datos.

• El DBA garantizará que los datos estén a salvo del acceso no deseado mientras aún
sea accesible para los usuarios.

• Además de un título en informática, experiencia práctica de campo y certificaciones

adicionales de TI relacionadas, un administrador de la base de datos frecuentemente
tendrá conocimiento práctico y experiencia con una amplia gama de soluciones de
administración de bases de datos como software basado en Oracle, SAP y SQL.
 Administrador de Datos
Responsabilidades del administrador de datos ▪ Realice un seguimiento de los detalles del sistema de
• Configuración de la base de datos, actualizaciones y bases de datos
parches ▪ Crear e implementar sistemas, políticas y
• Configurar y configurar los componentes de la red procedimientos de recuperación de desastres
redundantes
• Garantizar la accesibilidad de la base de datos, la ▪ Realice un seguimiento, optimice y asigne el
consistencia e integridad almacenamiento de datos físicos para los sistemas
• Solucion de problemas de obstaculos en el rendimiento de bases de datos
• Proporcionar informes sobre una variedad de variables ▪ Planifique y ejecute migraciones de datos
como disponibilidad, uso y rendimiento ▪ Crear, implementar y mantener los procedimientos de
• actividades que incluyen pruebas de rendimiento y gestión y prueba de cambios
evaluación comparativa ▪ Realizar auditorías de transacciones y seguridad en
• Colaborar con el personal de desarrollo para crear bases de datos
arquitecturas, estándares de codificación y prácticas de ▪ Definir niveles de control de acceso a la base de
garantía de calidad datos para usuarios finales
▪ Establezca el grabado de la base de datos y el
• Desarrolle modelos para nuevas bases de datos o grabado de datos
realice ajustes a los actuales ▪ Planifique y supervise la adhesión a las mejores
• Dirección y solucione el acceso a la base de datos y prácticas, reglas y legislación establecidas
problemas de rendimiento ▪ Contribuir como miembro del equipo al logro de los
objetivos del equipo
Administrador de Datos
Teorema de CAP
Por Eric Brewer en el año 2000, prueba que
podemos crear una base de datos distribuida
que elija dos de las siguientes tres
características:
• Consistencia: La propiedad con la que
cualquier lectura recibe como respuesta
siempre la reciente, nunca un dato
obsoleto.
• Disponibilidad (Available): Cualquier
petición recibe una respuesta no errónea,
en un tiempo razonable aunque, esta no
sea la escritura mas reciente.
• Tolerancia a Particiones: Es la propiedad
por al que el sistema sigue funcionando,
incluso si existen fallos de comunicación o
caídas parciales
Arquitectura de los sistemas gestores de bases de datos

Estructura física y lógica

Definimos un Sistema Gestor de

Bases de Datos o SGBD, también
llamado DBMS(Data Base
Management System) como una
colección de datos relacionados
entre sí, estructurados y organizados,
y un conjunto de programas que
acceden y gestionan esos datos.
 Arquitectura de los sistemas gestores de bases de datos

• Una arquitectura, es una

herramienta sencilla y
potente ideada para
abstraer y entender los
rasgos fundamentales
de los sistemas más
complejos.
 Arquitectura de los sistemas gestores de bases de datos
El nivel lógico
• El conjunto de tablas es el núcleo fundamental
– es el conjunto de datos disponibles para el usuario,
– es el conjunto más importante y voluminoso de datos almacenados en los soportes físicos
.

• El usuario puede acceder directamente a las tablas o bien puede acceder a estas de manera
indirecta por medio de las vistas; por este motivo, tablas y vistas están agrupadas como el
conjunto de componentes de datos.
• Una base de datos además tiene, restricciones, que definen ciertas reglas que tienen que cumplir
los datos, o los disparadores, los cuales indican acciones que se tienen que ejecutar si se cumplen
ciertas condiciones.
• Denominamos todos estos otros componentes como conjunto de componentes de control, puesto
que en cierto modo permiten controlar los datos dinámicamente.
• Se puede considerar que los índices pertenecen al conjunto de componentes de control, aunque
con una matiz ligeramente diferente, dado que su función fundamental es de rendimiento
 Arquitectura de los sistemas gestores de bases de datos
El nivel físico
• Los datos se almacenan en soportes no volátiles, normalmente en discos magnéticos.
• Estos soportes son controlados por el sistema operativo de la máquina, que es el que
realmente efectúa la lectura y la escritura física de los datos.
• Los SGBD no reimplementan estas funciones, sino que utilizan las rutinas especializadas del
sistema operativo para leer y escribir los datos y también para la gestión física de los
dispositivos.
• Los sistemas operativos gestionan los datos en los discos magnéticos a partir de unas
unidades globales denominadas ficheros. Normalmente, el sistema operativo no reserva una
gran cantidad de espacio de disco para cada fichero, sino que lo va adquiriendo a medida
que lo necesita.
• La unidad de adquisición es la denominada extensión, otro de los componentes de este nivel.

• La extensión es un múltiplo entero del componente físico más pequeño, que es la página.
 Arquitectura de los sistemas gestores de bases de datos
La página
• Los datos se almacenan en dispositivos externos pero para efectuar cualquier operación tienen que
estar presentes en la memoria principal del ordenador.
• Debe haber, un transporte de datos entre la memoria externa (un disco) y la memoria interna (o
memoria principal). Este transporte se hace empleando una unidad discreta de transporte de datos
que en los SO se denomina bloque y en los SGBD recibe el nombre de página.
• Paralelamente al hecho de ser la unidad de entrada/salida, la página también es la unidad de
organización de los datos almacenados. El espacio del disco siempre se asigna a un número
múltiple de páginas, y cada página puede estar direccionada de manera individual.
• La página es la unidad mínima de acceso y transporte del sistema de entrada/salida de un SGBD, lo
cual la hace ideal para ser a su vez la unidad de organización más importante de los datos
almacenados.
• Nunca se accede a menos de una página, sí que se puede acceder al mismo tiempo a un número
entero de páginas consecutivas.
• Que la página sea la unidad de organización del nivel físico no significa que no tenga su propia
estructura interna. De hecho, en una página hay diferentes componentes.
• A los componentes que hay en el interior de la página sólo pueden acceder las rutinas del SGBD,
una vez la página ya está en la memoria principal del ordenador. En cambio, a la página como
unidad accede (para leer y escribir) el subsistema de E/S del SO de la máquina
 Arquitectura de los sistemas gestores de bases de datos
Estructura de una página
• La página es de longitud fija. Hay SGBD que permiten elegir el tamaño de la página entre un
pequeño repertorio. Otros solo tienen un tamaño único. La estructura de la página, que se muestra
en la figura, es muy similar en todos los SGBD.
Arquitectura de los sistemas gestores de bases de datos
Una página consta de los siguientes elementos:

• a) Una cabecera, con información de control de la página.

• b) Un cierto número de registros, llamados filas porque corresponden a las filas de las
tablas del nivel lógico.

• c) Un espacio libre

• d) Un vector de direcciones de fila (VDF), que tiene tantos elementos como filas hay
en la página. Cada elemento del VDF contiene la dirección de una fila dentro de la
página (apunta a la fila).
 Arquitectura de los sistemas gestores de bases de datos
Estructura de una fila
• Se trata de una secuencia de campos (nivel físico), cada uno de los cuales registra la
información del campo de la fila correspondiente (nivel lógico).
• Es posible que el SGBD necesite guardar alguna información de control en lo que respecta a
la fila y, por este motivo, antes de la secuencia de campos encontramos una cabecera de fila.

Normalmente, las filas de una tabla son de

longitud inferior al tamaño de las páginas y
por este motivo caben en las mismas
perfectamente.
Si la longitud de la fila es superior a la de
la página, los SGBD parten la fila en
trozos. Cada trozo se almacena en una
página diferente y apunta al trozo siguiente
 Arquitectura de los sistemas gestores de bases de datos
Estructura de un campo
• Una página está formada por filas y que una fila está formada por campos.
• Un campo de una fila de una tabla (nivel lógico) se almacena como uno de los campos de la fila dentro
de la página (nivel físico).
• Un campo normalmente está formado por una cabecera y un contenido
• La cabecera del campo permite guardar ciertas características del campo, por ejemplo:
– a) La indicación de si el contenido en cada momento es nulo o no lo es. Esta indicación es
necesaria si el campo está definido de manera que admite el valor nulo.
– b) La longitud del campo, también en un momento concreto. Esta información es necesaria cuando
el campo se ha definido con un tipo de dato de longitud variable, como por ejemplo el tipo
CHARACTER VARYING.
• El contenido del campo es el resultado de almacenar el valor del campo según las normas de
codificación de cada SGBD en cada arquitectura de máquina concreta.

▪ Tipo SMALLINT: número binario entero de 16 bits.

▪ Tipo INTEGER: número binario entero de 32 bits.
▪ Tipo FLOAT: número en coma flotante de 64 bits.
▪ CHARACTER VARYING es el nombre del estándar SQL:1999
 Arquitectura de los sistemas gestores de bases de datos
Gestión de la página
1) Formateo de una página. Cuando el SGBD necesita más espacio dentro de un fichero para
almacenar datos, adquiere una nueva extensión. Las páginas de esta extensión se formatean,
es decir, se inicializan de una manera adecuada para que posteriormente las utilice el SGBD.
La inicialización consiste fundamentalmente en escribir la cabecera y dejar el resto de la
página como espacio libre
2) Carga inicial de filas. Si la extensión inicializada se utiliza para una carga inicial o masiva
de filas de tablas, el SGBD empieza a usar el espacio libre de la página de la manera siguiente:
– La primera fila se coloca detrás de la cabecera, se crea un elemento del VDF que apunta
a esta fila y se coloca al final de todo de la página.
– La segunda fila ocupa el lugar inmediatamente detrás de la primera, y su elemento del
VDF ocupa el lugar justo delante del elemento de la fila anterior.
• El proceso se repite sucesivamente, como ya habéis visto en la explicación de la estructura
de una página.
• De este modo el espacio libre va disminuyendo, pero siempre ocupa un lugar en torno al
centro de la página
 Arquitectura de los sistemas gestores de bases de datos
3) Alta posterior de una nueva fila. Para añadir una fila a una tabla de la BD, el SGBD en el nivel físico
localiza primero la página donde tiene que añadir la fila. Esta página se denomina página candidata. Una
vez el SGBD sabe cuál es la página candidata, utiliza el espacio libre disponible en la página para colocar
la fila y dejarla apuntada por un nuevo elemento del VDF. La fila y el elemento del VDF se colocan según
el criterio explicado anteriormente.
• Puede llegar un momento en el que ya no quede espacio libre suficiente en la página candidata para
colocar la fila. Entonces, la fila se coloca en otra página según algoritmos propios de cada SGBD.
4) Baja de una fila. La baja de una fila consiste en liberar el espacio ocupado por la fila y el elemento del
VDF. En este momento, o más adelante, el SGBD reorganiza la página para que el espacio liberado por
la baja se una al resto del espacio libre de la página. Habrá un desplazamiento de filas y de elementos
del VDF para que la estructura de la página continúe siendo tal y como hemos descrito anteriormente.
5) Cambio de longitud de una fila. Un cambio de longitud de una fila puede afectar de tres maneras:
a) Si el cambio tiene como resultado una disminución de la longitud de la fila, el espacio liberado se
unirá al espacio libre.
b) Si, por el contrario, da lugar a un aumento de la longitud y el espacio extra requerido está
disponible en forma de espacio libre dentro de la página, la fila quedará en su lugar ocupando más
espacio y las filas que la siguen se desplazarán hacia la derecha
c) En caso de que la necesidad de espacio no se pueda servir a partir del espacio libre de la página,
esta fila se traslada hacia otra página que disponga de espacio suficiente. En la página original y en
la posición original se crea una dirección que apunta hacia la nueva posición de la fila
 Configuración y tuneo del DBMS
• Aplicación web (web) ▪ Aplicación de escritorio
– Vinculado a la CPU – No es una base de datos dedicada
– DB mucho más pequeña que la RAM – Una estación de trabajo general,
quizás para un desarrollador
– 90% o más consultas son simples
▪ Aplicación mixta
• Procesamiento de transacciones en línea (oltp) – Características mixtas de DW y
– Vinculado a la CPU o a las E/S OLTP
– DB un poco más grande que la RAM a 1 TB – Una amplia mezcla de consultas
– 20-40% consultas de escritura de datos pequeños
– Algunas transacciones largas y consultas de
lectura complejas
• Almacén de datos (dw)
– Vinculado a E/S o RAM
– Grandes cargas masivas de datos
– Consultas de informes grandes y complejas
– También llamado "Business Intelligence"
 Configuración y tuneo del DBMS
• max_connections
– Numero maximo de clientes conectados a la vez a nuestras bases de datos.
– Deberiamos de incrementar este valor en proporcion al numero de clientes concurrentes
en nuestro cluster PostgreSQL.
– Un buen valor para empezar es el 100:
• shared_buffers
– Define el tamaño del buffer de memoria utilizado por PostgreSQL.
– No por aumentar este valor mucho tendremos mejor respuesta.
– En un servidor dedicado podemos empezar con un 25% del total de nuestra memoria.
Nunca mas de 1/3 (33%) del total
– Lo ideal o recomendable es usar un 10% del valor total de memoria ram del sistema
• effective_cache_size
– Parametro usado por el 'query planner' de nuestro motor de bases de datos para
optimizar la lectura de datos.
– En un servidor dedicado podemos empezar con un 50% del total de nuestra memoria.
– Como maximo unos 2/3 (66%) del total.
– Por ejemplo, en un servidor con 4Gbytes de memoria, podemos usar 2048MB como
valor inicial.
 Configuración y tuneo del DBMS
• maintenance_work_mem
– Usada en operaciones: VACUUM, ANALYZE, CREATE INDEX, ALTER TABLE, ADD
FOREIGN KEY.
– Su valor dependera mucho del tamaño de nuestras bases de datos.
– Por ejemplo, en un servidor con 4Gbytes de memoria, podemos usar 256MB como valor
inicial.
• work_mem
– Configura el espacio de memoria que postgres utiliza para realizar ordenaciones de
tablas o de resultados parciales de consultas, sobre todo en ORDER BY, CREATE
INDEX o MERGE JOIN.
– Este valor es más dificil de configurar porque depende, por un lado, de lo grande que
sean las tablas o resultados que hay que ordenar, y por otro, del número de peticiones
simultáneas para esa misma consulta (para cada una se empleará la misma cantidad de
memoria).
– Una buen comienzo es asignar entre un 2% y un 4% del total de la memoria si prevemos
pocos accesos simultáneos a grandes sesiones de ordenación y mucho menor, si
esperamos muchos accesos simultáneos a sesiones de ordenación pequeñas. Como
antes, lo mejor es ir probando distintos valores y ver en qué pueden afectar a la
paginación adversa (swap pagein).
– El valor hay que expresarlo en KB.
 Configuración y tuneo del DBMS
• HUGEPAGE:
• Los procesos no trabajan directamente con la memoria física, sino que lo hacen con la memoria
virtual. Aplicaciones que realizan una gran cantidad de accesos a memoria pueden obtener mejoras
de rendimiento usando páginas grandes gracias a la traducción reducida Lookaside Buffer (TLB).
Hugetlbfs es una función de administración de memoria que se ofrece en el kernel de Linux, que es
útil para aplicaciones que utilizan un gran espacio de direcciones virtuales.

• Para ello se debe realizar una conversión, entre la memoria física y la virtual. Para dicha conversión
cada proceso dispone de una tabla de conversión, y como lo que contiene son direcciones de
pagina, se llama tabla de paginación. En aplicaciones con mucho consumo de memoria, donde
además la información cambia constantemente (por ejemplo, una base de datos), el acceso a la
tabla de paginación es constante.

• Es una característica integrada en el kernel de Linux con la versión 2.6 y superior. Esta
proporciona la alternativa al tamaño de página 4K proporcionando páginas más grandes.

• Las HUGEPAGE más grandes significan que el sistema usa menos tablas de páginas, gestiona
menos asignaciones y, por lo tanto, reduce el esfuerzo para su administración y acceso.
 Las bases de datos en producción.
Las bases de datos en producción:
• Requerimientos para el Diseño de Bases de Datos
– La velocidad de acceso,
– El tamaño de la DB,
– El tipo de los DATOS,
– Facilidad de acceso a los datos,
– Facilidad para extraer los datos requeridos,
– El comportamiento del manejador de bases de datos con cada tipo de datos.

• Un modelo de datos es un conjunto de conceptos utilizados para organizar los datos de

interés y describir su estructura en forma comprensible para un sistema informático.

• Cada modelo de datos provee mecanismos de estructuración, que permiten definir nuevos
tipos de datos a partir de tipos elementales predefinidos
 Las bases de datos en producción.

Las bases de datos en producción: DISEÑO DE BASES DE DATOS

• El diseño de bases de datos es el proceso por el que se determina la organización de
una base de datos, incluidos su estructura, contenido y las aplicaciones que se han
de desarrollar.
• El, el diseño de una base de datos se descompone en: diseño conceptual, diseño
lógico y diseño físico.
 Las bases de datos en producción.
Las bases de datos en producción: DISEÑO DE BASES DE DATOS
• El diseño conceptual
– Parte de las especificaciones de requisitos de usuario y su resultado es el esquema conceptual de la base de
datos.
– Es una descripción de alto nivel de la estructura de la base de datos, independientemente del DBMS que se
vaya a utilizar para manipularla.
– Es un lenguaje que se utiliza para describir esquemas conceptuales.
– El objetivo es describir los datos de la base de datos y no las estructuras de almacenamiento que se
necesitarán para manejar estos datos.
• El diseño lógico
– Parte del esquema conceptual y da como resultado un esquema lógico.
– Es una descripción de la estructura de la base de datos en términos de las estructuras de datos que puede
procesar un tipo de DBMS.
– Un modelo lógico es un lenguaje usado para especificar esquemas lógicos (modelo relacional, de red, etc.).
– Depende del tipo de DBMS que se vaya a utilizar, no depende del producto concreto.
• El diseño físico
– Parte del esquema lógico y da como resultado un esquema físico.
– Es una descripción de la implementación de una base de datos en memoria secundaria: las estructuras de
almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos.
– Depende del DBMS concreto y el esquema físico se expresa mediante su lenguaje de definición de datos.
 Las bases de datos en producción.
Diseño relacional, dimensional y distribuido: Base de datos dimensional
• Son bases de datos ideadas para desarrollar aplicaciones muy concretas, como creación de
Cubos OLAP.
• No se diferencian demasiado de las bases de datos relacionales, la diferencia está más bien a
nivel conceptual;
• En las bases de datos multidimensionales los campos o atributos de una tabla pueden ser de dos
tipos, o bien representan dimensiones de la tabla, o bien representan métricas que se desean
estudiar.
• Está estrechamente relacionada con el procesamiento analítico en línea que forma parte de la
inteligencia empresarial y el almacenamiento de datos.
• El procesamiento analítico en línea (OLAP) facilita la extracción y visualización de datos a través
de diferentes puntos de vista. Se puede utilizar para acceder a datos multidimensionales.
• Las bases de datos multidimensionales se pueden visualizar como cubos de datos que
representan diferentes dimensiones de los datos disponibles. Combina las ventajas de las bases
de datos jerárquicas y relacionales.
• Responde consultas más rápido que las bases de datos relacionales debido a la indexación
multidimensional y el almacenamiento optimizado.
• La salida de las bases de datos multidimensionales tiene una vista similar a una hoja de cálculo
que no se puede lograr en el caso de las bases de datos relacionales.
 Las bases de datos en producción.

Diseño relacional, dimensional y distribuido: Base de datos distribuida

• La base de datos está almacenada en varias computadoras conectadas en
red. Surgen debido a la existencia física de organismos descentralizados.
• Esto les da la capacidad de unir las bases de datos de cada localidad y
acceder así a distintas universidades, sucursales de tiendas, etcétera.
 Las bases de datos en producción.
Limitaciones de los modelos y diagramas ER
 Exclusivo para datos relacionales: comprende que el propósito es solo mostrar
las relaciones. Los diagramas ER muestran únicamente la estructura relacional.
 Inadecuado para datos no estructurados: a menos que los datos se delineen
claramente en campos, filas o columnas diferentes, es probable que los
diagramas ER tengan un uso limitado. Lo mismo sucede con los datos
semiestructurados, porque solo algunos datos serán útiles.
 Complicaciones al realizar una integración con una base de datos
existente: usar modelos ER para realizar una integración con bases de datos
existentes puede ser un desafío debido a las diferentes arquitecturas
 Las bases de datos en producción.
Los componentes y las características de un diagrama ER
 Entidad Algo que se puede definir, como una persona, objeto, concepto u evento, que
puede tener datos almacenados acerca de este.
 Relación Cómo las entidades interactúan o se asocian entre sí. Piensa en las relaciones
como si fueran verbos. Las relaciones se muestran, por lo general, como diamantes o
etiquetas directamente en las líneas de conexión.
 Atributo Una propiedad o característica de una entidad. A menudo se muestra como
un óvalo o círculo.
Cardinalidad Define los atributos numéricos de la relación entre dos entidades o conjuntos
de entidades
Las bases de datos en producción.
CLIENTE miembros
pedidos
Las bases de datos en producción.
Cardinalidad de las Relaciones
 Las bases de datos en producción.
 Modelo dimensional
Diccionario de datos.
■ Un diccionario de datos trata de documentar los metadatos más ligados a su
almacenamiento en la base de datos.
■ Un diccionario de datos es una base de datos que almacena información sobre los
elementos de datos, como los nombres de las variables medidas, sus tipos de datos,
formatos, longitudes, descripciones de texto y otros detalles necesarios para entender los
datos.
■ Incluye aspectos técnicos como el tipo de dato, formato, longitud, posibles valores que
puede tomar e, incluso, transformaciones sufridas, sin olvidar la definición de cada
campo.
■ La documentación de estas transformaciones nos proporcionará automáticamente el linaje
del dato, entendido como la trazabilidad a lo largo de su ciclo de vida.
■ Estos metadatos ayudan a los usuarios a entender los datos desde el punto de vista técnico
para poder explotarlos adecuadamente..
 Diccionario de datos.
Ventajas
■ Permite a los usuarios comprender el significado y la finalidad de los datos.
■ Sirve como punto de referencia importante para cualquier persona que acceda a los datos o los
analice.
■ Ayuda a garantizar el cumplimiento de cualquier norma y reglamento de calidad de datos
existente.
■ Puede ayudar a garantizar la coherencia de los datos en toda la organización.
■ Proporciona a los usuarios una estructura organizada, lo que aumenta la eficacia a la hora de
trabajar con los datos.
■ Puede reducir el riesgo de errores relacionados con la interpretación de los datos.
■ Puede utilizarse como herramienta de gestión y organización de los datos
■ Puede proporcionar una visión general de todos los elementos almacenados en una base de
datos, ayudando a los usuarios a identificar posibles problemas de precisión o coherencia.
■ Permite a las organizaciones comprender mejor sus fuentes de datos, facilitando la toma de
decisiones informadas.
■ Mejora la comunicación entre el personal de TI y las partes interesadas de la empresa al
proporcionar definiciones y descripciones explícitas de los elementos de datos.
 Diccionario de datos.
Categorías de diccionarios de datos
Activo
• Puede considerarse un depósito de información que permite a los usuarios interactuar y realizar
diversas operaciones con los datos, como buscar información más detallada sobre un elemento
concreto, cambiar valores o filtrar entradas específicas.
• Los diccionarios de datos activos se construyen dentro de los sistemas de gestión de bases de
datos (SGBD) y reflejan los cambios en la base de datos anfitriona. .
Pasivo
• Por otro lado, un diccionario de datos pasivo no es mantenido por el SGBD.
• Los cambios en la estructura de la base de datos deben aplicarse manualmente en un
diccionario de datos pasivo o con un software dedicado.
• Suele utilizarse únicamente para proporcionar descripciones y características precisas de los
elementos almacenados en la base de datos asociada, como los tipos y las longitudes;
• Es posible que los diccionarios de datos pasivos no reflejen siempre el estado más reciente de
una base de datos, ya que las actualizaciones manuales pueden requerir más tiempo para su
mantenimiento, lo que puede conllevar el riesgo de que los datos sean inexactos
Diccionario de datos.
Importancia
■ Permiten entender e interpretar un conjunto de datos o base de datos al proporcionar
información básica sobre los campos o variables que contiene. Brindan la siguiente
información:
– Qué significa cada campo o variable.
– Qué tipo de datos contiene.
– Qué valores puede tomar, o si usa algún catálogo.
– Si contiene información pública, confidencial, o reservada.
– Entre otros.
■ Los conjuntos o bases de datos sin un diccionario de datos pueden derivar en malas
interpretaciones y mal uso de los datos.
■ En algunos casos, los datos son inutilizables ya que su interpretación se vuelve imposible.
Diccionario de datos.
■ Principios de los diccionarios de datos
■ Los diccionarios de datos están diseñados para facilitar la comprensión y proveer de
sentido, por tanto deben documentar la existencia, el significado y el uso de cada
elemento del conjunto y/o base de datos.
■ Los diccionarios de datos deben ser accesibles para todas las personas usuarias que
ingresan y extraen datos.
■ Las personas responsables de los datos deben mantener actualizado el contenido del
diccionario de datos, incluidas sus definiciones y sus valores.
■ Los diccionarios de datos deben revisarse periódicamente para garantizar su vigencia
Elementos embebidos.
■ BD embebida-
■ En ella el motor está incrustado en la misma aplicación y su uso es
exclusivo para ella.
■ La base de datos se inicia cuando se arranca la aplicación y finaliza cuando
se cierra la misma.
Catalogos.
■ Un catálogo de datos aprovecha los metadatos y las herramientas de gestión de
datos para crear un inventario de activos de datos dentro de una organización, lo
que permite a los usuarios encontrar y acceder a la información de forma rápida y
sencilla.
■ Un catálogo de datos es un inventario detallado de todos los activos de datos de
una organización, diseñado para ayudar a los profesionales de datos a encontrar
rápidamente los datos más apropiados para cualquier propósito comercial o
analítico.
■ Los catálogos, en una base de datos, son indispensables para un buen diseño de
la misma. Es por eso la importancia de conocer las ventajas y desventajas de su
uso
■ Un catálogo es una tabla de datos que contiene información relevante sobre las
opciones finales de un usuario en una aplicación.
 Catálogos.
■ Un catálogo de datos utiliza metadatos, para crear un inventario informativo y de
búsqueda de todos los activos de datos en una organización. Estos activos pueden incluir
(pero no se limitan a) estas cosas:
– Datos estructurados (tabulares)
– Datos no estructurados, incluidos documentos, páginas web, e-mail, contenido de
redes sociales, datos móviles, imágenes, audio y video
– Informes y resultados de consultas
– Visualizaciones de datos y paneles de control
– Modelos de machine learning
– Conexiones entre bases de datos
■ Este inventario permite a los ciudadanos de datos (analistas de datos, científicos de datos,
administradores de datos y otros profesionales de datos con acceso a datos corporativos)
buscar a través de todos los activos de datos disponibles de una organización y ayudarse
a sí mismos a obtener los datos más apropiados para sus fines analíticos o comerciales.
Catálogos.
■ Un catálogo de datos generalmente incluye funciones para recopilar y
enriquecer continuamente, o organizar, los metadatos asociados con cada
activo de datos para que cada activo sea más fácil de identificar, evaluar y
usar correctamente. El catálogo también proporciona herramientas que
permiten a los usuarios hacer lo siguiente:
– Buscar en el catálogo
– Automatizar el descubrimiento de datos potencialmente relevantes que
no buscaron específicamente
– Gestionar el uso de los datos de conformidad con las regulaciones
gubernamentales o de la industria
 Catálogos.
Beneficios del catálogo de datos
■ Mejor comprensión de los datos mediante un contexto mejorado: los analistas pueden encontrar
descripciones detalladas de los datos, incluidos los comentarios de otros ciudadanos de datos, y
comprender mejor cómo los datos son relevantes para el negocio.
■ Mayor eficiencia operativa: un catálogo de datos crea una óptima división del trabajo entre usuarios
y TI: los ciudadanos de datos pueden acceder y analizar datos más rápido, y el personal de TI puede
dedicar más tiempo a las tareas de alta prioridad.
■ Riesgo reducido: los analistas se sienten más seguros al trabajar con datos que están autorizados a
usar para un propósito determinado, de conformidad con las normas de privacidad de datos y de la
industria. También pueden revisar rápidamente anotaciones y metadatos para detectar campos nulos o
valores incorrectos que pueden afectar el análisis.
■ Mayor éxito con las iniciativas de gestión de datos: cuanto más difícil sea para los analistas de
datos encontrar, acceder, preparar y confiar en los datos, menos probable es que las iniciativas de
inteligencia comercial (BI) y los proyectos de big data tengan éxito.
■ Mejores datos y mejores análisis, más rápido: una ventaja competitiva: los profesionales de datos
pueden responder rápidamente a problemas, desafíos y oportunidades con análisis y respuestas
basadas en todos los datos contextuales más apropiados dentro de la organización.
■ Un catálogo de datos también puede ayudar a su organización a enfrentar desafíos y objetivos técnicos
y comerciales específicos.
■ Al proporcionar a los analistas una vista única y completa de sus clientes, un catálogo de datos puede
ayudar a descubrir nuevas oportunidades para ventas cruzadas, ventas adicionales, promociones
dirigidas y más.
Aplicaciones en producción.
Supervisión de la instalación de aplicaciones: Extensiones PostgreSQL
■ Una extensión es un conjunto coherente de funciones, tipos de datos, operadores o
cualquier otro objeto útil, que ofrece una nueva funcionalidad a PostgreSQL.
■ Una extensión se puede proporcionar por PostgreSQL o cualquier otro proveedor.
■ Cuando se instala PostgreSQL mediante un sistema de paquetes, como en las
distribuciones GNU/Linux Debian, Ubuntu, Red Hat o CentOS, un paquete específico
contiene las extensiones proporcionadas por PostgreSQL: postgresql-contrib-10 para
Debian y Ubuntu o postgresql10-contrib para Red Hat y CentOS.
■ Las extensiones no proporcionadas por PostgreSQL se instalan por el sistema de paquetes.
■ La mayor parte de ellas se escriben en lenguaje C y, por lo tanto, se deben compilar en
función de la versión elegida y, por otra parte, porque los archivos se deben instalar en la
arborescencia de la versión principal de PostgreSQL.
Aplicaciones en producción.
Supervisión de la instalación de aplicaciones: Extensiones PostgreSQL
■ Las extensiones son librerías que se agregan a PostgreSQL, para funcionalidades
especificas.
■ Dependiendo de las extensiones se pueden encontrar de tres formas diferentes.
■ Extensiones disponibles en el Servidor PostgreSQL.
– Son un grupo de extensiones habilitadas en nuestro servidor.
– Cuando ejecutamos SELECT * FROM pg_available_extensions ORDER BY name,
vemos cuales son las extensión que tenemos habilitadas en nuestro Servidor
■ Extensiones PostgreSQL de la web oficial.
– Éstas extensiones las podemos encontrar en la web official de Postgres, en software
catalogue – postgresql extensions y se implementan con unos sencillos pasos.
■ Extensiones PostgreSQL encontradas en Internet.
– Hay otras extensiones disponibles en internet por ejemplo. db_info: (btenemos información
sobre la Base de Datos) , jx_io (importar o exportar datos del tipo JSON o XML), msmov, (para
recoger datos desde un Servidor MS Server SQL) y vacuum_utils: (contiene funciones para llevar un
mantenimiento del Servidor)
Aplicaciones en producción.
■ Monitoreo de las aplicaciones y el acceso a las DB
■ Cuando una aplicación es lenta, debemos contestar a las siguientes inquietudes: ¿Desde
cuándo se presenta este comportamiento? y ¿Qué componente causa la lentitud?, aquí es
donde entran en juego las técnicas de monitoreo.
■ Algunos de los enfoques tradicionales para la supervisión del rendimiento incluyen la
ejecución de pruebas de ping en aplicaciones sospechosas de ser lentas, ejecutar pruebas
de telnet a los puertos de la aplicación para el diagnóstico y medir las métricas del nivel del
servidor (CPU, memoria, disco, etc.).
■ Pero estos no son suficientes para localizar los cuellos de botella en los entornos de
aplicaciones distribuidas en entornos híbridos de hoy: nube pública, nube privada o
sistemas hosteados en centros de datos.
■ Las organizaciones deben poder conectar el viaje del usuario con la infraestructura de la
aplicación y comprender cuándo, dónde y por qué la experiencia del usuario se ve afectada
durante el acceso a la aplicación.
Aplicaciones en producción.
■ El monitoreo o (Application Performance Monitoring o APM) son herramientas y procesos diseñados para
ayudar a garantizar que los usuarios de las aplicaciones obtengan los estándares de rendimiento y
tengan una experiencia de usuario (UX) valiosa.
■ APM es administrar el rendimiento de las aplicaciones (monitoreo) de manera que podamos determinar
cuándo se comportan normalmente y cuándo se comportan de manera anormal. Además, cuando algo
sale mal y una aplicación se comporta de manera anormal, necesitamos identificar la causa raíz del
problema rápidamente para poder remediarlo. Con un APM podemos observar cosas como:
– El hardware físico sobre el que se ejecuta la aplicación.
– Las máquinas virtuales en las que se ejecuta la aplicación.
– La JVM que aloja el entorno de la aplicación.
– El contenedor (servidor de aplicaciones o contenedor web) en el que se ejecuta la aplicación.
– El comportamiento de la aplicación en sí.
– Infraestructura de soporte, como comunicaciones de red, bases de datos, cachés, servicios web
externos y software heredado.
■ Una vez que hemos capturado los datos de rendimiento de todas estas fuentes, debemos interpretarlas y
correlacionarlas con respecto al impacto en las transacciones comerciales
■ Los proveedores de APM emplean expertos en diferentes tecnologías para que puedan comprender, en
un nivel profundo, qué significan los datos de rendimiento en cada sistema o software individual y luego
agregar esos datos en una vista holística de su aplicación.
Aplicaciones en producción.
■ ¿Qué sucede si no cuento con un APM?
■ A continuación, consideraremos cómo identificamos la causa raíz de un problema de
rendimiento sin una solución APM. La mayoría de las veces hacemos una de dos cosas:
– Revisar registros (logs) de tiempo de ejecución
– Intentar reproducir el problema en un entorno de desarrollo / prueba
■ Un DBA debe estar un paso adelante y evitar que la base de datos sufra problemas difíciles
de detectar manualmente, ya que requiere un monitoreo continuo las 24 horas del día, los 7
días de la semana. Las cosas empeoran si la base de datos es grande.
■ La mayoría de las herramientas de monitoreo modernas le permiten medir de manera
intuitiva cientos de métricas y datos históricos diferentes, lo que DBA puede comparar y
correlacionar con la identificación de cualquier problema de rendimiento.
■ También le permiten establecer alertas personalizadas utilizando diferentes puntos de
referencia y generar informes de rendimiento, lo que facilita la identificación de problemas y
áreas potenciales donde la base de datos puede aumentar su rendimiento.
■ Administrar y monitorear bases de datos en múltiples servidores e instancias es un desafío
sin las herramientas adecuadas, incluso para administradores de bases de datos
experimentados.
Aplicaciones en producción.
■ Control de mantenimiento y actualizaciones: Notificación de mantenimiento planeado
■ Permiten recibir alertas de eventos de mantenimiento planeado futuros para la
instancia de Base de datos. Estas notificaciones se integran con el mantenimiento
planeado de Service Health y le permiten ver todo el mantenimiento programado para
sus suscripciones en un mismo lugar.
■ Ayuda a escalar la notificación a las audiencias adecuadas de distintos grupos de
recursos, ya que puede tener distintos contactos responsables para los distintos
recursos.
■ En los casos de revisiones críticas o de seguridad, es posible que las notificaciones
se envíen más cerca del evento o se omitan.
 Aplicaciones en producción.
■ Control de mantenimiento y actualizaciones: Postgres
■ Antes de empezar tienes que comprender el concepto «filas muertas» y «filas vivas». Hay que
tener en cuenta que cuando se ejecuta un UPDATE o un DELETE, marca la fila como borrada.
Esto produce internamente «filas muertas«, que son aquellas filas cuyos valores han sido
eliminados o los valores anteriores a una actualización y «filas vivas«, que son los nuevos valores
insertados o los nuevos valores de una fila actualizada.
■ Comandos requeridos: En primer lugar necesitamos conocer los comandos necesarios para
ejecutar las tareas de mantenimiento.
■ Comando ANALYZE: Se analizan cada una de las tablas o la base de datos para informar al
planificador de consultas del estado de las mismas, de esta forma obtenemos mejor rendimiento
cuando se ejecutan las consultas.
■ Comando VACUUM: Se utiliza para realizar limpieza en cada tabla o en la base de datos, así
evitamos que el sistema se sobrecargue de filas muertas o que las tablas ocupen demasiado
espacio físico en el disco duro. Esto podría hacer que el sistema se vea mermado en su
rendimiento con el paso del tiempo.
■ Comando REINDEX: Es similar al anterior, con la diferencia que actúa sobre los índices.
Reconstruye los índices eliminando aquellas páginas que no contienen filas. De esta forma se
disminuye el tamaño.
Aplicaciones en producción.
■ Control de mantenimiento y actualizaciones: Areas de mantenimiento
■ Es posible ejecutar el comando ANALYZE junto al comando VACUUM, de
hecho es una buena práctica. De esta forma limpiamos cada una de las tablas de
manera que aquellas filas muertas producidas por los UPDATES y DELETES, sean
reutilizadas para nuevos INSERT y además, se actualiza la información obtenida
de las tablas.
■ Para las tablas que no se realizan nuevas escrituras, es conveniente ejecutar el
comando VACUUM FULL. De esta forma se recupera el espacio en el disco
duro a nivel físico ocupado por aquellas filas muertas.
■ Lo siguiente a realizar es el comando REINDEX para reconstruir aquellos
índices que están hinchados (bloated), es decir, contiene muchas páginas
vacías con filas muertas.
Aplicaciones en producción.
■ Control de mantenimiento y actualizaciones: Consideraciones a tener en cuenta
al realizar las tareas de mantenimiento en PostgreSQL
■ Es muy recomendable aumentar el valor del parámetro maintenace_work_men
para reducir el tiempo de ejecución de tales tareas. Podemos hacer uso del comando
SET para modificar el parámetro en la sesión. Recordad que una vez se terminen de
ejecutar todos los comandos hay que volver a poner el valor predeterminado del
parámetro.
■ El comando VACUUM ANALYZE es relativamente rápido y no bloquea las tablas
que está limpiando. Por lo contrario el comando VACUUM FULL, es mucho más lento
y además, bloquea la tabla que está reconstruyendo para recuperar el espacio
ocupado.
■ Para recuperar el espacio ocupado por las tablas se requiere de espacio extra en el
disco duro, pues realmente clona en un nuevo fichero aquellas páginas que están
llenas y elimina el fichero antiguo que contiene las páginas vacías..
 Unidad 2
OPTIMIZACIÓN DEL DBMS
Componentes del DBMS: Hardware
Componentes del DBMS: Hardware

■ Es el soporte físico que permite almacenar la información de la DB

■ Constituido por dispositivo de almacenamiento como discos, tambores, cintas,etc.
■ Hablamos de la parte de las estructuras físicas a través de las cuales se gestiona un
sistema de base de datos, por tanto los dispositivos informáticos, la propia máquina, más
o menos compleja según las necesidades.
■ Características del DBMS
■ Los sistemas de administración de bases de datos son usados para:
– Permitir a los usuarios acceder y manipular la base de datos proveyendo métodos
para construir sistemas de procesamiento de datos para aplicaciones que requieran
acceso a los datos.
– Proveer a los administradores las herramientas que les permitan ejecutar tareas de
mantenimiento y administración de los datos.
Componentes del DBMS: Hardware
■ Seguridad: La disponibilidad de los datos puede ser restringida a ciertos usuarios. Según
los privilegios que posea cada usuario de la base de datos, podrá acceder a mayor
información que otros.
■ Velocidad: Los sistemas DBMS modernos poseen altas velocidades de respuesta y
proceso.
■ Independencia del hardware: La mayoría de los sistemas DBMS están disponibles para
ser instalados en múltiples plataformas de hardware.
■ Los sistemas de bases de datos relacionales RDBMS (RelationalDatabase Management
System, por sus siglas en Inglés) tales como Oracle, MySQL, SQL Server, PostgreSQL,
Informix, entre otros, le permiten ejecutar las tareas que se mencionan a continuación, de
una forma entendible y razonablemente sencilla:
– Le permiten ingresar datos al sistema.
– Le permiten almacenar los datos.
– Le permiten recuperar los datos y trabajar con ellos.
– Le proveen herramientas para capturar, editar y manipular datos.
– Le permiten aplicar seguridad.
– Le permiten crear reportes e informes con los datos.
Componentes del DBMS: Hardware
Estructura de memoria y procesos de la instancia
La memoria se puede estructurar en las siguientes partes:
■ Área Global del sistema (SGA), la cual se comparte entre todos los servidores y los
procesos en segundo plano.
■ Áreas globales de programas (PGA), que es privada para cada servidor y proceso en
segundo planos; a cada proceso se asigna un PGA.
■ Área de Ordenaciones (SortAreas).
■ Memoria Virtual
■ Área de código de software.
Componentes del DBMS: Hardware
■ Instancia de una Base de Datos
■ Cada instancia está asociada a una base de datos.
■ Cuando se inicia una base de datos en un servidor (independientemente del tipo de
computadora), se le asigna un área de memoria (SGA) y lanza uno o más procesos. A la
combinación del SGA y de los procesos es lo que se llama instancia.
■ La memoria y los procesos de una instancia gestionan los datos de la base de datos
asociada de forma eficiente y sirven a uno o varios usuarios.
■ Cuando se inicia una instancia El DBMS monta la base de datos, es decir, asocia dicha
instancia a su base de datos correspondiente.
■ En un misma computadora pueden ejecutarse varias instancias simultáneamente,
accediendo cada una a su propia base de datos física.
■ Únicamente el administrador de la base de datos puede iniciar una instancia y abrir una
base de datos.
■ Si una base de datos está abierta, entonces el administrador puede cerrarla y, cuando esto
ocurre, los usuarios no pueden acceder a la información que contiene.
 Componentes del DBMS: Hardware
Desde el punto de vista físico, la base de datos está conformada por dos tipos de archivos:
1. Archivos de datos:
■ contiene los datos de la base de datos internamente, está compuesto por páginas
enumeradas secuencialmente que representa la unidad mínima de almacenamiento.
■ Cada página tiene un tamaño de 8kb de información. Existen diferentes tipos de páginas, a
tener en cuenta:
■ Páginas de datos: es el tipo principal de páginas y son las
que almacenan los registros de datos.
■ Páginas de espacio libre : almacenan información sobre la
ubicación y el tamaño del espacio libre.
■ Paginas GAM and SGAM: utilizadas para ubicar extensiones.
■ Páginas de Mapa de Ubicaciones: contiene información
sobre el almacenamiento de páginas de una tabla o índice en
particular.
■ Páginas Índices: Utilizada para almacenar registros de
índices
Componentes del DBMS: Hardware
2. Archivo de Registro de Transacciones:
■ El propósito del registro de transacciones es la recuperación de datos a un momento en el
tiempo o complementar una restauración de copia de respaldo completa (full backup).
■ El registro de transacciones no contiene páginas, sino entradas con todos los cambios
realizados en la base de datos, como son
– las modificaciones de datos,
– modificaciones de la base de datos y
– eventos de copia de seguridad y restauración.
■ El acceso a datos es secuencial, ya que el registro de transacciones se actualiza en el
mismo orden cronológico en el que se hacen las modificaciones
■ Este archivo no puede ser leído por herramientas de usuario de SQL auque existen
herramientas de terceros que leen este archivo para recuperar los cambios efectuados.
Componentes del DBMS: Hardware
■ Data File
■ Los datafiles son los archivos físicos en los que se almacenan los objetos que
forman parte de un tablespace.
■ Un datafile pertenece solamente a un tablespace y a una instancia de base de
datos.
■ Cuando se crea un datafile, se debe indicar su nombre, su ubicación o directorio,
el tamaño que va a tener y el tablespace al que va a pertenecer.
■ Al crearlos, ocupan ya ese espacio aunque se encuentran totalmente vacíos. Si
no hay sitio suficiente para crear un archivo físico del tamaño indicado, se
producirá un error.
Componentes del DBMS: Hardware
■ Un tablespace puede estar formado por uno o varios datafiles.
■ Cuando se van creando objetos en un tablespace, éstos físicamente se van
almacenando en los datafiles asignados a dicho tablespace, es decir, cuando creamos
una tabla y vamos insertando datos en ella, estos datos realmente se reparten por los
archivos físicos o datafiles que forman parte del tablespace.
■ No se puede controlar en qué archivo físico se almacenan los datos de un tablespace.
■ Si un tablespace está formado por 2 datafiles y tenemos una tabla en ese tablespace,
a medida que vamos insertando filas éstas se almacenarán en cualquiera de los dos
datafiles indistintamente, es decir, unas pueden estar en un datafile y otras en otro.
■ El espacio total disponible en un tablespace es lógicamente la suma de los tamaños
que ocupan los archivos físicos o datafiles que lo forman.
■ A medida que se van creando objetos en ellos como tablas, índices, etc. y se van
insertando registros en estas tablas, los datafiles se van llenando o, lo que es lo
mismo, el tablespace se va llenando.
 Componentes del DBMS: Hardware
Arquitectura de un DBMS
El comité ANSI/X3/SPARC propuso una arquitectura para DBMSs basada en tres niveles:
Nivel interno, o de máquina Describe en detalle la forma de cómo se almacenan los datos en los
dispositivos de almacenamiento. Responde a las cuestiones de rendimiento planteadas al hacer el
diseño físico de la BD y al ajustarlo posteriormente a nuevas necesidades.

■ Nivel externo, o de usuario Es lo que

el usuario final puede visualizar del
sistema terminado, muestra sólo una
parte de la base de datos al usuario
acreditado para verla.
■ Nivel conceptual Describe qué datos
son almacenados realmente en la base
de datos y las relaciones que existen
entre los mismos, describe la base de
datos completa en términos de su
estructura de diseño
Componentes
del DBMS:
Hardware
Componentes del DBMS: Software
■ Software.- Permite interactuar con la base de datos de manera eficiente
■ Una base de datos es una colección de datos almacenados y organizados de forma que un
programa del ordenador pueda seleccionarlos rápidamente y capaces de ser: recobrados,
actualizados, insertados y borrados.
■ En un DBMS una base de datos es un sistema de archivos electrónico
■ SISTEMA DE GESTIÓN DE BASE DE DATOS (SGBD) DATA BASE MANAGMENT
SYSTEM (DBMS)
– Son aplicaciones que permiten a los usuarios definir, crear y mantener la base de datos
y proporciona un acceso controlado a la misma.
– Son aplicación que interactúa con los usuarios de los programas de aplicación y la
base de datos.
– Algunos de los SGBD más conocidos son: SQL, DB2, SLQ/DS, ORACLE, INGRES,
INFORMIX, SYBASE, PARADOX, DBASE, ACCESS, FOXPRO, R, RM/T y RM/V2..
 Componentes del DBMS: Software
■ OBJETIVOS DE UN SGBD
■ Definir la Base de Datos mediante el Lenguaje de Definición de Datos, el cual permite especificar
la estructura, tipo de datos y las restricciones sobre los datos, almacenándolo todo en la base de
datos.
■ Separar la descripción y manipulación de la data, permitiendo un mayor entendimiento de los
objetos, además de flexibilidad de consulta y actualización de los datos.
■ Permitir la inserción, eliminación, actualización, consulta de los datos mediante el Lenguaje de
Manejo de Datos, lo que permite resolver el problema que presentan los sistemas de archivos,
donde hay que trabajar con un conjunto fijo de consultas o la necesidad de tener muchos
programas de aplicaciones. Existen dos tipos de programas de Manejo de Datos,
– Lenguajes procedurales: manipulan la base de datos registro a registro y se deben
especificar las operaciones a realizar para obtener los datos resultado.
– Lenguajes no procedurales: manipulan la base de datos en conjuntos de registros y se
especifican qué datos deben obtenerse como resultado sin plantear las forma de hacerlo. El
lenguaje no procedural más utilizado es SQL
 Componentes del DBMS: Software
■ OBJETIVOS DE UN SGBD
■ Proporcionar acceso controlado a la base de datos.
– Seguridad: los usuarios no autorizados no pueden acceder a la base de datos.
– Integridad: mantiene la integridad y consistencia de la base de datos.
– Control de Recurrencia: permite el acceso compartido a la base de datos.
– Control de Recuperación: restablece la base de datos después de producirse un fallo de
software o hardware.
– Diccionario de datos o Catálogo: contiene la descripción de los datos de la base de datos y
es accesible por el usuario.
■ Proporcionar un mecanismo de vistas, que permita a cada usuario tener su propia vista o visión
de la base de datos. El lenguaje de definición nos permite definir las vistas como subconjuntos
de la base de datos, permitiendo:
– Proporcionar un nivel de seguridad excluyendo datos para que no sean vistos por
determinados usuarios.
– Permiten que los usuarios vean los datos en el formato deseado.
– Una vista representa una imagen consistente y permanente de la base de datos, aún
cuando a la base de datos se le hagan cambios en sus estructura.
Componentes del DBMS: Software
■ OBJETIVOS DE UN SGBD
■ Gestionar la estructura física de los datos y su almacenamiento, proporcionando
eficiencia en las operaciones de la base de datos y el acceso al medio de
almacenamiento.
■ Eliminar la redundancia de datos, establecer una mínima duplicidad en los datos y
minimizar el espacio en disco utilizado.
■ Proveer interfaces procedimentales y no procedimentales, permitiendo la manipulación
por usuarios interactivos y programadores.
■ Independizar la estructura de la organización lógica de los datos (Independencia
física).
■ Independizar la descripción lógica de la Base de datos y las descripciones particulares
de los diferentes puntos de vistas de los usuarios.
■ Permitir una fácil administración de los datos
Componentes del DBMS: Software
EXISTENCIA DE LOS SGBD
■ Mejora en la integridad de datos: Se refiere a la validez y la consistencia de los datos
almacenados. Normalmente, se expresa mediante restricciones o reglas que no se pueden
violar. Estas restricciones se pueden aplicar tanto a los datos, como a sus relaciones, y es
el SGBD quien se debe encargar de mantenerlas.
■ Mejora en la seguridad: Los SGBD permiten mantener la seguridad mediante el
establecimiento de claves para identificar al personal autorizado a utilizar la base de datos.
Las autorizaciones se pueden realizar a nivel de operaciones, de modo que un usuario
puede estar autorizado a consultar ciertos datos pero no a actualizarlos,
■ Mejora en la accesibilidad a los datos: Muchos SGBD proporcionan lenguajes de
consultas o generadores de informes que permiten al usuario hacer cualquier tipo de
consulta sobre los datos, sin que sea necesario que un programador escriba una aplicación
que realice tal tarea.
Componentes del DBMS: Software
EXISTENCIA DE LOS SGBD
■ Mejora en la productividad: A nivel básico, el SGBD proporciona todas las rutinas de
manejo de archivos típicas de los programas de aplicación. El hecho de disponer de estas
funciones permite al programador centrarse mejor en la función específica requerida porlos
usuarios, sin tener que preocuparse de los detalles de implementación de bajo nivel.
■ Mejora en el mantenimiento gracias a la independencia de datos: Los SGBD separan
las descripciones de los datos de las aplicaciones. Esto es lo que se conoce como
independencia de datos, gracias a la cual se simplifica el mantenimiento de las aplicaciones
que acceden a la base de datos.
■ Aumento de la concurrencia: La mayoría de los SGBD gestionan el acceso concurrente a
la base de datos y garantizan que no ocurran problemas en el acceso de múltiples usuarios.
■ Mejora en los servicios de copias de seguridad y de recuperación ante fallos: Los
SGBD actuales funcionan de modo que se minimiza la cantidad de trabajo perdido cuando
se produce un fallo
 Componentes del DBMS: DATO

■ Técnicamente, los datos son hechos y cifras en

bruto, tales que pueden registrarse, como ser
números telefónicos, direcciones, nombres,
órdenes y pagos, los cuales se procesan para
obtener información,
■ por ejemplo el saldo deudor y el monto
disponible.
■ Nota: Los datos no contienen información
■ Datos de una DB se refiere a archivos, bases
de datos, documentos de texto, imágenes y, voz
y video codificados en forma digita
 Componentes del DBMS: DATO
INFORMACIÓN
■ La definición de información es: Un conjunto de datos significativos y pertinente que describen sucesos o
entidades.
■ A diferencia de los datos, la información tiene significado para quien la recibe siendo esta el resultado del
procesamiento de los datos extraídos de una DB
■ Es común que los términos datos e información se tomen incorrecta mente como sinónimos.
■ Recordemos que en una DB puede ser lo que para algunos usuarios es información sin embargo, esta
deberá considerarse siempre como datos hasta que estos hayan salido del sistema a través de un DBMS.
■ Las Bases de Datos y el sistema administrador resultan ser la columna vertebral de cualquier Empresa,
siendo esta una unidad económico- social, integrada por elementos humanos, materiales y técnicos, que
tiene por objeto obtener un resultado a través de su participación en la sociedad, con o sin afán de lucro.,
como pueden ser:
– Hospitales, Industrias manufactureras, Bancos, Escuelas, Instituciones Gubernamentales, etc
■ Donde para operar se deben tener una gran cantidad de datos como:
– Datos de producción, Información de pacientes , Cuentas contables, Datos de alumnos y profesores,
Censos de población y de recursos, Etc
 Data Lake

✓ Data Lake es ideal para almacenar big data no estructurado, como tweets, imágenes, voz y
datos en streaming. Pero puede utilizarse para almacenar todo tipo de datos: cualquier
fuente, cualquier tamaño, cualquier velocidad, cualquier estructura.
✓ Algunos de los formatos de información almacenada en los Data Lakes son:
• Datos estructurados, como las filas y columnas de las tablas de las bases de datos
relacionales.
• Datos semi estructurados, como archivos de texto plano delimitados y archivos con
esquemas.
• Datos no estructurados entre los que se incluyen los contenidos de las redes sociales y los
datos del Internet de las cosas (IoT), así como documentos, imágenes, voz y vídeo.
 Big Data
✓ Cuando hablamos de Big Data nos referimos a conjuntos de datos o combinaciones de conjuntos de
datos cuyo tamaño (volumen), complejidad (variabilidad) y velocidad de crecimiento (velocidad)
dificultan su captura, gestión, procesamiento o análisis mediante tecnologías y herramientas
convencionales, tales como bases de datos relacionales y estadísticas convencionales o paquetes de
visualización, dentro del tiempo necesario para que sean útiles.
✓ Aunque el tamaño utilizado para determinar si un conjunto de datos determinado se considera Big
Data no está firmemente definido y sigue cambiando con el tiempo, la mayoría de los analistas y
profesionales actualmente se refieren a conjuntos de datos que van desde 30-50 Terabytes a varios
Petabytes.
✓ La naturaleza compleja del Big Data se debe principalmente a la naturaleza no estructurada de gran
parte de los datos generados por las tecnologías modernas, como los web logs, la identificación por
radiofrecuencia (RFID), los sensores incorporados en dispositivos, la maquinaria, los vehículos, las
búsquedas en Internet, las redes sociales como Facebook, computadoras portátiles, teléfonos
inteligentes y otros teléfonos móviles, dispositivos GPS y registros de centros de llamadas.
✓ En la mayoría de los casos, con el fin de utilizar eficazmente el Big Data, debe combinarse con datos
estructurados de una aplicación comercial más convencional, como un o un CRM
Componentes del DBMS: DATO
Componentes del DBMS: Procedures (embebidos)
■ Un procedimiento almacenado se puede definir como un programa,
procedimiento ó función, el cual está almacenado en la base de datos y listo
para ser usado.
Componentes del DBMS: Procedures (embebidos)
■ Existen dos ventajas evidentes al utilizar procedimientos almacenados en
nuestro sistema:
■ La ejecución del procedimiento ocurre en el servidor de bases de datos.
– Esto probablemente aumentará el rendimiento de nuestra aplicación al
no tenerse que mandar datos entre el cliente y el servidor, y no tener
que procesar resultados intermedios en el cliente para obtener el
resultado final.
■ Al tener la lógica de la aplicación implementada en la base de datos no
tendremos que implentarla en los clientes, con el consiguiente ahorro de
lineas de código redundante y complejidad.
■ Si tenemos diferentes tipos de clientes implementados en diferentes
sistemas ó lenguajes de programación y accediendo a la misma base de
datos, no tendremos que programar la misma lógica en todos, al estar esta
disponible en la base de datos. Tendremos una API a la lógica de la
aplicación lista para usarse desde diferentes clientes
Componentes del DBMS: Procedures (embebidos)
■ PL/pgSQL
■ Un procedimiento almacenado en PostgreSQL se puede escribir en multiples
lenguajes de programación. En una instalación por defecto de PostgreSQL
podremos tener disponibles los siguientes lenguajes: PL/pgSQL, PL/Perl, PL/Tcl y
PL/Python
■ PL/pgSQL es muy parecido al lenguaje PL/SQL utilizado por Oracle.
■ Los objetivos de PL/pgSQL cuando se creo fueron:
– Poder ser usado para crear funciones y disparadores (triggers)
– Añadir estructuras de control al lenguaje SQL
– Poder realizar cálculos complejos
– Heredar todos los tipos, funciones y operadores definidos por el usuario
– Poder ser definido como un lenguaje “de confianza”
– Fácil de usar
■ PL/pgSQL es un lenguaje estructurado en bloques. Como mínimo tendremos un
bloque principal en nuestro procedimiento almacenado y dentro de este podremos
tener subbloques. Un bloque se define de la siguiente manera (Todo entre los
corchetes [] es opcional):
 Componentes del DBMS: Procedures (embebidos)
■ Disparador (trigger en inglés)
■ Es un objeto de una base de datos que define una acción que se ejecutará
de manera automática.
■ Este disparador se relaciona con una de las tablas y se ejecuta al realizarse
una modificación sobre la misma, normalmente con las sentencias INSERT,
UPDATE o DELETE.
■ Esta función definida en el disparador puede estar programado en diversos
lenguajes de programación, como PL/Python, Perl y PL, aunque el más
sencillo para la creación de este tipo de objetos es PL/pgSQL.
■ Las ventajas de usar PL/pgSQL son las siguientes:
– Puede usarse para crear funciones y disparadores
– Añade estructuras de control al lenguaje SQL
– Puede ejecutar cálculos complejos
– Hereda todos los tipos, funciones y operadores definidos por el usuario
Componentes del DBMS: Procedures (embebidos)

■ Un disparador no es otra cosa que una acción definida en una tabla de

nuestra base de datos y ejecutada automáticamente por una función
programada por nosotros.
■ Esta acción se activará, segun la definamos, cuando realicemos un INSERT,
un UPDATE ó un DELETE en la susodicha tabla.
■ Un disparador se puede definir de las siguientes maneras:
– Para que ocurra ANTES de cualquier INSERT,UPDATE ó DELETE
– Para que ocurra DESPUES de cualquier INSERT,UPDATE ó DELETE
– Para que se ejecute una sola vez por comando SQL (statement-level
trigger)
– Para que se ejecute por cada linea afectada por un comando SQL (row-
level trigger)
Componentes del DBMS: Procedures (embebidos)
■ Esta es la definición del comando SQL que se puede utilizar para definir un
disparador en una tabla

■ Antes de definir el disparador tendremos que definir el procedimiento

almacenado que se ejecutará cuando nuestro disparador se active
 Componentes del DBMS: Procedures (embebidos)
Características y reglas a seguir
1. El procedimiento almacenado que se vaya a utilizar por el disparador debe de definirse e instalarse
antes de definir el propio disparador.
2. Un procedimiento que se vaya a utilizar por un disparador no puede tener argumentos y tiene que
devolver el tipo "trigger".
3. Un mismo procedimiento almacenado se puede utilizar por múltiples disparadores en diferentes tablas.
4. Procedimientos almacenados utilizados por disparadores que se ejecutan una sola vez per comando
SQL (statement-level) tienen que devolver siempre NULL.
5. Procedimientos almacenados utilizados por disparadores que se ejecutan una vez per linea afectada
por el comando SQL (row-level) pueden devolver una fila de tabla
6. Procedimientos almacenados utilizados por disparadores que se ejecutan una vez per fila afectada por
el comando SQL (row-level) y ANTES de ejecutar el comando SQL que lo lanzó, pueden:
Retornar NULL para saltarse la operación en la fila afectada.
Ó devolver una fila de tabla (RECORD)
 Componentes del DBMS: Procedures (embebidos)
7. Procedimientos almacenados utilizados por disparadores que se ejecutan DESPUES de ejecutar el
comando SQL que lo lanzó, ignoran el valor de retorno, asi que pueden retornar NULL sin problemas.
8. En resumen, independendientemente de como se defina un disparador, el procedimiento
almacenado utilizado por dicho disparador tiene que devolver ó bien NULL, ó bien un valor RECORD
con la misma estructura que la tabla que lanzó dicho disparador.
9. Si una tabla tiene más de un disparador definido para un mismo evento (INSERT, UPDATE,
DELETE), estos se ejecutarán en orden alfabético por el nombre del disparador. En el caso de
disparadores del tipo ANTES / row-level, la file retornada por cada disparador, se convierte en la
entrada del siguiente. Si alguno de ellos retorna NULL, la operación será anulada para la fila afectada.
10. Procedimientos almacenados utilizados por disparadores pueden ejecutar sentencias SQL que a
su vez pueden activar otros disparadores. Esto se conoce como disparadores en cascada. No existe
límite para el número de disparadores que se pueden llamar pero es responsabilidad del programador
el evitar una recursión infinita de llamadas en la que un disparador se llame asi mismo de manera
recursiva.
El uso de disparadores de manera incorrecta ó inefectiva puede afectar significativamente al
rendimiento de nuestra base de datos.
Componentes del DBMS: atabase access language (DDL, DML, DCL, TCL)
■ Comandos de SQL
■ Los comandos de SQL son sentencias que se pueden utilizar para
diferentes tareas y están divididos en cuatro grupos: DDL, DML, DCL y TCL.
Componentes del DBMS: database access language (DDL, DML, DCL, TCL)

Lenguaje de Definición de Datos (DDL)

■ Es un lenguaje para definir estructuras de datos, proporcionado por los
sistemas gestores de bases de datos.
■ En inglés, Data Definition Language, de ahí sus siglas DDL.
■ Define las estructuras que almacenarán los datos así como los
procedimientos o funciones que permitan consultarlos.
■ Para definir las estructura por ejemplo:
– CREATE, se usa para crear una base de datos, tabla, vistas, etc.
– ALTER, se utiliza para modificar la estructura, por ejemplo añadir o
borrar columnas de una tabla.
– DROP, con esta sentencia, podemos eliminar los objetos de la
estructura, por ejemplo un índice o una secuencia
Componentes del DBMS: database access language (DDL, DML, DCL, TCL)

Lenguaje de Manipulación de Datos (DML)

■ Es un lenguaje proporcionado por los sistemas gestores de bases de datos.
■ En inglés, Data Manipulation Language (DML).
■ Para manipular la información de una base datos que previamente hemos definido con el DDL
■ Utilizando instrucciones de SQL, permite a los usuarios introducir datos para
posteriormente realizar tareas de consultas o modificación de los datos que contienen las
Bases de Datos.
■ Los elementos que se utilizan para manipular los datos, son los siguientes:
– SELECT, esta sentencia se utiliza para realizar consultas sobre los datos.
– INSERT, con esta instrucción podemos insertar los valores en una base de datos.
– UPDATE, sirve para modificar los valores de uno o varios registros.
– DELETE, se utiliza para eliminar las filas de una tabla.
■ Todos estos lenguajes forman parte del lenguaje SQL en general. Es decir, no son aplicables a
PostgreSQL sino a todos los gestores de bases de datos
Componentes del DBMS: database access language (DDL, DML, DCL, TCL)

■ Lenguaje de Control de Datos (DCL)

■ Es un lenguaje que incluye una serie de comandos SQL. Como los anteriores, es
proporcionado por los sistemas gestores de bases de datos.
■ Sus siglas son DCL por su nombre en inglés, Data Control Language.
■ Estos comandos permiten al Administrador del sistema gestor de base de datos,
controlar el acceso a los objetos, es decir, podemos otorgar o denegar permisos a uno o
más roles para realizar determinadas tareas.
■ Los comandos para controlar los permisos son los siguientes:
– GRANT, permite otorgar permisos.
– REVOKE, elimina los permisos que previamente se han concedido.
■ DCL Es el control de acceso a una base de datos. Crear un control de que usuarios pueden
acceder a una base de datos y que usuarios no pueden.
Componentes del DBMS: atabase access language (DDL, DML, DCL, TCL)

■ TCL. Si queremos hacer una transaction para pasar una base datos de A a
B, controla que se haga o no se haga. En caso de quedarse a medias, no se
hace y se queda en A. Si la transacción es exitosa, pasará a B.
Users (DBA, desarrolladores, usuarios finales)
■ Control de Acceso
■ Seguridad: proteger los datos contra usuarios no autorizados
■ Comandos usados por el BDA o el propietario para conceder/revocar
permisos de acceso a los objetos de la BD.
Users (DBA, desarrolladores, usuarios finales)

■ Usuarios
■ Permite acceder a la base de datos, crear un esquema y manipular datos a
través de usuarios.
– CREATE USER nombre_usuario
– DROP USER nombre_usuario
■ Roles
■ Grupos de privilegios relacionados que se otorgan a usuarios
 Users (DBA, desarrolladores, usuarios finales)

■ Privilegios
■ sobre objetos: ■ de sistema:
– DELETE: borrar objeto o parte de él – ALTER ANY INDEX
– INDEX: crear un índice sobre el objeto – ALTER ANY SECUENCE
– INSERT: añadir registros en tablas o vistas – CREATE ANY TABLE
– SELECT: seleccionar registros en tablas, vistas – CREATE TABLE
– REFERENCES: crear claves ajenas a una tabla – CREATE USER
– UPDATE: actualizar registros de tablas o vistas – INSERT ANY TABLE
– ALTER: modificar la estructura de una tabla o – SELECT ANY TABLE
secuencia. – GRANT ANY PRIVILEGE
– DROP ANY VIEW
– ….
Users (DBA, desarrolladores, usuarios finales)
GRANT: Concesión de privilegios
■ Se utiliza para otorgar privilegios del sistema, roles o un privilegio sobre un
objeto a usuarios y/o roles.
■ GRANT {grant_system_privileges | grant_object_privileges} ;
REVOKE: Eliminación de privilegios
■ Se utiliza para revocar privilegios del sistema, roles o un privilegio sobre un
objeto de usuarios y/o roles
■ REVOKE {revoke_system_privileges |revoke_object_privileges} ;
Users (DBA, desarrolladores, usuarios finales)
■ Postgres: Usuarios, grupos y roles
■ Los usuarios, grupos y roles permiso para iniciar sesión de forma
predeterminada.
■ Las instrucciones CREATE USER y CREATE GROUP son en realidad alias de
la instrucción CREATE ROLE.
■ En otros sistemas de administración de bases de datos relacionales (RDBMS)
como Oracle, los usuarios y las son lo mismo en PostgreSQL, y la única
diferencia es que los usuarios tienen funciones son dos entidades diferentes.
■ En Oracle, no se puede utilizar un rol para iniciar sesión en la base de datos.
Los roles se utilizan solo para agrupar grants y otros roles. Este rol se puede
asignar a uno o más usuarios para otorgarles todos los permisos.
 Users (DBA, desarrolladores, usuarios finales)
■ Para crear un usuario de PostgreSQL, utilice la siguiente instrucción SQL:
■ CREATE USER myuser WITH PASSWORD 'secret_passwd';
■ También puede crear un usuario con la siguiente instrucción SQL:
■ CREATE ROLE myuser WITH LOGIN PASSWORD 'secret_passwd';
■ Ambas sentencias crean exactamente el mismo usuario. Este nuevo usuario no
tiene ningún permiso aparte de los permisos predeterminados disponibles para el
rol public.
■ Todos los nuevos usuarios y roles heredan los permisos del rol public
Esquema public y rol public
■ Cuando se crea una nueva base de datos, PostgreSQL crea de forma
predeterminada un esquema denominado public y concede acceso en este
esquema a un rol de backend denominado public.
■ A todos los usuarios y roles nuevos se les concede de forma predeterminada el rol
public y, por lo tanto, pueden crear objetos en el esquema public.
Users (DBA, desarrolladores, usuarios finales)
■ Crear roles de base de datos
■ Los permisos deben concederse a nivel de base de datos, esquema y objeto
de esquema.
■ Por ejemplo, si necesita conceder acceso a una tabla, también debe
asegurarse de que el rol tenga acceso a la base de datos y al esquema en
que existe la tabla. Si falta alguno de los permisos, el rol no puede acceder a
la tabla.
Sintonización del DBMS
El proceso de diseño de la BD.
Está muy influenciado por la evolución
de:
■ ƒLa Arquitectura de BD.
⇒ Marca las fases de la
metodología.
■ ƒLos Modelos de Datos
⇒ Marca los instrumentos para
llevar a cabo el diseño.
Sintonización del DBMS: Consideraciones de diseño de las DB
 Sintonización del DBMS: Consideraciones de diseño de las DB
Entradas. Salidas.
■ ƒ
Requisitos de información y objetivos. ■ Estructura lógica de datos.
– Entrevistas con los usuarios – Esquema conceptual
– Análisis de los documentos a generar – Esquema lógico en el modelo soportado
por el SGBD
– Objetivos de la organización.
– Vistas de usuario .
■ ƒ
Requisitos de procesos.
■ Estructura de almacenamiento.
– Características que deben cumplir las – Esquema interno con especificaciones
aplicaciones, físicas como
– por ej. Tiempo de respuesta. – particiones, definiciones de espacio,
■ ƒ
Especificaciones del SGBD índices, cluster..
– Modelo de datos soportado ■ ƒNormativa de explotación.
– Características de rendimiento, seguridad, – Confidencialidad, seguridad e integridad
lenguajes... para la BD.
■ ƒ
Configuración del equipo físico y del SO ■ ƒEspecificaciones para los programas.
– Influirán en el diseño físico y ajuste de la BD. – Características que no pueden ser
recogidas en el esquema.
Sintonización del DBMS

Integración DBD/SI
■ Realizado conjuntamente.
■ O
ƒ freciendo una visión única
del proceso
■ ƒCada vez más ⇒ Enfoque
hacia los datos.
 Sintonización del DBMS:
Fases de diseño de la BD.
1. ANÁLISIS DE REQUERIMIENTOS:
Captar los requisitos de información de los distintos grupos de
usuarios.
Información sobre el uso que se piensa dar a la BD.
Captar requerimientos operativos
→Transacciones (críticas y no críticas)
2. DISEÑO CONCEPTUAL :
Obtener una buena representación de los recursos de información
de la empresa, con independencia de usuarios o aplicaciones en
particular, y fuera de consideraciones sobre eficiencia del
ordenador.
3. DISEÑO LÓGICO:
Transformar el esquema conceptual obtenido en la etapa anterior,
adaptándolo al modelo de datos en el que se apoya el SGBD que
se va a utilizar .
4. DISEÑO FÍSICO :
Trata de conseguir una instrumentación lo más eficiente posible,
del esquema lógico
 Sintonización del DBMS: Consideraciones de diseño de las DB
Análisis de requerimientos
■ Es la etapa de percepción, identificación y descripción del ■ Método de captura de datos
mundo real a analizar.
– Entrevistas con los usuarios de
■ Se responde a la pregunta ¿ qué representar?. distintos niveles de la organización.
■ Es necesario identificar los usuarios y aplicaciones que van – Análisis de la documentación
a interactuar con el sistema. existente.
⇒ Identificación de usuarios responsables: – Estudio de las reglas de la empresa.
– Alta dirección. – Análisis de las transacciones y su
o ƒObjetivos y metas corporativas. frecuencia.
o ƒVisión de funciones importantes ⇒ Se obtienen especificaciones de
o ƒEvolución futura. requerimientos mal estructuradas e
o ƒEstablecer prioridades. informales que posteriormente se
– Mandos intermedios. formalizarán mediante técnicas de
o ƒObjetivos detallados. especificación de requerimientos (ERD
no refinados, DFD..)..
o ƒIdentificar usuarios intermedios
– Usuarios operacionales.
o ƒRequerimientos detallados.
o ƒProcedimientos.
o ƒInformes.
o ƒFormularios...
 Sintonización del DBMS: Consideraciones de diseño de las DB
■ Mala Práctica N° 1: Ignorar el Propósito de la Data
■ El diseñador de la base de datos debe saber de antemano qué representarán los datos, cómo se va a adquirir
y a qué velocidad, cuál será su volumen operativo y, finalmente, cómo se usará.
■ Los diseñadores deben tener consideraciones especiales para mantener la eficiencia y la usabilidad de la base
de datos si los volúmenes de datos van a ser grandes. El volumen no es el único aspecto a considerar ya que
también afecta el nivel de normalización, la estructura de datos, el tamaño del registro y la implementación
general de todo el sistema.

Mala Práctica N° 2: Mala Normalización

■ Diseñar una base de datos no es una tarea determinista; dos diseñadores
de bases de datos pueden seguir todas las reglas y principios de
normalización para un problema determinado y, en la mayoría de los
casos generarán diferentes diseños de datos.
■ Tenemos que tenerlo claro: cada base de datos debe, al menos,
normalizarse a la tercera forma normal ya que es el diseño que mejor
representará a sus entidades y cuyo rendimiento se equilibrará mejor
entre consultas e inserción-actualización-eliminación de registros.
 Sintonización del DBMS: Consideraciones de diseño de las DB
Mala Práctica N° 3: Redundancia
■ Los campos y tablas redundantes son una pesadilla para los desarrolladores ya que
requieren lógica de negocios para mantener actualizada gran parte de la misma
información. Esto es una sobrecarga que puede evitarse si las reglas de normalización se
siguen al pie de la letra.
■ Los efectos negativos típicos de la redundancia son un aumento innecesario del tamaño de
la base de datos, los datos son propensos a la inconsistencia y disminuye la eficiencia de la
base de datos pero—más importante—podría llevar a una corrupción en la data.
Mala Práctica No. 4: Integridad Referencial Mala (Restricciones)
■ La integridad referencial es una de las herramientas más valiosas que proporcionan los
motores de base de datos para mantener la calidad de los datos en su mejor forma.
■ Si no se implementan restricciones o muy pocas restricciones desde la etapa de diseño, la
integridad de los datos tendrá que depender totalmente de la lógica de negocios, lo que la
hace susceptible a errores humanos.
 Sintonización del DBMS: Consideraciones de diseño de las DB
Mala Práctica N° 5: No Aprovechar las Características del Motor de Base de Datos
■ Un Motor de Base de Datos proporciona servicios como:
– Vistas que proporcionan una manera rápida y eficiente de ver tus datos,
– Índices que ayudan a acelerar las consultas en las tablas.
– Funciones agregadas que ayudan a analizar información sin programación.
– Transacciones o bloques de oraciones que alteran los datos que se ejecutan y comprometen o cancelan
(retrotraen) si ocurre algo inesperado.
– Bloqueos que mantienen los datos seguros y correctos mientras se ejecutan las transacciones.
– Procedimientos almacenados que proporcionan funciones de programación para permitir tareas
complejas de administración de datos.
– Funciones que permiten cálculos sofisticados y transformaciones de datos.
– Restricciones que ayudan a garantizar la exactitud de los datos y evitar errores.
– Disparadores que ayudan a automatizar las acciones cuando ocurren eventos en los datos.
– Comando optimizador (planificador de ejecución) que se ejecuta bajo el capó, asegurando que cada
frase se ejecuta en su mejor momento y manteniendo los planes de ejecución para futuras ocasiones.
■ No conocer o ignorar estas capacidades llevará el desarrollo a un camino extremadamente incierto y
seguramente a errores y problemas futuros.
 Sintonización del DBMS: Consideraciones de diseño de las DB
Mala Práctica N° 6: Claves Primarias Compuestas
■ Se debe tener en cuenta que si esperas que tu tabla con una clave
primaria compuesta tenga millones de filas, el índice que controla
la clave compuesta puede crecer hasta un punto en el que el
rendimiento de la operación CRUD está muy degradado.

Mala Práctica N° 7: Mala Indexación

■ A medida que la tabla crezca, notarás que los SELECT en estas columnas se ralentizan. Si la tabla es lo
suficientemente grande, pensarás lógicamente, en crear un índice en cada columna que uses para acceder a
esta tabla pero notarás casi de inmediato que el rendimiento de los SELECT mejora, pero INSERT, UPDATE y
DELETE caen.
■ Esto por supuesto se debe al hecho de que los índices deben mantenerse sincronizados con la tabla, lo que
significa una sobrecarga masiva para el Motor de Base de Datos
■ Además, la eficiencia del índice depende a veces del tipo de columna; los índices en columnas INT muestran el
mejor rendimiento posible pero los índices en VARCHAR, DATE no son tan eficientes.
■ Por lo tanto, la indexación es siempre una decisión delicada ya que demasiada indexación puede ser tan mala
como muy poca y porque el tipo de datos de las columnas a indexar tiene una gran influencia en el resultado
final.
 Sintonización del DBMS: Disponibilidad de recursos
■ Base de Datos: colección organizada de datos, relativa a un problema concreto, que puede ser
compartida por un conjunto de usuarios/aplicaciones..

• Optimización en la gestión de la
información.
• Flexibilidad de adaptación a cada problema.
• Control de la integridad de los datos.
• Independencia física y lógica de los datos.
• Garantía sobre la consistencia de la
información.
• Facilidad de acceso concurrente.
Sistema Gestor de Bases de • Seguridad ante accesos restringidos.
Datos: programa o conjunto de
programas que sirve para • Protección ante fallos del sistema.
mantener bases de datos y
responder consultas sobre ellas
Sintonización del DBMS: Disponibilidad de recursos
■ .
Sintonización del DBMS:
Disponibilidad de recursos
■ .
Sintonización del DBMS
■ .
 Sintonización del DBMS: Calendarización de procesos
Proceso:
■ El programa necesita una serie de recursos para su ejecución:
– Tiempo de la CPU.
– Memoria.
■ Con el contenido del programa.
■ Pila para datos temporales.
■ Sección de datos con variables globales.
■ Acceso a archivos y dispositivos E/S..
■ Los procesos tienen un carácter secuencial:
o Un proceso en su ejecución puede generar más de un proceso (llamada fork).
o Dos procesos pueden asociarse al mismo programa.
■ Proceso: Unidad de trabajo del sistema.
■ Procesos de usuario y procesos del sistema.
■ El sistema operativo se encargará de:
– La creación y eliminación de procesos.
– La planificación de procesos.
– La sincronización, comunicación y manejo de bloqueos mutuos entre procesos
 Sintonización del DBMS: Calendarización de procesos
Bloque de control del proceso (PCB).
■ En el S.O.: Un proceso se representa por: Un
Bloque de Control del Proceso (PCB).
■ Se utiliza para poder ejecutar procesos
concurrentes: hay un cambio de contexto
■ Es un conjunto de registros que almacena
información sobre el proceso:
o Estado del proceso: Nuevo, Listo, en Ejecución, Bloqueado.
o Contador del programa: Dirección siguiente instrucción a ejecutar .
o Registros de la CPU: Contenidos al final de la ultima ejecución (contador de
programa, puntero a pila, registros de datos, etc.).
o Información planificación CPU: prioridad, apuntadores a las colas, algoritmo usado.
o Información contable y de identificación: Número de proceso, tiempo real y de CPU
utilizado.
o Información estado E/S: Solicitudes E/S pendientes, lista archivos abiertos, etc.
Sintonización del DBMS: Administración de la concurrencia

■ .
Sintonización del DBMS: Administración de la concurrencia
Concepto de hilo de ejecución: thread.
■ 1) Varios procesos pueden cooperar para resolver una misma tarea. Tendremos
ejecución concurrente entre procesos comunicados por memoria
■ 2) Un programa podría realizar actividades concurrentes (paralelismo dentro del
proceso). Tendremos: Ejecución concurrente de varios “hilos” dentro de un proceso.
■ Cada hilo, thread o proceso ligero tiene su propio:
– Contador de programa, pila, registros y estado del proceso ligero
■ Los procesos ligeros de un mismo proceso comparten la información del proceso:
– Espacio de memoria, Variables globales, Archivos abiertos, Procesos hijos,
Temporizadores, Señales y semáforos, Contabilidad
■ Si hay dos procesos listos para ejecución ...
– ¿ Cual se ejecutará primero?
■ El planificador (scheduler) del sistema operativo decide cual
Sintonización del DBMS: Administración de la concurrencia
El planificador utiliza ŸAlgoritmo de
planificación.
■ Un ejemplo de planificación de
procesos: P 0 y P1 listos.

■ Una manera sencilla de planificación,

sin multiprogramación

■ Planificación con multiprogramación..

Sintonización del DBMS: Administración de la concurrencia
Colas de planificación:
■ El S.O. usa una serie de colas para planificar los recursos
– Cola de trabajos: Procesos en almacenamiento
secundario esperando memoria principal.
– Cola de procesos listos: Procesos en memoria principal,
listo y esperando su ejecución (una lista ligada).
– Cola de dispositivos: Para cada dispositivo (disco,
impresora, etc.) hay una cola de procesos esperando
utilizarlo.
■ Se usan los PCB como elementos de las colas:
■ Un proceso cambia de cola a lo largo de su ejecución.
■ Planificador:
– Elemento del sistema operativo que selecciona
procesos en esas colas.
■ En lo que a ejecución de procesos respecta:
– Planificador a largo plazo (planificador de trabajos).
– Planificador a corto plazo (planificador de la CPU).
Sintonización del DBMS: Administración de la concurrencia
Planificador de trabajos:
■ Necesidad: Si hay muchos procesos ... algunos en almacenamiento secundario.
■ Cometido: Se encarga del intercambio entre memoria y almacenamiento secundario.
Controla el número de procesos en memoria (grado de multiprogramación).
■ Frecuencia: Se ejecuta con menor frecuencia que el planificador CPU (cuando termina un
proceso, etc.) ... puede ser más lento
■ Eficiencia: Buena mezcla en memoria entre procesos limitados por la CPU y por E/S
■ Ejecución de un proceso: Ciclo de ráfagas CPU y E/S:
– En la ejecución de un proceso se alternan la ejecución en CPU y la espera de E/S.
o Ráfaga CPU: Tiempo de ejecución en CPU entre dos E/S.
o Ráfaga E/S: Tiempo entre solicitud y terminación de E/S.
■ Ejemplo gráfico de ejecución de proceso.
Sintonización del DBMS: Administración de la concurrencia

■ .
Sintonización del DBMS: Administración de la concurrencia

■ Ejemplo FIFO.

■ Round Robin
 Sintonización del DBMS: Administración del overhead
■ Puede argumentarse que los DBMSs no fueron originalmente concebidos para el desarrollo
de aplicaciones, pero los productos humanos “se convierten, en amplia medida, en
independientes de sus artífices”, evolucionan con vida propia, y son fértiles en el sentido
que podemos aprender de ellos y darles usos que no estaban presentes en las intenciones
de sus creadores.
■ Esto ya ha sucedido con los DBMSs, y también se ha predicho que podrían especializarse
en los próximos años para cumplir propósitos específicos, liberándose de todo el overhead
propio de una solución genérica
■ Existen situaciones donde no vale la pena usar una base de datos. Los costos de inversión
en hardware y software, tener personal especializado, la generalidad de un DBMS, y todo lo
que implica generan overhead que hacen que no valga la pena tener una DB en sistemas
simples cuya estructura de datos no cambia en el tiempo. Sistemas real-time donde la
performance es todo, sistemas embebidos con poca memoria o donde no interesa que
muchas personas accedan a los datos a la misma vez. .
 Sintonización del DBMS: Administración del overhead
Indices
■ El uso de un índice implica:
– Overhead debido a la actualización
de los mismos
– Espacio adicional en disco
– Procesos batch de muchos datos
pueden volverse demasiado lentos
– Manipulación de archivos
adicionales por el sistema
operativo
Sintonización del DBMS: Administración del overhead
Sección Debugging
■ Bajo este grupo de preferences se incluyen aquellas que permiten facilitar la identificación
de problemas tanto en la lógica de aplicaciones como en el código generado.
■ Esta opción de configuración permite controlar si programas generados incluyen o no
mensajes que faciliten la identificación de errores de programación o generación.
■ El valor por defecto es No.
■ El habilitar esta preference (ponerla en Yes) implica un importante overhead en tiempo de
ejecución de los programas generados a partir del momento de su habilitación
Sintonización del DBMS: Administración del overhead
Deadlock
■ Se da cuando una o mas transacciones esperan por otras. Podemos determinar si hay un
deadlock construyendo un grafo de espera. Si encontramos un ciclo... encontramos un
deadlock!!
■ Mantener un grafo de espera y si hay un ciclo, seleccionar una victima para que aborte.
Utilizado para transacciones pequeñas. Si estas fuesen largas o trabajan sobre muchos
items se genera mucho overhead y la prevención es mejor.
Granularidad
■ Que es un ítem? Este puede ser una tupla, un valor de una tupla, una tabla entera o incluso
al base de datos completa!
■ Cuanto mayor es el grado de granularidad, menor es el nivel de concurrencia permitido.
■ Sin embargo, cuanto menor el grado de granularidad, mayor va a ser el overhead que e le
impone a l sistema.
■ Si las transacciones acceden a pocos registros es mejor una baja granularidad, si las
transacciones acceden a tablas enteras, es mejor una granularidad alta
 Sintonización del DBMS: Administración del overhead
Formato de una Página:
■ Overhead: Formado por 3 zonas:
– Common and Variable Header: Información general, como la dirección de la página, el tipo de
segmento al que pertenece (de datos, de índice, de rollback...).
– Table Directory: Información sobre las tablas con filas en esta página.
– Row Directory: Información sobre las filas almacenadas en esta página.
o Al borrar una fila, su información en este directorio no es liberado.
Ese espacio se vuelve a usar al insertar una nueva fila en la página.

■ Row Data: Zona con datos de tablas o índices. Una fila puede estar en varias páginas.

■ Free Space: Espacio libre para insertar nuevas filas (INSERT) o nuevos valores en las filas ya
existentes (UPDATE), si requieren más espacio.
– Transaction entries: También se guarda aquí información sobre las transacciones (INSERT,
UPDATE y DELETE) sobre las filas de esta página. Se controla con dos valores que no es
recomendable modificar:
o INITRANS: Número inicial de entradas para las transacciones de esta página.
o MAXTRANS: Máximo número de transacciones concurrentes para esta página.
– Si el número de transacciones concurrentes supera INITRANS, Oracle guarda la información
dinámicamente hasta que se excede MAXTRANS o hasta que no haya espacio libre en la página.
 Sintonización del DBMS: Diseño de interfaces I/O
ODBC
■ Es un estándar de acceso a las bases de datos desarrollado por SQL Access Group en 1992.
■ El objetivo de ODBC es hacer posible el acceder a cualquier dato desde cualquier aplicación, sin importar qué
sistema de gestión de bases de datos (DBMS) almacene los datos.
■ ODBC logra esto al insertar una capa intermedia (CLI) denominada nivel de Interfaz de Cliente SQL, entre la
aplicación y el DBMS.
■ El propósito de esta capa es traducir las consultas de datos de la aplicación en comandos que el DBMS
entienda. Para que esto funcione tanto la aplicación como el DBMS deben ser compatibles con ODBC, esto es
que la aplicación debe ser capaz de producir comandos ODBC y el DBMS debe ser capaz de responder a ellos.
■ Desde la versión 2.0 el estándar soporta SAG y SQL.
■ El software funciona de dos modos, con un software manejador en el cliente, o una filosofía cliente-servidor.
■ En el primer modo, el driver interpreta las conexiones y llamadas SQL y las traduce desde el API ODBC hacia el
DBMS.
■ En el segundo modo para conectarse a la base de datos se crea una DSN dentro del ODBC que define los
parámetros, ruta y características de la conexión según los datos que solicite el creador o fabricante.
Sintonización del DBMS: Diseño de interfaces I/O
■ .
 Sintonización del DBMS: Diseño de interfaces I/O
REQUERIMIENTOS
■ En el caso de los DBMSs, cada uno utiliza un Data Provider para acceder a la base de datos, cada DBMS tiene
su propio Data Provider para acceso [Link].
■ Por el momento los DBMSs que soportan el acceso [Link] son: SQL Server, Oracle, DB2 Universal
Database y DB2 UDB for iSeries. Los requerimientos necesarios en cada caso son:
■ SQL Server: [Link] utiliza el Data Provider de Microsoft para SQL Server
■ Oracle: Se debe tener el Cliente de Oracle versión 8.1.7 o superior, de esta forma se instala el Data Provider
correspondiente. El valor “Server Name” de las Dbms option hace referencia al Service Name definido en la
instancia del Oracle.
■ DB2 UDB for iSeries Se necesita la V5R3 del iSeries Access, que es una versión beta y está solo en inglés.
Además cuando se crea un modelo se debe copiar la dll IBM.
– El Data provider para DB2 UDB for iSeries no soporta BLOBs por ahora.
– Una limitación del driver client acces V5 R3 no permite el llamado objetos remotos en el Iseries (RPC).
Esto implica store procedures u objetos externos en el Iseries
■ DB2 Universal Database Se necesita tener instalada la versión 8.1.3 o superior. La dll es [Link],
también se debe copiar a los directorios gxnet/bin si la aplicación es web o gxnetwin/bin win.
 Sintonización del DBMS: Diseño de interfaces I/O
JDBC
■ Java proporciona una plataforma completa, flexible y segura para el desarrollo de aplicaciones,
incluyendo la conectividad con una base de datos. Esta conectividad o acceso a base de datos
relacionales con Java es posible gracias a la API JDBC (Java DataBase Connectivity).
■ Este API es parte de la plataforma Java desde la versión 1.0 de JDK. Con el paso del tiempo se
ha ido mejorando y aumentando su funcionalidad.
■ JDBC es ODBC extendido para toda la plataforma Java. Mientras que ODBC es una interfaz
escrita en lenguaje C, que tiene que ser instalado manualmente en cada maquina, JDBC, al
estar escrito en Java, posee todas las propiedades y ventajas del mismo.
■ El API JDBC puede definirse como un conjunto de clases, métodos e interfaces escritos en
lenguaje Java, que permiten el acceso a sistemas de bases de datos relacionales utilizando
instrucciones SQL.
■ ¿ que necesitamos ?
– - El API JDBC con dos paquetes principale, [Link] y [Link]
– - Un controlador de acceso a una base de datos
 Sintonización del DBMS: Diseño de interfaces I/O
■ El controlador servirá para conectar la aplicación con la API JDBC, proporcionando
comunicación con la base de datos.
■ En definitiva, lo que el estándar JDBC hace posible es:
– Establecer una conexión.
– Lanzar sentencias SQL.
– Capturar conjuntos resultado (resulset) de las consultas.
– Capturar información de la base de datos.
– Manipular los datos.

■ Puesto que JDBC está implementado en

Java, posee la ventaja de ser independiente
de la plataforma e independiente de la base
de datos.
■ En esencia, podrá ejecutarse en cualquier
sistema que posea una Máquina Virtual de
Java.
 Sintonización del DBMS: Diseño de interfaces I/O
Extensiones nativas
■ PHP
– soporta más de 15 sistemas gestores de bases de datos: SQLite, Oracle, SQL Server,
PostgreSQL, IBM DB2, MySQL, etc.
– Hasta la versión 5 de PHP, el acceso a las bases de datos se hacía principalmente utilizando
extensiones específicas para cada sistema gestor de base de datos (extensiones nativas).
– Es decir, que si queríamos acceder a una base de datos de PostgreSQL, deberíamos instalar y
utilizar la extensión de ese gestor en concreto. Las funciones y objetos a utilizar eran distintos
para cada extensión.
– A partir de la versión 5 de PHP se introdujo en el lenguaje una extensión para acceder de una
forma común a distintos sistemas gestores: PDO.
– PDO ofrece un conjunto común de funciones, las extensiones nativas normalmente ofrecen más
potencia (acceso a funciones específicas de cada gestor de base de datos) y en algunos casos
también mayor velocidad.
■ SQL Server Native Client
– Conocido también como SNAC (o SQLNCLI), se incluyó con SQL Server entre sus versiones
2005 y 2012. Incorpora todo lo necesario para poder hacer acceso a datos con SQL Server tanto
con ODBC (segunda generación) como con OLEDB (segunda generación también).
– A partir de SQL Server 2012 se declaró como obsoleto aunque, si no tienes que sacar partido a
las nuevas características del gestor, podrías seguir utilizándolo, pero no es recomendable.
Integraciones y seguridades: Backups y restores
■ El backup y la recuperación son el proceso de creación y almacenamiento de copias de
datos que se pueden utilizar para proteger a las organizaciones contra pérdidas de datos. A
esto se le conoce a veces como recuperación operativa.
■ Para recuperar un backup es necesario restaurar los datos en la ubicación original o en una
ubicación alternativa, donde se podrán utilizar en lugar de los datos perdidos o dañados.
■ Una copia de seguridad correcta se almacena en un sistema o medio separado, como una
cinta, de los datos primarios para protegerlos contra la posibilidad de pérdida de datos
debido a un fallo del hardware o software primario.
■ Para conseguir un funcionamiento seguro de la BD y una pronta recuperación ante fallos se
necesita planear una estrategia de copias de seguridad, backup, y de recuperación,
recovery, ya que de nada sirve pensar que estamos a salvo de tales circunstancias, y que
eso no me puede pasar a mí.
■ El primer paso a dar es definir las características fundamentales de la implantación, porque
mal vamos a conseguir unos objetivos si se desconocen o están indefinidos.
■ El segundo paso es establecer unos planes de copias de seguridad y recuperación que nos
permitan asegurar los objetivos.
 Integraciones y seguridades: Backups y restores
■ Por qué realizar copias de seguridad
■ Con las copias de seguridad válidas de una base de datos puede recuperar los datos en caso de que se
produzcan errores, por ejemplo:
– Errores de medios.
– Errores de usuario, por ejemplo, quitar una tabla por error.
– Errores de hardware, por ejemplo, una unidad de disco dañada o la pérdida permanente de un servidor.
– Desastres naturales. .
■ Las copias de seguridad de una base de datos son útiles para fines administrativos habituales, como copiar una
base de datos de un servidor a otro, configurar Grupos de disponibilidad AlwaysOn o la creación de reflejo de la
base de datos y el archivo.
■ De entre todas estas posibilidades, el DBA sólo puede influir y prever los errores de funcionamiento, ya que el
resto habitualmente no está dentro de sus responsabilidades y capacidades.
■ Dada la complejidad de los sistemas actuales y las necesidades cada vez más críticas en la disponibilidad de los
sistemas, donde una BD caida puede causar pérdidas millonarias, puede ser interesante considerar los
mecanismos de protección hardware y de redundancia que la tecnología nos proporciona:
– UPS o fuentes de corriente ininterrumpida,
– espejado de disco, o tecnología RAID,
– Componentes duplicados,
– Sistemas redundantes.
 Integraciones y seguridades: Backups y restores
■ Errores de Usuario: Como por ejemplo un usuario borrando una fila o eliminando una tabla. Estos errores se
solucionan importando una tabla de una copia lógica anterior. Si no se dispone de la copia lógica, se puede
recuperar la BD en una instancia auxiliar, exportar la tabla en cuestión de la instancia auxiliar e importarla en la
instancia operativa.
■ Fallos de Sentencias: Se definen como la imposibilidad del SGBD de ejecutar alguna sentencia SQL. Un ejemplo
de esto se produce cuando se intenta una selección de una tabla que no existe. Estos fallos se recuperan
automáticamente mediante un rollback de la transacción que contenía la sentencia fallida. El usuario necesitará
volver a ejecutar otra vez la transacción cuando se haya solucionado la causa del problema.
■ Fallos de Procesos: Es una terminación anormal de un proceso. Si el proceso era alguno de los de background, la
instancia debe de ser parada y arrancada de nuevo, proceso durante el cual se recupera la caida efectuando un roll
forward y un rollback de las transacciones no confirmadas.
■ Fallos de la Red: Algunas veces los fallos en la red producen fallos de proceso. Si en el error de red se ve envuelta
una transacción distribuida, una vez que se reestablece la conexión, el proceso resuelve los conflictos
automáticamente.
■ Fallos de Instancia: Pueden deberse a fallos físicos o de diseño del software que hacen que algún proceso
background caiga y la instancia con él. La recuperación es automática cuando se levanta la BD, tomandose más o
menos tiempo en la recuperación.
■ Fallos del Sistema: Son los fallos más peligrosos, no sólo porque se pueden perder datos, sino porque se tarda
más tiempo en recuperar que los otros fallos. Además se depende mucho de la experiencia del DBA para levantar la
BD rápidamente y sin pédida (o casi) de datos.
 Integraciones y seguridades: Backups y restores
■ Presentación del Backup Los backups se pueden clasificar en físicos y lógicos.
– Los físicos se realizan cuando se copian los ficheros que soportan la BD. Entre estos se encuentran los backups
del SO, los backups en frío y los backups en caliente.
– Los backups lógicos sólo extraen los datos de las tablas utilizando comandos SQL y se realizan con la utilidad
export/import.
■ Backups del SO Cconsume mucho tiempo y hace inaccesible al sistema mientras se lleva a cabo. Aprovecha el backup
del SO para almacenar también todos los ficheros de la BD. Los pasos de este tipo de backup son los siguientes:
– Parar la BD y el SO
– Arrancar en modo superusuario.
– Realizar copia de todos los ficheros del sistema de ficheros
– Arrancar el sistema en modo normal y luego la BD.
■ Backups de la BD en Frio: Implican parar la BD en modo normal y copiar todos los ficheros sobre los que se asienta.
Antes de parar la BD hay que parar también todos las aplicaciones que estén trabajando con la BD. Una vez realizada la
copia de los ficheros, la BD se puede volver a arrancar.
■ Backups de la BD en Caliente: Se realiza mientras la BD está abierta y funcionando. Habrá que tener cuidado de
realizarlo cuando la carga de la BD sea pequeña.
■ Backups Lógicos con Export/Import: Permiten al DBA hacer copias de determinados objetos de la BD, así como
restaurarlos o moverlos de una BD a otra.
■ Una vez que se ha planeado una estrategia de backup y se ha probado, conviene automatizarla para facilitar así su
cumplimiento.
Integraciones y seguridades: Backups y restores
Principios de Backup
■ Un backup válido es una copia de la información sobre la BD necesaria para reconstruir la
BD a partir de un estado no utilizable de la misma.
■ Normalmente, si la estrategia de backup se basa en la copia de los ficheros de datos, se
han de tener copias de los ficheros de datos, de los ficheros de control y también de los
archivados.
Diseño de la BD y Reglas Básicas de Backup
■ Los ficheros copias no deben estar en el mismo dispositivo que los originales.
■ No siempre hay que pasar las copias a cinta, ya que si se dejan en disco se acelera la
recuperación. Además, si se copian las copias a cinta y se mantienen en el disco, se puede
sobrevivir a diversos fallos de dispositivo.
■ Se deberían mantener diferentes copias de los ficheros de control, colocadas en diferentes
discos con diferentes controladores.
■ Siempre que la estructura de la BD cambie debido a la inclusión, borrado o renombrado de
un fichero de datos, se debe copiar el fichero de control, ya que almacenan la estructura de
la BD. Además, cada fichero añadido también debe ser copiado.
■ Teniendo en cuenta las reglas anteriores, los siguientes puntos pueden considerarse un
ejemplo de estrategia de backup
Integraciones y seguridades: Rollback
■ ¿Qué es un ROLLBACK en SQL?
■ La cláusula ROLLBACK es una herramienta fundamental en el manejo de transacciones en
bases de datos SQL.
■ En términos simples, ROLLBACK es una operación que deshace las transacciones no
confirmadas en la base de datos, es decir, revierte cualquier cambio que se haya realizado
en la base de datos dentro de una transacción.
■ Es importante destacar que las transacciones son una serie de operaciones que se realizan
como una única unidad lógica y que, si una de ellas falla, todas las demás se deben
deshacer para mantener la integridad de la base de datos.
■ En este punto es donde entra en juego la cláusula ROLLBACK, la cual permite revertir
todos los cambios realizados en una transacción que no haya sido confirmada.
■ Se debe realizar cuando una transacción aborta o no termina por una falla.
■ Es la recuperación de todos los BFIM’s de los ítems que modificó esa transacción y de
todas las transacciones que leyeron de la que abortó. (Abortos en Cascada)
■ Lo Rollbacks en Cascada pueden consumir mucho tiempo por lo que deben evitarse
garantizando historias EAC o estrictas
Integraciones y seguridades: Rollback
■ Algunas de las funciones más importantes que cumple la cláusula ROLLBACK en SQL son:
■ Manejo de errores: Cuando se ejecuta una transacción en una base de datos, es posible
que se presenten errores que impidan su finalización. En este caso, ROLLBACK permite
revertir cualquier cambio realizado y asegurar la integridad de la base de datos.
■ Control de la concurrencia: En bases de datos que permiten el acceso concurrente de
varios usuarios, es posible que se presenten conflictos de acceso a los datos. En este caso,
ROLLBACK permite deshacer las transacciones que generan conflictos y mantener la
coherencia de los datos.
■ Control de la integridad referencial: En bases de datos que cuentan con relaciones entre
tablas, es posible que se presenten errores de integridad referencial al realizar cambios en
los datos. En este caso, ROLLBACK permite deshacer los cambios y mantener la
coherencia de los datos.
■ Es importante destacar que ROLLBACK debe utilizarse con precaución, ya que una vez que
se ejecuta esta operación, no es posible recuperar los cambios realizados. Por lo tanto, se
recomienda realizar pruebas exhaustivas antes de confirmar una transacción y, en caso de
presentarse errores, utilizar la cláusula ROLLBACK para deshacer los cambios realizados
■ .
Integraciones y seguridades: Rollback
Algoritmos de Recuperación
■ Cualquier algoritmo de recuperación debería implementar las siguientes operaciones o
procedimientos:
– Recuperación: Indica cual es la estrategia general de recuperación
– Undo: Indica cómo se debe hacer el undo de una operación.
– Redo: Indica como se debe hacer el redo de una operación.
■ Es fundamental que la operación de Redo sea idempotente.
■ En general, se asume que se están generando historias estrictas y serializables.
■ Idea Básica: Demorar la escritura de la base en el disco hasta que la transacción alcance el
commit.
■ Para esto, durante la ejecución la actualización se realiza en el Log y en los buffers o en un
área local a la transacción.
– El protocolo tiene dos reglas básicas:
– Los cambios realizados por una transacción T nunca son grabados en el disco hasta
que la T alcanza el commit.
– Una transacción T nunca puede alcanzar el commit hasta que grabó todas sus
operaciones de actualización en el Log y el log fue grabado en el disco
 Integraciones y seguridades: Rollback
■ ¿Qué es COMMIT en SQL?
■ La cláusula COMMIT se utiliza en SQL para confirmar las transacciones pendientes y hacer
que los cambios realizados en la base de datos sean permanentes.
■ En otras palabras, COMMIT confirma que la transacción se ha completado correctamente y
que los cambios deben ser guardados en la base de datos.
■ Es importante utilizar COMMIT para asegurarse de que los cambios realizados en la base
de datos sean permanentes y no se pierdan en caso de un error.
■ La instrucción commit señala el final con éxito de una transacción, informa al DBMS que la
transacción ha finalizado, que todas sus instrucciones se han ejecutado y que la base de
datos se encuentra de nuevo en un estado consistente.
■ Commit garantiza que todas las modificaciones llevadas a cabo por la transacción se hacen
permanentes en la base de datos. También libera los recursos, como aquellos para
garantizar el aislamiento, usados por la transacción.
■ La instrucción commit le dice al gestor de transacciones que se ha finalizado con éxito una
unidad lógica de trabajo, que la base de datos está (o debería estar) de nuevo en un estado
consistente y que se pueden hacer permanentes todas las modificaciones efectuadas por
esa unidad de trabajo
Integraciones y seguridades: Rollback
■ Conclusion
■ En conclusión, ROLLBACK y COMMIT son cláusulas importantes en SQL
que permiten el manejo de transacciones en bases de datos.
■ ROLLBACK se utiliza para deshacer una transacción en caso de que se
produzca un error o se necesite revertir una operación.
■ COMMIT se utiliza para confirmar una transacción y hacer permanentes los
cambios realizados.
■ Es importante entender cómo y cuándo utilizar estas cláusulas para
garantizar la integridad y consistencia de los datos en la base de datos.
■ En resumen, ROLLBACK y COMMIT son cláusulas fundamentales en el
manejo de transacciones en bases de datos y su correcto uso puede evitar
errores y garantizar la integridad de los datos.
Integraciones y seguridades: Puntos de control
■ SAVEPOINT:
■ Es un punto de guardado en las transacciones SQL define una ubicación a la que una
transacción puede regresar si parte de la transacción se cancela condicionalmente.
■ Por ejemplo, si ocurre algún desastre después de ese punto, o cualquier comando de
reversión ejecutado no elimina los datos antes del punto de guardado de la transacción SQL
■ Un punto de recuperación, del inglés savepoint, es una forma de implementar
subtransacciones (también conocidas como transacciones anidadas) dentro de un sistema
gestor de base de datos relacional indicando un punto dentro de una transacción de base
de datos que puede ser restaurada sin afectar a cualquier trabajo realizado en la
transacción antes de que el punto de recuperación fuera creado.
■ Pueden existir varios puntos de recuperación dentro de una transacción individual.
■ Los puntos de recuperación son útiles para implementar la recuperación ante errores
complejos en aplicaciones de base de datos.
 Integraciones y seguridades: Puntos de control
■ Si ocurre un error en medio de una transacción compuesta por múltiples
sentencias, la aplicación puede ser capaz de recuperarse del error revirtiendo la
transacción hasta un punto de recuperación anterior sin necesidad de abortar la
transacción completa.
■ Un punto de recuperación puede estar declarado emitiendo una
sentencia SAVEPOINT name.
■ Todos los cambios realizados después de que un punto de recuperación haya sido
declarado pueden ser deshechos emitiendo una sentencia ROLLBACK TO
SAVEPOINT name.
■ Emitiendo RELEASE SAVEPOINT name causará que el punto de recuperación
concreto sea descartado, pero no afectará a nada más.
■ Emitiendo los comandos ROLLBACK o COMMIT también descartará cualesquiera
puntos de recuperación creados desde el inicio de la transacción principal.
■ Los puntos de recuperación son implementados de una u otra forma en sistemas
de bases de datos tales como PostgreSQL, Oracle, Microsoft SQL
Server, MySQL, DB2, y Firebird. Los puntos de recuperación están también
definidos en el estándar SQL..
Integraciones y seguridades: Puntos de control

■ .
 Unidad 3
BASES DE DATOS DISTRIBUIDAS
** Clasificación
■ Una Base de Datos Distribuida, la podemos entender como una base de datos tradicional,
dividida en diferentes partes físicamente dispersas y que se acceden de forma lógica, tal
como se accede a una base de datos centralizada por medio de un Sistema de
Administración de Bases de Datos.
■ En un sistema de manejo de base de datos distribuido la base de datos se almacena en
diversas computadoras, denominados sitios o nodos, comunicados entre si.
■ Características
– Los nodos están en equipos que no comparten memoria ni disco y se conectan por la
red.
– Los nodos generalmente se ubican geográficamente separados.
– Las computadoras pueden variar en tamaño y función.
– Las transacciones pueden acceder a datos que está físicamente en sitios distintos.
Clasificación

■ .
Clasificación
Arquitectura de los Sistemas de Bases de Datos Distribuidas
La arquitectura está influenciada en por el sistema informático subyacente en el que se ejecuta,
en particular por aspectos de la arquitectura de la computadora como la conexión en red, el
paralelismo y la distribución
■ La conexión en red de varias computadoras permite que algunas tareas se ejecuten en un
sistema servidor y que otras ejecuten en los sistemas clientes. Esta división de trabajo ha
conducido al desarrollo de sistemas de bases de datos cliente-servidor.
■ El procesamiento paralelo dentro de una computadora permite acelerar las transacciones
unas respuestas más rápidas, así como la capacidad de ejecutar más transacciones por
segundo. Las consultas pueden procesarse de manera que se explote el paralelismo
ofrecido por el sistema informático subyacente.
■ La distribución de datos permite que los datos residan donde han sido generados, pero
continuar siendo accesibles desde otros lugares diferentes.
■ El hecho de guardar copias de la base de datos en diferentes sitios permite que puedan
continuar las operaciones sobre la base de datos, aunque algún sitio sea afectado por
cualquier desastre natural.
Clasificación
Ventajas
■ Los datos son localizados en un lugar más cercano, por tanto, el acceso es más rápido.
■ El procesamiento es rápido debido a que varios nodos intervienen en el procesamiento de
una carga de trabajo.
■ La comunicación entre nodos se mejora, los costos de operación se reducen, son amigables
al usuario, la probabilidad que una falla en un nodo afecte al sistema es baja y existe una
autonomía entre los nodos.
■ Los datos se pueden colocar físicamente en el lugar donde se accedan más frecuentemente,
haciendo que los usuarios tengan control local de los datos con los que interactúan.
■ Las bases de datos distribuidas pueden presentar cierto grado de tolerancia a fallas haciendo
que el funcionamiento del sistema no dependa de un solo lugar como en el caso de las
bases de datos centralizadas.
■ Muchas de estas aplicaciones están distribuidas naturalmente en diferentes lugares.
■ Mayor fiabilidad y disponibilidad
■ Mejor rendimiento.
Clasificación
Desventajas
■ Se refiere al control y manejo de los datos. Dado que éstos residen en muchos nodos
diferentes y se pueden consultar por nodos diversos de la red, la probabilidad de
violaciones de seguridad es creciente si no se toman las precauciones debidas.
■ Asegurar la integridad de la información en presencia de fallas no predecibles, tanto de
componentes de hardware como de software, es compleja.
■ Dado que los datos pueden estar replicados, el control de concurrencia y los
mecanismos de recuperación son mucho más complejos que en un sistema
centralizado.
■ La distribución produce un aumento en la complejidad del diseño y en la
implementación del sistema.
 Clasificación: Homogéneas
Clasificación
■ Desde el punto de vista funcional y de organización de datos, están divididos en dos clases
separadas, basadas en dos filosofías totalmente diferentes y diseñados para satisfacer
diferentes necesidades:
– Bases de datos distribuidas homogéneas:
■ El mismo software/esquema en todos los sitios, los datos son
particionados/replicados entre los sitios.
■ Objetivo: proveer la vista de una sola base de datos ocultando detalles de
distribución.
– Bases de datos distribuidas heterogéneas:
■ Diferentes software/esquema en los sitios.
■ Objetivo: integrar distintas bases de datos para proveer una función útil.
** Clasificación: Homogéneas
BASES DE DATOS DISTRIBUIDAS HOMOGÉNEAS
■ En estas bases todos los sitios tienen idéntico software de Gestores de Bases de Datos, son conscientes de la
existencia de los demás sitios y acuerdan cooperar en el procesamiento de las solicitudes de los usuarios.
■ Los sitios renuncian a una parte de su autonomía en cuanto a su derecho de modificar los esquemas o el software
gestor de base de datos.
■ Ese software también debe cooperar con los demás sitios en el intercambio de la información sobre las
transacciones para hacer posible el procesamiento de las transacciones entre varios sitios
■ Básicamente las bases de datos distribuidas homogéneas usan el mismo software SGBD y tienen las mismas
aplicaciones en cada nodo. Tienen une squema común.
■ Pueden estar basadas en cualquier SGBD que soporte estas características, pero no puede haber más de un
SGBD en el sistema.
■ La autonomía local especifica cómo el sistema funciona desde la perspectiva de los usuarios y programadores.
■ Los sistemas gestión de bases de datos distribuidas homogéneos son una realidad; aún están limitados por la
experiencia práctica; también necesitan seguir afrontando distintos entornos y variaciones de algoritmos de
acceso a datos.
■ Una base de datos distribuidas homogéneo tiene recaudos múltiples de datos; integra recursos múltiples de datos.
■ Las bases de datos distribuidas homogéneas son similares a las bases de datos centralizadas, pero en vez de
almacenar todos los datos en un sitio, los datos se distribuyen en diferentes sitios de una red
 Clasificación: Homogéneas
■ No existen usuarios locales y todos ellos acceden a la base de datos a través de una interfaz global.
■ El esquema global es la unión de todas las bases de datos locales y el acceso por parte de los
usuarios se define sobre el esquema global. Se trata de un conjunto de bases de datos administradas
cada una por un mismo SMBD
■ Ventaja de las Bases de Datos Distribuidas Homogéneas Permite el intercambio de información entre
las localidades. Son conscientes de la existencia de otras localidades.
■ Desventaja de las Bases de Datos Distribuidas Homogéneas Pérdida parcial de la autonomía de la
localidad. No pueden usar distinto software de gestión de base de datos.
** Clasificación: HETEROGÉNEAS
BASE DE DATOS DISTRIBUIDAS HETEROGÉNEAS
■ Las bases de datos heterogéneas aparecen cuando diferentes tipos de bases de datos coexisten en
una organización que trata de compartir datos entre éstas.
■ El tratamiento de la información ubicada en bases de datos distribuidas heterogéneas exige una
capa de software adicional por encima de los sistemas de bases de datos ya existentes. Esta capa
de software se denomina sistema de bases de datos múltiples.
■ Puede que los sistemas locales de bases de datos empleen modelos lógicos y lenguajes de
definición y de tratamiento de datos diferentes, y que difieran en sus mecanismos de control de
concurrencia y de administración de las transacciones.
■ En las bases de datos distribuidas heterogéneas puede que los diferentes sitios utilicen esquemas y
software de gestión de sistemas de bases de datos diferentes.
■ Puede que algunos sitios no tengan información de la existencia del resto y que sólo proporcionan
facilidades limitadas para la cooperación en el procesamiento de las transacciones.
■ La heterogeneidad se debe a que los datos de cada BD son de diferentes tipos o formatos. El
enfoque heterogéneo es más complejo que el enfoque homogéneo y favorece el enfoque
ascendente. Es una tecnología reciente y aún existen pocas en el mercado.
■ Hoy en día existe la tendencia a crear software que permita tener acceso a diversas bases de datos
autónomas preexistentes almacenadas en SGBD heterogéneos.
Clasificación:
HETEROGÉNEAS
■ En una base de datos distribuida
heterogénea se requiere realizar cierta
labor de traducción para que los
distintos SGBD puedan comunicarse
entre sí, esta tarea puede ser de mayor
o menor complejidad, dependiendo del
usuario, por Ejemplo
■ La integración de todos ellos se realiza
mediante subsistemas de software,
como semuestra en la siguiente
imagen:.
 Clasificación: HETEROGÉNEAS
Dificultades técnicas.
■ La inversión en los programas basados en los sistemas de bases de datos ya existentes puede ser
enorme, y el coste de transformar esas aplicaciones puede resultar prohibitivo
Dificultades organizativas.
■ Aunque la integración resulte técnicamente posible, puede que no lo sea, porque los sistemas de
bases de datos ya existentes pertenezcan a diferentes empresas u organizaciones.
■ En ese caso el sistema de bases de datos múltiples permite que los sistemas de bases de datos
locales conserven un elevado grado de autonomía para la base de datos local y para las
transacciones que se ejecuten con esos datos.
Vista unificada de los datos
■ Cada sistema local de administración de bases de datos puede utilizar un modelo de datos diferente.
■ Por ejemplo: puede que algunos empleen el modelo relacional, mientras que otros pueden emplear
modelos de datos más antiguos, como el de red o el jerárquico.
■ Dado que se supone que los sistemas con bases de datos múltiples ofrecen la ilusión de un solo
sistema de bases de datos integrado, hay que utilizar un modelo de datos común.
■ Una opción adoptada con frecuencia es el modelo relacional, con SQL como lenguaje.
 Clasificación: HETEROGÉNEAS
Procesamiento de las consultas:
■ Dada una consulta en un esquema global, puede que haya que traducir la consulta a en los
esquemas locales de cada uno de los sitios en que hay que ejecutar la consulta. Hay que
volver a traducir los resultados de las consultas al esquema global
■ La tarea se simplifica escribiendo envolturas para cada origen de datos, que o vista de los
datos locales en el esquema global.
■ Las envolturas también traducen las consultas del esquema global a consultas del esquema
local y vuelven a traducir los resultados al esquema global..
■ La optimización global de consultas en bases de datos heterogéneas resulta difícil que el
sistema de ejecución de consultas no conozca los costes de los planes de consulta
alternativos en los diferentes sitios.
■ La solución habitual es confiar sólo en a optimización a nivel local y utilizar únicamente la
heurística a nivel global
■ Los sistemas de bases de datos federadas o bases de datos heterogéneas son sistemas
computacionales que hacen disponible la información desde diversas fuentes, y donde esas
fuentes de información pueden ser heterogéneas, distribuidas y autónomas
**Diseño : Particionamiento y fragmentación
Almacenamiento de datos distribuidos
Hay dos formas de almacenar datos en los diferentes sitios.
Estos son:
■ Replicación
■ Fragmentatie
 Integraciones y seguridades: Particiones y replicación
¿Qué es la partición de bases de datos?
■ La partición de bases de datos es el proceso de almacenar una base de datos grande en varias máquinas.
■ Una sola máquina, o servidor de base de datos, puede almacenar y procesar únicamente una cantidad
limitada de datos.
■ La partición de bases de datos supera esta limitación al dividir los datos en trozos más pequeños,
denominados particiones, y almacenarlos en varios servidores de bases de datos.
■ Todos los servidores de bases de datos suelen tener las mismas tecnologías subyacentes y trabajan
conjuntamente para almacenar y procesar grandes volúmenes de datos.
¿Por qué es importante la partición de bases de datos?
■ A medida que una aplicación crece, la cantidad de usuarios de la aplicación y la cantidad de datos que
almacena aumentan con el tiempo.
■ La base de datos se convierte en un cuello de botella si el volumen de datos se hace demasiado grande y
demasiados usuarios intentan usar la aplicación para leer o guardar información de forma simultánea.
■ La aplicación se ralentiza y afecta a la experiencia del cliente.
■ La partición de bases de datos es uno de los métodos para resolver este problema porque permite el
procesamiento paralelo de conjuntos de datos más pequeños en todas las particiones.
 Integraciones y seguridades: Particiones y replicación
Beneficios de la partición
■ Mejorar el tiempo de respuesta
– La recuperación de datos lleva más tiempo en una sola base de datos grande.
– El sistema de administración de bases de datos necesita buscar en muchas filas para recuperar los datos correctos.
Las particiones de datos tienen menos filas que toda la base de datos.
– Lleva menos tiempo recuperar información específica o ejecutar una consulta desde una base particionada.
■ Evitar la interrupción total del servicio
– Si se produce un error en la computadora que aloja la base de datos, también se presenta un error en la aplicación
que depende de la base de datos.
– La partición evita esto mediante la distribución de partes de la base de datos en diferentes computadoras.
– El fallo de una de las computadoras no cierra la aplicación porque puede funcionar con otras particiones funcionales.
– La partición también se suele aplicar en combinación con la replicación de datos entre particiones. Por lo tanto, si una
partición deja de estar disponible, se puede acceder a los datos y restaurarlos desde una partición alternativa.
■ Escale eficientemente
– Una base de datos en crecimiento consume más recursos de computación y, finalmente, alcanza la capacidad de
almacenamiento.
– Las organizaciones pueden usar la partición de bases de datos para agregar más recursos de computación y admitir el
escalado de la base de datos. Pueden agregar nuevas particiones en tiempo de ejecución sin suspender la aplicación
para realizar tareas de mantenimiento.
Integraciones y seguridades: Particiones y replicación
¿Cómo funciona la partición de bases de datos?
■ Una base de datos almacena información en varios conjuntos de datos que constan de
columnas y filas.
■ La partición de bases de datos divide un único conjunto de datos en particiones o
fragmentos.
■ Cada partición contiene filas únicas de información que se puede almacenar por
separado en varias computadoras, que se conocen como nodos.
■ Todas las particiones se ejecutan en nodos separados, pero comparten el esquema o el
diseño de la base de datos original.
■ Por ejemplo, una base de datos sin particionar que contiene un conjunto de datos para
los registros de clientes podría tener este aspecto.
■ La partición implica separar diferentes filas de información de la tabla y almacenarlas
en diferentes máquinas, como se muestra a continuación.
Integraciones y seguridades: Particiones y replicación

■ .

ID de cliente Nombre Estado

1 Juan California
2 María Washington
3 Pablo Arizona
4 Wang Georgia

Computadora A Computadora B

ID de cliente Nombre Estado ID de cliente Nombre Estado

1 Juan California 3 Pablo Arizona
2 María Washington 4 Wang Georgia
 Integraciones y seguridades: Particiones y replicación
¿Cuáles son los desafíos de la partición de bases de datos?
■ Las organizaciones pueden enfrentarse a los desafíos que se indican a continuación al implementar la partición de
bases de datos.
■ Puntos de acceso de datos
■ Algunos de las particiones se desequilibran debido a la distribución desigual de los datos. Por ejemplo, una única
partición física que contiene nombres de clientes que comienzan con A recibe más datos que otros. Esta partición
física utilizará más recursos informáticos que otras.
■ Complejidad operativa
■ La partición de bases de datos crea complejidad operativa. En lugar de administrar una sola base de datos, los
desarrolladores tienen que administrar varios nodos de base de datos. Al recuperar información, los
desarrolladores deben consultar varias particiones y combinar la información. Estas operaciones de recuperación
pueden complicar los análisis.
■ Costos de infraestructura
■ Las organizaciones tienen más costos de infraestructura cuando agregan más computadoras como particiones
físicas. Los costos de mantenimiento pueden aumentar si se incrementa el número de máquinas en el centro de
datos local.
■ Complejidad de aplicaciones
■ La mayoría de los sistemas de administración de bases de datos no tienen características de partición integradas.
Esto significa que los diseñadores de bases de datos y los desarrolladores de software deben dividir, distribuir y
administrar la base de datos de forma manual.
 Integraciones y seguridades: Particiones y replicación
Fragmentos
■ Los trozos de datos particionados se denominan particiones lógicas. La máquina que almacena la partición lógica
se denomina partición física o nodo de base de datos. Una partición física puede contener varias particiones
lógicas.
Clave de partición
■ Los desarrolladores utilizan una clave de partición para determinar cómo particionar el conjunto de datos.
■ Una columna del conjunto de datos determina qué filas de datos se agrupan para formar una partición.
■ Los diseñadores de bases de datos eligen una clave de partición de una columna existente o crean una.
Arquitectura de nada compartido
■ La partición de bases de datos funciona en una arquitectura de nada compartido. Cada partición física funciona de
forma independiente y desconoce otras particiones.. Solo las particiones físicas que contienen los datos que se
solicitan procesarán los datos en paralelo por usted.
■ Una capa de software coordina el almacenamiento de datos y el acceso desde estas múltiples particiones.
■ Algunos tipos de tecnología de bases de datos tienen incorporadas características de partición automática.
■ Los desarrolladores de software también pueden escribir código de partición en la aplicación para almacenar o
recuperar información de la partición o particiones correctas.
 Integraciones y seguridades: Particiones y replicación

■ En fragmentación, dividimos la única

base de datos grande en varias bases
de datos más pequeñas, cada una de
las cuales se ejecuta en una instancia
de servidor de base de datos.
■ Cada una de estas bases de datos más
pequeñas se denomina casco.
■ Y cada fragmento contiene un
subconjunto único de los datos.
Diseño : Particionamiento y fragmentación
■ Fragmentación – Divide una relación r en fragmentos fr1, fr2,…,frn. Los
fragmentos contienen información suficiente como para reconstruir la relación
original r.
■ Tipos de fragmentación:
– Fragmentación Horizontal (por filas): separa a una relación r dividiendo las
tuplas en subconjuntos.
– Fragmentación Vertical (por columnas): separa a una relación r a través de
descomposiciones en subesquemas.
– Combinada: separa a una relación r horizontal y verticalmente
Diseño : Particionamiento y fragmentación
Diseño : Particionamiento y fragmentación

■ Fragmentación horizontal en sistemas distribuidos.

 Diseño : Particionamiento y fragmentación
■ Fragmentación horizontal
■ Fragmentación horizontal primaria (predicados definidos sobre la propia relación).
■ Fragmentación horizontal secundaria (predicados definidos sobre otras relaciones).
■ Base de datos: Esquema conceptual global.
– Enlaces entre relaciones (claves externas).
– Cardinalidad de cada relación.
■ Aplicaciones:
– Predicados utilizados en las consultas (regla 80/20: 20% de las consultas, 80% de los
accesos).
– Selectividad de los términos de las consultas (número de tuplas a las que se accede
al utilizar un término).
– Frecuencias de acceso.
 Diseño : Particionamiento y fragmentación
■ Fragmentación vertical
■ Dividir una relación en relaciones más pequeñas de forma que cada aplicación trabaje sólo
con un fragmento.
■ ¡Peligro! La reconstrucción de los datos requiere el uso de reuniones (operaciones
costosas, más si son distribuidas)..
■ En bases de datos centralizadas:
– Disminución del número de accesos a páginas de disco (menor tamaño de las
relaciones).
– Uso de cachés (memoria más rápida para fragmentos a los que se accede con mayor
frecuencia).
■ Aplicaciones:
• Predicados utilizados en las consultas (regla 80/20:
20% de las consultas, 80% de los accesos).
• Frecuencias de acceso de las consultas a los
atributos individuales: use(qi,Aj)
 Integraciones y seguridades: Particiones y replicación
■ Comprender la clave de fragmentación
■ Comprendamos el papel de la clave de fragmentación.
■ El equipo clave de fragmentación, que suele ser una columna (o una combinación de
columnas) en la tabla de la base de datos, debe elegirse de manera que la distribución de
los datos sea uniforme entre varios fragmentos.
■ Porque no queremos que un fragmento en particular sea mucho más grande que los otros
fragmentos.
■ En una base de datos que almacena datos sobre clientes y transacciones, el customer_ID
es un buen candidato para la clave de fragmentación.
■ Una vez que hayamos decidido la clave de fragmentación, podemos crear una función hash
que determine cuál de las filas va en cuál de los fragmentos.
■ En este ejemplo, digamos que necesitamos dividir la base de datos en cinco fragmentos
(fragmento #0 a fragmento #4) usando el customer_ID como clave de fragmentación. En
este caso, una función hash simple es ID_cliente % 5.
 Integraciones y seguridades: Particiones y replicación
■ Todas las customer_ID los valores que dejan un resto de cero cuando se dividen por 5 se
asignarán al fragmento #0. Y customer_ID los valores que dejan restos del 1 al 4 se asignarán al
fragmento n.º 1 al fragmento n.º 4, respectivamente.
■ Después de implementar la fragmentación de la base de datos de esta manera, es importante
tener una capa de enrutamiento que enrute las solicitudes entrantes al fragmento de base de
datos correcto.
 Diseño : Particiones y replicación
Replicación
■ La replicación es una técnica que hace copias exactas de la base de datos y las almacena en diferentes
computadoras.
■ Los diseñadores de bases de datos utilizan la replicación para diseñar un sistema de administración de
bases de datos relacionales tolerante a errores.
■ Cuando se produce un error en uno de los equipos que aloja la base de datos, otras réplicas
permanecen operativas.
■ La replicación es una práctica común en los sistemas de computación distribuida.
■ Cuando se produce una sobrecarga de la instancia del servidor de la base de datos debido a las
solicitudes entrantes, podemos considerar la replicación de la base de datos.
La replicación de datos
■ Es una técnica mediante la cual copiamos de forma exacta en otra ubicación una instancia de la base de
datos. Se utiliza en entornos distribuidos de Sistemas de Gestión de Bases de Datos donde una sola
base de datos tiene que ser utilizada y actualizada en varios lugares de forma simultánea.
■ Mediante la replicación de base de datos, usuarios de todo el mundo pueden estar accediendo a lo que
para ellos son los mismos datos, aunque en realidad, físicamente esos datos pueden estar de forma
transparente para el usuario, en diferentes nodos o localidades.
 Diseño : Particiones y replicación
Ventajas:
■ Recuperación de Fallos: Garantiza que siempre hay disponible una copia de seguridad de los datos en
caso que el servicio se detenga independientemente de la razón que cause el error en el sistema.
■ Fiabilidad y disponibilidad de datos: El servicio de replicación se encarga de mantener la base de datos
actualizada, estado relacional correcto y lista para realizar cualquier operación sobre ella.
■ Menos tiempo de carga: Tener los datos disponibles en distintas ubicaciones permite la reducción de
tiempos de carga, puesto que los clientes ya no deben hacer la petición a un servidor ubicado a miles de
kilómetros de sí mismo, sino que utilizan la réplica más cercana como fuente de datos.
Desventajas:
■ Mayores costos: Mantener la base de datos distribuida implica doble inversión en infraestructura.
■ Limitaciones de tiempo: la ejecución del proceso de replicación debe ser implementado y supervisado por
un equipo para garantizar que los datos replicados sean consistentes con los datos del editor.
■ Ancho de banda y Latencias: El servicio de conexión puede influir de forma negativa en las réplicas,
puesto una conexión muy deficiente puede provocar que genere dificultades en el proceso de replicación.
■ Datos inconsistentes: La sincronización puede darse en distintos lapsos de tiempo lo que puede provocar
que los suscriptores no se sincronicen de forma correcta lo que podría generar intervalos en los que los
datos no estén disponibles en los suscriptores durante minutos u horas, llegando a un extremo en el que
los datos no se sincronicen sin la intervención de los administradores.
 Diseño : Particiones y replicación
■ La replicación requiere una serie de componentes para funcionar correctamente.
■ Artículo
– Para cada objeto que debe ser replicado es necesario definir un artículo, cada artículo corresponde a
un único objeto de la base de datos.
– Un artículo se puede definir como una Tabla, una función, un procedimiento almacenado o un Trigger.
– Las propiedades de un artículo definen si el artículo contiene a todo el objeto.
– Las Publicaciones se refiere a una colección de artículos agrupados como unidad.
– Se puede definir que un artículo apunte a una publicación específica, dado que cada artículo puede ser
una publicación en sí misma.
■ Publicador
– Para cada objeto que debe ser replicado es necesario definir un artículo, cada artículo corresponde a
un único objeto.
– Cualquier base de datos que contenga objetos designados como artículos se denomina Base de Datos
de Publicación.
– El Publicador es la instancia del servidor de base de datos que hace que una publicación esté
disponible para la replicación; sin embargo, el editor en sí mismo no tiene un papel activo en la
configuración de la replicación.
– Una vez definida la publicación, el Distribuidor y el Suscriptor se encargan de todo el trabajo pesado.
 Diseño : Particiones y replicación
■ La replicación requiere una serie de componentes para funcionar correctamente.
■ Distribuidor
– Cada Publicador está vinculado a un único distribuidor.
– El Distribuidor es una instancia de un servidor de base de datos que identifica los cambios en los
artículos de cada uno de sus Publicadores.
– Dependiendo de la configuración de la aplicación, el Distribuidor también puede ser responsable
de notificar a los suscriptores que se han suscrito a una publicación que un artículo ha cambiado.
■ Suscriptor
– Una suscripción es la contraparte de la publicación.
– Cada suscripción crea un vínculo entre una Publicación y un Suscriptor.
– Existen dos tipos de suscripciones: las suscripciones push y las suscripciones pull.
■ En una suscripción push, el distribuidor actualiza directamente los datos en la base de datos
del suscriptor.
■ En una suscripción pull, el suscriptor pregunta regularmente al distribuidor si hay nuevos
cambios disponibles, y entonces actualiza los datos en la propia base de datos de la
suscripción.
Diseño : Particiones y replicación

■ .
 Diseño : Particiones y replicación
■ Tipos de replicación de base de datos
■ Replicación Instantánea:
– los datos de un servidor son simplemente copiados a otro servidor o a otra base de datos
dentro del mismo servidor.
– Al copiarse todo no necesitas un control de cambios. Se suele utilizar cuando los datos
cambian con muy poca frecuencia.
■ Replicación Transaccional:
– primero se envía una copia completa de la base de datos y luego se van enviando de forma
periódica (o a veces continua) las actualizaciones de los datos que cambian.
– Se utiliza cuando necesitas que todos los nodos con todas las instancias de la base de datos
tengan los mismos datos a los pocos segundos de realizarse un cambio.
■ Replicación de mezcla:
– los datos de dos o más bases de datos se combinan en una sola base de datos.
– En primer lugar, se envía una copia completa de la base de datos. Luego el Sistema de
Gestión de Base de Datos va comprobando los cambios que van apareciendo en los distintos
nodos y a una hora programada o a petición los datos se sincronizan.
– Es sobre todo útil cuando cada nodo suele utilizar solo los datos que se actualizan allí pero
que por circunstancias necesita tener también los datos de los otros sitios.
Diseño : Particiones y replicación
■ Bajo la replicación de la base de datos, tenemos un nodo maestro que normalmente recibe
solicitudes de escritura. Hay múltiples réplicas de lectura.
■ Esto mejora la disponibilidad y mitiga la sobrecarga del sistema. Ahora podemos procesar
varias consultas en paralelo, ya que las solicitudes de lectura se pueden enrutar a una de
las réplicas de lectura.

• Pero esto introduce otro

problema. Las solicitudes de
escritura al nodo principal
pueden cambiar los datos y
estas actualizaciones se
propagan periódicamente a las
réplicas de lectura.
 Diseño : Particiones y replicación

■ Supongamos que hay una solicitud de lectura para una de las réplicas de lectura al mismo
tiempo que una operación de escritura está en curso en el nodo principal.
■ Los cambios en el nodo maestro aún no se habrán propagado a las réplicas de lectura. En
este caso, es posible que estemos leyendo datos desactualizados, lo cual no es deseable.
 Diseño : Consultas centralizadas / distribuidas
■ Estrategias de procesamiento de consultas distribuidas.
■ Contamos con la estrategia de Reformulación de consultas, que nos sirve para encontrar la
información que nos va a proveer sea solo la que se le pidió por la fuente, también se cuenta
con la estrategia de descomposición de las fuentes, que consiste en que según las fuentes que
pidan cierto tipo de datos sean las atendidas con mayor velocidad.
■ Los lenguajes de bases de datos relacionales permiten la expresión de consultas complejas en
una forma concisa y simple.
■ Para construir una respuesta a una consulta, el usuario no tiene que especificar de manera
precisa el procedimiento que se debe seguir. Este procedimiento es llevado a cabo por un
módulo de DBMS llamado el procesador de consultas (query processor).
■ Dado que la ejecución de consultas es un aspecto crítica en el rendimiento de un DBMS, el
procesamiento de consultas ha recibido una gran atención tanto para bases de datos
centralizadas como distribuidas.
■ El procesamiento de consultas es mucho más difícil en ambientes distribuidos que en
centralizados, ya que existe un gran número de parámetros que afectan el rendimiento de las
consultas distribuidas.
 Diseño : Consultas centralizadas / distribuidas
■ Características de los procesadores de consultas
■ Comparar un sistema centralizado con uno distribuido es una tarea complicada ya que ambos
difieren en una gran cantidad de aspectos, desde su arquitectura hasta la forma de tratar una
consulta. Vamos a enumerar las características de los procesadores de consultas distribuidas :
– Tipo de optimización.
– Granularidad de la optimización.
– Tiempo de optimización
– Estadísticas
– Nodos de decisión.
– Topología de la red
■ Arquitectura del procesamiento de consultas
■ El procesamiento de consultas distribuidas podemos separarlo en cuatro fases o niveles,
desde que la consulta llega hasta que se optimiza al máximo posible:
– • Descomposición de consultas.
– • Localización de datos.
– • Optimización global de consultas.
– • Optimización local de consultas. .
 Diseño : Consultas centralizadas / distribuidas
■ Consultas distribuidas
■ Permite que se consulten zonas remotas, utilizando el mejor camino hacia ese lugar y los mejores
recursos que puedan realizar correctamente la consulta.
■ Las consultas distribuidas tienen como objetivo convertir transacciones de usuario en instrucciones
para manipulación de datos.
■ El orden en que se realizan las transacciones afecta grandemente la velocidad de respuesta del
sistema. Así, el procesamiento de consultas presenta un problema de optimización en el cual se
determina el orden en el cual se hace la menor cantidad de operaciones. Se tiene que considerar:
– El costo de transmisión de datos en la red.
– Repetición y fragmentación.
– Procesamiento de intersección simple.
■ En las consultas distribuidas el origen de los datos puede estar almacenado en el mismo equipo o en
equipos distintos y también detienen el acceso a datos de varios orígenes de datos homogéneo.
■ En SQL la sentencia join permite combinar registros de dos o más tablas en una base de datos
relacional. En el Lenguaje (SQL), hay tres tipo de JOIN: interno, externo, y cruzado
** Diseño : Consultas centralizadas / distribuidas
■ Procesamiento de consultas distribuidas.
■ Primeramente se debe de contar con heterogeneidad de los datos, para que puedan ser
usados para formular consultas.
– BD CENTRALIZADA.
– BD DISTRIBUIDA.
■ Asi como tambien necesitamos contar con:
– Localización de los datos para generar reglas heurísticas.
– Descomposición de consultas en paralelo en cada nodo.
– Reducir la cantidad de datos a transferir en la red.
 Diseño : Consultas
centralizadas / distribuidas
■ Diseño de una Base de Datos Distribuida:
■ Un sistema de base de datos distribuida (SBDD) es
entonces el resultado de la integración de una base
de datos distribuida con un sistema para su
manejo..
■ En el diseño de una BDD existen tres tipos:
■ Arquitecturas de memoria compartida: Consiste
en diversos procesadores los cuales acceden una
misma memoria y una misma unidad de
almacenamiento
■ Arquitectura de disco compartido: Consiste en
diversos procesadores cada uno de ellos con su
memoria local, pero compartiendo una misma
unidad de almacenamiento.
■ Arquitecturas de nada compartido: Consiste en
diversos procesadores cada uno con su propia
memoria y su propia unidad de almacenamiento
** Diseño : Control de la concurrencia (transacciones, deadlock)
■ Control de Concurrencia
■ Control de concurrencia es la coordinación de procesos concurrentes que operan sobre datos
compartidos y que podrían interferir entre ellos..
■ Estudio de un modelo formal y de los principios básicos de las técnicas que debe implementar
el manejador para garantizar la consistencia de la base en la situación de modificaciones
concurrentes
■ El propósito del control de concurrencia es mantener la consistencia de la BD cuando ésta es
actualizada por múltiples usuarios.
■ Existen casos en los que las transacciones ejecutadas aisladamente originan nuevos estados
consistentes, sin embargo las mismas transacciones ejecutadas concurrentemente pueden
originar efectos como pérdidas de operaciones y/o violación de restricciones de integridad.
■ Es muy raro que una aplicación no ejecute de forma concurrente operaciones sobre una base
de datos.
■ Es frecuente que de las operaciones iniciadas por el usuario se ejecuten procesos en segundo
plano que también toquen la base de datos.
■ Hay que empezar a pensar qué cosas nos pueden ocurrir cuando dos transacciones se
ejecutan a la vez y qué pasa con los datos que están siendo modificados mientras se ejecuta
una transacción. Esto puede dar lugar a tres problemas fundamentales:
 Diseño : Control de la concurrencia (transacciones, deadlock)
■ Lecturas sucias
– Se producen cuando una transacción puede leer datos que están siendo escritos por otra transacción antes de que ésta
realice el commit.
– Ejemplo: cuando la transacción 1 modifica un registro en la tabla Customer, la transacción 2 lo lee con las modificaciones,
y luego la transacción 1 hacer un rollback, descartando las modificaciones. En ese caso, la transacción 2 habrá estado
operando en base a unos datos que realmente no son válidos.
■ Lecturas no repetibles
– Podríamos solucionar el problema de las lecturas sucias haciendo que las modificaciones realizadas por una transacción
no sean visibles al resto hasta que se realice el commit.
– Aun así, podríamos encontrarnos con otro problema: el de las lecturas no repetibles, que se producen cuando una
transacción modifica datos que han sido leídos por otra. Ejemplo: si la transacción 1 lee el registro Customer {Id = 1,
Name = 'Paco'}, la transacción 2 modifica ese registro y realiza el commit, y la transacción 1 lo vuelve a leer, los datos
que obtendrá son diferentes de los que obtuvo al principio.
■ Lecturas fantasma
– Esto tiene solución si hacemos que una transacción no pueda modificar datos que hayan sido leídos por otra, pero
todavía nos quedaría otro problema por resolver: las lecturas fantasma, que se produce cuando una transacción lanza
una misma consulta dos veces y obtiene distinto conjunto de resultados.
– Si en las lecturas no repetibles podían cambiar los valores obtenidos para una fila, en una lectura fantasma podrían
aparecer o desaparecer filas. Ejemplo: si la transacción 1 consulta los clientes de Madrid y obtiene 10 filas, a continuación
la transacción 2 inserta un nuevo cliente también de Madrid y hace su commit, y la transacción 1 vuelve a consultar
clientes de Madrid obteniendo 11 filas.
– Para solucionar esto no nos basta con proteger los datos ya leídos por cada transacción, sino que necesitamos proteger
los datos que potencialmente podrían afectar a nuevas consultas de una transacción.
 Diseño : Control de la concurrencia (transacciones, deadlock)
■ Transacción
■ Es una unidad de la ejecución de un programa. Puede consistir en varias operaciones de acceso
a la base de datos. Está delimitada por constructoras como begin-transaction y end-transaction.
■ Es una unidad atómica de trabajo que se ejecuta completamente o no se ejecuta nada.
■ Es una unidad de programa que accede y posiblemente actualiza varios ítems de la base de
datos.
■ Se exige que las transacciones no violen ninguna restricción de consistencia de la base de
datos. Es decir, si la base de datos era consistente cuando comenzó la transacción, la base de
datos debe ser consistente cuando la transacción termine con éxito. Durante la ejecución de una
transacción puede ser necesario permitir inconsistencias temporalmente.
■ Una secuencia de lecturas y/o escrituras sobre los ítems de datos almacenados en una base de
datos se denomina transacción.
■ Una transacción es una secuencia de ejecución de sentencias, y es atómica con respecto a la
recuperación. Esto implica que el resultado de la ejecución es completamente satisfactorio o
bien no produce efectos sobre los datos.
■ Si las operaciones realizadas en la transacción no actualizan ningún dato, es decir no hay
escrituras, la transacción se denomina transacción de solo lectura.
■ Para propósitos de recuperación el sistema necesita mantener una marca de cuando la
transacción comienza, termina, se compromete, o aborta
 Diseño : Control de la concurrencia (transacciones, deadlock)
El manejador de recuperaciones guarda las marcas de las siguientes operaciones:
■ Comienzo de Transacción (Begin Transaction): Marca el comienzo de la transacción.
■ Lectura o Escritura (Read o Write): Se ejecutan como parte de una transacción sobre los ítems de la base
de datos.
■ Fin de Transacción (End Transaction): Especifica que las operaciones de lectura y escritura de una
transacción han terminado y marca el límite final de la ejecución de la transacción. Este punto es necesario
debido a que los cambios introducidos por la transacción pueden ser aplicados en forma permanente o porque
la transacción tiene que ser deshecha porque viola el control de concurrencia.
■ Comprometer la Transacción (Commit Transaction): Indica un fin exitoso de la transacción por lo que
cualquier cambio (actualización) ejecutado por la transacción puede ser comprometido en la base de datos en
forma segura y no será deshecho.
■ Deshacer la Transacción (Rollback Transaction): indica que la transacción ha terminado sin éxito, por lo
que cualquier cambio o efecto producido por la transacción en la base de datos debe ser deshecho.

Además de lo anterior, algunas técnicas de recuperación requieren las siguientes operaciones adicionales
■ Undo: Similar al Deshacer (Rollback) excepto que se aplica a una sola operación en vez de a una
transacción.
■ Redo: Esto especifica que ciertas operaciones de una transacción deben ser rehechas para asegurar que
todas las operaciones de una transacción comprometida se hayan realizado en la base de datos
satisfactoriamente
Diseño : Control de la concurrencia (transacciones, deadlock)

■ Propiedades ACID
■ Existen propiedades deseables para las transacciones que se denominan propiedades
ACID, y deberían estar garantizadas por el control de concurrencia y los métodos de
recuperación del SGBD.
■ Las propiedades ACID son :
1. Atomicidad (Atomicity):
2. Consistencia (Consistency):
3. Aislamiento (Isolation):
4. Durabilidad (Durability):
Diseño : Control de la concurrencia (transacciones, deadlock)

El Manejador de Transacciones (Scheduler o Transaction Manager)

■ Se encarga de la administración de las transacciones en la Base de Datos.
■ Para eso recibe las instrucciones que los programas pretenden ejecutar y se toma la
libertad de reordenarlas, sin cambiar nunca el orden relativo de los Read y Write.
■ Puede llegar a agregar instrucciones (nunca R/W) por su cuenta.
■ Puede llegar a demorar la ejecución de las instrucciones.
■ Hace lo que necesite para implementar ACID hasta donde pueda
 Diseño : Control de la concurrencia (transacciones, deadlock)
Bloqueos.
■ Un bloqueo (también conocido como seguro o candado) podemos definirlo como una variable asociada a
cada elemento de datos, ya que describe el estado de dicho elemento respecto a las posibles operaciones
que se pueden llevar a cabo con ellos en cada momento
■ Objetivo: Permitir únicamente la ejecución simultánea de operaciones compatibles operaciones compatibles
■ Evitan la generación de ejecuciones incorrectas
■ Transacciones con operaciones conflictivas sobre un objeto esperan
■ Modo de operación
– Clase que caracteriza a una operación
– Determinan compatibilidades entre operaciones
– Modos de operación clásicos: lectura y escritura
– Se extienden para optimizar los algoritmos de bloqueo
Protocolo de bloqueo
■ Sobre un gránulo, y simultáneamente, se permite ejecutar operaciones con modos compatibles
■ Protocolo que indica el acceso a un gránulo, que puede llegar a ser compartido, caracterizado por petición
de autorización para realizar una operación, y señales que indican la finalización de la operación
■ Es necesario conocer: el comienzo, modos de operación y el final
 Diseño : Control de la concurrencia (transacciones, deadlock)
Bloqueos compartidos o de lectura (S):
■ Se utiliza cuando las transacciones solo necesitan leer los datos, pero quieren impedir cualquier
modificación de estos mientras son consultados.
Bloqueos exclusivos o de escritura (X):
■ Cuando una transacción mantiene un bloqueo de este tipo sobre un dato, ninguna otra transacción puede
acceder a él, ni adquirir ningún tipo de bloqueo sobre ese dato, hasta que sea liberado por la transacción
que lo había retenido.
■ Este tipo de bloqueo se utiliza cuando una transacción quiere actualizar algún dato.
■ Los bloqueos pueden colocarse de manera automática por el DBMS o por medio de un comando emitido
al DBMS partiendo del programa de aplicación del usuario que consulta.
■ A los bloqueos colocados por el DBMS se les llama bloqueos implícitos y a los que son colocados por
comando se les llama explícitos..
Bloqueos de actualización (U)
■ Indica que una transacción tal vez vaya a realizar la actualización de un registro
■ Cualquier transacción que intente actualizar un registro, debe primero obtener la dirección sobre el
registro y adquirir el bloqueo U sobre éste. Después, cualquier actualización al registro provocará que el
bloqueo se convierta a uno de nivel X.
■ El bloqueo de actualización previene el deadlock , y permite mayor concurrencia que utilizando el bloqueo
 Diseño : Control de la concurrencia (transacciones, deadlock)
Bloqueo Mortal (Dead lock)
■ Aunque bloquear resuelve un problema, genera otro que se denomina dead lock (también
conocido como bloqueo mortal, interbloqueo o abrazo mortal).
■ Sucede cuando un usuario está esperando un recurso que otro usuario tiene bloqueado y que a
su vez el segundo usuario está esperando por un recurso que el primer usuario tiene bloqueado.
■ El dead lock es una condición que ningún sistema o conjunto de procesos quisiera exhibir, ya
que ocurre cuando se presentan al mismo tiempo cuatro condiciones necesarias:
– La condición de no apropiación,
– la condición de espera circular,
– la condición de exclusión mutua
– la condición de ocupar y esperar un recurso.
■ Ante esto, si el dead lock involucra a todos los procesos del sistema, el sistema ya no podrá
hacer algo productivo.
■ Si el dead lock involucra algunos procesos, éstos quedarán congelados para siempre..
Diseño : Control de la concurrencia (transacciones, deadlock)

Existen dos posibilidades para un

DBMS ante los dead locks:
EJEMPLO:
■ La primera es tratar de evitarlo, Supongamos los siguientes eventos:
evento 1: Proceso A pide recurso 1 y se le asigna.
permitiendo que el bloqueo se
evento 2: Proceso B pide recurso 2 y se le asigna.
haga desde el inicio y siempre que evento 3: Proceso C pide recurso 3 y se le asigna.
se procesen registros de las tablas evento 4: Proceso C pide recurso 1 y como lo está ocupando el
en una relación padre-hijo proceso A, espera.
evento 5: Proceso B pide recurso 3 y espera porque lo está ocupando
bloquear al padre antes que a los el proceso C.
hijos. Y evento 6: Proceso A pide recurso 2 pero lo está ocupando el proceso
B, entonces espera
■ La segunda es permitir el dead
lock y después romperlo.
■ Casi todos los DBMS tienen
algoritmos para detectar el dead
lock, la solución más común es
revertir una de las transacciones
para eliminarlo.
** Diseño : Almacenamiento y procesamiento distribuido
■ El procesamiento distribuido es la forma en que es posible conectar distintas máquinas, en cierto tipo de red de
comunicaciones, generalmente una LAN o una red de área amplia o una red como Internet, logrando así, que una
sola tarea de procesamiento de datos pueda ser procesada o ejecutada entre varias máquinas de la red, es decir
que un solo proceso se pueda realizar entre varias máquinas diferentes y conectadas a una red.
■ Un error común es confundir procesamiento distribuido con procesamiento paralelo; el término “procesamiento
paralelo”, básicamente es el mismo, con excepción que las máquinas distintas tienden a estar físicamente muy cerca
en un sistema “paralelo”, lo que no es necesario en un sistema “distribuido”.
■ DESCRIPCIÓN
■ Proceso distribuido, varios procesos ejecutándose en paralelo, en la misma máquina o distribuidos entre
computadoras interconectados a través de una red de comunicaciones, colaboran en la realización de una tarea,
esta colaboración puede ser tan sencilla como distribuir la carga de trabajo entre procesos idénticos.
■ El procesamiento distribuido permite una mejor utilización de equipos y mejora el balanceo del procesamiento dentro
de una aplicación, ya que en algunas aplicaciones simplemente no hay una máquina que sea capaz de realizar todo
el procesamiento.
■ Existe una tendencia inevitable al desarrollo de aplicaciones distribuidas, el procesamiento distribuido permite
dispersar los procesadores, datos y otros elementos de una aplicación, la dispersión ofrece un sistema más sensible
a las necesidades de los usuarios, capaz de ofrecer tiempos de respuesta mejores y minimizar los costes de
comunicación, un sistema distribuido consiste de un gran número de CPU´s conectados por medio de una red
■ Un sistema distribuido se encarga del procesamiento cooperativo de solicitudes mediante una colección de
computadoras independientes que aparecen ante los usuarios del sistema como una única computadora.
 Diseño : Almacenamiento y procesamiento distribuido
Transparencia de Distribución
■ Es la capacidad de un sistema de ocultar el hecho de que sus recursos están físicamente
distribuidos en muchos computadores
■ Un sistema distribuido transparente es aquel que se presenta a los usuarios y a las aplicaciones
como si fuera un único sistema de computación, este concepto puede ser aplicado a varios
aspectos de un sistema distribuido..
Grado de Transparencia
■ Aspirar a una transparencia total puede ser demasiado: Los usuarios pueden estar en
continentes diferentes; con frecuencia esto no es algo que conviene ocultar, ocultar totalmente
las fallas de redes y nodos es imposible ya que no hay manera de distinguir entre un recurso
excesivamente lento y uno que ha fallado, mantener la consistencia de múltiples copias de un
recurso replicado puede implicar un tiempo significativo.
 Diseño : Almacenamiento y procesamiento distribuido
Escalabilidad
■ La escalabilidad se refiere a varios aspectos:
– Capacidad del sistema de incrementar el rendimiento ante un incremento de la carga si se agregan
recursos adicionales
– Un sistema distribuido "x" es más escalable que un sistema distribuido "y" si utilizando el mismo
hardware, "x" puede atender una carga más alta.
■ La escalabilidad puede medirse en tres dimensiones:
– Con respecto a su tamaño: permite incrementar el número de usuarios o procesos soportados.
– Geográficamente: permite que sus usuarios y/o recursos estén alejados geográficamente entre sí.
– Administrativamente: permite cubrir muchas organizaciones administrativas independientes.
■ La escalabilidad geográfica se ve afectada por los siguientes aspectos: uso de comunicación síncrona y la
comunicación en WANs es poco confiable y casi siempre punto a punto, algunos problemas de escalabilidad
que se presentan son:
– Servicios Centralizados: Uso de un solo servidor para atender solicitudes de los usuarios
– Datos Centralizados: Tener todos los datos en un único servidor de base de datos.
■ En ambos casos el servidor se puede volver un cuello de botella si aumenta el número de usuarios, Si el
servidor tiene capacidad ilimitada de procesamiento y almacenamiento, las líneas de comunicación desde y
hacia el servidor se saturarán y harán imposible el crecimiento.
 Diseño : Almacenamiento y procesamiento distribuido

■ Dentro de la escalabilidad se encuentra el uso de algoritmos que requieran centralizar

información proveniente de todos los nodos del Sistema de Distribución, algunos problemas en
este caso son las siguientes:
– El transporte de toda la información al punto centralizado haría que una parte de la red se
sobrecargue.
– Sólo deben usarse algoritmos descentralizados.
– El uso de algoritmos centralizados está especialmente relacionado con problemas de
escalabilidad geográfica.
■ Por el contrario también se encuentran los algoritmos descentralizados; tienen las siguientes
características:
– Ninguna máquina tiene la información completa sobre el estado del sistema.
– Las máquinas toman decisiones basándose únicamente en información local.
– La falla de una máquina no arruina el algoritmo.
– No se asume que existe un reloj global.
 Diseño : Almacenamiento y procesamiento distribuido
■ Para manejar este tipo de procesamiento en las aplicaciones existen diversas maneras, siendo la
arquitectura “cliente-servidor” la tendencia actual, e tanto el uso actual de esta arquitectura que por
diversas razones, el término “cliente-servidor” ha llegado a aplicarse casi exclusivamente al caso
en el que el cliente y el servidor están, en efecto en máquinas distintas.
■ Una aplicación muy común del procesamiento distribuido es en las bases de datos, donde el
procesamiento distribuido podría realizar la entrada/salida, la selección y la validación de los datos
en una computadora, y luego crear un reporte basado en esos datos o una consulta en otra
computadora
Diseño : Almacenamiento y procesamiento distribuido

Procesamiento de operaciones de actualización distribuidas.

■ Los sistemas cliente/servidor involucran varias computadoras conectadas a una red. Las
computadoras que procesan programas de aplicaciones se conocen como clientes y las
que procesan bases de datos se conocen como servidor.

Arquitectura Cliente Servidor

■ Un sistema cliente servidor puede tener varios
servidores de procesamiento de bases de datos,
cuando esto ocurre cada servidor debe procesar
una base de datos distinta.
■ Cuando dos o más servidores procesan una
misma base de datos, el sistema no es
considerado cliente servidor, más bien, es
conocido como sistema de base de datos
distribuido.
 Diseño : Almacenamiento y procesamiento distribuido
■ Procesamiento de consultas distribuidas.
■ Primeramente se debe de contar con heterogenidad de los datos, para que puedan ser usados para
formular consultas..
 Diseño : Almacenamiento y procesamiento distribuido
■ Manejo de transacciones.
■ Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto de
órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.
■ Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos, haciendo
que estas transacciones no puedan finalizar en un estado intermedio.
■ Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las
órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de
integridad), como si la orden de la transacción nunca se hubiese realizado.
■ Una transacción debe contar con ACID. Para que un Sistema de Gestión de Bases de Datos sea
considerado Transaccional, debe cumplir con estos criterios (ACID).
■ Para esto, el lenguaje de consulta de datos SQL, provee los mecanismos para especificar que un
conjunto de acciones deben constituir una transacción.
– BEGIN TRAN: Especifica que va a empezar una transacción.
– COMMIT TRAN: Le indica al motor que puede considerar la transacción completada con
éxito.
– ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la base al
punto de integridad.
Diseño : Almacenamiento y procesamiento distribuido

■ En un sistema ideal, las

transacciones deberían
garantizar todas las
propiedades ACID; en la
práctica, a veces alguna de
estas propiedades se simplifica
o debilita con vistas a obtener
un mejor rendimiento..
 Diseño : Almacenamiento y procesamiento distribuido
Colocación de Datos
■ Para la ubicación de los datos se deben observar tres estrategias de alojamiento:
– Centralizado: Toda la base de datos esta almacenada en un solo sitio.
– Particionada: La base de datos está dividida en varios fragmentos y almacenados en diversos sitios.
– Replicada: Copias de uno o más fragmentos de base de datos están almacenados en diversos sitios.
■ La distribución de los datos a lo largo de una red de computadoras se logra a través de la partición de los
datos, a través de la replicación de los datos o bien a través de una combinación de ambos.
■ El alojamiento de los datos está muy relacionado con la forma en que la base de datos está dividida o
fragmentada. La mayoría de los estudios de ubicación de los datos se enfoca en DONDE poner QUE.
■ Los algoritmos de colocación de datos toman en consideración una variedad de factores como:
– Requerimientos de rendimiento y disponibilidad de datos
– Tamaño, numero de registros y el número de relaciones que una entidad mantiene con otras entidades.
– Tipos de transacciones a ser aplicados a la base de datos, los atributos accesados por cada una de
estas transacciones, etc.
■ Algunos algoritmos incluyen datos externos, como la topología de la red, el throughput de la red. No existe
un algoritmo universalmente aceptado aun y pocos algoritmos han sido implementados hasta la fecha..
** Diseño : Fallas y recuperación
CONCEPTOS GENERALES DE RECUPERACIÓN
■ La recuperación en un SBD consiste en (volver a) dejar la información almacenada en la
base de datos en un estado consistente, después de un fallo (o caída) del sistema que ha
llevado la BD a un estado inconsistente, o por lo menos “sospechoso” de serlo.
■ Los SBD pequeños no suelen proporcionar soporte para la recuperación. Sí lo hacen los
grandes sistemas de base de datos multiusuario.
■ El módulo componente del SGBD encargado de que el SBD sea seguro frente a posibles
fallos, es el Subsistema Gestor de Recuperación, cuya función es, entre otras cosas, velar
por que...
– las transacciones no se pierdan (es decir, que se ejecuten),
– las transacciones no se realicen parcialmente (deben ejecutarse en su totalidad),
– no se ejecute una operación más de una vez o, si se hace, que el resultado sea
equivalente al obtenido si se hubiera realizado una única vez.
 Diseño : Fallas y recuperación
Clasificación de los fallos de un sistema de base de datos
Existen diversas causas por las que el sistema de bases de datos puede fallar. Algunos tipos
de fallos son los siguientes:
1. Errores locales previstos por la aplicación (rollback explícito o programado) Durante la
ejecución de una transacción pueden presentarse condiciones que requieran la
cancelación de la misma (por ejemplo, un saldo insuficiente en una cuenta bancaria implica
la cancelación de una transacción de reintegro sobre dicha cuenta).
2. Errores locales no previstos (overflow, división por cero...) Errores lógicos de
programación (bugs), o interrupciones provocadas. Un fallo local sólo afecta a la
transacción que se está ejecutando donde ha ocurrido el fallo. Normalmente supone la
pérdida de los datos en memoria principal y en los búferes de entrada/salida.
3. Fallos por imposición del control de concurrencia El Subsistema de Control de
Concurrencia puede decidir abortar una transacción T (para reiniciarla posteriormente) bien
porque viola la seriabilidad o porque varias transacciones están en un estado de bloqueo
mortal y se ha seleccionado T como víctima.
Diseño : Fallas y recuperación
1. Fallos del sistema (caídas suaves) Consisten en un mal funcionamiento del hardware,
errores software (del SGBD o del SO) o de red, que afectan a todas las transacciones en
progreso de ejecución en el sistema de BD. No dañan físicamente el disco (el contenido de
la BD permanece intacto y no se corrompe), pero se pierden los datos en la memoria
principal y en los búferes de entrada/salida.
2. Fallos de disco (caídas duras) Son fallos en los dispositivos de almacenamiento (por
ejemplo, si ocurre una rotura o un aterrizaje de alguna cabeza lectora-escritora en el disco,
si funciona mal la lectura o la escritura, o si ocurre un fallo durante una transferencia de
datos). Afectan a todas las transacciones en curso y suponen la pérdida de información en
disco (es decir, algunos bloques del disco pueden per- der sus datos).
3. Fallos catastróficos o físicos Algunos ejemplos son el corte del suministro eléctrico, robo
del disco, incendio, sabotaje, sobreescritura en discos o cintas por error, etc.
■ Los fallos de tipo 5 y 6 suceden con menos frecuencia que el resto y su recuperación es
más com- plicada...
Diseño : Fallas y recuperación
Técnicas de Recuperación de Bases de Datos
Descripción de la Recuperación y Clasificación de los Algoritmos de Recuperación
■ Recuperarse al fallo de una transacción significa que la base de datos se restaura al estado
coherente más reciente, inmediatamente anterior al momento del fallo para esto el sistema
guarda las información sobre los cambios de las transacciones esta información se guarda
en el registro del sistema.
1. Si hay un fallo como la caída del disco, el sistema restaura una copia se seguridad del
registro, hasta el momento del fallo.
2. Cuando el daño se vuelve inconsistente, se pueden rehacer algunas operaciones para
restaurar a un estado consistente. En este caso no se necesita una copia archivada.
■ Actualización Diferida: No se actualiza físicamente la base de datos Hasta que no haya
alcanzado su punto de confirmación.
■ Actualización Inmediata: La base de datos puede ser actualizada por Algunas Operaciones
antes de que esta ultima alcance su punto de confirmación.
 Diseño : Fallas y recuperación
Tipos de Almacenamiento
■ Almacenamiento volátil: no sobrevive a las caídas del sistema.
■ Almacenamiento no volátil: disco, cinta...: existen accidentes.
■ Almacenamiento estable frente al no estable: la información no se pierde “nunca”, se repite en varios
medios no volátiles (disco) con modos de fallo independientes.
Almacenamiento en cache (búfer) de los bloques de disco
■ El proceso de recuperación se entrelaza con funciones del sistema operativo en particular con el
almacenamiento en cache o en búfer en la memoria principal, Normalmente se reserva una colección de
búferes en memoria, denominados cache DBMS. Se utiliza un directorio para rastrear los elementos de la
base de datos que se encuentra en los búferes.
– Bit sucio que puede incluirse en la entrada del directorio, para indicar si se ha modificado o no el búfer.
– Pin-un pin dice que una página en cache se está accediendo actualmente.
– Actualización en el lugar (in place) escribe en el búfer el mismo ubicación de disco original.
– Shadowing(en la sombra) escribe un búfer actualizado en una ubicación diferente.
– BFIM before image imagen antes de la actualización.
– AFIM after imagen después de la actualización..
 Diseño : Fallas y recuperación
■ Registro antes de la escritura, robar/no-robar y forzar no forzar
■ El mecanismo de recuperación debe garantizar la grabación de la BFIM de los datos en la entrada
apropiada del registro del sistema y que esa entrada se vuelque en el disco antes que la BFIM sea
sobrescrita con la AFIM de la base de datos del disco.
■ Puntos de control (checkpoint) en el registro del sistema y puntos de control difusos
■ En este punto el sistema escribe en la base de datos en disco todos los búferes del DBMS que se
han modificado.
■ No tienen que rehacer sus operaciones, es decir, ESCRIBIR en caso de una caída del sistema.
■ El gestor de recuperaciones de un DBMS debe decidir en qué intervalos tomar un punto de control.
■ La toma de un punto de control consiste en las siguientes acciones:
1. Suspender temporalmente la ejecución de las transacciones.
2. Forzar la escritura de disco de todos los búferes de memoria que se hayan modificado.
3. Escribir un registro [checkpoint] en el registro del sistema y forzar la escritura del registro en
el disco.
4. Reanudar la ejecución de las transacciones..
Diseño : Fallas y recuperación
■ Diarios para Recuperación
■ Se utilizan también los términos log y journal.
■ Mantiene un registro de todas las operaciones que afectan a ítems de la base de datos.
■ Esta información permite recuperar.
■ Se almacena en disco.
■ Operaciones posibles a reflejar:
– [start,T]
– [write,T,X, valor_viejo, valor_nuevo]
– [read,T,X]
– [commit,T]
– [abort,T]
– undo, redo.
Diseño : Fallas y recuperación
■ 1 Técnicas de Recuperación Basadas en la Actualización Diferida
■ Graba todas las actualizaciones de la BD en el diario, pero aplaza la ejecución de todas las
operaciones de escritura (write) de una transacción hasta que ésta se encuentre
parcialmente cometida.
■ Solamente requiere el nuevo valor del dato.
■ Si la transacción aborta (no llega a committed), simplemente hay que ignorar las
anotaciones en el diario.
■ Los Redo comienzan a hacerse en el último checkpoint!
– Recuperación Mediante la Actualización Diferida en un Entorno monousuario El
algoritmo RDU se utiliza un procedimiento rehacer, proporcionado con posterioridad,
Para rehacer determinadas operaciones escribir_elemento.
■ Actualización Diferida con ejecución concurrente en un entorno multiusuario
Planificación de la ejecución de las transacciones Cuando se tomo el punto de control
en el momento t1 la transacción T1 se habría confirmado.
 Diseño : Fallas y recuperación
■ Recuperaciones Basadas en Actualizaciones Inmediatas
■ Permite que las actualizaciones se graben en la BD mientras la transacción está todavía en estado activo
■ Antes de ejecutar un output (X), deben grabarse en memoria estable los registros del diario correspondientes a X.
■ Los registros del diario deben contener tanto el valor antiguo como el nuevo.
■ El esquema de recuperación utiliza dos procedimientos de recuperación:
– undo (Ti): restaura los datos que Ti actualiza a los valores que tenían antes.
– redo (Ti): asigna los nuevos valores a todos los datos que actualiza Ti.
■ Después de ocurrir un fallo, el procedimiento de recuperación consulta el diario para determinar qué transacciones
deben repetirse y cuáles deshacerse:
– Ti debe deshacerse si el diario contiene el registro starts pero no el commit.
– Ti debe repetirse si el diario contiene el registro starts y el commit.
■ Recuperación hasta un punto de validación
1. Examina el diario hacia atrás hasta localizar un registro <checkpoint>.
2. Considera sólo los registros existentes entre este punto y el final del diario.
3. Ejecuta undo(Tj) para las transacciones que no tengan registro <Tj commits>, partiendo del final del fichero.
4. Ejecuta redo (Ti) para las transacciones que tengan su registro <Ti commits>, partiendo desde el punto de
verificación hasta el final del diario.
Diseño : Fallas y recuperación

■ Procedimientos de Recuperación
■ Recuperación Normal
– Tiene lugar después de una parada normal de la máquina, en la que se escribe un
punto de verificación como último registro del diario.
– Se ejecuta cuando el último registro del diario es un punto de verificación o
recuperación del sistema.
– Este tipo de recuperación también tiene lugar cuando aborta una transacción, debido a
la razón que sea.
■ Recuperación en Caliente
– Después de un error del sistema.
– Se ejecuta cuando el último registro del diario no es un punto de verificación y el
operador no indica pérdida de memoria secundaria.
– El procedimiento es el indicado en el apartado referente a los puntos de verificación en
el diario.
Diseño : Fallas y recuperación

■ Procedimientos de Recuperación
■ Recuperación en Frío
– Después de un incidente con la memoria masiva dañada. Se ejecuta si se pierden
datos o la BD ya no es [Link] utiliza:
■ Copia de seguridad (backup) más reciente de la BD (Debe existeir).
■ Diario de las actividades posteriores.
■ Se aplican las imágenes posteriores al respaldo.
– Puede encadenar una recuperación en caliente.
– ·Se deben realizar copias de seguridad de la BD periódicamente:
■ Toda la BD debe copiarse en memoria secundaria.
■ El proceso de transacciones debe pararse durante el procedimiento de copia
(Costoso).
Diseño : Fallas y recuperación
■ Respaldos de Bases de Datos
■ Siempre es necesario tener un respaldo de nuestras bases de datos,
■ Se conoce como transacción toda operación que se haga sobre la base de datos.
■ Las transacciones deben por lo tanto ser controladas de manera que no alteren la
integridad de la base de datos.
■ La recuperación de fallas tiene que ver con la capacidad de un sistema DBMS de
recuperar la información que se haya perdido durante una falla en el software o en el
hardware.
** Diseño : Seguridades y consolidación
■ Seguridad de base de datos distribuidas
■ Se deberían incluir todas las características de seguridad disponibles en un ambiente no
distribuido dentro de un sistema de base de datos distribuido, incluyendo:
– Autentificación de contraseña para usuarios y roles.
– Algunos tipos de autentificación externa para usuarios y roles incluyendo:
■ Kerberos (Subsistema de seguridad, supervisor) conectados a través de links.
■ Paquetes de ingreso encriptados para conexiones, cliente a servidor y servidor a servidor
■ Tópicos adicionales que se deben considerar al configurar un sistema de base de datos:
– Autentificación de base de datos a través de links.
– Autentificación sin contraseñas.
– Soporte a cuentas de usuarios y roles.
– Usuarios centralizados y privilegios de administración.
– Encriptación de datos
Diseño : Seguridades y consolidación
■ Autentificación de base de datos a través de links
– Los links de base de datos pueden ser públicos o privados, autentificados o no
autentificados. Al crear un link público debe especificar la palabra clave PUBLIC
■ Autentificación sin contraseñas
– Cuando se usa un usuario conectado o conexión actual de base de datos de usuario,
se puede utilizar una autentificación externa, tal como los Kerberos, para obtener una
seguridad de punta a punta.
– En la autentificación de punta a punta, las credenciales pasan de un servidor a otro, y
pueden ser autentificados por un servidor de base de datos que pertenece al mismo
dominio.
■ Soporte a cuentas de usuarios y roles
– En un sistema de base de datos distribuido, se debe plantear cuidadosamente la
cuenta de usuario y los roles que son necesarios para que den soporte a aplicaciones
que usan el sistema. Porque:
■ La cuenta de usuario que se establece para las conexiones de servidor a servidor
debe estar disponible en todas las bases de datos del sistema distribuido.
■ Para que las aplicaciones estén disponibles en un sistema distribuido, se deben
tener los roles y privilegios necesarios, y los usuarios deben estar presentes en
todas las bases de datos del sistema distribuido
 Diseño : Seguridades y consolidación
■ Usuarios centralizados y privilegios de administración
– Administración de usuarios empresariales, se puede crear usuarios globales, quienes son
autentificados a través de un SSL o por el uso de contraseñas, entonces se puede manejar a
estos usuarios y sus privilegios dentro de un directorio a través de un servicio de directorio
empresarial independiente.
– Servicio de autentificación de red, esta técnica simplifica la seguridad administrativa de
ambientes distribuidos. Se puede usar las opciones de seguridad avanzada propias de la
base para reforzar la red y la seguridad de sistemas de bases de datos distribuidos.
– Esquemas dependientes de usuarios globales, una opción para centralizar usuario y
administrar privilegios es crear lo siguiente:
■ Un usuario global dentro de un directorio centralizado.
■ Un usuario en cada base de datos al que el usuario global debe conectarse
– Esquemas independientes de usuarios globales, brindar funcionalidad que permite a un
usuario global ser administrado de manera centralizada por un servicio de directorio
empresarial. Los usuarios que son administrados en el directorio empresarial se llaman
usuarios empresariales o usuarios de la empresa. Este directorio contiene información de:
■ Los usuarios empresariales que pueden acceder a las bases de datos en un sistema
distribuido.
■ Los roles que los usuarios de la empresa pueden usar dentro de cada base de datos.
■ Los usuarios empresariales que pueden conectarse a los esquemas de cada base de datos.
Diseño : Seguridades y consolidación

■ Encriptación de datos
– Permiten que los datos no puedan ser leídos o alterados.
– Protege los datos para que no sean vistos usando la seguridad de datos ASL
(Algoritmo de Seguridad de Lectura –RSA Read Security Algorithm) o el algoritmo
AEDE (Algoritmo de Encriptación de Datos Estándar – DES Data Encriptation
Standard).
– Para asegurar que los datos no sean modificados, borrados o reemplazados durante la
transmisión, los servicios de seguridad de la opción avanzada de pueden generar un
código de seguridad encriptado para incluirlo en cada paquete enviado a través de la
red.
** Arquitectura: Cliente – servidor
■ Modelo Cliente-Servidor
■ En el modelo cliente-servidor, el dispositivo que solicita información se denomina “cliente”, y el
dispositivo que responde a la solicitud se denomina “servidor”. Los procesos de cliente y servidor se
consideran parte de la capa de aplicación.
■ El cliente comienza el intercambio solicitando los datos al servidor, quien responde enviando uno o más
streams de datos al cliente.
■ Los protocolos de la capa de aplicación describen el formato de las solicitudes y respuestas entre
clientes y servidores.
■ Este intercambio también puede requerir la autenticación del usuario y la identificación de un archivo de
datos que se vaya a transferir.
■ Un ejemplo de una red cliente-servidor es el uso del servicio de correo electrónico de un ISP para
enviar, recibir y almacenar correo electrónico. El cliente de correo electrónico en una PC doméstica
emite una solicitud al servidor de correo electrónico del ISP para que se le envíe todo correo no leído. El
servidor responde enviando al cliente el correo electrónico solicitado.
■ Aunque los datos se describen generalmente como el flujo del servidor al cliente, algunos datos fluyen
siempre del cliente al servidor.
■ El flujo de datos puede ser el mismo en ambas direcciones, o inclusive puede ser mayor en la dirección
que va del cliente al servidor.
■ Por ejemplo, un cliente puede transferir un archivo al servidor con fines de almacenamiento. La
transferencia de datos de un cliente a un servidor se conoce como “subida” y la transferencia de datos
de un servidor a un cliente se conoce como “descarga”.
Arquitectura: Cliente – servidor

■ .
Arquitectura: Cliente – servidor

■ Las ventajas del lenguaje SQL en arquitecturas cliente/servidor

■ Una ventaja importante del lenguaje SQL es su eficacia en entornos de red, lo que implica
una mejora en el rendimiento del gestor de base de datos.
■ Cuando se emplean servidores de archivos tradicionales, al estilo de las redes clásicas de
PCs, una gran parte del archivo de datos viaja por la red desde el servidor de archivos a la
máquina cliente.
■ Al utilizar en el servidor un gestor de bases de datos SQL, sólo los datos implicados en la
consulta (query) -normalmente un fragmento de tabla o tablas- viajan a la máquina cliente.
Arquitectura: Cliente – servidor
■ ¿Qué hay detrás de la arquitectura cliente/servidor?
■ La capacidad para separar la lógica de la aplicación de la gestión de la base de datos y
repartirlas en dos CPUs, permite a los sistemas cliente disponer de más potencia que a su vez
les permitirá ejecutar los nuevos entornos gráficos, proporcionando al usuario un acceso más
sencillo e intuitivo a la información que necesita.
■ Al mismo tiempo, están disponibles toda una serie de nuevas prestaciones a nivel de gestores
de bases de datos en cuanto a informática distribuida.
■ Gran parte del interés por la informática distribuida se deriva del hecho de que muchas
empresas desean implementar aplicaciones, que antes residían obligatoriamente en
mainframes, en sistemas más pequeños y que están resultando más rápidos, flexibles y, sobre
todo, económicos.
■ Los PCs y las LANs tienen la reputación de no tener los niveles de seguridad ofrecidos por los
sistemas mainframe.
■ La arquitectura cliente/servidor es una solución que combina la docilidad del PC o estación de
trabajo, con la integridad, seguridad y robustez del entorno mainframe.
■ Las bases de datos ubicadas en LANs de PCs utilizan implementaciones del lenguaje SQL, el
lenguaje estándar utilizado en los mainframes.
■ Una vez que los usuarios se encuentran en un entorno cliente/servidor, tienen la libertad
necesaria para crear una arquitectura de aplicaciones económica, flexible, transportable y
abierta a la evolución.
** Arquitectura: Aplicaciones punto a punto
■ Aplicaciones punto a punto
■ Una aplicación punto a punto (P2P) permite que un dispositivo funcione como cliente y como servidor
dentro de la misma comunicación.
■ En este modelo, cada cliente es un servidor y cada servidor es un cliente. Ambos pueden iniciar una
comunicación y se consideran iguales en el proceso de comunicación.
■ Las aplicaciones P2P requieren que cada dispositivo final proporcione una interfaz de usuario y ejecute un
servicio en segundo plano.
■ Cuando inicia una aplicación P2P específica, se cargan los servicios en segundo plano y la interfaz de
usuario requeridos; a continuación, los dispositivos se pueden comunicar directamente.
■ Algunas aplicaciones P2P utilizan un sistema híbrido donde se descentraliza el intercambio de recursos,
pero los índices que apuntan a las ubicaciones de los recursos están almacenados en un directorio
centralizado.
■ En un sistema híbrido, cada punto accede a un servidor de índice para alcanzar la ubicación de un recurso
almacenado en otro punto.
■ El servidor de índice también puede ayudar a conectar dos puntos, pero una vez conectados, la
comunicación se lleva a cabo entre los dos puntos sin comunicación adicional con el servidor de índice.
■ Las aplicaciones P2P se pueden utilizar en redes P2P, en redes cliente/servidor y a través de Internet.
Arquitectura: Aplicaciones punto a punto

■ .
** Arquitectura: Multipunto y muti-database
■ ARQUITECTURA PUNTO A MULTIPUNTOs
■ Esto se ve contrastado con un punto a multipuntos o una topología de comunicación de
emisión, en la que muchos nudos pueden recibir informaciones transmitidas por un único
nudo.
■ El punto a multipuntos generalmente supone que hay una estación de base en la que los
módulos o sensores distantes estén conectados.
■ Seguridad :
– Existe un aislamiento parcial al utilizar múltiples bases de datos
■ Mantenibilidad
– La opción de elegir si queremos tener muchas bases de datos o pocas bases de datos
– Posibilidad de reubicar la información
■ Escalabilidad
– Scale-out y Scale-up son opciones viables — pueden ser distribuidos en múltiples
servidores
– Elegir un balance entre costo (alta densidad / menos servidores) y eficiencia (baja densidad
/ más servidores)
Arquitectura: Multipunto y muti-database

■ .
¿Qué es una base de datos en la nube?

Una base de datos en la nube es un servicio de base

de datos diseñado y al que se accede a través de una
plataforma de cloud computing. Cumple muchas de las
mismas funciones que una base de datos tradicional
con la flexibilidad añadida del cloud computing. Los
usuarios instalan software en una infraestructura de
nube para implementar la base de datos.
FECHA ÚLTIMA REVISIÓN: 13/12/11 CÓDIGO: [Link].260 VERSIÓN: 1.0
 Proveedores de servicios en la nube
Principales proveedores de servicios en la nube:

• Amazon Web Services (AWS): Ofrece una gran variedad de servicios,

incluyendo computación, almacenamiento, bases de datos, análisis, redes,
aplicaciones móviles, herramientas para desarrolladores, IoT y más.
• Microsoft Azure: Proporciona una plataforma flexible y abierta para crear,
implementar y administrar aplicaciones en la nube.
• Google Cloud Platform (GCP): Se destaca por sus servicios de análisis de
datos, inteligencia artificial y machine learning.
• IBM Cloud: Ofrece servicios de nube pública, privada e híbrida, con un
enfoque en soluciones para empresas.
• Oracle Cloud: Proporciona una gama completa de servicios en la nube,
incluyendo bases de datos, aplicaciones y servicios de infraestructura.
• Alibaba Cloud: Líder en China, Alibaba Cloud ofrece una amplia gama de
servicios para empresas de todos los tamaños.
• Red Hat: Especializada en soluciones de código abierto, Red Hat ofrece
servicios de nube pública, privada e híbrida, con un enfoque en la
flexibilidad y la interoperabilidad

FECHA ÚLTIMA REVISIÓN: 13/12/11 CÓDIGO: [Link].260 VERSIÓN: 1.0

 Seguridad en la Nube

Gestión de la Seguridad en la Nube: Implica la implementación de estrategias para

proteger los recursos en la nube, como:
• Identificación y Evaluación de Riesgos: Analizar los servicios en la nube para identificar
posibles vulnerabilidades y amenazas.
• Control de Acceso: Implementar políticas de control de acceso para garantizar que solo
los usuarios autorizados puedan acceder a los recursos en la nube.
• Cifrado: Utilizar técnicas de cifrado para proteger los datos tanto en reposo y en tránsito
• Cumplimiento Normativo: Asegurar que los servicios en la nube cumplen con las
regulaciones y normativas relevantes.
• Monitoreo y Respuesta ante Incidentes: Implementar sistemas de monitoreo para
detectar y responder a incidentes de seguridad de manera oportuna.
Protección en la Nube: Se centra en implementar medidas para mitigar las amenazas y
proteger los activos en la nube, incluyendo:
• Seguridad de Endpoint: Proteger los dispositivos que acceden a la nube contra malware,
ransomware y otros ataques.
• Seguridad de Datos: Implementar medidas para proteger la confidencialidad, integridad
y disponibilidad de los datos almacenados en la nube.
• Seguridad de la Red: Implementar medidas para proteger la infraestructura de red de la
nube contra accesos no autorizados y ataques.
• Seguridad de Aplicaciones: Asegurar que las aplicaciones en la nube estén diseñadas y
configuradas de forma segura para evitar vulnerabilidad

FECHA ÚLTIMA REVISIÓN: 13/12/11 CÓDIGO: [Link].260 VERSIÓN: 1.0

 Monitorización, Migración
Migración a la Nube: Es el proceso de trasladar aplicaciones, datos y otros activos de un entorno
local a la nube. A continuación algunas consideraciones de seguridad:
• Evaluación de Riesgos: Identifica y evaluar los riesgos de seguridad asociados con la migración
• Plan de Seguridad: Desarrollar un plan de seguridad que aborde los riesgos identificados
durante la migración.
• Modelo de Responsabilidad Compartida: Comprender las responsabilidades de seguridad del
proveedor de la nube y del cliente.
• Preparación Previa a la Migración: Asegurar que los sistemas estén actualizados y securizados
antes de la migración.
• Cifrado: Cifrar datos en tránsito y en reposo para protegerlos de accesos no autorizados.
• Control de Acceso: Implementa controles de acceso para proteger los recursos en la nube.
• Monitorización Continua: Supervisar la seguridad y el rendimiento de los recursos en la nube
después de la migración.
Monitorización en la Nube: Implica la supervisión continua de la infraestructura, aplicaciones y
servicios en la nube para detectar problemas y vulnerabilidades y su importancia es:
• Detección Temprana de Problemas: Permite identificar y solucionar problemas de rendimiento,
seguridad o disponibilidad de manera rápida.
• Cumplimiento Normativo: Ayuda a garantizar el cumplimiento de los requisitos de seguridad y
gobernanza.
• Optimización de Recursos: Permite identificar áreas donde se puede optimizar el uso de
recursos y reducir costos.
• Mejora de la Experiencia del Usuario

FECHA ÚLTIMA REVISIÓN: 13/12/11 CÓDIGO: [Link].260 VERSIÓN: 1.0

 MultiCloud databases

• La multicloud es una estrategia de computación en la nube que reúne servicios

de más de un proveedor para satisfacer las necesidades de una organización.
• Una solución multicloud puede integrar IaaS, PaaS y SaaS en una arquitectura
acoplada estrecha o débilmente, y los CIO la ven como una buena manera de
evitar la dependencia de un solo proveedor y obtener la mejor opción para
cada carga de trabajo.
• Una configuración multicloud bien diseñada debe considerar la compatibilidad
del software, capacidades de red, exigencias de rendimiento, redundancia,
seguridad, gestión operativa y costo total de propiedad.
• El conjunto de servicios normalmente se determina según el costo, la
necesidad empresarial y los requisitos de gobernanza de datos.
• Los proveedores de nube a menudo ofrecen servicios gestionados y
herramientas de autoservicio para ayudar a los clientes a tener éxito.
• El objetivo es simplificar el diseño e implementación de soluciones multicloud
mediante la abstracción de la complejidad y el apoyo en la integración.
• Una arquitectura multicloud se da cuando una organización usa múltiples
servicios de nube pública o privada de diferentes proveedores en su pila
tecnológica.
• Los beneficios de una configuración multicloud a menudo dependen del nivel
de integración entre los proveedores y servicios en la nube.

FECHA ÚLTIMA REVISIÓN: 13/12/11 CÓDIGO: [Link].260 VERSIÓN: 1.0

 Principales Bases de Datos para MultiCloud

• Una estrategia multicloud permite a las organizaciones distribuir sus cargas de trabajo
entre múltiples plataformas y proveedores de nube. Esto ayuda a brindar flexibilidad al
elegir la herramienta adecuada para cada tarea.
• Al seleccionar el mejor servicio de nube para cada función, los arquitectos de TI pueden
aprovechar las fortalezas de cada proveedor, incluyendo hardware personalizado,
software y capacidades de servicio.
• Debido a que un enfoque multicloud involucra dos o más proveedores de nube, la gestión
ocurre en múltiples niveles.
• Cada plataforma tiene sus propias herramientas y paneles de administración, que
permiten al equipo de TI supervisar, configurar y ejecutar de manera granular dentro de
ese entorno
In a multicloud architecture, an organization uses several public or
private cloud services from different providers to deliver IT services.

FECHA ÚLTIMA REVISIÓN: 13/12/11 CÓDIGO: [Link].260 VERSIÓN: 1.0