***
←
→
.
.
.
.
.
.
.
.
.
.
.
Hierarchical modeling
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].
Network modeling
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'].
.
.
.
.
Data creation, querying
Relational model
Relational model
Relational DBMS
Relation - BETWEEN entities
Note: this relation is NOT what relational modeling is about!! Here, we relate two entities, via a common attribute (AGENT_CODE, in our example).
SQL + RDBMS
E-R
E-R
Notations
Notations - more..
Additional reading: here is information on, and comparison between, four ER notations: Chen, Crow, Rein85, IDEFIX.
O-O databases
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..
O-R databases
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: hierarchical => => NoSQL
Data models have evolved - from 'hierarchical' (very rigid) to 'NoSQL' (VERY flexible).
Layered data abstraction
External model
An external model is a collection of 'fragmented', 'from the stakeholders' POV', modeling of a database.
External model
Conceptual model
Conceptual model
A conceptual model unifies the external views into a cohesive one.
Internal model
An internal model specifies what type of modeling (eg. relational, NoSQL...) to use for storing the data.
Internal model
Physical model
The physical model specifies actual data storage specifics (file format, APIs...).