The ORM Foundation

How should I properly represent an entity or value type that only permits a single value? For example in the following model CPI and ECI are supposed to represent single values - RateOfInflation being the designated rate at some point in time.

 

Well, Terry says that one should use an example.So I used this one:

http://www.statistics.gov.uk/cci/nugget.asp?id=19

From this example, I created the model below
For the "Month" reference mode you could use either YYMM or YYYYMM.
For the other three object types I suggest a data type of Numeric Decimal with a precision of 4 and a scale of 1. 

Thanks for the suggestion Ken but there is no month or date associated with the values. They are just single values that will serve as configurable inputs to queries and other logic. The actual implementation will be a table restricted to a single row and with columns for each of CPI and ECI. My question is how do I visualise that.

ORM includes an Object Cardinality Constraint for this purpose (in this case, use # <= 1), as discussed on p. 289 of the "Big Brown Book".

Unfortunately, we have not yet added support for this kind of constraint to NORMA. Until we do add this support, I suggest you add the constraint in a model note, and code the constraint manually in your implementation.

Kind regards

Terry

Terry, What verbalisations do you use for cardinality constraints? I don't see any examples in the BBB. Clifford Heath.

Here are suggested verbalizations for the object cardinality constraint examples on p. 289, Fig. 22:

(a)    The number of instances in the population of JuryMember is 12.

(b)    The number of instances in the population of Senator is less than or equal to 100.

Here is a suggested, optimized verbalization for the role cardinality constraint example on p. 289, Fig. 22 (c):

At most one Employee is the director.

This role cardainality constraint pattern is the common case, so is worth optimizing. A more complex verbalization pattern is needed for the general case.

Cheers

Terry

Thanks Terry. My question arose because I couldn't see how to specify a uniqueness constraint in NORMA without specifying at least one value type. In other words I didn't know how to express a dependency on the empty set: {} -> A. A cardinality constraint would do though.

An alternative to a cardinality constraint for a singleton is to define an entity with a simple identification scheme, but use a value constraint on the identifying value. If there's only one allowed value, there can only be one identified entity.

However I usually find that it's better not to use cardinality constraints anyhow. To take the BBB JuryMember example, that would allow representation of only a single jury. instead, you could allow any number of juries, each having exactly 12 members, using a non-mandatory frequency constraint. Then you can restrict the number of allowed Juries to one (in code, if no cardinality constraint is possible) - but if your requirements later change to require you to support more than one Jury, it's a simpler change.

Hi Clifford, that alternative won't work for the example posed because the value may change over time. The cardinality constraint does the job because it simply restricts the cardinality for the population (which may vary over time), not the type. Of course, you could use a value constraint if you were willing to change the constraint every time the value changed, but that would be a pain.

However, I agree with you that in most cases, cardinality constraints are less useful than value or frequency constarints, as they are often implied by the latter (a similar example to the one you cite is given on p. 289 of the BBB).

Cheers

Terry

Terry Halpin:

that alternative won't work for the example posed

Actually, the single value used doesn't have to be the mutable value. For example, the CPI is the inflation rate as calculated by some authority. Use the name of that authority as the sole allowed identifying value for a "CPI Authority" entity type, then you can have a CPI entity identified by that value type "CPI is identified by CPI Authority where CPI is current value as determined by CPI Authority". Finally add the "CPI has one Value" fact type, and you're done. There can only be one CPI instance, and it can have only one value.

Hi Clifford

That's a neat trick, and it will work so long as (a) the CPI Authority itself is immutable, and (b) you know the CPI Authority. If either of those assumptions doesn't hold, then you are going to need a cardinality constraint.

I'd prefer to add support for cardinality constraints in the relevant ORM tool, as I think this is conceptually cleaner as well as adding expressibility. In practice, role cardinalities turn out to be even more useful than object cardinalities.

Cheers

Terry

Terry Halpin:

That's a neat trick

it's a trick, but it's not just a trick. It reflects the fact that every model exists in some context, and a thing that's a singleton in one context may have counterparts in other contexts. This approach merely makes the contextualisation explicit by encoding the contextual assumption into the model. I find that's almost always a useful thing to do, because such assumptions are a source of problems when, for example, your company merges with another, and now has two of something it previously only had one of.

Of course, I have no real issues with the concept of implementing cardinality constraints. I suspect they're mostly used to hide contextual assumptions though. True uniqueness is a very rare thing indeed.

Clifford's suggestion is generally how I do it in SQL. I'd just prefer not to put a "dummy" attribute (x) in the model simply in order to express this constraint. A cardinality constraint is more concise. An alternative would be to have some way to specify a uniqueness constraint without any associated values - in relational terms a primary key on the empty set of attributes.

CREATE TABLE RateOfInflation (x CHAR(1) NOT NULL CHECK (x = '!') UNIQUE, CPI NUMERIC(10,2) NOT NULL, ECI NUMERIC(10,2) NOT NULL);