Un diagrama de estructura de datos es un esquema que representa el diseño de una base de datos de red. Este modelo se basa en representaciones entre registros por medio de ligas, existen relaciones en las que participan solo dos entidades(binarias ) y relaciones en las que participan más de dos entidades (generales) ya sea con o sin atributo descriptivo en la relación.

La forma de diagramado consta de dos componentes básicos:

    Celdas: representan a los campos del registro.
    Líneas: representan a los enlaces entre los registros. 

    Un diagrama de estructura de datos de red, especifica la estructura lógica global de la base de datos; su representación gráfica se basa en el acomodo de los campos de un  registro en un conjunto de celdas que se ligan con otro(s) registro(s), ejemplificaremos esto de la siguiente manera:

Consideremos  la relación alumno-cursa-materia donde la relación cursa no tiene atributos descriptivos :

Las estructuras de datos según la cardinalidad se representan en los siguientes casos:

Cuando el enlace no tiene atributos descriptivos

Caso 1. Cardinalidad Uno a Uno.

Caso 2. Cardinalidad Muchos a uno.

Caso 3. Cardinalidad Muchos a muchos.

Cuando el enlace tiene atributos descriptivos.

   Consideremos que a la relación cursa le agregamos el atributo Cal (calificación), nuestro modelo E-R quedaría de la siguiente manera:

 

    La forma de convertir a diagramas de estructura de datos consiste en realizar lo siguiente:

    1. Realizar la representación de los campos del registro agrupándolos
        en sus celdas correspondientes.
    2. Crear nuevo registro, denominado Calif, para este caso, con un
        solo campo, el de cal (calif).
    3. Crear los enlaces indicando la cardinalidad de :

        AluCal, del registro Calif al registro Alumno.
        MatCal, del registro Calif al registro Materia.

    AluCal y MatCal son solo los nombres que emplearemos para
identificar el enlace, pueden ser otros y no son empleados para
otra cosa.

    Los diagramas de estructuras de datos según la cardinalidad
se transforman en:

Caso 1. Cardinalidad uno a uno.

Caso 2. Cardinalidad Uno a muchos.

Caso 3. Cardinalidad Muchos a muchos.

    Diagramas de estructura de datos cuando intervienen
más de dos entidades y el enlace no tiene atributos descriptivos.

   Consideremos que a la relación alumno-cursa-materia le agregamos la entidad maestro, quien es el que imparte dicha materia.

    Nuestro diagrama E-R quedaría de la siguiente manera:

    La transformación a diagramas de estructura de datos se realiza mediante los siguientes pasos:

1.Crear los respectivos registros para cada una de las entidades que intervienen en el modelo.

2. Crear un nuevo tipo de registro que llamaremos Renlace, que puede no tener campos o tener solo uno que contenga un identificador único, el identificador lo proporcionará el sistema y no lo utiliza directamente el programa de  aplicación, a este registro se le denomina también como registro ficticio o de enlace o unión.

    Siguiendo los pasos anteriores nuestra estructura finalmente es: (Considerando una relación con cardinalidad Uno a Uno)

    Ahora si nuestro enlace tuviera atributos descriptivos, se crea el registro con los campos respectivos y se liga indicando el tipo de cardinalidad de que se trate.

    En este caso tomamos el ejemplo anterior con cardinalidad uno a uno y le agregamos a la relación el atributo calif. (calificación).

    Considerando el anterior diagrama de estructura de datos, una instancia de este seria:

La estructura quedaría:

    Este diagrama nos indica que los alumnos Luis A. Laura M. y Leticia L. cursaron la materia Base de datos 2 con La maestra Ing. Lourdes A. Campoy M obteniendo una calificación de 100,80,95 respectivamente.

Este modelo fue desarrollado en 1971 por un grupo conocido como CODASYL: Conference on Data System Languages, Data Base Task Group, de ahí el nombre; este grupo es el que desarrolló los estándares para COBOL, el modelo CODASYL ha evolucionado durante los últimos años y existen diversos productos DBMS orientados a transacciones, sin embargo hoy día, estos productos están de salida, ya que este modelo es complejo y no cohesivo; los diseñadores y programadores deben de tener mucho cuidado al elaborar bases de datos y aplicaciones DBTG, además este modelo tiene mucho enfoque de COBOL, gran parte a las deficiencias detectadas en la actualidad se le atribuye a que este modelo fue desarrollado muy pronto antes de que se establecieran correctamente los conceptos esenciales de la tecnología de bases de datos.

    En esta unidad se estará aprendiendo sobre un modelo que fué base para el diseño de muchos productos DBMS orientados a transacciones.