5: Legacy Databases

Which two legacy database models are compared in this chapter?

The hierarchical model and the CODASYL network model.

What features do the hierarchical and CODASYL models share?

Record types, procedural DML, direct support for 1:N relationships, and workarounds or application logic for more complex requirements.

What is the main structural difference between hierarchical and CODASYL databases?

Hierarchical databases use a parent–child tree; CODASYL databases use an owner–member network.

What relationship ratio do both models directly support?

1:N.

What DML style do both legacy models use?

Procedural DML.

What is procedural DML?

A language style that specifies how to navigate to the desired data rather than only stating the desired result.

Why are applications closely tied to database structure in these legacy models?

They explicitly follow structural connections and access paths to locate records.

Do the chapter’s limitations necessarily describe every feature of every product based on these models?

No. They describe the models as presented in the slides.

What is a record type?

A definition describing a collection of similar records, such as PRODUCT.

What is a record occurrence?

One instance of a record type, such as Product 105, “Blue Pen.”

What is a field or data item?

A property within a record type, such as product number, name, or color.

How does a record type differ from a record occurrence?

The type defines a category of records; an occurrence is one actual record.

How many occurrences can a record type have?

Zero, one, or many.

What ER concept roughly corresponds to a record type?

An entity type.

What ER concept roughly corresponds to a record occurrence?

An entity.

Is PRODUCT a record type or a record occurrence?

A record type.

Is Product 105, “Blue Pen,” a record type or a record occurrence?

A record occurrence.

What historical project is associated with the origins of the hierarchical model in the slides?

NASA’s Apollo program.

Which IBM DBMS is associated with the hierarchical model?

IMS.

During which years do the slides place IBM’s development of IMS?

1966–1968.

What are the two building blocks of the hierarchical model?

Record types and relationship types.

What does a hierarchical relationship type connect?

Two record types in a parent–child relationship.

What structure does the hierarchical model use?

A tree structure.

What does a direct 1:N parent–child relationship permit?

One parent can have many children.

Can a hierarchical record type be a parent in multiple relationship types?

Yes. It can have different child record types.

In how many relationship types can a hierarchical record type participate as a child?

At most one.

Does “a child has at most one parent relationship” mean that a parent can have only one child?

No. A parent can have many children.

Can a hierarchical record type be both a child and a parent?

Yes. An intermediate type can be a child of one type and a parent of another.

What does nesting relationships mean in a hierarchy?

A child record type can itself be a parent further down the tree.

What is a root record type?

The record type at the top of a hierarchy.

What is a leaf record type?

A record type with no children.

In Department → Employee → Dependent, which record type is the root?

Department.

In Department → Employee → Dependent, which record type is the leaf?

Dependent.

In Department → Employee → Dependent, which type is both a parent and a child?

Employee.

How is data accessed in the hierarchical model described in this chapter?

By navigating downward from the root.

Who specifies the navigation path in hierarchical data access?

The application, using procedural DML.

What path would an application follow to reach a dependent in Department → Employee → Dependent?

Department, then Employee, then Dependent.

What is a key consequence of root-based procedural navigation?

Programs depend closely on the hierarchy’s structure and access paths.

Does the hierarchical model directly support M:N relationships?

No.

What are the two hierarchical workarounds for M:N relationships?

Duplicate child records beneath different parents, or use linked hierarchies with virtual child records and pointers.

How does the duplication workaround represent suppliers and products?

Choose Supplier as the parent and store Product child records beneath each supplier that supplies them.

If a product is supplied by three suppliers, how many full product copies are needed in the duplication representation?

Three copies, one under each supplier.

What is the main drawback of duplicating child records for M:N relationships?

Redundancy in the underlying entity data.

How can duplicated product records become inconsistent?

A product’s name or other details may be updated in some copies but not others.

Where can a supplier-specific price be stored in the hierarchical duplication approach?

In the product child record beneath that supplier.

Why is a supplier-specific price a relationship attribute?

It describes a particular supplier–product association rather than the supplier or product alone.

How do linked hierarchies represent an M:N relationship without duplicating entity data?

They connect separate hierarchies using virtual child record types, virtual parent–child relationships, and pointers.

What is the role of pointers in the linked-hierarchy workaround?

They support navigation between the separate hierarchical structures.

Where can relationship attributes be stored in the virtual-child approach?

In the virtual child record type.

What is the main benefit of virtual children and linked hierarchies?

They avoid repeated copies of the underlying entity data.

Does avoiding duplicated entity data eliminate the need to represent relationship information?

No. Each association and its relationship-specific facts still need to be represented.

Which hierarchical M:N workaround introduces redundant entity data?

Duplicating child records beneath different parents.

Which hierarchical M:N workaround avoids duplicating the underlying product data?

Linked hierarchies with virtual child records and pointers.

How are 1:1 relationships enforced in the hierarchical model described here?

Through application programs.

How are recursive relationships handled in the hierarchical model?

Using virtual child record types.

How are relationships involving more than two record types handled in the hierarchical model described here?

Using virtual child record types.

Can a child exist disconnected from its parent in the basic hierarchical structure?

No.

What is the existence dependency of a hierarchical child?

It depends on its parent and cannot remain unattached.

What does cascading deletion mean in the hierarchical model?

Deleting a parent also deletes its dependent children.

Which deletion behavior do the slides associate with hierarchical parent–child dependency?

ON DELETE CASCADE.

Does a hierarchical 1:N relationship automatically require every parent to have at least one child?

No. Supporting 1:N does not automatically enforce that minimum participation rule.

Does a Department–Employee 1:N structure guarantee exactly one manager per department?

No. That additional business rule is not guaranteed by the relationship ratio alone.

What organization developed the CODASYL model?

The Data Base Task Group of the Conference on Data System Languages.

In what year was the CODASYL model developed according to the slides?

1969.

What does CODASYL stand for?

Conference on Data System Languages.

What is an example of a CODASYL DBMS named in the slides?

CA-IDMS.

What are the two building blocks of the CODASYL model?

Record types and set types.

What is a CODASYL vector?

A multi-valued attribute.

What is an example of a CODASYL vector?

A list of email addresses.

What is a CODASYL repeated group?

A composite, multi-valued attribute.

What is an example of a CODASYL repeated group?

Several addresses, each containing street, city, and postal code.

How does a vector differ from a repeated group?

A vector contains multiple values; a repeated group contains multiple structured groups of values.

Which two attribute properties does a repeated group combine?

Composite and multi-valued.

How would a list of email addresses be classified in CODASYL?

As a vector.

How would multiple addresses with street, city, and postal code be classified in CODASYL?

As a repeated group.

What is a CODASYL set type?

A definition of a 1:N relationship between an owner record type and a member record type.

What are the two roles in a CODASYL set type?

Owner and member.

What is a CODASYL set occurrence?

One owner record together with its associated member records.

How many owner records does a set occurrence contain?

Exactly one.

How many member records can a set occurrence contain?

Zero, one, or many.

How does a set type differ from a set occurrence?

The set type defines an owner–member relationship; a set occurrence contains one actual owner and its associated members.

What is an example of a Department–Employee set occurrence?

One particular department record together with its associated employee records.

Can a CODASYL set occurrence have an owner but no members?

Yes. Zero members are allowed.

Can a CODASYL set occurrence contain multiple owners?

No. It contains exactly one owner.

Why is a CODASYL set not simply a mathematical set?

It distinguishes owner and member roles, includes both owner and members, and can order its members.

Can CODASYL member records be logically ordered?

Yes, for example alphabetically.

What feature makes CODASYL a network rather than a single-parent tree?

A record type can be a member in multiple set types.

Can multiple CODASYL set types connect the same record types?

Yes.

Can a CODASYL member record exist without an owner connection?

Yes, as described in this chapter.

How does child/member existence differ between the two legacy models?

A basic hierarchical child cannot be unattached; a CODASYL member record can exist without an owner connection.

An employee record has not yet been connected to a department. Which model explicitly permits this unattached member?

CODASYL.

How could Employee participate in multiple CODASYL set types?

It could be a member in both a Department–Employee set type and a Project–Employee set type.

Does membership in multiple set types imply unlimited membership in multiple occurrences of the same set type?

No. These are different concepts and should not be confused.

Does CODASYL directly support native M:N set types?

No. Its set types directly represent 1:N relationships.

How is an M:N relationship represented in CODASYL?

Introduce a dummy record type that is a member in two set types, with the original record types as owners.

What does a dummy record represent in a CODASYL M:N design?

A particular association between records of the original types.

Which conceptual-model construct is similar to a CODASYL dummy record used for M:N?

An associative entity.

How can CODASYL represent suppliers supplying products?

Use Supply as a dummy record type: Supplier owns Supply, and Product owns Supply.

In a CODASYL Supplier–Supply set type, which type is the owner and which is the member?

Supplier is the owner; Supply is the member.

In a CODASYL Product–Supply set type, which type is the owner and which is the member?

Product is the owner; Supply is the member.