What business folks have to understand about database design

A business team is asking me to explain database design. I'm thinking of:

1. what a RDBMS is.
2. what a table is, what constraints are and why we need them.
3. what a transaction is and what ACID properties are.
4. things to do developing a database:
   • a. Decide how much detail you need and how much you may in need future.
   • b. Identify fields with unique values.
   • c. Select the appropriate data types for your fields.
   • d. Normalize and design indexes.

Most of the time this team has their data coming in from flat files which we need to load into the DB and format. We couldn't set up a stable process to do the import.

What should I explain?

You haven't said what your audience expects to take away from your presentation. So I'll have to guess, based on my dealings with business people in the past. Your mileage may vary.

Business people typically don't care about the skills and knowledge you put into doing a good job with database design, even when they say they do. They want to understand database design in terms of costs and benefits. That is how business people think.

So if you must cover some technical topic like indexing, do so from a cost benefit point of view. There is a cost to adding an index to a table, and there is a benefit to adding an index to a table. Figuring out in advance whether the benefit is worth the cost is the really tricky part, and they will be interested in this.

On a larger scale, data is a business asset. There is a cost to managing that asset well, and there is a benefit to managing that asset well. If you can connect your talk to these two concepts, they will be interested.

If they are really good business people, they will have a good understanding of the subject matter that the database covers, provided it's a part of the enterprise data that affects their business. If you have a good ER model of the data in the database, this model will connect every value in every table to an attribute, and every attribute will describe some aspect of the subject matter. This is a very different use of an ER model than just using it as a preliminary to creating a relational model.

Technical people tend to think of ER modeling as "relational modeling light". It's really much deeper than that. It's an analytical handle on the question "what does the data really mean?" And this is a handle on "what is the data really worth?". And this is where the technical world meets the business world.