IDEF1X Optional-Non Identifying - Wrong!

[Paolo F Cantoni]

I've reversed engineered a large ORACLE model into EA.

At present I'm off-site and so can't look into the database directly.  However, I DO have a reverse Engineered Embarcadero ERStudio model of the same database and I'm engaging in a compare and contrast exercise.

I am comparing a small submodel and Embarcadero claims that a number of relationships are (in IDEF1X terms) optional, non-identifying.  The cardinality is "Zero or One to Zero or More".

EA claims it is mandatory.  However, if I change the multiplicity of the target role from 1 to 0..1, I get the wring symbol at the target end (and the line doesn't go dotted as required by IDEF1X).  If I change it from 1 to 0, the symbol doesn't change (and the line also doesn't go dotted).

Can anyone confirm this IDEF1X anomaly?  I'm using build 797.

TIA,
Paolo

[sargasso]

Paolo,

Can you give me a small concrete example.  I'm not to good on (read "cant stand") IDEF1X,  but I'll try it if I can get an IE  model that means "something".

bruce


(Correction: your demotion to a small "p" has been rectified.)

[sargasso]

Hang on, I may have it.

1. At the barbie there are 0..n Eskys (chillibins for you sassenachs)
2. At the barbie there are 0..n beers.
3. Some of those beers are in some of those Eskys.
4. There exists attr "Esky.Owner" which implies a relationship  beer.Owner.
5. It is ( ) possible there are no Eskys or beers.
6. It is possible ( ) there are beers unassociated with Eskys.
7.  The goal is to "SELECT beers WHERE Implied(BEER.OWNER) = null".

Possible diagram exists here >< failing that http://sargasso.sphosting.com/beer1.png

Confirm!


bruce

[Paolo F Cantoni]

Hang on, I may have it.

1. At the barbie there are 0..n Eskys (chillibins for you sassenachs)
2. At the barbie there are 0..n beers.
3. Some of those beers are in some of those Eskys.
4. There exists attr "Esky.Owner" which implies a relationship  beer.Owner.
5. It is ( ) possible there are no Eskys or beers.
6. It is possible ( ) there are beers unassociated with Eskys.
7.  The goal is to "SELECT beers WHERE Implied(BEER.OWNER) = null".

Confirm!


bruce

NO... At the barbie are beers and bogans.  Both Embarcadero and EA agreed that each bogan may drink 0 or many beers (you may treat the lower bound as unlikely - but must be modelled just in case there's a designated driver).  Embarcadero says each beer may be drunk by up to 1 bogan (since they start life in the above mentioned Esky).  EA says each beer MUST be drunk by exactly one bogan.  This can't be so since at the start of the barbiie, they're in the Esky.

Now, my point is, even if I tell EA that the beer to bogan relationship is optional, it doesn't change the rendering to show that...

Capiish?
Paolo

[Edit: Information Engineering rendering is OK - however the reverse engineering is wrong]

[sargasso]

Ah. Gotcha.  And it looks like you're right.  hmmmm

I'll keep trying.

bruce

Confirmed!  (However, I always thought IE was better!)
http://sargasso.sphosting.com/Beer2.PNG

oops for some strange reason I neglected to add the "bad" model
http://sargasso.sphosting.com/Beer3.png
and, which from ERWin
http://sargasso.sphosting.com/beer4.png

[sargasso]

Missed your edit.  Are you saying there are two problems?  I haven't tried reveng.
b

p.s. a pox on sphosting - anyone got a good image sight! site!
:-/ <- Sorry Bruno.....  stand by....

[Paolo F Cantoni]

Missed your edit.  Are you saying there are two problems?

Yes bruce...

The RE was bad (but I can't test that yet as I don't have access to the DB at moment.  Will check on site tomrrow...)

But even if I could fix the RE, the adornment is broken as you  indicate in the diagram...

Paolo

[Paolo F Cantoni]

OK,  I've now verified (in my own mind) that the Reverse Engineering bug exists and have reported it to Sparx.

Can anyone else confirm the bug?  Environment was EA: 797 (6.5) and ORACLE 9i on Solaris.

If you have a nullable foreign key constraint, it reverse engineers as mandatory (not nullable) instead of optional.  NOTE, I found the bug on the initial reverse.  It may not appear on subsequent (not tested).

TIA,
Paolo