DataChat's Traceability
One of DataChat’s key differentiators is traceability. Our platform automatically documents every step it takes to produce your analytics, in plain English. That way anyone can verify what DataChat did, regardless of their technical knowledge. We think this traceability is crucial to making data-driven decisions confidently. If you don’t know how the proverbial sausage was made, do you really want to bet millions of dollars on its quality?
There is a technical trick to how DataChat documents data workflows in a way that everyone can understand. Nerd alert: we do need to talk about Structured Query Language, better known as SQL, to explain. In the spirit of DataChat, we’ll do so with minimal jargon.
SQL and Nested Structures
SQL is a coding language that directs programs to find and summarize patterns in big, complex databases. That’s why data scientists know SQL and Python, and that is also why business users can’t do anything with typical data science tools (unless they have access to a no-code analytics platform, like DataChat).
Typically, data scientists write SQL in a nested structure. For laypeople who don’t code, imagine a nonfiction book in which every footnote has two footnotes, which each have two more footnotes, which also have footnotes, and so on. It would be very difficult to fact check anything because if a footnote deep in the nest is false or misleading, footnotes higher up could be wrong as a result. For the same reason, debugging deeply nested SQL queries is next to impossible. There are too many dependencies.
Our co-founders, Drs. Jignesh Patel and Rogers Jeffrey Leo John, decided to introduce a linear structure that represents deeply nested SQL queries in DataChat. That way, DataChat could show a data workflow the way an individual (or gen AI) would understand and break it down. Continuing with our book analogy, it’s like rewriting a paragraph to include references that were once in footnotes, so the reader doesn’t need to stray from the paragraph at all.
Instead of nesting SQL, DataChat starts the linear structure with the most deeply nested query and progresses to the shallowest. Thus, later queries can reference things introduced earlier in the code. For example, the query could produce report Report A and later reference it when data from Report A is to be combined with data in Report B.
If nested queries are impossible to debug let alone understand, why would programmers use them in the first place?
Programmers designed the nested structure for the sake of computers, not for the sake of human understanding. Database systems run more efficiently on nested queries, and efficiency lowers computing costs.
If we want SQL queries to make sense to anyone but the programmer, we can’t overload them with footnotes inside footnotes. We have to use longer, wordier paragraphs—that is, until we relay the query to the database system.
DataChat's Difference
When you use gen AI to ask DataChat a question, our platform translates it to DataChat English, which is linear. Under “Data Assistant” on the right side of the interface, you see steps taken in DataChat English. Behind the scenes, we convert that linear structure into a nested structure before sending it to the database system—so that the query runs efficiently in your database system and keeps the bill low. The user and the database get the workflow in the verbiage they understand best. Everyone is happy
A linear structure is the key to making SQL queries easy to understand and verify—and therefore the key to building confidence in analytics and the decisions they drive. We emptied the SQL query nest to make that all possible.