Base de datos de red

una base de datos de red es una base de datos conformada por una colección o set de registros, los cuales están conectados entre sí por medio de enlaces en una red. El registro es similar al de una entidad como las empleadas en el modelo relacional.

Un registro es una colección o conjunto de campos (atributos), donde cada uno de ellos contiene solamente un único valor almacenado.

El enlace es exclusivamente la asociación entre dos registros, así que podemos verla como una relación estrictamente binaria.

Una estructura de base de datos de red, llamada algunas veces estructura de plex, abarca más que la estructura de árbol: un nodo hijo en la estructura red puede tener más de un nodo padre. En otras palabras, la restricción de que en un árbol jerárquico cada hijo puede tener sólo un padre, se hace menos severa.

Así, la estructura de árbol se puede considerar como un caso especial de la estructura de red.

 Bases de Datos en Red

Como en el caso de las bases de datos jerárquicas, se trata de una organización jerárquica de nodos, pero un nodo hijo puede tener más de un solo nodo padre (relación muchos a muchos). En las bases de datos en red, existen los punteros, que son conexiones adicionales entre nodos padres y nodos hijos, que permiten acceder a un nodo por vías distintas accediendo al mismo en dirección descendente por las diversas ramas.

La base de datos en red representa una mejora al modelo jerárquico.

Por ejemplo: Los vendedores destacados para distribuir determinados productos en algunas ciudades pueden ilustrar este modelo (ver fig. 2.2).

Cada Producto puede ser distribuido por más de un Vendedor, así mismo cada Vendedor puede encargarse de diferentes Ciudades.

Modelos en red

El modelo de datos en red general representa las entidades en forma de nodo de un grafo, y las asociaciones o interrelaciones entre éstas mediante los arcos que unen dichos nodos.

Esta representación no impone en principio ninguna restricción ni al tipo ni al número de los arcos permitiéndote el modelado de estructuras de datos tan complejas como se desee. Podemos definir el modelo en red general con una mayor formalización, como un conjunto finito de tipos de entidades {E1,E2, ... ,En} con sus respectivas propiedades (atributos): {A11,A12,A13...,Anm} y un conjunto finito de interrelaciones (al igual que las entidades y que los atributos tienen un nombre {Ihj,k...n}.Con la notación anterior representamos la interrelación entre los elementos j,k...,n (bien sean entidades y / u otras interrelaciones), donde el superíndice h permite diferenciar dos interrelaciones distintas entre los mismos elementos, ya que se refiere al nombre de la interrelación.

El esquema representa los aspectos estáticos, la estructura de los datos (tipos de entidades, tipos de interrelaciones, etc...), mientras que una ocurrencia del esquema (base de datos) son los m valores que toman los elementos del esquema en un determinado momento, los cuales irán variando a lo largo del tiempo por el efecto de aplicar los operadores de manipulación de datos a una ocurrencia del esquema.

El modelo en red general es muy flexible debido a la inexistencia de restricciones inherentes, pero también por esta misma razón su instrumentación física resulta difícil y poco eficiente. esta es la causa de que se le suela introducir restricciones al llevarlo a la practica. el modelo jerárquico y el modelo CODASYL son modelos que responden a estructuras del tipo de red pero con restricciones bastante fuertes.

Los diferentes tipos de interrelaciones que se pueden representar en un modelo en red son:

Tipo de interrelación N:M y ocurrencia de la misma

Tipo de interrelación 1:N y ocurrencias de la misma

Interrelación reflexiva 1:N y ocurrencias de la misma

Interrelación reflexiva N:M y ocurrencias de la misma

Tipo de interrelación entra mas de dos tipos de entidad y ocurrencias de la misma

Propuesta CODASYL

CODASYL Es un modelo de datos de tipo red que introduce restricciones inherentes. este modelo constituye una simplificación del modelo en red general, en la que se admiten solo determinados tipos de interrelaciones y se incluyen algunas restricciones adicionales, que, sin embargo, no limitan excesivamente la flexibilidad que proporciona el modelo en red, pero si que facilita una instrumentación eficiente.

Historia

El termino CODASYL proviene de COnference on DAta SYstem Languajes, una organización no oficial compuesta por persona privadas (entre las que se encontraban también miembros de varios departamentos del gobierno de estados unidos), apoyadas por instituciones, con el fin de estudiar y normalizar aspectos relativos a la utilización y diseño de bases de datos. a pesar de su carácter no oficial, los informes y normas CODASYL tuvieron una amplia difusión y respaldo, existiendo muchos sistemas comerciales que se adaptaban a dichas normas. la aceptación las normas CODASYL se debió en gran medida al apoyo brindado por el departamento de defensa de los estados unidos.

Los orígenes del grupo CODASYL se remontan al año 1959. en el mes de abril de dicho año se celebro una reunión de un grupo de constructores y usuarios de ordenadores con el fin de abordar la tarea de definición de un lenguaje de programación común orientado al tratamiento y resolución de problemas de gestión (el que llegaría a ser el lenguaje COBOL). Un poco mas tarde, a finales del mes de Mayo del mismo año, se decidió la continuación de los trabajos y el grupo tomo el nombre de COnference on DAta SYstem Languajes (CODASYL).

En principio las tareas se distribuyeron en tres comités coordinados por un comité ejecutivo. el grupo CODASYL obtuvo un gran éxito con la especificaciones del COBOL, por lo que se decidió a ampliar el espectro de sus estudios y actividades a todos aquellos tema que pudiesen ser de utilidad a COBOL.

En 1964 el grupo sufrió una reestructuración y poco tiempo después en junio de 1965, se creo el List Processing Task Force, dedicado a estudiar las capacidades de proceso de listas para el lenguaje COBOL. en ese mismo año se presento el documento List Processing Extension to Mass Storage, en el que se proponían los cambios necesarios para hacer posible el trabajo con listas en COBOL. Este grupo cambio su nombre dos años más tarde por el de DataBase Task Group (DBTG), con cuyas siglas fue conocido. Este cambio de nombre muestra el creciente interés que despertó hacia mediados y finales de los años setenta el desarrollo de normas y especificaciones en el campo de las bases de datos.

Dentro del grupo destacaron tres personas, a las que se considera sus creadores y máximos impulsores: G.G Dodd, de los laboratorios de la General Motors, con su trabajo sobre un lenguaje de programación asociativo; el presidente del grupo, W.G Simmons, de la United States Steele Corporation, que con gran acierto animo y coordino todos los trabajos y actividades, y C.W Bachman, padre del SGBD de la compañía General Electric, IDS (Luego IDS II de Bull), que además de su labor en el área de almacenamiento integrado de datos propuso la estructura de datos propia del modelo CODASYL y los conocidos diagramas que llevan su nombre.

En el verano de 1968, el comité ejecutivo de CODASYL decidió reorganizar de nuevo el grupo, modificando la estructura de los comités. el resultado fue la formación de tres comités permanentes:

• Comité de sistemas: encargado del desarrollo de lenguajes y técnicas avanzadas para el proceso eficiente de datos.
• Comité de planificación: cuya misión consistía en obtener información de los usuarios e instrumentadores sobre aspectos relacionados con los objetivos perseguidos por CODASYL, de forma que pudieran servir de ayuda en la tarea de planificación de sistemas
• Comité de lenguajes de programación (PLC): que asumió y extendió los objetivos planteados por un subcomité anterior y se responsabilizo del desarrollo y mantenimiento de las especificaciones del COBOL. de este comité encargado también de todas las actividades relativas a las bases de datos, dependía el grupo DBTG.

Después de una primera versión en 1968, en octubre de 1969 e grupo DBTG presentó al PLC el primer informe , que suscito un gran interés, pero que también fue objeto de multitud de criticas. el informe recogía la especificación de la sintaxis y semántica de un lenguaje de definición de datos (DDL) que permitía la descripción de una base de datos, así como de un lenguaje de manipulación de datos (DML); el DML se configuro como una extensión del lenguaje anfitrión, pero en la practica su orientación a COBOL era indiscutible. En estas propuestas de 1969 se definía una arquitectura de base de datos estructurada a dos niveles, esquema y subesquemas, lo cual hacia bastante difícil conseguir la independencia lógico / física deseable en un sistema de base de datos. quizás fue este, junto con su orientación a COBOL, el aspecto mas criticado de las especificaciones contenidas en el informe.

Los trabajos del DBTG continuaron activamente hasta abril de 1971, incluyéndose varios cambios y ampliaciones del informe anterior. se proponían dos lenguajes de descripción de datos, uno para el esquema DDL-Schema, y otro para el subesquema, DDL-SubSchema, con el fin de mejorar la independencia entre los aspectos lógico y físico de la base de datos. En ese mismo año, el comité ejecutivo de CODASYL acepto la recomendación del PLC sobre la creación de un comité independiente encargado del desarrollo y mantenimiento de las especificaciones del lenguaje de definición de datos, al que se llamo comité de lenguaje de definición de datos CODASYL (DDLC). la tarea de añadir a las especificaciones del COBOL el lenguaje de definición de datos del subesquema y las facilidades del lenguaje de manipulación de datos fue encomendada a un subgrupo del DBTG (más tarde convertido en grupo del lenguaje de manipulación DMLTG).

Esta dualidad dio lugar a que se produjesen inconsistencias entre la definición del esquema y la del subesquema y por otro lado con la manipulación de datos. tampoco la terminología empleada por estos dos grupos era uniforme.

En 1973, el DDLC publico en el journal of developement su propuesta para el lenguaje de definición de datos del esquema. En este informe se reconocía que el desarrollo de los lenguajes de bases de datos debía realizarse de forma evolutiva, al igual que lo había sido el COBOL.

Ese mismo año, el DDLC comenzó su colaboración con un grupo de trabajo de la British Computer Society, el Database Administration Working Group (DBAWG), creándose un grupo de trabajo conjunto, denominado BCS/CODASY DDLC. La contribución más importante de este grupo fue el desarrollo y especificación de un lenguaje de almacenamiento de datos (DSDL), que define la representación de la base de datos desde el punto de vista del almacenamiento físico. El informe que contenía las especificaciones del DSDL fue incluido como un anexo en los informes de 1978 y 1981. En estos informes se presentaban los lenguajes de definición y manipulación de datos para una arquitectura a tres niveles (similar a la del grupo ANSI / SPARC de 1975 y 1977). Además de las especificaciones del DSDL, se incluían también las modificaciones necesarias para eliminar ciertas cláusulas del DDL que se consideraba tenían excesivas implicaciones físicas, por lo que se hacia recomendable su desaparición del DDL para introducirlas en el lenguaje de definición del almacenamiento de datos.

Mientras se realizaban estos trabajos e informes, continuaban las actividades de los diferentes comités de CODASYL en otras áreas y se seguían creando nuevos comités encargados de diferentes tareas. en 1974 se formó el comité del lenguaje FORTRAN para bases de datos (FDBLC), que realizo la especificación del lenguaje de datos del subesquema y del lenguaje de manipulación de datos para FORTRAN. Sus trabajos se publicaron en 1977 y 1980. E 1976 se creó un nuevo comité para investigar los requisitos de las bases de datos con vistas a su utilización por usuarios finales, denominado comité de facilidades par usuarios finales (EUFC), cuyas conclusiones fueron publicadas en 1980. Finalmente, cabe destacar la creación en 1978 del comité de lenguajes de mandatos para sistemas operativos comunes (COSCL), el cual publicó sus trabajos en 1980. También se formaron otros grupos específicos dentro de los distintos comités permanentes, con la misión de estudiar aspectos puntuales concernientes al modelo; la mayor parte de ellos fueron disueltos una vez publicados los resultados.

El grupo CODASYL se disolvió en 1983 debido a que la organización oficial ANSI estaba trabajando sobre diferentes propuestas de lenguajes de datos para modelos en red culminando estos con su recomendación NDL/ANS de un lenguaje normalizado de datos en red.

la historia de CODASYL se puede resumir así:

• 1959 aparece CODASYL- COnference on DAta SYstems Languajes
• 1965 Creacion del Lsit Processing Task Group
• 1967 Cambio de nombre por el de DataBase Task Group (DBTG)
• 1968 Informe preliminar sobe LDD y LMD
• 1969 Versión mas completa
• 1971 Versión revisada. creación del comité DDCL
• 1973 Versión aprobada oficialmente
• 1975 Informe Grupo de Trabajo de Administración de Bases de Datos (DBAWG)
• 1976 Informe sobre selección y adicción de SGBD
• 1978 Modificaciones a las propuestas de 1973
• 1980 LDD del subesquema y LMD para FORTRAN
• 1981 Nuevas propuestas del DIC
• 1983 Disolución del grupo

Una de las razones, entre otras, por las que le grupo CODASYL fue elogiado, es la excelente descripción que hizo de los lenguajes que propuso, tanto de los de definición como del de manipulación. Este hecho ha tenido, sin duda, una considerable influencia en la difusión de sistemas de gestión de bases de datos apoyados en estas recomendaciones.

Objetivos

A)Flexibilidad para los usuarios

Permitir la estructuración de los datos de la forma mas adaptada a cada aplicación, independientemente del hecho de que todos o parte de dichos datos pudiesen utilizarse en otras aplicaciones, una flexibilidad que debe conseguirse evitando las redundancias. este es un objetivo esencial en un sistema de base de datos, que permite diferenciarlo de los sistemas clásicos de ficheros.

B) Uso concurrente

Facilitar a varias aplicaciones recuperar o actualizar concurrentemente los datos de la base. Este ha sido uno de los puntos más controvertidos y criticados, a pesar de ser una necesidad reconocida, la verdad es que las especificaciones, ni la de 1973 ni la de 1978, proporcionaban las facilidades necesarias para obtener un verdadero acceso concurrente. de hecho, algunos de los sistemas basados en este modelo no se comportaban nada bien en este aspecto.

C) Estrategias de búsqueda diversas

Suministrar y permitir el uso de varias estrategias de búsqueda, tanto sobre el conjunto de la base como sobre una parte de ella. El lenguaje de definición de datos CODASYL facilita la consecución de este objetivo mediante diferentes opciones para la elección de la forma de ubicación de cada tipo de registro. Estas opciones se encontraban en la especificaron de 1973 en el lenguaje de definición de datos del esquema, lo que fue muy criticado por su implementaciones físicas, pero en 1978 paso al lenguaje de definición del almacenamiento de datos.

D) Seguridad

Proteger la base de datos de accesos no autorizados y de interacciones indeseable de los programas. Este objetivo es de gran importancia ya que asegura la confidenciabilidad y la integridad de la base de datos, para esto se establecieron distintas cláusulas de control de acceso y asignación de contraseñas (PRIVACY LOCK...)

E) Gestión centralizada del almacenamiento físico

Hacer los programas independientes del almacenamiento físico de los ficheros

F) Independencia del almacenamiento físico

Hacer los programas independientes del almacenamiento físico de los ficheros

G) Flexibilidad en el modelo de datos

Permitir la especificación de diversas estructuras de datos, desde entidades aisladas hasta redes. el modelo CODASYL no es excesivamente restrictivo en cuanto a las características de la entidades e interrelaciones que pueden ser representadas. Sin embargo, se ha de tener en cuenta que no permitía en la especificaciones de 1973 la existencia de SET reflexivos, aunque en 1978 se modifico este punto, admitiéndose las interrelaciones reflexivas, siendo posible incluso que una ocurrencia de registro sea propietaria de si misma.

H) facilidad para el usuario

Permitir la interacción del usuario con los datos, pero descargándolo de la operaciones de mantenimiento de las estructuras que han sido declaradas. De hecho, una vez realizada la definición de la base de datos, compilada esta e introducidos los datos, el programados utiliza el lenguaje de manipulación sin tener que ocuparse del mantenimiento del esquema, solo ha de conocer la estructura de los datos y manejarla.

I) Independencia de los programas respecto a los datos

Conseguir programas tan independientes de los datos como sea posible con las técnicas existentes.

J) Descripción de datos independiente

Separar la descripción de la base de datos en su conjunto de la de cada programa.

K) Independencia respecto a los lenguajes

Dotar de medios de descripción de la base de datos que no estén restringidos a un determinado lenguaje. aunque CODASYL señala este objetivo y le concede bastante importancia, la verdad es que las especificaciones de los diferentes lenguajes de definición y manipulación están claramente orientadas a COBOL.

L) Interfaces con múltiples lenguajes

Proporcionar una arquitectura que permita que la descripción de la base de datos, así como la manipulación de la misma, puedan tener interfaces con múltiples lenguajes.

Medios para conseguir los objetivos

Para que un sistema de gestión de base de datos pueda conseguir los objetivos anteriormente citados, CODASYL propone los siguientes lenguajes:

• Lenguaje de definición del esquema (Schema DDL): permite describir la estructura de la totalidad de los elementos que forman parte de la base de datos a nivel lógico (entidades, atributos, interrelaciones, etc...), permitiendo al usuario la elección de su estructura, nombres, etc... su primera especificación fue presentada en los informes de 1968, 1969 y 1971. Contenía muchas cláusulas con claras implicaciones físicas. Las propuestas de 1978 se realizaron con el fin de eliminar dichas cláusulas conservando solamente la parte correspondiente a consideraciones lógicas y pasando los aspectos físicos al nuevo nivel interno que surge con la arquitectura a tres niveles. Si bien, estos cambios supusieron un importante avance en relación con la independencia, le problema solo se resuelve en parte y aunque en 1981 se introducen nuevos cambios, la independencia datos / aplicaciones en CODASYL es relativa.
• Lenguaje de definición de subesquemas (SubSchema DDL): permite la descripción de subconjuntos del esquema para diferentes usuarios que no necesitan para su trabajo más que una parte determinada de la base de datos. Este lenguaje hace posible introducir ciertos cambios en el formato y en la estructura de los elementos del esquema que intervienen en el subesquema.
• Lenguaje de manipulación de datos (DML): se ocupa de los aspectos de manipulación de los datos que contiene la base de datos (recuperación, inserción, modificación, borrado, etc...) su especificación estaba presente en los informes de los años 1971 y 1978, aunque ha ido sufriendo cambios a lo largo de su vida a fin de adaptarlo a las modificaciones que ha ido experimentando el esquema, principalmente con la desaparición de las cláusulas de tipo físico del mismo.
• Lenguaje de control de dispositivos/ soporte (DMCL): En las recomendaciones del año 1971, en las que no existía un lenguaje especifico para el almacenamiento interno de los datos, CODASYL se limito a reflejar la necesidad de un lenguaje que controlase los aspectos relativos a los dispositivos y soportes donde estaban almacenados los datos, pero no definió su sintaxis ni su semántica, algunos de los productos de bases de datos incluyeron este lenguaje, pero al haber sido descrito solo en sus generalidades, existen considerables diferencias entre ellos. No se le hizo mucho caso a las especificaciones del DMLC de 1978.
• Lenguaje de definición del esquema de almacenamiento (DSDL): considera todos los aspectos físicos del almacenamiento de los datos recogidos en la base de datos. fue descrito en el informe de 1978, habiéndose desarrollado por el grupo DBAWG.

Principales criticas al modelo CODASYL

Las criticas al modelo se han centrado principalmente en la falta de independencia, confidencialidad, integridad, y ausencia de un lenguaje de interrogación auto contenido.

Una de las más importantes criticas se refiere a la independencia. este objetivo de cualquier SGBD, queda muy lejos de ser alcanzado en las especificaciones de CODASYL de 1971 y 1973, la razón principal de esta dependencia entre los niveles físico y lógico deriva de la arquitectura a dos niveles, la cual se cambio en 1978.

Otro aspecto cuestionado era la necesidad de que el programador de aplicaciones tuviese que abrir las áreas en las que se encontraban las ocurrencias a las que tenia que acceder su programa, así como a las áreas referidas indirectamente; en el modelo de 1978 se introducen modificaciones para mejorar la situación.

También el concepto de modo de emplazamiento o ubicación de los registros (LOCATION MODE) en el lenguaje de definición de datos y los mecanismos de selección de un registro que utilizan la clave de base de datos, guardando la dirección física y recuperando después el registro indicando dicha dirección, han sido muy controvertidos en razón de la pérdida de independencia que produce y de los problemas que causa cuando se reorganiza la base de datos.

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

Arquitectura

En primer lugar destacar el cambio sufrido a través de las distintas especificaciones, ya que se empezó por una arquitectura de dos niveles (esquema y subesquema) y que terminó en una de tres niveles al separarse los aspectos físicos en un nuevo esquema (esquema de almacenamiento) de las características de tipo lógico que continúan formando parte del esquema.

El esquema de las propuestas de 1971 se transforma en 1978 en una descripción esencialmente lógica de la base de datos al eliminarse de el los aspectos físicos, como son los relacionados con el emplazamiento y la agrupación de las ocurrencias de registro, los punteros, etc... que pasan al esquema de almacenamiento. A fin de describir estas características de tipo físico aparece el lenguaje de definición del esquema de almacenamiento (DSDL), que permite describir como se organizan y almacenan los datos en los soportes, independientemente de los dispositivos y del sistema operativo.

Elementos del modelo y definiciones

Los elementos básicos de la estructura de datos propia del modelo CODASYL son:

• Elemento de datos (Data item): Es la unidad de datos más pequeña a la que se puede hacer referencia en el modelo CODASYL. Un elemento de datos a de tener un nombre, y una ocurrencia del mismo contiene un valor que puede ser de distintos tipos (booleano, numérico, tira de caracteres,...) además, un elemento de datos puede definirse como dependiente de los valores de otros elementos (datos derivados).
• Agregado de datos (data aggregate): puede ser un vector, con un numero fijo de elementos, o un grupo repetitivo. El elemento y le agregado de datos se corresponden con los campos de los ficheros clásicos o con los atributos de otros modelos, aunque a diferencia de algunos modelos, como el relacional, aquí si que se admiten estructuras no planas como son los agregados.
• Registro (record): colección nominada de elementos de datos. Es la unidad básica de acceso y manipulación de la base de datos y se corresponde con el concepto de registro (en los ficheros) y de entidad (en otros modelos como el E/R).
• Conjunto (SET o COSET): es una colección nominada de dos o mas tipos de registros que establece una vinculación entre ellos. Constituye el elemento clave y distintivo de este modelo de datos, siendo el origen de muchas de sus restricciones, tanto inherentes como opcionales. Las interrelaciones 1:N de otros modelos se representan en CODASYL como SET.
• Área (area o realm): es una subdivisión nominada del espacio de almacenamiento direccionable de la base de datos que contiene ocurrencias de registros. En un área puede haber ocurrencias de mas de un tipo de registro y las ocurrencias de un mismo tipo de registro pueden estar contenidas en distintas áreas, aunque una ocurrencia determinada se almacena solo en una área. En 1981 paso a formar parte del esquema de almacenamiento.
• Clave de base de datos (Database Key): identificador interno único para cada ocurrencia del registro, que proporciona su dirección en la base de datos. en principio, esta clave era permanente y se podía utilizar par acceder rápidamente a un registro de forma directa o para indicar donde almacenarlo, pero suponía un grave obstáculo para conseguir la independencia lógica / física por lo que las últimas versiones del modelo restringen mucho su uso, aunque se conservó.

Conjunto

En el modelo CODASYL, el conjunto, también llamado SET o COSET, constituye el elemento básico para la representación de las interrelaciones. Por medio de los SET, se establecen asociaciones jerárquicas (1:N) a dos niveles, en las cuales el nodo raíz se llama propietario (owner) y los nodos descendientes de uno o mas tipos se denominan miembros (members).

Una representación de un SET y una ocurrencia del mismo podría ser por ejemplo:

La flecha del esquema parte del propietario y apunta al miembro, lo que indica que el tipo de interrelación es 1:N o 1:1 en dicho sentido. El SET tiene un nombre, lo que permite establecer más de una interrelación entre un par de registros propietario-miembro. por tanto, el SET representa un tipo de interrelación nominada entre tipos de registros. En la ocurrencia de SET es una ocurrencia del registro propietario (P) y m1,m2... son ocurrencias del registro miembro (M) asociadas mediante una interrelación que a nivel físico se puede establecer, en principio, mediante cualquier mecanismo, pero en la práctica se realiza mediante punteros, bien embebidos o empotrados.

En el modelo CODASYL, un mismo tipo de entidad puede ser propietarios de un tipo SET y miembro en otro distinto, lo que le da una gran flexibilidad al modelo. En otros modelos de datos de tipo red, como por ejemplo el instrumentado en el sistema total, no se admite tales interrelaciones.

También es posible en el modelo CODASYL considerar las ocurrencias de una entidad (registros) interrelacionadas entre si como si se tratara de un fichero clásico. Para ello habría que definir un SET especial, denominado singular, en el que el propietario sería ficticio (el sistema) y el miembro el tipo de entidad cuyas ocurrencias queremos que estén interrelacionadas con independencia de que dicho registro intervenga o no en otros SET; este tipo de SET singular tiene una única ocurrencia de SET y su forma de instrumentación a nivel interno suele ser de tipo INDEX.

se puede resumir las características básicas del modelo en los siguientes puntos:

• Un SET es una colección nominada de dos o mas tipos de registros que representa un tipo de interrelación 1:N (también 1:1)
• Cada SET debe tener forzosamente un tipo de registro propietario y uno o más tipos de registros miembros
• No hay limitación en cuanto al número de SET que pueden declararse en el esquema
• Cualquier registro pude ser declarado propietario de uno o varios SET
• Cualquier registro puede ser declarado miembro de uno o varios SET
• Pueden existir SET singulares en los que el propietario es el sistema
• Aunque un tipo de registro se haya declarado miembro de un SET, existe la posibilidad de no encadenar en el SET ciertas ocurrencias del mismo, las cuales no pertenecerán a ningún propietario, es decir, quedarán "sueltas" respecto a ese SET.