Simple Entities

The easiest kind of entity to represent on a form is a simple entity that is represented by a single table in the database. If such an entity participates in any relationships, it is either on the many side or the other participant will not be included on the form.

For example, look at the E/R diagram in Figure 14-1, representing the Customers entity and its relationships.

Figure 14-1. This E/R diagram shows the entities that are related to Customers.

The Customers entity is on the many side of all the relationships shown in the diagram except for the relationship with the Orders entity. Somewhere in the application, you will probably have a form for maintaining customer information. (This is true even if all the data is initially captured as a by-product of other activities.) You probably won't include the Orders entity on this Customers form. Orders are logically distinct, and users would maintain them elsewhere in the system.

The Customers entity is therefore on the many side of all the entities that are included on the customer maintenance form and so can be treated as a simple entity. This makes for a straightforward form layout. You don't need subforms or grid controls. Simply choose the control that best represents each field (as discussed in the next chapter), slap it down on the form, and you're finished.

Well, you won't slap it down, you'll arrange all the controls neatly, with a seven-unit margin and four units between each control, and with the most important items placed in the upper left corner, as described in The Windows Interface Guidelines for Software Design, right? But you get the idea. There's nothing tricky required unless you run out of space on the form.

But you might very well run out of space. Technically, you can add 754 controls during the lifetime of a Microsoft Access form or report (with controls deleted later still counting toward the total) and have a maximum of 254 controls on a form in Microsoft Visual Basic (with control arrays counting as a single control).

Practically, you won't want users to have to deal with more than about 25 to 30 controls or control groups at one time. (Note that I said "controls or control groups"; a group box containing three or four radio buttons counts only as one logical control.) So what do you do if you have a simple entity with 75 attributes? You must show only part of the data at any one time.

The easiest way to structure a form that represents an entity with too many attributes to display comfortably is to break the fields down into groups or categories. I usually start by picking out the attributes that are used to firmly identify the entity. By this, I mean not just the candidate key attributes, but also whatever descriptive attributes users will need to be certain they're working with the correct instance.

For a Customers entity, for example, this group of identifying attributes probably includes the name and address details, and perhaps the Sales Representative attribute. For a Products entity, it might include the ProductCategory, Name, and Description attributes. This group of attributes should be on the top of the form and always visible.

The remaining attributes are then divided into groups that are related and need to be viewed together. For a Customers entity, you might combine those attributes that represent sales terms—standard discount and payment terms, for example—into one group, and contact information—purchasing officer, sales manager, and so on—into another. For a Products entity, you might combine technical specifications in one group and packaging-related attributes in another.

Having organized the attributes into groups, you have a couple of options. You could use a tab control on the main form with each group on a separate tab. This is the solution I use most often. Tab controls provide the most context for users—they know immediately that additional information is available and what that information is. If you have more than five or six groups, however, a tab control is unworkable.

In this case, you might have to move some or all of the groups to subsidiary forms. Subsidiary forms are also useful if the individual groups contain more attributes than you can comfortably fit on one tab. You could allow users to open the subsidiary forms from command buttons on the main form, in a structure similar to a switchboard. With too many command buttons, however, your form will once again become unworkable. A better solution in this case would be to have the subsidiary forms available from a menu.

Be careful to maintain context for users when using subsidiary forms. Users should always be sure to which instance of the entity the displayed details pertain. The easiest way to identify the entity is by having the subsidiary form repeat details from the main screen. It's not usually necessary to repeat the entire identifying group—just enough of the group to tie the subsidiary form to the master form.

Alternatively, you could make the subsidiary forms modal. This is one of the few places where modality can be justified in a system, since it helps maintain users' context. However, modal forms always constrain users, which is something you should avoid doing wherever possible. I use this technique only as a last resort, when there absolutely isn't enough real estate to include the few attributes required to maintain context.

Rather than using multiple subsidiary windows, you could theoretically display the secondary information in multiple subforms (Frame controls, in Visual Basic) on the main form. I don't like this approach very much, as it's difficult to maintain the users' context. You must provide some mechanism for determining which subform is displayed. If you use a menu for controlling the display, there's no indication on the form itself that other information is available. If you use some control on the form, perhaps a set of radio buttons, it might not be immediately clear to the users why their form display keeps changing. I think it's preferable to use a tab control, which is an established mechanism, rather than inventing your own approach.