Figure 2 shows a CODASYL network database that represents the Bureau's data.
(1) Each IMS segment or CODASYL record that represents a real-world entity will be converted into a table in the relational database.
(3) Each IMS logical chld pair or CODASYL juncture record that accomplishes a many-to-many relationship will be converted into a table in the relational database.
Beginning with the IMS database in Figure 1 (the steps for the CODASYL network database in Figure 2 are similar), the conversion to the relational database in Figure 3 proceeds in the following manner.
In CODASYL network databases, immediately superior and subordinate record types (known as a set when combined) are connected to each other with circular chains of next pointers.
In a CODASYL network database, direct access via hashing to any record type of one's choosing is tempting, but the absence of hashing provides faster access when an ordered subset of the occurences of a record type have to be retrieved from an occurrence of the superior or owner record type of the set they are in.
To begin with, every relational table that was directly derived from the root segment of an IMS hierarchy or a hashed CODASYL network record must be indexed or hashed on the equivalent key fields (e.g., the HNAME field of the Hotel segment of the Hotel hierarchy of Figure 1 and the HNAME field of the Hotel table of Figure 3).
The same can be done for CODASYL network record types.
Contemporaneous with the Codasyl committee's report, McLean  proposed a somewhat broader classification of end users.
Rockart and Flannery  built upon the classifications of end-users proposed by Codasyl and McLean [7, 19].
The Codasyl categorization of indirect end user corresponds to node (0, 0, 0) (consumer) on Figure 1.
 Codasyl end-user facilities committee status report.