In my recently-posted (in bug reports) orienteering models, I need a
Series entity and an Event entity. An event may be identified by an
EventName, or it may have a particular sequence in a series (which
is named). I've made the Inclusive-Or constraint, but I'd like to
avoid declaring an Event reference mode of ID when that really isn't
in the domain model.
How can I model this external identifier? The ORM2 elements show a
circle containing a "P" for this case, but I can't see how to get this
in NORMA. It seems that I should be able to right-click on the inclusive
OR marker and make it an identifier...? Or is this not supproted yet in
Kevin M. Owen
If you put on an external uniqueness constraint and connect it to the correct roles, you should be able to set "IsPreferredIdentifier" to true in the Properties window.
With the ORM2 notation, we are using a double line in the circle to represent the preferred identifier uniqueness constraint, and a single line to represent a "normal" uniqueness constraint. This better matches the notation for uniqueness constraints on FactTypes (a single line above the role), and is much less English-specific (unlike the 'U'niqueness and 'P'rimary that Visio and other tools used for ORM1).
I'm sure you'll see a responce from the team, but it looks like you can use a generic external uniquness constraint; then after sellecting the appropriate role sequences and commiting them, use the properties window of the new constraint to change the "Is prefered reference from 'False' to 'True.'
My guess is that this will suit your needs. However, you should also consider using a unique ID for your events, even though the the designation isn't in the current specifications for the domain. If you judge that an event will play an important role, and especially, if an event might change it's order in, or even in which series it will be included,then it makes sense to give it an unique ID of it's own. Remember that you can alter column name assignments in the physical implementation, or refer to an event by any term or terms you like in a report or application that will access the DB. I often chose terms that I feel makes for a better model, even if they aren't what a client might expect to see. After all ORM requires a formalized language to avoid ambiguities - so there isn't always a one to one match up to a natural language. (As I haven't looked at your model, these are generic observations). In any even, I hope it helps - and I was right about setting the constraint! BRN..
Ok, thanks guys. I had missed the change from (P) to (=) in ORM2.
Re "you should also consider using a unique ID for your events",
I dislike creating surrogate keys in a conceptual model, as it
gets used to bypass the fact that you don't really know how the
object is identified. In my physical schemas, I use surrogate keys
for referential integrity checking, and put a unique constraint on
those fields, but I reserve the "primary key" distinction for the
*natural* primary key. The cases where I've seen this policy violated
have *always* been a source of problems. O-O programmers don't seem
to like to use natural primary keys, but I've found them essential.
In this case, an Event is either a single named item such as
"The Ringwood Maxi-Micro", or it's an event in a series "The 3rd
event in the Wednesday Summer Series 2007".
In the little model I've published at the URL below, when I try
to make the external uniqueness constraint into a preferred
identifier, I get the message "The current state of the roles
attached to the external uniqueness constraint do no permit its
use as a preferred identifier. All roles must be on a binary
fact types, and all opposite roles must be attached to the same
non-ValueType ObjectType. All opposite roles must also have
single-column uniqueness constraints, but this precondition is
applied automatically by the object model if it is not satisfied."
It looks to me like there's no logical reason why this constraint
cannot be a preferred identifier, though I accept that it isn't
implemented in NORMA yet. Comments on that please?
I've resolved the problem by objectifying the Series/number fact,
then relating that fact to Event with inclusive-or and an external
uniqueness constraint as preferred.
The before and after ORM files are published at
Glad you found the prefered property assignment for the external constraint. Sounds like you still have issues with the implementation, and I hope you and the team are able to work through to a satisfactory result. (I recall have issues with composite keys in InfoModeler, when it got to the point of generating DDL scripts.)
I'll try to take a look at the ORM files you posted later on. Sounds like you have good reasons go with the composite primary reference. As long as you choose wisely, going that route may help to stick closer to the Relational Model principles, and so be the better choice. I had thought you might be adding derived data into the schema to satisfy a clients expectations; but it sounds like you are working to retain RM adherance, not violate it. All for that. BRN..
Just took a look at the ORM diagram ('After'). What you have there doesn't look right to my eyes. Basically, you are saying that some entity (say me), is primarly referenced by either my FirstName AND my MiddleName+LastName (indicated by the external uniqueness constraint), yet at the same time saying, that I can't play the roles of having a FirstName if I also play the role of having a MiddleName+LastName (indicated by the disjunctive manatory role constraint). Seems that my primary reference is a contradiction (some people would agree with that!). I could have missed something important - has happened before, but as it stands, it doesn't look workable. I'll take another look and see if I can suggest alternatives, for what I think you are trying to accomplish. First thought is perhaps a subtyping scheme for Event.
Another suggestion is in finding a good (and short) alternative for the Name property of an objectified predicate - if your Fact concerned a piece of music in a particular place in a symphony, I'd suggest 'Movement.' In a series of events, maybe Episode or Lesson - though I think you can do better than those. One reason is that when you get to the mapping phase, those concatanated Entity names get very unwieldy.
If missed the logic in the reference scheme you employed, please point it out - live and learn! BRN..
Ok, Thanks, I'll try to explain my rationale. Orienteering is a sport; an event is a course set on a map, in which people (or in rogaines, teams) may enter different classes (by age range, gender, etc). You can see this in the big model attached to bug 1595405 at <https://sourceforge.net/tracker/index.php?func=detail&aid=1595405&group_id=158881&atid=809608>.
Some events are special, having their own name and identity, and some are un-named, just a part of a series of events. That's what I'm trying to model here. A mathematician might say that a special event is just a single-event series, but that doesn't jibe with actual usage "Are you doing the Four Peaks event this year?", "Fred won A grade in the 2nd event of the Summer Park/Street series," etc.
Now the reason I'm using ORM is that rather than shoot for mathematical models as relational data modelling does, I can capture actual usage. The goal here is to capture the semantics exactly the way the users think, not the way it's convenient to model it, so that when an application UI is built, it *exactly maps* the conceptual model and doesn't need a lot of code written to handle the mapping. In the process, I hope to show that most of the work of building an application can be automated, with the real content moving into the semantic model. A tool can be given a few hints about the navigational model to use, then it can generate a complete working application that just needs visual styling to be complete.
I realize that's a big goal, but I don't believe in setting low goals :-).
I have a better idea of how/why you are using ORM now. As long as you aren't aiming for a normalized, Relational Model compliant DB schema the 'primary reference is a contradiction' need not slow you down. My guess is that the limitations of NORMA (as it trys to help you achive a RM compliant schema) will be a hassle, unless and until they provide a set of override capablities that will let you wander of the path 'proceed at your own risk.' ORM2 as a method of expression and a set of symbols for expression of a methodology shouldn't be a problem, but any tool that trys to keep the users on the stright and narrow is bound to be frustratingly overly helpful.
BTW, have you looked into Intentional Programming (IP)? It was a research inititive out of Microsoft in the early 2000's. They dropped it (not sure why), but is being carried forward by Intentional Software - http://intentsoft.com You may find some useful concepts in futherance of your objectives.
Thanks for the UofD about orienteering, always helps to know about the domain to be able to model it. Also, I'd give generating a fully RM compliant schema for the domain (using NORMA), a shot. Then a comparison of where the two diverge (on a conceptual/semantic level) could provide useful insights for your research. You could then asses what's gained and what's lost from the symantic intention by the formalization impossed by RM compliance, on the conceptual model level. BRN..