Having discussed attributes intended to name entity instances in Part 6 of this series, we move on to attributes intended to satisfy the need to say something quantitatively about an instance.
Well-defined quantity attributes require particular attention be paid to their unit of measure (UoM) and precision.
Numbers verses Quantities
There are attributes whose values only contain numeric digits, such Credit Card Number. There are others, such as Part Number, whose name implies that values are numbers, but in some organizations, values of these attributes are allowed to include alphabetic characters. The objective of these sorts of attributes is actually to name or identify an entity instance, not to quantify it.
Genuine quantities have magnitude. A value can be bigger, smaller, or the same size as another value. If you double a quantity value (i.e. multiply it by 2), the resulting value is twice as big (unless of course the original value was zero). It would not make business sense to double a credit card number, or subtract one from another.
Unit(s) of Measure (UoM)
The following table contains types and examples of units of measure commonly used in relation to quantity attributes.
|Type of Unit of Measure
|Example Measurement Units
| Feet, Metres, Miles, Kilometres
| Square Feet, Square Metres
| Cubic Feet, Cubic Metres, Gallons, Litres
| Ounces, Tons, Grams, Kilograms
| Seconds, Hours, Days, Years
| Degrees Fahrenheit, Degrees Celsius
| Amps, Watts
| US Dollars, GB Pounds, Euros
| Each, Carton
| Percentage, Multiplier
NOTE: In the table above, ‘None’ represents types of quantities that are intended to be used in calculations but themselves have no unit of measure. E.g. An additional 10% discount, intended to be applied to the value contained in a ‘price’ attribute.
The unit of measure that applies to a given quantity attribute may be defined globally for the organization, apply to a number of attributes within a given entity, apply to a single attribute, or be different for each attribute instance.
Organizational Level — An organization may deal in a single unit of measure for a given measurement type. For example, the organization’s customers and suppliers are all local, and so all dealings with them are always in one currency. In such situations, the unit of measure can be defined once, as an assumption or as a non-functional requirement. E.g. “All currency amounts represent US Dollars.”
Entity Level — An entity may contain a number of quantity attributes that are of the same unit of measure type, and for any given instance, all of the quantities involving that UoM type will be of the same units. E.g. An Order entity with attributes Net Amount, Tax, and Gross Amount all being in a given currency for an order. Each of these attributes can be identified as the “Currency” UoM type and a separate Currency attribute in the entity used to identify the specific currency that applies for a given order instance.
Attribute Level — A quantity attribute within an entity can always involve values of the same unit of measure. E.g. Hours Worked. Even if the UoM is part of the attribute name, it should still be defined explicitly as a property of the attribute within the data dictionary.
Entity Instance Level — In an entity where a quantity attribute can involve a different UoM per instance, one or more additional attributes will be required to identify the unit(s) that apply. E.g. A Service Contract with the quantity attribute Charge-out Rate, where for one instance the rate can be in US Dollars per hour and for another in Euros per day. In the service contract example there would need to be one attribute to capture the currency type and another for the applicable unit of time.
For most quantity attributes, their precision can be specified as a number of decimal places required by the organization. E.g. integer indicating no decimal places, or cents for currency quantities, implying two decimal places. The following are examples of precision that require special attention when defining the quantity attribute.
Smallest Reportable Time Increment — Many time recording systems capture the time worked in hours and portions of an hour. Typically, those portions of hours are restricted to specific increments. If the portions are in units of minutes, the precision may actually be limited to increments of 15 (i.e. 0, 15, 30 or 45). If the hours being recorded allow decimal values, up to two decimal places are allowed, but the actual precision may be limited to quarters of an hour (.25, .5, .75).
Orders of Magnitude Quantities — Where a quantity attribute represents what an organization considers a very large amount, the precision can be defined as an order of magnitude. E.g. the value 1 intended to represent one million, or one billion. The order of magnitude quantity could be defined to allow some number of decimal places, e.g. 1.3 indicating the value ‘one million, three hundred thousand’.
Sources of Quantity Values
As with other types of data, quantity values can be provided from sources external to the organization or from internal sources. A third source, in the case of quantity attributes, is derivations.
Externally-Sourced Values — Quantities that are sourced externally in real-time can be validated individually. The real-time process should be designed to deal with an invalid value, preventing the process from completing successfully if necessary. When batches of records containing quantities are received, the business needs to decide how it wants to deal with errors — either rejecting only those records that have problems or rejecting the entire batch, until the invalid values have been dealt with.
Internally-Sourced Values — When a quantity is sourced internally, it is useful to identify the organizational role(s) that have responsibility for providing values. Some quantities, often price-related, are decided by product owners. Other quantities are simply part of an operational process, where staff members record values that come to them as part of the process. Where money is involved, and potentially large amounts, there is often a ‘separation of duty’ (SOD) process where a dollar value is entered by one person but required to be validated by a second person before the process is allowed to complete.
Derivable Values — Where two or more values from different attributes are used to produce a new value of interest to the organization, an attribute should be defined to represent the derived value, associated with the entity it quantifies. The derivation should be described as part of that attribute’s definition. NOTE:
The derived attribute represents values that are meaningful to the business. Designers are left to decide whether a derived value should be physically stored, or derived as needed.
Both UoM and precision are important when defining a derivation. As the saying goes, “You can’t add apples and oranges.” Also to be considered is where two or more quantities are of the same units, but of different orders of magnitude. Those magnitudes will need to be brought into alignment within the derivation.
NOTE: Where derivations involve more than multiplying or dividing two or more decimal values, rounding can be an issue. Where and how to round is outside the scope of these articles.
Well-defined Quantity Attributes
From a data dictionary template perspective, a well-defined quantity attribute should have the following quantity-specific properties addressed:
- Unit(s) of measure — Even if the attribute name says something about its units, the unit(s) should be identified explicitly. Where the unit(s) vary per instance and are captured in a separate attribute, that attribute should be referenced.
- Precision — Most often a simple statement of the number of decimal places. Exceptions, as discussed above, should be described in text.
- Maximum — The business question that should be answered by a subject matter expert is, “What’s the largest value of this quantity ever encountered or that needs to be catered for?” NOTE: Using nines (e.g. 999,999) to describe a large value is not business oriented. If, for example, the answer to the question is ‘850,000’ then designers will understand what’s required.
- Can be negative? — yes/no
- Zero ok? — yes/no
- Derivation — For the attribute being derived, a business definition or rule describing it. This can be in the form of an algebraic formula, a step-by-step process, a flow chart, or formal business rule definition language. Ideally one or more worked examples containing realistic values would be included.
Coming in Part 8 —Attributes That Classify