A data driven application should reflect the process of the organization. Failing to do this is the degree to which the application is not valued in the process of accomplishing the organization’s mission. I find it appropriate then to consider the best outcome of a database design effort as resulting from a well-directed process.

So what is it about ‘process’? How do we think about it in terms of designing databases?

Process is how the customer gets their work done. Yet, in order for the database designer to model the data and relationships accurately, understanding the customer’s process remains key.

The particular end goals with the organization’s preferred practices determine what steps are needed to obtain an end result.

For the database designer, an understanding of the process enhances the ability to build a true to nature data repository.

What tools and techniques should the designer employ? I can offer some suggestions.

1. Awareness the database design should reflect the organization’s processes accurately. Reflecting on this point will give you the impetus to accomplish the rest.

2. Identifying interested parties. Interviewing them. Determine what their stake in the application is. Ensure their needs are met. 

Prioritize what they want and focus on what they need. Among these individuals, spare no effort to refine and clarify the process model.  When you have a consensus among stakeholders you almost guaranteed a successful outcome.

3. Document the business process. You should use whatever tools you have to document it. There are some interesting modelling tools like Microsoft Visio that can create some good flow charts. However, most organizations benefit the most from a plainly written, accurate, easy to understand document. Both approaches work well in tandem.

4. Reiterate through the prior 3 steps. As your learning and understanding of the process deepens update your documentation and seek out your team members for comment. Re-enlist your group of interested stakeholders for additional comments.

So, at this point no coding was done, no data definition language composed.

Part of the benefit of this process is you will find a treasure trove of succinct terms to describe your entities, attributes  and views. The closer you can name your database objects to terms familiar to your customers, the more likely you can stay on the same page. 

Recap: Prior to development efforts take the time to document and model these processes. They are the foundation of your database design. Consider the database application as the end result of a process.