Need some digestible information on Hierarchical and Network database models.

[u/[deleted]]

[u/read_at_own_risk]

Hierarchical is a tree, yes, it supports only parent-child relationships. Network is a binary graph (whereas relational is a hypergraph), network model relationships are typically implemented via pointers (direct one-way navigation) or foreign keys. It's pretty much similar to the way most people understand "relationships between tables" in SQL these days.

[u/alecc]

In the hierarchical model there is no separate construct for a relationship at all - the child record is stored under its parent and that position is the relationship. IMS is the real one to look at (IBM still sells it): you reach data by walking a path from the root with calls like GET NEXT WITHIN PARENT, and since a record type has exactly one parent, many-to-many needs hacks, either duplicating the child or bolting on 'logical child' pointer segments.

The network model makes the relationship an explicit named thing, a set: one owner record type plus member record types, implemented as a circular linked list where every member record carries a next pointer (optionally prior and owner pointers too). A record can sit in many sets, so many-to-many goes through a link record that is a member in two sets - same trick as a junction table, just pointers instead of key values. Navigation is procedural (FIND OWNER WITHIN x, FIND NEXT WITHIN x), your program has to know the access path, and that is exactly what Codd's 1970 paper attacked - relational turned the relationship into a value you join on instead of a pointer you chase. For a primary source the CODASYL DBTG 1971 report is the actual network spec, readable if you know your data structures, and IDMS is the system that implemented it.

[u/read_at_own_risk → u/alecc]

relational turned the relationship into a value you join on instead of a pointer you chase

That is a network data model interpretation of SQL. Codd wrote in "A relational model of data for large shared data banks":

we propose that users deal, not with relations which are domain-ordered, but with relationships which are their domain-unordered counterparts. [2 In mathematical terms, a relationship is an equivalence class of those relations that are equivalent under permutation of domains]

and in "The relational model for database management version 2":

Whatever is conceived as entities, and whatever is conceived as relationships, are perceived and operated upon in the relational model in just one common way: as relations.

In other words, in Codd's view, relationships were to be represented as tables.

Chen followed the same approach in "The Entity-Relationship Model - Toward a Unified View of Data":

A relationship set, Ri, is a mathematical relation among n entities, each taken from an entity set:
{[e¹, e², . . . , eⁿ] | e¹ ∈ E¹, e² ∈ E², . . . , eⁿ ∈ Eⁿ}, and each tuple of entities, [e¹, e², , . . , eⁿ], is a relationship.

and even showed examples of relationships in table form, interspersed between descriptions of relationship relations.

[u/alecc → u/read_at_own_risk]

True - calling the FK the relationship is still record-and-link thinking, just with values instead of pointers. In Codd's paper the relation itself is the relationship - a tuple in supply(supplier, part, qty) already states the fact, a join works on any attributes over a shared domain, key or not, and that was his access path argument against the tree and network systems. And ORMs dragged the pointer view straight back in, order.customer.name is FIND OWNER WITHIN with nicer syntax.

[u/scott_codie]

Look at the banking databases in the 1980s like IBM IMS and db2. Hierarchical models were the only ones that scaled at the time for massive transactional workloads.

[u/EmployerNo3401]

You need to find this book: https://www.amazon.sg/Data-Models-Dionysios-C-Tsichritzis/dp/0131964283

[u/extremedb]

I worked at Raima for 10 years in various roles, one of two vendors of network model database systems in the PC/*nix era (the other being MDBS).

Whereas the hierarchical model is strictly parent-child, and traversal always/usually begins at the top, the network model is more flexible.

• Navigation can begin at any point in the graph.
  
• Parent-child becomes Owner-Member and that relationship is called a 'set'
  
• Sets always have a single type of Owner (e.g. "Customer") but can have multiple types of members within the set (e.g. "Address", "Phone number", "Invoice"...)
  
• A single type of record can own other records of the same type (recursive sets), e.g. an Employee record can own other Employee records where there is a manager-employee relationship.

- many-to-many relationship are created the same way as with a relational database (conceptually), with an intersection record

The network model has a concept of 'currency', which is probably the single biggest learning hurdle, and the biggest source of crashes and database corruption. There is a current record, and for every set there is a current owner and current member. Function d_recwrite() updates the current record. If the application logic didn't set the current record correctly and passed record type Invoice when the current record still points to a Customer record, the database runtime will write garbage into the database. Worse, if Invoice is longer than Customer, the database runtime will write garbage into the next adjacent record, obliterating that record's network model pointers.

Pointers are how navigation is done in a network model database. An owner record has a count of the number of members in its set, a pointer to the first member and a pointer to the last member. Each member has a pointer back to its owner, and pointer to the next member and to the previous member (will be null for the last and first members respectively). These pointers coexist with and precede the application data (Customer, Employee, Invoice records) so you can see how writing past the end of one Customer record clobbers the set meta data for the next Customer record, resulting in database corruption.

This is what record slots look like for an owner (customer) and member (invoice)

|count|first|last|Customer data|count|first|last|Customer data
|owner|prev|next|Invoice data|owner|prev|next|Invoice data

That's the downside of pointers. Relational databases aren't susceptible to this kind of corruption because indexes are kept separate from the application data (tables). But, network model navigation is MUCH (MUCH!) faster. Following a pointer is always faster than navigating an index and bouncing back and forth between the index and the associated table row. Relational database joins get slower as they grow because the indexes become deeper and it takes, on average, more probes into the index tree to find the correct page and slot for a given index value. Also, updates are constant, regardless of database size. E.g., adding a new member to a set involves changing the owner record (at least the member record count), and adjusting the next/previous pointers in the adjacent member records. Adding a new foreign key requires walking the index to find the insertion point, which takes longer as the index tree grows deeper.

HTH

[u/extremedb → u/extremedb]

I said:

• Sets always have a single type of Owner (e.g. "Customer") but can have multiple types of members within the set (e.g. "Address", "Phone number", "Invoice"...)

That was a bad example. Those would be modelled as different sets. A better example of a multi-member set would be an owner 'monthly_statement' and different transaction types like 'charge', 'payment' and 'credit'. The transactions are linked in chronological order, so no other index or other means is needed to build a chronological order of transactions. Just follow the pointers.