At first, data was stored in individual files (transitioned from paper). The next improvement was a 'hierarchical DB model', where data was structured in the form of a tree [similar to a modern filesystem]. Data, in the form of nodes, are linked in a tree-like fashion. To traverse the tree, we need to know the underlying format ('class hierarchy, to make an analogy with classes and objects), and the actual path [eg. to relate A1 and D2, we need to traverse A1->B1->C3>D2].

Hierarchies are good for '1:M' [tree], but not 'M:N' [graph or multiple inheritance].

A network model is better than a hierarchical one, because it can capture M:N [in addition to the above, another example is 'products and orders'].

Note: this relation is NOT what relational modeling is about!! Here, we relate two entities, via a common attribute (AGENT_CODE, in our example).

Additional reading: here is information on, and comparison between, four ER notations: Chen, Crow, Rein85, IDEFIX.

Also called 'object stores', these dbs offer(ed) a way to store ("persist") objects on disk. The objects (entity instances) are instanced from classes (entities), like with standard OO programming practice.

Advantages:

• 'cleaner' design - objects mimic real-world counterparts
• inheritance and encapsulation possible
• richer datatypes (attributes) available
• good for CAD, multimedia..

Drawbacks:

• harder to query (compared to relational DBs) - no straightforward way to build and traverse relations between objects
• relations are simpler in certain situations

The RDBMS community collectively ignored this development..

These are a compromise between RDBs and OODBs - they feature an O-O front-end over a relational architecture. Interfacing applications do so in an O-O way, and queries/modifications are translated to/from relational form ("ORM").

Benefits:

• easy to access the data from an O-O application
• queries can be simpler (can use objects' structure)

Drawback:

• performance can be poor on account of the two-way translation

Data models have evolved - from 'hierarchical' (very rigid) to 'NoSQL' (VERY flexible).

An external model is a collection of 'fragmented', 'from the stakeholders' POV', modeling of a database.

A conceptual model unifies the external views into a cohesive one.

An internal model specifies what type of modeling (eg. relational, NoSQL...) to use for storing the data.

The physical model specifies actual data storage specifics (file format, APIs...).