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