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 table on the other side of the relationship will not be included on the form.

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

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. The Customers entity is on the many side of all the relationships shown in the diagram except for the relationship with the Orders entity, which you probably won't include on this Customers form anyway. 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. This means that only a single record will be included from any of the other tables, and so Customers can be treated as a simple entity.

This makes for a straightforward form layout. You don't need sub-forms or grid controls. Simply choose the control that best represents each field (we'll look at that issue 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, 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 deleted controls 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 is perceived as a single 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.

In 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 Product-Category, 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 termsstandard discount and payment terms, for exampleinto one group, and contact informationpurchasing officer, sales manager, and so oninto 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 usersthey 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 groupjust 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.

An alternative to subsidiary forms is a panel structure. It's then a fairly simple matter to provide the user with a mechanism for changing the display, either from a menu or (preferably) from a control on the main form. Figure 17-2 shows an example from Visual Studio that uses a TreeView to control the display.