Unidad 6: Otros modelos de implementación

Modelo jerárquico: conceptos y características generales. 348 3°,

Bases de datos orientadas a objetos: conceptos y Características generales. 664 3° h, 597 5° h 597
Sistemas distribuidos: conceptos y características generales. 704 3°h363, 750 5° h744
Modelo de red: conceptos y características generales. 292 3° h157,

Modelo jerárquico: El modelo de datos jerárquico representa organizaciones jerárquicas en forma directa y
natural y puede ser la mejor opción en algunas situaciones, aunque presentará problemas cuando representa
situaciones con vínculos que no sean jerárquicos.
 Estructuras de BD jerárquicas:
 Vínculos Padre-Hijo y esquemas jerárquicos: El modelo jerárquico utiliza 2 conceptos principales de
la estructuración de datos, Registros y Vínculos Padre-Hijo
 Registro: es una colección de valores que proporcionan información sobre una entidad o un ejemlar
de vínculos. Los registros del mismo tipo se agrupan en tipos de registros. Cada tipo resive su
nombre y su estructura se define en términos de una colección de campos. Cada campo tiene un
cierto tipo de datos cono entero, real o cadena
 Tipos de Vínculos Padre-Hijo: es una vinculación 1:N entre 2 tipos de registros. El tipo de registros
del lado 1 se denomina registro padre y del lado N registro hijo, del tipo VPH. Una ocurrencia del tipo
VPH consiste en un registro del tipo padre y varios registros (0 o más) del tipo de registros hijos.
 Ejemplo:
 Vínculos virtuales Padre-Hijo:
El modelo jerárquico tiene problemas cuando se trata de modelar:
1. Vínculos N:M
2. El caso en que un tipo de registro participa como Hijo en más de un tipo de VPH
3. Vínculos N arios con más de 2 tipos de registros participantes
Estos problemas generan una duplicación de los registros, desperdicio de espacio de almacenamiento y
dificultad en el mantenimiento de copias consistentes del mismo registro.
Para solucionar esto se usan apuntadores de los nodos de un esquema jerárquico a otro para
representar los vínculos.
Un tipo de registro Virtual es apuntador. HV es un tipo de registro con la propiedad de que cada uno de
sus registros contiene un apuntador a un registro de otro tipo de registros PV, HV siempre representa
el papel de “Hijo virtual” y PV de “Padre Virtual” en un “Vínculo virtual Padre-Hijo”.
Cada ocurrencia de registros H de HV apuntan a una y solo una ocurrencia de registro P de PV. Varios
registros Virtuales pueden apuntar P pero solo se almacena una copia de P en la BD.
 Propiedades:
1. La raíz del esquema jerárquico no puede ser registro hijo de ningún tipo de VPH.
2. Todos los registros, menos la raíz, participa como registro hijo en uno y selo un tipo de VPH.
3. Un tipo de registro puede participar como tipo de registros padre en cualquier cantidad (0 o
más) de tipo de VPH.
4. Un tipo de registro que no participa como tipo de registro padre en ningún tipo de VPH se
denomina hoja del esquema jerárquico.
5. Si un registro padre tiene varios hijos, entonces están ordenados de izquierda a derecha.

---------------------------------------------------------------------------------------------------------------------------------------------------
-

Bases de datos orientadas a objetos: es una BD que incorpora los conceptos del paradigma orientado a objetos

 Encapsulación: propiedad que permite ocultar la información al resto de los objetos, impidiendo así
Access incorrectos o conflictivos.
 Herencia: propiedad mediante la cual los objetos heredan comportamientos dentro de una jerarquía
de clases.
 Polimorfismo: propiedad de una operación mediante la cual puede ser aplicada a distintos tipos de
objetos.
 Una BDOO: almacena objetos. Los datos se almacenan junto a los métodos que procesan dichos datos.
Toman la idea de bases inteligentes de datos a su conclusión lógica. No se tiene acceso a dato alguno si no
es a través de los métodos almacenados en la DB. Estos métodos están listos para entrar en acción al
momento en que reciben una solicitud. Los datos de todos los objetos quedan entonces encapsulados,
esto es porque todas las operaciones que un usuario pueda aplicar están predefinidas.

Además las BDOO combinan las mejores cualidades de los archivos planos, las bases jerárquicas y
relacionales, proporcionan una estructura flexible con acceso ágil, rápido, con gran capacidad de
modificación. Estas permiten el desarrollo y mantenimiento de aplicaciones complejas ya que se puede
utilizar un mismo modelo conceptual y así las aplicaciones al análisis, diseño y programación, esto reduce
el problema entre diferentes modelos a través de todo el ciclo de vida, con un costo menor.

 Características:
 Mejor rendimiento que el de las BD relacionales
 Bases de Datos activas
 BD con conocimiento
 Objetos binarios de gran tamaño (sonido, video, etc)
 Tipos de datos abstractos
 Propiedades:
 el objetivo principal es el encapsulamiento, que permite almacenar datos y métodos. Los datos solo
se utilizan mediante los métodos, los datos están diseñados para ser utilizados por esos métodos.
 Los objetos son activos, las solicitudes hacen que los objetos ejecuten sus métodos, algunos
pueden ser complejos. Como aquellos que utilizan un motor de interferencias.
 Las clases son diseñadas para una alta utilización y son rara vez modificadas pudiendo ser
reorganizadas sin modificar su forma de uso.
 Las estructuras de datos son complejas, esto es transparente al usuario, debido a que estos están
encapsulados.
 Los datos están ligados entre sí, de modo que los métodos logran un mejor rendimiento.
 No se busca obtener datos no redundantes, sino métodos no redundantes utilizando e
encapsulamiento y la herencia.
 Las solicitudes al objeto provocan la ejecución de sus métodos.
---------------------------------------------------------------------------------------------------------------------------------------------------
-

Sistemas distribuidos: consiste en un número de elementos de procesamiento, no necesariamente

homogéneos, que están interconectados mediante una red de computadores, y que cooperan para la
realización de ciertas tareas asignadas.

Una base de datos distribuida es una colección de datos que pertenece lógicamente al mismo sistema
pero que está dispersa físicamente entre los sitios de una red de computadoras.

Una Base de Datos Distribuida (BDD) 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.

Un Sistema de Base 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 los datos en cualquier parte de la red exactamente como si los datos estuvieran almacenados en su
sitio propio.

Un Sistema de Manejo de Base de Datos Distribuida (SMBDD) es aquel que se encarga del manejo de
la BDD y proporciona un mecanismo de acceso que hace que la distribución sea transparente a los usuarios.
Transparente significa que la aplicación trabajaría como si un solo SMBD ejecutado en una sola máquina,
administrara esos datos.

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.

Dada la definición anterior, es claro que algunos sistemas no se pueden considerar como SBDD. Por
ejemplo, un sistema de tiempo compartido no incluye necesariamente un sistema de manejo de base de datos
y, en caso de que lo haga, éste es controlado y administrado por una sola computadora. Un sistema de
multiprocesamiento puede administrar una base de datos pero lo hace usualmente a través de un solo sistema
de manejo de base de datos.

Finalmente una base de datos la cual reside en un solo sitio de una red de computadoras y que es
accesada por todos los nodos de la red, no es una base de datos distribuida. Este caso se trata de una base de
datos cuyo control y administración está centralizada en un solo nodo pero se permite el acceso a ella a través
de la red de computadoras.

 Principios Fundamentales
Es posible expresar lo que podría considerarse como el principio fundamental de las BDD.
Desde el punto de vista del usuario, un sistema distribuido deberá ser idéntico a un sistema no distribuido.
Los usuarios del sistema distribuido deberán comportarse exactamente como si el sistema no estuviera
distribuido. A esto es lo que llamamos “la regla cero” de los sistemas distribuidos. Esta conduce a varios
objetivos o reglas secundarias; ellas son:

1.- Autonomía local

2.- No dependencia de un ciclo central
3.- Operación continúa
4.- Independencia con respecto a la localización
5.- Independencia con respecto a la fragmentación
6.- Independencia de replica
7.- Procesamiento distribuido de consultas
8.- Manejo distribuido de transacciones
9.- Independencia con respecto al equipo
10.- Independencia con respecto al sistema operativo
11.- Independencia con respecto a la red
12.- Independencia con respecto al Manejo de Sistemas de Bases de Datos Distribuidas

 Características:
 Los datos se pueden colocar físicamente en el lugar donde se accesan más frecuentemente,
haciendo que los usuarios tengan control local de los datos con los que interactúan. Esto resulta en
una autonomía local de datos permitiendo a los usuarios aplicar políticas locales respecto al tipo de
accesos a sus datos.
 Mediante la replicación de información, 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 el caso de las bases de datos centralizadas.

 Ventajas de SGBDD:
 La naturaleza distribuida de algunas aplicaciones de base de datos: las aplicaciones están
distribuidas en diferentes lugares.
 Mayor fiabilidad y disponibilidad: es decir que estén en funcionamiento y disponible
continuamente. Cuando los datos y el SGBD están distribuidos en varios sitios, un sitio puede fallar
mientras que los demás siguen operando.
  Brinda posibilidad de compartir los datos al mismo tiempo que se mantiene un cierto grado de
control local.
 Mejora el rendimiento con DB unas pequeñas en diferentes sitios.
 Los datos son localizados en un lugar más cercano, por lo que 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.
 Nuevos nodos se pueden agregar fácil y rápidamente.
 La comunicación entre nodos se mejora.
 Los costos de operación se reducen.
 Son amigables al usuario.
 La probabilidad de que una falla en un solo nodo afecte al sistema es baja y existe una autonomía e
 independencia entre los nodos.

Por otro lado la distribución produce un aumento en la complejidad del diseño y la implementación del
sistema, por lo que un SGBDD debe contar con las funciones de un SGBD centralizado y además con las
siguientes

 Capacidad de tener acceso a sitios remotos y transmitir consultas y datos entre diversos sitios a
través de la red.
 La capacidad de seguir la pista a la distribución y la replicación de los datos en el catálogo del
SGBDD.
 La capacidad de decidir a cual copia de un elemento de información replicado s tendrá acceso.
 La capacidad de mantener la consistencia de las copias.
 La capacidad de recuperarse de caídas individuales de sitios.

 Desventajas:
 La principal desventaja 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.
 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.
 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.
 Mayor tiempo extra de procesamiento: el intercambio de mensajes y los cálculos adicionales son
una forma de tiempo extra que no existe en los sistemas centralizados.

 Diseño de Base de Datos Distribuidas:

El problema de diseño de BDD se refiere a hacer decisiones acerca de la ubicación de datos y programas a
través de los diferentes sitios de una red de computadoras. La decisión de donde colocar a las aplicaciones
tiene que ver tanto con el software del SMBDD como con las aplicaciones que se van a ejecutar sobre la
base de datos.
Cuando se trabaja con BDD se tienen que considerar los siguientes problemas:
1. El Diseño de la fragmentación. Este se determina por la forma en que las relaciones globales se
subdividen en fragmentos horizontales, verticales o mixtos.
2. El Diseño de la asignación de los fragmentos. Esto se determina en la forma en que los fragmentos se
mapean a las imágenes físicas, en esta forma, también se determina la solicitud de fragmentos.

 Enfoques al problema de diseño de BDD:

Existen dos estrategias generales para abordar el problema de diseño de BDD:
 1. El enfoque de arriba hacia abajo (top-down): Para aplicaciones nuevas. Consiste en partir desde el
análisis de requerimientos para definir el diseño conceptual y las vistas de usuario. A partir de ellas se
define un esquema conceptual global y los esquemas externos necesarios. Se prosigue con el diseño de
la fragmentación de la BD, y de aquí se continua con la localización de los fragmentos en los sitios,
creando las imágenes físicas. Luego, se completa ejecutando en cada sitio, “el diseño físico” de los
datos, que se localizan en éste.
2. El diseño de abajo hacia arriba (botton-up): Se utiliza particularmente a partir de bases de datos
existentes, generando a partir de ellas bases de datos distribuidas. El diseño botton-up de una BDD
requiere de la selección de un modelo de bases de datos común para describir el esquema global de la
base de datos. Esto se debe a que es posible que se utilicen diferentes SMBD. Después se hace la
traducción de cada esquema local en el modelo de datos común y finalmente se hace la integración del
esquema local en un esquema global común.

El diseño de una Base de Datos Distribuida, cualquiera sea el enfoque que se siga, debe responder
satisfactoriamente las siguientes preguntas: ¿Por qué hacer una fragmentación de datos?, ¿cómo realizar
la fragmentación?, ¿qué tanto se debe fragmentar?, ¿cómo probar la validez de una fragmentación?,
¿cómo realizar la asignación de fragmentos?, ¿cómo considerar los requerimientos de la información?

---------------------------------------------------------------------------------------------------------------------------------------------------
-

Modelo de red

Hay 2 estructuras básicas en el modelo de Red:

 Registros
 Conjuntos
 Registros, tipos de registros y elementos de información:
Los datos se almacenan en registros, cada registro consiste en un grupo de valores de datos relacionados
entre sí. Los registros se clasifican en tipos de registros, cada uno de los cuales describe la estructura de un
grupo de registros que almacenan el mismo tipo de información. Damos un nombre a cada tipo de registro
y también damos un nombre y un tamaño/formato (tipo de datos) a cada elemento de información
(atributo) del tipo de registros.
Veamos un tipo de registros ESTUDIANTE con los elementos de información: NOM, NSS, DIR, DPTOCA y
FENAC, y también el tipo de datos de cada elemento de información.

Tipo de Registro Estudiante

ESTUDIANTE
NOM NSS DIR DPTOCA FENAC

Nombre del elemento de información Formato

NOM CHAR 30
NSS CHAR 9
DIR CHAR 40
DPTOCA CHAR 10
FENAC CHAR 9

También es posible definir elementos de información virtuales o derivados, cuyos valores no se almacenan
realmente en los registros, en vez de ello se derivan de los elementos de información reales mediante
algún procedimiento definido específicamente para tal fin.
 Por ejemplo, se puede declarar un elemento de información virtual edad para el tipo de registros
ESTUDIANTE y escribir un procedimiento que calcule la edad a partir de la fecha de nacimiento de cada
registro.
Para representar los vínculos entre los registros, el modelo de red proporciona la construcción
de modelado llamada TIPO DE CONJUNTO

 Tipos de conjuntos y propiedades:

Un tipo de conjuntos es una descripción de un vínculo 1:N entre dos tipos de registros. Cada definición de
tipo de conjuntos consta de tres elementos básicos:
 Un nombre para el tipo de conjunto
 Un tipo de registros propietarios
 Un tipo de registros miembro
En la BD habrá muchas ocurrencias de conjunto que corresponderán a un tipo de conjuntos. Cada ejemplar
relaciona un registro del tipo de registros propietarios con el conjunto de registros del tipo de registros
miembro relacionado con él.

DEPARTAMENTO Tipo de registro

NOMD … … … … Propietario

DPTO_Carrera Tipo de Conjunto

Tipo de registro
ESTUDIANTE
Miembro
NOM NSS DIR DPTOCA FENAC

Así cada ocurrencia de conjunto se compone de:

 Un registro propietario
 Varios registros miembro relacionados (0 o más )

Un registro del tipo de registros miembro no puede existir en más de una ocurrencia de conjunto de un tipo de
conjuntos particular. Esto mantiene la restricción de que un tipo de conjuntos representa un vínculo l:N. En el
ej: un registro ESTUDIANTE puede estar relacionado cuando más con una ocurrencia de conjunto del tipo de
conjunto DPTO_CARRERA. Observe que cada ejemplar de conjunto debe tener solo un registro propietario;
pero a la vez puede tener cualquier número de registros miembros (0 o más), casi siempre se hace referencia a
un ejemplar de conjunto por su registro propietario. Las ocurrencias pueden representarse también mediante
listas enlazadas.
EJ: Dos ejemplares de conjunto del tipo de conjuntos DEPTO-CARRERAS.

Un ejemplar de conjunto no es idéntico al concepto matemático de conjunto. Sus principales diferencias son
dos:

 El ejemplar de conjunto tiene un elemento distinguido – el registro propietario. En un conjunto

matemático no hay distinción alguna entre los elementos.
 En el modelo de red los registros miembro están ordenados, mientras que en un conjunto matemático
no.
A continuación mostramos otra representación “enlazada” de un ejemplar del conjunto DEPTO-
CARRERA.

 Tipos especiales
de conjuntos:
 Conjuntos Singulares o Propiedad del sistema: son conjuntos sin tipo de registro propietario, en
este caso, el sistema es el propietario. Podemos considerar al sistema como un tipo de registro
propietario “virtual” especial en el que solo hay una ocurrencia en ese conjunto.
Estos conjuntos tienen 2 funciones principales en el modelo de red
A. Proveer puntos de entrada a la DB a través de los registros del tipo de registro miembro
específico.
B. Puede servir para ordenar los registros de un tipo de registro dado mediante las
especificaciones de ordenamiento de conjunto. Si un usuario especifica varios conjuntos
 propiedad del sistema para el mismo tipo de registros, puede tener acceso a sus registros
en diferentes órdenes.

Conjunto propiedad
del sistema (permite
tener acceso a los
registros
DEPARTAMENTO, en
orden, según cierto
campo ej NOM)

Esta es una representación diagramática del conjunto propiedad del sistema TODOS-DEPTOS, que
permite tener acceso a los registros DEPARTAMENTO en orden según cierto campo, por ejemplo
NOM, con una especificación apropiada de ordenamiento de conjunto.

 Conjuntos Multimiembro: se utilizan en casos en que los registros miembro de un conjunto

pueden pertenecer a más de un tipo de registros. Los registros miembro en una ocurrencia de
conjuntos multimiembro pueden contener registros de cualquier combinación de tipos de registros
miembro. La restricción de que cada registro miembro pueda aparecer en una ocurrencia de
conjunto, como máximo, sigue siendo válida, a fin de imponer la naturaleza 1:N del vínculo.

EMO_DEPTO: conjunto multimiembro

3 tipos de registros multimiembro

 Conjuntos Recursivos: es un tipo de conjuntos en el que el mismo tipo de registros desempeña el

papel tanto de propietario como de miembro. Un ejemplo de vínculo recursivo 1:N que se puede
representar con un conjunto recursivo es el vínculo SUPERVISIÓN, que relaciona un empleado
supervisor con la lista de empleados a los que supervisa directamente. El registro EMPLEADO
desempeña ambos papeles, el de tipo de registro propietario (el empleado supervisor) y el de tipo
de registros miembros (los empleados supervisados).
En el caso de los conjuntos recursivos, el mismo registro puede ser propietario de una ocurrencia
de conjunto y miembro de otra, si ambas ocurrencias de conjunto son del mismo tipo de conjuntos.
Por este problema, se acostumbra representar los conjuntos recursivos en el modelo de red con un
tipo de registros de enlace (o ficticio) adicional. La misma técnica se utiliza para representar
vínculos M:N. En la figura se muestra la representación del vínculo SUPERVISIÓN empleando dos
tipos de conjuntos y un tipo de registros de enlace. El tipo de conjuntos SUPERVISOR en realidad es
un vínculo 1:1, es decir, hay cuando más un tipo de registros SUPERVISIÓN miembro en cada
ocurrencia del conjunto SUPERVISOR. Podemos considerar cada registro de enlace SUPERVISIÓN
como la representación de un empleado en el papel de supervisor.
 Casi ninguna implementación de SGBD de red permite al mismo tipo de registros participar como
propietario y como miembro en el mismo tipo de conjuntos.
 Empleo de conjuntos para representar vínculos 1:1 y M:N :
Un tipo de conjuntos representa un vínculo 1:N entre dos tipos de registros. Esto significa que un registro
del tipo de registros miembro solo puede aparecer en una ocurrencia del conjunto.
Si queremos representar un vínculo 1:1 entre dos tipos de registros con un tipo de conjuntos, debemos
hacer que cada ocurrencia de conjunto solo pueda tener un registro miembro. El programador debe
comprobar que no se viole esta restricción cada vez que se inserta un registro miembro en una ocurrencia
de conjunto, ya que el modelo de red no cuenta con el mecanismo para imponer automáticamente esta
restricción.

Un vínculo M:N entre dos tipos de registros no puede representarse con un solo tipo de conjuntos. Por ej:
consideremos el vínculo TRABAJA_EN entre EMPLEADO y PROYECTO, supongamos que un empleado puede
trabajar en varios proyectos al mismo tiempo y que un proyecto siempre tiene varios empleados que
trabajan en él. Para representar este vínculo en el modelo de red empleamos 2 tipos de conjuntos y un tipo
de registros adicionales. Este tipo de registros adicional TRABAJA_EN, en nuestro ejemplo, se usara tipo de
registro enlace (o ficticios). Cada registro del tipo de registro TRABAJA_EN debe ser propiedad de un
registro EMPLEADO a través del conjunto E_T y de un registro PROYECTO, a través del conjunto P_T, y sirve
para relacionar estos 2 registros propietarios.
 Restricciones en el modelo de red:
Existen ciertas restricciones de “comportamiento” que se aplican a los miembros de los conjuntos cuando
se realizan operaciones de inserción, eliminación y actualización con esos conjuntos. Podemos especificar
varias restricciones sobre la pertenencia a un conjunto, y estas suelen dividirse en dos categorías
principales, llamadas opciones de inserción y opciones de retención.
 Restricciones de inserción en conjuntos: especifican lo que sucede cuando se inserta en la BD un
registro nuevo que es de un tipo de registros miembro. Los registros se insertan con la orden
STORE. Hay dos opciones de inserción:
a) Automática: el nuevo registro miembro se conecta automáticamente a una ocurrencia de
conjunto apropiada cuando se inserta el registro.
b) Manual: el nuevo registro no se conecta a ninguna ocurrencia de conjunto. Si el
programador lo desea, puede conectar después manualmente a una ocurrencia de
conjunto, mediante la orden connect.
 Restricciones de retención en conjuntos: Las restricciones de retención especifican si un registro
de un tipo de registros miembro pueden existir en la BD por sí solo o si siempre debe estar
relacionado con un propietario como miembro de algún ejemplar de conjunto. Hay tres opciones
de retención:
a) Opcional: un registro miembro puede existir por si solo sin ser miembro de ninguna
ocurrencia del conjunto. Se le puede conectar y desconectar de las ocurrencias de
conjuntos a voluntad con las órdenes connect y disconnect.
b) Obligatoria: ningún registro miembro puede existir por sí solo, siempre debe ser miembro
de una ocurrencia de conjunto del tipo de conjuntos. Se le puede reconectar en una sola
operación de una ocurrencia de conjunto a otra mediante la orden reconnect.
c) Fija: al igual que en la obligatoria, ningún registro miembro puede existir por sí solo. Por
añadidura, una vez insertado en una ocurrencia de conjunto queda fijo, no se le puede
reconectar a otra ocurrencia de conjunto.