Maintain Data Integrity

[WHIMSICAL MUSIC] So I guess the first question I have is around data integrity and validation rules, techniques, et cetera. And I get the intent-- you know, ensuring data remains accurate and consistent across this life cycle, et cetera. Well, I would think if you're migrating databases from one platform to another or within the platform, you absolutely want to maintain the consistency. So I think the first thing you need to know is, are you fully aware of the validations and integrity checks that are in place? So that exists in a number of different places-- potentially, some of it may exist in the database. Some of it may exist in the application code. One place where it should-- and if you're doing things right in your organization, one place where I guarantee you that it always exists-- would be in a data model for that database, right? Because The whole data modeling process is to really tease out of the business user, what are the business rules behind how data is entered, stored, delivered, managed, things like that? And you want to be able to understand that both from a business perspective as well as a technical perspective, meaning, how are we implementing that in our database of choice? And that implementation-- there's the crux of it-- may be different from one platform to another. So this is a real key area where I think having a strong data modeling practice will put you ahead of the game. Now, if you've had a data modeling practice in place, I would assume that you have been documenting this in the data model. Right? That logical model that shows the business needs in terms of validating data and making sure that only appropriate data can be entered into a specific database. And then within that data model, you would actually have that documented. Let's say right now, that database currently sits in Oracle-- how that's implemented in Oracle, whether they have a mechanism for valid values, those types of things, or stored procedures that they go through and do all of that. So the real key here is to be able to figure out what you have. And if you don't have a data modeling practice in place and you haven't done that, work up front, the data modeling tool can still really help you, because now, you can at least reverse-engineer what exists in your existing instance and pull that logic out of what's been implemented. Then, I would go back, use that to have a conversation with my partners in the business to make sure that this is still appropriate moving forward in our [? to-be ?] world that we're migrating to, and then be able to leverage the data modeling tool to basically migrate those validation rules to the new platform, because the way it's implemented in Oracle will be very different from how it's implemented in a Postgres or a SQL Server. So being able to have that, capture that, go through the analysis, make sure that it's correct as it stands or needs to be modified in x, y, z different way, and then being able to model in that environment without actually having to go out and build a database in this new platform and start entering it there, and then leverage the automation that exists in the data modeling tool to be able to forward-engineer those validation rules with integrity, and then use the complete-compare capability to make sure that they've maintained that integrity from where they are today and where you want them to be at the end of this migration. Danny, I should have called you yesterday. I wasted so many hours looking that up. I completely get that now. Totally. Appreciate it. Like, it really is-- it gets down to clean data, you know?