in

The ORM Foundation

Get the facts!

Derivation and tables

Last post Mon, Oct 27 2008 16:15 by Ken Evans. 6 replies.
Page 1 of 1 (7 items)
Sort Posts: Previous Next
  • Sat, Oct 25 2008 12:50

    • rolemo
    • Top 25 Contributor
    • Joined on Sun, Oct 12 2008
    • Posts 38

    Derivation and tables

     Hi Terry,

    I've noticed that once I add derivation rules, the derived fact types are erased from the relational view. Could you help me understand the reason for this?

    For instance, for the attached diagram only one table is generated, the WBT, with two columns (WBTId and FTPCode).

    Cheers 


  • Mon, Oct 27 2008 13:15 In reply to

    Re: Derivation and tables

     I suppose the underlying question would be:  What are the derivation rules?  If these truly are derived facts, i.e. derived from other information in the model, then that single-table map would be correct.That is the only fact not marked as derived! If you want them to be 'derived and stored', mark the derivation rule property for the fact type to 'derived and stored' - you'll see a double star on the diagram, and it should also affect the relational mapping

     

    Also, be wary of any fact type that uses the word 'is' for its predicate. If it really is an 'is' relationship, perhaps you want a subtype, or even a single object to represent both. 

  • Mon, Oct 27 2008 13:24 In reply to

    Re: Derivation and tables

     I have attached what I believe may be a better way to represent what your diagram appears to be attempting to represent, using subtypes. It carries these assumptions:

     

     All Content types either are WBT or are NOT WBT.

     All WBT Content types are stored in exactly one FTP

     An FTP may store any number of WBT content types.

     

    [Edit] This is still technically incorrect, as there is (in the model) no way to determine if a given Content type is or is not a WBT. To correctly use subtypes, you need to have a subtype rule. In this instance, a simple unary fact on Content type, 'is WBT', and some text for the subtype rule would be enough.

     


  • Mon, Oct 27 2008 14:12 In reply to

    • rolemo
    • Top 25 Contributor
    • Joined on Sun, Oct 12 2008
    • Posts 38

    Re: Derivation and tables

    thanks!

    it is better. should have thought of it myself...

  • Mon, Oct 27 2008 14:49 In reply to

    Re: Derivation and tables

    Hi Orion

    Thanks for answering Rolemo's question. As a minor refinement to your answer, ORM 2 allows subtypes to be (simply) asserted, derived, or semiderived. So it is OK to simply assert the subtypes you show without a definition, if that is what you prefer. We hope soon to distinguish these 3 kinds of subtypes graphically as discussed in the BBB (append "*" to the name of derived subtypes, and append "+" to the name of semiderived subtypes).

    Cheers

    Terry

  • Mon, Oct 27 2008 15:09 In reply to

    Re: Derivation and tables

     Thanks!

     

    That is good to know, Terry!

  • Mon, Oct 27 2008 16:15 In reply to

    • Ken Evans
    • Top 10 Contributor
      Male
    • Joined on Sun, Nov 18 2007
    • Stickford, UK
    • Posts 801

    Re: Derivation and tables

    Hi Rolemo,

    I hope that you are finding the website and feedback from other members to be useful.

    However, I have been wondering if you realise that the answers to most of your questions are in Terry's 942 page "Big Brown Book". You could save yourself a lot of time by finding answers to your questions in the book and then discussing the things that you don't understand on the website.

    The book contains lots of detail and lots of exercises and I can thoroughly recommend it.

    Cheers
    Ken  

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