Expanding on Bridging Relational Databases and Vector Embeddings

Getting your Trinity Audio player ready...

The article discusses how traditional relational databases (RDBs) can be enhanced with vector embeddings to enable semantic processing, particularly for integration with large language models (LLMs). It emphasizes three core elements:

• Normalization: This RDB design principle organizes data into atomic, non-redundant tables (e.g., up to 4th Normal Form) to eliminate ambiguities and dependencies. It creates a “flat” structure where meaning is deferred to queries, reducing anomalies but requiring inference to reconstruct relationships.
• SQL Inference: SQL serves as the inferential layer, dynamically rebuilding semantics through operations like joins (reconstructing relationships), selections (filtering conditions), projections (deriving views), and matches (pattern enforcement). Historical SQL queries capture domain knowledge, such as business heuristics or patterns (e.g., frequent joins implying correlations).
• TVRE Training: Token-Vector Relational Embedding (TVRE) translates normalized RDB data into vector spaces. Rows are tokenized (e.g., via primary keys), and attributes are embedded as vectors that capture semantic similarities (e.g., “Engineering” and “IT” vectors being proximate). TVRE is trainable using historical SQL as data, optimizing embeddings to learn inferential patterns like query heuristics.

This bridging allows RDBs’ structured rigor to meet vector embeddings’ semantic flexibility: normalization purges ambiguity from storage, SQL reintroduces inference dynamically, and TVRE embeds it all into a trainable vector form for AI-driven tasks like semantic search or predictive analytics.

To expand on this, I’ve created a simulated Python environment (using an in-memory SQLite database, NumPy for vector operations, and SciPy for similarity calculations) to test specific use cases. This demonstrates how normalization, SQL inference, and TVRE-like embeddings work in practice. The setup uses a small normalized schema with three tables: Employees (ID, Name, Role, Salary), Departments (ID, Name), and Assignments (ID, EmployeeID, DepartmentID). Dummy data is inserted, and simple 3D vectors simulate embeddings for roles and departments to mimic semantic proximity (e.g., tech roles like “Engineer” and “Developer” have close vectors).

Test Environment Setup

• Normalization in Action: The schema separates employee details from assignments to avoid redundancy (e.g., no repeating department names per employee row).
• SQL Inference: A join query reconstructs the full view, inferring relationships.
• TVRE Simulation: Employee embeddings are composite vectors averaging role, department, and normalized salary vectors. This preserves relational structure while adding semantic depth (e.g., cosine similarity for queries).

Here are the results from running the tests:

Use Case 1: Semantic Search (Vector-Based Similarity)

In a TVRE setup, embeddings enable queries like “find similar employees” without explicit SQL rules—leveraging vector proximity instead. We compute similarities to Alice (ID 1, an Engineer in Engineering with high salary).

Generated Embeddings (3D vectors for each employee):

• Employee 1 (Alice): [0.9333, 0.4000, 0.3333]
• Employee 2 (Bob): [0.8500, 0.4500, 0.3833]
• Employee 3 (Charlie): [0.3333, 0.8667, 0.2667]
• Employee 4 (David): [0.4167, 0.8167, 0.3500]
• Employee 5 (Eve): [0.8000, 0.4667, 0.4000]

Similarities to Alice (using cosine similarity; higher = more similar):

• Employee 2 (Bob, Developer in IT): 0.9951
  (High similarity due to close tech roles/departments and similar salaries.)
• Employee 5 (Eve, IT Specialist in IT): 0.9893
  (Similar tech alignment.)
• Employee 4 (David, Sales Rep in Sales): 0.7935
  (Moderate; sales roles are semantically distant.)
• Employee 3 (Charlie, Marketer in Marketing): 0.7232
  (Low; non-tech role/department.)

This shows how TVRE bridges to vectors: A traditional SQL query might require explicit filters (e.g., WHERE Role LIKE '%tech%'), but embeddings allow fuzzy, semantic matching. In a real system, this could scale to vector DBs like Pinecone for faster searches on large datasets.

Use Case 2: SQL Inference for Relationship Reconstruction

To illustrate SQL as the inferential engine, a join query rebuilds the denormalized view from the normalized tables:

Joined Data (inferred via SQL):

Name	DepartmentName	Role	Salary
Alice	Engineering	Engineer	100000.0
Bob	IT	Developer	95000.0
Charlie	Marketing	Marketer	80000.0
David	Sales	Sales Rep	85000.0
Eve	IT	IT Specialist	90000.0

This query infers assignments, embodying domain logic (e.g., employee-department links). In TVRE training, such queries could be embedded as vectors to fine-tune the model, teaching it to prioritize tech-related proximities.

Additional Potential Use Cases and Extensions

• Anomaly Detection: Embed a new “anomalous” employee (e.g., a marketer with an engineer-like salary) and flag if its vector diverges significantly from cluster norms (e.g., average similarity < 0.5). This leverages TVRE’s learned inferences from historical SQL patterns.
• Auto-Query Generation: An LLM could use trained embeddings to infer SQL from natural language (e.g., “Show tech employees” → generate a join with role filters). While not fully simulated here, the embeddings provide the semantic foundation.
• Scalability Testing: On larger datasets, vector searches outperform SQL joins for similarity queries, as noted in the article. With tools like FAISS (not used here but integrable in full setups), this could handle millions of rows.
• Training Simulation: In a real TVRE system, historical SQL (e.g., frequent tech joins) would optimize embeddings via loss functions like cross-entropy, making vectors “learn” heuristics. Here, our dummy vectors mimic post-training behavior.