CODASYL

CODASYL (also spelled Codasyl) is the acronym for the "Conference on Data Systems Languages", a consortium of computer industries formed in 1959 with the aim of regulating the development of a standard programming language that could be used on a multitude of computers. From all these efforts the COBOL language resulted.

CODASYL members belonged to industries and government institutions related to data processing. Its main goal was to promote more effective analysis, design and implementation of data systems. The organization worked on various languages over time but never came to any standards, leaving the process to ANSI.

In 1965 CODASYL formed the List Processing Task Force (in Spanish, Grupo de Trabajo para el Procesado de Listas). This group was dedicated to developing extensions to the COBOL language for processing collections of records; the name arose because of the IDS system (Integrated Data System) developed by Charles Bachman (system that represented the greatest technical contribution to the project), and which handled the different relationships through chains of pointers. In 1967 the group was renamed the Group of Work on Databases, and its first report dated January 1968 was entitled COBOL extensions to handle data bases (in Spanish, COBOL extensions for database management). In October 1969, the DBTG published the first specifications for the network database model, which came to be known as the Codasyl Model. These specifications themselves defined several languages separately: a data description language (DDL) to define the database schema, another DDL to create one or more subschemas to define views of the database in applications.; and a data manipulation language (DML) that defined keywords to include in COBOL code for database calls and updates. Although work always focused on COBOL, the idea of an independent language began to emerge, prompted by IBM's claims to use PL/I as a replacement for COBOL.

In 1971, largely in response to the need for the new programming language's independence, work was reorganized: development of DDL was continued by the Data Description Language Committee, while The development of COBOL DML was taken over by the COBOL Language Committee. In hindsight, this split had unfortunate consequences. The two groups were never able to synchronize their specifications, forcing dealers to fix the problems caused by the differences between them. Finally, the appearance of a lack of interoperability between implementations became inevitable.

Some companies have implemented database products roughly conforming to the DBTG specifications, the best known of which are: Honeywell Integrated Data Store (IDS/2), Cullinet Integrated Database Management System (IDMS), Univac DMS-1100 or Digital Equipment Corporation DBMS32.

The CODASYL model

The Codasyl model defined a series of basic elements that defined its structure of data. They are the following:

- Data element.- Smallest data unit that can be referenced. It can be of different types, and can be defined as dependent on values of other elements (derived data).

- Aggregate data.- It is similar to the fields of a file or the attributes of other models.

- Record.- Named collection of data elements. Basic unit of access and manipulation. It resembles records in files and entities in the E/R model.

- Set (SET).- Nominated collection of two or more types of records that establishes a link between them. Origin of many restrictions. 1:N relationships are represented here by SET.

- Area.- Named subdivision of the addressable space of the database that contains record occurrences.

- Database key ▪ unique internal identifier for each record occurrence.

Provide your address in the database. It is an obstacle to achieve logical / physical independence. It caused problems to reuse a key when the database was reorganized.

CODASYL: SETS (SET)

The set is one of the most important elements of the Codasyl model, since it constitutes the basic element for the representation of interrelationships. Using SET, hierarchical relationships (1:N) are established at two levels. The root node is the owner and the descendant nodes (can be of various types) are the members.

BASIC CHARACTERISTICS OF THE CODASYL MODEL

The basic characteristics of the model can be summarized as:

- A SET is a named collection of two or more record types that represent a 1:N (consequently also 1:1) type of relationship.

- Each SET will have an owner record type and one or more member record types.

- The number of SETs that can be declared in the system is unlimited.

- Any record can own one or more SETs.

- Any record can be a member of one or more SETs.

- There may be singular SETs in which the owner is the system (an entity is interrelated with itself).

- Despite the fact that an entity is a member of a SET, there is the possibility that certain occurrences of that entity are not bound to the SET, so they would not have an owner and would remain unbound with respect to that SET.

INHERENT RESTRICTIONS OF THE CODASYL MODEL.

When we talked about the general network model, we said that it was a very flexible model at the cost of having no inherent restrictions. This absence of restrictions makes it very difficult to implement, and in the long run it usually reports poor performance, which is why, as we also said, it is no more than a theoretical model.

The Codasyl model is based on the general network model, but unlike the latter, it is a used model. This is because Codasyl has included inherent constraints that make it possible to implement and achieve high system performance.

The restrictions are as follows:

- Only two-level (owner and member) hierarchical relationship types are supported. Whether the combination of several SETs to generate multilevel hierarchies is supported.

- Only one record type is allowed at the owner level.

- In the same SET, a record is not allowed to be both owner and member, reflexivity is not allowed. Although this restriction was removed over time, it is still used by Codasyl-based products.

- The same member occurrence cannot belong in the same SET type to more than one owner. This simplifies the physical implementation of SETs, since their occurrences can be arranged as a string.