Skip to content

Business rules

There are several identifiable points during the development of a database structure where it is important to talk directly to the end users. One of those times it right at the beginning when you are finding out exactly what the application will need to do, and therefore what data it will have to store.

At that time, you may already be picturing the data structure as an ER diagram; however, the end users will have great difficulty in understanding that representation. An alternative that is much more user-friendly is to talk about business rules. These are simple statements that capture either structural requirements or constraints on the data.

Structural rules

These rules describe the cardinality of relationships among entities in the system. Using the example of the music database again, the structural business rules would be as follows.

  • One artist may create many songs, and one song must be created by one or more artists
  • One artist may perform on many recordings, and one recording must have one or more performers
  • One album is made up of many track recordings, and one recording may be used on many albums
  • One publisher publishes many albums, and one album is published by one publisher

Music db

Notice that the business rules specify the relationship from both ends. It is important to elicit this information from the users at the beginning of the design process. Once you have identified a relationship between two entities during a user interview, it is always a good idea to ask the questions about cardinality explicitly. For example, if the user tells you that an artist may create many songs, that suggests a 1: relationship. When you ask the question "How many artists create one song?"*, the user will probably tell you that the answer is one or many. This shows that the relationship is actually *:*.

The business rules shown above do not mention the link tables that are shown in the ER diagram. The reason for this is that the entities CREATOR and PERFORMANCE will not have much meaning for the users you are talking to. The entity TRACK will be confusing because the user will probably want to use that term for the entity labelled RECORDING. Part of your job as designer is to include the appropriate amount of detail in your communications. Remember that the users are operating at the external level in the ANSI-SPARC model. Their understanding of the structures will be different from the one you are most interested in at the conceptual level. Expressing the structure as a set of business rules helps communication across the external/conceptual boundary.

Data rules

Users can also give you the information you need to define constraints on the data. For most of the tables in the music database, there are no problems, but the role column in the CREATOR table needs some clarification. The need for this column would arise out of asking the user how an artist can contribute to the creation of a song. The answer might be that the artist can be the lyricist or the composer, or both. Thus the only permissible values for the role column are lyricist and composer. There is no standard form for these rules, but you could write it like this:

  • An artist can contribute to the creation of a song as lyricist or composer