The ORM Foundation

 I would regard that rule as incorrect. It's not common, but as a counter-example, I have a model that says "Month is in Season", where both are value types both with enumerated value restrictions (month names, season names). There's nothing logically wrong with that approach, though it would have been just as easy (and arguably better!) to have an objectified Month identified by MonthName and equivalent for Season. It yields the same result on mapping, but there are two concepts not just one defined in the ORM.

Regarding Vicor's original question, some NIAM users originally placed restrictions on use of value types, but I never adopted those restrictions. In ORM 2, a value type may appear wherever an entity type may appear. A simple example from my book is: State(.code) calls BeerServe(flOz:) by CommonName(). Here the UC spans roles 1 and 3.

Regarding Clifford's example, I regard Month and season to be entity types, not value types.

Cheers

Terry

Hi Dr, Clifford,

Thank you for responding to this post. The subject has always been a burning question with me. As an intuitionist, I don't always get it right, but there seemed good grounds for there to be Value Types in Fact Types with TotalInternalUniquenessConstraints.

So I can support this one without trying.

As a funny story, at Uni my project partner and I got a 21/2 out of 5 for a solution to our first assignment, based on our having objectified a Fact Type with a Uniqueness Constraint spanning only 1 of 2 roles (of the Fact Type). It gives me great joy (but not an extra 21/2 marks) to know that this is now possible in ORM 2. I wonder if it's too late to be re-graded...lol

Best regds

Victor

 Fact types having a UC covering only one of two roles are the most common type, and have always been allowed since NIAM. That doesn't mean that your university answer was correct, of course! But I think that objectified versions of such fact types are rather strange and unusual. Can you remember what the example was? I haven't com across the idea before, and though my metamodel and syntax for CQL allows it, I'm not sure what it would mean.

Clifford, we got 4 1/2 out of 5 for the project. I was able to demonstrate that if that type of construct was allowed in Niam, then the result was superier to the lecturers result and in fact showed gaping holes in the lecturers result.

Yes, I still know what the example was. It is treasured piece of memerabilia. I was looking at it the other day.

You, on the other hand, might look upon 'humor' as 'humor' and pick your targets more wisely ;)

I post this one out of deep respect for my lecturer. This was 1993 and still in the days of Niam. You can see the comment "The uniqueness constraint must be over all the roles of the nested fact type". This was true at the time, so we'd stuck our neck out by submitting this work. My memory of it was that we had actually 'missed' that this was not allowed in Niam (at the time) and thought that was the most logical and concise result (based on what we thought Niam was).

You can see the marks (in pencil) of a great discussion about the whole model. Our result, if Objectified fact types without TotalInternalUniquenssConstraints were allowed (as is now allowed in ORM 2), was exactly what the assignment question demanded (which is lost to time, I don't have the original question).

As with all universities, sometimes private business and governments come to them for advice. I'm not sure that this was the case for the assignment (a transport database for the City of Brisbane), but I have a hunch. At any rate, we were awarded an upgrade of marks, probably not because we proved a case for changing Niam, but because the 450 other students had been marked based on a model that allowed violations from the question (i.e. ours was a better result when normalised as a relational database). I kinda got the feeling at the time it was like "Okay...here's the marks, but don't tell anyone [you've shaken the tree]". lol Which we didn't of course. But we formed a very strong relationship and respect for that lecturer, who went on to oversee our major final year project. I dedicated Niam+, my first ORM modeling tool to that lecturer, and still call to say hello from time to time.

So, I'm not interested in debating this one. We weren't 'incorrect' (as pragmatism and time has shown), but we took chances and got lucky. I think the respect was reciprocated, so to that extend we did okay. I wouldn't recommend taking big chances to anyone, you risk failure at every turn.

Assignment1-ITB220.JPG

 Hello Dr. Halpin,

Not seeing the full context of the UofD for Clifford's example, would it be fairer to say that "Month" and "Season" would be Entity Object Types, in most common UofDs?  If months are used purely as labels for payment periods in a UofD concerning property tax payments:

Payment(.id) is made for Property(.address)

Payment is made in Month() in Year(.integer)

I could see them as Value Object Types.  Just being used as a label or ordinal doesn't make the term a Value Object Type, but if they are used exclusively as ordinals or otherwise only as labels or indicators for instances of some Entity Object Type in a UofD, isn't Value Type a better choice?   In other words, is use of a term in the context of a particular UofD the deciding factor in choice of Entity or Value, Object Type?

Brian Nalewajek:

Not seeing the full context of the UofD for Clifford's example

I've attached the ORM diagram where this occurred below. This was my attempt at comprehending what Adrian Walker is doing at his "wiki" for "executable English" at <https://www.reengineeringllc.com/> in his Oil Industry Supply Chain Management example (log in to see the Business Rule Examples using the demo account). I manually reverse engineered this ORM schema from his SQL one, as outlined in his paper.

I left most elements of Adrian's schema unchanged, but I changed the handling of SupplyPeriods, because I believe that his would yield incorrect query results across years. I haven't tested that though, as his sample population isn't significant. I also added Costs to transport and production, which weren't modeled in his system. The complete CQL from my ORM model is pasted below. You'll see that in CQL at least, objectifying Month as "Month identified by MonthName" would add nothing but extra words. I haven't added the month name abbreviations as a value restriction, now have I added the reference population for "Month is in Season", as that's not supported in ORM (though it is in CQL).

vocabulary OilSupply;

/*
 * Value Types
 */
Cost is defined as Money();
Month is defined as VariableLengthText(3);
Product is defined as VariableLengthText(80);
Quantity is defined as UnsignedInteger(32);
RefineryName is defined as VariableLengthText(80);
Region is defined as VariableLengthText(80);
Season is defined as VariableLengthText(6) restricted to {'Spring', 'Summer', 'Autumn', 'Winter'};
TransportMethod is defined as VariableLengthText() restricted to {'Rail', 'Road', 'Sea'};
Year is defined as SignedInteger(32);

/*
 * Entity Types
 */
Refinery is identified by RefineryName where
    Refinery has exactly one RefineryName,
    RefineryName is of at most one Refinery;
TransportRoute is where
    TransportMethod transportation is available from Refinery to Region at at most one Cost per kL,
    TransportMethod transportation is available to Region from Refinery at Cost per kL;

SupplyPeriod is identified by Month and Year where
    SupplyPeriod is in exactly one Month,
    SupplyPeriod is in exactly one Year;
ProductionCommitment is where
    Refinery has committed to produce Quantity of Product in SupplyPeriod at at most one Cost;
RegionalDemand is where
    Region will need at most one Quantity of Product in SupplyPeriod;

Month is in exactly one Season;
AcceptableSubstitutes is where
    Product may be substituted by alternate-Product in Season [acyclic, intransitive],
    alternate-Product is an acceptable substitute for Product in Season;
 

Hi Clifford,

There's Lot of stuff there to consider.  I'll premise my remarks by noting that there are various motivations to model with ORM; and so comments on the correctness of an ORM model can be subjective.  I know you have, on other occasions, put aside standard ORM modeling practices, to pursue something other than the usual goal of a Relational Model compliant data structure.  You also mentioned that this was an interpretation (manual re-engineering), of a model created using another method; so I won't assume this is how YOU would create an ORM model for this UofD.  I know you also have attempted models where only the terms explicitly used in the UofD, are allowed.  All this is that I get that you may have a good reasons to model this as you have.  With those caveats, there are a number of places where the model breaks with standard ORM practice - as I understand it

I see the Month VOT is shadowed, so I assume there's a reference outside of the visible part of the model; so I can't really comment on how Season and Month (and I guess SupplyPeriod) are used.

The quaternary Fact Type about committing to production looks like it violates the elementary FT restriction.  If you limit the model to the terms used in the target, it may seem necessary; but adding a Contract(.id) Entity OT allows the FT to be divided without loss of import:

Refinery(.id) signs Contract(.id) - rather than Refinery commits to ....

Contract is for Product(.name)

Contract is for Quantity()

Contract is for Cost()

Contract is for SupplyPeriod

The "Region will need..." quaternary FT looks legitimate, but why objectify it, if it is not referenced elsewhere? 

The ...transportation is available... quaternary FT is oddly constructed: "TransportMethod ...transportation is available...."  I'd opt for "Transportation(.method) is available...."  Also, I think the "...per KL" at the end is out of place in a predicate reading.  I think the "at...Cost" should be taken out, reducing the FT to a ternary.  The pricing structure can be added in a separate FT, if the ternary is objectified.

I can't validate the >2 role IUCs without using the tool (it's like trying to do square roots in my head - in other words, too hard). 

Getting back to TH's comment on Entity/Value Object types, I think most of the Value Types in this model would be better as EOTs. 

If I have a chance later, I'll take a better look at the text listing, and visit the website you referenced.  I hope the "what's wrong with this picture" approach I took is what you were after.  Final thought: consider moving this to a new thread; maybe titled ORM and CQL.

BRN..

Regarding Clifford's model and the difference between entity types and value types, I agree that sometimes it might make no difference to the physical database design whether an object type is classified as an entity type or a value type. But for conceptual schema design, I believe we should try to convey the semantics as clearly as possible, and there it does make a difference, especially if the conceptual schema is to be used in communicating with someone unfamiliar with the UoD.

As used in the model, I would rename Month to MonthNr or MonthName, or instead remodel using entity types. The term "Month" is used differently by people so needs care. For example, I usually model a month in the time stream as a coreferenced entity type, e.g. Month(is in year(CE), has MonthNr()) If I want to talk about a MonthNr or MonthName, then I call it what it is.

With the possible exception of Quantity, I would replace all of Clifford's other value types with entity types, with requires specifying an identification scheme.

e.g. instead of Cost(), I would use an entity type with the currency unit specified, e.g. Cost(USD:) or Cost(AUD:) or Cost(EUR:) etc.

Cheers

Terry

Terry Halpin:

I would replace all of Clifford's other value types with entity types

I agree. I left this model this way because it serves as a useful test case in the CQL converter.

Terry Halpin:

I would use an entity type with the currency unit specified

I haven't implemented units support yet, but I agree.

 Brian's right about the elementarity of ProductionCommitment; Quantity shouldn't be covered by the UC, which means that one of (or probably, both) Quantity and Cost should be roles of the objectification. Again, this was an error in Adrian's example that I retained.

There is no notion of Contract in the UoD; this model pertains to operations within a single company. ProductionCommitment is my word, and I perhaps should have used ProductionForecast. I wouldn't co-reference it fully to the binary form as Brian suggests however.

Month is only shadowed to a second occurrence on the same diagram, for its role in SupplyPeriod. There is no other diagram.

Brian Nalewajek:

I can't validate the >2 role IUCs without using the tool

If anyone has a model they'd like to see represented as CQL, I'd be happy to receive it in email. 

 Hi Clifford,

If you have reworked the model, it would be interesting to see how you incorporated the changes.  (I still think this line deserves it's own thread).  The text in your original post: is that generated from CQL, or something you typed in as notation?

When I suggested creating a "Contract" Object Type, I was not concerned with the name - Commitment, or something other would do as well.  For me, keeping to the literal terms in the current UofD is too restrictive.  My view is that the Object Type exists in the UofD, even if it has not been named; or the Object Type is required in order to model the target domain correctly (the modeler being justified in adding it to the UofD).

A few months back, I tried to start a thread on interpretations of the nature of Universe of Discourse.  In that thread, I included my working definition of a UofD.  My guess is that yours is somewhat different.  I'd like to see how you define it, why you choose to, and how it effects your approach to ORM.  I think that question is related to a survey Ken did on models as description or design. Reply to that thread, when you have a chance.  Your views will give me a better idea of where you are going with CQL.  Thanks for the offer to run a model through CQL; that too should help illustrate the differences.

BRN..

Brian Nalewajek:

The text in your original post: is that generated from CQL, or something you typed in as notation?

It's exactly as generated from the NORMA .ORM file, including the blank lines.

Brian Nalewajek:

working definition of a UofD

It's not really a term I use. I've adopted SBVR's term "Vocabulary", meaning a set of shared terms attaching to shared meanings in some community. Each member of that community will use many vocabularies attaching to different subject areas, or used by different communities for the same subject matter. Vocabularies may overlap in terms or in meanings, and may adopt some or all of the content of other vocabularies, but no single vocabulary may use the same term for more than one meaning. In this way, there's really no way to draw a line at the edge of the universe - just around the vocabularies of interest at the moment.

Brian Nalewajek:

If you have reworked the model, it would be interesting to see

A fresh PNG file is attached. Moving some of the value types to entity types improves the semantic purity (though I haven't done it with Season for example). Adjusting ProductionForecast and RegionalDemand so that all roles are covered by the uniqueness constraint clears up the other objections, including the error that allowed more than one quantity to be predicted for a given Refinery/Product/SupplyPeriod.

The generated CQL follows. Again, the CQL may be processed to exactly the same generated code as the ORM file. The data types are implicitly defined at present; in future they'll be imported from a vocabulary of standard NORMA types. I don't distinguish between data types and value types as NORMA does.

vocabulary OilSupply;

/*
 * Value Types
 */
Cost is defined as Money();
MonthCode is defined as FixedLengthText();
ProductName is defined as VariableLengthText();
Quantity is defined as UnsignedInteger(32);
RefineryName is defined as VariableLengthText(80);
RegionName is defined as VariableLengthText();
Season is defined as VariableLengthText(6) restricted to {'Spring', 'Summer', 'Autumn', 'Winter'};
TransportMethod is defined as VariableLengthText() restricted to {'Rail', 'Road', 'Sea'};
YearNr is defined as SignedInteger(32);

/*
 * Entity Types
 */
Month is identified by MonthCode where
        Month has exactly one MonthCode,
        MonthCode is of at most one Month;
Month is in exactly one Season;

Product is identified by ProductName where
        Product has exactly one ProductName,
        ProductName is of at most one Product;
AcceptableSubstitutes is where
        Product may be substituted by alternate-Product in Season [acyclic, intransitive],
        alternate-Product is an acceptable substitute for Product in Season;

Refinery is identified by RefineryName where
        Refinery has exactly one RefineryName,
        RefineryName is of at most one Refinery;

Region is identified by RegionName where
        Region has exactly one RegionName,
        RegionName is of at most one Region;
TransportRoute is where
        TransportMethod transportation is available from Refinery to Region,
        TransportMethod transportation is available to Region from Refinery;
TransportRoute incurs at most one Cost per kL;

Year is identified by YearNr where
        Year has exactly one YearNr,
        YearNr is of at most one Year;

SupplyPeriod is identified by Month and Year where
        SupplyPeriod is in exactly one Month,
        SupplyPeriod is in exactly one Year;
ProductionForecast is where
        Refinery forecasts production of Product in SupplyPeriod;
RegionalDemand is where
        Region will need Product in SupplyPeriod;
ProductionForecast predicts at most one Cost;
ProductionForecast is for exactly one Quantity;
RegionalDemand is for at most one Quantity;
 

Clifford Heath:

Brian Nalewajek:

The text in your original post: is that generated from CQL, or something you typed in as notation?

 

It's exactly as generated from the NORMA .ORM file, including the blank lines.

 

To clarify further, it's not "text generated from CQL", it *is* the CQL. That's the text I compile, and it's generated from ORM (or can be hand-typed).