Summary

   

---

Defining Field Specifications for Each Field in the Database

Now that you have all the necessary fields assigned to each table and you understand the various elements within a field specification, you can begin the process of defining a field specification for each field in the database. It will take you a considerable amount of time to complete this process, but remember that you're working diligently to establish field-level integrity by ensuring that the data is consistent, valid, and as free from errors as possible. All your hard work will pay great dividends because the information you retrieve from the database will always be timely and accurate, and you will have a reliable set of structural blueprints you can use when you implement the database in an RDBMS program.

You can ensure that the specifications are as complete and accurate as possible by working with both users and management to define them. They can provide insights into the data and can be of special assistance in refining the specification's logical elements. You don't have to speak with everyone in the organization, but you do want to assemble and meet with a representative number of people who are very familiar with the data and how it is used. Schedule as many meetings as are necessary (or possible) to complete the interview process, and take the time you need to be as thorough as you can. Above all, do not rush through this phase! Doing so just diminishes the benefits of your overall efforts and increases your chances of making unnecessary mistakes.

The best strategy for this task is to define as many of the specifications as you can (as completely as possible) and then work with the participants to complete the rest. As you work with a field's specifications, use your best judgment to define the settings for each element. Don't worry if your settings seem slightly incorrect or if you have difficulty providing settings for some of the elementsyou're going to review them with the participants anyway. After you've defined specifications for all of the fields that are familiar to you, begin meeting with the participants to work on specifications for the remaining fields.

Your first order of business during the initial meeting is to explain the various elements within a field specification and make sure that everyone understands them as much as possible. Providing the participants with a brief and succinct education on the specification's elements gives them the knowledge they need to help you define a specification properly. (In subsequent meetings, just review the elements to make certain that everyone remembers what they represent.)

Next, review all of the specifications you've defined and ask the participants whether the settings for the elements are suitable and correct. In some cases, the participants will reveal new information about a field that will affect that field's specification. For example, a participant may remember (prompted by some topic in the discussion) that there is a specific set of values that has always been used for a particular field; therefore, you set the field's Range of Values element to reflect this new information. Make sure that you examine each part of the specification and then move on to the next specification when the participants have no further suggestions for refinement. Repeat this process for each specification.

Now, work with the participants on the specifications you were unable to define or complete. Try to work with the people who are most familiar with the fields under discussion because they are likely to know what settings should be used for the Logical Elements category. Identify the appropriate element settings for each field and mark them on the Field Specifications sheet. After you've defined specifications for every field in the database, the entire process is complete.

The design of the new database is now close to completion. In the next chapter, you'll learn how to establish relationships between the tables in the database. Relationships are important because they allow a view to draw data from multiple tables simultaneously .

CASE STUDY

Now that you have all the appropriate fields assigned to the tables in the Mike's Bikes database, it's time to define field specifications for each field. Before you meet with Mike and his staff, you define as many field specifications as you can. None of the tables are unusual in any way, and the fields are pretty straightforward, so you have little difficulty in defining the specifications. Figure 9.11 shows the specification for the P RODUCT D ESCRIPTION field in the PRODUCTS table.

Figure 9.11. Field specification for the P RODUCT D ESCRIPTION field.

Now you meet with Mike and his staff to discuss the field specifications you've defined. No one seems to have problems with any of the specifications; everyone confirms that all of the element settings seem suitable and correct. You do have a question, however, regarding the C ATEGORY field in the PRODUCTS table: You want to know the appropriate setting for the Range of Values element. The response to your question is mixedno one seems to know the complete list of categories that are valid for the field, so you decide to specify a general range of values for now. Figure 9.12 shows the revised logical elements for the C ATEGORY field.

Figure 9.12. The logical elements for the Category field in the PRODUCTS table.

You'll revisit this field (and its elements) again when you establish business rules for the database. With this problem solved , your meetingas well as the process of establishing field specificationsis complete.

---

Top