in

The ORM Foundation

Get the facts!

Applying a default value to a value type object

Last post 08-12-2013 12:39 by micbui. 9 replies.
Page 1 of 1 (10 items)
Sort Posts: Previous Next
  • 11-03-2011 21:08

    • _Allan
    • Top 150 Contributor
    • Joined on 11-01-2011
    • New Zealand
    • Posts 3

    Applying a default value to a value type object

    When using ms-sql in design mode it is possible to set a "default value or binding".

    It can be set to a value or a function call.

    Is it possible to set this value when using NORMA?

    __Allan

    __Allan
  • 11-10-2011 15:30 In reply to

    Re: Applying a default value to a value type object

    In NORMA you can set a default value or a default value range in the property sheet of an object type as shown in the example below.

     Ken

     

     


  • 11-12-2011 17:45 In reply to

    Re: Applying a default value to a value type object

    That's not a default value, but a value constraint - it prevents any value outside the range from being used.

    In the SQL Server mapping, it gets translated as CHECK (RangeNr BETWEEN 1 AND 5), not as a default.

    I don't know any way to add a default using NORMA. Perhaps Terry can comment here, because I don't see a representation for this in ORM

  • 11-12-2011 17:58 In reply to

    • _Allan
    • Top 150 Contributor
    • Joined on 11-01-2011
    • New Zealand
    • Posts 3

    Re: Applying a default value to a value type object

    Clifford,

     I agree with you!  That was not the correct answer to the question.

     __Allan

    __Allan
  • 11-12-2011 19:07 In reply to

    Re: Applying a default value to a value type object

    Yes, you are right - my mistake.

    If you are using SQL Server, then you can set the default value for a column in SQL Server Management Studio.

    In the Tables folder, right click on a table and choose "Design". Then click the column where you want to create the default value and enter the value in the "Default Value or Binding" cell of the properties sheet for that column.   

    Of course it would be nice to have it in NORMA...

    Ken

  • 11-15-2011 20:22 In reply to

    Re: Applying a default value to a value type object

    Hi Allan,

    There is currently no setting for doing this in NORMA.

    There are certainly some things that could be applied in this area, but the fundamental problem is that it is not always clear how a 'default value' on all types of conceptual fact types actually means. When you're talking about a default value in a relation--such as a column in a relational table--then you already have already dealt with the question of existence: the row must exists for the default to be applied. Translating back to the conceptual world, this means that another fact (such as the identifying fact type that populates the primary key) must be true before the default value can be applied.

    A default value would definitely not apply to a ValueType, but it could apply to a fact type with a value role, meaning a role that is not under a uniqueness constraint. This is reasonably well defined for binary fact types with a value role connected to a value type, but becomes much trickier as soon as you hit a multi-role non-spanning uniqueness constraint.

    [I'm not proposing a solution here, just trying to introduce some of the potential issues.]

    The conceptual binary case translates most directly to the relational default value. However, it isn't all theoretical smooth sailing. The first question arises with the mandatory/optional setting on the functional role (the role under the uniqueness). Conceptually, automatically populating the fact type if the functional object exists means that this role is always mandatory. However, I think this would be counterintuitive to most modelers, who would expect default values to apply only to optional fact types. There is a similar issue with the implied mandatory on the non-unique role. For example, if the PersonName value type is used only in the Person has PersonName fact type, then there is an implied mandatory constraint on PersonName that means no PersonName instance exists that is not associated with a Person instance. However, if the default value is '<Unknown>', we have to ask if this is a theoretical violation of the implied mandatory constraint. After all, we now have a PersonName instance that was not asserted.

    Basically, what you now have is a semi-derived fact type with the derived portion dependent upon the asserted portion. As with other derivations, the choice of storage needs to be made when this is mapped to a relational model. For a binary, the theoretically cleanest way to do this is with two columns, one asserted and the other calculated. The calculation would provide the default value, and the user would read the derived column and write to the asserted column. Unfortunately, this is somewhat impractical from the relational perspective, although it does allow a more flexible model than the 'default value' approach because the default is stored once (in the derivation rule) instead of being injected into each row of the table.

    The bigger issue with default values comes with the n-ary case. Consider Person(.id) speaks Language(.code) with Proficiency() with a uniqueness on the first two roles and a default value on the Proficiency role. Unlike the binary case, where you clearly apply the default only when the functional role player is populated, the population in this case is actually a cross product of all Person and Language instances that are not formally paired in this fact type. This makes sense for a query or as part of a derivation rule, but is definitely not something you would want to populate. Also note that in this case there is an implied objectification with a co-referenced binarized form behind the scenes (but visible if needed) in NORMA. In the binarized form, the Proficiency role here is mandatory, so is probably not a good default value candidate anyway.

    Given these theoretical concerns, if we add this, I would suggest the following:

    1. Limit it to non-spanning binary cases only.
    2. Allow value types or simply-identified entity types only on the value role.

    Even in these cases I have reservations about the conceptual nature of this feature, but I agree that it can be very useful and that some architects much prefer a default value to a null, so I think we should consider it. At the very least we should allow adding it at the relational column level (where the existence question is not an issue and all identifiers are resolved).

    -Matt

  • 11-17-2011 15:53 In reply to

    • _Allan
    • Top 150 Contributor
    • Joined on 11-01-2011
    • New Zealand
    • Posts 3

    Re: Applying a default value to a value type object

    Wow – big answer.  For now I will go forward knowing simply that the answer is ‘No’.

    Thank-you for the response!

    __Allan
  • 11-17-2011 17:19 In reply to

    Re: Applying a default value to a value type object

    Hi Allan,

    You made me laugh. I wasn't trying to overdo it, but I think I failed.

    I think the fundamental issue is that on the conceptual side--which is just a first-order logic representation of the domain--there are only notions of true or false. The default value question issue is a question for the logical schema, not the conceptual model. Conceptually, if A r Value, then a derived fact type would state (logical keywords in boldA r resolved- Value1 iff that A r that Value1 or (that A r no Value and Value1=DEFAULT).

    This basic pattern derivation pattern is also generalizable to n-ary and entity cases, whereas the logical schema notion of default value does not move as well. Applying this pattern to a mandatory fact type is also pointless (the second clause is never executed), so there is more conceptual consistency there as well. Clearly, a smart mapping engine could look for this pattern and choose to implement it using a relational default value. However, we need to be very careful about extending the conceptual model to cater for this notion.

    I'm interested in hearing what others think about this, but the simple answer (and definitely the current one) is 'No'.

    -Matt

  • 11-17-2011 17:40 In reply to

    Re: Applying a default value to a value type object

    Hi Matt,

    Regarding " What might be helpful"?

    It seems to me that it would be useful to add a "default value" field in the property sheet of each column of the relational model.

    That way, you could set the default values during the modeling phase, rather than waiting until the physical DB had been generated.
    Of course the default value would have to be included in the DDL.

    Ken

     

     

  • 08-12-2013 12:39 In reply to

    • micbui
    • Not Ranked
    • Joined on 06-18-2008
    • Posts 1

    Re: Applying a default value to a value type object

    This is the similar approach to what is done in Visio (Architect) version. The data model diagram that is derived from the ORM model allowed you to set the default value for the column. This didnt affect the ORM model when it was updated. It would be nice to have this feature for smaller database. Having to use another tool and additional steps, increases the complexity and management.
Page 1 of 1 (10 items)
© 2008-2014 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service