Constraints

In a data model, the values that attributes can take are constrained at a basic level by the data type of the attribute. For example, if the attribute “number” is defined as an integer, it may only hold numeric integer values, such as the number 10; it would not be allowed to hold string values, even the string “ten.”

It is often the case that a data model must enforce constraints on data values even if they are technically legal from the standpoint of the domain of an attribute. For example, even if an attribute is defined as an integer, it may be necessary to restrict which integers it will be allowed to hold. Ideally, a data management system allows constraints to be defined within data models that enforce such restrictions.

A common situation where constraints on data values are necessary is in representing entities that have a fixed set of values. For example, an application that asks users to input a postal address can and should enforce the correctness of certain values that are a part of an address. Postal codes, provinces or states, and even city names in a given country exist within fixed sets. Thus, even if the postal code and province attributes are of a string data type, the particular string values they are allowed to hold can be restricted to the values contained in the official lists of postal codes and province names, respectively.

The principle of using constraints to enforce attribute data values can be applied to any type of data, even those of mixed types. Database management systems typically provide mechanisms that allow designers to specify constraints at the same time they specify a schema.

Another category of constraints within a data model involve the cardinality of relationships between entities. Thus, they are called cardinality constraints. These are used to restrict the types of cardinalities that exist between entities, as discussed in the section on relationships. Corresponding to the discussion in that section, the cardinality of relationships between two types of entities can be constrained at a basic level to: one-to-one, one-to-many, or many-to-many. A one-to-one constraint between entity type A and entity type B in a schema says that a given entity of type A may be associated with only one other entity of type B. One-to-many and many-to-many are used similarly.

A cardinality constraint may go further, however. It is sometimes necessary to specify a minimum cardinality in a given relationship. For example, given a one-to-one relationship between entity type A and entity type B, the following specific types of cardinality constraints might also be added:

c. 1..1 := one entity type A must be associated with one entity of type B;
d. 0..1 := one entity type A may be associated with zero or on entity of type B.

Given a one-to-many relationship between entity type A and entity type B, the following specific types of cardinality constraints might also be added:

1..m:= one entity type A must be associated with one or more entities of type B;

a. 0..m := one entity type A may be associated with zero or more entities of type B;
b. 0..x := one entity type A may be associated with zero or up to x entities of type B; and
c. 1..x := one entity type A must be associated with at least one or up to x entities of type B.

Given a many-to-many relationship between entity type A and entity type B, the following specific types of cardinality constraints might also be added:

0..m:= each entity may be associated with 0 or more entities of the other type; and

a. n..m := each entity must be associated with 1 or more entities of the other type.

Another perspective on cardinality constraints is as dependencies. A dependency defines a relationship that is required between entities.

EX. TR-7:

In our train_equipmentschema, some cardinality constraints are required. For example, that train_equipmentmust include at least one engine in its set of engines. This may seem obvious to us, but in terms of data management, we must try to architect our systems to ensure that erroneous data are not entered. The use of cardinality constraints helps in this cause. In defining the train_equipmentschema then, we can specify a minimum number of engines.

In reality in this particular application domain – the management of trains – we may need to derive the minimum cardinality of the engines set based on other factors.

Question to the reader:

Without necessarily being an expert on trains, can you make educated guesses about the variables that should be considered in determining the cardinality of the engines set?