Uso de la transformación ER- jerárquico para el diseño de bases de datos jerárquicas

Transformación Entidad-Relación Jerárquico

Un diagrama de estructura de árbol en el esquema de una base de datos jerárquica. Este tipo de diagrama esta formado por dos componentes básicos:

• Cajas, que corresponden a tipos de registro.
• Líneas, que corresponden a enlaces.

Un diagrama de estructura de árbol tiene el mismo propósito que un diagrama de entidad-relación; a saber, especificar la estructura lógica global de la base de datos. Un diagrama de estructura de árbol es similar a un diagrama de estructura de datos en el modelo de red. La principal diferencia es que en este ultimo los tipos de registro se organizan en forma de grafo arbitrario, mientras que en el primero se organizan en forma de árbol con raíz.

Tenemos que ser más precisos en lo que quiere decir árbol con raíz. En primer lugar, el grafo no puede contener ciclos . En segundo lugar, Las relaciones formadas en el grafo deben ser de tal forma que solo existan relaciones uno a muchos o uno a uno entre un padre y un hijo. La forma general de una estructura de árbol se ilustra en la figura 2. Nótese que las flechas están apuntando de padres a hijos.

Un padre puede tener una flecha apuntando a un hijo, pero un hijo siempre debe tener una flecha apuntando a su padre.

Restricciones de integridad en el modelo jerárquico

Restricciones de Integridad

A continuación se mencionan los problemas típicos de las bases de datos jerárquicas y que no existen en las bases de datos relacionales. Todos estos problemas derivan del hecho de que el sistema gestor de base de datos no implementa ningún control sobre los propios datos, sino que queda en manos de las aplicaciones garantizar que se cumplen las condiciones invariantes que se requieran (por ejemplo, evitar la duplicidad de registros). Dado que todas las aplicaciones están sujetas a errores y fallos, esto es imposible en la práctica. Además dichas condiciones suelen romperse ex profeso por motivos operativos (generalmente, ajustes debidos a cambios en el negocio) sin evaluarse sus consecuencias.

 

Duplicidad de registros: No se garantiza la inexistencia de registros duplicados. Esto también es cierto para los campos “clave”. Es decir, no se garantiza que dos registros cualesquiera tengan diferentes valores en un subconjunto concreto de campos.

Integridad referencial: No existe garantía de que un registro hijo esté relacionado con un registro padre válido. Por ejemplo, es posible borrar un nodo padre sin eliminar antes los nodos hijo, de manera que éstos últimos están relacionados con un registro inválido o inexistente..

Desnormalización: Este no es tanto un problema del modelo jerárquico como del uso que se hace de él. Sin embargo, a diferencia del modelo relacional, las bases de datos jerárquicas no tienen controles que impidan la desnormalización de una base de datos. Por ejemplo, no existe el concepto de campos clave o campos únicos.

Los vínculos virtuales padre - hijo

Vinculos Virtuales Padre-Hijo

El modelo jerárquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a varios) del modelo relacional. Pero a diferencia de éste último, las relaciones son unidireccionales. En justicia, dichas relaciones son hijo-padre, pero no padre-hijo. Por ejemplo, el registro de un empleado (nodo hijo) puede relacionarse con el registro de su departamento (nodo padre), pero no al contrario. Esto implica que solamente se puede consultar la base de datos desde los nodos hoja hacia el nodo raíz. La consulta en el sentido contrario requiere una búsqueda secuencial por todos los registros de la base de datos (por ejemplo, para consultar todos los empleados de un departamento). En las bases de datos jerárquicas no existen índices que faciliten esta tarea.

Obsérvese que, a priori, no existen relaciones N:M (de muchos a muchos) en el modelo jerárquico. Salvo que se simulen mediante varias relaciones 1:N. No obstante, esto puede provocar problemas de inconsistencia, ya que el gestor de base de datos no controla estas relaciones.

Como ya se ha mencionado, las relaciones se establecen mediante punteros entre registros. Es decir, un registro hijo contiene la dirección física en el medio de almacenamiento de su registro padre. Esto tiene una ventaja fundamental sobre las bases de datos relacionales: el rendimiento. El acceso de un registro a otro es prácticamente inmediato sin necesidad de consultar tablas de correspondencia.

Las relaciones jerárquicas entre diferentes tipos de datos pueden hacer que sea muy sencillo responder a determinadas preguntas, pero muy difícil el contestar a otras.

Estructura de una Base de Datos Jerárquico

Modelo  de Base de datos Jerárquico:

En el modelo de red, los datos se representan mediante colecciones de registros y las relaciones entre los datos por medio de enlaces. Esta representación también es valida para el modelo jerárquico. La única diferencia es que el modelo jerárquico los registros se organizan par formar colecciones de árboles en vez de grafos arbitrarios.
Una base de datos jerárquica consiste en una colección de registros que se conectan entre si por medio de enlaces. Los registros son similares a los del modelo en red. Cada registro es un conjunto de campos (atributos), cada uno de los cuales contiene un solo valor. Un enlace es una asociación entre dos registros exclusivamente. Por tanto, el concepto de enlace es similar al del modelo de red.



Estructura de una base de datos jerarquica
Los datos se almacenan en la forma de registros, el equivalente a las filas del modelo relacional. Cada registro consta de un conjunto de campos, el equivalente a las columnas del modelo relacional. Un conjunto de registros con los mismos campos se denomina fichero (record type, en inglés), el equivalente a las tablas del modelo relacional.
Considérese una base de datos que representa una relación cliente-cuenta en un sistema bancario. Existen dos tipos de registro, cliente ycuenta. El tipo de registro cliente puede definirse de la misma manera que en el modelo de red. Consta de tres campos: nombre, calle y ciudad. De manera similar, el registro cuenta consta de dos campos: numero y saldo.
Un ejemplo de esta base de datos sería la siguiente, que muestra que el cliente Lowman tiene la cuenta 305, el cliente Camp las cuentas 226 y 177 y el cliente Kahn la cuenta 155.
Nótese que el conjunto de todos los clientes y cuentas esta organizado en forma de un árbol con raíz donde la raíz del árbol es un nodo ficticio. Como veremos, una base de datos jerárquica es una colección de árboles de este tipo, formando así un bosque. Cada uno de estos árboles con raíz se denominara árbol de base de datos.
El contenido de un registro especifico puede tener que repetirse en varios sitios. Por ejemplo, en el sistema bancario cliente-cuenta, una cuenta puede pertenecer a varios clientes. La información correspondiente a esa cuenta, o la correspondiente a los clientes a los que puede pertenecer, tendrá que repetirse. Esta repetición puede ocurrir tanto en el mismo árbol de base de datos como en varios árboles distintos. La repetición de registros tiene dos desventajas principales:

• Puede producirse una inconsistencia de los datos al llevar a cabo la actualización.
• El desperdicio de espacio es inevitable.

Ejemplos de diagrama de esquema de red para una base de datos

Programación de una Base de Datos de Red

Programación:

Para ilustrar la estructura de los registros en una base de datos de red, mostraremos la base de datos alumno – materia, con los siguientes registros (en el Lenguaje de programación Pascal)
type materia = record

clave: string[7]

nombreM: string[25]

cred: string[2];

end;type alumno = record nombre: string[30];

control: string[8];

materia: Materia; {Enlace a materia}

Uso de la transformación ER-Red para el diseño de Base de Datos de Red

Los diagramas de estructura de datos son esquemas que representan el diseño de las bases de datos en red. Estos diagramas constan de dos componentes fundamentales: las cajas, que corresponden a tipos de registros, y las líneas, que corresponden a punteros. Los diagramas de estructuras de datos cumplen la misma finalidad que los diagramas E-R, es decir, especifican la estructura lógica global de la base de datos. Los diagramas E-R pueden transformarse en los diagramas de la estructura de datos correspondientes.

                                       

A modo de ejemplo, considérese el diagrama E-R de la Figura 7.2a, que consta de dos conjuntos de entidades, cliente y cuenta, relacionados mediante una relación binaria de varios a varios impositor, sin atributos descriptivos. El diagrama especifica que un cliente puede tener varias cuentas y que una cuenta puede pertenecer a varios clientes diferentes. El diagrama de la estructura de datos correspondiente se ilustra en la Figura 7.2b. El tipo de registro cliente corresponde al conjunto de entidades cliente. Incluye tres campos —nombre-cliente, calle-cliente y ciudad-cliente—, tal y como se ha definido anteriormente. De manera parecida, cuenta es el tipo de registro correspondiente al conjunto de entidadescuenta. Incluye los dos campos número-cuenta y saldo. Finalmente, la relación impositor ha sido sustituida por el puntero impositor. Si la relaciónimpositor fuera de uno a varios de cliente a cuenta, el puntero impositor tendria una flecha que apuntaría al tipo de registro cliente. De manera parecida, si la relación impositor fuera de uno a uno, el puntero impositor tendría dos flechas, una que apuntaría al tipo de registro cuenta y otra que apuntaría al tipo de registro cliente.

Considérese el diagrama E-R de la Figura 7.3a, que consta de tres conjuntos de entidades —cuenta, cliente y sucursal— relacionadas mediante la relación general CCS sin atributos descriptivos. El diagrama específica que un cliente puede tener varias cuentas, cada una de ellas abierta en una sucursal bancaria específica, y que una cuenta puede pertenecer a varios clientes diferentes.

Dado que los punteros pueden conectarse exactamente con dos tipos de registros diferentes, hay que conectar estos tres tipos de registros mediante un nuevo tipo de registro que se vincule directamente con cada uno de ellos.

Para transformar el diagrama E-R de la Figura 7.3a en un diagrama la estructura de datos de red hay que crear un nuevo tipo de registro Renlaceque pueda no tener ningún campo o tener un solo campo que contenga un identificador único. Este identificador lo proporciona el tema y no lo utiliza directamente el programa de aplicación. Este nuevo tipo de registro se denomina a veces tipo de registro ficticio (o enlace o conexión).También hay que crear tres punteros de varios a uno, ClienRenl, CuenRenl y SucRenl, tal y como se muestra en la Figura 7.3b. Si la relación CCS tuviera atributos descriptivos, se transformarían en campos del tipo de registro Renlace.

Restricciones en el modelo de Base de Datos de Red

Restricciones en el modelo de Base de Datos de Red:

Cuando hablamos de restricción, hemos hablado de restricciones estructurales que gobiernan la forma como están estructurados los tipos de registros de conjuntos. En esta sección hablaremos de restricciones de comportamiento que se aplican a los miembros de los conjuntos, o bien al comportamiento de dichos miembros, 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 en la terminología CODASYL. Para determinas estas restricciones durante el diseño de la base de datos hay que conocer como deberá comportarse un conjunto cuando se inserten registros miembros o cuando se eliminen registros miembros o propietario. Las restricciones se especifican al SGBD cuando se declara la estructura de la base de datos empleando el lenguaje de definición de datos. No todas las combinaciones de las restricciones son posibles.

Todo el tema de la clave de base de datos ha sido muy discutido, ya que aún cuando es generalmente admitida la necesidad de la existencia de un identificador único para los registros, se cuestiona mucho que este deba ser una dirección física. Los problemas derivados de este hecho son muchos, desde una gran limitación a la independencia físico-lógica hasta un grave peligro para la integridad de los datos de la base, al poder acceder el programador a las direcciones físicas de los datos. En esto también se introdujeron modificaciones en 1978.

Otra de las criticas que se han hecho al modelo es la ausencia de mención expresa a un diccionario de datos, así como la falta de especificaciones concretas para el mismo. Esta deficiencia fue subsanada en mayor o en menor medida por los distintos productos, pero al no existir normas concretas en cuanto a sus características o a su definición, las diferencias entre los diccionarios son notables.

Se han hecho también objeciones en relación con el acceso concurrente ya que se pueden producir errores en la actualización debido a que los mecanismos especificados en los lenguajes de definición y de manipulación, además de solaparse son diferentes.

Por ultimo, citar la fuerte dependencia de COBOL y la ausencia de una especificación para un lenguaje de manipulación de auto contenido

Estructuras de una Base de Datos de Red

Base de Datos en Red:

Una base de datos en red consiste en un conjunto de registros conectados entre si mediante punteros. Los registros son en muchos aspectos parecidos a las entidades del modelo entidad-relación (E-R). Cada registro es un conjunto de campos (atributos), cada uno de los cuales sólo contiene un valor de datos. Los punteros son asociaciones entre exactamente dos registros. Por tanto, los punteros pueden considerarse una forma restringida (binaria) de relación en el sentido del modelo E-R.

Estructura de una Base de Datos de Red:

Los diagramas de estructura de datos son esquemas que representan el diseño de las bases de datos en red. Estos diagramas constan de dos componentes fundamentales: las cajas, que corresponden a tipos de registros, y las líneas, que corresponden a punteros. Los diagramas de estructuras de datos cumplen la misma finalidad que los diagramas E-R, es decir, especifican la estructura lógica global de la base de datos. Los diagramas E-R pueden transformarse en los diagramas de la estructura de datos correspondientes.