Knowledge Hub

Knowledge Graph Modelling is the practice of representing information as a network of interconnected entities and relationships, enriched with semantic meaning. Instead of viewing data as isolated records stored in tables, this approach treats knowledge as a web of connections. Entities become nodes in a graph, and relationships between them become edges. The structure itself reflects how concepts are linked in the real world.

The primary goal of Knowledge Graph Modelling is to create a flexible and interconnected view of knowledge. By explicitly representing relationships, it becomes easier to integrate information from multiple sources, discover hidden patterns, and enable reasoning across domains. This modelling approach is especially valuable in environments where connections matter as much as individual data points.

A knowledge graph models the world as nodes and edges. Nodes represent entities such as Customer, Loan, or Product. Edges represent relationships such as applies for, owns, guarantees, or reviews. Unlike traditional relational models, where relationships are often embedded in foreign keys, the connections in a knowledge graph are first-class elements. They are visible, traversable, and central to the model.

Metagraph Modelling is an advanced form of graph-based modelling in which nodes and relationships can themselves represent groups, sets, or even entire subgraphs. In other words, it allows relationships to carry their own structure and meaning. This makes it possible to represent complex, multi-level interactions that traditional graph models cannot fully capture.

The primary goal of Metagraph Modelling is to provide a more expressive framework for modelling context, grouping, and higher-order relationships. While a standard graph connects entities through simple relationships, a metagraph can describe relationships about relationships. This added expressiveness is particularly useful in domains where context, provenance, and interaction details are as important as the entities themselves.

To understand the difference, consider a simple graph example. In a loan system, we might represent the fact that a Customer applies for a Loan Application. In a traditional knowledge graph, this would appear as a node for the Customer, a node for the Loan Application, and an edge labeled appliesFor connecting them. This captures the relationship, but it does not fully describe the circumstances under which the application occurred.

Boyce–Codd Normal Form (BCNF) is a stricter refinement of Third Normal Form. While 3NF eliminates transitive dependencies, it still allows certain edge cases where a non-key attribute (or a non-superkey determinant) can functionally determine other attributes. BCNF addresses these edge cases by strengthening the dependency rule.

Formally, a table is in BCNF if, for every functional dependency X → Y, the determinant X is a superkey of the relation. In simpler terms, whenever one attribute (or group of attributes) determines another, that determining attribute must uniquely identify rows in the table. If it does not, the design violates BCNF.

To understand the difference from 3NF, consider a scenario in the loan approval domain. Suppose a table stores LoanID, ProductType, and InterestRate. Assume that business rules state that each ProductType has exactly one InterestRate. This creates the functional dependency:

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.

Event-Driven Data Modelling structures data around events, discrete occurrences that capture something that has happened, typically with a timestamp and contextual details. Instead of centering the model on static entities such as Customer or Loan, this approach treats events as the primary unit of design. Each event represents a fact in time.

The goal of event-driven modelling is to enable real-time processing, streaming architectures, and event sourcing patterns. By designing systems around events, organizations can react immediately to business activity while maintaining a complete, replayable history of what occurred.

In this model, the focus shifts from storing the current state of entities to recording event streams. Events are immutable and append-only. Once an event is written, it is never updated or deleted. Typical events in a loan approval domain might include LoanApplicationSubmitted, LoanApplicationApproved, or RepaymentMade. Each event contains identifying information, contextual data, and a timestamp.

Temporal Data Modelling is the practice of structuring data so that changes over time are explicitly captured and preserved. Instead of storing only the current state of information, temporal models record how data has evolved, enabling systems to answer questions about the past, the present, and even planned future states.

The primary goal of Temporal Data Modelling is to enable time-aware queries, regulatory compliance, auditing, and historical analysis. In many industries, especially banking, insurance, healthcare, and government, organizations must demonstrate not only what data looks like today, but what it looked like at a specific point in time.

Temporal modelling distinguishes between different types of time. Valid Time refers to when a fact is true in the real world. For example, an interest rate may be valid from January to March. Transaction Time refers to when the fact was recorded in the system. A correction entered in February about a January event has a different transaction time from its valid time. When both are captured together, the model is called bi-temporal.

3NF Data Modelling, championed by Bill Inmon, organizes enterprise data in a normalized structure, typically Third Normal Form (3NF), to build a centralized Enterprise Data Warehouse (EDW). The warehouse is subject-oriented, integrated, time-variant, and non-volatile, serving as the authoritative single source of truth for the organization.

The primary goal of a 3NF Data Warehouse is to create a consistent and governed enterprise data foundation. By eliminating redundancy and enforcing referential integrity, the EDW ensures that core entities such as Customer, Loan, Officer, and Product are defined once and integrated across all source systems. This approach prioritizes data quality, traceability, and long-term governance over direct query performance.

In this architecture, data from operational systems is extracted, cleansed, standardized, and loaded into normalized tables. For example, Customer data from a CRM system and Customer data from a Core Banking system are reconciled and integrated under a single enterprise identifier. Loan terms, balances, approval decisions, and officer assignments are stored in separate but related 3NF tables, each with clearly defined primary and foreign keys. Redundancy is minimized, and relationships are explicitly maintained.