The CODASYL Network Approach to DBMS's
Fundamental Concepts
Record type and record occurrence
Set type and set occurrence
Database cursors
System record and system sets
Navigation through the database
The hierarchical approach as the original dbms approach was developed by IBM in its IMS
(Information Management System) dbms in the early 60's. The hierarchical approach can
represent data in records in files and can represent 1:n relationships between files in a
hierarchical structure.
Pictures.
A hierarchical DB structure A non-hierarchical DB structure
CODASYL stands for Conference On DAta SYstem Languages which was a collection of
manufacturer, government and other interested participants.
The CODASYL approach was developed by a CODASYL subcommittee called the Database
Task Group, DBTG, as a “recommendation”, or a standard that DBMS manufacturer's could
follow.
They wanted an alternative to the restrictions of the hierarchical database systems such as IBM’s
IMS.
The name “network” in this approach was borrowed from the concept of a directed graph of
nodes and edges as a “network”
Again, let's compare the various terminologies for the different dbms approaches. All dbms
approaches represent "entities" as "records" stored in "files", and so we base the following chart
on these fundamental terms used in file data processing systems.
File
Record
Field
File Processing
File
Record
Field
SQL Relational
Theoretical
Relational
Network
Table
Row
Relationship Tuple
Hierarchical
Entity
Relationship
Object
Oriented DB
1:n
(Instance)
Relationship
-
Column Attribute -
Record
Type
Segment
Record
Field
Occurrence
Record
Field
Entity Type
Entity
Set Type
Parent/Child
Relationship
Attribute Relationship
Set
Occurance
Hierarchy
Occurance
?
Data
Type
Data
Type
(Domain)
Domain
(data
type)
Value
Type
A production ER database has not been developed.(?) It is mainly a concept. It provides an
understanding of the problems with the relational approach. The diagramming technique in
UML is a descendent from the ER.
DEFINITIONS:
Record Type - A record type is a description of the format of the records in a conceptual file.
Record Occurrence – A record occurrence of a record type is a specific instance of a record of
that type.
Example:
Record Type:
WAREHOUSE
WHNUMB
Record Occurrence
‘WH1’
CITY
FLOORS
‘Rock Hill’
1
Set Type - A set type consists of two record types, one designated as the owner record type and
the other designated as the member record type and satisfying:
Each record occurrence of the member record type is connected to exactly one
record occurrence of the owner record type.
Note that a record occurrence of the owner record type can be connected to any number of
member record occurrences.
Set Occurrence – A set occurrence of a set type consists of a single record occurrence of the
owner record type together with all of the member record occurrences that are connected to this
owner record occurrence.
Example: Here, the employee member records are shown as indented under the warehouse owner
record:
WH1
E1
E2
E3
Rock Hill
1
20000
2007
21000
2007
18000
2009
Implementing a Conceptual Database Design in a Network Database
- Each conceptual file is implemented as a record type in the network database (N-DB)
- Each 1:n relationship between two conceptual files is implemented as a set type in the
network database
Example: For the conceptual warehouses db design
(diagram here)
- The record types required are
- the Warehouse record type
- the Employee record type
- the Supplier record type
- the Shipment record type
- The set types required are
- the Warehouse-Employee set type
- the Employee-Shipment set type
- the Supplier-Shipment set type
System Sets:
To provide for a single point of entry into the database, some Network DBMS’s
implemented a single SYSTEM record type with a single SYSTEM record occurrence
that acts as the root of the database. Once this has been added, then in order to get to a
record, you have to start at the root and "navigate" through the records along a path to the
target record.
Any record type in the conceptual design that was not a member of a set type (did not
have a parent) had to be made a member of a system set.
Example: In the warehouse db design, must have two set types
- The system-warehouse set type
- The system-supplier set type
(diagram here)
Navigating through the Database
The thing that drove people away from this concept is navigation (accessing records in the
database)
Navigating through the DB refers to the method of accessing a record, that is, record occurrence.
In the network DBMS’s that use the system set concept, there is just one method of accessing
any record and that is to access it as the member record occurrence in the set occurrence of some
owner record occurrence of a set type.
Example: Assume the Warehouse database contains the following for the warehouse and
employee data:
Whole DB
Contents
=======
SYS
WH1
E1
E3
E7
WH2
E2
E4
WH3
E5
E6
SYS-WAR
set occurrence
==========
SYS
WH1
WH2
WH3
----- WAR-EMP set occurrences ---=========================
WH1
WH2
WH3
E1
E2
E5
E3
E4
E6
E7
There are three WAR-EMP set occurrences
Query statement syntax (pretend syntax)
1. FETCH FIRST record-type
2. FETCH FIRST record-type
3. FETCH NEXT record-type
4. FETCH NEXT record-type
5. STORE record-type
WITHIN
WITHIN
WITHIN
WITHIN
set-type
set-type USING fieldname in record-type
set-type
set-type USING fieldname in record-type
Query 1: Retrieve the WH1 record.
Copy 'WH1' into the WhNumb field of the Warehouse record buffer, then do a FETCH
FIRST using Format 2 above:
Warehouse.WhNumb = "WH1"
FETCH FIRST Warehouse WITHIN Sys-War USING WhNumb in Warehouse
Display (Warehouse)
Query 2: Retrieve the E1 record in the WH1 warehouse.
- Must know that it is in the WH1 WAR-EMP set occurrence.
- We would have to first fetch the WH1 record, then fetch the E1 record
Warehouse.WhNumb = "WH1"
Employee.EmpNumb = "E1"
FETCH FIRST Warehouse WITHIN Sys-War USING WhNumb in Warehouse
Display(Warehouse)
FETCH FIRST Employee WITHIN War-Emp USING EmpNumb in Employee
Display(Employee)
All database navigation depends on the current database currency cursor values.
An operation on the network database depends on which records the currency cursors are
pointing to during the current operation.
There are these currency cursors automatically created in the database from the schema:
- one cursor for the most recently accessed record in the database,
called the current of database
- one cursor for each record type, called the current of record type
- one cursor for each set type, called the current of set type
Trace of the cursor values for our warehouses database - each line represents a cursor:
Database Operation
OPEN
AFTER
CURSOR DB
FIRST
for
FETCH
of WH1
DB
SYS
WH1
WAR
null
WH1
EMP
Null
Null
SUP
Null
Null
SHIP
Null
Null
SYSSYS
WH1
WAR
SYS-SUP SYS
SYS
WARNull
WH1
EMP
EMPNull
Null
SHIP
SUPNull
null
SHIP
AFTER
FETCH
OF E1
FETCH
SUP1
STORE
SH1
E1
WH1
E1
Null
Null
WH1
SUP1
WH1
E1
SUP1
Null
WH1
SH1
WH1
E1
SUP1
SH1
WH1
SYS
E1
SUP1
E1
SUP1
E1
E1
E1
SH1
Null
SUP1
SH1
Query 3: Fetch first SUPPLIER in SYS-SUP
Storing a record: To store a record in the database, all of the record cursors of records that are to
own this new record must be set to point to these owner records.
Query 4: Store the shipment SH1
Query 5: List all of the employees in the WH1 warehouse.
For this operation, assume there is a database function EOS(set-type) that returns TRUE
if the specified set type is at end-of-set, and FALSE if not at end-of-set.
Warehouse.WhNumb = "WH1"
FETCH FIRST Warehouse WITHIN Sys-War USING WhNumb in Warehouse
FETCH FIRST Employee WITHIN War-Emp
While NOT EOS (Warehouse)
Display(Employee)
FETCH NEXT Employee WITHIN War-Emp
End-While
Query 6: List all warehouses and the employees in each warehouse.
FETCH FIRST Warehouse WITHIN Sys-War
While NOT EOS (Warehouse)
Display (Warehouse)
FETCH FIRST Employee WITHIN War-Emp
While NOT EOS(War-Emp)
Display(Employee)
FETCH NEXT Employee WITHIN War-Emp
End-While
FETCH NEXT Warehouse WITHIN Sys-War
End-While