En el modelo relacional, los datos y las relaciones entre ellos se representan mediante un conjunto de tablas. El modelo de red se diferencia del modelo relacional en que los datos se representan mediante conjuntos de registros, y las relaciones entre ellos mediante punteros.
 

2.1. CONCEPTOS BÁSICOS

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.

Como ejemplo, considérese una base de datos que represente una relación cliente-cuenta en un sistema bancario. Hay dos tipos de registros, cliente y cuenta. Como se ha visto anteriormente, se puede definir el tipo de registro cliente utilizando una notación parecida a la del Pascal, de la manera siguiente:

El tipo de registro cuenta puede definirse de la manera siguiente:

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 entidades cuenta. Incluye los dos campos número-cuenta y saldo. Finalmente, la relación impositor ha sido sustituida por el puntero impositor. Si la relación impositor 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 Renlace que 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.
 
 

2.3. EL MODELO CODASYL DE DBTG

La primera especificación de una norma para las bases de datos, denominada informe CODASYL DBTG 1971, la elaboró a finales de los años sesenta el grupo de trabajo sobre bases de datos (Database Task Group, DBTG). En el modelo DBTG sólo se pueden utilizar punteros de varios a uno. Los punteros de uno a uno se representan como punteros de varios a uno. No se permiten los punteros de varios a varios para simplificar la aplicación.

Si la relación impositor es de varios a varios, el algoritmo de transformación debe refinarse de la manera siguiente. Considérese la relación mostrada en la Figura 7.4a. Para transformar la relación hay que crear un nuevo tipo de registro ficticio, Renlace, que puede no tener ningún campo o tener un solo campo que contenga un identificador único definido externamente, y dos punteros de varios a uno, ClienRenl y CuenRenl, tal y como se muestra en la Figura 7.4b.
 
 

Dado que sólo se pueden utilizar punteros de varios a uno en el modelo DBTG, un diagrama de estructura de datos que consta de dos tipos de registro vinculados entre sí tiene la forma general de la Figura 7.5. Esta estructura se denomina conjunto DBTG en el modelo DBTG. El nombre del conjunto suele elegirse para que sea igual que el del puntero que conecta los dos tipos de registro.

En cada uno de estos conjuntos DBTG, el tipo de registro A se denomina propietario (o padre) del conjunto, y el tipo de registro B se denomina miembro (o hijo) del conjunto. Cada conjunto DBTG puede tener un número indefinido de apariciones del conjunto, es decir, casos reales de registros vinculados. Por ejemplo, en la Figura 7.6 hay tres apariciones del conjunto correspondientes al conjunto DBTG de la Figura 7.5.
 
 

Dado que no se permiten los punteros de varios a varios, cada aparición del conjunto tiene exactamente un propietario y cero o más registros miembros. Además, ningún registro miembro de un conjunto puede participar en más de una aparición del conjunto en ninguna ocasión. Los registros miembros, sin embargo, pueden participar simultáneamente en varias apariciones de conjuntos DBTG diferentes.

El lenguaje de tratamiento de datos de la propuesta DBTG consta de órdenes que se incorporan en un lenguaje anfitrión. Las órdenes permiten a los programadores seleccionar registros de la base de datos de acuerdo con el valor de un campo especificado e iterar en los registros seleccionados mediante órdenes repetidas para obtener el registro siguiente. También se facilitan a los programadores órdenes para averiguar el propietario de un conjunto en el que tome parte un registro e iterar en los miembros de dicho conjunto. Y por supuesto que hay órdenes para actualizar la base de datos.
 

2.4. TÉCNICAS DE IMPLEMENTACIÓN

En el modelo DBTG los punteros se establecen añadiendo campos puntero a los registros que se asocian mediante ellos. Para mostrar la manera de hacerlo, supóngase que la relación impositor es de varios a uno de cuenta a cliente. Un registro cuenta sólo puede estar asociado con un registro cliente. Por tanto, para representar la relación impositor sólo hace falta un puntero en el registro cuenta. Sin embargo, los registros cliente pueden estar asociados con varios registros cliente. En vez de utilizar varios punteros en los registros cliente, se puede utilizar una estructura de anillo para representar todas las apariciones del conjunto DBTG impositor. En las estructuras de anillo, los registros de los tipos propietario y miembro de cada aparición del conjunto se organizan en listas circulares. Hay una lista circular por cada aparición del conjunto (es decir, por cada registro del tipo propietario).

En la Figura 7.7 se muestra la estructura de anillo del ejemplo de la Figura 7.1. Examínese la aparición del conjunto DBTG que posee el registro «González». Hay dos registros de tipo miembro (cuenta). En vez de contener un puntero por cada registro miembro, el registro propietario (González) sólo contiene un puntero para el primer registro miembro (la cuenta C-101). Este registro miembro contiene un puntero al siguiente registro miembro (la cuenta C-201). Dado que el registro de la cuenta C-201 es el último registro miembro, contiene un puntero para el registro propietario.
 
 

Establecer punteros de varios a varios utilizando punteros es significativamente más difícil. Por tanto, el modelo DBTG restringió los punteros a ser de varios a uno. La estrategia de implementación del modelo DBTG también proporcionó la base para el sistema de recuperación de datos DBTG.
 

2.5. DISCUSIÓN

Resulta evidente del estudio anterior que el modelo de red está estrechamente vinculado con su implementación. Como se vio anteriormente, los diseñadores de bases de datos tienen que crear tipos de registros artificiales incluso para establecer relaciones sencillas de varios a varios. A diferencia del modelo relacional, en el que las consultas pueden realizarse de una manera sencilla y declarativa, la realización de consultas resulta significativamente más complicada. Los programadores se ven obligados a pensar en términos de punteros y de la manera de atravesarlos para llegar a la información necesaria; el tratamiento de los datos en el modelo de red se denomina, por tanto, de navegación

Así, el modelo de red aumenta de manera significativa el trabajo de los programadores, tanto para el diseño de las bases de datos como para el tratamiento de los datos, en comparación con el modelo relacional. Fue preferido al modelo relacional durante muchos años debido a que las primeras implementaciones del modelo relacional fueron muy poco eficientes. Hoy en día hay excelentes implementaciones del modelo relacional, por lo que el modelo de red ha perdido importancia.