An investment research platform is building a knowledge graph that links entities across six node types: companies, executives, suppliers, customers, patents, and regulatory filings. A semiconductor analyst asks the platform to identify 'all companies with greater than 30% revenue exposure to a Tier-1 foundry if that foundry experiences a production halt lasting 90 days, including second-order effects through contract manufacturers that source from that foundry.' Why does a knowledge graph handle this query more naturally than a traditional normalized relational database schema with the same underlying data?
Select an answer to reveal the explanation.
Short Explanation and Infographic
The query is asking 'follow this chain of relationships two hops deep and tell me who gets hurt.' In a relational database, you'd need to write a JOIN for each hop — company to supplier, supplier to its customers, customers to their revenue exposure — and it gets expensive fast. A graph database is literally built around 'start at this node, walk the edges, find what you reach,' which is exactly what second-order contagion analysis requires. It's the difference between following a thread and untangling a spreadsheet.
Full explanation below image
![A 2048x1536 infographic on deep navy with gold and electric blue. Title: 'Knowledge Graph Multi-Hop Query — Supply Chain Contagion Analysis' in bold gold. Center: a force-directed graph visualization. Central node: red hexagon labeled 'Tier-1 Foundry (Production Halt)'. First ring (hop 1): 4 blue circle nodes labeled 'Contract Manufacturer A-D' connected by edges labeled 'SUPPLIESTO'. Second ring (hop 2): 8 gold diamond nodes labeled 'Fabless Co. 1-8' connected from contract manufacturers with edges labeled 'SOURCESFROM'. Third ring (hop 3): selected nodes highlighted in red with label '>30% revenue dependency'. Left sidebar: Cypher query snippet in monospace — MATCH (f)-[:SUPPLIESTO1..3]->(c:Company) WHERE c.revenuedependency > 0.30 RETURN c. Right sidebar: comparison — 'Graph: O(depth) traversal' vs. 'SQL: recursive JOIN, O(n³) at 3 hops'. Bottom: use case icons — corporate control maps, ESG supply chains, patent landscape. Professional financial graph DB aesthetic.](/media/icfdt/cfia/CFIA-q017-infographic.webp)
Full Explanation
The query posed — find all companies with significant revenue exposure to a specific supplier through intermediate contract manufacturers — is a variable-depth graph traversal problem. It requires following relationship edges across heterogeneous entity types (foundry → contract manufacturer → fabless semiconductor company → end customer) while accumulating and filtering on edge properties (revenue share, contract volume) at each hop.
In a knowledge graph (property graph or RDF), this query is expressed naturally using Cypher (Neo4j) or SPARQL. A Cypher query might read: MATCH (f:Foundry {name: 'X'})-[:SUPPLIES_TO1..3]->(c:Company) WHERE c.revenue_dependency > 0.30 RETURN c. The 1..3 notation instructs the graph engine to follow the SUPPLIES_TO relationship up to three hops, evaluating the condition at each hop. This leverages index-free adjacency — the graph database stores direct physical pointers from each node to its neighbors, enabling O(depth) traversal rather than O(n log n) join operations.
In a normalized relational schema, the equivalent query requires constructing recursive CTEs (Common Table Expressions) or a sequence of self-joins on the relationships table: one JOIN to find direct Tier-1 suppliers, another JOIN to find who sources from those suppliers (Tier-2), and a third to complete the chain. Each additional hop multiplies the JOIN complexity. At three or more hops, query planners frequently resort to full table scans, and execution times degrade dramatically as the supply chain data grows — making real-time contagion analysis infeasible.
Why the distractors fail: (A) JSON-LD is a serialization format for linked data, not a storage advantage — graph databases store property graphs or triple stores internally, not raw JSON. The flexibility advantage is in the schema model, not the data format. (C) Full-text search on unstructured documents is a separate capability (typically layered via Elasticsearch or a search index) and is not an inherent advantage of graph databases over relational ones — both require external search integration. (D) Compression efficiency is not a structural advantage of graph databases; columnar relational databases (e.g., ClickHouse, Redshift) typically achieve superior compression on large datasets compared to graph databases.
Knowledge graphs in investment research are also used for corporate control mapping, beneficial ownership disclosure analysis, ESG supply chain traceability, and patent landscape analysis — all of which share the multi-hop relationship traversal characteristic.