Knowledge Hub

Fourth Normal Form (4NF) addresses multi-valued dependencies. A table is in 4NF if it is already in Boyce–Codd Normal Form and does not contain two or more independent multi-valued facts about the same key. In simpler terms, a single row should not attempt to store multiple independent lists related to the same primary key.

A multi-valued dependency occurs when one key determines multiple independent sets of values that are unrelated to each other. When these independent lists are stored in the same table, they can unintentionally create false combinations, often described as a Cartesian explosion. This happens because relational tables combine values across columns, even when those values are logically independent.

Consider an extension of the loan domain. Suppose we attempt to store, in one table, the following information about each LoanID:

• A list of CollateralTypes (e.g., House, Car)
• A list of Guarantors (e.g., PersonA, PersonB)

(Projection–Join Normal Form)

Fifth Normal Form (5NF), also known as Projection–Join Normal Form (PJNF), eliminates redundancy that appears only when a table is decomposed into smaller projections and then re-joined. Unlike earlier normal forms, which focus on functional or multi-valued dependencies, 5NF addresses join dependencies, situations where a table can be reconstructed from multiple smaller tables, yet still contains hidden redundancy.

A table is in 5NF if it is already in Fourth Normal Form and every join dependency in the table is implied by the candidate keys alone. If a table can be decomposed into smaller tables in such a way that the original data can be perfectly reconstructed by joining them, without introducing spurious rows, then the decomposition should be performed.

To understand this more intuitively, consider an expanded loan example. Suppose we create a table that records relationships between Loan, Guarantor, and CollateralType together in one structure:

Sixth Normal Form (6NF) represents the most fine-grained level of relational decomposition used in practical modelling. A table is in 6NF when it is already in Fifth Normal Form and has been decomposed so that each relation captures a single fact about a key, typically with explicit time validity. In this form, every table represents one attribute, or a tightly bound set of attributes, over time.

The guiding idea of 6NF can be summarized simply: one attribute, one timeline, one table.

Earlier normalization stages focused on eliminating redundancy caused by partial dependencies, transitive dependencies, multi-valued dependencies, and join dependencies. Sixth Normal Form goes further by decomposing data to its smallest meaningful components, particularly when time becomes an important dimension.

To understand 6NF in the loan approval context, consider a Loan table that includes attributes such as Amount, InterestRate, ProductType, and Status. In earlier normal forms, these attributes might coexist in a single table keyed by LoanID. However, if each of these attributes can change independently over time, storing them together may create temporal anomalies.

Domain–Key Normal Form (DKNF) represents the theoretical “ultimate” stage of normalization. A relation is in DKNF if every constraint on the table can be expressed solely as either a domain constraint or a key constraint. If any rule governing the data cannot be enforced purely through domain definitions or key definitions, the relation is not in DKNF.

A domain constraint defines what values are valid for a column. For example, a DecisionStatus column may allow only APPROVED, REJECTED, or PENDING. An InterestRate column may allow only non-negative numeric values. These constraints govern permissible values.

A key constraint defines uniqueness. It specifies which combination of attributes uniquely identifies a row. For example, LoanID may uniquely identify a loan. A composite key such as (LoanID, EffectiveStart) may uniquely identify a time-bound fact.

The rule for achieving DKNF is conceptually simple but practically demanding. Starting from Sixth Normal Form, all remaining constraints, including business rules, dependencies, conditional requirements, and cross-attribute logic, must be expressible through domain or key rules alone. No non-trivial constraints should remain outside these two categories.

Hierarchical Data Modelling is one of the earliest approaches to organizing data in computer systems. It structures data in a strict tree-like format, where each child record has exactly one parent. This creates a single-rooted hierarchy composed entirely of one-to-many relationships. The model enforces a rigid parent–child structure in which navigation always follows predefined paths.

The goal of hierarchical modelling is clarity and efficiency in environments where data relationships are predictable and fixed. By organizing records into a tree, systems can navigate from parent to child quickly and deterministically. Each level in the hierarchy represents a deeper level of detail within the same structural path.

Historically, this model dominated the 1960s and 1970s, particularly in mainframe environments such as IBM’s Information Management System (IMS). In such systems, data might be structured as:

Network Data Modelling is a pre-relational database approach that organizes data using owner–member sets, allowing records to participate in multiple parent and child relationships. Unlike the strict tree structure of hierarchical modelling, the network model forms a flexible graph-like structure where records can have many-to-many connections.

The goal of the network model was to overcome the limitations of hierarchical databases. In hierarchical systems, each child could have only one parent, making many-to-many relationships difficult or impossible to represent naturally. The network model removed this restriction by allowing records to be linked through multiple set relationships.

Historically, this model gained prominence in the 1960s through the CODASYL Data Base Task Group and systems such as IDMS. It became widely used in banking, insurance, and government systems before the relational model emerged.

Object-Oriented Data Modelling represents data as objects that combine attributes (data) and methods (behavior), mirroring the principles of object-oriented programming such as classes, inheritance, encapsulation, and polymorphism. Instead of separating data from logic, this approach treats real-world entities as self-contained units that include both state and behavior. The goal was to align persistent storage directly with object-oriented application design, removing the need to transform objects into relational tables.

In this model, entities such as Customer, LoanApplication, or LoanOfficer are defined as classes. Each class contains attributes that describe its state and methods that define its behavior. For example, a Customer object may contain attributes like CustomerID, Name, and CreditScore, along with a method such as calculateRisk(). A LoanApplication object may include attributes such as LoanID, Amount, InterestRate, and Status, together with methods like approve() or reject(). Relationships between entities are expressed through object references rather than foreign keys, and inheritance allows specialized types to extend base classes.

NoSQL Data Modelling refers to the practice of designing data structures for non-relational databases such as document stores, key-value stores, wide-column databases, and graph databases. Unlike relational modelling, which is driven by normalization theory and functional dependencies, NoSQL modelling is driven primarily by application access patterns and workload requirements. The goal is not theoretical purity but scalable, high-performance data access.

The primary objective of NoSQL data modelling is to support flexible or schema-less storage, distributed scale-out architectures, and fast, query-driven design. Instead of decomposing data into highly normalized tables, NoSQL models are often intentionally denormalized or embedded to minimize joins and reduce cross-node communication in distributed environments. Data is structured according to how it will be read and written, not according to relational dependency rules.

Document databases store data as JSON-like documents that can contain nested fields, arrays, and variable structures. Instead of organizing information into rows and columns, they treat each document as a self-contained representation of a business object. The goal is to provide flexible schema design and rapid development by allowing complete entities to be stored and retrieved in a single record.

In a document database, each document typically represents one business object. In a loan approval system, for example, a single document may represent an entire loan application. Customer details, loan officer information, approval status, and repayment history can all be embedded within that same structure. Because the schema is flexible, new fields can be added without requiring costly table migrations or rigid schema alterations. This makes document databases particularly attractive in fast-moving development environments.

Key–Value databases represent the simplest form of non-relational data storage. They store data as a pair consisting of a unique key and its associated value. The key serves as an identifier, while the value contains the data itself. This model eliminates structural complexity and focuses entirely on fast retrieval by key.

The primary goal of key–value databases is to deliver ultra-fast lookups with minimal overhead. They are designed for workloads where the access pattern is simple and predictable, such as caching, session management, token storage, or high-volume read/write operations. Instead of supporting complex queries, these systems optimize for speed and scalability.

In a key–value database, each record is accessed directly through its key. The value associated with that key can be a simple string, a JSON object, or even a binary blob. There is no concept of joins, relational constraints, or query-based filtering beyond key lookup. This makes the model extremely efficient for operations such as “fetch loan details by LoanID.”