Sponsored By: Quest | From Back Office to Boardroom: The New Era of Data Modeling for AI

Summary

Data modeling has become a strategic discipline in the AI era because LLMs and AI agents that lack clear semantic definitions will infer meanings confidently but incorrectly, making well-defined ontologies essential to AI accuracy, compliance, and cost efficiency.
Quest's Erwin Data Modeler integrates natively inside the Databricks Data and AI platform, providing AI-assisted enrichment including automated domain definitions, relationship discovery, and enterprise conceptual model generation from cross-schema patterns.
Modern data modeling platforms can generate ETL pipelines and deployable data products directly from data models, transforming models from static documentation artifacts into living systems that actively drive business outcomes.

Chapters

FAQs

Why does data modeling matter more in the AI era?

AI agents and LLMs that cannot access clear semantic definitions will infer the meaning of data fields on their own, which leads to confidently wrong answers — a risk that was previously acceptable but is not in production AI systems. Well-structured data models provide the ontology, definitions, and relationships that AI needs to reason accurately and reduce hallucinations and compliance failures.

What are trust scores in the context of data modeling for AI?

Trust scores are metadata-driven quality indicators that reflect how well-defined and governed a dataset is for AI consumption. As described in this video, they help AI agents assess how much confidence to place in a given data source, preventing agents from acting on poorly governed or ambiguously defined data.

How does Erwin Data Modeler work inside Databricks?

Quest Erwin Data Modeler integrates directly inside the Databricks Data and AI platform, connecting to existing schemas and using AI-assisted enrichment to automatically generate domain definitions, data element descriptions, and relationships. It can also build enterprise conceptual models by discovering patterns across multiple schemas and generate ETL pipelines and data products from those models.

What is the token cost problem that LLMs face without defined data models?

When data is not properly defined and documented, LLMs must consume additional context tokens attempting to infer the meaning of fields and relationships from raw data alone. This video explains that forcing LLMs to infer what should already be explicitly defined wastes token budget and increases the likelihood of incorrect conclusions, making upfront semantic documentation a financially efficient investment.

Full transcript

[00:07] Uh my name is Yetkin and I work for Quest uh software. Uh you guys might know us as Irwin, the data modeling tool. So, it is Irwin. And today I'll talk about how the data
[00:19] modeling changed, uh what it was before and how it changed into. And at the end of my session, I'll give you guys a demo and not live demo, but screen by screen going through the slides, right?
[00:33] And you'll get a good idea about what we are talking about here. So, I love this quote, "If you cannot explain simply, you don't understand well enough." And it's so true in the
[00:46] age of era uh AI era. You if you cannot explain your data in simplest terms to your LLMs, to your AI agents, they will start inferring.
[00:59] An LLM is really good at inferring, but LLM is also really good at making outrageous mistakes, you know, being very confidently wrong. So, our job today is we will look at
[01:14] how I pictured here from back room to board room, how the data modeling is changed. I'll tell you how I um um how I got to know data modeling. I
[01:27] was working on Y2K projects. How many guys Do you guys know Y2K? And my job was going from company to company, finding those two-digit dates and converting them to four digits. As
[01:40] trivial as it sounds, it was a big thing back then. And in one of the companies we went, and it's it's not like Java code or anything. It was COBOL code, copybooks, IMS, DB2, you name it.
[01:53] One of the customers we went, they had data models. It was the first time I was seeing a data model and I'm like, "Wow, this is great. So, I can see where the dates are. You know, I can see from the physical model, I can map it to my
[02:06] logical model." It made my job so much easier and it was way back 1999 and I'm like, "Data models are great." And over the decades and if you look at Irwin, our our product, 36 years on the market,
[02:21] over 1,500 customers, and it's great. It brings you efficiency, it brings you documentation, versioning, control, everything you need. But, let's be honest.
[02:33] So, data modeling, a lot of people thinks is past the peak era. Like, you know, after the data warehouse era went down, data lakes, and everybody was like, "Don't worry about the structure.
[02:46] Uh we got this. We will infer." And yes, the data modeling went down popularity and it was seen as an extra step. Like, do we have to spend time for for it? And a lot of the times, the data
[02:59] models were out of sync and yeah, you need to catch up, but hey, I don't have time and over time the data models got forgotten. Up until AI came in and said, "Look, we
[03:11] need semantics. We need ontology. We need taxonomy. We need definitions. We need to understand the relationship between your data assets." And guess where is this information today?
[03:23] If you have data models, it's in the data models. So, in summary, I mean, if you guys leave this session with one thing, um
[03:37] we are not modeling schemas anymore. We are modeling information. And the things the uh the artifacts we are modeling are no longer I mean, yes, entities and attributes and primary keys, what have you, they're they're still there.
[03:50] But, now we are talking about the definition, the business rules, the um the ownership, the domains. There's additional information being packed into the data models to support what we call
[04:03] the semantic layer, which consists of, you know, taxonomies, ontologies, and other artifacts, which we will talk about. So, let's get in. I'll start with little bit boring
[04:15] because, I mean, let let's look at the current data management issues. Like we Like I said, we have thousands of customers worldwide. When we talk to them, these are the things they are saying telling us. Number one, trust.
[04:27] Yep, I have my data. Can I trust it? So, this we introduced this trust score concept. So, along with your model, along with your entities, there is a trust score, which is calculated based on the data quality, is
[04:40] it coming from the right source, etc., etc. So, now you need to start talking about trust score, and you need to feed this trust score to your AI agents and LLMs, so they can say, "All
[04:52] right, look, I'm answering your question based on this data set. Is a trusted data set, or it's not a trusted data set?" Speed and scale. Like I said, the very first thing the AI did was the data
[05:04] modeling teams, they become after the fact. They are like, "Just deliver the data. Don't worry about the metadata. Don't worry about the model. We'll We'll retrofit it. We'll come back to it later." And what happened is all these
[05:17] JSON files, whatever the shape of form um our rows and stuff, lying around in the organization, which no metadata attached to that, right? Speed and scale
[05:29] kind of turned the best practices upside down, and we have to retrofit and say, "All right, we need to make it as agile and as part of the process possible, so it's not forgotten." And, of course, the
[05:42] last part part is a lack of interoperability, which is, if your data models are here, and if your data is here in Databricks like you have to always go to the extra step. Okay, I'm looking at this
[05:55] database. I'm looking at this data. The model is here. I need to somehow associate it. So, we said, "Look, the data the metadata travels with the data. Wherever your data goes, metadata
[06:07] comes with it." And when I say metadata in this context, we are talking about the modeling concept. So, those are the three things we focus and those are the three things we are seeing as the challenges. And it opens more can of worms. Like just
[06:21] take this example. Provisioning data. Like business user comes in, "Hey, look, I I'll I want to optimize my supply chain. I want to optimize my customer churn. I need data."
[06:34] All right. Typically, I mean, if you are following the best practices, you go to your modeling team and say, "What data do we have? Do we need to create more attributes? Do we need to capture more data?" The modeling team says, "Check."
[06:46] You know, "Here is the model. Go." Metadata team, "All right. So, these are the definitions. These are the business rules." And then the quality team, "Check. Yeah, there's good quality data or bad quality data."
[06:58] And then how are we governing it? It goes through all these different teams and every team like of course, I mean, assuming this team can understand each other and you know, talk it's all siloed.
[07:11] So, our approach is you need to create workflows which cuts across all these teams and brings all these processes together under the same umbrella of data modeling, right? So,
[07:23] that's one of the focus areas. We talk a lot about and I I'm looking at the nodding heads in the audience. You guys know what semantics is. You know, you guys know how it is important, but
[07:36] it's sometimes hard to explain. Why? Because people who on the inference power of LLM. They say, "Look, if I go and ask, what's my profitable customer segment?" AI can
[07:50] somehow infer and figure it out and come back to me with some answers. Yes, it can. With maybe certainty, maybe less, maybe it might hallucinate, it may not hallucinate.
[08:02] But the token cost. So, that is becoming a thing because every time you force your LLM to infer, you are forcing its compute and tokens. And usually what you realize is just go
[08:16] stand behind the business user as he's is struggling with the prompts. It will take them four or five attempts at least to get to the right answer they are looking for. So, they will get some wrong answers,
[08:28] maybe some hallucinations, incomplete answers. They will rephrase the thing and then go deeper and go deeper. You are looking at for a question like this, uh approximately 5,000 to 15,000 uh
[08:40] tokens. And I This is not me speaking. This is This is from Gartner. And what if you have everything nicely defined? What if you said, "Look, if you are looking for this information, here
[08:52] is your data set. This is what you want to look at. Here is how we calculate profitability. Here is the metric for that. Here is the trust score." Once you provide this information to your LLM, you will
[09:04] realize how much it reduces the token cost. So, less attempts and less hallucinations. So, that's I mean, for those people who doesn't understand the semantics and you know, that they who are not data professionals, let's
[09:17] say you are talking to a CIO or CEO, just show this. I'm I'm going to save you money. So, let's come back. I'll show you guys some
[09:29] um slides. It's kind of a demo flow, but I didn't trust myself to do a live demo, so I'm doing screen by screen. So, I'll skip these slides and I'll I'll get to how is it today the data modeling works.
[09:43] So, this application lives inside of your data bricks. It's not a separate application. It is within your data bricks. So, the very first thing and there are different ways to approach it. This approach I'm taking here is all right,
[09:56] you have a database. Give me your database. So, I'm picking the database here. I'm importing from your Unity catalog or from your lake base. I'm picking the tables.
[10:08] And then if you guys are familiar by the way with this schema, it's one of the data brick samples. There is no relationship between the tables. This just raw data. The very first thing we do is we infer relationships.
[10:21] We infer domains. We say, "Okay, this couple of data sets belongs to this domain. This couple of data sets belongs to this domain." So, we start creating a physical model and on top a logical model. So, those
[10:34] are the artifacts we create on the side. Because let's be honest, if I go to a customer and say, "Hey, I'm going to give you a modeling tool and you can sit down and create models." They are like, "We don't have time for this."
[10:46] But if I create the models as a side product as I'm already doing the enrichment, at the end of it, yes, you will have data models. That's great. So, after this initial assessment, we create a
[10:58] heat map and say, "I mean, this is a small schema. I only have like 10 tables maybe." But imagine you are looking at a 50,000 table schema. What do you do? I mean, you cannot just sit down and say, "I'm going to generate definitions
[11:10] for every attribute coming in my way." You cannot do it. So, heat map is I can figure it out what data sets are most frequently used, what data sets are never used, and blah blah blah. So, I can focus you on what are the most
[11:25] you know, critical data sets. From there, we go to enrichment. So, again, you can say, "Yetkin, I have you know, what what's interesting about it? I can infer it with my LLM." Yes,
[11:37] you can. But, our 35 years of experience in this space, we know how to do it. So, we know how to use the industry standard models. We know how to look at your data and look at the metadata and the data
[11:51] itself and the lineage and everything else. And we recommend you look in your data model, we recommend you have these domains. So, domains means ownership. So, hence, you have the ownership
[12:03] defined. Entities, attributes, relationships, vocabulary types, classifications, blah blah. So, all of these things we recommend and enrich. And if you are, let's say, a bank, okay, there's a FIBO industry standard
[12:16] model. If you're an insurance company, there's a court. Don't you want to know how your data structure compares against those industry standards? Don't you want to know is my naming convention okay or is it how I described it? Does it make sense,
[12:29] you know? After you go through this step, and by the way, these are the you know, all the things we have in place. Um vocabularies, ISO standards, what have you. So, like, we put everything in
[12:42] place and we enrich it. And there's always human in the loop, right? So, whatever we try to enrich, there is always a human in the loop. Like, do you agree with this? Do you agree with this? Do you agree with this?
[12:54] And most of the time, okay, the person who is uh running this show may not be the business person. Like, he may not know, "Yeah, I don't know the definition of this." So, what you can do is you can say, "Look, I'll take this definition and run
[13:07] it by the workflow. I'll ask my business user, is this the accurate definition of profitability? Is this the accurate definition of ACV? Whatever is this." And get it confirmed. So, human in the loop is key, right?
[13:20] And then once you get past that, everything what we generated and created and enriched is inside this D DDL, it goes back into Databricks. So, nothing stays in our repository. Yes, we do I'll come back to
[13:34] that. Yes, we keep the information, but I'm not creating a semantic layer separately. I'm I'm writing it back into Databricks. Hence, the genie or whatever the AI agents you have, they immediately
[13:46] pick up this information. So, we follow the principle of metadata has to follow data. Like whatever this data goes, metadata has to be right there on on access, right? So, that's what we did.
[13:58] And then I can deploy it. So, there's a Git repository behind the scenes. So, I haven't seen a lot of best practice like change control management. We used to say it like put it in development first
[14:11] and promote it to UAT and or you go back and do a change. Okay, let's compare the versions. You know, what did I change? Like So, all of these things are built in so now we put it in development, so you can
[14:24] promote it to dev, staging, blah blah blah. And along the way you will see the version numbers growing. You would you can always compare them side by side and see what has changed, etc. And this last screen, so once you deploy all
[14:38] your models and when I describe this previous flow, I only talk about one schema, one model. But imagine you keep repeating this Snowflake, Databricks, Oracle.
[14:51] You start building behind the scenes an enterprise conceptual model. Because I keep reusing the same entities like you agreed that this is customer. There's a customer entity in this exercise. Okay,
[15:04] I go to the next database and I'm looking at it and I say this looks like the same entity. Do you agree? Yes. So, over time, so you what you did is you mapped your physical local models to an enterprise logical
[15:17] conceptual model. And again, typically some companies have it some companies try to build a Typically, it's a 9 months to a year project if you sit down in an enterprise and say, "I'm going to create an enterprise conception
[15:30] model." We are doing this behind the scenes. So, once you achieve this, once you have gone through this enrichment enrichment enrichment, and of course, after we enrich, we observe it like what's
[15:42] changing, and you know, we let you know that there are changes, etc. Now, you can come in and you can start talking about data products. I mean, I don't know if you guys talk about data products a lot, but if you
[15:55] happen to have certain data sets, certain data which is frequently used, what you want to do is you want to bundle them together nicely in a curated what we call a data product. And yes, Databricks is uh rolling out data
[16:07] products and marketplace along with Snowflake, so it's becoming an industry standard uh concept. So, now you The next thing you can do is, "Hey, look, I need to create a data product. Everybody needs customer 360.
[16:20] Everybody needs uh some reference data. Everybody needs, you know, some data. So, there's kind of overlapping use cases. So, what you want to do is The next thing what we I'm showing you is if you have all your models ready, you can come
[16:32] in and say, "Can you suggest what's the best data to use for this data product? This is my use case." And what it will do is it will leverage all those models what you have created across the board,
[16:45] and then come back and recommend to you and say, "This is the model I recommend for this data product. Do you agree with that?" And once you agree with that, it will recommend you the best data sets based
[16:57] on the trust score, domain match, attribute match, whatever. And so, it makes your lives easier because now that you are operating based on well-curated models, you can create your data model uh products, you can
[17:09] create your ETL jobs. The next thing we are doing is I can generate pipelines out of my data models, you know, like I You need to write code for it. So, that's the gist of it, guys. Um
[17:21] this is all what I wanted to show. So, I have 2 minutes remaining. I don't know if question and answer is a practical thing, but if you guys want to see the live demo VR Quest booth 105, just come
[17:33] and find us. Live demo. And look, I mean, if I'd like to leave you guys with this I'll I'll try to remember exactly what I was going to say, but people think in the era of AI, data
[17:46] modeling has become history. It is not. In the contrary, AI has changed data modeling. So, it's no longer a manual process. It is uh automated AI-driven process. And if
[18:01] you do it if you do a good job of following these workflows and processes, you will have always up-to-date models which you can feed your semantics, ontologies, and taxonomies, and everything else you need. So, thank you
[18:13] very much for listening. And if you guys have any questions, I'll be here, so you can find me. Thank you.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.