The structure of every database is determined by a database model. A database model is a formal structure for organizing and linking data in a database.
What are the Standard Database Models?
The standard database models are:
Relational model: A formal structure that organizes data into relations (i.e., tables).
Object-oriented model: Object/relational database management systems (ORDBMSs) add new object storage capabilities to the relational systems at the core of modern information systems
hierarchical model: A database model that organizes data in a top-down (inverted tree) structure.
network model: An extension of the hierarchical model. (See hierarchical model.)
The major types of data models in the history of Databases are listed below.
Relational Model organizes data into two dimensional arrays known as relations(tables) and each relation consists of rows and columns. Another major characteristic of relational model is that of keys, designated columns in a relation used to order data or establish relations.
Relational Model
It is based on the relational model, which organizes data into tables comprising columns and rows. In the relational database model:
A record: (row) contains all the fields in a table. A particular instance of the subject of a table.
Table, field, and record are terms typically used in general database discussions. Table, column, and row are used to physically describe a tabular format.
Definition: The "relational model" consists of five components:
An open ended collection of scalar types, including type BOOLEAN in particular
A relation type generator and an intended interpretation for relations of types generated thereby
Facilities for defining relation variables of such generated relation types
A relational assignment operator for assigning relation values to such relation variables
A relationally complete (but otherwise open ended) collection of generic relational operators for deriving relation values from other relation values
Object Model: The "Object Model" aims to reduce the overhead of converting information representation in the database to an application specific representation. Unlike a traditional database, an object model allows for data persistence and storage by storing objects in the databases. The relationships between various objects are inherent in the structure of the objects. This is mainly used for complex data structures such as 2D and 3D graphics which must otherwise be flattened before storage in a relational database.
2) Diagram of the Object Model
Evolution of Object Databases: Object oriented databases or object databases incorporate the object data model to define data structures on which database operations such as CRUD can be performed. They store objects rather than data such as integers and strings. The relationship between various data is implicit to the object and manifests as object attributes and methods Object database management systems extend the object programming language with 1) transparently persistent data, 2) concurrency control, 3) data recovery, 4) associative queries.
3) Hierarchical model: The "hierarchical model" contains data organized into a tree-like structure. This supports parent-child relationships between data similar to a tree data structure where object types are represented by nodes and their relationships are represented by arcs. This model is restrictive in that it only allows one to many relationship (a parent can have many children but a child can only have one parent) An example of this is Jump to search IBM's Information Management System (IMS), which is a joint hierarchical database with extensive transaction processing capabilities.
Network Model: Network Model is similar to the hierarchical model in representation of data but allows for greater flexibility in data access as it supports many to may relationships. It is a database model that was developed as an evolution of the hierarchical model to address some of its limitations. It allows for more flexible and complex relationships between data records, representing them as a graph-like structure. The Network Model was standardized by the Conference on Data Systems Languages (CODASYL)[3] in the late 1960s. Here are some key characteristics of the Network Model with respect to databases:
The Network Model distinguishes itself from the Relational Model
The "Network Model" and the "Relational Model" are two distinct database models that differ in structure, relationships, and usability. Here's a breakdown of their key differences:
Structure and Representation
Network Model:
Data is represented as a graph or a network, with records (nodes) connected by links (edges).
Relationships are explicitly defined using pointers, creating a complex web of data.
It follows a many-to-many relationship approach and organizes data in a hierarchical or interconnected fashion.
Example: A "Customer" record may directly link to multiple "Orders" and vice versa.
Relational Model:
Data is represented in tabular form, where information is stored in tables (relations).
Relationships are defined logically using keys (primary and foreign keys) rather than physical pointers.
Each table can represent one entity type, and links are established using column values.
Example: A "Customer" table and an "Orders" table can be related using a "CustomerID" foreign key.
Relationships
Network Model:
Relationships are navigational and pre-defined, with links (pointers) directly connecting related records.
Accessing related data requires traversing the network, often through predefined paths.
Suited for complex relationships but requires more effort to design and maintain.
Relational Model:
Relationships are logical and flexible, established through common fields.
Data can be queried dynamically using SQL without the need for pre-defined navigational paths.
Simplifies data modeling, making it easier to add or modify relationships.
Querying Data
Network Model:
Requires navigational commands and procedural languages like CODASYL DML.
Queries involve following pointers, which can be complex and less intuitive.
Performance is high for pre-defined queries but struggles with ad hoc queries.
Relational Model:
Uses Declarative SQL, where users specify what they want rather than how to retrieve it.
Flexible and efficient for ad hoc queries.
SQL queries are easier to learn and use than navigational languages.
Flexibility and Usability
Network Model:
Less flexible; changes to the schema or relationships often require restructuring of the database.
More difficult to use and maintain due to its navigational nature and reliance on pointers.
Best suited for applications with fixed, well-known queries and relationships.
Relational Model:
Highly flexible; changes to tables or relationships are easier to implement.
Widely adopted because of its simplicity, abstraction, and ease of maintenance.
Best suited for dynamic applications where relationships may evolve over time.
Performance
Network Model:
Offers high performance for navigational queries, especially in scenarios with frequent and complex many-to-many relationships.
Inefficient for unstructured or ad hoc queries because of its reliance on traversing pointers.
Relational Model:
Performance can vary depending on indexing and query optimization but is generally slower than the Network Model for complex relationships.
More efficient for dynamic, unpredictable queries due to its SQL-driven approach.
Real-World Usage
Network Model:
Historically used in hierarchical and network database systems like IDMS and IMS.
Found in legacy systems and specialized applications requiring high performance in predefined relationships.
Relational Model:
Dominates modern database systems such as Oracle, MySQL, PostgreSQL, and SQL Server.
Common in applications across industries due to its standardization, flexibility, and ease of use.
Summary of Differences:
Feature
Network Model
Relational Model
Structure
Graph-like (nodes and edges)
Tables (rows and columns)
Relationships
Navigational (pointers)
Logical (keys)
Querying
Procedural
Declarative (SQL)
Flexibility
Rigid and complex
Flexible and simple
Performance
High for predefined queries
Efficient for dynamic queries
Use Cases
Legacy systems, fixed relationships
Modern applications, dynamic use
In summary, the "Network Model" excels in tightly controlled environments with complex predefined relationships, while the "Relational Model" offers greater flexibility, usability, and scalability, making it the dominant choice in modern database systems.
Relationship between Data Grid, Database and Data Model
A data grid is related to a database and a data model in several key ways, primarily in how it stores, manages, and processes distributed data. Below is a breakdown of how they interconnect:
1. What is a Data Grid?
A data grid is a distributed in-memory data storage system that provides scalability, low-latency access, and high availability for large datasets. It is commonly used in high-performance computing (HPC), financial systems, e-commerce, and cloud-based applications.
Key Characteristics of a Data Grid:
Distributed architecture (spreads data across multiple nodes)
In-memory storage (caches data for fast access)
Parallel processing (improves query and transaction performance)
High availability and fault tolerance (replication and failover mechanisms)
Scalability (adds/removes nodes dynamically)
Supports ACID transactions (in some implementations)
2. Relationship Between Data Grid and Database
Feature
Data Grid
Database
Data Storage
In-memory (RAM-based)
Disk-based (persistent storage)
Query Processing
Distributed, fast, and scalable
Centralized or distributed, but slower due to disk I/O
Use Case
Caching, real-time analytics, microservices
Transactional applications, data warehousing
Scalability
Horizontally scalable (adds/removes nodes)
Can be scaled but with more complexity
Fault Tolerance
Redundant nodes, replication
High Availability (HA) mechanisms like Oracle RAC
Data Persistence
Optional (can write to disk or databases)
Persistent storage by default
Data grids often complement databases by serving as a cache layer or a distributed storage layer to reduce load on traditional databases.
Example:
An Oracle database stores persistent transactional data.
A data grid (like Oracle Coherence, Redis, or Hazelcast) caches frequently accessed data, reducing database queries and improving response time.
3. Relationship Between Data Grid and Data Model
A data model defines how data is structured, related, and processed within a database or distributed system. Data grids store and manage data differently than traditional relational databases, which impacts the data model.
Data Grid Data Modeling Approaches
Key-Value Model (like Redis, Hazelcast, Oracle Coherence)
Relational-Like Structures (some grids support SQL queries)
Some grids, like Oracle Coherence and GridGain, support SQL-based querying on in-memory data.
Event-Driven Data Model
Data grids support real-time event processing, where data updates trigger actions or alerts.
How Data Modeling Changes for Data Grids
Denormalization is preferred to avoid joins and improve performance.
Indexing strategies differ (data grids often use hash-based or in-memory indexes).
ACID compliance varies, so eventual consistency may be used instead of strict transactions.
Sharding and partitioning strategies influence how data is distributed.
4. Real-World Use Cases
Financial Systems → Stock trading platforms use data grids for low-latency transactions.
E-Commerce → Shopping carts and session management use data grids for caching.
Big Data and AI → Data grids enable real-time analytics and machine learning workloads.
Cloud and Microservices → Microservices architectures use data grids for distributed caching and state management.
Conclusion
A data grid, database, and data model are interconnected in modern distributed architectures:
Databases store persistent structured data.
Data grids enhance performance with in-memory distributed storage.
Data models adapt based on the storage layer (relational, key-value, or document-based).
Relational Model Concepts
The relational model represents the database as a collection of relations. Informally, each relation resembles a table of values or, to some extent, a flat file of records. It is called a flat file because each record has a simple linear or flat structure. There are important differences between relations and files, as we shall soon see. When a relation is thought of as a table of values, each row in the table represents a collection of related data values. A row represents a fact that typically corresponds to a real-world entity or relationship. The table name and column names are used to help to interpret the meaning of the values in each row. For example, a student table is called STUDENT because each row represents facts about a particular student entity. The column names 1) Name, 2)Student_number, 3) Class, and 4) Major specify how to interpret the data values in each row, based on the column each value is in. All values in a column are of the same data type.
In the formal relational model terminology,
a row is called a tuple,
a column header is called an attribute, and
the table is called a relation.
The data type describing the types of values that can appear in each column is represented by a domain of possible values.
XML model
The XML model has emerged as a standard for exchanging data over the Web, and has been used as a basis for implementing several prototype native XML systems. XML uses hierarchical tree structures. It combines database concepts with concepts from document representation models. Data is represented as elements; with the use of tags, data can be nested to create complex hierarchical structures. This model conceptually resembles the object model but uses different terminology. XML capabilities have been added to many commercial DBMS products. In the next lesson, we will examine a relational database table in detail.
[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.
[3]CODASYL: The Conference on Data Systems Languages (CODASYL) was a consortium formed in 1959 to guide the development of a standard programming language for data processing. While their initial goal of a unified language wasn't achieved, CODASYL is best known for its work on the network database model, which heavily influenced early database management systems.
