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.

5.3  El modelo CODASYL DBTG.

   En el modelo DBTG solamente pueden emplearse enlaces uno a uno y uno a muchos. En este modelo existen dos elementos principales que son el dueño y el miembro, donde solo puede existir un dueño y varios miembros, donde cada miembro depende solamente de un dueño.

    Empleando el ejemplo de la relación Alumno-cursa-Materia.

viñeta.jpg (687 bytes)  Si la relación es uno a muchos  sin atributos descriptivos, entonces el diagrama de estructura
      de datos apropiado es:

viñeta.jpg (687 bytes)  Si la relación tiene un atributo descriptivo, como el de calif, entonces el diagrama de estructura de datos apropiado es:

viñeta.jpg (687 bytes)  Si la relación fuera de muchos a muchos el algoritmo de transformación seria como el siguiente considerando que la relación no tiene atributos descriptivos, entonces:

1. Crear los registros correspondientes de las entidades involucradas (alumno,materia).
2. Crear un nuevo tipo de registro ficticio, renlace que puede no tener campos o tener sólo uno que contenga un   identificador único definido externamente.
3. Crear los enlaces correspondientes muchos a uno.



viñeta.jpg (687 bytes)  En el caso de  las relaciones generales (es decir, no binarias), el algoritmo de transformación es el mismo  empleado para el estructurado de los diagramas de los modelos de red donde intervienen más de 2 entidades.
     Por ejemplo consideremos la agregación de la entidad   maestro, entonces  para este caso resulta la  estructura siguiente:

Conjuntos DBTG

    Como se mencionó anteriormente en este modelo solo pueden utilizarse enlaces muchos a uno y uno a uno, así una  forma general de este modelo sería:




    En el modelo DBTG, esta estructura de denomina conjunto DBTG. El nombre que se le asigna al conjunto generalmente es el mismo que el de la relación que une a las entidades.

    En todo conjunto DBTG de este tipo, el tipo de registro A se denomina dueño (o padre) del conjunto, el tipo de registro B se le denomina miembro (o hijo) del conjunto.Cada  conjunto DBTG puede tener cualquier numero de ocurrencias del conjunto. Puesto que no se permiten enlaces del tipo muchos a muchos, cada ocurrencia del conjunto tiene exclusivamente un dueño y cero o más registros miembros. Además ningún registro puede participar en más de una ocurrencia del conjunto en ningún momento. Sin embargo, un registro miembro puede participar simultáneamente en varias ocurrencias de diferentes conjuntos.

Podemos ejemplificar las ocurrencias que se pueden presentar, como:


Para ilustrarlo, considérese el diagrama de estructura siguiente:


Existen dos conjuntos DBTG:

    viñeta.jpg (687 bytes) AluCal, cuyo dueño es Alumno y cuyo miembro es reenlace.
    viñeta.jpg (687 bytes)  MatCal, cuyo dueño es Materia y el miembro reenlace.

Declaración de conjuntos

El  conjunto AluCal se define:          y el conjunto MatCal:

        Set name is AluCal                Set name is MatCal       
            
owner is Alumno                      owner is Materia
            
member is reenlace                  member is reenlace

Una instancia de la base de datos podría ser:

            

Diagramas de estructura de datosPágina anterior Página siguienteRecuperación de datos en DBTG