Does anyone know how to suppress the verbalization of Physical data types
on object domains in VisioEA (2003)?
It represents unnecessary information, not needed by the user domain
expert,
and should not be part of the verbalization of the conceptual ORM data
model.
If I remember correctly, it was possible to suppress through the definition
of Preferences in VisioModeler 3.1.
-gord.everest

Does anyone know how to suppress the verbalization of Physical data types
on object domains in VisioEA (2003)?
It represents unnecessary information, not needed by the user domain
expert,
and should not be part of the verbalization of the conceptual ORM data
model.
If I remember correctly, it was possible to suppress through the definition
of Preferences in VisioModeler 3.1.
-gord.everest

First a little background. We have been asking for a different way to manage
this for about 8 years. So, I have some similar feelings about this. The
idea is a model driven approach - but we wanted a fact repository - this we
could reuse facts more freely. We also asked for an open-ended ability to
group facts as we see fit and place either facts or groups of facts together
for models as needed. Reuse of facts and object was a goal. However, what we
got is what we have. It seems you have gotten past the initial issue. That
being, you can have sub-models (components) which can be brought back
together to make a model. The issue with that is - the component model must
be as small as needed. For example I have made a component model as small as
a single fact. I had to do this in order to add that fact to more than one
major model  or another sub model for that matter. I adjusted my thinking to
say a model was a repository entry. That entry could be used in several
other models. This is a way out - but I do not like it, as it is too much
work. I like very fast things as well, especially at compile time and really
important at model creation time.

So, rather than 30 models you may actually have more models if any part of
those 30 models are the same facts/objects.

You would also have to maintain 30 logical models - one for each schema.
Then you could effect one logical model and not the others. This means that
in order to have a full physical model you have to put all 30 logical models
together.

I have create component models to use in several major models as a m means
to create re-useable parts such as address, or Product(id) has Product
Description().
These modes are very small to medium sized (10 or so tables). The idea
works, but is not exactly modeler friendly.

The bottom line - keep a separate logical model for each schema, make as
many component models as needed. Some components models may be used in more
that one logical model build. Merge the logical models in the ORACEL world.

You could also keep one logical model that consists of all the models, but
that where the slowness is probably located.

Future: There are a few new tools being created by various vendors. Some a
very small groups while Unisys and IBM are very forceful. The future is a
world where ORM, it may not bear that name) is used along with English rules
to create the databases.
For example, a Customer is a Gold Customer is they do over $50,000 worth of
Orders each Year for the past 3 years. This is rule and can be entered in
the modeling tool in English close to what I just said. Customer, Gold,
Order Total, Order Yearly Total are all objects that we would define in ORM
- some are derived. The rule would be implemented as well, just like any
other rule. The specs for this are well developed and Unisys for example has
15 people working on the implementation. Many of the issues we see today
have also been addressed - to what degree I am not sure.

Your issue is very important to us as we have been ORM practitioners for 25
years now. As people in the field we see things very differently than do the
theory people.

I am sorry you are having this issue. I am going to create a small sample
myself to see how I would manage your problem. If I come up with something
different I will let you know. Maybe, in our Visio extension, I can solve
the problem. We have created a very large extension to the Visio tool, but
it strictly for ourselves at this point. It is a product in the rough right
now. But, it has some possibilities. It also give me an idea of something to
add that would not be had to do. I am not sure out version will be useful in
the future, if these other vendors get their acts together. The Unisys tool
may be ready at the end of this year. It may also be for Unisys users only.
Others are probably 2 years away.

Pat



-----Original Message-----
From: markus_gallagher [mailto:markus@...]
Sent: Friday, March 19, 2004 9:16 AM
To: jcm@yahoogroups.com
Subject: [JCM] Updating Oracle Schema Owners using Visio Enterprise
Architect

I have a fairly large data model on an Oracle database containing
approximately 30 schema owners. I would like to reverse engineer the
individual schema owners into sub-models, edit the sub-models and
update the database schemas (keeping data model and database schema in
sync).

The problem is that every time I try to update the database from a
sub-model, Visio EA tries to synchronize the entire database instead
of simply the objects for the schema owner that I reverse engineered
in the first place. This process takes 30+ minutes which is unacceptable!

Is there anyway I could have Visio EA only synchronize the schema
owner instead of the entire database when I have the "detect changes
in database" selected during the "Update Database" process from the
Database menu?

Any help or hints greatly appreciated.




~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to correctly
model your business data requirements. Each day also contains "hands on"
labs where students practice the technique  while ORM-certified instructors
give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see
http://www.inconcept.com/training/ormseminar.html or e-mail
training@....
Yahoo! Groups Links

I have a fairly large data model on an Oracle database containing
approximately 30 schema owners. I would like to reverse engineer the
individual schema owners into sub-models, edit the sub-models and
update the database schemas (keeping data model and database schema in
sync).

The problem is that every time I try to update the database from a
sub-model, Visio EA tries to synchronize the entire database instead
of simply the objects for the schema owner that I reverse engineered
in the first place. This process takes 30+ minutes which is unacceptable!

Is there anyway I could have Visio EA only synchronize the schema
owner instead of the entire database when I have the "detect changes
in database" selected during the "Update Database" process from the
Database menu?

Any help or hints greatly appreciated.

Sorry - there is no Linux Version. It has been noted by the groups working
on the next generation of an ORM tool - it must work on multiple platforms.
I am not sure who will comply with the request however. There are at least 3
companies working on a new solution which includes vastly improved "business
rules". This is all part of the OMG business rules initiative. This
initiative includes ORM + business rules all in structured language. I
really want the tool be "any" platform.

The good news is that ORM + Business Rules is alive and people other than
Microsoft are working on it. I am not sure what MS is up to these days when
it comes to the current ORM implementation. I hear rumors, but nothing
solid.

Pat
InConcept, Partner

-----Original Message-----
From: Rodrigo B. Vieira [mailto:rodviking@...]
Sent: Sunday, February 29, 2004 3:33 PM
To: jcm@yahoogroups.com
Subject: [JCM] ORM tool for Linux?

Hi,

I just presented ORM to some colleagues and they got
really excited about it. The problem is that they use
Linux, so I'd like to know is there is any ORM tool
for that platform.

Anyway, I tested the implementation on Visio EA 2003
and it's brilliant, most of the small problems I had
on the previous versions were gone. I met some people
at Accenture-Norway who are using ORM for a huge
system and they are very happy with it.

Rodrigo

=====
The problem with designing something completely foolproof is to
underestimate the ingenuity of a complete fool. (Douglas Adams)


~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to correctly
model your business data requirements. Each day also contains "hands on"
labs where students practice the technique  while ORM-certified instructors
give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see
http://www.inconcept.com/training/ormseminar.html or e-mail
training@....
Yahoo! Groups Links

Hi,

I just presented ORM to some colleagues and they got
really excited about it. The problem is that they use
Linux, so I'd like to know is there is any ORM tool
for that platform.

Anyway, I tested the implementation on Visio EA 2003
and it's brilliant, most of the small problems I had
on the previous versions were gone. I met some people
at Accenture-Norway who are using ORM for a huge
system and they are very happy with it.

Rodrigo

=====
The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete fool. (Douglas Adams)

I'm looking for a quick way to load many objects and their metadata
into Microsoft Visual Studio Enterprise Architect, or even into
VisiomModeler 3.1. I have not discovered any capability in Architect,
and am not qualified to program my own OLE interface to VisioModeler.
Anyone want to help me?

In article <blh9lv+obe6@eGroups.com>, judiewebber
<judiewebber@...> writes
>Hi all,
>
>I am new to the world of ORM and am building my first ORM model but
>have run into a glitch that I am unsure how to handle.  We are
>currently in the process of rearchitecting all of our outdated
>systems.  A good portion of the data is shared amongst all of the
>different departments and has to this point been copied from system
>to system on a monthly basis.  Our goal is to create a global db for
>the shared data and individual ones for each application containing
>only the data that is not global.  I have modeled the data but I see
>no way to separate the model so I can build it in separate db's and
>each of the models needs the data in the global model for the project
>to build.
>
>My question is how would you go about handling this situation?
>
>Any help would be most appreciated.
>
>Judie

I've never seen Visual Studio whateveritis so I can only ask the obvious
question.

Do they have to be separate databases, or could it be just the
applications that are spread around the departments ? Or would that give
you performance problems ?

   John
--
John G Harris

Hi all,

I am new to the world of ORM and am building my first ORM model but
have run into a glitch that I am unsure how to handle.  We are
currently in the process of rearchitecting all of our outdated
systems.  A good portion of the data is shared amongst all of the
different departments and has to this point been copied from system
to system on a monthly basis.  Our goal is to create a global db for
the shared data and individual ones for each application containing
only the data that is not global.  I have modeled the data but I see
no way to separate the model so I can build it in separate db's and
each of the models needs the data in the global model for the project
to build.

My question is how would you go about handling this situation?

Any help would be most appreciated.

Judie

>THE 6th INTERNATIONAL BUSINESS RULES FORUM CONFERENCE

>Opryland Resort and Convention Center, Nashville, TN

In your next revision of this international announcement please say that
the conference is in the USA, and expand the parochial acronym TN into
Tennessee. After all, TN is the internet domain name for Tunisia.

>or phone us at (877) 604-8622

It's better to write this as  +1 877 604 8622  to save people having to
look up the international code, and to save them looking for a
non-existent "-" button.

Remember, in business rules, as in ORM, you need to speak the customer's
language :-)

   John

THE 6th INTERNATIONAL BUSINESS RULES FORUM CONFERENCE
November 2-6, 2003
Opryland Resort and Convention Center, Nashville, TN
http://www.BusinessRulesForum.com


Find out why so many companies are turning to the Business Rules
Approach!

* Insurance ... Rules for underwriting, rating, regulatory compliance.
* Financial Services ... Rules for loan or mortgage application
   processing, on-line banking and brokering, real-time compliance.
* Governments ... Rules for licensing, registration, human services,
   taxation.
* Pharmaceuticals, Telecom, Energy, Software Companies .. and many
   more!

Plan to attend now.  Last year's Conference was a resounding success.
You'll come away from the Forum with a host of practical ideas you can
put to immediate use for your company. This Forum will help you
succeed!

Co-chaired by two of the world's leading experts in Business Rules:
- Ronald G. Ross, Business Rule Solutions, LLC
- Terry Moriarty, Inastrol

This year will feature an all new, expanded Conference with more
tutorials, speakers and real-life case studies than ever before. Have
a quick look at our schedule by selecting the Conference Schedule
button on the conference home page
http://www.businessrulesforum.com/business_rules_forum.htm.

All the major areas of the Business Rules Approach will be addressed:

* Building agile, flexible applications amenable to change.
* Using rules for real-time compliance and massive personalization.
* Where Business Rules fit in with Model-Driven Architecture (MDA).
* Integrating Business Rules into object-oriented applications using
   RUP.
* Creating a more adaptive business environment.
* Developing smart processes.
* How other companies are using the Business Rules Approach to stay
   competitive.
* Applying Business Rules to eCommerce.
* Real-life experiences with business rule mining and harvesting.
* How other companies have approached business rule management.
* Tools and techniques available from vendors.

~ Product Derby Redux!!!

Last year's Product Derby was the hit of the Forum. Join us on
Monday night, as the conference's four top sponsors (Fair Isaac,
Sapiens, Expert Solutions International (ESI) and Pegasystems) square
off showing their solutions to the same case study.

~ Standards Organizations to Meet Again at the Forum.

The OMG Business Rules SIG and the Business Rules Group are holding
a joint work session on business rule standards. Open to attendees!

This timely Conference brings together the leading gurus and
practitioners in the field to talk about what really works. Don't
miss this opportunity to find out about the most exciting area of
software development today!

Sponsored by the leading providers of Business Rule products and
services.

Diamond: Fair Isaac, Sapiens
Platinum: Expert Solutions International (ESI), Pegasystems
Gold: American Management Systems (AMS), Business Rules Solutions
(BRS), Computer Associates (CA), Computer Sciences Corporation (CSC),
Inastrol, Knowledge Partners, Inc. (KPI), RulesPower
Silver: The Haley Enterprise, Trinity Millennium Group

Industry and Media Organizations that endorse the Business Rules
Forum include...

* Intelligent Enterprise Magazine
* www.BRCommunity.com
* PC/AI Magazine

The Business Rules Forum is the international industry focal point
for Business Rules. "If you are doing Business Rules, you can't
afford to not be at this Conference!"

TO REGISTER ...
Visit http://www.BusinessRulesForum.com
or phone us at (877) 604-8622

SEE YOU AT THE FORUM!

Patrick,

	 Thanks for your kind reply. Just a clarification. A modification to
one of this "temporal tables" does only involve an INSERT: a copy of the old
row is generated, and since the TmpId attribute is an identity column the
new row (the copy) will have a different TmpId. All the other columns are
exact copies of the original row, barring the columns that are changed.
	 An example would be:

	 Sales

	 Id  TmpId  Status   Salesman  Customer  TmpStart   TmpEnd
TmpUsername TmpAppName  TmpHostname
       1   1      active   3         98        10/7/2003  9/9/9999   juang
vcciSales   ANGULAR

	 When the user 'James' makes a modification to this entity (let's say
he does it yesterday, 23/7, and he just changes the Salesman to '7'), this
row is updated, and a new row is inserted, as follows:

	 Id  TmpId  Status   Salesman  Customer  TmpStart   TmpEnd
TmpUsername TmpAppName  TmpHostname
       1   1      active   3         98        10/7/2003  22/7/2003  juang
vcciSales   ANGULAR
       1   4      active   7         98        23/7/2003  9/9/9999   james
vcciSales   ANGULAR

So, the table will have two versions of this sale, one that is valid from
10/7 to 22/7, and the other (the currently valid version) from 23/7 to
9/9/9999. One just needs to query the database for the sale where TmpEnd =
'9/9/9999' to obtain the currently valid version of any entity.

	 Likewise, when the system needs to 'delete' an entity from the
database, the actual operation is just an update to this table. Let's say
James needs to delete this same entity on 27/7. The last version (the
currently valid version) is updated as follows:

	 Id  TmpId  Status   Salesman  Customer  TmpStart   TmpEnd
TmpUsername TmpAppName  TmpHostname
       1   4      active   7         98        23/7/2003  27/7/2003  james
vcciSales   ANGULAR

	 Anyways, your suggestion about independent history tables sounds
more and more attractive everytime I delve into the problem. Mine was just a
shot in the dark, maybe someone had some sort of arrangement designed in ORM
applicable to this case.

Thanks again,
Juan


>
> -----Original Message-----
> From: Patrick Hallock [mailto:path@...]
> Sent: Miércoles, 23 de Julio de 2003 12:22 a.m.
> To: jcm@yahoogroups.com
>
> Juan,
>
> I had to go back and the article. It is a bit late and I want to think
> about this again, so maybe a better answer tomorrow.
>
> However, I notice that one solution keeps changing the values in the
> primary key for each version. This makes me nervous in two ways. 1) A
> general rule of keeping the values in a primary key very stable. 2)
> Changing the key usually results in some sort of cascade update or
> confusion when moving data to a data-mart. So, I would opt for
> maintaining the primary key and moving the original row to a history
> table. Or some complex solutions only put changed columns in a history
> table along with updating the audit data on original rows. I find it
> easier, if the number of columns is small to just keep a history table
> and move the original row there and then change the current
> row without
> changing the key. The time frame is them a set of attributes. You can
> retrieve history in the correct reverse order as needed.
> (Reverse order, newest first - oldest last)
>
> I read your note again.
>
>
> Pat
>
> Patrick Hallock
> InConcept Partner
> path@...
> Journal of Conceptual Modeling
> www.inconcept.com/jcm
>
>
> > -----Original Message-----
> > From: Juan Ignacio Gelos [mailto:juan@...]
> > Sent: Tuesday, July 22, 2003 8:54 PM
> > To: jcm@yahoogroups.com
> > Subject: [JCM] Temporal database
> >
> > Hi all,
> >
> >  I've been designing a conceptual model and its SQL Server
> database
> > through the last months.
> >  This database needs to store temporal data, in both senses: data
> > that refers to specific events that take place during time
> intervals,
> and
> > also a record of every modification made to certain entities (tables
> in
> > the
> > physical model), hence their different versions over time.
> >     Against my best wishes, I had to implement the latter using a
> "trick"
> > which is best thought at the physical level: adding to every table
> that
> > needs "record versioning" an identity column that stands
> for "version
> Id".
> > This column is then added to the primary key for that table.
> >     A typical example would be:
> >
> > Table: Sales
> > ----------------------------------------------------------
> > PK  Id            int
> > PK  TmpId         int identity
> >     Status        char(10)
> > FK1 Salesman      int
> > FK2 Customer      int
> >     TmpStart      datetime
> >     TmpEnd        datetime
> >     TmpUsername   varchar(50)
> >     TmpAppName    varchar(50)
> >     TmpHostname   varchar(50)
> >
> >
> > Table: Items
> > -----------------------------------------------------------
> > PK  Id            int
> > PK  TmpId         identity int
> > FK1 Product       int
> > FK2 SaleId        int
> > FK2 SaleTmpId     int
> >     Ordinal       int
> >     UnitPrice     money
> >     Quantity      decimal
> >     TmpStart      datetime
> >     TmpEnd        datetime
> >     TmpUsername   varchar(50)
> >     TmpAppName    varchar(50)
> >     TmpHostname   varchar(50)
> >
> >
> >  Whenever the user changes data in the Sales relation, a new
> tuple is
> > created in it, being it a new version of the old tuple, with its
> TmpEnd
> > attribute being "9/9/9999" and its TmpStart attribute being the date
> at
> > which the new version should start being valid. At the same
> time, the
> old
> > version is updated setting the TmpEnd attribute to this latter date.
> >  Both versions will have the same value for the Id attribute, but
> > their TmpId values will differ.
> >  As of yet I've had no problems with this approach, I've even
> > designed two conceptual components, following Patrick Hallock's JCM
> > article
> > "Creating Conceptual Source Components" (available at
> > http://www.inconcept.com/jcm/August2001/hallock.html). The first one
> is
> > "Temporal Id", which has an [Id] and a [TmpId], and is primarily
> > identified
> > by both. The other one is a "Temporal Record", and has a [Start], an
> [End]
> > (both are date+time's), and also a [Username], [AppName] and a
> [Hostname].
> >  Now I just need to say that an entity has a [Temporal Id] and
> also a
> > [Temporal Record] to instantly make it a "temporal entity".
> >  Now into the problem: following this approach, whenever the
> system
> > needs to produce a new version of a Sale, and since the Item entity
> has a
> > FK
> > that includes the Sale.TmpId column (which differs for every version
> of
> > any
> > single Sale), it needs to either update every Item for that Sale
> updating
> > the "SaleTmpId" record to point to the new Sale's version, or create
> new
> > versions of every Item for that Sale and make those new
> versions point
> to
> > the new Sale's version.
> >  A solution for this would be to consider the Item table (at the
> > physical level) as related to Sale only by means of the
> SaleId column.
> > This
> > would in fact make each Item point to every version of its
> corresponding
> > Sale, and we can just query the database for the currently
> valid Sale
> and
> > its related Items.
> >  At the physical level this approach will work. But I do have
> > problems with it: to begin with, I can't find a way to
> model it at the
> > conceptual model (let alone an *elegant* way to model it), since the
> > primary
> > key for Sale needs to include both Ids (Id and TmpId), and any FK
> pointing
> > to Sale would need to include them.
> >  Even at the physical level there are complications: if we remove
> the
> > SaleTmpId column from Item and go along just using SaleId, being
> unable to
> > define a foreign key causes loss of referential integrity
> enforcement.
> If
> > we
> > don't remove it and create the foreign key, we are introducing
> redundancy,
> > since we don't really use the SaleTmpId column.
> >  I realize this is the result of taking a physical shortcut to
> solve
> > a logical problem. I think this is in part justified by the lack of
> > support
> > for temporal data in the currently available database engines in the
> > market.
> >  My obvious question is: Has anyone found a better solution for
> this
> > at the conceptual level?
> >
> > Best Regards,
> > Juan Ignacio Gelos
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> >
> > ~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
> > Would you like to learn more about Object-Role Modeling (ORM)?
> >
> > Then check out InConcept's ORM Seminars!
> >
> > These seminars will focus on the use of Object-Role Modeling to
> correctly
> > model your business data requirements. Each day also contains "hands
> on"
> > labs where students practice the technique  while ORM-certified
> > instructors give one-on-one assistance.
> >
> > Custom on-site courses are also available.
> >
> > For more information, please see
> > http://www.inconcept.com/training/ormseminar.html or e-mail
> > training@....
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> >
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
> Free shipping on orders $50 or more to the US and Canada.
> http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
> http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/89EolB/TM
> --------------------------------------------------------------
> -------~->
>
> ~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
> Would you like to learn more about Object-Role Modeling (ORM)?
>
> Then check out InConcept's ORM Seminars!
>
> These seminars will focus on the use of Object-Role Modeling
> to correctly model your business data requirements. Each day
> also contains "hands on" labs where students practice the
> technique  while ORM-certified instructors give one-on-one assistance.
>
> Custom on-site courses are also available.
>
> For more information, please see
> http://www.inconcept.com/training/ormseminar.html or e-mail
> training@....
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>

Juan,

I had to go back and the article. It is a bit late and I want to think
about this again, so maybe a better answer tomorrow.

However, I notice that one solution keeps changing the values in the
primary key for each version. This makes me nervous in two ways. 1) A
general rule of keeping the values in a primary key very stable. 2)
Changing the key usually results in some sort of cascade update or
confusion when moving data to a data-mart. So, I would opt for
maintaining the primary key and moving the original row to a history
table. Or some complex solutions only put changed columns in a history
table along with updating the audit data on original rows. I find it
easier, if the number of columns is small to just keep a history table
and move the original row there and then change the current row without
changing the key. The time frame is them a set of attributes. You can
retrieve history in the correct reverse order as needed.
(Reverse order, newest first - oldest last)

I read your note again.


Pat

Patrick Hallock
InConcept Partner
path@...
Journal of Conceptual Modeling
www.inconcept.com/jcm


> -----Original Message-----
> From: Juan Ignacio Gelos [mailto:juan@...]
> Sent: Tuesday, July 22, 2003 8:54 PM
> To: jcm@yahoogroups.com
> Subject: [JCM] Temporal database
>
> Hi all,
>
>  I've been designing a conceptual model and its SQL Server
database
> through the last months.
>  This database needs to store temporal data, in both senses: data
> that refers to specific events that take place during time intervals,
and
> also a record of every modification made to certain entities (tables
in
> the
> physical model), hence their different versions over time.
>     Against my best wishes, I had to implement the latter using a
"trick"
> which is best thought at the physical level: adding to every table
that
> needs "record versioning" an identity column that stands for "version
Id".
> This column is then added to the primary key for that table.
>     A typical example would be:
>
> Table: Sales
> ----------------------------------------------------------
> PK  Id            int
> PK  TmpId         int identity
>     Status        char(10)
> FK1 Salesman      int
> FK2 Customer      int
>     TmpStart      datetime
>     TmpEnd        datetime
>     TmpUsername   varchar(50)
>     TmpAppName    varchar(50)
>     TmpHostname   varchar(50)
>
>
> Table: Items
> -----------------------------------------------------------
> PK  Id            int
> PK  TmpId         identity int
> FK1 Product       int
> FK2 SaleId        int
> FK2 SaleTmpId     int
>     Ordinal       int
>     UnitPrice     money
>     Quantity      decimal
>     TmpStart      datetime
>     TmpEnd        datetime
>     TmpUsername   varchar(50)
>     TmpAppName    varchar(50)
>     TmpHostname   varchar(50)
>
>
>  Whenever the user changes data in the Sales relation, a new
tuple is
> created in it, being it a new version of the old tuple, with its
TmpEnd
> attribute being "9/9/9999" and its TmpStart attribute being the date
at
> which the new version should start being valid. At the same time, the
old
> version is updated setting the TmpEnd attribute to this latter date.
>  Both versions will have the same value for the Id attribute, but
> their TmpId values will differ.
>  As of yet I've had no problems with this approach, I've even
> designed two conceptual components, following Patrick Hallock's JCM
> article
> "Creating Conceptual Source Components" (available at
> http://www.inconcept.com/jcm/August2001/hallock.html). The first one
is
> "Temporal Id", which has an [Id] and a [TmpId], and is primarily
> identified
> by both. The other one is a "Temporal Record", and has a [Start], an
[End]
> (both are date+time's), and also a [Username], [AppName] and a
[Hostname].
>  Now I just need to say that an entity has a [Temporal Id] and
also a
> [Temporal Record] to instantly make it a "temporal entity".
>  Now into the problem: following this approach, whenever the
system
> needs to produce a new version of a Sale, and since the Item entity
has a
> FK
> that includes the Sale.TmpId column (which differs for every version
of
> any
> single Sale), it needs to either update every Item for that Sale
updating
> the "SaleTmpId" record to point to the new Sale's version, or create
new
> versions of every Item for that Sale and make those new versions point
to
> the new Sale's version.
>  A solution for this would be to consider the Item table (at the
> physical level) as related to Sale only by means of the SaleId column.
> This
> would in fact make each Item point to every version of its
corresponding
> Sale, and we can just query the database for the currently valid Sale
and
> its related Items.
>  At the physical level this approach will work. But I do have
> problems with it: to begin with, I can't find a way to model it at the
> conceptual model (let alone an *elegant* way to model it), since the
> primary
> key for Sale needs to include both Ids (Id and TmpId), and any FK
pointing
> to Sale would need to include them.
>  Even at the physical level there are complications: if we remove
the
> SaleTmpId column from Item and go along just using SaleId, being
unable to
> define a foreign key causes loss of referential integrity enforcement.
If
> we
> don't remove it and create the foreign key, we are introducing
redundancy,
> since we don't really use the SaleTmpId column.
>  I realize this is the result of taking a physical shortcut to
solve
> a logical problem. I think this is in part justified by the lack of
> support
> for temporal data in the currently available database engines in the
> market.
>  My obvious question is: Has anyone found a better solution for
this
> at the conceptual level?
>
> Best Regards,
> Juan Ignacio Gelos
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> ~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
> Would you like to learn more about Object-Role Modeling (ORM)?
>
> Then check out InConcept's ORM Seminars!
>
> These seminars will focus on the use of Object-Role Modeling to
correctly
> model your business data requirements. Each day also contains "hands
on"
> labs where students practice the technique  while ORM-certified
> instructors give one-on-one assistance.
>
> Custom on-site courses are also available.
>
> For more information, please see
> http://www.inconcept.com/training/ormseminar.html or e-mail
> training@....
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>

Hi all,

	 I've been designing a conceptual model and its SQL Server database
through the last months.
	 This database needs to store temporal data, in both senses: data
that refers to specific events that take place during time intervals, and
also a record of every modification made to certain entities (tables in the
physical model), hence their different versions over time.
     Against my best wishes, I had to implement the latter using a "trick"
which is best thought at the physical level: adding to every table that
needs "record versioning" an identity column that stands for "version Id".
This column is then added to the primary key for that table.
     A typical example would be:

Table: Sales
----------------------------------------------------------
PK  Id            int
PK  TmpId         int identity
     Status        char(10)
FK1 Salesman      int
FK2 Customer      int
     TmpStart      datetime
     TmpEnd        datetime
     TmpUsername   varchar(50)
     TmpAppName    varchar(50)
     TmpHostname   varchar(50)


Table: Items
-----------------------------------------------------------
PK  Id            int
PK  TmpId         identity int
FK1 Product       int
FK2 SaleId        int
FK2 SaleTmpId     int
     Ordinal       int
     UnitPrice     money
     Quantity      decimal
     TmpStart      datetime
     TmpEnd        datetime
     TmpUsername   varchar(50)
     TmpAppName    varchar(50)
     TmpHostname   varchar(50)


	 Whenever the user changes data in the Sales relation, a new tuple is
created in it, being it a new version of the old tuple, with its TmpEnd
attribute being "9/9/9999" and its TmpStart attribute being the date at
which the new version should start being valid. At the same time, the old
version is updated setting the TmpEnd attribute to this latter date.
	 Both versions will have the same value for the Id attribute, but
their TmpId values will differ.
	 As of yet I've had no problems with this approach, I've even
designed two conceptual components, following Patrick Hallock's JCM article
"Creating Conceptual Source Components" (available at
http://www.inconcept.com/jcm/August2001/hallock.html). The first one is
"Temporal Id", which has an [Id] and a [TmpId], and is primarily identified
by both. The other one is a "Temporal Record", and has a [Start], an [End]
(both are date+time's), and also a [Username], [AppName] and a [Hostname].
	 Now I just need to say that an entity has a [Temporal Id] and also a
[Temporal Record] to instantly make it a "temporal entity".
	 Now into the problem: following this approach, whenever the system
needs to produce a new version of a Sale, and since the Item entity has a FK
that includes the Sale.TmpId column (which differs for every version of any
single Sale), it needs to either update every Item for that Sale updating
the "SaleTmpId" record to point to the new Sale's version, or create new
versions of every Item for that Sale and make those new versions point to
the new Sale's version.
	 A solution for this would be to consider the Item table (at the
physical level) as related to Sale only by means of the SaleId column. This
would in fact make each Item point to every version of its corresponding
Sale, and we can just query the database for the currently valid Sale and
its related Items.
	 At the physical level this approach will work. But I do have
problems with it: to begin with, I can't find a way to model it at the
conceptual model (let alone an *elegant* way to model it), since the primary
key for Sale needs to include both Ids (Id and TmpId), and any FK pointing
to Sale would need to include them.
	 Even at the physical level there are complications: if we remove the
SaleTmpId column from Item and go along just using SaleId, being unable to
define a foreign key causes loss of referential integrity enforcement. If we
don't remove it and create the foreign key, we are introducing redundancy,
since we don't really use the SaleTmpId column.
	 I realize this is the result of taking a physical shortcut to solve
a logical problem. I think this is in part justified by the lack of support
for temporal data in the currently available database engines in the market.
	 My obvious question is: Has anyone found a better solution for this
at the conceptual level?

Best Regards,
Juan Ignacio Gelos

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 6/25/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 6/25/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 6/25/2003

-----Original Message-----
From: Andy Carver [mailto:andy.carver@...]
Sent: Thursday, July 03, 2003 10:29 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Thanks for this clear and helpful explanation Terry.

 

But I have a new question, re the "warnings": Won't a nested, non-full-UC-spanned object type and any predicates in which it plays roles still represent an elementary fact type, if and when it plays only mandatory roles that are in predicates with fully spanning UCs? If so, won't the warning have to be merely that the nested object MAY ENGENDER non-elementary fact types? or else appear when the above condition doesn't hold?

 

Cheers,

Andy

-----Original Message-----
From: Terry Halpin [mailto:terry@...]
Sent: Tuesday, July 01, 2003 5:40 PM
To: jcm@yahoogroups.com
Cc: 'TERENCE HALPIN'
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

With the new ORM metamodel we are constructing for the public domain, I have relaxed the requirement that nested associations have spanning UCs, even when they are not 1:1 associations.

    I will discuss this in detail in the next issue of the JCM, but here is a brief summary of my position. The following rule may be regarded as an extension of my relaxation to allow nesting of 1:1 fact types (to avoid non-conceptual choices of relative importance, e.g. husband over wife)

 

If an n-ary association has at least two UCs spanning n-1 roles

then it may be nested with a gentle reminder that the fact type is not elementary

else it may be nested with a warning that the fact type is not elementary and is probably better modeled by splitting it into separate fact types.

 

 <snip>

 

 The main disadvantages are

(1) The fact type is non-elementary, so pre-processing is needed for mapping to normalized relational schemas

(2) In cases where there are not two candidate keys, it is usually just bad modeling (e.g. my orbital example).

 

 <snip>

 

 Terry

 

<snip>

~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to correctly model your business data requirements. Each day also contains "hands on" labs where students practice the technique  while ORM-certified instructors give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see http://www.inconcept.com/training/ormseminar.html or e-mail training@....

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 6/25/2003

-----Original Message-----
From: Terry Halpin [mailto:terry@...]
Sent: Tuesday, July 01, 2003 5:40 PM
To: jcm@yahoogroups.com
Cc: 'TERENCE HALPIN'
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

With the new ORM metamodel we are constructing for the public domain, I have relaxed the requirement that nested associations have spanning UCs, even when they are not 1:1 associations.

    I will discuss this in detail in the next issue of the JCM, but here is a brief summary of my position. The following rule may be regarded as an extension of my relaxation to allow nesting of 1:1 fact types (to avoid non-conceptual choices of relative importance, e.g. husband over wife)

 

If an n-ary association has at least two UCs spanning n-1 roles

then it may be nested with a gentle reminder that the fact type is not elementary

else it may be nested with a warning that the fact type is not elementary and is probably better modeled by splitting it into separate fact types.

 

 <snip>

 

 The main disadvantages are

(1) The fact type is non-elementary, so pre-processing is needed for mapping to normalized relational schemas

(2) In cases where there are not two candidate keys, it is usually just bad modeling (e.g. my orbital example).

 

 <snip>

 

 Terry

 

<snip>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 6/25/2003

Hi Pat,

 

Please see my responses in-line (with no unintended profanities, I hope):

-----Original Message-----
From: Patrick Hallock [mailto:path@...]
Sent: Friday, June 27, 2003 6:15 PM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Andy,

Terry has taken that position in the past and had good reasons for doing so. However, I believe he has changed his mind about this.

Yes, people do change their minds, hopefully for the better. 

 

But is it for the better here? :-) 

 

Here is the way we have thought about it. Ternary ABC with two roles spanned say A & B means:

A table will be formed with the name ABC and AB is the primary key. C is a column and in my mind it is mandatory that column C holds data, else it is not a ternary. Given that: If I then say ABC has D with the constraint on ABC, the D also becomes a column in table ABC. It may be mandatory or optional. Why bother? Sometimes the ternary is a much better semantic expression of what you need to say. It is not nice to force a restatement of the fact into smaller pieces only because nesting is involved. This has been a pain the side for years (John obviously agrees). Now is C was optional – then a ternary would not be correct in the first place. The population of only two roles would cause an incomplete sentence which is not allowed. . 

 

That's an extremely clear explanation. Thanks. 

 

Not a technical argument, but has caused us extra work to redo ternary semantics when the fact ABC-D happens.

RMAP would have to change – but it needs fixing for other things as well. I do not think it is in the thinking, but in the implementation where the errors occur - software bugs). 

 

I probably didn't make that point clear enough, so now please read the Word doc I have attached! 

 

Well Andy how the view from the window? All I am getting here is rain – I think I have moved to the Pacific Northwest.

I see Terry is in the homeland for a break. 

 

The view is superb! But Terry went to Austria, not Australia (I'm sure he would have preferred the latter). 

 

Regards,

Andy

 

Pat

 

 

 

 

Patrick Hallock

InConcept Partner

path@...

Journal of Conceptual Modeling

www.inconcept.com/jcm

 

-----Original Message-----
From: Andy Carver [mailto:andy.carver@...]
Sent: Friday, June 27, 2003 6:47 PM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

 

Hi John,

 

Yes I was missing something, thanks for your clear and very helpful explanation. I will have to add "stability" to the possible positives of allowing non-spanning UCs in nested objects.

 

However (and I'd like feedback from anybody on this), I'm still not convinced that the positives outweigh the serious negatives, which T.A.H. mentions--though quite briefly--in his article at http://orm.net/pdf/ElemFact.pdf , particularly on pp. 3, 6, 8, and 9.  For example, the sheer complexity (and thus hidden pitfalls) that this would introduce into Rmap, as well as model transformation and optimization, is not pleasant to think about. Terry notes (p. 9): "The mapping is now complicated. Before passing the schema to the normal mapping algorith, it will have to be pre-processed [to a version where all fact types are elementary, and thus, where all nested objects have spanning UCs] ... Note that if a role played by an objectified functional predicate is optional, it may be necessary to include in the pre-processing an appropriate subset or subtype constraint." If you don't know what he means by this last sentence, play around with examples: believe me, things can get horribly complicated; and they couldn't be automated, you'd have to do it manually (to get the desired semantics), a process which (I think) non-expert modelers would m_ff up quite frequently.  IMHO, a loss of some "stability" (and really, I'm not sure you don't lose as much "stability" as you gain, cf. p. 3) would be a small price to pay to avoid the massive added complexity and inevitable mistakes inherent in such a rule-change.

 

Furthermore, I think ORM would lose something of what essentially distinguishes it from ER, UML, etc.: all fact structures are elementary. If you give up your essential distinguishing characteristic, I don't think you can win, in the long run, against the opposing position. If anyone is not clear on why and how fact-structure elementarity is compromised by allowing non-spanning UCs in NOs, read the above article carefully, especially p. 6.

 

Again, I would love some feedback.  Thanks much, John.

 

Cheers,

Andy

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 3:23 PM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Andy,

 

Here is Chris' original invalid model:

 

http://www.pdata.com/wikifiles/images/orm1.jpg

 

Here is my proposed solution:

 

http://www.pdata.com/wikifiles/images/orm2.jpg

 

If the requirements change to require more than one payment method for a given Account and Effective From Date (a full spanning UC on the original ternary) this poses a problem for my solution because the Effective To Date needs to apply to a unique Account, Payment Method, Effective From Date combination.  You would either need to change my proposed solution to something like:

 

http://www.pdata.com/wikifiles/images/orm3.jpg

 

Or revert back to the original ternary:

 

http://www.pdata.com/wikifiles/images/orm4.jpg

 

Either way, the model is not nearly as stable as it would have been if Chris could nest the original ternary and simply change the constraint to a full spanning UC.

 

jMM'.

-----Original Message-----
From: Andy Carver [mailto:andy.carver@...]
Sent: Friday, June 27, 2003 11:31 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

>>question in-line below:

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 10:38 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Chris,

I've argued that the full spanning UC requirement for nesting
unnecessarily contributes to the instability of the model and your
scenario is another example.

If you reduce your ternary to the binary:

[ Account ] is subject to payment method from [ Payment Method Effective
>From Date ]

With a full spanning UC and nested as: [ "Account Payment Method" ]

You can then state:

[ "Account Payment Method" ] has [ Payment Method ]

And

[ "Account Payment Method" ] is effective to [ Payment Method Effective
To Date ]

While not as clear as your approach, it will pass validation. However if
the model ever requires the full spanning UC over the ternary you would
have to change the model back to your approach.  This is what I mean by
unstable. 

 

>>That's an interesting claim, but I don't really see why it would be necessary to "change the model back". If the Account and Date no longer together functionally determine the Payment Method, there's no single thing that has an End Date, so the issue doesn't even arise. Or am I missing something? If so, please point it out, because I am very interested in this issue of UCs spanning nested objects and the arguments for and against.

Regards,

Andy 

jMM'.

 

~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to correctly model your business data requirements. Each day also contains "hands on" labs where students practice the technique  while ORM-certified instructors give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see http://www.inconcept.com/training/ormseminar.html or e-mail training@....

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 6/25/2003

-----Original Message-----
From: Patrick Hallock [mailto:path@...]
Sent: Friday, June 27, 2003 6:15 PM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Andy,

Terry has taken that position in the past and had good reasons for doing so. However, I believe he has changed his mind about this.

Yes, people do change their minds, hopefully for the better. 

 

But is it for the better here? :-) 

 

Here is the way we have thought about it. Ternary ABC with two roles spanned say A & B means:

A table will be formed with the name ABC and AB is the primary key. C is a column and in my mind it is mandatory that column C holds data, else it is not a ternary. Given that: If I then say ABC has D with the constraint on ABC, the D also becomes a column in table ABC. It may be mandatory or optional. Why bother? Sometimes the ternary is a much better semantic expression of what you need to say. It is not nice to force a restatement of the fact into smaller pieces only because nesting is involved. This has been a pain the side for years (John obviously agrees). Now is C was optional – then a ternary would not be correct in the first place. The population of only two roles would cause an incomplete sentence which is not allowed. . 

 

That's an extremely clear explanation. Thanks. 

 

Not a technical argument, but has caused us extra work to redo ternary semantics when the fact ABC-D happens.

RMAP would have to change – but it needs fixing for other things as well. I do not think it is in the thinking, but in the implementation where the errors occur - software bugs). 

 

I probably didn't make that point clear enough, so now please read the Word doc I have attached! 

 

Well Andy how the view from the window? All I am getting here is rain – I think I have moved to the Pacific Northwest.

I see Terry is in the homeland for a break. 

 

The view is superb! But Terry went to Austria, not Australia (I'm sure he would have preferred the latter). 

 

Regards,

Andy

 

Pat

 

 

 

 

Patrick Hallock

InConcept Partner

path@...

Journal of Conceptual Modeling

www.inconcept.com/jcm

 

-----Original Message-----
From: Andy Carver [mailto:andy.carver@...]
Sent: Friday, June 27, 2003 6:47 PM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

 

Hi John,

 

Yes I was missing something, thanks for your clear and very helpful explanation. I will have to add "stability" to the possible positives of allowing non-spanning UCs in nested objects.

 

However (and I'd like feedback from anybody on this), I'm still not convinced that the positives outweigh the serious negatives, which T.A.H. mentions--though quite briefly--in his article at http://orm.net/pdf/ElemFact.pdf , particularly on pp. 3, 6, 8, and 9.  For example, the sheer complexity (and thus hidden pitfalls) that this would introduce into Rmap, as well as model transformation and optimization, is not pleasant to think about. Terry notes (p. 9): "The mapping is now complicated. Before passing the schema to the normal mapping algorith, it will have to be pre-processed [to a version where all fact types are elementary, and thus, where all nested objects have spanning UCs] ... Note that if a role played by an objectified functional predicate is optional, it may be necessary to include in the pre-processing an appropriate subset or subtype constraint." If you don't know what he means by this last sentence, play around with examples: believe me, things can get horribly complicated; and they couldn't be automated, you'd have to do it manually (to get the desired semantics), a process which (I think) non-expert modelers would m_ff up quite frequently.  IMHO, a loss of some "stability" (and really, I'm not sure you don't lose as much "stability" as you gain, cf. p. 3) would be a small price to pay to avoid the massive added complexity and inevitable mistakes inherent in such a rule-change.

 

Furthermore, I think ORM would lose something of what essentially distinguishes it from ER, UML, etc.: all fact structures are elementary. If you give up your essential distinguishing characteristic, I don't think you can win, in the long run, against the opposing position. If anyone is not clear on why and how fact-structure elementarity is compromised by allowing non-spanning UCs in NOs, read the above article carefully, especially p. 6.

 

Again, I would love some feedback.  Thanks much, John.

 

Cheers,

Andy

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 3:23 PM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Andy,

 

Here is Chris' original invalid model:

 

http://www.pdata.com/wikifiles/images/orm1.jpg

 

Here is my proposed solution:

 

http://www.pdata.com/wikifiles/images/orm2.jpg

 

If the requirements change to require more than one payment method for a given Account and Effective From Date (a full spanning UC on the original ternary) this poses a problem for my solution because the Effective To Date needs to apply to a unique Account, Payment Method, Effective From Date combination.  You would either need to change my proposed solution to something like:

 

http://www.pdata.com/wikifiles/images/orm3.jpg

 

Or revert back to the original ternary:

 

http://www.pdata.com/wikifiles/images/orm4.jpg

 

Either way, the model is not nearly as stable as it would have been if Chris could nest the original ternary and simply change the constraint to a full spanning UC.

 

jMM'.

-----Original Message-----
From: Andy Carver [mailto:andy.carver@...]
Sent: Friday, June 27, 2003 11:31 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

>>question in-line below:

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 10:38 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Chris,

I've argued that the full spanning UC requirement for nesting
unnecessarily contributes to the instability of the model and your
scenario is another example.

If you reduce your ternary to the binary:

[ Account ] is subject to payment method from [ Payment Method Effective
>From Date ]

With a full spanning UC and nested as: [ "Account Payment Method" ]

You can then state:

[ "Account Payment Method" ] has [ Payment Method ]

And

[ "Account Payment Method" ] is effective to [ Payment Method Effective
To Date ]

While not as clear as your approach, it will pass validation. However if
the model ever requires the full spanning UC over the ternary you would
have to change the model back to your approach.  This is what I mean by
unstable. 

 

>>That's an interesting claim, but I don't really see why it would be necessary to "change the model back". If the Account and Date no longer together functionally determine the Payment Method, there's no single thing that has an End Date, so the issue doesn't even arise. Or am I missing something? If so, please point it out, because I am very interested in this issue of UCs spanning nested objects and the arguments for and against.

Regards,

Andy 

jMM'.

 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 6/25/2003

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 3:23 PM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Andy,

 

Here is Chris' original invalid model:

 

http://www.pdata.com/wikifiles/images/orm1.jpg

 

Here is my proposed solution:

 

http://www.pdata.com/wikifiles/images/orm2.jpg

 

If the requirements change to require more than one payment method for a given Account and Effective From Date (a full spanning UC on the original ternary) this poses a problem for my solution because the Effective To Date needs to apply to a unique Account, Payment Method, Effective From Date combination.  You would either need to change my proposed solution to something like:

 

http://www.pdata.com/wikifiles/images/orm3.jpg

 

Or revert back to the original ternary:

 

http://www.pdata.com/wikifiles/images/orm4.jpg

 

Either way, the model is not nearly as stable as it would have been if Chris could nest the original ternary and simply change the constraint to a full spanning UC.

 

jMM'.

-----Original Message-----
From: Andy Carver [mailto:andy.carver@...]
Sent: Friday, June 27, 2003 11:31 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

>>question in-line below:

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 10:38 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Chris,

I've argued that the full spanning UC requirement for nesting
unnecessarily contributes to the instability of the model and your
scenario is another example.

If you reduce your ternary to the binary:

[ Account ] is subject to payment method from [ Payment Method Effective
>From Date ]

With a full spanning UC and nested as: [ "Account Payment Method" ]

You can then state:

[ "Account Payment Method" ] has [ Payment Method ]

And

[ "Account Payment Method" ] is effective to [ Payment Method Effective
To Date ]

While not as clear as your approach, it will pass validation. However if
the model ever requires the full spanning UC over the ternary you would
have to change the model back to your approach.  This is what I mean by
unstable. 

 

>>That's an interesting claim, but I don't really see why it would be necessary to "change the model back". If the Account and Date no longer together functionally determine the Payment Method, there's no single thing that has an End Date, so the issue doesn't even arise. Or am I missing something? If so, please point it out, because I am very interested in this issue of UCs spanning nested objects and the arguments for and against.

Regards,

Andy 

jMM'.

~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to correctly model your business data requirements. Each day also contains "hands on" labs where students practice the technique  while ORM-certified instructors give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see http://www.inconcept.com/training/ormseminar.html or e-mail training@....

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 3:23 PM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Andy,

 

Here is Chris' original invalid model:

 

http://www.pdata.com/wikifiles/images/orm1.jpg

 

Here is my proposed solution:

 

http://www.pdata.com/wikifiles/images/orm2.jpg

 

If the requirements change to require more than one payment method for a given Account and Effective From Date (a full spanning UC on the original ternary) this poses a problem for my solution because the Effective To Date needs to apply to a unique Account, Payment Method, Effective From Date combination.  You would either need to change my proposed solution to something like:

 

http://www.pdata.com/wikifiles/images/orm3.jpg

 

Or revert back to the original ternary:

 

http://www.pdata.com/wikifiles/images/orm4.jpg

 

Either way, the model is not nearly as stable as it would have been if Chris could nest the original ternary and simply change the constraint to a full spanning UC.

 

jMM'.

-----Original Message-----
From: Andy Carver [mailto:andy.carver@...]
Sent: Friday, June 27, 2003 11:31 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

>>question in-line below:

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 10:38 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Chris,

I've argued that the full spanning UC requirement for nesting
unnecessarily contributes to the instability of the model and your
scenario is another example.

If you reduce your ternary to the binary:

[ Account ] is subject to payment method from [ Payment Method Effective
>From Date ]

With a full spanning UC and nested as: [ "Account Payment Method" ]

You can then state:

[ "Account Payment Method" ] has [ Payment Method ]

And

[ "Account Payment Method" ] is effective to [ Payment Method Effective
To Date ]

While not as clear as your approach, it will pass validation. However if
the model ever requires the full spanning UC over the ternary you would
have to change the model back to your approach.  This is what I mean by
unstable. 

 

>>That's an interesting claim, but I don't really see why it would be necessary to "change the model back". If the Account and Date no longer together functionally determine the Payment Method, there's no single thing that has an End Date, so the issue doesn't even arise. Or am I missing something? If so, please point it out, because I am very interested in this issue of UCs spanning nested objects and the arguments for and against.

Regards,

Andy 

jMM'.

~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to correctly model your business data requirements. Each day also contains "hands on" labs where students practice the technique  while ORM-certified instructors give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see http://www.inconcept.com/training/ormseminar.html or e-mail training@....

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 3:23 PM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Andy,

 

Here is Chris' original invalid model:

 

http://www.pdata.com/wikifiles/images/orm1.jpg

 

Here is my proposed solution:

 

http://www.pdata.com/wikifiles/images/orm2.jpg

 

If the requirements change to require more than one payment method for a given Account and Effective From Date (a full spanning UC on the original ternary) this poses a problem for my solution because the Effective To Date needs to apply to a unique Account, Payment Method, Effective From Date combination.  You would either need to change my proposed solution to something like:

 

http://www.pdata.com/wikifiles/images/orm3.jpg

 

Or revert back to the original ternary:

 

http://www.pdata.com/wikifiles/images/orm4.jpg

 

Either way, the model is not nearly as stable as it would have been if Chris could nest the original ternary and simply change the constraint to a full spanning UC.

 

jMM'.

-----Original Message-----
From: Andy Carver [mailto:andy.carver@...]
Sent: Friday, June 27, 2003 11:31 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

>>question in-line below:

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 10:38 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Chris,

I've argued that the full spanning UC requirement for nesting
unnecessarily contributes to the instability of the model and your
scenario is another example.

If you reduce your ternary to the binary:

[ Account ] is subject to payment method from [ Payment Method Effective
>From Date ]

With a full spanning UC and nested as: [ "Account Payment Method" ]

You can then state:

[ "Account Payment Method" ] has [ Payment Method ]

And

[ "Account Payment Method" ] is effective to [ Payment Method Effective
To Date ]

While not as clear as your approach, it will pass validation. However if
the model ever requires the full spanning UC over the ternary you would
have to change the model back to your approach.  This is what I mean by
unstable. 

 

>>That's an interesting claim, but I don't really see why it would be necessary to "change the model back". If the Account and Date no longer together functionally determine the Payment Method, there's no single thing that has an End Date, so the issue doesn't even arise. Or am I missing something? If so, please point it out, because I am very interested in this issue of UCs spanning nested objects and the arguments for and against.

Regards,

Andy 

jMM'.

~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to correctly model your business data requirements. Each day also contains "hands on" labs where students practice the technique  while ORM-certified instructors give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see http://www.inconcept.com/training/ormseminar.html or e-mail training@....

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

Hi Pat,

It's stable if you model only with binaries.

jMM'.


-----Original Message-----
From: Patrick Hallock [mailto:path@...]
Sent: Friday, June 27, 2003 3:18 PM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested
ternaries with temporal aspects


Sometime the ternary do get broken down because of the current rule.
That rule will change in the future. However, now you have set of
binaries and no ternary as suggest below. If the span goes to all three
you do not have to recreate the ternary - you merely change the
constraint from making the key from two roles to three roles. It is not
required to change anything else. For the old timers, prior to having
any fact greater than a binary we had to do this all the time. The
ternary can always be broken down into a set of binaries connected to
the new object as suggested (This new Object is the name for the ternary
anyway.) Normally you would say the primary reference mode is two of the
three binaries. But, again to change it to three binaries participating
in the primary identifier does not required a restatement of the facts,
you only change the external primary constraint. Thus it is stable.

Pat

Patrick Hallock
InConcept Partner
path@...
Journal of Conceptual Modeling
www.inconcept.com/jcm


> -----Original Message-----
> From: John Miller [mailto:jMiller@...]
> Sent: Friday, June 27, 2003 11:38 AM
> To: jcm@yahoogroups.com
> Subject: RE: [JCM] Problem with mandated full span UC on nested
ternaries
> with temporal aspects
>
>
> Hi Chris,
>
> I've argued that the full spanning UC requirement for nesting
> unnecessarily contributes to the instability of the model and your
> scenario is another example.
>
> If you reduce your ternary to the binary:
>
> [ Account ] is subject to payment method from [ Payment Method
Effective
> >From Date ]
>
> With a full spanning UC and nested as: [ "Account Payment Method" ]
>
> You can then state:
>
> [ "Account Payment Method" ] has [ Payment Method ]
>
> And
>
> [ "Account Payment Method" ] is effective to [ Payment Method
Effective
> To Date ]
>
> While not as clear as your approach, it will pass validation. However
if
> the model ever requires the full spanning UC over the ternary you
would
> have to change the model back to your approach.  This is what I mean
by
> unstable.
>
> jMM'.
>
>
> -----Original Message-----
> From: Chris Bruce [mailto:chris@...]
> Sent: Friday, June 27, 2003 1:29 AM
> To: jcm@yahoogroups.com
> Subject: [JCM] Problem with mandated full span UC on nested ternaries
> with temporal aspects
>
>
> Hi,
>
> The general principle of a full span UC on nested facts I'm happy
with.
> However I've come across a problem when the fact is representing
> temporal constraints.
>
> [ Account ] is subject to a [ Payment Method ] from a [ Payment Method

> Effective From Date ]
>
> The UC is over the first and last roles giving
>
> Given any [ Account ] and [ Payment Method Effective From Date ] that
> Account ] is subject to at most one [ Payment Method ] from that [
> Payment Method Effective From Date ]
>
> The fact is stating the rule that only one Payment Method is allowed
for
> an Account at any one time.
>
> I want to delimit the Payment Method so I nest the fact as "Account
> Payment Method" and incorporate in another fact
>
> [ "Account Payment Method" ] is effective to [ Payment Method
Effective
> To Date ]
>
> With the UC over the first role...
> [ "Account Payment Method" ] is effective to at most one [ Payment
> Method Effective To Date ]
>
> The fact that I've nested the fact means I should have a full span UC
> but if I do I can no longer represent the business requirement in the
> fact: the "at most one Payment Method" constraint is lost. (I could
put
> a secondary UC over the first and last roles but this seems a cheat!)
>
> The Payment Method Effective To Date is not known at the time an
> instance of the fact is recorded so I can't make it a quaternary.
>
> The Account may have the same Payment Method on more than one occasion

> so I can't make it a binary.
>
> This seems to cause me problems every time I introduce temporal
aspects
> to facts. I know that the full span is always implied so have I really

> got a problem - except that I get an error validating the model if I
> don't have an explicit one? (I'm using VisioModeler.)
>
> I suppose the Effective to Date could be derived, but only if there
was
> a subsequent changed Payment Method. If the Account was terminated
it'd
> have to be derived from the Account Termination Date.
>
> Have I lost the plot?
>
> I believe the facts are elementary.
>
> Comments, suggestions etc. all very welcome.
>
> TIA..
>
> Chris Bruce
>
>
>
>
>
> ~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
> Would you like to learn more about Object-Role Modeling (ORM)?
>
> Then check out InConcept's ORM Seminars!
>
> These seminars will focus on the use of Object-Role Modeling to
> correctly model your business data requirements. Each day also
contains
> "hands on" labs where students practice the technique  while
> ORM-certified instructors give one-on-one assistance.
>
> Custom on-site courses are also available.
>
> For more information, please see
> http://www.inconcept.com/training/ormseminar.html or e-mail
> training@....
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> ~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
> Would you like to learn more about Object-Role Modeling (ORM)?
>
> Then check out InConcept's ORM Seminars!
>
> These seminars will focus on the use of Object-Role Modeling to
correctly
> model your business data requirements. Each day also contains "hands
on"
> labs where students practice the technique  while ORM-certified
> instructors give one-on-one assistance.
>
> Custom on-site courses are also available.
>
> For more information, please see
> http://www.inconcept.com/training/ormseminar.html or e-mail
> training@....
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>





~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to
correctly model your business data requirements. Each day also contains
"hands on" labs where students practice the technique  while
ORM-certified instructors give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see
http://www.inconcept.com/training/ormseminar.html or e-mail
training@....

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

-----Original Message-----
From: Andy Carver [mailto:andy.carver@...]
Sent: Friday, June 27, 2003 11:31 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

>>question in-line below:

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 10:38 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Chris,

I've argued that the full spanning UC requirement for nesting
unnecessarily contributes to the instability of the model and your
scenario is another example.

If you reduce your ternary to the binary:

[ Account ] is subject to payment method from [ Payment Method Effective
>From Date ]

With a full spanning UC and nested as: [ "Account Payment Method" ]

You can then state:

[ "Account Payment Method" ] has [ Payment Method ]

And

[ "Account Payment Method" ] is effective to [ Payment Method Effective
To Date ]

While not as clear as your approach, it will pass validation. However if
the model ever requires the full spanning UC over the ternary you would
have to change the model back to your approach.  This is what I mean by
unstable. 

 

>>That's an interesting claim, but I don't really see why it would be necessary to "change the model back". If the Account and Date no longer together functionally determine the Payment Method, there's no single thing that has an End Date, so the issue doesn't even arise. Or am I missing something? If so, please point it out, because I am very interested in this issue of UCs spanning nested objects and the arguments for and against.

Regards,

Andy 

jMM'.

Sometime the ternary do get broken down because of the current rule.
That rule will change in the future. However, now you have set of
binaries and no ternary as suggest below. If the span goes to all three
you do not have to recreate the ternary - you merely change the
constraint from making the key from two roles to three roles. It is not
required to change anything else.
For the old timers, prior to having any fact greater than a binary we
had to do this all the time. The ternary can always be broken down into
a set of binaries connected to the new object as suggested (This new
Object is the name for the ternary anyway.) Normally you would say the
primary reference mode is two of the three binaries. But, again to
change it to three binaries participating in the primary identifier does
not required a restatement of the facts, you only change the external
primary constraint. Thus it is stable.

Pat

Patrick Hallock
InConcept Partner
path@...
Journal of Conceptual Modeling
www.inconcept.com/jcm


> -----Original Message-----
> From: John Miller [mailto:jMiller@...]
> Sent: Friday, June 27, 2003 11:38 AM
> To: jcm@yahoogroups.com
> Subject: RE: [JCM] Problem with mandated full span UC on nested
ternaries
> with temporal aspects
>
>
> Hi Chris,
>
> I've argued that the full spanning UC requirement for nesting
> unnecessarily contributes to the instability of the model and your
> scenario is another example.
>
> If you reduce your ternary to the binary:
>
> [ Account ] is subject to payment method from [ Payment Method
Effective
> >From Date ]
>
> With a full spanning UC and nested as: [ "Account Payment Method" ]
>
> You can then state:
>
> [ "Account Payment Method" ] has [ Payment Method ]
>
> And
>
> [ "Account Payment Method" ] is effective to [ Payment Method
Effective
> To Date ]
>
> While not as clear as your approach, it will pass validation. However
if
> the model ever requires the full spanning UC over the ternary you
would
> have to change the model back to your approach.  This is what I mean
by
> unstable.
>
> jMM'.
>
>
> -----Original Message-----
> From: Chris Bruce [mailto:chris@...]
> Sent: Friday, June 27, 2003 1:29 AM
> To: jcm@yahoogroups.com
> Subject: [JCM] Problem with mandated full span UC on nested ternaries
> with temporal aspects
>
>
> Hi,
>
> The general principle of a full span UC on nested facts I'm happy
with.
> However I've come across a problem when the fact is representing
> temporal constraints.
>
> [ Account ] is subject to a [ Payment Method ] from a [ Payment Method
> Effective From Date ]
>
> The UC is over the first and last roles giving
>
> Given any [ Account ] and [ Payment Method Effective From Date ] that
> Account ] is subject to at most one [ Payment Method ] from that [
> Payment Method Effective From Date ]
>
> The fact is stating the rule that only one Payment Method is allowed
for
> an Account at any one time.
>
> I want to delimit the Payment Method so I nest the fact as "Account
> Payment Method" and incorporate in another fact
>
> [ "Account Payment Method" ] is effective to [ Payment Method
Effective
> To Date ]
>
> With the UC over the first role...
> [ "Account Payment Method" ] is effective to at most one [ Payment
> Method Effective To Date ]
>
> The fact that I've nested the fact means I should have a full span UC
> but if I do I can no longer represent the business requirement in the
> fact: the "at most one Payment Method" constraint is lost. (I could
put
> a secondary UC over the first and last roles but this seems a cheat!)
>
> The Payment Method Effective To Date is not known at the time an
> instance of the fact is recorded so I can't make it a quaternary.
>
> The Account may have the same Payment Method on more than one occasion
> so I can't make it a binary.
>
> This seems to cause me problems every time I introduce temporal
aspects
> to facts. I know that the full span is always implied so have I really
> got a problem - except that I get an error validating the model if I
> don't have an explicit one? (I'm using VisioModeler.)
>
> I suppose the Effective to Date could be derived, but only if there
was
> a subsequent changed Payment Method. If the Account was terminated
it'd
> have to be derived from the Account Termination Date.
>
> Have I lost the plot?
>
> I believe the facts are elementary.
>
> Comments, suggestions etc. all very welcome.
>
> TIA..
>
> Chris Bruce
>
>
>
>
>
> ~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
> Would you like to learn more about Object-Role Modeling (ORM)?
>
> Then check out InConcept's ORM Seminars!
>
> These seminars will focus on the use of Object-Role Modeling to
> correctly model your business data requirements. Each day also
contains
> "hands on" labs where students practice the technique  while
> ORM-certified instructors give one-on-one assistance.
>
> Custom on-site courses are also available.
>
> For more information, please see
> http://www.inconcept.com/training/ormseminar.html or e-mail
> training@....
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> ~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
> Would you like to learn more about Object-Role Modeling (ORM)?
>
> Then check out InConcept's ORM Seminars!
>
> These seminars will focus on the use of Object-Role Modeling to
correctly
> model your business data requirements. Each day also contains "hands
on"
> labs where students practice the technique  while ORM-certified
> instructors give one-on-one assistance.
>
> Custom on-site courses are also available.
>
> For more information, please see
> http://www.inconcept.com/training/ormseminar.html or e-mail
> training@....
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>

-----Original Message-----
From: John Miller [mailto:jMiller@...]
Sent: Friday, June 27, 2003 10:38 AM
To: jcm@yahoogroups.com
Subject: RE: [JCM] Problem with mandated full span UC on nested ternaries with temporal aspects

Hi Chris,

I've argued that the full spanning UC requirement for nesting
unnecessarily contributes to the instability of the model and your
scenario is another example.

If you reduce your ternary to the binary:

[ Account ] is subject to payment method from [ Payment Method Effective
>From Date ]

With a full spanning UC and nested as: [ "Account Payment Method" ]

You can then state:

[ "Account Payment Method" ] has [ Payment Method ]

And

[ "Account Payment Method" ] is effective to [ Payment Method Effective
To Date ]

While not as clear as your approach, it will pass validation. However if
the model ever requires the full spanning UC over the ternary you would
have to change the model back to your approach.  This is what I mean by
unstable. 

 

>>That's an interesting claim, but I don't really see why it would be necessary to "change the model back". If the Account and Date no longer together functionally determine the Payment Method, there's no single thing that has an End Date, so the issue doesn't even arise. Or am I missing something? If so, please point it out, because I am very interested in this issue of UCs spanning nested objects and the arguments for and against.

Regards,

Andy 

jMM'.


-----Original Message-----
From: Chris Bruce [mailto:chris@...]
Sent: Friday, June 27, 2003 1:29 AM
To: jcm@yahoogroups.com
Subject: [JCM] Problem with mandated full span UC on nested ternaries
with temporal aspects


Hi,

The general principle of a full span UC on nested facts I'm happy with.
However I've come across a problem when the fact is representing
temporal constraints.

[ Account ] is subject to a [ Payment Method ] from a [ Payment Method
Effective From Date ]

The UC is over the first and last roles giving

Given any [ Account ] and [ Payment Method Effective From Date ] that
Account ] is subject to at most one [ Payment Method ] from that [
Payment Method Effective From Date ]

The fact is stating the rule that only one Payment Method is allowed for
an Account at any one time.

I want to delimit the Payment Method so I nest the fact as "Account
Payment Method" and incorporate in another fact

[ "Account Payment Method" ] is effective to [ Payment Method Effective
To Date ]

With the UC over the first role...
[ "Account Payment Method" ] is effective to at most one [ Payment
Method Effective To Date ]

The fact that I've nested the fact means I should have a full span UC
but if I do I can no longer represent the business requirement in the
fact: the "at most one Payment Method" constraint is lost. (I could put
a secondary UC over the first and last roles but this seems a cheat!)

The Payment Method Effective To Date is not known at the time an
instance of the fact is recorded so I can't make it a quaternary.

The Account may have the same Payment Method on more than one occasion
so I can't make it a binary.

This seems to cause me problems every time I introduce temporal aspects
to facts. I know that the full span is always implied so have I really
got a problem - except that I get an error validating the model if I
don't have an explicit one? (I'm using VisioModeler.)

I suppose the Effective to Date could be derived, but only if there was
a subsequent changed Payment Method. If the Account was terminated it'd
have to be derived from the Account Termination Date.

Have I lost the plot?

I believe the facts are elementary.

Comments, suggestions etc. all very welcome.

TIA..

Chris Bruce





~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to
correctly model your business data requirements. Each day also contains
"hands on" labs where students practice the technique  while
ORM-certified instructors give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see
http://www.inconcept.com/training/ormseminar.html or e-mail
training@....

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to correctly model your business data requirements. Each day also contains "hands on" labs where students practice the technique  while ORM-certified instructors give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see http://www.inconcept.com/training/ormseminar.html or e-mail training@....

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003

Hi Chris,

I've argued that the full spanning UC requirement for nesting
unnecessarily contributes to the instability of the model and your
scenario is another example.

If you reduce your ternary to the binary:

[ Account ] is subject to payment method from [ Payment Method Effective
From Date ]

With a full spanning UC and nested as: [ "Account Payment Method" ]

You can then state:

[ "Account Payment Method" ] has [ Payment Method ]

And

[ "Account Payment Method" ] is effective to [ Payment Method Effective
To Date ]

While not as clear as your approach, it will pass validation. However if
the model ever requires the full spanning UC over the ternary you would
have to change the model back to your approach.  This is what I mean by
unstable.

jMM'.


-----Original Message-----
From: Chris Bruce [mailto:chris@...]
Sent: Friday, June 27, 2003 1:29 AM
To: jcm@yahoogroups.com
Subject: [JCM] Problem with mandated full span UC on nested ternaries
with temporal aspects


Hi,

The general principle of a full span UC on nested facts I'm happy with.
However I've come across a problem when the fact is representing
temporal constraints.

[ Account ] is subject to a [ Payment Method ] from a [ Payment Method
Effective From Date ]

The UC is over the first and last roles giving

Given any [ Account ] and [ Payment Method Effective From Date ] that
Account ] is subject to at most one [ Payment Method ] from that [
Payment Method Effective From Date ]

The fact is stating the rule that only one Payment Method is allowed for
an Account at any one time.

I want to delimit the Payment Method so I nest the fact as "Account
Payment Method" and incorporate in another fact

[ "Account Payment Method" ] is effective to [ Payment Method Effective
To Date ]

With the UC over the first role...
[ "Account Payment Method" ] is effective to at most one [ Payment
Method Effective To Date ]

The fact that I've nested the fact means I should have a full span UC
but if I do I can no longer represent the business requirement in the
fact: the "at most one Payment Method" constraint is lost. (I could put
a secondary UC over the first and last roles but this seems a cheat!)

The Payment Method Effective To Date is not known at the time an
instance of the fact is recorded so I can't make it a quaternary.

The Account may have the same Payment Method on more than one occasion
so I can't make it a binary.

This seems to cause me problems every time I introduce temporal aspects
to facts. I know that the full span is always implied so have I really
got a problem - except that I get an error validating the model if I
don't have an explicit one? (I'm using VisioModeler.)

I suppose the Effective to Date could be derived, but only if there was
a subsequent changed Payment Method. If the Account was terminated it'd
have to be derived from the Account Termination Date.

Have I lost the plot?

I believe the facts are elementary.

Comments, suggestions etc. all very welcome.

TIA..

Chris Bruce





~~~~~~ Sponsor's Message ~~~~~~~~~~~~~~~~~~~~~
Would you like to learn more about Object-Role Modeling (ORM)?

Then check out InConcept's ORM Seminars!

These seminars will focus on the use of Object-Role Modeling to
correctly model your business data requirements. Each day also contains
"hands on" labs where students practice the technique  while
ORM-certified instructors give one-on-one assistance.

Custom on-site courses are also available.

For more information, please see
http://www.inconcept.com/training/ormseminar.html or e-mail
training@....

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/