Sistemas de Base de Datos

Distribuidos y Heterogéneos
 INTRODUCCIÓN

Los sistemas de información empezaron a utilizar las bases de datos distribuidas

aproximadamente a mediados de la década de los 70’s, pero no fue sino hasta 1980
cuando la distribución de la información empezó a tomar auge.

Originalmente se había pensado en almacenar la información de manera centralizada

utilizando un conjunto de herramientas que facilitaban este tipo de almacenamiento. Pero
con el paso del tiempo esto produjo ciertos inconvenientes que no eran posibles
solucionar. Estos problemas impulsaron la creación de almacenamiento distribuido, los
cuales hoy en día proveen características indispensables en el manejo de información.

La cantidad de innovaciones tecnológicas que ha habido en los últimos años ha

promovido un cambio en la forma de observar a los sistemas de información y a las
aplicaciones computacionales en general. Un área en la cual las soluciones integran
tecnología con nuevas arquitecturas o formas de hacer las cosas es el área de los
sistemas distribuidos de información. Esto se refiere al manejo de datos almacenados en
diferentes localizaciones, con sitios ligados a través de una red de comunicaciones.
Existe una gran cantidad de sistemas computarizados y distribuidos en múltiples
lugares que se interconectan a través de una red de comunicaciones. Un SBDD es un
sistema capaz de trabajar en forma transparente con datos dispersos en varias base de
datos diferentes, administradas por SMBD distintos, ejecutadas en distintas máquinas,
apoyadas por diversos sistemas operativos y conectadas entre sí, mediante varias redes
de comunicaciones distintas.
En un sistema de base de datos centralizado, todos los componentes del sistema
(datos, software del SMBD, dispositivos de almacenamiento secundario y otros.) residen
en un solo computador o sitio, a diferencia de los sistemas de base de datos distribuidos,
en los cuales los componentes del sistema residen en varias ubicaciones. Esta
distribución causa muchas dificultades en el procesamiento de las transacciones y
consultas.
PROCESAMIENTO DISTRIBUIDO

Consiste en la ejecución distribuida de una tarea entre diversos computadores

que se encuentran interconectados entre sí mediante una red.

SISTEMA DISTRIBUIDO

Se encuentra conformado por un conjunto de elementos de procesamiento

autónomo, no necesariamente homogéneos, los cuales se encuentran
interconectados mediante una red y cooperan en la ejecución de las tareas
asignadas.

BASES DE DATOS DISTRIBUIDAS

Es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales

se encuentran distribuidas entre diferentes sitios interconectados por una red de
comunicaciones, los cuales tienen la capacidad de procesamiento autónomo, lo
cual indica que puede realizar operaciones locales o distribuidas. Una Base de
Datos Distribuida (BDD) es una colección de datos que pertenecen lógicamente a
un sólo sistema, pero se encuentra físicamente esparcido en varios sitios de la
red.

SISTEMA DE BASE DE DATOS DISTRIBUIDO

Un sistema de Bases de Datos Distribuida (SBDD) es un sistema en el cual
múltiples sitios de bases de datos están ligados por un sistema de
comunicaciones, de tal forma que un usuario en cualquier sitio puede acceder a
los datos en cualquier parte de la red exactamente como si los datos estuvieran en
local. En estos sistemas hay múltiples computadores, llamados sitios o nodos, y
deben de estar comunicados por medio de algún tipo de red de comunicaciones
para transmitir datos y órdenes entre los sitios. Cada lugar es un SMBD que puede
operar solo y los usuarios pueden acceder a los datos de cualquier lugar como si
fueran datos locales.
 Los sitios pueden estar cercanos físicamente, es decir en un mismo edificio o
grupo de edificios cercanos y conectados a través de una red de área local o
pueden estar distribuidos geográficamente a grandes distancias y conectados a
través de una red de área amplia. Las redes de área local por lo regular usan
cables y las redes de área amplia emplean líneas telefónicas o satélites.

El tipo y la topología empleada pueden tener un efecto significativo sobre el

rendimiento y por ende sobre las estrategias para el procesamiento de consultas
distribuidas. Sin embargo, en lo referente a los aspectos arquitectónicos de alto
nivel, no importa qué tipo de red se use, sólo importa que cada uno de los sitios
pueda comunicarse directa o indirectamente con todos los demás.

En la siguiente figura puede verse una representación de un sistema de base

de datos distribuido en distintos sitios del mundo. Cada sitio tiene su propio
sistema de base de datos real y local, sus usuarios locales, su Sistema Manejador
de Base de Datos (SMBD), sus programas para administración de transacciones
(bitácoras, recuperación y otros.) y su propio administrador local de
comunicaciones de datos.
 En un sistema como este, un usuario puede realizar operaciones sobre los
datos en su propio sitio local, como si ese sitio no participará en lo absoluto en el
sistema distribuido. De esta manera los sistemas de base de datos distribuidos
pueden considerarse como una especie de sociedad entre los SMBD individuales
locales de todos los sitios.

Un sistema distribuido, debe contar con un catálogo que no sólo indique la

información acerca de las relaciones, índices o usuarios sino también toda la
información de control necesaria para que el sistema pueda ofrecer independencia
con respecto a la fragmentación y replicación, entre otros.

Un SBDD se clasifica como homogéneo si cada lugar tiene el mismo SMBD, de

otro modo se denomina heterogéneo.

SISTEMA MANEJADOR DE BASE DE DATOS DISTRIBUIDO

Es un sistema que permite la gestión de una Base de Datos distribuida de
forma transparente para los usuarios.

La distribución produce un aumento en la complejidad del diseño y en la

implementación del sistema y para que esta se desempeñe satisfactoriamente
debe contar con las funciones de un SMBD centralizado y además con las
siguientes:
o Capacidad de tener acceso a sitios remotos y transmitir consultas y
datos entre los diversos sitios a través de una red de comunicaciones.
o Capacidad de seguir la pista de distribución y replicación de los datos.
o Capacidad de elaborar estrategias de ejecución para consultas y
transacciones que tienen acceso a datos de más de un sitio.
o Capacidad de decidir a qué copia de un elemento de información
replicado se tendrá acceso.
 o Capacidad de mantener la consistencia de las copias de un elemento de
información replicado.
o Capacidad de recuperarse de caídas de sitios individuales y de nuevos
tipos de fallos .

Por sí solas estas funciones elevan la complejidad de un SMBDD en

comparación con un SMBD centralizado. Es difícil incluir todas estas
funcionalidades adicionales y más difícil aún encontrar las soluciones óptimas.

SISTEMA MANEJADOR DE BASE DE DATOS HETEROGÉNEO

La heterogeneidad se puede presentar a varios niveles: hardware, sistema de
comunicaciones, sistema operativo o SMBD. Para el caso de SMBD heterogéneos
ésta se puede presentar debido al modelo de datos, al lenguaje de consultas o a
los algoritmos para manejo de transacciones. Este permite la gestión de una BDD
garantizando la transparencia de ubicación, acceso y procesamiento, de los datos
independientemente de la naturaleza de las fuentes de datos que por lo general
difieren entre sí en cuanto a sus características e implementación.

Una de las principales razones por la que surgen los Sistemas Manejadores de
Base de Datos Heterogéneos (SMBDH), es por la necesidad de integrar
información proveniente de fuentes diversas, donde la heterogeneidad se presenta
en el modelo, en el lenguaje de consultas o en los algoritmos para el manejo de
transacciones.

A través de tecnología de redes de computadoras disponible, la información

almacenada se mantiene distribuida y los SBDD permiten el acceso a ésta como si
estuviera localizada en un solo lugar. La distribución de la información, permite
tener accesos rápidos a la información, tener copia de la información para accesos
más rápidos y para tener respaldo en caso de fallas.
 Los SMBDH deben tener toda la funcionalidad de un SMBDD, pero
adicionalmente debe proveer la tecnología adecuada, para que las distintas bases
de datos se entiendan entre sí, ya que cada SMBD maneja su propio idioma y
surge la necesidad de que alguien entienda todos los idiomas.

CARACTERÍSTICAS DE LOS SISTEMAS DE BASE DE DATOS DISTRIBUIDOS

Autonomía Local: Se refiere a que todas las operaciones en un sitio dado se
controlan en ese sitio, es decir ningún sitio A deberá depender de otro sitio B para
su buen funcionamiento, ya que si B no está en funcionamiento, entonces A
tampoco podrá operar aunque éste no presente ningún problema y además
acceder a B podría convertirse en un cuello de botella si varias estaciones lo
intentan hacer al mismo tiempo. La autonomía local, implica también un propietario
y una administración local de los datos, con responsabilidad local aunque sean
accesibles desde algún sitio remoto.

Operación Continua: En general, el sistema nunca debería necesitar apagarse

para que se pueda realizar alguna función, como añadir un nuevo sitio o instalar
una versión mejorada del SMBD.

Independencia con Respecto a la Localización: Es también conocida como

transparencia en la localización. La idea de esto es que los usuarios no sepan
donde están almacenados los datos físicamente y el sistema debe comportarse
como si todos los datos estuviesen almacenados en su propio sitio local. Esto es
deseable porque simplifica los programas de usuario y sus actividades en el
computador y además permite modificar la distribución de los datos dentro de la
red en respuesta a cambios en los requerimientos de desempeño.

Independencia con Respecto a la Fragmentación: La fragmentación consiste

en dividir, bajo condiciones específicas, una relación en partes con el fin de que
estos fragmentos pueden almacenarse en la localidad donde se utilizan con mayor
frecuencia y así mejorar el desempeño del sistema ya que la mayor parte de las
operaciones serán locales y por ende se reducirá el tráfico de la red.
Adicionalmente los datos fragmentados deben poder unirse o reunirse cuando sea
necesario para formar el dato original (antes de la fragmentación). La idea de la
independencia con respecto a la fragmentación, es que para el usuario sea
transparente que los datos están fragmentados es decir, que si éste solicita ver un
dato que está fragmentado, éste se muestre completo a través de vistas, usando
las operaciones de unión o reunión según el caso. La finalidad de esto es
simplificar los programas de usuario y sus actividades en el computador.

Independencia de Replicación: Un sistema soporta replicación de datos cuando

una tabla almacenada o un fragmento dado de una tabla almacenada, puede ser
representada por muchas copias distintas, o réplicas, almacenadas en muchos
sitios distintos. Las réplicas son necesarias porque mejoran el rendimiento (las
aplicaciones pueden operar sobre copias locales en lugar de tener que
comunicarse con sitios remotos) y además porque permiten una mejor
disponibilidad de la data. La replicación, al igual que la fragmentación, debe ser
transparente para el usuario: los usuarios deben ser capaces de comportarse, al
menos desde el punto de vista lógico, como si los datos en realidad no estuviesen
replicados.

Procesamiento de Consultas Distribuidas: Una consulta puede involucrar bajo

el enfoque distribuido, varios sitios. El objetivo es convertir transacciones de
usuario en instrucciones para manipulación de datos, y así reducir el tráfico en la
red, esto implica que el proceso mismo de optimización de consultas debe ser
distribuido.

Administración de Transacciones Distribuidas: Existen dos aspectos

principales en la administración de transacciones: el control de la recuperación y el
control de la concurrencia. Ambos requieren de un tratamiento amplio en el
ambiente distribuido. En los sistemas distribuidos, una sola transacción puede
involucrar la ejecución de código en muchos sitios. Por lo tanto, se considera que
una transacción tiene varios agentes, donde un agente es el proceso realizado en
nombre de una transacción dada en un sitio dado.

Independencia de Hardware: Las instalaciones de computadoras involucran una

gran diversidad de máquinas diferentes y estaciones de trabajo con diversas
características, existiendo la necesidad de integrar los datos en todos estos
sistemas y presentar al usuario una “imagen de sistema único”. Por lo tanto, es
necesario tener la posibilidad de ejecutar el mismo SMBD en diferentes
plataformas de hardware, y además, hacer que estas máquinas diferentes
participen como “socios igualitarios” en un sistema distribuido.

Independencia de Sistema Operativo: Es necesario no solo tener la posibilidad

de ejecutar el mismo SMBD en diferentes plataformas de hardware, sino también
ejecutarlo en diferentes plataformas de sistema operativo, incluyendo diferentes
sistemas operativos bajo la misma plataforma de hardware.

Independencia de Red: Es necesario tener la posibilidad de soportar también una

variedad de redes de comunicación distintas; esto porque el sistema va a tener la
posibilidad de soportar muchos sitios distintos, con hardware y sistemas
operativos distintos.

Independencia de SMBD: Es necesario que todas las versiones de SMBD en

sitios diferentes soporten la misma interfaz, aunque no tienen que ser
necesariamente copias del mismo software SMBD. El soporte para la
heterogeneidad es necesario. El hecho es que por lo general las instalaciones de
computación emplean no solo muchas máquinas diferentes y muchos sistemas
operativos diferentes, sino que muy frecuentemente, también los SMBD son
diferentes, y donde lo ideal es que esos SMBD puedan participar de alguna forma
en un sistema distribuido.

VENTAJAS
o Un sistema distribuido permite que la estructura de la base de datos refleje
la estructura de la empresa. Es decir, por lo general las empresas ya están
distribuidas lógicamente en divisiones o departamentos y físicamente en
plantas, talleres o laboratorios, por lo que se desprende que en general la
información ya está también distribuida, ya que cada unidad de
organización dentro de la empresa, mantendrá datos pertinentes a su
propio funcionamiento y podrá obtener acceso a datos remotos en caso
necesario.
o Proveen mayor fiabilidad y disponibilidad. Cuando los datos y el software
del SMBD ya están distribuidos en varios sitios, un sitio puede fallar
mientras que los demás siguen operando. Sólo los datos y el software que
reside en el sitio que falló están inaccesibles. Además se logran mejores
resultados si se replican adecuadamente los datos en más de un sitio.
o Son capaces de compartir datos sin perder el control local de los mismos,
es decir, es posible controlar los datos localmente en cada sitio y además
permitir el acceso de sitios remotos a ciertos datos a través del software del
SMBDD.
o Mejoran el rendimiento. Cuando una base de datos grande está distribuida
en múltiples sitios, hay bases de datos más pequeñas en cada uno de
éstos. En consecuencia, las consultas locales y las transacciones que
tienen acceso a datos de un solo sitio tienen un mejor rendimiento porque
las bases de datos locales son más pequeñas. Además, cada sitio tiene un
menor número de transacciones en ejecución que si todas las
transacciones se enviaran a una sola base de datos centralizada.
DESVENTAJAS
o La distribución produce un aumento en la complejidad del diseño y en la
implementación del sistema.
o Incrementa el costo en tiempo y dinero de enviar un mensaje desde un
punto a otro.
o Aumenta el costo de enlazar físicamente cada sitio .

o Dado a que los datos 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.

o La habilidad para asegurar la integridad de la información en presencia de

fallas no predecibles tanto de componentes de hardware como de software
es compleja. La integridad se refiere a la consistencia, validez y exactitud
de la información.
o 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.

ALMACENAMIENTO DE DATOS DISTRIBUIDOS

o TÉCNICA DE FRAGMENTACIÓN
Un sistema maneja la fragmentación de los datos si es posible dividir una
relación en partes o fragmentos para propósitos de almacenamiento físico. Los
fragmentos contienen suficiente información como para permitir la reconstrucción
de la relación original. La fragmentación es deseable por razones de desempeño,
ya que los datos pueden almacenarse en la localidad donde se utilizan con mayor
frecuencia, de manera que la mayor parte de las operaciones sean sólo locales y
se reduzca el tráfico de la red. Hay tres esquemas diferentes para fragmentar una
relación: fragmentación horizontal vertical y mixta.
 Fragmentación Horizontal: Divide una relación horizontalmente agrupando
filas mediante una condición sobre uno o más atributos de la relación, para crear
subconjuntos de tuplas, donde cada subconjunto tiene cierto significado lógico.
Estos fragmentos pueden asignarse a diferentes sitios del sistema distribuido. Se
puede obtener la reconstrucción de una relación tomando la unión de todos los
fragmentos. Para ejemplificar esto se tiene la relación cuenta que contiene tuplas
de cuentas que pertenecen a una sucursal específica, la cual se fragmentará
horizontalmente por sucursal, lo que traerá como consecuencia que se originen
dos fragmentos de la siguiente manera:

Relación Cuenta
Nombre_Sucursal Nro_Cuenta Saldo
Caracas 123 100.000
Valencia 456 500.000
Valencia 789 7.000.000
Caracas 147 2.000.000
Valencia 258 40.500
Caracas 369 700.000
Caracas 159 10.000

Fragmentación Horizontal de la Relación Cuenta

Nombre_Sucursal Nro_Cuenta Saldo
Caracas 123 100.000
Caracas 147 2.000.000
Caracas 369 700.000
Caracas 159 10.000

Nombre_Sucursal Nro_Cuenta Saldo

Valencia 123 500.000
Valencia 456 7.000.000
Valencia 789 40.500
 Fragmentación Vertical: La fragmentación vertical divide una relación
verticalmente en columnas y mantiene sólo ciertos atributos de la relación. La
fragmentación vertical no es del todo apropiada porque si los fragmentos se
almacenan por separado, no se pueden juntar otra vez las tuplas originales ya que
no existe un atributo común entre los fragmentos. Es necesario incluir un atributo
de clave primaria en todo fragmento vertical para que sea posible reconstruir la
relación completa a partir de los fragmentos. Para ejemplificar esto se contará con
la relación depósito que contiene los atributos: Nombre_Sucursal, Nro_Cuenta,
Nombre_Cliente y Saldo, pero adicionalmente y para garantizar la reconstrucción
de la relación luego de ser fragmentada se debe añadir un atributo llamado Id, que
identificará unívocamente a cada tupla. En el siguiente ejemplo, la relación se
fragmenta en dos, teniendo por un lado Nombre_Sucursal y Nombre_Cliente y por
el otro Nro_Cuenta y Saldo. En ambas se tiene el atributo Id. La fragmentación
queda de la siguiente manera:
Relación Depósito
Nombre_Sucursal Nro_Cuenta Nombre_Cliente Saldo Id
Caracas 123 Pedro 100.000 1
Valencia 456 Luis 500.000 2
Valencia 789 Mary 7.000.000 3
Caracas 147 Jesús 2.000.000 4
Valencia 258 Laura 40.500 5
Caracas 369 Carlos 700.000 6
Caracas 159 Enrique 10.000 7

Fragmentación Vertical de la Relación Depósito

Nombre_Sucursal Nombre_Cliente Id
Caracas Pedro 1
Valencia Luis 2
Valencia Mary 3
Caracas Jesús 4
Valencia Laura 5
Caracas Carlos 6
Caracas Enrique 7
 Nro_Cuenta Saldo Id
123 100.000 1
456 500.000 2
789 7.000.000 3
147 2.000.000 4
258 40.500 5
369 700.000 6
159 10.000 7

Fragmentación Mixta: Se puede entremezclar los dos tipos de

fragmentación para obtener una fragmentación mixta. Para representar esto se
puede suponer que se cuenta con la relación depósito luego de ser fragmentada
verticalmente. Entonces una vez que se obtienen los dos fragmentos, éstos se
pueden volver a fragmentar pero horizontalmente siguiendo alguna condición
específica.

o REPLICACIÓN DE LOS DATOS

Consiste en crear varias copias idénticas de los datos para ser guardados en
diferentes sitios. La replicación es útil para mejorar la disponibilidad de los datos
para transacciones de solo lectura, ya que si falla uno de los sitios donde está
cierta relación se contará con otro sitio que tenga una réplica de ésta relación.
También mejora el rendimiento de la obtención de datos en consultas. Sin
embargo, las transacciones de actualización originan una sobrecarga mayor. Se
puede tener una replicación completa de la base de datos, aumentando más aún
la disponibilidad de los datos e incrementando la sobrecarga y reduciendo
drásticamente la rapidez de las operaciones de actualización. El extremo opuesto
a la replicación completa es no tener ninguna replicación, lo cual no siempre es lo
más conveniente.
 El número de copias puede ir desde uno hasta el número total de sitios en el
sistema distribuido. La elección de sitios y el grado de replicación dependen de los
objetivos de rendimiento y disponibilidad para el sistema.

o REPLICACIÓN Y FRAGMENTACIÓN DE DATOS

La replicación y la fragmentación de los datos pueden aplicarse de manera
sucesiva a la misma relación, es decir, se replica un fragmento y las réplicas de los
fragmentos se pueden volver a fragmentar.

PROCESAMIENTO DE CONSULTAS DE DATOS DISTRIBUIDOS

Para el procesamiento distribuido se deben tomar en cuenta varios factores,
entre ellos el costo de la transmisión de los datos por la red. Los datos incluyen los
archivos intermedios que se transfieren a otros sitios para continuar su
procesamiento, así como los archivos de resultado final que tal vez deben
transferirse al sitio donde se necesita el resultado de la consulta. Aunque es
posible que estos costos no sean demasiado altos si los sitios están conectados
en una red de área local de alto rendimiento, adquieren una importancia
considerable en otros tipos de redes. Por ello, los algoritmos de optimización de
consultas de los SMBDD consideran el objetivo de reducir la cantidad de
transferencia de datos como criterio de optimización al elegir una estrategia de
ejecución de una consulta distribuida.

Una estrategia más compleja que a veces funciona mejor es usar la

operación llamada semi reunión, la cual se basa en la idea de reducir el número
de tuplas de una relación antes de transferirla a otro sitio.
FALLAS EN LOS SISTEMAS DISTRIBUIDOS
Los sistemas distribuidos pueden sufrir los mismos tipos de fallos que los
sistemas centralizados como errores de software, de hardware o de disco, pero
adicionalmente se pueden presentar fallos de un sitio o de un enlace de
comunicaciones o pérdida de mensajes.

Para que un sistema distribuido sea robusto debe detectar los fallos, volver a
configurar el sistema para que el proceso pueda continuar y debe recuperarse
cuando se repare el enlace. Los diferentes tipos de fallos se tratan de manera
diferente, la pérdida de mensajes se trata mediante la retransmisión. Si se
retransmite sucesivamente un mensaje y no se recibe un acuse de recibo, puede
ser síntoma de fallo del enlace y para solventar esto la red trata de encontrar una
ruta alternativa para el mensaje. Si un sitio falla, el SMBDD debe seguir operando
con los sitios activos y el sitio que falló debe iniciar un procedimiento que permita
al sistema volver a configurarse y continuar con el modo normal de
funcionamiento. Además se debe tomar en cuenta lo siguiente:
● Si se guardan datos replicados en el sitio que fallo, hay que actualizar el
catálogo para que las consultas no hagan referencia a la copia ubicada en
el mismo
● Si estaban activas las transacciones en el sitio afectado por el fallo en el
momento del mismo, hay que abortarlas. Es deseable abortar estas
transacciones lo antes posible dado que pueden tener bloqueos sobre
datos en sitios que sigan activos

La reincorporación de un sitio o un enlace reparado al sistema, debe hacerse

tomando en cuenta las siguientes precauciones:
● El sitio recuperado de la falla debe iniciar un procedimiento para actualizar
sus tablas de sistema para reflejar los cambios realizados mientras estaba
sin conexión.
 ● Si el sitio tenía réplicas de algunos elementos de datos, deberá obtener los
valores actualizados de dichos elementos y asegurarse de que recibirá
todas las actualizaciones posteriores

PROTOCOLO DE RECUPERACIÓN
Para recuperarse existen varios protocolos. Commit en 2 fases es el
protocolo de recuperación más sencillo y más ampliamente usado para sistemas
distribuidos.
El control de la recuperación en los sistemas distribuidos se basa por lo
general en este protocolo, el cual es obligatorio en cualquier ambiente donde una
sola transacción puede interactuar con varios SMBD locales, pero tienen especial
importancia en un sistema distribuido porque los SMBD locales operan en sitios
distintos.
Como las transacciones tienen que ser atómicas, entonces si una
transacción T termina normalmente sus actualizaciones deben ser garantizadas en
todos los sistemas y si falla debe hacerse ROLLBACK en todos los sistemas.
Existe un coordinador y los manejadores se denominan participantes. Este
protocolo consta de dos fases.
Fase I: El coordinador solicita a los participantes que vayan a un estado en
el que ellos puedan ir adelante con la transacción, es decir cada participante debe
forzar todos los registros de la transacción al LOG, si todo estuvo bien el
participante responde OK al coordinador. En caso contrario responde NO OK. Si
ocurre un Time Out también se asume NO OK.
Fase II: Si todos responden OK, el coordinador difunde el mensaje
COMMIT a todos los participantes, y éstos colocan un COMMIT en su LOG local.
En caso contrario el coordinador difunde ROLLBACK a todos los participantes y se
deshacen los efectos de la transacción en su LOG local.
Tipos de Fallas y su Recuperación
● Falla de un Participante: Cuando se recupera de la falla debe examinar su
LOG para determinar el destino de las transacciones que se estaban
ejecutando. Si existe en el LOG el registro COMMIT ejecuta Redo(T). Si
existe un registro ABORTAR ejecuta Undo(T). Si sólo existe un registro OK
debe consultar al coordinador el destino de esa transacción.
● Falla del Coordinador: Cuando se recupera se debe decidir si hace
COMMIT o ABORT a todas las transacciones que estaba coordinando. Y
antes de que se recupere los participantes pueden decidir qué hacer. Se
puede decidir hacer COMMIT(T) si existe algún participante activo que
contenga en el LOG el registro COMMIT. Se aborta si alguna localidad
activa tiene en su LOG algún registro NO OK o ABORT para la transacción
T.

CONTROL DE CONCURRENCIA
Las técnicas del control de la concurrencia deben resolver los problemas antes
mencionados. En la mayor parte de los sistemas distribuidos el control de
concurrencia se basa en el bloqueo, tal como sucede en los sistemas no
distribuidos. Pero en un sistema distribuido las solicitudes de prueba,
establecimiento y liberación de bloqueos se convierten en mensajes y estos
implican costos adicionales. Entre las técnicas más usadas se tienen las
siguientes:
o PROTOCOLOS DE BLOQUEO
GESTOR DE BLOQUEO ÚNICO: El sistema conserva un único
gestor de bloqueo que reside en un único sitio seleccionado. Todas
las solicitudes de bloqueo y desbloqueo se realizan en el sitio.
Cuando una transacción necesita bloquear un elemento de datos,
envía al sitio seleccionado una solicitud de bloqueo. El gestor de
bloqueo determina si se puede conceder el bloqueo de manera
inmediata. Si se puede conceder el bloqueo, el gestor de bloqueo
envía un mensaje al respecto al sitio en que se inició la solicitud de
bloqueo. La transacción puede leer el elemento de datos desde
cualquiera de los sitios en que residan réplicas del elemento de
datos. En caso de escritura, todos los sitios en los que residan
réplicas del elemento de datos deben quedar implicados en la
escritura. Las ventajas de éste enfoque es que su implementación
es sencilla, porque sólo exige dos mensajes para tratar las
solicitudes y uno para tratar las de desbloqueo otra ventaja es que el
tratamiento de los interbloqueos es sencillo, ya que todas las
solicitudes de bloqueo y desbloqueo se realizan en un solo sitio. Una
de las desventajas de éste método es que el lugar donde se realizan
las solicitudes de bloqueo o desbloqueo se convierte en un cuello de
botella, ya que todas las peticiones se deben procesar allí. Otra
desventaja es que si el sitio donde se realizan las solicitudes de
bloqueo o desbloqueo falla, entonces se pierde el control de la
concurrencia. Se debe detener el procesamiento o se debe utilizar un
esquema de recuperación para que un nuevo lugar pueda asumir la
gestión de los bloqueos.

VARIOS GESTORES: Este enfoque busca mejorar la segunda

desventaja del método anterior, por lo que designa dos o más sitios
como sitios de respaldo. Toda la información de bloqueo se mantiene
tanto en el sitio primario como en los de respaldo. Cada gestor de
bloqueo reside en un sitio diferente. Este enfoque disminuye la
condición de cuello de botella, pero hace más complicado el
tratamiento de los interbloqueos, dado que las solicitudes de bloqueo
o desbloqueo no se realizan en un solo lugar.

PROTOCOLO DE SESGADO: En este enfoque cada sitio conserva

un gestor local de bloqueo cuya función es gestionar las solicitudes
 de bloqueo y desbloqueo de los elementos de datos guardados en
ese lugar. Las solicitudes de bloqueos compartidos reciben un
tratamiento más favorable que la de los bloqueos exclusivos. En los
bloqueos compartidos, cuando una transacción necesita bloquear un
elemento de datos simplemente solicita un bloqueo sobre ese dato al
gestor de bloqueo de un sitio que contenga una réplica de éste. En
los bloqueos exclusivos, cuando una transacción necesita bloquear
un elemento de datos, solicita un bloqueo sobre éste al gestor de
bloqueo de todos los lugares que contienen réplicas del elemento de
datos. La respuesta a la solicitud se pospone hasta que se pueda
conceder. Este esquema tiene la ventaja de imponer menos
sobrecarga a las operaciones de lectura. Este ahorro es significativo
cuando se hacen más operaciones de lectura que de escritura, sin
embargo, la sobrecarga añadida de las operaciones de escritura es
un inconveniente.

SISTEMAS MANEJADORES DE BASE DE DATOS DISTRIBUIDAS

COMERCIALES
Los procedimientos ejecutados y almacenados en el servidor generalmente
efectúan una secuencia de consultas y regresan sus respuestas a través de un
procedimiento remoto. Ellos son: Sybase, Informix, Oracle, entre otros. Ellos
logran aislar las BD de las estructuras y lenguajes soportados en la BD servidor,
aumentando la autonomía y formando una base para la integración de BD
servidoras heterogéneas.
Un cliente puede estar conectado simultáneamente a varios servidores de
BD. La correlación de los datos de varias fuentes es responsabilidad del cliente.
Un SMBDD ofrece las facilidades para manejar la transparencia de red y manejo
distribuido de una transacción.
 CONCLUSIONES

Un sistema distribuido de base de datos consiste en una colección de

localizaciones, cada uno de los cuales mantiene un sistema local de base de datos
y cada uno puede procesar las transacciones locales, es decir manejar las
transacciones que sólo tienen acceso a ese único sitio. Además un lugar puede
participar en la ejecución de las transacciones globales, es decir transacciones
que tienen acceso a datos en varios lugares. La ejecución de las transacciones
globales exige que haya comunicación entre los lugares involucrados. Los sitios
pueden estar cercanos físicamente (dentro de un mismo edificio) y conectados a
través de una red de área local o pueden estar distribuidos geográficamente a
grandes distancias y conectados a través de una red de área amplia. Las redes de
área local por lo general usan cables, mientras que las de área amplia emplean
una línea telefónica o satélite. También es posible usar una combinación de ambos
tipos de redes. Las redes pueden tener diferentes topologías como estrella, anillo,
árbol, completamente conectadas, parcialmente conectadas, entre otras.
Hay varias razones para construir sistemas distribuidos de base de datos,
incluyendo el comportamiento de los datos, la fiabilidad, la disponibilidad y la
aceleración del procesamiento de consultas. Sin embargo junto con estas
ventajas, se presentan varios inconvenientes incluyendo el mayor costo del
desarrollo del software, la mayor posibilidad de fallos y el incremento de la
sobrecarga de procesamiento. El principal inconveniente de los sistemas
distribuidos de base de datos es la complejidad añadida, necesaria para asegurar
la correcta coordinación entre los diferentes sitios.
En los sistemas distribuidos debe poderse fragmentar los datos según
condiciones específicas y replicarse para poder ser almacenados en diversos
lugares, en caso de ser necesario. Estos sistemas pueden sufrir las mismas fallas
que los sistemas centralizados, sin embargo hay que tomar en cuenta otras fallas,
incluyendo las fallas en un sitio, fallas en el enlace y pérdida del mensaje, entre
otras. El sistema debe detectar estas fallas y además solventarlas. Para la
recuperación se usa el protocolo de Commit en 2 fases.
Bases de Datos

Esp. Eduardo Fabián Tossolini

BASES DE DATOS
DISTRIBUIDAS
 BASES DE DATOS DISTRIBUIDAS
En un sistema de base de datos centralizado todos los componentes
del sistema residen en un único ordenador denominado servidor de
base de datos.

Existen organizaciones que requieren aplicaciones que tienen una

naturaleza distribuida (compañías de transportes con centros de
logística en varias ciudades, o bancos con varios centros de
procesamiento de operaciones) y requieren bases de datos
distribuidas.
 BASES DE DATOS DISTRIBUIDAS

Sistema de computación distribuido:

● Gran número de elementos de procesamiento

● No necesariamente homogéneos

● Interconectados mediante una red de computadores

● Cooperan para la realización de ciertas tareas asignadas.

 BASES DE DATOS DISTRIBUIDAS

Base de Datos Distribuida (DDB): colección de múltiples bases de

datos distribuidas interrelacionadas de forma lógica sobre una red de
computadores.

Sistema de administración de bases de datos distribuidas

(DDBMS): software encargado de administrar la base de datos
distribuida mientras hace la distribución transparente para el usuario.
 BASES DE DATOS DISTRIBUIDAS
Características de los sistemas de bases de datos distribuidas
 BASES DE DATOS DISTRIBUIDAS

Autonomía local de los nodos:

La autonomía permite que todas las decisiones que afectan a un
nodo se decidan en ese nodo y que no dependa de otros para
ejecutar sus propias operaciones.
Los SBDD con mayor nivel de autonomía son los sistemas
federados.
 BASES DE DATOS DISTRIBUIDAS
Heterogeneidad de datos y sistemas:
Los nodos que componen un SBDD, pueden utilizar diferentes
sistemas hardware, protocolos de red, lenguajes de consulta,
protocolos de control de transacciones, e incluso diferentes
modelos de datos como puede ser el relacional y el orientado a
objetos.
Un SGBDD puede soportar diferentes niveles de heterogeneidad
haciendo que todos los problemas que eso conlleva sean
transparentes para los usuarios.
 BASES DE DATOS DISTRIBUIDAS
Distribución de los datos:
Según la manera en que se distribuyen los datos, los SBDD se
pueden dividir en dos grupos.

Sistemas peer-to-peer o totalmente distribuidos, donde cada nodo

de la red es un SGBD totalmente funcional, que además tiene la
capacidad de poderse comunicar con otros nodos para ejecutar
consultas y transacciones.

Sistemas cliente/servidor, clasifican los nodos del SBDD en dos

grupos separados: los nodos servidores y los nodos cliente.
 BASES DE DATOS DISTRIBUIDAS

Ventajas de las bases de datos distribuidas:

Administración de datos distribuidos con distintos niveles

de transparencia.

● Un DBMS debe ser una distribución transparente en el

sentido de ocultar los detalles de dónde está físicamente
ubicado cada fichero (tabla, relación) dentro del sistema.
 BASES DE DATOS DISTRIBUIDAS

Ventajas de las bases de datos distribuidas:

Transparencia de red o de distribución.

● Un DBMS debe ser transparente para el usuario de los

detalles operacionales de la red. Puede dividirse en
transparencia de localización y de denominación.
 BASES DE DATOS DISTRIBUIDAS

Ventajas de las bases de datos distribuidas:

Transparencia de replicación.

● Un DBMS debe poder almacenar copias de los datos en

distintos lugares para permitir una mayor disponibilidad,
rendimiento y fiabilidad.
 BASES DE DATOS DISTRIBUIDAS

Ventajas de las bases de datos distribuidas:

Transparencia de fragmentación.
Existen dos posibles tipos de fragmentación, horizontal a nivel
de tuplas (filas) y vertical a nivel de columnas.

● Un DBMS debe poder ocultar la fragmentación permitiendo

que el usuario no se entere de la existencia de fragmentos.
 BASES DE DATOS DISTRIBUIDAS

Ventajas de las bases de datos distribuidas:

Transparencia de diseño y de ejecución.

Esta ventaja hace referencia al hecho de saber cómo está
diseñada la base de datos distribuida y dónde ejecuta una
transacción.
 BASES DE DATOS DISTRIBUIDAS
Ventajas de las bases de datos distribuidas:

Incremento de la fiabilidad y la disponibilidad.

Cuando los datos y el software DBMS están distribuidos a lo
largo de distintas localizaciones, uno de ellos puede fallar,
mientras el resto continúa operativo.

Esta ventaja permite que sólo los datos y el software

almacenados en la localización que falla serán los que no
estén disponibles.
 BASES DE DATOS DISTRIBUIDAS

Ventajas de las bases de datos distribuidas:

Rendimiento mejorado.
La distribución de los datos a lo largo de varias localizaciones, da
como resultado bases de datos más pequeñas.
Como resultado, las consultas locales y las transacciones de
acceso a los datos de uno de estos sitios tienen un mayor
rendimiento debido al menor tamaño de esas bases de datos.
 BASES DE DATOS DISTRIBUIDAS

Ventajas de las bases de datos distribuidas:

Expansión más sencilla.

En un entorno distribuido, la expansión del sistema en términos de
incorporación de más datos, incremento del tamaño de las bases
de datos o la adición de más procesadores es mucho más sencilla.
 BASES DE DATOS DISTRIBUIDAS
Funciones adicionales de las bases de datos distribuidas:
Seguimiento de los datos. La capacidad de controlar la distribución de
los datos, la fragmentación y la replicación expandiendo el catálogo
DDBMS.

Procesamiento de consultas distribuidas. La posibilidad de acceder

a sitios remotos y de transmitir consultas y datos a lo largo de todos
esos sitios mediante una red de comunicación.
 BASES DE DATOS DISTRIBUIDAS
Funciones adicionales de las bases de datos distribuidas:
Administración de transacciones distribuidas. La facultad de diseñar
estrategias de ejecución de consultas y transacciones que accedan a
los datos desde más de una ubicación y de sincronizar el acceso a los
datos distribuidos y de mantener la integridad de toda la base de datos.

Administración de datos replicados. La capacidad de decidir a qué

copia de un dato acceder y de mantener la consistencia de las copias
de un elemento de datos replicado.
 BASES DE DATOS DISTRIBUIDAS

Funciones adicionales de las bases de datos distribuidas:

Recuperación de una base de datos distribuida. La facultad de
recuperarse de las caídas de una localización individual u otro tipo de
fallos, como los fallos en los enlaces de comunicación.

Seguridad. Las transacciones distribuidas deben ejecutarse con una

adecuada administración de la seguridad de los datos y contando con
los privilegios de autorización/acceso de los usuarios.
 BASES DE DATOS DISTRIBUIDAS

Funciones adicionales de las bases de datos distribuidas:

Administración del directorio (catálogo) distribuido. Un directorio

contiene información (metadatos) sobre los datos de la base de datos.
Puede ser global a toda la DDB, o local para cada sitio.
La ubicación y distribución del directorio son temas relacionados con el
diseño y las políticas.
 BASES DE DATOS DISTRIBUIDAS
A nivel de hardware existen los siguientes factores que distinguen un
DDBMS de un sistema centralizado:

Existen múltiples computadores llamados sitios o nodos.

Estos sitios deben estar conectados por algún tipo de red de
comunicación para transmitir los datos y los comandos entre ellos.
 BASES DE DATOS DISTRIBUIDAS

Etapas del diseño de SBDD:

Estrategias ascendentes.
Estrategias descendentes.
BASES DE DATOS DISTRIBUIDAS

Integración de fuentes de datos heterogéneos

 BASES DE DATOS DISTRIBUIDAS

Arquitecturas para integrar información distribuida

Existe una gran variedad de arquitecturas que permiten la

integración de información distribuida.
A continuación se mencionan cinco arquitecturas ordenadas de
menor a mayor según el nivel de integración de datos que
proporcionan.
 BASES DE DATOS DISTRIBUIDAS

Interfaz de integración. El usuario o aplicación del sistema cuenta

con una interfaz para acceder a los datos distribuidos que una vez
recuperados son visualizados.
 BASES DE DATOS DISTRIBUIDAS

Middleware de integración. Los usuarios y las aplicaciones

del sistema disponen de diferentes herramientas middleware para
ejecutar algunas de las funciones de integración de datos.
 BASES DE DATOS DISTRIBUIDAS

Esquema de integración virtual. Los usuarios y las aplicaciones

acceden a los datos integrados a través de un esquema de datos
global que realiza una integración virtual.
 BASES DE DATOS DISTRIBUIDAS
Arquitectura de servicios web. La principal diferencia de esta
arquitectura con respecto a la anterior, es que el acceso a las
fuentes de datos se realiza por medio de servicios web en lugar de
de recubridores.
 BASES DE DATOS DISTRIBUIDAS

Almacén de datos común. Las aplicaciones y los usuarios

reciben datos ya integrados, a los que acceden a través de un
esquema global que se materializa en un almacén de datos común.
por su atención
Bases de Datos

Esp. Eduardo Fabián Tossolini

 SEGURIDAD DE LOS DATOS. INTEGRIDAD Y CONTROL

AMENAZAS A LAS BASES DE DATOS

Las amenazas a las bases de datos están relacionadas con:
● Pérdida de integridad.
● Pérdida de disponibilidad.
● Pérdida de confidencialidad.

Pérdida de integridad.
La información debe ser protegida de intentos de modificaciones inadecuadas.
La integridad se pierde si se realizan cambios no autorizados en los datos mediante acciones
intencionadas o accidentales.
La modificación de datos incluye la creación, inserción, modificación, cambio del estado de los datos y el
borrado.

Pérdida de disponibilidad.
La disponibilidad de la base de datos consiste en garantizar que los datos estén disponibles para un
usuario o para un programa que tenga los permisos correspondientes.

Pérdida de confidencialidad.
La información de la base de datos debe ser protegida de accesos no autorizados.
El impacto del acceso no autorizado a la información confidencial puede variar desde la violación de las
leyes sobre privacidad de los datos hasta la amenaza a la seguridad nacional.
El acceso no autorizado, podría tener como resultado la pérdida de la confianza en la organización, que
la misma vea afectada su reputación y se sea objeto de acciones legales en su contra.

Protección de las bases de datos

Para proteger las bases de datos contra las amenazas, es necesario implementar medidas de control
como:
● Control de accesos,
● Control de inferencias,
● Control de flujo
● Cifrado.
En un sistema de base de datos multiusuario, el DBMS debe proporcionar técnicas que permitan a
determinados usuarios o grupos de usuarios el acceso a partes concretas de una base de datos sin tener
acceso al resto de la misma BD.

Por ejemplo, la información confidencial, como los salarios de los empleados o las evaluaciones de
rendimiento de los mismos, deberían permanecer como confidenciales para la mayoría de los usuarios
del sistema de base de datos.

Para implementar controles un DBMS debe incluir un subsistema de autorizaciones y seguridad en la

base de datos responsable de garantizar la seguridad de partes de una base de datos frente a accesos
no autorizados.
Podemos mencionar dos tipos de mecanismos de seguridad en bases de datos:
Mecanismos de seguridad discrecionales.
Permiten conceder permisos a usuarios, incluyendo la capacidad de acceso a determinados
archivos de datos, registros o campos en un modo en concreto (lectura, inserción, borrado o
actualización).
Mecanismos de seguridad obligatorios.
Permiten brindar seguridad por niveles mediante la clasificación de los datos y de los usuarios en
varias clases de seguridad (o niveles) para después implementar la política de seguridad
adecuada a la organización.
Por ejemplo, una política de seguridad habitual es permitir a los usuarios de un determinado nivel de
clasificación ver sólo los elementos de datos clasificados en el mismo (o menor) nivel de clasificación que
el del usuario.
Una extensión a esto es la seguridad basada en roles, en la cual se refuerzan las políticas y permisos
basándose en el concepto de roles.

Seguridad de la bases de datos

DBA( Administrador de la Base de Datos) y la seguridad de la Base de Datos.
El DBA( Administrador de la Base de Datos) es el responsable de la seguridad general del sistema de
bases de datos.
El DBA dispone de una cuenta en el DBMS, denominada como cuenta de sistema o de superusuario, que
proporciona todos los privilegios disponibles en la base de datos
Para garantizar la seguridad el DBA( Administrador de la Base de Datos) realiza las siguientes acciones:
● Creación de cuentas. Esta acción crea una nueva cuenta y contraseña para posibilitar el
acceso al DBMS a un usuario o grupo de usuarios.
● Concesión de privilegios. Esta acción permite al DBA conceder determinados permisos a
determinadas cuentas.
 ● Quita de privilegios. Esta acción permite al DBA retirar (cancelar) determinados permisos
concedidos previamente a determinadas cuentas.
● Asignación del nivel de seguridad. Esta acción consiste en asignar cuentas de usuario al
nivel de clasificación de seguridad adecuado.

Protección de accesos
Cuentas de usuarios.
Las cuentas de usuarios deben almacenarse en una tabla cifrada y borrarse en el momento de cancelar
una cuenta.
Es fundamental que el sistema de base de datos realice un seguimiento del rastro de todas las
operaciones en la base de datos que un usuario determinado realice durante cada sesión. Esto
comprende toda la secuencia de interacciones realizadas por ese usuario en la base de datos desde el
momento en que inicia la sesión hasta el momento en que la finaliza.

Auditoría de la BD.
Las auditorías en la base de datos son muy importantes en el caso de bases de datos con información
confidencial que sean actualizadas por un gran número de transacciones y usuarios, como una base de
datos bancaria que puede ser actualizada por un gran número de cajeros del banco.
Un registro de una base de datos que se utilice para propósitos de seguridad se lo denomina registro de
auditoría.
Es muy importante seguir el rastro de las operaciones de actualización que se realicen sobre la base de
datos, de modo que el DBA pueda determinar qué usuario provocó el daño en el caso de que la base de
datos sea modificada de forma malintencionada.
Para mantener un registro de todas las actualizaciones realizadas en la base de datos por los usuarios se
puede modificar el registro de sucesos del sistema (system log). Es posible expandir las entradas del
registro de forma que incluya también en el registro el número de cuenta del usuario y el identificador del
terminal desde el que se realizó la operación.
Si se sospecha de alguna modificación malintencionada, se debe realizar una auditoría de la base de
datos.
La auditoría consiste en la revisión del archivo de registro (logs) para examinar todos los accesos y
operaciones realizadas sobre la base de datos durante un determinado período de tiempo.
Cuando se encuentre una operación ilegal o no autorizada, el DBA podrá determinar el número de cuenta
utilizado para realizar la operación.

Las diferentes amenazas a las bases de datos pueden provocar pérdida de integridad, disponibilidad y
confidencialidad de la información.
Las medidas de control que permiten mitigar las mismas son: control de accesos, control de inferencias,
control de flujo y cifrado.
La seguridad de la BD tiene relación con el control de los accesos al sistema de base de datos en su
totalidad y con el control de la autorización para acceder a determinadas partes de una base de datos.
La seguridad de la BD tiene relación con el control de los accesos al sistema de base de datos en su
totalidad y con el control de la autorización para acceder a determinadas partes de una base de datos.
Esto se realiza habitualmente mediante la asignación de cuentas con contraseñas a los usuarios. También
utilizando un sistema de concesión y revocación de privilegios a cuentas individuales para acceder a partes
concretas de la base de datos.

Se debe tener presente que las bases de datos modernas enfrentan grandes desafíos en relación a la
seguridad y privacidad de los datos, donde la calidad de los datos, los derechos de propiedad intelectual y
la supervivencia de los datos, son solo algunos ejemplos de grandes retos que enfrentan las mismas.
Bases de Datos

Esp. Eduardo Fabián Tossolini

 BASES DE DATOS
SEGURIDAD DE LOS DATOS
AMENAZAS A LAS BASES DE DATOS

Pérdida de integridad.

Pérdida de disponibilidad.

Pérdida de confidencialidad.
 AMENAZAS A LAS BASES DE DATOS

Pérdida de integridad.
La información debe ser protegida de intentos de
modificaciones inadecuadas.
La integridad se pierde si se realizan cambios no autorizados
en los datos mediante acciones intencionadas o accidentales.
La modificación de datos incluye la creación, inserción,
modificación, cambio del estado de los datos y el borrado.
 AMENAZAS A LAS BASES DE DATOS

Pérdida de disponibilidad.
La disponibilidad de la base de datos consiste en garantizar
que los datos estén disponibles para un usuario o para un
programa que tenga los permisos correspondientes.
 AMENAZAS A LAS BASES DE DATOS

Pérdida de confidencialidad.

La información de la base de datos debe ser protegida de

accesos no autorizados.
El impacto del acceso no autorizado a la información
confidencial puede variar desde la violación de las leyes sobre
privacidad de los datos hasta la amenaza a la seguridad
nacional.
 PROTECCIÓN DE LAS BASES DE DATOS

Medidas de control:
Control de accesos,
Control de inferencias,
Control de flujo
Cifrado.
 PROTECCIÓN DE LAS BASES DE DATOS

Mecanismos de seguridad discrecionales.

Permiten conceder permisos a usuarios, incluyendo la
capacidad de acceso a determinados archivos de datos,
registros o campos en un modo en concreto (lectura,
inserción, borrado o actualización).
 PROTECCIÓN DE LAS BASES DE DATOS

Mecanismos de seguridad obligatorios.

Permiten brindar seguridad por niveles mediante la
clasificación de los datos y de los usuarios en varias clases
de seguridad (o niveles) para después implementar la
política de seguridad adecuada a la organización.
 SEGURIDAD DE LA BASES DE DATOS

DBA( Administrador de la Base de Datos) y la seguridad de la

Base de Datos.
El DBA dispone de una cuenta en el DBMS, denominada como
cuenta de sistema o de superusuario, que proporciona todos los
privilegios disponibles en la base de datos
 SEGURIDAD DE LA BASES DE DATOS

1. Creación de cuentas. Esta acción crea una nueva cuenta y contraseña

para posibilitar el acceso al DBMS a un usuario o grupo de usuarios.
2. Concesión de privilegios. Esta acción permite al DBA conceder
determinados permisos a determinadas cuentas.
3. Quita de privilegios. Esta acción permite al DBA retirar (cancelar)
determinados permisos concedidos previamente a determinadas cuentas.
4. Asignación del nivel de seguridad. Esta acción consiste en asignar
cuentas de usuario al nivel de clasificación de seguridad adecuado.
 PROTECCIÓN DE ACCESOS
Cuentas de usuarios.
Las cuentas de usuarios deben almacenarse en una tabla cifrada y
borrarse en el momento de cancelar una cuenta.

Es fundamental que el sistema de base de datos realice un seguimiento

del rastro de todas las operaciones en la base de datos que un usuario
determinado realice durante cada sesión. Esto comprende toda la
secuencia de interacciones realizadas por ese usuario en la base de datos
desde el momento en que inicia la sesión hasta el momento en que la
finaliza.
 PROTECCIÓN DE ACCESOS

Auditoría de la BD.
Las auditorías en la base de datos son muy importantes en el caso de
bases de datos con información confidencial que sean actualizadas por un
gran número de transacciones y usuarios, como una base de datos
bancaria que puede ser actualizada por un gran número de cajeros del
banco.

Un registro de una base de datos que se utilice para propósitos de

seguridad se lo denomina registro de auditoría.
 PROTECCIÓN DE ACCESOS
Auditoría de la BD.
Es muy importante seguir el rastro de las operaciones de actualización
que se realicen sobre la base de datos, de modo que el DBA pueda
determinar qué usuario provocó el daño en el caso de que la base de
datos sea modificada de forma malintencionada.

Para mantener un registro de todas las actualizaciones realizadas en la

base de datos por los usuarios se puede modificar el registro de sucesos
del sistema (system log). Es posible expandir las entradas del registro de
forma que incluya también en el registro el número de cuenta del usuario
y el identificador del terminal desde el que se realizó la operación.
 PROTECCIÓN DE ACCESOS
Auditoría de la BD.
Si se sospecha de alguna modificación malintencionada, se debe realizar
una auditoría de la base de datos.
La auditoría consiste en la revisión del archivo de registro (logs) para
examinar todos los accesos y operaciones realizadas sobre la base de
datos durante un determinado período de tiempo.
Cuando se encuentre una operación ilegal o no autorizada, el DBA podrá
determinar el número de cuenta utilizado para realizar la operación.
 PROTECCIÓN DE ACCESOS

Las diferentes amenazas a las bases de datos pueden provocar pérdida

de integridad, disponibilidad y confidencialidad de la información.
Las medidas de control que permiten mitigar las mismas son: control de
accesos, control de inferencias, control de flujo y cifrado.
La seguridad de la BD tiene relación con el control de los accesos al
sistema de base de datos en su totalidad y con el control de la
autorización para acceder a determinadas partes de una base de datos.
 PROTECCIÓN DE ACCESOS

La seguridad de la BD tiene relación con el control de los accesos al

sistema de base de datos en su totalidad y con el control de la
autorización para acceder a determinadas partes de una base de datos.
Esto se realiza habitualmente mediante la asignación de cuentas con
contraseñas a los usuarios. También utilizando un sistema de concesión y
revocación de privilegios a cuentas individuales para acceder a partes
concretas de la base de datos.
 SEGURIDAD DE LA BASES DE DATOS

Se debe tener presente que las bases de datos modernas enfrentan

grandes desafíos en relación a la seguridad y privacidad de los datos,
donde la calidad de los datos, los derechos de propiedad intelectual y la
supervivencia de los datos, son solo algunos ejemplos de grandes retos
que enfrentan las mismas.
por su atención
Bases de Datos

Esp. Eduardo Fabián Tossolini

 BASES DE DATOS ORIENTADAS A OBJETOS

La estructura de bases de datos relacionales son muy utilizadas en la mayoría de los ámbitos de
aplicación. Las tablas relacionales son apropiadas para muchas aplicaciones habituales. Pero existen
casos de uso en los que presenta serios inconvenientes prácticos, generalmente si se requiere gestionar
datos muy complejos o no convencionales (imágenes, documentos, entre otros.), para los que las
estructuras relacionales resultan muy complejas e ineficientes.
Algunos ejemplos de gran importancia práctica son las bases de datos multimedia, las bases de datos
científicos y los sistemas de apoyo al diseño industrial (cad/cam)
Los SGBDOO surgen debido a la falta de capacidad del Modelo Relacional para atender nuevos tipos de
aplicaciones:

●Diseño y fabricación en ingeniería(CASE, CAD/CAM)

●Bases de datos gráficas y de imágenes
●Bases de datos científicas
●Sistemas de información geográfica
●Bases de datos multimedia
●Acceso uniforme a sistemas de múltiples bases de datos

Dichas aplicaciones tienen requerimientos y características diferentes a las aplicaciones de negocios

tradicionales:

●Estructuras más complejas para los objetos

●Transacciones de mayor duración
●Nuevos tipos de datos para almacenar imágenes o grandes bloques de texto
●Necesidad de definir operaciones no estándar, específicas para cada aplicación
●Controlar versiones y configuraciones

En las bases de datos orientadas a objetos todos los elementos que se manejan son objetos. Algunos
conceptos del modelo de datos orientado a objetos son:

Objetos:
Un objeto es una representación abstracta de una entidad del mundo real que tiene una identidad única
dentro de la base de datos, algunas propiedades incorporadas en sí mismo, y un comportamiento que le
proporciona la capacidad de interaccionar con otros objetos y consigo mismo.

Los objetos, al igual que las filas de las bases de datos relacionales, expresan las propiedades de los
elementos de la realidad.
Los objetos, a diferencia de las tuplas, tienen identidad y son elementos activos, poseen un
comportamiento y pueden interaccionar entre sí.

Identidad:
La identidad de cada objeto se representa por medio de un oid (Object Identifier), el cual es único para
ese objeto. Es la parte más importante de un objeto.
El oid es asignado por el sistema en el momento en que el objeto es creado y no puede ser alterado bajo
ninguna circunstancia.
El oid de un objeto no es visible para el usuario externo, sino que el sistema lo utiliza internamente para
identificar al objeto, y para referenciarlo desde otros objetos.

La diferencia entre un oid y una clave primaria (modelo relacional), está en que la clave primaria se basa
en los valores dados por los usuarios para ciertos atributos.
A diferencia del modelo relacional y las claves primarias, el oid es asignado por el sistema, debe ser
independiente del valor de cualquier atributo, y no puede ser alterado.
El oid solo puede desaparecer cuando su objeto lo haga, y en ese caso nunca puede volver a ser
utilizado.

Propiedades de los objetos:

El valor de un objeto se ajusta a una estructura de datos que se construye por medio de constructores de
tipos de datos y de tipos de objetos.
Los tipos de datos pueden ser básicos, multimedia y texto. El usuario también puede definir tipos de
datos básicos.
Esto hace al sistema muy flexible y capaz de soportar los datos de cualquier aplicación.

Constructores de los objetos:

Constructores de átomos: elementos de los dominios básicos: valores reales, enteros, cadenas,
entre otros.

Constructores de colecciones: suelen ser tuplas ([…]), conjuntos ({…}) y listas (//…//).
Los valores de los objetos se construyen a partir de los átomos y también a partir del conjunto de
oid de todos los objetos existentes en la base de datos.

Ejemplo constructores de dos objetos.

En las bases de datos orientadas a objetos una clase es un conjunto de objetos que comparten
propiedades (tipo de objetos) y comportamientos (operaciones).
La instanciación es el proceso inverso al de la clasificación y consiste en generar los objetos de una
clase.
Cada objeto de la base de datos es instancia de una clase.
Para crear y eliminar las instancias, toda clase debe disponer de un método de creación (constructor) y
otro de eliminación de instancias (destructor).
Los métodos se implementan utilizando alguno de los lenguajes de programación disponibles en el
SGBDOO que se esté utilizando.
Normalmente el SGBDOO está acoplado a un lenguaje de programación orientado a objetos para
implementar las operaciones de los objetos y las aplicaciones de las bases de datos.

Ejemplo, objeto empleado y departamento que dirige:

o1 = (OID = oid_e1, valor = [‘José García’, ‘99.999.999-X’, [1980, 12, 10], V, oid_d1] )

o2 = (OID = oid_d1, valor= [‘Informática’, 17, [oid_e1, [1999, 10, 17] ], {‘Castellón’, ‘Valencia’,
‘Alicante’}, {oid_e1, oid_e13, oid_e11, oid_e17, oid_e5, oid_e3, oid_e2}] )

En el siguiente ejemplo se utiliza el lenguaje de definición de datos simplificado, basado en el lenguaje

O2 C del SGBDOO O2.
Se define un tipo de datos, (data type) Fecha, para simplificar la definición de los tipos de objetos, (object
type) Empleado y Departamento.
Los tipos de datos se utilizan para simplificar la definición de tipos de objetos, y representan estructuras
de datos que se reutilizan en la definición de las
propiedades de distintos tipos de objetos (como fechas o direcciones), y no van a tener existencia
independiente: en ningún caso va haber objetos «Fecha» con identidad propia.
Es muy importante hacer notar esta distinción entre «object type» para definir objetos, y «data type» que
se utiliza exclusivamente para facilitar la definición de las propiedades de los tipos de objetos.

Ejemplo basado en el lenguaje O2 C del SGBDOO O2:

Un atributo de un tipo tiene un dominio asignado, que puede ser un tipo de datos o un tipo de objetos
previamente definidos.
En este ejemplo puede verse que, cuando el valor de un atributo es de un tipo de objetos ([Link].
Departamento), en lugar de asignar al atributo todo el valor, se le asigna el oid del objeto.
Así, los atributos cuyo dominio sea un tipo de objetos en realidad se implementan como referencias
usando el oid, y representan relaciones entre los objetos.

Referencias entre objetos:

El estado de un objeto es el valor que tiene asignado dicho objeto en un momento determinado.
Interfaz o protocolo de acceso es el conjunto de operaciones de una clase y constituye el aspecto público
de un objeto.
La ejecución de una operación provoca el envío de un mensaje a un determinado objeto.

Resumen de conceptos básicos del modelo orientado a objetos

Sistemas de gestión de bases de datos orientados a objetos
Como las bases de datos orientadas a objetos y los lenguajes de programación orientados a objetos
comparten el mismo modelo de datos permite desarrollar aplicaciones sobre BDOO de manera casi
transparente, en contraste con lo que ocurre en las aplicaciones desarrolladas sobre bases de datos
relacionales.
Sin embargo el Modelo de persistencia de los datos Orientado a Objetos no es muy utilizado, debido a
que tiene una serie de ventajas y desventajas.

Diseño lógico de una base de datos OO

Para implementar una BDOO a partir de un esquema conceptual se debe definir los tipos de datos, los
tipos de objetos y las operaciones de las clases en el lenguaje de definición de datos del SGBDOO.
Posteriormente añadir los métodos que se implementan en el lenguaje de programación disponible.

¿Cómo convertir el modelo de clases en DER?

Las clases son representadas por entidades con los atributos de la clase, como se observa en la
siguiente imagen. Se debe considerar que en el DER las entidades tienen un atributo identificador y en
las clases no existe. (los objetos tienen identidad, no necesitan un atributo identificador). También que las
entidades no tienen métodos a diferencia de las clases.
Las asociaciones se convierten en relaciones. La multiplicidad pasa a ser la cardinalidad.

Las clases asociativas se convierten en relaciones con los atributos de la clase asociativa. Se debe tener
en cuenta que las clases asociativas en el DER no van a tener atributo identificador porque dependen de
otras clases en el diagrama. La multiplicidad pasa a ser la cardinalidad.
Las generalizaciones se convierten en entidades.
Una posibilidad es convertir cada clase (no la superclase) de la generalización en entidad, con sus
atributos y los atributos de la superclase.

Otra posibilidad es convertir sólo la superclase de la generalización en entidad, con todos los atributos de
la generalización.

En orientación a objetos se diseña primero el modelo de clases y luego el modelo de datos, que es una
consecuencia de este. Se convierte el modelo de clases al modelo conceptual (DER), este al modelo
lógico (MR) y este al modelo físico.
En un sistema orientado a objetos, se debe tener en cuenta que el dato no es exactamente igual al
objeto. Puede que el modelo de datos contenga tablas que en el modelo OO no existan como clases.
Bases de Datos

Esp. Eduardo Fabián Tossolini

 BASES DE DATOS
ORIENTADAS A OBJETOS
 BASES DE DATOS ORIENTADAS A OBJETOS
Los SGBDOO surgen debido a la falta de capacidad del Modelo
Relacional para atender nuevos tipos de aplicaciones:

● Diseño y fabricación en ingeniería(CASE, CAD/CAM)

● Bases de datos gráficas y de imágenes
● Bases de datos científicas
● Sistemas de información geográfica
● Bases de datos multimedia
● Acceso uniforme a sistemas de múltiples bases de datos
 BASES DE DATOS ORIENTADAS A OBJETOS
Dichas aplicaciones tienen requerimientos y características
diferentes a las aplicaciones de negocios tradicionales:

● Estructuras más complejas para los objetos

● Transacciones de mayor duración
● Nuevos tipos de datos para almacenar imágenes o grandes
bloques de texto
● Necesidad de definir operaciones no estándar, específicas
para cada aplicación
● Controlar versiones y configuraciones
BASES DE DATOS ORIENTADAS A OBJETOS

Objetos:
Un objeto es una representación abstracta de una entidad del
mundo real que tiene una identidad única dentro de la base de
datos, algunas propiedades incorporadas en sí mismo, y un
comportamiento que le proporciona la capacidad de
interaccionar con otros objetos y consigo mismo.
BASES DE DATOS ORIENTADAS A OBJETOS

Objetos:
Los objetos, al igual que las filas de las bases de datos
relacionales, expresan las propiedades de los elementos de la
realidad.

Los objetos, a diferencia de las tuplas, tienen identidad y son

elementos activos, poseen un comportamiento y pueden
interaccionar entre sí.
BASES DE DATOS ORIENTADAS A OBJETOS

Identidad:
La identidad de cada objeto se representa por medio de un oid
(Object Identifier), el cual es único para ese objeto. Es la parte
más importante de un objeto.

El oid es asignado por el sistema en el momento en que el objeto

es creado y no puede ser alterado bajo ninguna circunstancia.
BASES DE DATOS ORIENTADAS A OBJETOS
Identidad:
La diferencia entre un oid y una clave primaria (modelo
relacional), está en que la clave primaria se basa en los valores
dados por los usuarios para ciertos atributos.
A diferencia del modelo relacional y las claves primarias, el oid es
asignado por el sistema, debe ser independiente del valor de
cualquier atributo, y no puede ser alterado.
BASES DE DATOS ORIENTADAS A OBJETOS

Propiedades de los objetos:

El valor de un objeto se ajusta a una estructura de datos que se
construye por medio de constructores de tipos de datos y de tipos
de objetos.
Los tipos de datos pueden ser básicos, multimedia y texto. El
usuario también puede definir tipos de datos básicos.
Esto hace al sistema muy flexible y capaz de soportar los datos
de cualquier aplicación.
BASES DE DATOS ORIENTADAS A OBJETOS

Constructores de los objetos:

Constructores de átomos: elementos de los dominios básicos:
valores reales, enteros, cadenas, entre otros.

Constructores de colecciones: suelen ser tuplas ([…]),

conjuntos ({…}) y listas (//…//).

Los valores de los objetos se construyen a partir de los átomos y

también a partir del conjunto de oid de todos los objetos
existentes en la base de datos.
BASES DE DATOS ORIENTADAS A OBJETOS

Ejemplo, objeto empleado y departamento que dirige:

o1 = (OID = oid_e1, valor = [‘José García’, ‘99.999.999-X’, [1980,

12, 10], V, oid_d1] )

o2 = (OID = oid_d1, valor= [‘Informática’, 17, [oid_e1, [1999, 10,

17] ], {‘Castellón’, ‘Valencia’, ‘Alicante’}, {oid_e1, oid_e13,
oid_e11, oid_e17, oid_e5, oid_e3, oid_e2}] )
BASES DE DATOS ORIENTADAS A OBJETOS
Ejemplo basado en el lenguaje O2 C del SGBDOO O2:
define data type Fecha define object type Empleado
tuple [ año: integer, tuple [nombre: string,
mes: integer, dni: string,
dia: integer] fecha_nac: Fecha,
sexo: char,
depto: Departamento]
define object type Departamento
tuple [nombred: string,
numerod: integer,
dirigido: tuple [ gerente: Empleado,
fecha_inic: Fecha],
sedes: set(string),
empleados: set(Empleado)]
BASES DE DATOS ORIENTADAS A OBJETOS
Referencias entre objetos:

define object type Empleado define object type Departamento

tuple [nombre: string, tuple [nombred: string,
dni: string, numerod: integer,
fecha_nac: Fecha, dirigido: tuple [ gerente:
sexo: char, Empleado,
depto: Departamento] fecha_inic:
Fecha],
sedes: set(string),
empleados: set(Empleado)]
BASES DE DATOS ORIENTADAS A OBJETOS

Resumen de conceptos básicos del modelo orientado a objetos

 BASES DE DATOS ORIENTADAS A OBJETOS

Sistemas de gestión de bases de datos orientados a objetos

Como las bases de datos orientadas a objetos y los lenguajes de

programación orientados a objetos comparten el mismo modelo
de datos permite desarrollar aplicaciones sobre BDOO de
manera casi transparente, en contraste con lo que ocurre en las
aplicaciones desarrolladas sobre bases de datos relacionales.
 BASES DE DATOS ORIENTADAS A OBJETOS

Diseño lógico de una base de datos OO

Para implementar una BDOO a partir de un esquema conceptual

se debe definir los tipos de datos, los tipos de objetos y las
operaciones de las clases en el lenguaje de definición de datos
del SGBDOO. Posteriormente añadir los métodos que se
implementan en el lenguaje de programación disponible.
 BASES DE DATOS ORIENTADAS A OBJETOS

¿Cómo convertir el modelo de clases en DER?

Modelo de clases tiene: Modelo entidad relación tiene:
Clases Entidades
Asociaciones Relaciones
Clases asociativas Atributos
Generalizaciones Identificadores
Atributos
 CONVERSIONES BÁSICAS

Las clases se convierten en entidades

 CONVERSIONES BÁSICAS

Las asociaciones se convierten en relaciones

 CONVERSIONES BÁSICAS
Las clases asociativas se convierten en relaciones
 CONVERSIONES BÁSICAS
Las generalizaciones se convierten en entidades
 CONVERSIONES BÁSICAS
Las generalizaciones se convierten en entidades
 RESUMEN

En orientación a objetos se diseña primero el modelo de

clases y luego el modelo de datos, que es una consecuencia
de este.

Se convierte el modelo de clases al modelo conceptual (DER),

este al modelo lógico (MR) y este al modelo físico.
por su atención
Bases de Datos

Esp. Eduardo Fabián Tossolini