Relational Database Model and Other Database Models

A database model describes how data is organized, how relationships are represented, and how applications retrieve and update data. In practice, the model you choose influences everything from query language and indexing to how difficult it is to change the design over time.

In this lesson you will:

1. Define the relational model using its core structures (table, row, column, keys, domain).
2. Compare the relational model to other widely cited models: object-oriented, hierarchical, and network.
3. Place XML and data grids in context as technologies that often complement database systems and influence modeling decisions.

The classic “standard” models most often discussed in database fundamentals are the relational, object-oriented, hierarchical, and network models. Each solves the same core problem—storing related data—but they represent relationships differently and require different query approaches.

The relational model organizes data into relations, commonly implemented as two-dimensional tables. A table stores facts about one subject area, and relationships between subjects are represented logically using keys.

• Table (Relation): ^[1] A collection of rows representing one entity or concept (for example, Student, Customer, Order).
• Column (Attribute / Field): ^[2] A named property of the entity (for example, Student_Number, LastName, OrderDate).
• Row (Tuple): A single record containing one value for each column in the table.
• Domain: The allowed type and set of values for a column (data type + rules).
• Keys: Columns that identify and relate data:
  • Primary key: uniquely identifies each row.
  • Foreign key: references a primary key in another table to represent a relationship.

The relational model is strongly associated with SQL, which provides a declarative way to retrieve and update data. Rather than navigating record-by-record, you describe the result you want, and the database engine chooses an efficient execution plan (joins, indexes, sort methods, etc.).

Why this model dominates: it is easy to understand, flexible to extend, supports ad hoc querying, and has decades of mature engineering behind transaction processing, recovery, security, and optimization.

Relational vocabulary you will keep using: entity, attribute, tuple, key, constraint, referential integrity, normalization, join, and transaction.

Some texts present a more formal description of the relational model (types, relation variables, relational operators). At an introductory level, the practical takeaway is simple: tables store facts, keys represent relationships, and SQL queries combine related tables to answer questions.

The object-oriented model stores data as objects, aligning database storage with object-oriented programming concepts. Instead of decomposing information into rows and columns, data is persisted as structures that can include nested fields and explicit object references.

• Strength: natural storage for complex, nested, or highly interconnected structures (for example, engineering models, graphics, scientific objects).
• Trade-off: general-purpose querying and ad hoc reporting can be harder than in a relational design, depending on the system.
• Modern reality: many systems are object-relational—they keep relational tables but add object-like extensions or mapping layers.

In practice, you will often see object orientation implemented at the application layer (classes) while the database remains relational, with an ORM or mapping layer translating between the two.

The hierarchical model stores data in a tree structure. Each child has exactly one parent, so the model naturally represents one-to-many relationships (parent → children).

• Strength: fast navigation when the access path is predictable and naturally hierarchical.
• Trade-off: many-to-many relationships are awkward, and redesign can be rigid.
• Where you still see it: legacy transaction systems and systems whose data naturally forms strict hierarchies.

The network model generalizes hierarchical storage by allowing records to participate in many-to-many relationships, producing a graph-like structure of connected records. Historically, it was standardized by CODASYL and implemented in systems such as IDMS.

• Strength: very efficient for predefined navigational access patterns.
• Trade-off: applications often must “navigate” relationships procedurally, and the structure can be difficult to evolve.

A useful way to compare models is to focus on how relationships are represented and how queries are written.

Feature	Network Model	Relational Model
Structure	Graph-like (records connected by links/pointers)	Tables (rows and columns)
Relationships	Navigational, commonly pointer-based	Logical, using keys (primary and foreign keys)
Query style	Procedural navigation (CODASYL-style DML)	Declarative SQL
Change management	Can be complex and rigid	Usually easier to evolve logically
Best fit	Fixed, known access paths	Dynamic, ad hoc reporting and mixed workloads

• Network model advantage: excels when relationships are predefined and performance is optimized around navigational paths.
• Relational model advantage: excels when requirements change and when users need flexible querying and reporting.

The XML model is commonly used to represent and exchange data in a hierarchical structure. XML is not a “database model” in the same sense as relational or network, but it strongly influences how information is structured and transmitted across systems.

Example XML representation:

<product>
  <id>101</id>
  <name>Smartphone</name>
</product>

Many database platforms support storing and querying XML (and, more commonly today, JSON). The key idea is that document-shaped data tends to be hierarchical and nested, while relational data is normalized into related tables.

A data grid is a distributed data layer (often in-memory) designed for low-latency access and horizontal scalability. Data grids are frequently used as a cache, a state store, or a fast access layer in front of a primary database.

1. What a data grid provides
   • Distributed storage across multiple nodes
   • Replication and failover for availability
   • Horizontal scaling by adding nodes
   • Optional transactional semantics, depending on the product and configuration
2. How modeling changes in grids
   • Designs often reduce or avoid joins (denormalization) to keep lookups fast.
   • Key-based access patterns are common (key-value, document-shaped records).
   • Consistency may be relaxed in exchange for latency and availability, depending on requirements.

In short: the relational model remains the foundation for durable transactional data, while data grids are frequently used to accelerate reads, handle session/state, or support high-throughput distributed workloads.

Conclusion: The relational model remains the most widely adopted database model because it represents relationships logically (keys), supports declarative querying (SQL), and scales well across changing requirements. The hierarchical and network models are historically important and still appear in specialized legacy environments, while object-oriented approaches align storage with application objects for complex structures. XML and data grids are not replacements for the relational model in most transactional systems, but they influence real-world architectures by shaping how data is exchanged (XML) and how systems scale for low-latency access (data grids).

[1] table: A collection of data arranged in rows and columns is known as a table and is the largest structure in a relational database.

[2] field: The smallest structure in a table; contains data describing the subject of a table.