The Assertions Approach

Printed with permission from Morgan Kaufmann, a division of Elsevier. Copyright 2005. For more information on this book and other similiar titles, please visit http://www.books.elsevier.com/computing.

Please recognize that this Special Feature is an excerpt from the book identified above. When book excerpts are published, you will find that they often refer to
other sections and chapters of the book and may make the reading somewhat difficult to follow. To learn more about the authors’ topics, please consider purchasing the book.

 

 

10.18 The Assertions Approach

In this section, we look at a rigorous technique for reviewing the detail of data models by presenting them as a list of plain language assertions. In Section 3.5, we saw that if we named a
relationship according to some simple rules, we could automatically generate a plain language statement that fully described the relationship, including its cardinality and optionality, and,
indeed, some CASE products provide this facility.

The technique described here extends the idea to cover the entire data model diagram. It relies on sticking to some fairly simple naming conventions, consistent with those we have used throughout
this book. Its great strength is that it presents the entire model diagram in a non-diagrammatic linear form, which does not require any special knowledge to navigate or interpret. We have settled,
after some experimentation, on a single numbered list of assertions with a check box against each in which reviewers can indicate that they agree with, disagree with, or do not understand the
assertion.

The assertions cover the following metadata:

1. Entity classes, each of which may be a subtype of another entity class
2. Relationships with cardinality and optionality at each end (the technique is an extension of that described in Section 3.5)
3. Attributes of entity classes (and possibly relationships), which may be marked as mandatory or optional (and possibly multi-valued)
4. Intersection entity classes implementing binary “many-to-many” relationships or n-ary relationships
5. Uniqueness constraints on individual attributes or subsets of the attributes and relationships associated with an entity class
6. Other constraints.

10.18.1 Naming Conventions

In order to be able to generate grammatically sensible assertions, we have to take care in naming the various components of the model. If you are following the conventions that we recommend, the
following rules should be familiar to you:

• Entity class names must be singular and non-collective, (e.g., Employee or Employee Transaction but not Employees, Employee Table, nor
  Employee History).

•  

• Entity class definitions must be singular and non-collective, (e.g., for an entity class named Injury Nature,“a type of injury that can be incurred by a worker,” not
  “a reference list of the injuries that can be incurred by a worker,” nor “injuries sustained by a worker”). They should also be indefinite, (i.e., commencing with
  “a” or “an” rather than “the”-hence “a type of injury incurred by a worker” rather than “the type of injury incurred by a worker”).

•  

• Relationship names must be in infinitive form, (e.g., “deliver” rather than “delivers” or “deliverer” and “be delivered by” rather than “is delivered
  by” or “delivery”). There is an alternative set of assertion forms to support attributes of relationships; if this is used, alternative relationship names must also be provided in
  the 3rd person singular form (“delivers,” “is delivered by”).

•  

• Attribute definitions must refer to a single instance, (e.g., for an attribute named Total Price, “the price paid inclusive of tax” not “the prices paid inclusive of
  tax”). They should also be definite, (i.e., commencing with “the” rather than “a” or “an” -hence “the price paid inclusive of tax” rather than
  “a price paid inclusive of tax”).

•  

• Attribute and entity class constraints must start with “must” or “must not” and any other data item referred to should also be qualified so as to make clear precisely which instance of that
  data item we are referring to, (e.g., “[End Date] must not be earlier than the corresponding Start Date” rather than “must not be earlier than Start Date”).

10.18.2 Rules for Generating Assertions

In the assertion templates that follow:

1. The symbols are used to denote placeholders for which the nominated metadata items can be substituted.

2.  

3. The symbols { and } are used to denote sets of alternative wordings separated by the | symbol, (e.g., {A|An} indicates that either “A” or “An” may be used). Which alternative is used may
   depend on:

   1.  

   2. The context, (e.g., “A” or “An” is chosen to correspond to the name that follows).

   3.  

   4. A property of the component being described, (e.g., “must” or “may” is chosen depending on the optionality of the relationship being described).

The examples should make these conventions clear.

10.18.2.1 Entity Class Assertions

For each entity class, we can make an assertion of the form:

“{A|An} is .”
(e.g., “A Student is an individual person who has enrolled in a course at Smith College.”)

For each entity class that is marked as a subtype (subclass) of another entity class, we can make an assertion of the form:

“{A|An} is a type of , namely .”
(e.g., “A Distance Learning Student is a type of Student, namely a student who does not attend classes in person but who uses the distance learning facilities provided by Smith
College.”)

10.18.2.2 Relationship Assertions

For each relationship, we can make an assertion of the form:

“Each {must|may} {just one |one or more } that {may|must not} change over time.”
(e.g., “Each Professor may teach one or more Classes that may change over time.”)

For recursive relationships, however, this assertion type reads better if worded as follows

“Each {must|may}
{just one other |one or more other } that {may|must not}6 change over time.”
(e.g., “Each Employee may report to just one other Employee.”)

We found in practice that the form of this assertion for optional relationships (i.e., with “may” before the relationship name) was not strong enough to alert reviewers who required that the
relationship be mandatory, so an additional assertion was added for each optional relationship:

“Not every has to
{{a|an} |}.”
(non-recursive) or “Not every has to
{another |other }.” (recursive)
(e.g., “Not every Organization Unit has to consist of other Organization Units.”)

We have also found that those relationships that are marked as optional solely to cope with population of one entity class occurring before the other (e.g., a new organization unit is created
before employees are reassigned to that organization unit) require an additional assertion of the form:

“Each should ultimately {{a|an} |}.”
(e.g., “Each Organization Unit should ultimately be assigned Employees.”)

10.18.2.3. Attribute Assertions

For each single-valued attribute of an entity class, we can make assertions7 of the form:

“Each {must|may} have {a|an} which is .
No may have more than one .”
(e.g., “Each Student must have a Home Address, which is the address at which the student normally resides during vacations. No Student may have more than one Home Address.”)

Note that the must/may choice is based on whether the attribute is marked as optional. Again, the “may” form of this assertion is not strong enough to alert reviewers who required that the
attribute be mandatory, so we added for each optional attribute:

“Not every has to have {a|an} .”
(e.g., “Not every Service Provider has to have a Contact E-mail Address.”)

This particular type of assertion highlights the importance of precise assertion wording. Originally this assertion type read:

“{A|An} does not have to have {a|an} .”
(e.g., “A Service Provider does not have to have a Contact E-mail Address.” )

However, that led to one reviewer commenting, “Yes they do have to have one in case they advise us of it.” Clearly that form of wording allowed for confusion between provision of an attribute for
an entity class and population of that attribute.

If the model includes multi-valued attributes, then for each such attribute we can make assertions8 of the form:

“Each {must|may} have which are .
{A|An} may have more than one .”
(e.g., “Each Flight may have Operating Days, which are the days on which that flight operates. Each Flight may have more than one Operating Day.”)

If the model includes attributes of relationships, then for each single-valued attribute of a relationship, we can make assertions of the form:

“Each combination of and {must|may} have {a|an} which is .
No combination of and may have more than one .”
(e.g., “Each combination of Student and Course must have an Enrollment Date, which is the date on which the student enrolls in the course. No combination of Student and Course may have more
than one Enrollment Date.”)

Similarly, if the model includes multi-valued attributes as well as attributes of relationships, then for each such attribute, we can make assertions9 of the form:

“Each combination of and {must|may} have which are .
A combination of and may have more than one .”
(e.g., “Each combination of Student and Course may have Assignment Scores which are the scores achieved by that student for the assignments performed on that course. A combination of Student
and Course may have more than one Assignment Score.”)

All assertions about relationships we have previously described relied on the relationship being named in each direction using the infinitive form (the form that is grammatically correct after
“may” or “must”); if a 3rd person singular form (“is” rather than “be,” “reports to” rather than “report to”) of the name of each relationship with attributes is also recorded,
alternative assertion forms are possible. If the attribute is single-valued:

“Each that
{a|an} {must|may} have {a|an} which is .
No that
{a|an} may have more than one for that .”
(e.g., “Each Student that enrolls in a Course must have an Enrollment Date, which is the date on which the student enrolls in the course. No Student that enrolls in a Course may have more
than one Enrollment Date for that Course.”)

If the attribute is multi-valued:

“Each that
{a|an} {must|may} have which are .
A that
{a|an} may have more than one for that .”
(e.g., “Each Student that enrolls in a Course may have Assignment Scores, which are the scores achieved by that student for the assignments performed on that course. Each Student that enrolls
in a Course may have more than one Assignment Score for that Course.”)

Note that each derived attribute should include in its the calculation or derivation rules for that attribute.

If the model includes the attribute type of each attribute (see Section 5.4), then for each attribute of an entity class we can make an assertion of the form:

“The of {a|an} is (and exhibits the properties of) {a|an} .”
(e.g., “The Departure Time of a Flight is (and exhibits the properties of a TimeOfDay.”)

The document containing the assertions should then contain in its frontmatter a list of all attribute types used and their properties. If these are negotiable with stakeholders they should be
included as assertions, (i.e., each should be given a number and a check box).

10.18.2.4. Intersection Assertions

There are three types of intersection entity classes to consider:

1. Those implementing a binary many-to-many relationship for which only one combination of each pair of instances is allowed (i.e., if implemented in a relational database, the primary key would
   consist only of the foreign keys of the tables representing the two associated entity classes). The classic example is Enrollment where each Student may only enroll once in each Course.

2.  

3. Those implementing a binary many-to-many relationship for which more than one combination of each pair of instances is allowed (i.e., if implemented in a relational database the primary key
   would consist not only of the foreign keys of the tables representing the two associated entity classes, but also an additional attribute, usually a date). The classic example is Enrollment where a
   Student may enroll more than once in each Course.

4.  

5. Those implementing an n-ary relationship.

For each attribute of an intersection entity class of the first type, we can make assertions10 of the form:

“There can only be one for each combination of and .
For any particular a different can occur for each .
For any particular a different can occur for each .”
(e.g., “There can only be one Conversion Factor for each combination of Input Measurement Unit and Output Measurement Unit.
For any particular Input Measurement Unit a different Conversion
Factor can occur for each Output Measurement Unit.
For any particular Output Measurement Unit a different Conversion
Factor can occur for each Input Measurement Unit.”)

Note that can be:

1. An attribute name
2. The name of an entity class associated with the intersection entity class via a non-identifying relationship.11

For each attribute of an intersection entity class of the second or third type, we can make assertions12 of the form:

“There can only be one for each combination of
, , …and .
For any particular combination of …and a different can occur for each .”

Note that:

1. There is an for each part of the identifier of the intersection entity class, and it is expressed as one of:
   1. The name of an entity class associated with the intersection entity class via an identifying relationship
   2. The name of the attribute included in the identifier of the intersection entity class.

       

2. An assertion of the second form above must be produced for each identifier component of each intersection entity class, in which the name of that identifier component is substituted for , and
   all other identifier components appear in the list following “combination of.”

Thus, in the case of Enrollment where a Student may enroll more than once in each Course:

“There can only be one Achievement Score for each combination of Student, Course, and Enrollment Date.
For any particular combination of Course and Enrollment Date, a different Achievement Score can occur for each Student.
For any particular combination of Student and Enrollment Date, a different Achievement Score can occur for each Course.
For any particular combination of Student and Course, a different Achievement Score can occur for each Enrollment Date.”

10.18.2.5. Constraint Assertions

For each attribute of an entity class on which there is a uniqueness constraint, we can make an assertion of the form:

“No two can have the same .”
(e.g., “No two Students can have the same Student Number.”)

For each set of data items of an entity class on which there is a uniqueness constraint, we can make an assertion of the form:

“No two can have the same combination of , , . . . and .”
(e.g., “No two Payment Rejections can have the same combination of Payment Transaction and Payment Rejection Reason.”)

Note that each can be:

1. An attribute name
2. The name of another entity class associated with this entity class via a relationship.

For each other constraint13 on an attribute, we can make an assertion of the form:

“The of {a|an} .”

As these can vary considerably in their syntax, we provide a number of examples:

“The Unit Price of a Stock Item must not be negative.”
“The End Date & Time of an Outage Period must be later than the Start Date & Time of the same Outage Period.”
“The Alternative Date of an Examination must be entered if the Deferral Flag is set but must not be entered if the Deferral Flag is not set.”
“The Test Day of a Test Requirement must be specified if the Test Frequency is Weekly, Fortnightly, or Monthly. If the Test Frequency is Monthly, this day can be either the nth day in the month
or the nth occurrence of a specified day of the week.”
“The Test Frequency of a Test Requirement may be daily, weekly, fortnightly, monthly, a specified number of times per week or year, or every n days.”

The last example shows how a category attribute having a defined discrete set of values can be documented for confirmation by reviewers.

For each other constraint on an entity class, we can make an assertion of the form:

“{A|An} .”
(e.g., “A Student Absence may not overlap in time another Student Absence for the same Student.”)

It can also be useful to use this template to include additional statements to support design decisions, such as:

“A Sampling/Analysis Assignment covers sampling and/or analysis relating to all Sampling Points at one or more Plants, therefore there is no need to identify which Sampling Points at a Plant
are covered by an Assignment.”

6 – Depending on whether the relationship is transferable or non-transferable.

7 – These are not alternatives, both assertions must be made.

8 – Again these are not alternatives, both assertions must be made.

9 – Again these are not alternatives, both assertions must be made.

10 – Again these are not alternatives, both assertions must be made.

11 – For example the intersection of entity class Enrollment may have the identifying relationships to Student and Course but a nonidentifying relationship to Payment Method and attributes of
Enrollment Date and Payment Date. can refer to any of those last three.

12 – Again these are not alternatives, both assertions must be made.

13 – Note that these may exist in many forms, as described in Chapter 14.

Printed with permission from Morgan Kaufmann, a division of Elsevier. Copyright 2005. For more information on this book and other similiar titles, please visit www.books.elsevier.com/computing.