>_
EngineeringNotes
Back to DBMS Topics
Lecture 16

Types of Databases

Database management systems have evolved through several conceptual models. Choosing the appropriate architecture requires an in-depth understanding of the four primary paradigms: Relational (RDBMS), Object-Oriented, NoSQL, and Hierarchical models.

1

Relational Databases (RDBMS)

Relational databases represent the most widely adopted database paradigm. Designed in the 1970s, they store data in structured tables, representing entities and relationships through schema-enforced attributes.

Core Mechanics of RDBMS

Relational databases store information in discrete tables with fixed rows and columns. Tables are joined together dynamically by shared fields known as foreign keys. They utilize **Structured Query Language (SQL)** as a standardized querying interface for all operations: Creating, Reading, Updating, and Deleting (CRUD) data.

Example Association: A database can maintain a User table containing profile information. When a user makes a purchase, the purchase is recorded in a separate Purchases table. Rather than duplicating user data inside purchases, the tables are dynamically joined together via a foreign key (e.g. User.id = Purchases.userId).
Core Strengths
  • Ubiquitous Standard: Steady, massive user base and battle-tested maturity since the 1970s.
  • Structured Optimization: Highly optimized for working with structured, reliable schema data.
  • Stronger Normalization: Guarantees rigorous normalization, eliminating duplicate data anomalies.
  • Declarative Power: Standard querying capability using well-known SQL interfaces.
Limitations & Challenges
  • Scalability Issues: Relational architectures are designed to scale up vertically. Horizontal scaling (scale-out across multiple nodes) is highly complex due to shared-nothing joins.
  • Complexity at Scale: As data sets expand into billions of rows, the overhead of joining massive tables causes extreme latency, requiring high complexity optimizations.
Standard Examples
MySQLMicrosoft SQL ServerOracle DatabasePostgreSQL
2

Object-Oriented Databases (OODBMS)

Object-Oriented databases align directly with the object-oriented programming (OOP) paradigm, bridging the semantic gap between application code objects and disk storage patterns.

Core Concepts & Design

OODBMS models are defined by core OOP concepts: Inheritance, Object-Identity, and Encapsulation (information hiding) with custom methods providing an interface to interact with data.

While traditional entity-relationship models support complex structures to some extent, it is encapsulation and unique object identifiers (OIDs) that distinguish OODBMS from E-R designs. Data is treated strictly as an object; all related bits of information are stored and loaded as one instantly available object package, rather than split across multiple tables.

Relationship Complexity Warning: Because OODBMS maintains complex OOP hierarchies, databases can become extremely complex if there are multiple interrelated networks. Maintaining these relationships without strict RDBMS schemas can be tedious and resource-intensive at times.
Advantages
  • Fast Storage & Retrieval: Since information is stored as complete, self-contained objects, reading data is quick and avoids table assembly joins.
  • Complex Data Support: Can handle complex data relationships and more variety of data types than standard relational databases.
  • Friendly Modeling: Provides a natural, intuitive structure to model advanced, real-world inheritance patterns.
  • Natively OOP Compatible: Works seamlessly with the features, libraries, and design patterns of Object-Oriented languages.
Disadvantages
  • Performance Degrades under Complexity: High schema complexity can cause performance degradation where read, write, update, and delete operations slow down heavily.
  • Lacks Community Adoption: Extremely limited community support and developer adoption compared to relational databases.
  • No Support for Views: Unlike RDBMS, OODBMS models generally do not support relational 'Views' to customize user access representations.
Standard Examples
ObjectDBGemStone-Sdb4o
3

NoSQL Databases

NoSQL represent a scale-out alternative to the rigid tabular paradigms, offering high velocity write rates, geo-replication, and dynamic schemas.

Key Features of NoSQL

NoSQL ("not only SQL") databases store data in alternative non-tabular structures, supporting Document, Key-Value, Wide-Column, and Graph formats. They provide highly flexible schemas, allow structures to adjust dynamically, and easily scale horizontally across commodity clusters to handle Big Data volumes.

For a complete deep-dive into NoSQL history, advantages, data models (Key-Value, Columnar, Document, Graph), and limitations, please check out the dedicated lesson module.

View NoSQL Notes
4

Hierarchical Databases

Hierarchical databases structure data in strict, nested parent-child trees. They are highly efficient for concrete, one-to-many organizational charts.

Tree-Like Architecture & Constraints

The schema of a hierarchical database is structured as a tree organization. It begins at a root "parent" directory of data stored as records that links to various other subdirectory branches, and each subdirectory branch, or child record, may link to various other subdirectory branches. While a parent record can have several child records, each child record is strictly restricted to only one parent record.

Field Properties

Data within records is stored in the form of fields, and each field can only contain one value. Retrieving hierarchical data from a hierarchical database architecture requires traversing the entire tree, starting at the root node.

Physical Disk & Separation

Because physical disk storage systems are inherently structured hierarchically (e.g. tracks, sectors, clusters), hierarchical models can also be used as physical models. Due to the separation of the tables from physical storage structures, information can easily be added or deleted without affecting the entirety of the database.

Key Advantages
  • Traversing Speed: The one-to-many organisation of data makes traversing the database simple and fast, with no complex join calculations.
  • Agility in Modifying Data: Separation of tables from physical layers allows information to be easily added or deleted without affecting the entirety of the database.
  • Language Support: Most major programming languages offer native functionality for reading tree structure databases.
Major Disadvantages
  • Inflexible Nature: Highly inflexible. The one-to-many structure is not ideal for complex structures as it cannot describe relationships in which each child node has multiple parent nodes.
  • Sequential Searching: The tree-like organisation of data requires top-to-bottom sequential searching, which is highly time-consuming.
  • Data Redundancy: Requires repetitive storage of data in multiple different entities to maintain associations, which can be redundant.
Typical Usecases
  • Website navigation drop-down menus.
  • Computer folders directories in operating systems like Microsoft Windows OS.
  • Organizational department hierarchies (individual employees reporting to a single department).
Examples
IBM IMS (Information Management System)
5

Network Databases

Network databases act as a powerful extension of Hierarchical databases, discarding strict single-parent limits to support complex graph network structures.

Graph Structure & Many-to-Many Mapping

Network databases are an extension of Hierarchical databases where the child records are given the freedom to associate with multiple parent records. Rather than a tree, they are organised in a Graph structure, allowing them to handle and capture complex relations.

Advantages & Capabilities
  • Handles Complex Relations: Native support for modeling and capturing complex records without duplicate data nodes.
  • M:N Links Architecture: Dynamically models many-to-many associations by allowing child entities to connect with multiple parents.
Limitations & Challenges
  • Tedious Maintenance: Schema updates and pointer navigation link updates are highly tedious.
  • Slow Retrieval Speed: Traversing through multiple complex M:N links may cause slow retrieval times at scale.
  • Minimal Community Support: Legacy technology lacking web developer community groups or documentation.
Core Architecture Concept

By arranging data records in a graph where records form vertices and associations act as edges, Network databases solve the duplication limits of strict trees.

Examples
Integrated Data Store (IDS)IDMS (Integrated Database Management System)Raima Database ManagerTurboIMAGE