Interview end Users

Once the ER diagram is complete, the next step is to review it and any related documentation with specific end users to determine if the model is an adequate container for the data to be stored or if there are modifications that need to be made prior you transform the ERD diagrams into physical tables. Some specific areas to review include:

1. Business objects: Have all business objects and their characteristics been converted into entities and attributes?
2. Business rules: Have constraints on entities, attributes, and relationships derived from business rules (and common-sense rules) been properly identified and, where appropriate, incorporated into the model?
3. Queries and user views: Do end users agree that the model, as constructed, will result in a database that returns useful information to them quickly and efficiently?

If there are modifications to be made to the conceptual model and, in particular, to any relationship constraints placed on that model, these should be addressed before the next major step in the logical design stage is taken: data normalization (discussed in the next course in this series).

You cannot create a database model without the involvement of the people who will use that database model. It does not matter whether they are

1. technical people such as computer programmers or
2. end-users such as executives wanting forecast plans from a data warehouse.

There is only one important thing to remember about company employees and that is they know their business, how it operates, and how it works. Many database designers with extensive experience can often go into a new company and draw on past experiences that they gained in similar organizations. This is nearly always the case for experienced designers, but there are often exceptional situations in any company where even experienced designers cannot prepare for.
You can find out what is needed by talking to the people who will use the database model you are about to design for them. Your first task is to talk with and listen to company personnel such as developers and end-users. By talking and listening, you can discover how to design a better database model for them.

The users of the database model can often tell you the most about what should be in the model and how pieces within that model should relate to each other. Remember, that those people are usually non-technical and know nothing about database model design. The database designer applies modeling techniques to the thoughts and statements of the users. Both users and designers have equal weight to add to this process.
In fact, even though I emphasize the point of listening (by always assuming the customer is right), essentially the users are people who the designer gathers information from as to how the model should be designed and what should be in it. Ultimately, the designer is 97 percent responsible for figuring out the design and building the database model. The end-users can give you many pointers, and from their perspective, it all makes sense. From your perspective, information from end-users can often feel like a stream of incoherent facts. It is your job to clarify everything and to make complete sense of it. Remember, design is largely a planning process, and thinking about various options is a big part of that planning process.

The next step is to organize the required elemenets into sequences of logical and mathematical steps. Those components are placed into a logically structured database model. It is the database designer's responsibility to figure out the logical organization of the tables within the DBMS. The end-users are likely to think of the rules in terms of priorities and how they react to different situations.
Question:

1. How important is each task on their desk?
2. How is it related to the running of their business?

There also may be indirect effects in play such as a specific employee thinks something is important because he or she has been managed and motivated in a specific direction. Of course, it is likely that the manager or even the manager's manager is aware of the importance of a specific task. A lower-level employee may not be aware of why something is significant or not and everything is subjective at this stage. The database designer must be objective, clinical, analytical, and precise.

Designing a database model is an abstraction of specifics. Abstraction is a logical process designed to make handling of situations easier. Abstraction attempts to compartmentalize different activities, ultimately processing at the compartment level, and not the activity level. An event a business environment could be two distinctly different things could be identical when properly abstracted.
For example, a car salesman may picture selling a Ford and selling a Chevy as two different processes. Mustangs and Camaros can be in different lots and could have different service agreements. There could be many other differences as well. From the perspective of the database modeler, both Ford and Chevy are automobiles are both either automatic transmissions or stick-shift.

Before moving on to the next lesson, click the Exercise link one last time to try your hand at modifying the Stories on CD ER diagram to accommodate a revised business rule.
Accommodating Client - Exercise
The next lesson describes the process of “verbalizing” the ER diagram.