The ORM Foundation

Get the facts!

IsIndependent greyed out & Facts not in Relational & ER views

Last post 06-24-2008 15:12 by Matthew Curland. 4 replies.
Page 1 of 1 (5 items)
Sort Posts: Previous Next
  • 06-16-2008 7:28

    IsIndependent greyed out & Facts not in Relational & ER views

    Some of the entities in several of my models have the "IsIndependent" property greyed out.
    It is also the case that some of the facts don't appear in the relational view.
    Lastly, in some cases, the ER view does not have the same structure as the relational view.

    Any clues anyone?




    Filed under:
  • 06-16-2008 13:19 In reply to

    Re: IsIndependent greyed out & Facts not in Relational & ER views

    Hi Ken,

    If by ER view, you mean the Barker ER view, I know that's a work in progress.  A grad student is handeling that, and it's mentioned in the notes as a "premininary effort."  The feature first appeared in an intermediate build about a week before the last version drop.  I had mentioned a missing table (and other quirks) to Matt, as well. 

    As for the IsIndependent grey-out, I haven't looked for or noticed that - as I haven't been concerned with optimization in the resulting DBs for the test models I've done.  My guess is that the tool might recognize instances where making a seperate table would undercut the model inegrity elsewhere.  If you look at the ObJect Types involved in the Fact Type that you can't make independent, what is the reference mode, compared to Fact Types you can make independent?  I'd also look at external uniqueness constraints, and other differences for clues.  If the grey-out is random - then mabye it is just a bug.

    I'm glad you're testing nORMa models, as your work with VEA will help you spot things I for one would likely miss. 


  • 06-16-2008 14:22 In reply to

    Re: IsIndependent greyed out & Facts not in Relational & ER views

    Hi Brian,

    Thanks for your interesting observations. 

    Yes - I was referring to the "Barker ER view".
    Since most folks know what "ER" means and since Terry's book clearly explains why the focus is on the Barker ER notation, I can't see the value in releasing code that has numerous clearly visible problems.
    Better to keep things under wraps until a "solid" piece of functionality can be released.

    In the "IsIndependent grey out" issue, I have tried several different models with different results. (some greyed out and some not)
    My concern is that my tests did not help me to reveal any underlying "rules of behaviour".

    For example, in a model with an entity that has three subtypes, I first set the IsIndependent" value of each subtype to true and the relational view was correct in that it showed three additional tables.  Then I generated a Barker ER model from the same ORM diagram - it did not recognise the "IsIndependent" property that I had just set.
    Then I went back to the relational model and - no three tables and the IsIndependent property was greyed out.
    It looks as though my sequence has reset some fundamental property in Visual Studio that is now being persisted to my new models.
    This may not be the case - its just the best idea up with which I can come at present!

    Regarding VEA - yes - what I'm doing is bulding an ORM model in VEA and generating a logical schema.
    Then I'm recreating the ORM model in NORMA and comparing the NORMA relational model with the VEA logical model.
    In addition I'm doing this on a single (4GB) machine with two large screens so that I can see everything in one glance.

     Maybe Kevin or Matt have some clues on these issues.

    Filed under:
  • 06-16-2008 15:40 In reply to

    Re: IsIndependent greyed out & Facts not in Relational & ER views

    Hi Ken,

     The side by side of VEA and nORMa test should be useful to the team for evaluating feature behavior.  I’m not as concerned as you are about injecting untested features (like the Barker view) into the CTPs, as long as they are optional, and the status is noted.  If this were a fully supported finished product, or even a late beta or RTM it would be unacceptable, but I’m Ok with this in a CTP.  I think last month’s issue with shape connections not matching predicate readings was a bigger issue, as it was long standing core feature of the tool.  On the Barker view, they could have held off and did more internal tests, but I guess they weigh that against the opportunity to give us a chance for a preview, and provide feedback.  You’re right in that it has to be fixed. In another thread, a member pointed out his opinion on concentrating on UI usability, where I had mentioned my preference for getting the internal logic correct as the highest priority.  I’d put the missing tables in Barker View in the later, but as it’s a new and optional feature of the tool, I wouldn’t put it as high as issues that concern the model itself.  I thought the release notes (not the README included in the folder, but the notes posted in the OF Library for the download), that accompanied the last drop were a big improvement over what we got from the SourceForge notes.  There’s still room for improvement in documentation (internal help and tool tips, as well as better notes, README, and external documents); but it’s better than it was. Your detailed notes on IsIndependent issue ought to help the team track down the cause. The Barker omissions I noticed we not matched in the Relational View.  I don’t know enough about Barker to say if that means it’s a simple bug  - but I’d be more worried if the same tables were missing in both extensions.   BTW, have you tried to use the LINQ to SQL feature in the VS2008 version yet?  I see the files generated, but haven’t tried writing any .Net language queries.  It will be interesting to see if there are any similar omissions, as you pointed out in the Barker View – even more interesting if they contain the same elements. BRN..


  • 06-24-2008 15:12 In reply to

    Re: IsIndependent greyed out & Facts not in Relational & ER views

    The semantics are straightforward: IsIndependent can only be set if the ObjectType places no non-existential explicitly mandatory roles. We enforce this in the underlying object model (setting IsIndependent to true on such a beast should throw), and disable the UI if we know changing the value will cause an exception in the model.

    The question then becomes when does an element play a mandatory role? There are a couple of non-obvious cases. First, subtypes always play a mandatory role corresponding the implied 1-1 relationship between the subtype and its supertype. The resulting behavior corresponds to the "The [independent object type] term is not used for subtypes" on page 291 of the brown good. The other case that is non-obvious is an objectification with an explicit identifier (set the RefMode property). In this case, the implied FactTypes for the coreferenced form are mandatory. What concerns me most here is your

    Ken Evans:
    I first set the IsIndependent" value of each subtype to true
    statement, which shouldn't be possible. If you set 'IsIndependent' before attaching the subtype, then the property will automatically be set to false when the subtype is connected. I could not get any case where this does not happen.

    If you want to give a subtype a separate table, then turn on the Relational Model extension, click the subtype, and set the 'AbsorptionChoice' property to Separate. IsIndependent will often have the side effect of adding a table, but this is not the only way to add said table. The AbsorptionChoice property is part of the 'Relational Mapping' extensions and has no effect on the Barker model. The Barker ER mapping is very new. It is clearly marked as 'preliminary' andhas no effect on the product until you explicitly turn it on. Subtyping, name generation, and most case of live regeneration are not currently implemented in the Barker model (turn both Barker extensions on and off to regenerate). I wouldn't read too much into the different mappings at this point: the Barker mapping is generally much more direct than the relational because the subtyping maps to a basic containment hierarchy.

    Please share any case where you can set a subtype's IsIndependent property to true. The Barker code should have no effect here, the IsIndependent property is not referenced by any of the relational or barker extension projects (6 total). The value is used by the absorption model, which the other mappings are based on.


Page 1 of 1 (5 items)
© 2008-2014 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service