This reminds me of a time I was at a company using a BI tool for dashboarding. The numbers weren't making much sense to me, so I looked at the query building tool. I couldn't tell for the life of me if a part of the query was doing an inner join or left join. The business analyst who built the dashboard had no idea either.
It turned out that it was doing a left join when the intent was an inner join, and the data being shown was an order of magnitude higher than it should have been. This is when I lost all faith in these kinds of abstraction layers on top of SQL targeting people who don't actually know SQL.
As someone who leads a Data Engineering and Data Science team and has for 15+ years, this is exactly the problem. Too many folks with access to data who do not understand the data, its relationships, and what the outputs their individual efforts create mean.
Decentralized/embedded Engineers/Scientists; self-service dashboards; low-code BI/data tooling; and, now, LLM-driven text to SQL/viz lipstick on a pig have been floated as some of the solves to the problems seen in the analytics space over the 25 years I've worked in the space. Unfortunately, to date, nothing has actually solved the root issue: lack of data understanding and, its end result, trust in the deliverables.
But, to your specific point, SQL isn't the solve here, either. Too many folks know enough SQL to pull data and use it as they see fit, but too few folks understand the data, its structure/schemas, and valid use of those data. THAT requires time, energy, knowledge, and experience in the space. NO TOOLING, other than experience, solves for this--today (note: will LLMs get to a place where they can? Maybe; but, let's be honest--probably not).
Dashboards are great at giving quick hit information of KPIs and the ability to drill down into them; but, the most important thing to solve are always:
1. Data Management practices
2. Understanding of data, its relationships, and proper use of those data/metrics in deriving insight to drive the business forward.
I am excited to see what the future holds, but my grey beard doesn't allow me to ever, Ever, EVER trust any next-gen tooling being it hasn't held true to date.
I'm a SRE and have used my fair share of BI tooling. I have a rule that if the dashboard has a sufficient number of consumers/users then it should actually be in an internal application. BI tools are for me to play and prototype with data, they don't produce products in themselves. Much of that has to do with what you mentioned here, the other half is that I will absolutely never devote another part of my life to debugging some dashboard query I made six months ago.
I am data science manager at my own startup. Everywhere I go, I tell people proudly, I am ardently and stridently against data democratization.
I honestly will prefer people make decisions with their guts than with ill-understood data. Instead what I get is people who don't understand the data, its context, its meanings (and what it doesn't mean) trying to lead people down the wrong road while using the data as crutch. It is so frustrating to me.
Intuition of folks with good understanding of the business, especially when their salaries depend on it is often a much much better compass than some rubbish someone is claiming data is saying.
Another term I hate with a passion "data driven". No! data drives nothing. "Data informed" is where its at. You take the data, our best understanding, mix it our understanding of things the data doesn't cover, and use to that inform the best decisions we can make.
And then when you fixed it, did everyone freak out that it was lower?
I've been at big companies where you realize a subtle bug/design causes higher revenue and nobody wants to touch it and be responsible for loss of revenue. Things like the free plan button being just below the fold on average resolutions, calculating state incorrectly that causes discounts to not be applied, someone forgetting to add a "false" that causes people to be prompted to signup when signup isn't technically needed, etc.
I wonder if you felt the same way; like people would blame you for there being lower numbers?
This is a problem that's common to all "no code" solutions. The heavy lifting involved in implementing complex logic flows isn't typing code into an IDE, it's knowing how to model the problem and design an effective algorithm to solve it.
These solutions are targeted at non-technical users with the promise of not having to write code, but those users often get lost or produce erroneous results because they still don't understand the more complicated parts of engineering their solution.
Every time I see an attempt to scale up complex business processes with "no code" tools, it inevitably winds up hitting a wall after a lot of churn, then ultimately having to be handed off to actual engineers anyway, who are in turn hamstrung by the lack of any of the affordances applicable to actually writing code in a real programming language. It's almost impossible to work off a shared repo, have proper version control, do code review, automate testing, or do any kind of CI/CD when you are stuck working with visual flow builder tools.
Do what everyone else does - synthesize the abstract relations into views and limit the self-serve BI dashboard to the views that do make sense.
Users default to only seeing it from their perspective, so have alternate methods to let them see it how they think it works.
I'm aware of a product that uses time-based attendance for education, because not every day, every school, or every campus uses the same timetable quilt and often you have to be flexible (school sports carnivals, relief swaps, joint class activities, or 14-day rolling timetables for example). Doesn't mean there isn't a view that synthesizes the quilt into class-based attendance, or even just AM/PM for those users that think that way.
It turned out that it was doing a left join when the intent was an inner join, and the data being shown was an order of magnitude higher than it should have been. This is when I lost all faith in these kinds of abstraction layers on top of SQL targeting people who don't actually know SQL.